别把 LLM 当架构师，把它当成一个执行力爆表的超级实习生

很多人在用 AI 写代码时，最常见的误区就是试图让 LLM 扮演“架构师”的角色，希望它能给出最优的软件设计方案。但实际操作下来你会发现，LLM 在软件设计权衡上的能力，其实比资深架构师差了上百倍。它知识面极广，但缺乏真正的判断力。

我最近在处理一个超过 35 万行代码的复杂项目时，通过调整协作模式，在连续 16 周的实测中发现了一个惊人的数据：我的产出效率达到了前 AI 时代的 40-50 倍。以前一年勉强写 6 万行代码，现在平均一周就能产出同等规模的代码量。

这种效率的提升并不是因为 AI 变得更聪明了，而是因为我改变了与它的协作逻辑。想要真正榨干 AI 的生产力，必须把它定义为一个“单词计算器”而非决策者。以下是我总结的三套实操逻辑，希望能给还在纠结 AI 代码质量的朋友一些参考。

首先，必须将所有思考环节前置，在编码阶段强制 AI “关闭思考”。

很多开发者最头疼的是，AI 在写代码的过程中经常反复质疑已确定的逻辑，或者在不该修改的地方自作聪明。我的解决方法是：在让 AI 写代码之前，先写一份极其详尽的设计规范（Design-spec）和实现规范（Implementation-spec）。

在这两份文档里，我会把所有的逻辑死角、接口定义和边界条件全部定死。当任务交给 AI Agent 执行时，所有的歧义已经在前置阶段被我解决了。此时，我要求它单纯地执行指令，不要在已经定死的设计上自我纠结。当你把“思考”和“执行”彻底解耦，AI 才会变成一个纯粹的高速产出机器。

其次，对任何“不和谐”的信号保持零容忍，实时对齐输出。

我绝对不会在 AI 生成代码时走开，而是盯着每一行输出。一旦发现 AI 说了任何与我预设设计不符的话，哪怕是一个变量名的细微偏差，我也会立刻中断生成。

因为这种微小的偏差通常是一个危险信号，意味着 LLM 的上下文（Context）已经发生了偏移或产生了误解。如果此时不及时纠正，AI 会在错误的路径上通过自我强化继续写下去，导致后面生成的代码全部变成难以维护的“AI 垃圾（Slop）”。实时监控并及时掐断，是保证大规模代码产出质量的唯一手段。

最后，手动规划优先级，并构建外部验证闭环。

我依然坚持传统开发的思维，亲自设计功能开发的先后顺序，先解决那些未知的技术风险，最后才填充业务复杂度。最关键的一点是：我绝不靠肉眼检查代码正确性，而是构建自动化的验证机制（Harnesses）。

举个具体的例子，我在处理图形渲染相关的模块时，绝对不会简单地通过运行结果“看一眼”是否正确，而是直接调用 Skia 的像素级对比测试来验证输出结果。我把 AI 放在一个它绝对能成功、且有客观标准可循的环境里工作。只有通过这种客观的验证闭环，才能确保 50 倍产出率带来的不是 50 倍的 Bug。

总结来说，LLM 确实能快速实现某个算法或写个 Demo，但它无法决定软件“为什么”要这么构建，也无法在灵活性和实用性之间做权衡。在 AI 时代，开发者的核心竞争力已经发生了转移：现在的关键不再是你写代码的速度，而是你是否能快速阅读并分辨出，哪些是高效的执行，哪些是它在自信地胡说八道。