二维码

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