Uncle Bob的AI编程实验：不再逐行审代码，但架构仍离不开人

导语

AI智能体正在改变“谁来写代码”，但还没有解决“谁来负责系统设计”。在近期播客对话中，软件工程领域的资深实践者 Uncle Bob Martin 分享了自己的实验：让AI负责实现功能和运行工具，人类则尽量退出逐行代码审查，转而维护一套自动化质量约束。这个方向引发了与 Grady Booch 等人的分歧，也暴露出AI编程从“能生成”走向“可长期维护”时的关键难题。

从人工审查转向质量门禁

Uncle Bob的核心判断是，长篇提示词并不能稳定约束模型。规则放在上下文中间时，可能被模型弱化或忽略；相比之下，自动化工具能够以更确定的方式执行标准。因此，他为智能体设置了多层检查，包括：

• 单元测试、Gherkin验收测试和QA流程，验证功能是否符合需求；
• 圈复杂度、模块规模和依赖关系分析，控制结构性风险；
• 代码覆盖率与变异测试，检验测试是否真的能发现逻辑缺陷；
• 代码清理与加固环节，让生成结果在进入下一轮迭代前先接受修整。

变异测试的价值在于，它会主动改变代码中的逻辑符号，再观察测试是否失败。如果被修改的程序仍能通过测试，就说明测试套件存在盲点。不过，这些指标主要回答“现有需求和测试是否被满足”，并不能自动证明需求本身完整，也不能充分识别安全、性能或长期演化方面的问题。

多智能体提高效率，但不是万能分工

在他的设想中，需求解析、编码、代码清理、测试加固和QA可以由不同智能体接力完成。每个智能体只处理边界清晰的任务，并在任务结束后清空上下文，以减少信息混杂和错误轨迹延续。这样做的优点是规则更容易落地，也便于并行推进；代价则是启动、交接和重新理解上下文都会产生额外成本。

这套方法的前提，是团队已经拥有足够成熟的测试体系和工程纪律。对于缺乏测试、依赖关系混乱的项目，单纯增加智能体数量只会更快地产生更多代码，并不会自动形成质量保障。自动化门禁也存在平衡问题：约束过少，缺陷会累积；约束过多，则可能拖慢迭代。

架构仍是当前短板

Uncle Bob坦言，AI在架构规划、模块边界和依赖设计上仍经常给出漏洞百出的方案。因此，他并没有采用一次性完成全部设计的重度前置规划，而是倾向于小步迭代：先实现一个小需求，再由人类复盘结构、进行重构，随后进入下一轮。

这也构成了这场讨论的真正焦点。Booch主张完整审查智能体生成的代码，认为覆盖率和复杂度无法替代经验、业务语境以及对安全和性能的判断。两种观点并非简单的“信任”与“不信任”之争，而是对责任边界的不同安排：前者试图把质量判断转化为可执行的工程约束，后者提醒人们仍有大量风险无法被现有指标覆盖。

对开发者的启示

AI时代，代码阅读可能不再是唯一的质量手段，但测试设计、架构判断、故障定位和风险意识的重要性反而上升。新人不能只学习提示词，还需要亲手编码、调试和排错，理解经典软件工程思想，才能判断自动化结果是否可信。

Uncle Bob的实验尚未证明“完全不看代码”已经可行，却提供了一个有价值的工程命题：让AI负责高频实现，让机器负责确定性检查，人类把时间集中到需求、架构和不可量化的风险上。真正成熟的AI开发流程，或许不是取消审查，而是重新定义审查应当发生在哪里、由谁完成，以及哪些问题仍必须由人承担。

InfoQ 中文