Signal #22：代码生成越便宜，理解系统越稀缺

Info 当 Agent 可以在 Loop 中持续推进任务，系统变化的速度可能逐渐超过团队形成共同理解的速度。 本周 Signal 关注的是，在自动化持续扩大的过程中，团队如何保留对设计意图、关键边界和长期演化成本的理解与判断。 本文是「每周 Signal｜AI × SE」第 22 期，关于关注和交流～

代码正在变得越来越容易生成和修改。一个任务可以在 Loop 中持续推进：测试失败后，Agent 会读取结果、继续修改并再次验证；多个 Agent 还可以围绕不同模块或子任务并行执行，各自完成修改、运行检查并提交结果。系统变化的速度，由此不再完全受限于单个开发者的时间。

但代码产出速度提高，并不意味着团队形成系统理解的速度也会同步提高。

当修改越来越多、执行越来越快，团队阅读代码、讨论设计和更新共同认知的速度未必能够跟上。系统仍然可以运行，测试也可能全部通过，但团队逐渐难以回答一些基本问题：

为什么这里要这样设计？哪些边界不能改变？这层抽象解决的原始问题是什么？一次局部修改，会不会正在增加系统的长期成本？

这里所说的“理解系统”，并不意味着每个工程师都必须读懂每一行代码。现代软件系统原本就很难完整装进某个人的大脑。更现实的标准是：关键边界有人负责，重要决策能够追溯，历史约束没有随着人员和代码变化而消失，高影响变更仍然能够被解释和判断。

当 Agent 开始持续参与代码生成、评审和修复，这种系统理解能力就需要被重新建设。

一、Loop 让任务继续，也可能放大局部修补

Flask、Jinja2 作者 Armin Ronacher 在文章 《The Coming Loop》[1] 中讨论了两层嵌套的 Loop。

一层发生在 Coding Agent 内部。Agent 读取文件、调用工具、修改代码并运行测试，再根据执行结果进入下一轮，直到它认为工作已经完成。

另一层发生在 Agent 外部。即使 Agent 已经停止，外部的 Harness 仍会继续检查结果，并决定是续接原来的 Session、补充上下文、重新启动一个 Session，还是将任务转交给其他执行单元。这里的 Harness，是围绕 Agent 提供运行环境、工具、状态管理和完成条件的外部执行框架。

Agent 内部的 Loop 负责持续执行，Harness 层的 Loop 则负责判断任务是否还需要继续。任务因此可以跨越单次模型调用，保持更长时间的自主运行。

这套机制扩大了 Agent 的执行能力，也可能放大模型原有的编码倾向。

例如，Agent 遇到一个异常状态时，可能在出错位置增加一层判空、异常捕获或 Fallback，让当前测试顺利通过。这次修改单独看往往合理，但更根本的解决办法，可能是收紧数据模型或状态约束，从源头避免非法状态出现。

Armin 的担忧正在于此：当前模型容易增加局部防御、复制已有逻辑或引入新的抽象，却未必会主动建立更强的系统约束。

每一轮 Loop 都可能叠加一小块看似合理的防御逻辑。系统表面上能够处理更多异常情况，原有设计意图却可能逐渐被局部实现和历史补丁掩盖。

问题通常不会立即表现为功能失败。代码仍然可以运行，Agent 也能够继续修改，只是团队越来越难解释：为什么这里存在三层兼容逻辑？这个抽象最初解决了什么问题？哪些分支来自真实业务约束，哪些只是过去某次任务留下的修补？

Loop 放大的不仅是代码生成能力，也包括每一次局部判断带来的长期影响。

二、从 Loop 到软件工厂，理解债开始显现

Addy Osmani 在 《Software Factories, Light and Dark》[2] 中，将 Loop 的规模化运行放进了 Software Factory，也就是“软件工厂”的框架中。

在这套框架里，Loop 持续执行具体任务，Harness 提供环境、工具、状态和完成条件，多个受 Harness 约束的 Loop 从任务队列中领取工作，测试、扫描以及更高层的 Review Gate，共同决定结果能否进入部署和生产环境。

这里 Review Gate 指的是任务继续向下流转前，需要经过的检查与判断。它既可以包含测试、静态扫描等自动化机制，也包括架构判断、风险评估等仍然依赖人类经验的环节。

Addy 用“亮灯工厂”和“黑灯工厂”描述同一套流程的两种运行状态。

亮灯模式同样可以高度自动化。Agent 负责实现，系统自动执行测试、扫描和部署，但关键设计、架构边界和高影响变更仍然有人参与判断，重要决策也保留了可以追溯的原因。

黑灯模式中的流程依然能够运行，代码也可以持续生成、检查和交付，但具体实现越来越少被人阅读，设计意图和历史原因逐渐从系统中消失。

Addy 将由此形成的差距称为 comprehension debt，可以译作“理解债”。

理解债通常被描述为代码规模与人类理解范围之间不断扩大的差距。但在真实工程系统中，它不只是“有多少代码没有被人读过”，更重要的是：关键设计为什么存在，哪些约束仍然有效，谁能够解释这些判断，以及后续变更能否继续继承这些判断。

大型系统并不必然拥有严重的理解债。即使没有任何人掌握全部实现，只要模块边界明确、重要决策可以追溯、关键领域有稳定的责任人，团队仍然可以持续演进系统。

真正危险的是另一种状态：隐式依赖不断增加，历史原因逐渐丢失，原有边界被局部修改绕过，而团队的认知没有同步更新。

系统一直在变化，却越来越少有人能够说明它为什么变成现在这样。

三、验证建立底线，却无法独自维护理解

面对 Agent 执行中的不确定性，加强验证是最直接、也最必要的工程方向。

Anthropic 在 《Building verification loops in Claude Code with skills》[3] 中，介绍了如何把测试、Lint、运行检查和项目规则封装成可复用的 Skill，也就是 Agent 可以反复调用的项目级操作与检查规则。

Agent 完成修改后运行这些检查，失败便继续修复和验证，直到结果达到预设标准。不同开发者和不同 Session 因此可以复用同一套验证步骤，而不必每次重新提醒 Agent 应该检查什么。

Anthropic 还介绍了 Spec Validation、GitHub Actions，以及使用独立 Grader Agent 根据预先定义的 Rubric 检查结果等机制。检查未通过时，任务可以自动退回执行 Agent 继续处理。

在另一篇关于 AI-native 软件开发生命周期的文章 《How Anthropic secures its AI-native software development lifecycle》[4] 中，Anthropic 表示，Claude 已经编写了约 80% 的合并代码，工程师每季度交付的代码量相较于过去也出现了显著增长。

团队通过 CLAUDE.md、组织级 Skill、自动化评审和风险分层，将安全约束直接放进代码生成和交付过程，同时把人工判断保留在高风险和高影响环节。

这些机制非常重要。缺少验证的 Agent，很难成为可靠的生产系统。

但验证能力与系统理解解决的是不同层面的问题。

测试、Spec 和 Eval 可以把已经明确的目标、约束和验收标准，转化为可重复执行的检查。它们能够覆盖的，主要是团队已经意识到、成功表达出来，并且能够以足够低的成本持续执行的规则。

那些散落在历史需求、线上事故、性能限制、组织边界和过去架构决策中的判断，不会自然进入验证体系。

为什么这里采用事件驱动，而不是直接调用？为什么两个看起来重复的数据结构不能合并？为什么某个服务必须独立存在？为什么这段逻辑宁愿增加一点复杂度，也不能引入共享状态？

这些问题很难只靠“检查是否通过”来回答。

验证能够告诉我们，系统是否仍然按照已经表达出来的规则运行；系统理解还需要继续回答：规则是否完整，边界是否仍然合理，原有假设是否已经变化，当前实现是否值得继续保留和演进。

Thoughtworks 的 Valentina Servile 在 《Should we still design code for humans?》[5] 中也指出，软件设计无法在 Spec、Harness 或架构图中一次性完成。

耦合、内聚、重复和复杂度最终会在具体代码中显现，设计判断必须随着实现和上下文变化持续调整。即使未来大部分代码由 Agent 生成，人类仍然需要在关键场景中进入代码层面，判断系统是否保持健康。

良好的代码和架构设计，也不再只服务于人类阅读。清晰的边界、稳定的命名和可控的依赖关系，同样能够减少 Agent 获取上下文和修改系统时的不确定性。

四、AI Coding 正在改变理解债积累的速度

理解债并不是 AI Coding 出现后才产生的问题。

传统软件团队同样会丢失历史背景，形成只有少数人知道的隐性约束，也会因为人员流动、文档缺失和长期修补而逐渐失去对系统的掌握。

AI Coding 带来的变化，在于理解债可能以更快、更隐蔽的方式积累。

. 系统变化的数量和并行度同时提高

过去，一个工程师在同一时间能够推进的修改相对有限。即使设计并不理想，实现、调试和 Review 的过程也为团队提供了观察变化的机会。

当多个 Agent 同时处理不同模块，单位时间内产生的 Diff、PR 和架构变化会显著增加。人类注意力却很难以相同速度扩展。

系统变化速度与组织更新认知的速度，由此开始分离。

. 形成理解的过程被部分抽走

工程师对系统的理解，往往不是通过集中阅读文档一次性形成的。

编写实现、排查问题、阅读调用链、处理测试失败、讨论边界和修改代码，本身就是建立系统认知的过程。Agent 接管越来越多执行工作后，人类获得结果的速度提高了，却可能跳过原本用于形成理解的中间过程。

团队知道功能已经完成，却未必知道 Agent 在实现过程中作出了哪些局部选择，也未必知道这些选择会怎样影响未来变更。

. Review 容易从理解变化退化为验收结果

当一次任务产生数千行修改，逐行理解 Diff 的成本会迅速升高。

Review 很容易收缩为几个更容易确认的问题：测试是否通过、页面是否符合预期、性能指标是否下降、自动评审是否发现问题。

这些检查能够确认结果，却不一定能够暴露实现中新增的隐式依赖、重复概念和长期架构成本。

代码顺利合并，并不代表团队已经吸收了这次变更带来的系统认知。

. 生成结果会成为下一轮 Agent 的系统事实

Agent 生成的代码不会停留在一次任务中。

它会进入代码库，成为后续 Agent 检索、模仿和继续修改的上下文。一次局部修补可能在下一轮被视为既有模式，一个临时抽象也可能被继续复用和扩展。

如果设计原因没有同步记录，局部选择便会逐渐固化为系统结构。后续 Agent 可以继续围绕它工作，却很难判断它是稳定边界，还是一次应该被重新审视的历史偶然。

因此，理解债并不是由“代码由 AI 生成”这一事实直接产生的。

当系统变化越来越频繁、决策过程越来越不可见、关键边界又缺少明确责任时，理解债才会加速积累。

它甚至可能产生在一个运行顺利的 Agent 系统中：代码通过测试，功能正常发布，任务也被标记为完成。

因为没有明显失败，系统认知的流失反而更难被及时发现。

五、团队需要建设可持续的系统理解能力

控制理解债，并不意味着回到逐行手写、逐行审查所有代码的工作方式。

更现实的方向，是明确哪些变化需要人类理解，哪些判断需要长期保留，以及团队如何持续确认自动化系统仍然处于可控状态。

. 把高价值判断前移

高影响变更不应等到大量代码生成完成后，才开始讨论方向是否合理。

在 Agent 执行前，团队需要先明确任务目标、系统边界、数据流、影响范围、关键风险和回滚方式。未来 Review 的高价值对象，不只包括最终代码 Diff，也包括 Agent 准备如何改变系统的计划。

对于跨模块、改变数据模型、引入新依赖或调整核心流程的任务，先审查一份结构清晰的实现计划，通常比事后进入大量生成代码中寻找关键决策更有效。

人类判断应该出现在决策仍然容易改变的位置。

. 把设计原因变成正式的工程资产

文档不能只描述系统现在是什么，还需要记录：为什么这样设计，依赖了哪些前提，保护了什么边界，以及在什么条件下可以改变。

架构决策、重要业务规则、历史事故和高风险约束，需要从少数人的个人经验，转化为人和 Agent 都能够检索、引用和更新的工程事实。

这并不要求每次修改都产生大量文档。更重要的是识别那些寿命长、影响大、难以通过测试完整表达的决策，并让它们拥有稳定的记录位置和责任人。

理解系统，不只是知道代码在哪里，也包括知道一项设计为什么存在。

. 根据风险分配 Agent 的自主权

并不是所有任务都需要相同程度的人工介入。

影响范围小、检查结果明确、失败后容易回滚的任务，可以交给 Agent 自动运行。例如机械性迁移、明确的规则修复、格式调整和可由确定性测试覆盖的局部变更。

跨模块、涉及关键数据、改变公共协议、调整架构边界，或者长期成本难以立即判断的变化，则应该保留人工决策。

团队可以围绕四个维度决定 Agent 获得多少自主权：

• • 变更的影响范围；
• • 结果的可验证程度；
• • 判断中的不确定性；
• • 失败后的可逆性。

自主权不应来自对模型能力的笼统信任，而应来自任务已经拥有足够可靠的边界和验证机制。

. 持续审计自动化系统本身

当越来越多的代码评审和批准由 Agent 完成，团队需要检查的不再只有代码，也包括负责检查代码的 Loop、Skill、Rubric 和规则是否仍然可靠。

Anthropic 的治理实践中包含了对代码库进行风险分层、新评审 Agent 先以 Shadow Mode 运行、抽样检查自动批准结果，以及记录 Agent 的工具调用和决策依据等机制。

这些做法指向一个容易被忽略的问题：自动化规则本身也会过期，评审 Agent 也可能产生偏差，过去有效的 Skill 未必能够持续覆盖新的系统变化。

因此，团队需要定期确认：

• • 关键规则是否仍然有效；
• • 新发现的问题是否已经反映到 Skill、Spec 或项目约束中；
• • 自动批准的结果是否经过持续抽样；
• • Agent 的关键决策是否能够归因和审计；
• • 哪些领域的人工介入正在异常增加或减少。

未来的工程治理，不只是检查某一次生成结果，还需要检查整个生成、验证和批准系统是否仍然值得信任。

在这套体系中，不同工程资产承担不同职责。

测试保护已有行为，Eval 评估 Agent 的结果质量和稳定性，Spec 表达任务目标与验收标准，架构和决策记录保存关键边界及其形成原因，代码则保留最终可执行的实现事实。

它们无法相互替代，但可以共同维护系统的可理解性。

结语：理解需要被持续建设

AI Coding 会继续降低代码生成、修改和重写的成本。

过去因为开发成本过高而未被实现的产品能力和内部工具，可能会以更低的成本完成设计、开发和验证。系统变化的数量、频率和并行度也会继续上升。

团队不需要理解每一行由 Agent 生成的代码，也不可能让有限的人类注意力追上所有自动化执行。

真正需要保留的是一种可持续的系统理解能力：有人知道关键边界在哪里，重要决策为什么存在，高影响变化会带来什么后果，以及什么时候应该停止自动执行、重新作出工程判断。

随着实现成本持续下降，更加稀缺的将是另一类能力：判断哪些变化值得发生，哪些边界必须保留，以及系统应该如何长期演进。

代码生成会越来越便宜，可信的系统理解却不会自动出现。它需要被设计、记录、验证，也需要有人持续负责。

引用链接

[1] 《The Coming Loop》: https://lucumr.pocoo.org/2026/6/23/the-coming-loop/ [2] 《Software Factories, Light and Dark》: https://addyosmani.com/blog/software-factories/ [3] 《Building verification loops in Claude Code with skills》: https://claude.com/blog/building-verification-loops-in-claude-code-with-skills [4] 《How Anthropic secures its AI-native software development lifecycle》: https://claude.com/blog/how-anthropic-secures-its-ai-native-software-development-lifecycle [5] 《Should we still design code for humans?》: https://www.thoughtworks.com/insights/blog/programming-languages/should-still-design-code-humans