AI驱动开发的体感记录 - 与Claude Code共度的5天真相

实验开始:不碰代码的限制玩法 配合前几天的网站改版,正在重新构建工具群。 本来是自制的工具们,但这次特意决定用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 - 二维码生成·读取工具 ...

2025-06-15 · aoiroinc

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也一样。不,某种意义上比人类限制更严格。 ...

2025-06-07 · aoiroinc