首页科技快讯完全相信AI代码的Uncle Bob，坦诚这条路还没走通

完全相信AI代码的Uncle Bob，坦诚这条路还没走通

来源：晰数塔互联网快讯时间：2026年08月23日 17:02

整理｜褚杏娟

在 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 时代架构反馈周期缩短但新人缺少历史踩坑经验的短板。

下面是两人的详细对话，我们进行了翻译和整理，并在不改变原意基础上进行了删减，以飨读者。

太长不看版

Q：如今人工智能和 AI 智能体已经普及，你的工作和编程体验发生了哪些变化？

A：现在，我的核心工作模式是全权交给 AI 智能体执行开发任务、运行各类检测工具，我的终极目标是彻底不用手动查看代码，完全信任 AI 的输出结果。

Q：为什么要耗费大量精力优化代码、搭建管控体系，而不是快速迭代？

A：即便 AI 智能体速度快、智能化程度高，但也和人类一样无法应对极度混乱的代码。只是它们的容错阈值和人类略有不同，但依然存在上限。

Q：有没有一些传统编程理念，在 AI 时代已经不再适用，需要被淘汰？

A：最核心的调整是复杂度阈值。AI 智能体的短期记忆能力远超人类，容量更大、精度更高，能处理更复杂的代码逻辑。第二个需要调整的是人工开发规范的落地方式。我一直是测试驱动开发的忠实拥护者，但这是适配人类开发者的工作准则，完全不适合强行约束 AI 智能体。

Q：在交给需求解析智能体之前，你会做多少人工前置规划？

A：我彻底放弃了重度前置规划，转而拥抱敏捷开发思路。不再一次性规划全部需求，而是让 AI 先完成单个、小型需求迭代，结束后人工复盘架构、优化结构，再推进下一轮迭代，逐步完善整体系统。这套模式无法彻底规避人工收尾、架构调整的工作，我目前也在尝试自动化优化，但暂时没有突破。

Q：很多人会让多个 AI 反复打磨需求文档，拿到完美方案后再落地开发，你如何看待这种模式？

A：如今编程的修改成本已经无限趋近于零，我们完全没有必要耗费大量精力做重度前置规划，快速迭代、持续优化才是最优解。

Q：新人该如何培养这种敏锐度？

A：新人没有这种实战积累，想要培养这种能力，最直接的方式就是研读经典老书。这些书籍虽然部分内容老旧，但核心的架构思维、工程理念、战略逻辑永不过时。新人研读这些内容，就能快速建立顶层认知，再结合 AI 实战体感，慢慢就能培养出战略思维。

Q：AI 可以替代一切，无需学习底层原理，你怎么看？

A：底层基础的价值从未改变。鼓吹基础无用的人，终究会付出代价。

“浴袍”出镜的 Uncle Bob

主持人：从我成为开发者至今，甚至在我入行之前，他就深耕软件领域多年，如今更是在智能体 Agent 领域闯出了自己的一片天地。今天我们有幸连线身着浴袍的 Uncle Bob Martin，欢迎他来到现场。

主持人：真的非常荣幸能请到你。可能很多观众好奇你穿浴袍出镜的缘由，我们正好借此聊聊这个有趣的小细节。这件浴袍为什么成了你的标志性特点呢？

Uncle Bob：这件事大概发生在两年前。某天清晨，我穿着浴袍站在自家门廊上，突然有感而发，忍不住吐槽 SQL 的种种弊端。出于安全层面的考量，将文本语言作为数据库访问语言本身就很不合理，还会引发大量 SQL 注入漏洞之类的问题。

当时我就在浴室里，随手拿起手机即兴吐槽了一番，这段晨间浴袍吐槽视频就这样诞生了。没想到这段视频反响特别好，之后我就陆续多更新了几期晨间浴袍吐槽内容。

主持人：所以你今天也是带着这种随性的晨间状态来做客的吗？是不是还没喝咖啡，保持着清晨不想被打扰的状态？清晨六点就开始琢磨 SQL 问题，也太拼了。

Uncle Bob：其实现在已经上午十点了。（笑）我已经喝完第一杯健怡可乐，状态完全在线，没问题的。

主持人：那就好。看你现在换上了 polo 衫，状态满满。我的观众里大部分是开发者，但也有不少非技术观众，能不能给大家好好介绍一下 Uncle Bob 这个行业传奇人物，让非开发者也能了解你？

Uncle Bob：传奇谈不上，我只是一名普通的程序员，而且已经入行很久了，至今从业时长已经超过五十年。我第一次接触编程是在 1964 年，那年我十二岁。当时我生日，妈妈给我买了一台小型模型计算机，我通过在插钉上摆放白色小管的方式编写程序。那本质上是一个三位有限状态机，但当时这个小东西彻底勾起了我的好奇心，让我深深迷上了编程。

主持人：十二岁就接触编程，那五十多年后的今天，你是一步步走到如今的行业地位的？

Uncle Bob：从接触编程开始，我就疯狂汲取各类编程知识。父亲给我买了 Fortran、Cobol、PL1 相关的编程书籍，我全部通读了一遍。那时候没有电脑设备可以运行代码，我就把程序写在纸上，在脑海里模拟运行。十六岁的时候，我找到了第一份编写代码的临时工作，十八岁正式入职成为全职程序员，从那以后就一直深耕这个行业。

主持人：你深耕编程一线数十年，还写出了极具影响力的著作。你出版过好几本书，但其中有一本绝对是里程碑式的作品。我没记错的话，就是讲解代码整洁之道的《Clean Code》（代码整洁之道）。在软件工程领域，这本书绝对是被引用最多、影响力最广、认可度最高的经典著作之一。

终极目标：完全信任 AI 的输出结果

主持人：你在人工智能出现之前的时代，就已经深刻影响了整个编程行业，几乎见证了人工智能时代到来前软件工程的全部发展历程。如今人工智能和 AI 智能体已经普及，你的工作和编程体验发生了哪些变化？

Uncle Bob：去年圣诞前后，我第一次真切感受到了这种变革，当时颇感意外。在此之前，我也尝试过 ChatGPT、Grok 等各类 AI 工具，但一直没觉得有多惊艳。

直到后来我慢慢发现，这些 AI 工具的能力远比我想象的更强。我最先试用的是早期版本的 Grok 智能体，我让它帮我写代码，虽然完成质量不算高，但确实能生成可用代码。当时我正在做一个项目，索性就让这个智能体全程辅助我开发。

那段时间我一直要不停地修正它写出的代码，它总会写出各种不规范、冗余的劣质代码。我发现 AI 编码的优势是速度极快，但缺点也很明显，会拖慢我的整体开发节奏，让人十分头疼。

但我很快意识到，凭借极致的速度，AI 智能体能完成很多人类做不到的事。早在 21 世纪初，有两项技术理念让我印象深刻，但在当时完全不具备落地可行性。

其中一项是 CRAP 代码评估机制，它的核心逻辑是结合代码覆盖率、测试覆盖率与每个函数的圈复杂度，通过一套复杂公式计算出评分，以此判定函数代码的劣质程度。

21 世纪初我就觉得这个理念非常好，当时我在一个大型项目中尝试套用这套机制，确实检测出了大量劣质函数。但问题是，我需要耗费海量时间逐一修改代码、重写测试用例，而项目本身能够正常运行，投入这么多精力优化得不偿失，最后我只能暂时搁置了这套方案。

另一项让我格外关注的技术是变异测试。这项技术的原理很有意思：通过程序遍历源代码，对代码中的正负号、大小于符号、等于符号等逻辑符号进行反转修改，随后运行全套测试用例。

正常情况下，代码逻辑被修改后，测试用例必然会报错；如果测试用例依旧通过，就说明存在“存活变异体”，代表这段代码存在测试漏洞，必须修复。

2000 年左右，我在同一个项目中尝试了变异测试。当时单次完整测试需要四分钟，我需要重复运行数百次，只能通宵挂机测试。最后确实检测出了不少漏洞并完成了修复，但这套流程效率极低，根本无法融入常规的构建流程，完全不具备实用性。

去年年底到今年年初，我突然顿悟：AI 智能体运算速度快、不畏惧枯燥重复的工作，还能精准执行指令。我完全可以让 AI 自动运行 CRAP 代码检测工具，自动清理劣质代码；再让它运行变异测试。原本需要通宵完成的工作，现在三十分钟左右就能搞定，还能自动修补所有代码漏洞、完善测试覆盖。

AI 生成的代码往往存在大量冗余、不规范的问题，而这套组合工具刚好可以完美清理这些代码瑕疵。之后我持续迭代，为 AI 智能体搭配了更多自动化工具，不断优化协作流程，如今它们的工作质量已经非常出色。

现在，我的核心工作模式是全权交给 AI 智能体执行开发任务、运行各类检测工具，我的终极目标是彻底不用手动查看代码，完全信任 AI 的输出结果。

目前我只会通过核查 CRAP 评分、不定期抽查代码、运行全套定制测试等方式，验证代码质量是否达标。AI 编码速度远超人类，而我擅长把控整体质量、核查校验，所以我选择让 AI 全权负责代码编写，我专注做好后续的质量管控，目前这套模式运行得非常顺利。

AI 同样受代码腐烂折磨

主持人：也就是说，你的目标是逐步脱离代码编写和人工审核工作，搭建一套完善的代码管控体系，最大限度约束 AI 智能体的行为，规避它的出错风险。

这里我想抛出一个核心疑问：所有人都知道 AI 会写出劣质、混乱的代码，但 AI 开发速度极快，我们为什么要耗费大量精力优化代码、搭建管控体系，而不是快速迭代、等待漏洞自行修复呢？规整代码质量的意义到底是什么？

Uncle Bob：我在去年年底就发现了这个关键问题。我当时让 Grok 智能体持续迭代开发，发现如果不及时清理它产出的劣质代码，一味堆叠新功能，代码冗余和漏洞会持续累积。

随之而来的就是 AI 迭代效率持续下降，还会陷入恶性循环：修改一处代码，无意间破坏了另一处功能，反复修补、反复出错，最后原地打转、越改越乱。我甚至遇到过智能体直接停止工作、无法继续迭代的情况，虽然它没有直白说出这句话，但状态已经完全停滞。

这就说明，即便 AI 智能体速度快、智能化程度高，但也和人类一样无法应对极度混乱的代码。只是它们的容错阈值和人类略有不同，但依然存在上限。一旦代码混乱程度突破阈值，AI 就会迭代卡顿、漏洞激增、问题持续恶化，最终彻底无法推进工作。

主持人：所以你的解决方案是通过工具清理劣质代码。但大多数人的做法和你截然不同，大家遇到 AI 代码出错后，会不断给智能体补充提示词、新增规则指令，通过持续引导的方式修正问题，也就是“人工干预调控”。你为什么放弃这种方式，转而选择自动化检测工具呢？

Uncle Bob：我最开始也尝试过这种方式，在提示词里详细写明测试驱动开发规范、代码整洁准则、代码编写标准，最后整理出了长达数页的代码规范文档，甚至几乎把《Clean Code》的核心内容都录入了提示词。

但我很快发现，AI 模型对待这些明文规则，就像《加勒比海盗》里的准则一样，只是“参考建议”，可遵守可不遵守，不会严格落地。

背后存在一个核心技术现象，叫做“中间信息丢失（lost in the middle）”。

模型的上下文窗口存在注意力机制偏差，开头和结尾的信息权重更高、优先级更强，而中间的内容会被弱化、忽略。如果你的规范提示词过长，大部分规则都会落入上下文窗口的中间区域，直接被模型无视。可能开头几句核心规则还能生效，但几十条之后的规范，模型完全不会读取执行。随着迭代推进，上下文信息不断累积，模型根本无法筛选全部有效规则。

但自动化检测工具不会出现这种问题，规则固定、执行确定性强，不会被上下文窗口的机制影响。使用 AI 智能体的核心技巧，就是精简初始提示词，只保留最核心的规则，让所有关键信息都处于高优先级区域，剩余的规范约束，全部依靠后置自动化工具落地。

主持人：完全赞同。行业里有个很贴切的定义，把上下文窗口分为“智能区”和“迟钝区”，是 Dex Hardy 提出的概念。上下文窗口的前段 token，模型注意力集中、判断力强，属于智能区；随着内容增多、token 累积，注意力机制会被稀释，就像嘈杂的人群里每个人都在发声，根本分辨不出有效信息，模型也就变得迟钝了。

所以你彻底摒弃了人工引导调控的模式，回归传统的自动化检测机制。这类检测工具不会占用上下文窗口的动态注意力，可以无限叠加。那是否存在“检测规则过多、过度约束”的情况？自动化检测是不是越多越好？

Uncle Bob：这也是我目前一直在研究的问题。显然自动化检测规则存在上限，一旦约束过多就会拖慢 AI 迭代速度，甚至比人工开发效率更低，那就得不偿失了。只要 AI 的生产效率依然高于人类，这套约束体系就是有效的。

就我目前的实测结果来看，即便叠加了大量检测规则、约束条件，AI 的开发效率依然是人类的 2-4 倍，优势十分明显。

我们添加的确定性工具，本质上是给 AI 搭建了一套迭代闭环：强制 AI 反复优化代码，直到通过全部检测，包括降低圈复杂度、补充测试用例、修复全部漏洞、规范代码格式等。这套流程会牺牲一部分迭代速度，换取极致的代码质量，我目前还没有摸索到这套平衡机制的上限。

现在，我正在搭建多智能体协作体系，让不同智能体分工协作、接力完成工作：一个负责开发实现，一个负责代码审核，一个负责专项测试，一个负责代码加固。虽然多智能体沟通会产生一定开销，但整体效率依然远超人工开发。

多智能体开发质量高于人工

主持人：我对多智能体系统非常感兴趣，这也是我一直存疑的方向。现在很多人鼓吹搭建多智能体团队，给每个智能体分配独立岗位、独立账号，实现全流程自主协作，但我一直不太认可这种模式。

但我个人更倾向极简分工：只区分开发实现和代码审核两个角色。开发智能体只需要完成基础功能开发、编写基础测试用例，不用追求代码优雅；审核智能体无需梳理业务逻辑，只需要针对开发产出的代码差异做精细化校验，同时可以叠加大量约束规则，因为审核场景的任务边界更清晰。

我想听听你的看法，你如何定义开发、审核、加固等不同智能体的分工价值？

Uncle Bob：多智能体精细化分工有两大核心优势。第一是支持并行工作，我的普通笔记本电脑可以同时运行三个以上的编码智能体，同步推进多项开发任务，大幅提升效率。

第二是精准控制上下文窗口，完美缓解“中间信息丢失”问题。给单个智能体分配单一专项任务，只需少量核心规则就能约束它的行为，规则落地率极高。同时，我会采用“即用即毁”的模式，智能体完成单次任务后直接销毁，下一轮任务启用全新智能体，保证上下文环境干净无冗余。

当然这套模式也存在弊端，智能体启动需要 10-15 秒的初始化时间，还要重新读取、梳理任务上下文，会产生一定耗时损耗。我目前的完整协作流程非常清晰：

首先由需求解析智能体，将人工撰写的需求文档，转化为 Gherkin 结构化验收测试用例和系统化 QA 测试流程。Gherkin 用例是高阶验收标准，QA 流程则是完整的系统测试方案，模拟用户操作界面、验证系统完整功能。

随后，编码智能体承接需求，根据结构化用例开发业务代码、编写单元测试，确保完全匹配需求、通过基础验收测试；代码开发完成后，交由代码清理智能体，运行 CRAP 代码检测、完成常规代码评审，清理编码智能体产出的冗余、劣质代码。

之后由代码加固智能体执行严苛的变异测试，实现 100% 代码覆盖率，逐一校验代码逻辑漏洞，修正所有潜在风险，这一步是保障代码稳定性的关键；最后由 QA 测试智能体，将标准化 QA 流程转化为可执行脚本，全自动操作系统、输出确定性测试结果。

整套流程走完，产出的代码质量会非常稳定、可靠。原本单个智能体需要五分钟完成、质量参差不齐的工作，这套多智能体闭环体系大概需要一小时完成，但对比人类半天的开发时长，效率依然提升了 4-5 倍，且代码质量远高于人工开发水平。

主持人：我发现了你这套模式的核心精髓。你不仅在管控上下文窗口的信息丢失问题，还在把控上下文的迭代轨迹。AI 会话的上下文存在固定轨迹，一旦在单次会话中定下某个基调、开启某项任务，后续所有迭代都会延续这个方向。

比如你让智能体做界面测试，它后续的所有修改都会默认附带界面测试逻辑。只有清空上下文，才能打破这种固有轨迹。所以开发智能体的迭代轨迹是“优先实现功能”，而加固智能体的轨迹是“极致完善测试覆盖”，分层分工刚好规避了轨迹混乱的问题，这个逻辑和你的实践完全契合吧？

Uncle Bob：完全契合。这是大模型普遍存在的特性，即便非编程场景也会出现。比如你和 AI 讨论咖啡冲泡技巧，中途上下文混入了电视剧相关内容，后续所有咖啡相关的回答，都会被电视剧信息干扰，模型无法区分有效信息、过滤冗余内容。

你提出的“迭代轨迹”非常精准。只要保持模型上下文方向统一、信息一致，就能有效规避幻觉、逻辑错位等问题。而多智能体分层校验、层层把关的模式，刚好能彻底规避这些风险。

AI 架构规划流程全自动化，还不行

主持人：我们聊了很多落地实现的细节，接下来想聊聊前置规划。自动化测试、代码检测固然能保障代码质量，但如果 API 设计不合理、模块结构规划混乱，后续的所有质检工作都会事倍功半。你在前期架构设计、模块规划上有哪些思考？

Uncle Bob：就在一个月前，我还在人工负责架构设计工作。我会让 AI 完成基础开发后，主动向它问询系统结构、模块关联、依赖关系等核心问题。很多时候 AI 给出的架构答案漏洞百出、问题重重，我会基于经验重新规划模块拆分逻辑、定义模块间的通信规则，输出明确的落地方案，再交由 AI 执行开发。

为了提升架构管控效率，我让 AI 开发了架构可视化工具，可以实时生成 UML 结构图，清晰展示系统模块化结构、依赖链路。我可以点击任意模块查看子模块细节、逐层研究，最终直接查看对应源码，实现全层级架构可视化管控。

同时，我搭建了一套确定性检测工具，明确定义模块间的依赖规则：哪些模块可以相互依赖、哪些禁止依赖、依赖链路的流转规范，全部写入固定配置文件，AI 绝对不能违规。最后会有专属检测程序校验架构合规性，一旦 AI 打破依赖规则，就必须通过反转依赖、新增接口、拆分模块等方式整改修复，强制保证架构规范。

目前我正在尝试将这套架构规划流程全自动化，但暂时还没有取得理想效果。

主持人：我和你有一模一样的体会。合理的模块架构能带来巨大的收益，你能具体说说优质模块化结构的核心价值吗？

Uncle Bob：核心逻辑和整洁代码的价值完全一致。边界清晰、接口规范、分工明确的模块，无论是人类开发者还是 AI 智能体，都能轻松理解、精准把控。

人类擅长模块化拆分思考，AI 模型也是同理，只是容错阈值略有差异。只要单个模块职责单一、迭代轨迹清晰，模型就不会被杂乱的业务逻辑干扰，高效完成开发工作。

反之，如果一个模块堆砌各类无关功能、逻辑混乱，AI 根本无法明确工作重心，迭代效率和质量都会大幅下滑，和人类开发遇到的困境一模一样。

主持人：没错，优质架构能最大化发挥测试体系的价值。我一直非常认同 John Ousterhout 的深度模块理论：劣质的浅层模块接口繁杂、内部逻辑单薄，优质的深度模块接口极简、内部封装大量核心逻辑。这套理论似乎完美适配 AI 开发模式，AI 只需读懂极简接口，无需深究底层实现逻辑，就能完成高效开发，这也是你的核心思路吗？

Uncle Bob：完全正确。大模型会重点关注代码结构和接口定义，依托规范的模块接口，它可以无需解析底层源码，直接完成开发迭代。这既是优势也是风险点，只要底层代码逻辑统一规范，就能规避风险、放大优势。

同时 AI 会通过读取测试用例理解系统功能，所以代码结构、模块设计越规范，AI 对业务的理解就越精准，开发质量自然越高。对了，这本书的附录里，我和 John Ousterhout 专门针对这个话题展开了详细辩论，过程非常有趣。

AI 开发普及，需要对《Clean Code》做什么调整

主持人：结合当下 AI 开发的时代背景，你会对《Clean Code》的内容做哪些更新和调整？

我们之前聊到，传统的代码规范、质检体系在 AI 时代依然适用，只是落地方式变了。但有没有一些传统编程理念，在 AI 时代已经不再适用，需要被淘汰？

Uncle Bob：最核心的调整是复杂度阈值。AI 智能体的短期记忆能力远超人类，容量更大、精度更高，能处理更复杂的代码逻辑。

以往我对人类开发者的要求是，CRAP 评分控制在 4 以下；现在针对 AI 开发，我把阈值调整到了 6，后续可能会放宽到 8。这个阈值对应的核心指标是圈复杂度，代表函数的逻辑分支数量。CRAP 评分为 6，意味着函数存在 6 条独立逻辑分支，且全部被测试用例覆盖，这在 AI 开发场景下是完全可控的。我也多次和 AI 验证过这个标准，适配性非常好。

第二个需要调整的是人工开发规范的落地方式。我一直是测试驱动开发的忠实拥护者，但这是适配人类开发者的工作准则，完全不适合强行约束 AI 智能体。

人类适合“写一行测试、写一行业务代码”的迭代节奏，但 AI 不适用这种模式。即便我在提示词中强制要求严格执行测试驱动开发，AI 最终还是会回归“完成函数开发、再补充对应测试用例”的模式，和 John Ousterhout 提倡的节奏一致。

所以，我的核心结论是：人类的编程价值理念依然通用，但人类的开发行为规范、操作阈值，需要针对 AI 全面调整，不能直接照搬套用。

“没有必要耗费大量精力做前置规划”

主持人：这个总结太精辟了。测试驱动开发的本质，是弥补人类短期记忆不足的短板，而 AI 不存在这个问题，所以无需照搬这套流程。

我们聊完了代码实现和规范，再来聊聊前置规划。在交给需求解析智能体之前，你会做多少人工前置规划？如果前期需求规划出错，后续整套智能体迭代闭环都会做无用功，你是如何规避这个问题的？

Uncle Bob：很多人会陷入“极致前置规划”的误区，让人工把需求打磨到完美，再交给 AI 执行，这是几十年前瀑布式开发的老路。

我本周刚好在测试这种模式，结果和以往一样，彻底失败。无论前期规划多么细致，人类都无法穷尽所有场景，AI 也不具备人类的全局思考能力。执行过程中，AI 总会出现规划外的偏差，我们只能反复暂停、重构规划、重新迭代，效率极低。

所以，我彻底放弃了重度前置规划，转而拥抱敏捷开发思路。不再一次性规划全部需求，而是让 AI 先完成单个、小型需求迭代，结束后人工复盘架构、优化结构，再推进下一轮迭代，逐步完善整体系统。

这套模式无法彻底规避人工收尾、架构调整的工作，我目前也在尝试自动化优化，但暂时没有突破。

主持人：我完全认同。当下的开发模式中，代码编写的工作量已经被 AI 极致压缩，但前置需求规划、后置质量复盘的工作量，几乎和以前持平。现在业内流行“需求驱动开发”，很多人会让多个 AI 反复打磨需求文档，拿到完美方案后再落地开发，你如何看待这种模式？

Uncle Bob：AI 非常擅长撰写需求规划文档，还会主动丰富细节、美化方案，看起来无可挑剔，但落地执行时一定会漏洞百出。

我的多次实验证明，纯粹的需求驱动开发模式并不适配 AI 时代，最优解依然是敏捷迭代：小步快跑、快速反馈、迭代优化、实时重构。我之前经常用建房举例，如果修改房屋设计的成本极低，你根本不会提前花高价请设计师做完美图纸，再一次性施工。你会先打地基、再调整格局、逐步优化，边搭建、边修改、边完善。

如今编程的修改成本已经无限趋近于零，我们完全没有必要耗费大量精力做重度前置规划，快速迭代、持续优化才是最优解。

主持人：我非常反感现在泛滥的需求驱动开发标签。很多人把所有前置对齐、需求梳理工作都定义为需求驱动开发，甚至把提示词工程也归为此类，概念太过泛化。你是否会在代码仓库中留存、固化所有需求文档，还是说需求本身是临时、可迭代的？

Uncle Bob：我不会留存固定的需求文档，所有需求都是临时可变的，会根据迭代情况实时调整。

传统开发中，人类编写的源码就是最终的需求落地形态，是唯一的刚性标准。但现在源码由 AI 编写，不再是人类的直接产出，很多人会因此缺失安全感，执着于留存固定的前置需求文档。

但在我看来，最终落地的可运行系统、可通过的检测标准，才是真正的需求。我也不建议大家直接下载使用我开发的 CRAP 检测、变异测试等工具，大家应该让 AI 读取我的工具逻辑，自主复刻、定制适配专属工具，这才是真正掌握核心需求的方式。

新人要把把自己当成“人类智能体”

主持人：这也是 AI 时代很奇妙的一点：AI 会认真读取人类给出的所有参考资料，但人类几乎不会细看 AI 产出的海量代码，信息交互完全单向，非常有意思。

最后我想请教一个核心问题。John Ousterhout 把编程分为战术编程和战略编程，战术是一线落地执行，战略是全局架构规划、方向把控。AI 极其擅长战术编码，但完全不具备战略思维。如今所有基础战术编码工作都被 AI 替代，新手开发者该如何学习战略编程、培养顶层思维？你对新人成长有什么建议？

Uncle Bob：这是当下行业最核心的问题，我也没有完美答案，但我可以分享我的思考。

首先，新手必须亲自手写代码，积累足够的实战经验。不用过长，但一定要亲身经历编码、调试、改错的全过程，才能理解 AI 面对的底层问题，看懂代码背后的逻辑，否则永远无法建立顶层思维。

其次，入行后的新人，应该把自己当成“人类智能体”。在重度使用 AI 的团队中，资深工程师负责战略规划、架构设计，新人承接 AI 级别的基础任务，接受和 AI 一样的自动化检测约束。这个阶段的工作效率会很低，但能快速积累海量实战经验。熬过这个阶段，才有资格把控 AI 工作、做顶层战略设计。

另外，新手必须补齐底层基础。十年前我就建议开发者，即便日常使用高级语言开发，也要抽空学习汇编语言，搞懂底层运行逻辑，跳出上层语法的“虚拟幻境”。这套逻辑现在依然适用。新手必须从二进制、汇编、C 语言等底层知识学起，再到高级语言、AI 工具协作，逐层搭建认知，最终才能具备管控 AI、做战略编程的能力。

主持人：但有一个现实问题，战略编程的反馈周期极长，传统开发模式下，架构设计的失误可能半年后才会暴露，很多新人根本等不到反馈就已经离职转行，永远学不会顶层设计。但 AI 时代加速了整个流程，战略失误会快速暴露。你当初是如何快速发现 AI 的代码存在严重问题的？新人该如何培养这种敏锐度？

Uncle Bob：初期我只是直观看到代码混乱，但真正让我意识到问题严重性的，是 AI 的迭代卡顿、逻辑死循环。我亲身经历过传统开发中代码混乱带来的所有问题，所以能一眼识别 AI 的困境。

新人没有这种实战积累，想要培养这种能力，最直接的方式就是研读经典老书。Tom DeMarco、Ed Yourdon 等人的著作，还有《程序员修炼之道》这类经典书籍，沉淀了几十年的行业经验。这些书籍虽然部分内容老旧，但核心的架构思维、工程理念、战略逻辑永不过时。新人研读这些内容，就能快速建立顶层认知，再结合 AI 实战体感，慢慢就能培养出战略思维。

主持人：所以归根结底，软件工程的底层基础依然至关重要。现在很多人鼓吹“基础无用论”，认为 AI 可以替代一切，无需学习底层原理，你怎么看？

Uncle Bob：底层基础的价值从未改变。Dijkstra 曾说过，软件是人类创造过最复杂的事物，远超其他所有工程体系。软件工程的底层基础，本质是用来拆解、组织、梳理复杂系统的方法论，这套逻辑不仅适配人类，也适配仿生人类的 AI 模型。

鼓吹基础无用的人，终究会付出代价。AI 虽然强大，但依然会撞上复杂度的天花板，而掌握底层基础、架构思维的开发者，才能突破瓶颈、把控全局。只是 AI 延缓了问题暴露的时间，并非彻底消除了问题。

主持人：这是行业迭代的必然规律。从二进制到汇编、再到编译器、如今的大模型，每一次抽象层级升级，都会有人高呼“底层基础无用”，但最终都会被验证是错的。所有被抛弃的底层规则，终有一天会被重新拾起，因为核心逻辑从未改变。

Uncle Bob：没错，亘古不变。

发布于：北京