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