Uncle Bob 访谈笔记：AI 写代码之后，工程师关注什么

B 站视频 BV1Emgq6wEnw 的标题是《代码整洁之道》作者：我现在完全不读 AI 写的代码。这个说法很醒目，但访谈里更值得关注的是：当实现越来越多地交给 Agent，工程师要怎样判断系统是否可靠、结构是否合理，以及它是否解决了用户的问题。

视频对应 Kent C. Dodds 与 Robert C. Martin（Uncle Bob）的访谈 Architecture, AI agents, and product empathy with Robert C. Martin。本文依据官方文字稿整理，采用意译与归纳；下文时间均对应英文原版，与 B 站配音版可能有偏差。

一、抽象层在上升，架构问题仍然存在

在原版 03:38–06:40，Bob 从自己的编程经历谈起：工具和语言不断变化，但模块划分、依赖控制、信息封装等设计问题一直存在。

他的类比是不断上升的水位。二进制、汇编、语法细节逐渐被工具接手，而更高层的系统设计仍需要有人负责。Agent 让实现变快，却没有自动回答模块应该怎样组织、边界应该放在哪里。

我的理解是，开发者可以把更多精力放到变化的影响范围上。一个功能看起来只改了几行代码，却可能让原本独立的模块相互依赖；另一个改动涉及许多文件，却可能让职责更清楚。代码量本身不足以说明设计的好坏。

二、“不读代码”有具体语境

原版 08:00–12:59 是标题对应的核心讨论。

Bob 描述的工作方式是：执行过程中有意减少直接阅读代码，完成后可能做一些抽查。他仍然检查模块结构，并让 Agent 展示依赖关系和数据流，再据此要求调整实现。

这里有一个不能省略的限定：Kent 问这种方式能否适用于大型、重要系统时，Bob 承认，自己当时主要在做小工具、个人项目，以及一个附近飞行学校的状态看板。他对更大系统的判断，更多建立在模块化原则上。

因此，我会把这段话视为一种值得尝试的工作方式。对于具体项目，仍要根据出错的后果、验证手段和维护需求决定审查深度。Agent 给出的结构说明也应当能对应到实际文件、调用关系和运行结果，方便人继续追查。

三、把质量要求变成 Agent 能执行的反馈

在原版 14:54–19:20，Bob 明确表示自己仍然关心代码质量。他会看函数结构、命名、大小和参数数量，也会要求 Agent 运行检查工具并修正问题。

他举的例子把测试覆盖率与圈复杂度结合起来：缺少测试时补充测试，结构仍然过于复杂时再拆分函数。他也谈到，面向 Agent 时会适当放宽自己原先的一些限制。这些数值属于他的实践选择，不宜直接当作通用标准。

这段讨论给我的启发是，向 Agent 提出要求时，要同时说明如何验证。只说“保持代码整洁”，很难确认任务是否完成；指出具体问题、提供检查方法，才有条件形成持续反馈。

例如，对一个搜索功能，可以先明确：

搜索范围包含哪些字段，界面提示是否与之对应。
空关键词、无结果和大小写差异分别怎样处理。
数据规模增加时，客户端要加载多少内容。
修改搜索逻辑后，用哪些输入验证既有行为。

这些是结合日常开发补充的例子，并非视频中的演示。测试和指标能帮助发现问题，但仍需要人判断检查项是否覆盖了真正的需求。

四、设计判断需要实践，初学者仍要理解代码

原版 20:09–34:49 讨论了 Agent 的设计判断，以及初学者怎样学习。

Bob 的观察是，Agent 在被要求评价设计时能够给出分析，却未必会在实现时主动运用同样的判断。他还提醒要留意上下文变长后偏离任务的情况。这是他在访谈当时的使用观察。

谈到初学者，他一度给出很强的建议：先花几年写代码，再使用 Agent。Kent 随后追问这种做法与就业现实的冲突，Bob 则把基础训练的责任进一步放到学校和学徒培养中。

我更愿意保留这段讨论背后的学习目标：使用工具的人，需要理解工具正在处理的材料。即使已经能让 Agent 做出功能，也应该能解释关键代码，追踪一次失败，理解一次重构为什么改善了结构。

练习可以很小：先自己实现一个功能，再比较 Agent 的实现；给已有功能增加一个需求，观察哪里最难改；出现错误时，先提出自己的原因假设，再借助工具验证。重点是积累判断依据。

五、技术能力要与用户理解结合

原版 35:29–40:36 中，Bob 回忆自己开发电话线路测试软件时，被要求跟随维修人员外出工作。亲眼看到用户怎样使用系统，改变了他对产品的理解。

这也是访谈里对产品工程最具体的解释：工程师既要理解技术，也要接近用户的真实处境。

对我而言，这意味着开始实现前，应先弄清楚用户在哪一步遇到了困难。一个功能能够运行，只能证明它完成了某种行为；用户是否理解入口、是否需要反复操作、是否因此节省了时间，还需要通过实际使用来确认。

如果把 Agent 节省下来的时间用于观察这些问题，开发速度的提升才更有机会转化为产品的改善。

可以带回日常开发的做法

以下是基于访谈整理的实践思路，并非讲者原话：

先描述问题和验收条件。 明确使用场景、边界情况，以及怎样确认功能完成。
让实现与验证一起交付。 除了改动，保留必要的测试结果和结构说明。
按风险选择审查深度。 关注关键路径、异常处理和依赖变化，需要时继续读到具体代码。
从真实使用中修正需求。 自动化检查通过后，再确认用户是否顺利完成了任务。

访谈最后，Bob 邀请听众尝试他的 SwarmForge，体验多个 Agent 之间的协作，并反馈实际使用中的问题。这也与前面的产品讨论相呼应：做出工具之后，还要了解它究竟帮到了谁。

来源与延伸阅读

O’Reilly 链接是相关课程，不是这段访谈的课程录像。课程介绍包含验收测试、单元测试、变异测试及代码质量分析等主题，可以作为进一步学习 Agent 开发纪律的入口；本文没有将课程大纲当作视频中的实际演示。