AI热榜 在 AI 代码极度普遍的当下，一直告诫开发者要严肃对待自己编写的代码的 Uncle Bob，如今已经彻底放弃对 AI 代码逐行人工评审，转而在搭建一套依靠指标与约束条件的管控框架，这一做法在工程师群体当中引发激烈争论。
不是所有的软件工程领域的权威领袖都认同这一思路。
统一建模语言（UML）联合作者、软件工程领域的奠基人物之一 Grady Booch 直接公开提出过反对意见。
“信任，但要核验。
作为经验丰富的开发者，我可以凭直觉分辨代码好坏。
但没有任何智能体，能够拥有同等的实战积累与业务上下文，做到这件事。
”Booch 说道。
Booch 会完整审核智能体生成的全部代码。
在他看来，测试覆盖率和复杂度指标可以让我们对功能正确性抱有信心，却无法发现智能体是否引入安全漏洞、生成无效死代码悄悄侵蚀后续的可维护性，或是漏掉对性能至关重要的逻辑拆分。
那么，自动化指标，到底能不能替代资深工程师在长年职业生涯中练就的问题识别能力？
Uncle Bob 为智能体设置了强约束体系：单元测试、Gherkin 验收测试、QA 测试流程、圈复杂度阈值、模块大小限制、依赖结构分析、变异测试（mutation testing）以及测试覆盖率要求。
他的核心逻辑是：只要 AI 生成的代码能够全部通过这一道道关卡，即便没人读过一行函数内部实现，我们也有充分理由相信代码的正确性。
这套方案绝非纸上谈兵。
单是变异测试这项技术，就会系统性改动源代码，以此检验测试用例是否真的能够捕获缺陷，其严谨程度已经超过绝大多数普通工程团队的人工评审流程。
但这种模式需要前期投入巨大成本：想要把测试套件当作唯一质量关卡，需要极强的工程纪律，而绝大多数团队并不具备，也很难快速建立这套能力。
最近在 Matt Pocock 的播客节目中，Uncle Bob 透露了自己的这套方案进度。
AI 全权负责代码编写，他自己专注做好后续质量管控，这套模式运行得非常顺利。
但在将自己的一整套架构规划流程全自动化时，暂时没有取得理想效果。
他承认，现阶段 AI 做架构设计经常产出漏洞方案，架构、模块依赖管控仍然需要人类主导。
播客中，Uncle Bob 介绍了自己当前的强约束约束方案和他现在的研发流程，他建议，放弃瀑布式重度前置规划，采用敏捷小迭代，即做完一小轮迭代后，人工复盘重构架构，再进入下一轮。
开发者不必维护固定静态需求文档，可运行系统、自动化检测标准才是权威需求。
他也不建议开发者不要直接下载使用自己的成品，而是理解工具逻辑后让 AI 复刻适配自己的检测工具。
他还强调了学习底层知识的重要性，认为新人必须亲手写代码，完整经历编码、调试、排错，不能全程只做 AI 提示词工程师。
新人可以把自己当作 “人类智能体”，接受自动化检测约束，积累实战，再进阶做战略架构。
通过阅读经典软件工程书籍，获取架构与战略思维，弥补 AI 时代架构反馈周期缩短但新人缺少历史踩坑经验的短板。
🔗 原始来源
如果你要核对细节，可以再看原文： InfoQ AI原文链接