AI 写的代码还要不要看？我不逐行改，但一定会看系统架构
最近我看到一种很有冲击力的说法：AI 写出来的代码，其实不用看。
这句话有它的现实背景。Coding Agent 已经可以自己读仓库、修改文件、运行测试、修复失败。如果人还坚持逐行理解每一次生成，人的阅读速度很快会成为整条链路最慢的地方。
这句话来自 Robert C. Martin，也就是《Clean Code》和《Clean Architecture》的作者 Uncle Bob。2026 年 7 月 23 日，他在 X 上的一则回复中说，自己目前的策略是不阅读 Agent 写出的代码，而是用单元测试、Gherkin 验收测试、QA 流程、质量指标、变异测试和覆盖率等大量约束，让代码通过一道“考验场”。
这张回复很重要。原始问题问的是：既然人要对代码负责，是不是就必须理解它？Uncle Bob 给出的不是一句孤立的“不看”，而是一种交换——放弃逐行阅读，同时把规格、测试、质量指标和 QA 约束提高到足以建立信任的强度。
Clean Coders 公布的 Agentic Discipline 流程设置了 Specifier、Coder、Cleaner、Architect、Hardener 和 QA 等角色。代码要经过行为规格、代码质量、模块结构、依赖图、属性测试、变异测试和界面操作验证。O'Reilly 对相关课程的介绍，也把单元测试、验收测试、变异测试、代码质量和依赖检查列为不同纪律。
问题因此落在另一处：人的判断应该留在哪一层？
但我的做法并不完全一样。
我仍然会看 AI 写的代码，只是很少从第一行读到最后一行，也很少亲手修改某个函数。看的目的不是检查它有没有少写一个分号，而是判断系统有没有变得更难理解，架构边界是否仍然合理，这次局部实现会不会把问题带到下一轮。
不逐行通读，和完全不看，是两回事。
分歧不在测试，而在谁来观察架构
Uncle Bob 的流程并没有放弃架构。它设置专门的 Architect Agent，检查和调整模块结构与依赖图；Cleaner Agent 负责控制重复和复杂度；Hardener Agent 再用变异测试等方法检查测试是否真的能发现错误。
这套方法把过去依赖人眼的很多检查变成了可执行门禁。我认同这个方向。类型、复杂度、依赖、覆盖率、变异测试和真实界面验证，本来就比一次快速人工扫读更稳定。
我与这种做法的差别在于：现阶段，我还不愿把系统级判断全部交给 Agent。
我会让 Agent 生成架构分析、热点统计和依赖检查，也会让第二个模型挑错。但我仍会亲自看模块怎样分工、状态由谁持有、依赖朝哪里走，以及一次局部修改是否正在改变系统长期结构。
原因很实际：产品方向、兼容边界和未来还要承接什么需求，往往没有完整地写进现有测试。
这套想法已经进入了我们的工具链。7 月 26 日，我们在 ArchSight AIOS 中增加了 aios-arch-health：项目自己的扫描器先产生复杂度、重复、依赖、覆盖率和运行证据，它再与历史基线比较，判断有没有新增或恶化的架构债。
这与 Uncle Bob 的思路很接近：不要把信任建立在“我大概看过”，而要把可以自动检查的约束写成持续运行的门禁。但这套门禁刻意限制了自己的权力。只有工具能够复验的问题才可以阻断；文件行数、扇入扇出和模型推断只作为调查信号；里程碑要求的真实数据库、性能或失败注入证据缺失时，结果只能是暂缓放行。
至于一个热点是合理复杂度，还是责任已经混在一起，仍然要交给 aios-arch 解释。这个传统架构分析命令几乎是我在 AIOS 中使用最多的入口。它不只看复杂度数字，还会结合业务目标、模块责任、数据链路、模型与 Runtime 边界，判断系统为什么形成现在的结构，以及下一步应不应该改。
我把两者看成不同层次的工作：aios-arch-health 负责反复运行、可复验的门禁；aios-arch 负责带着上下文做架构评估。前者告诉我哪里发生了可测量的变化，后者帮助我理解这项变化对系统意味着什么。最终取舍仍然在人。
代码越来越多以后，逐行阅读很难继续
传统开发里，代码大多由人亲手写出来。设计、实现和理解常常发生在同一个过程中。开发者知道一个判断为什么放在这里，也记得某个兼容分支是为了解决什么历史问题。
Agent 改变了这个节奏。
一个过去需要几天的功能，现在可能在一轮任务里完成。它会增加接口、状态、异常处理、测试和文档。代码量快速增长，人却没有经历每一行形成的过程。
这时如果仍把“我是否逐行读完”当作唯一质量标准，通常会出现两个结果：要么 Agent 的速度被人工阅读重新拖慢，要么人只是快速扫过大量代码，获得一种已经检查过的错觉。
所以我接受一个变化：低风险、边界清楚、验证充分的实现，不需要每一行都由我重新解释。
但系统不能因此变成黑箱。
我先看的不是函数，而是系统发生了什么
Agent 完成任务后，我通常先看修改地图。
它动了哪些模块？增加了什么入口？谁开始保存新的状态？依赖方向有没有改变？原来的公共接口是否还稳定？测试证明的是局部函数，还是用户真正会走的路径？
我特别关注几类信号：
- 同一份业务事实是否开始被多个模块分别保存；
- 一个入口是否同时承担界面、业务、存储和错误恢复；
- 为了让测试方便，生产代码里是否出现了只服务测试的特殊通道；
- 新功能是否绕过已有契约，直接依赖内部实现；
- 工具失败以后，系统是否用一个看起来完整的结果静默降级；
- 测试数量增加了，真实运行和异常恢复是否仍然没有证据。
这些问题很少能通过某一行代码单独看出来。
一段实现可以完全正确，放进系统以后仍然可能让责任边界变得模糊。一个文件行数很多，也不一定有问题：如果它职责单一、变化稳定、接口清楚，就未必需要为了“看起来整洁”而拆开。
我真正想知道的是，这次修改以后，系统是不是还在人的理解范围内。
最近一次对 Compliance 项目的连续重构，很能说明我实际在看什么。
我没有要求 Agent 把每个大文件都拆小，也很少指出某个函数应该怎样改。我反复追问的反而是：
- 这项持续运行的重构目标还在解决当前最重要的问题，还是已经变成为了重构而继续重构？
- 外部模型指出的风险是真实缺陷，还是一个听起来严重、却没有运行证据的推测？
- 一个大文件是真的混合了多种责任，还是只是代码较长？
- 路由、业务判定、状态和存储路径为什么会由同一层同时解释？
- 这轮治理怎样变成以后可以周期性运行的检查，而不是依赖某次人工发现？
其中一次，Gemini 指出图数据库的多步写入可能留下部分成功、部分失败的状态。我们没有因为“另一个大模型也这样认为”就立刻重构，而是先做故障注入。风险能够重现，才被提升为优先问题。它同时提出的另一个后台任务风险没有复现，就没有为了配合报告而制造整改任务。
同样，看到一千多行的面板或路由文件，我关心的也不是先把行数降下来，而是沿着责任继续追：谁拥有状态，谁解释业务规则，谁负责持久化，失败以后由谁恢复。最后发生的变化，往往是让业务判定回到唯一边界，让共享的可变存储路径变成显式上下文，或者让交付预检不再藏在 HTTP 路由里。文件变短只是结果，不是目标。
当一次重构持续很久，我还会追问它是否已经接近收口。架构治理也有机会成本。只要继续扫描，总能找到下一个热点；难的是判断哪些风险值得现在处理，哪些只需要记录，以及现有证据是否已经足够支持停止。
我看代码时实际保留了四种判断：方向是否正确，边界是否清楚，证据是否独立，以及工作是否应该继续。它们都可能从一段代码开始，却不会停在那一段代码里。
看出问题以后，我通常不会亲手改
这也是我的工作方式与传统代码审查不太一样的地方。
发现架构方向不合理时，我很少打开文件，把几个函数直接改掉。更常见的做法是重新描述问题：哪一份状态应该成为唯一事实，依赖应该朝哪个方向，哪些接口不能变化，哪些旧行为需要先由测试锁住，以及什么证据才能说明调整没有破坏用户流程。
然后让 Agent 完成迁移、补测试、运行验证，再回来汇报结果。
因为架构问题通常不是改好一行代码就结束。人如果只修眼前的实现，Agent 下一轮仍可能沿着原来的边界继续生成。只有把责任、契约和验收条件重新说清楚，后续代码才会换一条路径。
我的价值不在于比 Agent 更快地敲出那几行代码，而在于及时发现方向偏了，并让整个系统回到更可控的结构上。
约束可以替代逐行阅读，但谁来约束这些约束？
“不看代码”的做法会把更多信任交给规格、质量指标、测试、构建和运行结果。这一部分我赞同。
这场讨论里还有一个追问。Repojournal 问：如果 AI 会擅自修改测试，让结果符合自己的实现，甚至制造虚假的阳性结果，我们凭什么相信它会一直留在设定的约束里？
Uncle Bob 的回答很短：它们的可靠性与人相似，所以要留意它们。
这句话反而把问题说得更清楚了。自动化门禁降低了逐行阅读的必要，却没有取消人的注意力。人仍然要确认 Agent 有没有改动验收标准，测试和实现是否来自同一套错误假设，以及所谓“通过”是否能在真实环境中重现。
这也暴露了第一版 aios-arch-health 的一个缺口。
报告可以写“单元测试、覆盖率、性能证据已经取得”，但如果没有记录它由什么工具、哪条命令、针对哪个提交产生，就很难证明这盏绿灯属于当前代码。更麻烦的是，Agent 可能在修改实现的同时调整验收测试、质量阈值或 QA 流程。测试仍然通过，约束本身却已经变了。
我据此为已经随 ArchSight AIOS 1.6.0 发布的 aios-arch-health 补了两层检查。
第一层是证据来源完整性。必需证据可以记录工具、版本、命令、执行者、角色、提交号、运行时间和环境；周检或里程碑还可以要求保存原始报告的位置与 SHA-256 摘要。证据对应的提交不一致，或者只剩一句无法复验的“测试已通过”，门禁返回 HOLD。
第二层是受保护约束完整性。规格、验收测试、单元测试、质量配置和 QA 流程都可以登记稳定 ID 与内容摘要。只要它们相对基线发生新增、修改或删除，就需要一份覆盖全部变化的独立复核证据。改动约束的人不能同时批准自己的改动。
这两层检查不能证明测试已经穷尽全部风险，也不能判断规格本身一定正确。它们只解决一个更基础的问题：实现代码和约束一起变化时，不能让“绿灯”把这个事实藏起来。
很多正确性判断，本来就不应该依赖人肉阅读。类型检查比人更适合发现类型错误，单元测试适合锁定局部行为，浏览器或桌面端实测能够证明真实交互，基准算例可以验证计算结果。只靠眼睛看代码，既慢，也容易漏。
但门禁主要证明已经被写进规则和断言的内容。
它不一定会告诉你：系统里已经出现第二份事实来源；依赖方向正在反转；一个公共接口悄悄泄漏了内部结构；五个局部正确的补丁正在把同一个入口变成新的巨石。
这些问题短期内可能不会让测试失败。它们影响的是下一次修改的成本、故障能否归层，以及半年后团队还能不能解释系统为什么这样工作。
所以，自动化门禁可以减少逐行阅读，却不能替产品负责人补齐尚未显式表达的架构意图，也不能自己证明约束没有在执行过程中被悄悄改写。
不同风险的代码，应该看不同深度
我现在更愿意按风险决定审查深度，而不是规定“所有代码都看”或“所有代码都不看”。
样式调整、机械适配、生成文件和边界清楚的重复代码，我主要看任务结果、修改范围和自动化检查，通常不逐行读。
业务流程、状态管理、公共接口和持久化结构已经影响系统边界。我会检查契约、依赖方向、状态归属与关键差异，再选择性进入实现。
权限、安全、数据迁移、删除操作、资金逻辑、工程计算和不可逆变更，需要独立验证、失败测试、真实运行证据与人工复核。这里不能只看报告摘要，关键实现和回滚路径都要深入检查。
这里没有一个适用于所有项目的固定比例。
一个内部一次性脚本和一个长期维护的工程平台，要求不同；一个页面颜色调整和一次数据库迁移，也不能使用同样的审查方法。代码是否需要细看，取决于错误代价、可逆性、验证能力和后续维护责任。
风险不在少看了几行低风险代码。高风险变化也被一句“测试通过”带过去，才是问题。
我更关心三层证据
如果不再逐行通读所有代码，人的审查需要换成更清楚的结构。
第一层是系统证据：模块职责、依赖方向、状态所有者、公共契约和修改热点是否仍然清楚。
第二层是变更证据：这次具体改了什么，为什么改，哪些兼容行为不能破坏，哪些高风险路径需要人工打开确认。
第三层是运行证据：测试、构建、真实界面、真实文件、硬件环境或用户操作是否证明任务确实完成。
三层证据解决不同问题。
架构图不能证明功能已经运行，测试通过也不能证明架构仍然健康。只有把系统方向、具体变化和运行结果放在一起，人才有条件决定这次修改能不能进入下一步。
Martin Fowler 对 Agentic Programming 的区分也提供了另一条参照：Vibe Coding 的特点是人不再关心代码，而 Agentic Programming 仍由人评估 Agent 的工作，包括代码审查、测试结果和其他传感器输出。实际团队未必只能选择其中一个极端，更可能按风险决定人要深入到哪一层。
AI 时代，人保留的不是每一行代码，而是设计权
我不认为未来的软件负责人必须理解 Agent 生成的每一行代码。随着系统规模和生成速度继续增长，这个要求会越来越难做到。
但他至少要知道系统由哪些部分组成，关键事实保存在哪里，风险集中在哪些路径，出现问题以后怎样定位，以及哪些结果不能只交给模型和测试自行判断。
人可以少写，也可以少做低价值的逐行检查。
不能一起放弃的，是对系统方向的理解，以及最后的放行责任。
我现在仍然看 AI 写的代码。只是我看的单位，正在从一行代码变成一组边界、一条依赖和一套证据。
参考资料
以下资料均可按作者、机构和标题检索：
- Robert C. Martin（@unclebobmartin）：2026 年 7 月 23 日关于 Agent 代码审查的公开回复。
- Clean Coders：《Agentic Discipline 6: Swarm Forge Demonstration》。
- O'Reilly：《AI Agents for Clean Code with "Uncle Bob" Martin》。
- Martin Fowler：《Agentic Programming》。
- ArchSight AIOS：
aios-arch-health架构健康门禁，以及aios-arch架构分析与评估。
关注我们
欢迎搜索并关注 筑见实验室，获取更多建筑 AI、数字化工具与工程工作流实践：
