40-50倍的代码产出率
很多人把LLM当成能独立思考的架构师，这其实是最大的误区。在我看来，它们更像是一个知识面极广但缺乏判断力的“超级实习生”——执行力极强，但在软件设计权衡上比资深架构师差100倍。想要真正榨干AI的生产力，必须改变协作模式，把LLM当成一个“单词计算器”而非决策者。
以下是我在处理超过35万行复杂代码库时总结的三套实操逻辑：
一、前置设计，在编码阶段“关闭思考”
很多人的痛点是AI在写代码时总是反复质疑或修改已经确定的逻辑。我的做法是将所有思考环节前置，先写一份极其详尽的设计规范（Design-spec）和实现规范（Implementation-spec）。
当任务交给AI Agent执行时，所有的歧义已经由我提前解决了。此时我会尽量降低AI的“思考”权重，让它单纯地执行指令，避免它在已经定死的设计上自我纠结。
二、实时对齐，对任何“不和谐”信号零容忍
我绝不会在AI生成代码时走开。我会盯着每一行输出，一旦发现AI说出任何与我脑中设计不符的话，立刻中断。
因为这种微小的偏差通常意味着LLM的上下文（Context）已经发生了偏移或误解。如果不及时纠正，后面生成的代码将全部变成难以维护的“AI垃圾（Slop）”。
三、手动规划优先级，构建外部验证闭环
我会像传统开发一样，亲自设计功能开发的先后顺序，先解决未知风险，再填充复杂度。
为了确保正确性，我不会靠肉眼检查，而是构建自动化的验证机制（Harnesses）。比如在处理图形渲染时，我会用Skia的像素级对比测试来验证，而不是简单地看一眼。我把AI放在一个它绝对能成功、且有客观标准可循的环境里工作。
说到底，LLM能快速写个Demo或实现个算法，但它无法决定软件“为什么”这么构建，也无法在灵活性和实用性之间做取舍。目前最核心的竞争力，其实是你能否快速阅读并分辨出哪些是高效执行，哪些是自信地在胡说八道。
