即便 AI 代码能运行，我为何仍拒绝：审查瓶颈、输出信任及人工审查的必要
2026 年 6 月 19 日
随着代码实现速度加快，真正的瓶颈转移到审查 AI 生成的大量代码上。这里所说的并非同事（及其代理）的拉取请求（PR），而是代码编写代理完成工作后，自己的 `git diff` 结果。
即便遵循了良好实践方法，如从规划模式入手、将大任务拆分成多个阶段，以及小步迭代交付变更，但审查自己实际上并未深入思考过的内容时，仍会感到认知负担过重。
生成更优方案
在有代码编写代理之前，接到任务会先研究代码库，思考不同解决方案，进行实验，再开始实现。整合这些上下文信息可能需花好几天时间。最终提交拉取请求时，信心更足，向同事解释每处变更也更容易。
必须承认，有了 AI 后，完成大任务依旧需要好几天时间。很多时候，会拒绝 AI 做出的所有更改，重新开始。第一次和第二次操作的区别不在于大语言模型（LLM），而在于屏幕后的人。有更多时间梳理要解决的问题，就能引导代理找到更好的解决方案，而非被它牵着走。
图：你能信任代码差异吗？
拒绝 AI 代码的原因越来越趋同：
- 无法用自己的语言解释代码实现思路时，会拒绝。
- 代码差异比问题本身还大时，会拒绝。
- 代码在未证明抽象的必要性之前就引入抽象时，会拒绝。
- 代码在本地能运行，但让系统更难以理解时，会拒绝。
- 对输出结果的信任超过自己的理解时，会拒绝。
工程师过快接受 AI 生成的变更并不少见，所以主张在 AI 审查的同时，必须有人工审查。现实是，能运行且能让持续集成（CI）通过的代码，仍可能是糟糕的解决方案，而工程领域一直追求实现合适、可扩展且可延伸的解决方案。
使用代码编写代理已有一段时间，尽管它们令人印象深刻，但仍需要优秀的工程师引导它们找到出色的解决方案。没错，代码编写代理完成任务时，能提供的帮助不止于编写代码，但这并不意味着它们目前就能以可持续的方式自主完成工作。