当人类读不完 AI 写的代码,软件质量该由谁负责?

前言

Agent 正在改变软件开发中最基本的一组关系。

过去，代码由人编写，也由人逐行审查。今天，Agent 可以并行修改多个模块、生成测试、运行命令，并在短时间内提交大量变更。代码产量不断上升，但人的注意力没有同步增长。

这意味着，传统代码评审正在遇到一个现实上限：

当人类已经读不完所有 AI 生成的代码，质量保障就不能只依赖“有人看过”。

这并不意味着人工评审将消失，更不意味着 Agent 可以不受约束地修改生产系统。真正发生的变化是：软件质量正在从“依靠个人经验把关”，逐渐转向“由整套约束系统持续执行”。

Google Chrome 团队工程负责人 Addy Osmani 的核心观点是：

Agent 时代的软件质量，取决于我们在 Agent 周围建立了什么约束。

模型负责提出修改，约束决定哪些修改可以继续，哪些必须返工，哪些能够进入生产。🧪

一、AI 生成得越快，传统评审越容易成为瓶颈

代码评审长期以来承担着多重职责：

检查功能是否正确；判断实现是否符合需求；发现安全与性能问题；保持代码清晰、简洁、可维护；确保测试覆盖关键行为；帮助团队共享技术背景。

这套机制有效，是因为代码生成量通常处在人类能够处理的范围内。

Agent 改变了这一前提。一个人可以同时安排多个 Agent 工作，每个 Agent 又能在几分钟内修改多个文件。团队获得了更高的代码产量，也迅速制造出更多等待审查的 Diff。

如果生成系统以机器速度运行，验证系统却仍完全依赖人工，最终必然出现队列：

Agent 高速生成→ 修改持续积压→ 人工评审来不及处理→ 等待时间不断增长→ 整体交付速度反而下降

所以，问题已经不再只是“Agent 写得好不好”，而是：

我们的验证能力，能否跟上代码生产能力？

Addy Osmani 并不主张彻底放弃人工阅读。他强调的是，应当有意识地决定人类注意力投向哪里。

未来的代码评审不会简单消失，而会从“平均检查每一行”，转向“集中处理自动化无法可靠判断的问题”。🤖

二、是否阅读每行代码，首先取决于失败代价

围绕 AI 生成代码，一个常见争论是：人类是否还应该阅读所有代码？

这个问题没有统一答案，因为不同代码承担的风险完全不同。

如果只是一段一次性脚本、内部实验或验证想法的原型，没有真实用户，不接触敏感数据，也能随时丢弃，那么逐行评审的收益可能很低。

但如果修改涉及以下内容，审查标准就必须提高：

用户账户与身份认证；支付、订单和资金处理；隐私数据与企业机密；权限、加密和安全边界；数据库结构与不可逆迁移；核心业务和生产基础设施；需要长期维护的公共接口。

因此，判断能否减少人工阅读，本质上不是判断 Agent 是否值得信任，而是评估：

审查强度≈ 失败概率 × 影响范围 × 恢复成本

一次低风险实验即使失败，也可能只损失几分钟；一项权限逻辑错误，则可能带来数据泄露和合规问题。

真正不可接受的，不是减少人工阅读，而是在没有足够自动约束的情况下，用“Agent 很聪明”替代验证。

如果人类不逐行检查，系统就必须提供同等甚至更强的安全证据。 🧭

三、质量门禁，决定什么代码有资格进入生产

Prompt 可以要求 Agent“写出高质量代码”，却无法确保它每一次都能做到。

它可能忘记边界、扩大修改范围，也可能为了让测试通过而绕开真正问题。语言指令表达的是期望，不能替代确定性约束。

因此，Agent 周围需要一组质量门禁：

Agent 提出修改→ 检查修改范围→ 编译与类型检查→ 单元和集成测试→ 架构规则检查→ 安全与性能验证→ 必要时人工审批→ 允许合并或发布

质量门禁不是一个工具，而是多种信号的组合。

正确性门禁

通过单元测试、属性测试、集成测试和业务验收测试，检查代码是否满足预期行为。

测试质量门禁

测试本身也可能无效。变异测试会主动对代码制造错误，如果原有测试仍然通过，说明它可能没有真正覆盖关键行为。

可维护性门禁

复杂度、重复率、函数长度、依赖方向和命名规范，可以帮助团队及时发现“虽然能运行，但越来越难维护”的代码。

安全门禁

依赖漏洞、密钥泄漏、注入风险、越权访问和危险配置，都应尽量由自动规则提前拦截。

性能门禁

基准测试、响应时间和资源消耗可以防止一项功能正确，却明显拖慢整个系统。

这些检查并不互相替代。测试通过不代表代码安全，安全扫描没有告警也不代表业务逻辑正确。

Addy Osmani 强调，软件质量并不是一个单一分数，而是一组重要程度不同的信号：

正确性；可维护性；性能；安全性；资源效率；可理解性。

Agent 可以提出任何方案，但门禁决定它是否足够正确、安全、克制和有用。🚧

四、最有效的约束，不在最后拦截，而在全程提供反馈

很多团队把质量控制集中在 CI 最后一步。

Agent 已经完成大量修改并提交代码，CI 才告诉它测试失败、性能下降或安全扫描未通过。这种模式虽然能够阻止问题进入生产，却发现得太晚。

真正有效的质量系统，应把反馈压力分布到整个执行过程。

工作开始前：限制行动范围

Agent 应该提前知道：

哪些文件允许修改；哪些目录只能读取；哪些依赖可以引入；哪些命令需要批准；哪些数据不可访问；这次任务明确不包含什么。这些约束减少的是“走错方向”。

执行过程中：提供可信反馈

编译器、类型检查、局部测试、Linter 和写后回读，应在 Agent 工作时持续返回结果。

类型不匹配→ 立即修正接口局部测试失败→ 重新检查实现修改越过目录边界→ 直接拒绝操作写入文件后→ 重新读取并验证结果

这些反馈帮助 Agent 逐步逼近正确答案，而不是在结束时凭主观判断宣布完成。

进入生产前：守住最终边界

完整回归、安全扫描、性能基线、审批机制和灰度发布，决定一项修改能否真正影响用户。

这种贯穿全程的拒绝和反馈，就是 Addy Osmani 所说的back-pressure（反馈压力）。

它不是单纯拖慢 Agent，而是防止低质量变更在系统中一路向下游扩散。

沙箱、独立工作区、临时数据库、最小权限和可回滚提交，都是实现“低损害失败”的重要基础。🔄

五、机器负责规模化检查，人类负责高价值判断

自动化验证的目标，不是把人完全移出流程，而是保护稀缺的人类注意力。

机器擅长稳定、重复地回答：

代码能否编译？类型是否正确？测试是否通过？是否违反格式和架构规则？是否出现已知漏洞？性能是否低于基线？修改是否超出任务范围？

人类更适合判断：

Agent 是否真正理解了需求；实现方向是否符合产品意图；架构取舍是否合理；用户体验是否自然；风险是否值得承担；代码是否容易被未来团队理解；某项设计是否符合长期战略。

因此，更合理的评审路径是按风险动态分流：

自动门禁全部通过＋低风险修改→ 自动进入下一阶段信号互相冲突或结果难以客观判断→ 请求专业人员审核涉及支付、权限、数据与核心架构→ 强制人工审批Agent 多次修复仍失败→ 停止自动循环并升级处理

这会让人工代码评审从“机械检查”转向“判断与决策”。

机器可以执行标准，人类仍然负责定义标准，并为发布结果承担责任。👥

六、质量与速度的关键，不是约束越多越好

Agent 时代容易出现两种极端。

一种是完全依赖人工，所有修改都进入漫长评审队列；另一种是为了速度不断降低门禁，直到系统只能在生产事故中发现问题。

真正成熟的做法，是根据风险主动调整约束强度。

当验证速度跟不上生成速度时，团队有几种选择：

扩大验证能力

增加并行测试环境、优化慢测试、拆分测试套件，让更多检查能够同时运行。

降低生成速度

限制 Agent 并发，缩小单次修改范围，并要求提交前完成本地验证。

降低生成量未必降低交付速度。更少、更小、更容易验证的 Diff，往更快进入生产。

按场景调整质量标准

原型、内部工具、普通业务功能与支付系统，不需要采用完全相同的门禁。

低风险区域可以提供更多自由，高风险区域则必须保持强约束。

重新分配自由与限制

团队可以允许 Agent 自由探索界面和文案，却严格限制数据库、权限和基础设施变更；也可以允许它在沙箱中尝试多种方案，却不允许未经批准操作生产环境。

核心原则是：

在最在意的地方收紧约束，在可以安全失败的地方释放创造力。

约束本身也需要证明价值。

如果一项检查速度极慢、误报严重，又无法提供清晰反馈，它会让团队逐渐忽略告警，最终损害整个质量体系。

好的约束应至少完成一个目标：

阻止关键风险；提供有助于修复的明确反馈。

既不能改善质量，也不能帮助执行的规则，应被调整或移除。

Addy Osmani 的观点最终指向的，并不是“用机器取代码评审”，而是重新设计软件质量的责任分配：

Agent 提高生产速度，自动门禁提供规模化验证，人类把注意力留给意图、架构、风险和品味。

未来的软件质量，不会只存在于某一次 PR Review 中。它会分布在权限、编译器、测试、静态分析、安全策略、沙箱、CI、监控与人工审批组成的整条链路上。

当 AI 生成的代码多到人类无法全部读完时，真正的问题不再是“谁读过这些代码”，而是：

我们是否建立了足够可信的证据，证明它们可以安全地被使用。