今年二月，我决定做一个实验：核心项目的代码全部用 AI Agent 来写，我只负责审查和调试。
不是玩票，是玩真的。一个正在线上运行的数据管道，每天处理几十万条业务数据。我给自己和 Claude 三个月时间。
先说结果：代码确实写完了。功能也上线了。但省下来的时间……几乎为零。
原因有三。
第一，review 的时间比你想象的长。
AI 写的代码看起来很漂亮。格式规范、注释整齐、变量命名合理。但当你真正一行一行去读的时候，会发现一些非常隐蔽的问题——边界条件没处理、异常捕获得太宽、性能在小数据量下没问题但上了量就会崩。
这些问题不是因为模型不行，是因为模型没有"部署焦虑"。它对代码的思考停留在"这段代码能在 IDE 里跑通"就结束了。而你需要思考的是"这段代码在凌晨三点跑满负载的时候会不会挂"。
天然的信息不对称。所以每一段 AI 代码，我都得像审查一个刚毕业的新人一样，从头到尾过一遍。
第二，改 prompt 的时间比你想象的碎。
你不可能一句话就让 AI 写出 2000 行生产级代码。你需要不断地迭代 prompt——"这里改成异步" "这里加个缓存" "异常日志的格式不对" "这个函数太长了拆一下"。
每改一次 prompt，就要等几秒到几十秒重新生成。每次生成的结果都可能不一致。有时候换了措辞，输出就变了风格。这种碎片化的等待和调整，比你自己写代码更消耗注意力。
第三，向同事解释的时间比你想象的多。
"这段代码是谁写的？"
"Agent 写的。"
然后你就要解释为什么一个没有工号的 AI 写了一段生产代码。不是解释技术，是解释信任。同事们不是不相信 AI，是不相信一个他们没有审查过工作方式的同事。
最后三个月下来，我最大的收获不是效率提升，而是对"效率"这个词有了新的理解。
真正的效率不是代码写得快，是上线之后不需要返工。如果你把 AI 节省的写代码时间，全部花在了 review、调 prompt 和沟通信任上——那净收益就是零。
当然，这不意味着 Agent 写代码不行。它意味着你需要的不是一个更好的模型，而是一套更好的工作流程——让 AI 写模块化的、边界清晰的部分，你自己保留整体的架构判断和关键路径的审查权。
AI 是很好的执行者，但还不是一个好的判断者。