工具开发

实验开始：不碰代码的限制玩法 配合前几天的网站改版，正在重新构建工具群。 本来是自制的工具们，但这次特意决定用AI驱动重构。理由很简单明了。“因为比我准备的东西UI更精致”。 生成AI使用Claude Code。而且，给自己定的规则是这个： 读生成的代码，但自己完全不碰。只通过提示指示完成。 简直是限制玩法。到底能做到哪里？ 第一印象：超出期待的精致度 首先，关于UI超出了期待。确实很精致。 与自己做的硬核实用系UI相比，Claude Code生成的界面明显时髦漂亮。响应式对应也理所当然地内置，也能看到对无障碍的关照。 “哦，这确实厉害” 最初的感动确实存在。 渐渐看到的"Claude感" 但是，做的工具越多，渐渐产生既视感。 都变成类似的"外壳"。而且，不知为何喜欢青色和紫色的渐变氛围。嘛，因为是漂亮的颜色所以也不错。 这方面"用Claude Code做的感"明显表露，外观方法还有改进余地吧。 就像，同一个设计师反复使用模板的感觉。 单功能工具的话"几乎一击"的威力 做出来的东西大多运行良好，说明等也非常恰当。说实话，作为助手超优秀。 如果是单功能的紧凑工具，几乎一击就能拿出期待值90%左右的东西吧。真的无可挑剔。 “大部分东西用这个就行了吧？” 这样想。如果能完成满意的东西，那就OK吧。 但是，踏入坚持的沼泽后… 不过，如果"想做得更好"“想加功能"“想按我的喜好调味”，话就完全变了。 从这里开始的话，就要下定决心重新面对AI。 不如说，就跟对着人一样了。 专业vs专业的墙：传达的困难 想法不同时，“想这样"传达给对方，让对方输出期待的东西，相当困难。 如果自己是外行，就做不出精细的好坏判断，“好厉害～“就结束了。 但是，如果对领域很了解，或者坚持变强，就不是那样了。专业vs专业越是如此，越会注意到那沟壑、差距的巨大。 创造性活动越是如此，越明显。 也许与建筑师和AI的关系一样 这与建筑、绘画和雕塑等艺术、音乐、文学、戏剧、甚至料理世界等，完全一样也说不定。 一个人就能做的东西，制作者变成多个的瞬间，不正确传达就无法成形的瞬间就会到来。 看到目标的能力 那个过程的安排能力 在与AI更进一步的开发中，正是这里被考验。 即使AI是全知全能的神，如果这边的传达能力弱就完全得不到想要的结果。 与人类管理业务的共通点 撇开具体做法不说，作为感想与对人传达事物的管理业务完全一样的印象很强烈。 推测对方的理解度 以适当粒度传达信息 接受反馈进行轨道修正 为了目标持续沟通 正是项目管理本身。 超越"被夺走工作"的次元 AI夺走程序员工作的话题，已经不是那个次元了。 要管理生成AI取得成果需要： 更需要提高分辨率的理解 需要看穿未来的能力 需要明确想象目标的能力 那个精度的高低决定好坏 也就是说，得出了需要更广泛的知识和经验的结论。 实战数据：制作时间和难度 总结了实际制作花费的时间和体感难度。当然"完全不碰代码的限制"基本遵守了。 难度⭐️：几乎一击的世界 Web字体比较工具 制作时间：约10分钟 指示次数：几乎1击 难度：⭐️ Favicon生成工具 制作时间：约20分钟 指示次数：2〜3击 难度：⭐️ 图像转换工具 制作时间：约30分钟 指示次数：5〜10击 难度：⭐️ QuickQR Enhanced - 二维码生成·读取工具 ...

从简陋QuickQR的脱离 QuickQR Enhanced，终于完成了。 说起原来的QuickQR，外观简陋，功能只是把文本转换成二维码，简直是"能用就行"精神的化身般的工具。 但这次，随着网站改版的流程，“既然如此就把外观弄漂亮，功能也扩展一下”——以轻松的心情着手，结果成了噩梦的开始。 结果，搭载了WiFi设置、联系人、事件、位置信息、批处理、预设管理、历史管理、相机读取、打印功能，成了远超当初设想的高功能工具。 与AI讨论让功能增殖 “如果能做WiFi设置的二维码就方便了” “也想对应联系人的vCard” “位置信息二维码应该很有趣” “如果能批处理就高效了” 与AI讨论时，想法不断涌现，不知不觉功能就增殖了。 生成AI不断提议"这样的功能怎么样？"，我就不由得说"那也不错！"。简直是功能的通货膨胀状态。 1000行的壁垒 - 感受到AI极限的瞬间 最初500行左右很顺利。AI输出的代码几乎一次就能运行，我想"这很轻松啊"。 但是超过1000行后情况就完全变了。 代码输出耗时异常（能泡好一碗方便面的程度） 输出的代码无法运行 请求微调却破坏了别的部分 交流增多，修正的修正的修正… “啊，这是AI的极限”——感受到的瞬间。 大规模代码库时，AI也无法完全掌握整体。就像人类一样，撞上了复杂性的墙。 AI时代设计阶段的革命 - 看到的新方法论 这次经验让我再次感受到设计阶段的重要性。不，不仅仅是重要性。是生死攸关的程度。 传统开发中，“先做出能动的东西，之后重构"的方法也可以。但对AI就不行。 准备八分，AI一二分？ 自古有"准备八分"的说法，但AI开发时代可能已经是**“准备九分”**了。 从这次经验中看到的，是需要以更高的分辨率描绘到达开发完成目标的剧本。 具体来说： ❌ 不好的例子："添加WiFi功能" ⭕ 好的例子："用WiFiForm类管理SSID/密码/安全设置， 向QRGenerator类传递字符串，以WIFI:T:WPA;S:...格式生成" 对AI说"添加WiFi功能”，它会迷失在如何嵌入现有代码的哪里。但如果事先明确接口和责任范围，AI就能毫不迷茫地实现。 依赖关系的可视化是生命线 特别是松耦合的设计。需要减少功能和代码的依赖，构建一个变更不会影响其他部分的结构。 这次深刻体会到，AI不擅长把握依赖关系。人类能直觉地知道"啊，改了这里会影响那里"，但AI看不到。 最终，切换到了分割文件、逐步固化能确实运行的部分的策略： core_utils.js - 基本工具（不依赖其他） ui_manager.js - UI相关（仅依赖core_utils） data_manager.js - 数据管理（仅依赖core_utils） qr_generator.js - 二维码生成逻辑（完全独立） 就像这样。让各个部分独立运行，明确接口。正是松耦合的方法。 AI共存的新方法论 这方面从这次经验中隐约看到了一些东西，但今后需要确立好的方法。 这大概会成为在代码生成AI共存中新诞生的方法论。 在传统设计手法之外： AI容易理解的模块边界设计 考虑上下文量的功能分割 掌握AI能保持输出质量的代码规模 人类最后能保证质量的粒度设计 虽然还在摸索，但能确定的是**“AI变聪明了所以设计可以随便"是大错特错**。 反而相反，正因为与AI协作，更需要精密的设计。 1000行的教训 - 与AI上下文限制的相处之道 “AI不是万能的"虽然脑子知道，但通过1000行的壁垒亲身体会了。 人类也有一次能掌握的信息量的极限。AI也一样。不，某种意义上比人类限制更严格。 ...

网站迁移的副产物 前几天的网站迁移完成后，在新环境中进行各种整理时，发掘出了多年积累的大量"私人工具"。 都是"如果有这样的东西就方便了"这种想法做出来的，然后就一直自己一个人悄悄地用着。大部分都是CUI（命令行）工具，连UI的概念都没有。代码很乱，使用方法也只有自己懂，简直是"能用就行"精神的集合体。 整理外观的苦行 既然如此就想着公开试试，但这比想象的要困难得多。 毕竟要把CUI工具变成Web工具，需要从头开始做UI。从"通过参数传递设置"改为"通过表单接收输入"，从"向标准输出输出结果"改为"整齐地格式化显示"… 最困难的是，我没有像样的设计品味。虽然能做功能，但做出"让人想用的UI"是另一种技能。 被生成AI拯救的故事 这时作为救世主登场的是生成AI。 当我指示"想要这样功能的工具，想做成这样的UI"时，几乎无代码就能做出差不多的东西。从CSS Grid的使用方法到响应式对应，甚至动画。 特别令人惊讶的是，即使是"通过拖放接收文件，能下载处理结果的工具"这样复杂的要求，也能一次生成可运行的代码。 说实话，看到过去花费数小时在Stack Overflow上搜索、阅读MDN、试错制作的功能，只需一个指示就完成了，心中不禁感叹"那些辛苦算什么…"。 真的，到了了不起的时代了。 （这方面的话题，想在别的机会详细写写） 坚持的要点 在整理时，有一些不能妥协的部分。 轻量 没有比加载时间让人烦躁的工具更容易不用的了。最小化必要依赖，快速打开快速使用。这很重要。 易用 比UI的美观更优先操作的易懂性。目标是不看说明书也能直观使用。（能否达成是另一回事） 在本地环境运行 这是我长久以来的坚持。 一般来说，图像转换和数据处理在服务器端进行是主流，但我从互联网开始普及的时候就一直努力用JavaScript解决。 当然，当时JavaScript没有现在这么强大。记得一直在和浏览器的"禁用JavaScript"设置作斗争。不知道显示了多少次"脚本已被禁用"的消息… 但是，“不向外部发送数据"从隐私和安全的角度来看非常重要。特别是图像类工具，经常处理机密性高的数据。 现在，随着JavaScript的进化和浏览器API的充实，以前不可能的处理也能在客户端完成了。多年的坚持，终于在技术上得到了回报的感觉。 响应式适配是理所当然 不用说了，能从手机使用是前提。 技术上有趣的点 既然如此，也说几个技术上有趣的部分。 使用Web Workers进行后台处理 繁重的处理交给Web Workers，不阻塞UI。进度条也实时更新，没有"卡住了？“的不安。 OffscreenCanvas用于图像处理 也活用了能将Canvas操作从主线程分离的OffscreenCanvas。在处理大量图像时对性能提升很有效。 说起来，已经迈入第8年的Pixnote也一直在使用Canvas进行图像转换、坐标转换、压缩处理等，这次回顾工作让我重新体会到了那份乐趣。 当时"浏览器能做这样的事情"让人惊讶的功能，现在已经能理所当然地使用了。技术的积累，真的很有趣。 说到Pixnote，虽然一直想着要做YouTube视频说明，但需要说明的内容太多，至今只做了3个视频就结束了。真是三天打鱼… 视频制作需要集中的时间，现实中很难下定决心。但在那之前会在这里写文章。因为网站改版后能写文章了！ 文字的话即使在碎片时间也能写，也能仔细说明技术细节。在视频准备好之前，打算在这里继续发信息。 与JavaScript的长久交往 通过这次工具群整理，重新回顾了"与JavaScript的长久交往”。 最初被当作"玩具语言"的JavaScript，现在已经成为正式的应用开发语言。在浏览器上能进行视频编辑、3D渲染，甚至机器学习。 以前在被说"JavaScript无法进行文件操作"的时代，勉强用Data URI和Blob API努力的经历很怀念。现在File API和FileReader API理所当然地使用，拖放也简单。 能切身感受技术进步，是工程师的特权。 今后的展望 总之，打算从手头能展示给别人的状态开始依次公开。还需要"发掘工作”，请长期关注。 重新认识到，比起从零开始做新工具，有时候把现有的CUI工具Web化更困难。但因为是自己实际在使用的，至少不是"纸上谈兵"。 总结 在新的网站环境中，终于能轻松公开这样的实验性内容了。不是"做完就结束"，而是想做成实际持续使用并改进的Live项目。 贯彻多年的JavaScript之爱和"对本地处理的坚持"，希望能培育出有用的工具群。 也请随意提出需求和bug报告。不过，可能会收到"抱歉，还在发掘中"的回复。 Lab: https://aoiroinc.com/zh/lab/