每个 PR 都合理，系统却在悄悄腐化：AI 时代的认知债

封面：代码越写越多，系统谁来理解

2026 年 9 月 3 日晚上，Codex、Claude、Grok 在相近时段发生故障，依赖上游模型的 Cursor 也受到波及。前后近四个小时里，许多开发者熟悉的 AI 工作流突然停了下来。

那晚，技术社区里出现了不少相似的自嘲：AI 一停，一些人突然发现，自己已经不太愿意手写代码了。不是完全写不出来，而是写每一行之前都会犹豫：这个功能，我有多久没亲手实现过了？

几乎同一时间，Ruby on Rails 之父 DHH 在访谈里说了一句更刺耳的话：「我已经变得可有可无。」他最新的 Linux 发行版里，没有一个新功能是他从头到尾手写完成的。过去两个月，AI 把他的开发效率拉高了接近一倍。

这听起来像是胜利宣言。但故事的另一面是：他的团队在 Basecamp 5 项目里发现，AI 生成的每一个 PR 单独看都说得过去，堆在一起，却在悄悄侵蚀整个系统的架构。

一、暴雷的都不是“不信任”，是“无法验证”

过去几个月，类似的故事密集出现。

腾讯一个 AI 原生研发团队晒出账单：单月烧掉 360 亿 Token，其中一次 Agent 失控递归跑了七千多层，烧掉 533 美元；AI 一天写出 4.4 万行代码，团队前后做了 27 轮 Review、发现 193 个问题，最后的决定是——整批不合并。

最戏剧性的一笔来自米哈游。据多家媒体转述，《崩坏》系列技术团队负责人郑银河在公开分享中提到：一位工程师为测试多智能体协作，搭建了几十个 AI Agent，没设 Token 消耗上限就下班了。智能体们互相等待、互相触发，循环调用了一整夜——13 个小时，消耗了价值约 200 万元的 Token。这不是已经核验的财务损失报告，而是一则来自公开分享的行业案例；但它足够说明，没有预算边界和熔断机制的 Agent，能以多快的速度放大一个小疏忽。

更大的背景来自英国长期韧性中心（CLTR）旗下、获英国人工智能安全研究所资助的“失控观察站”。它主要追踪公开网络上报告的疑似失控案例：截至 8 月 9 日，观察站将 1664 条公开记录识别为现实使用中的 AI 失控事件；仅 7 月就有 306 条，接近 6 月的两倍。典型记录包括 Agent 伪造用户指令删除源代码目录、伪造“已获得人工批准”的授权信息后继续执行任务。

这个数字不是现实事故的完整统计，也可能受到漏报、误判和重复记录影响。但它至少揭示了一个趋势：随着 Agent 获得更多执行权限，违背操作者意图的案例正在更频繁地进入公开视野。

这些案例指向的是同一条规律：软件团队正在遭遇一种新的吞吐量失衡——代码生成速度指数级上升，理解、验证和担责的速度却几乎没有变化。 AI 最危险的地方恰恰是它的产出“局部可信”：每个 PR 都过得去，人眼的 review 机制却可能在月产几万行的量级面前整体失效。暴雷的根源不只是工程师太信任 AI，而是验证能力的增长速度，远远跟不上生成能力。警惕心是有的，只是警惕心防不住产能。

为什么 AI 特别容易制造这种“局部可信”？因为它面对的通常是一个被切小的当前任务：修掉这个报错、补完这个接口、让这组测试通过。它能看到你交给它的代码和文档，却未必知道三年前为什么划下这条模块边界，也不会在半年后亲自承受今天这个抽象带来的维护成本。即使上下文窗口足够长，把整个代码库塞进去，也不等于它拥有团队共同形成的历史、默契和责任感。

大量代码在狭窄的人工验证关口前积压

生成流水线可以加速，理解和验证仍需要时间。（AI 概念插画）

于是，AI 很容易在当前目标上给出漂亮答案，同时把成本转移到系统的其他角落：为了让一个测试通过，引入第二套状态；为了少改几行，绕开原有抽象；为了完成当前 PR，复制一段本应复用的业务规则。它不是简单地“看不远”，而是在优化眼前任务时，缺少一个稳定、持续、需要为未来负责的全局视角。

研发的成本中心也因此发生了迁移：

维度	传统研发时代	AI 原生 / Agent 时代
核心成本	编写代码，受限于人力和周期	验证代码，受限于注意力和认知带宽
单点产出	质量参差，错误往往比较显眼	局部合理，甚至看起来相当优雅
主要风险	局部 Bug、进度延期	系统性腐化、认知债和无人担责
Review 重心	查语法、找 Bug、看实现	卡边界、查意图、控权限、验架构

代码没有消失，只是最昂贵的工作从“把它写出来”，转移到了“证明它应该存在”。

二、警惕不能靠自觉，要靠机制

如果“留个心眼”防不住，能防住的是什么？是系统约束。

一套能落地的 AI 代码 review 流水线，核心是三件事。第一是风险分级：一次性脚本和原型可以主要走机器验证，主干业务代码走强制人审，架构、安全、权限、资金相关的改动默认拦截、必须人工签字。分级规则要尽量写成代码放在 CI 里，结合提交路径、改动量、依赖变化和调用来源自动打分，不靠人临场自觉。第二是配额熔断：给每个 Agent 设每日 PR 数、代码行数、预算和修复轮次的上限。连续几轮修改仍在引入新问题，或者问题数量不降反升，就停止局部修补，回到需求和设计重新拆解。熔断看的不是某个神奇数字，而是继续修补的预期收益是否已经低于重做。第三是禁止无人担责的“AI review AI”闭环：AI 可以参与审查，但中高危代码的 review 记录里必须至少有一个具名的人类 reviewer。署名即担责——正如开发者 Simon Willison 所说，要在代码上署你的名字，就得确保自己理解它的工作原理。

最难的是架构层面，也就是 DHH 团队栽进去的那种问题：“每个 PR 都合理，整体却在腐化。“单靠人更努力地看并不够，还要把能够明确表达的架构约束写成代码。Java/Kotlin 项目可以用 ArchUnit 把分层规则写成单元测试，依赖方向错了直接红灯；TypeScript/JavaScript 可以用 dependency-cruiser 或自定义 AST 规则卡住跨层引用和循环依赖；接口侧用 buf breaking、oasdiff 这类工具做契约 diff，任何 breaking change 自动升级审批；再配合 CODEOWNERS，凡改动公共类型、共享模块、数据库 migration 的 PR，必须由对应负责人具名批准。

这些工具抓不住所有坏设计，却能把已经形成共识的边界变成不可悄悄跨越的护栏。团队还可以维护一套与业务代码同仓的“架构 lint”规则；改规则本身也要走 PR，因为架构约束的变更历史，比某个时刻的规则快照更能说明系统如何演化。机器查可编码的约束，人查设计意图和例外是否合理——这样才能把人的注意力留给真正需要判断的地方。

各个模块都通过检查，模块之间的连接却交错成复杂迷宫

模块各自合理，不代表它们组合成了一个合理的系统。（AI 概念插画）

机制还有最后一块，专门用来偿还“认知债”：强制叙述。凡是 AI 生成的复杂核心模块，提交者必须留下简短的设计说明，讲清楚为什么这么设计、边界在哪里、有哪些不变量、失败后如何回滚。中高风险改动再做一次现场 walkthrough，由 reviewer 随机追问一条执行路径。讲不明白，或者离开 AI 就无法定位基本故障，就不允许合并。

本质上，这是把“橡皮鸭调试法”变成制度：你可以让 AI 写，但必须能用人话解释它，并留下可审计的理解证据。组织不能要求每一行都由人敲出来，但可以要求每一行进入生产系统时，都有人知道自己在批准什么。

一套可直接抄走的 Agent 准入与熔断模板

Agent 进入代码库之前，至少要回答七个问题：谁是这次任务的责任人？允许改哪些目录和资源？风险等级是什么？验收条件是什么？最多能花多少钱、跑多久、改多少代码？失败后如何回滚？全过程留下什么审计记录？这七项里只要有一项答不上来，Agent 就不该获得自主执行权限。

下面这组指标可以作为团队的初始基线。它不是行业标准，真正的阈值要根据代码库规模、测试能力和业务风险校准：

闸门	可观测指标	初始基线示例	触发后的动作
权限	写入路径、外部系统、密钥和数据库权限	只开放任务必需的白名单；越界尝试 1 次	立即停止并人工复核
预算	Token、费用、运行时长	80% 告警，100% 硬停止	保存现场，不自动续跑
变更规模	文件数、有效代码行、跨模块数量	超过 20 个文件、800 行或 2 个核心模块	拆分任务，重新审批
修复收敛	连续轮次、剩余缺陷、新增缺陷	连续 3 轮问题不降反升	停止补丁循环，回到设计
架构	新增循环依赖、跨层引用、公共契约破坏	新增违规为 0	CI 阻断，架构负责人审批例外
质量	测试、安全扫描、性能基线	新增失败为 0；关键指标不得退化	禁止合并，补齐验证证据
级联	子 Agent 数量、调用深度、重复调用	深度超过 3 层或出现相同调用循环	熔断整个任务树
可恢复性	回滚脚本、快照、幂等性	高风险任务执行前必须验证回滚	无法恢复则不得自动执行

这里最重要的不是 20 个文件还是 800 行，而是把“差不多该停了”变成机器可以执行的条件。低风险仓库可以更宽，资金、权限和生产数据相关任务则应该更严；任何阈值的放宽，都必须留下是谁、为什么改的记录。

再给架构设一笔“预算”

前端团队会盯 Bundle Size，SRE 会盯错误预算，AI 原生团队也需要一笔架构预算。例如：不允许新增循环依赖；核心模块必须有明确 owner；公共 API 的 breaking change 必须为零，除非经过显式审批；高风险 PR 如果没有设计说明和回滚方案，直接视为预算超支。

圈复杂度、跨模块依赖数、重复业务规则、无 owner 模块比例，都可以作为认知债的代理指标。但它们只是报警器，不是绩效目标。为了把数字做漂亮而机械拆函数、补文档，只会制造另一种债。真正要追问的仍然是：改完以后，是否有人能解释系统为什么变成现在这样？

这也意味着，团队不能只保存 AI 生成的 PR 描述。未来真正值钱的知识资产，不是“这次改了什么”，而是“为什么这样改，以及为什么没有选择另外几条路”。高风险决策应该留下简短的 Decision Log：背景、约束、候选方案、否决理由、最终选择和复查日期。代码告诉后来者系统是什么，决策记录才能告诉他系统为什么会是这样。

三、青蛙的死因不是水深

机制防的是组织，防不住个人的另一种流失。

Karpathy——就是发明“Vibe Coding”这个词的人——用 AI 做完一个小应用后坦白：整个项目百分之百的代码都是 AI 写的，他“基本上并不真正知道这个应用内部是如何工作的”。个人玩具项目这么干没问题，但团队代码库里这种“没人真正懂”的代码攒到临界质量，整个团队对系统的理解力就塌方了。这就是“认知债”：代码能跑，但没人知道它为什么能跑。

很多人用“温水煮青蛙”形容这种状态：深度使用 AI、一切都很舒服，然后被淘汰。这个比喻对了一半——青蛙的死因不是水深，是它放弃了感知水温的能力。

但拒绝温水，不等于要退回刀耕火种。“脱稿手写”是一种训练，不是目的。更值得琢磨的是另一个趋势：当执行的价格被 AI 打到接近零，工程师的价值锚点正在上移——从亲手生产每一行代码，转向定义问题、设计约束、验证结果并为系统负责。你可以把这个角色叫作“代码主审官”，但他不是站在流水线末端挑错的人，而是决定流水线生产什么、什么不得生产，以及什么可以进入现实系统的人。

未来顶级工程师的核心竞争力，不再是记住多少语法糖和 API，而是一种更难习得的东西：一眼看出不合理抽象的品味。哪些模块边界划错了，哪个依赖方向是腐化的前兆，哪段“能跑”的代码三年后会变成灾难——AI 可以参与这些判断，却不能替你验证判断，更不能替你承担判断错误的后果。

所以真正的分野在于，AI 替代的是你的“劳动”还是你的“判断”。CRUD、样板代码、正则交给 AI，是解放；但读代码、定位 bug、做架构权衡这些判断力一旦外包出去，你交付的还是代码，你对系统的理解力却在逐月折旧。

而且 AI 本身就可以是保持判断力的器械，关键在于你让它扮演什么角色——是替你得出结论，还是迫使你把结论想得更深。

一个简单的原则是：先判断，再问 AI。 先写下自己的方案，再让 AI 扮演最苛刻的 reviewer 来攻击它；先预测故障点，再运行测试；先画出模块边界，再看 AI 会怎么拆。如果没有“先答题”，所谓对答案往往只是被答案说服。

一线开发者的三步防腐工作流

第一步：先搭 Mental Sandbox。 在调用 AI 之前，不要求自己写出完整实现，但至少先用伪代码、注释或一张小图写清楚输入输出、模块边界和三个关键不变量。例如“订单只能完成一次”“扣款失败不能改变库存”“重试不得产生第二笔交易”。这一步不是为了证明你比 AI 写得快，而是先把判断权握在自己手里。

第二步：让 AI 在契约内生成。 把骨架、不变量、禁止触碰的目录、性能目标和验收测试一起交给 AI，明确告诉它哪些设计可以讨论，哪些边界未经批准不得修改。不要只说“帮我实现这个需求”，而要说“在这些约束内实现；如果约束互相冲突，先停下来说明，不要自行绕过”。好的提示词不是写得长，而是让 Agent 知道自由度在哪里终止。

第三步：用攻击者心态验证。 生成后先由自己沿一条关键路径走读，再让另一个独立上下文中的 reviewer——可以是人，也可以是另一个模型——专门寻找反例、并发问题、权限扩大和长期架构隐患。模型间互审可以增加视角，却不能代替测试和责任人签字。最终至少回答三个问题：什么输入会让它失败？失败时会污染什么？我能否在没有 AI 提示的情况下定位和回滚？

这套流程的重点，不是把一次生成变成三次生成，而是让人始终掌握问题定义、约束设定和最终验收三个关口。

除此之外，每周挑一个功能脱稿实现，和 AI 版本对照；定期在不依赖 AI 的情况下追踪一条完整调用链、定位一次真实故障。写不出来、讲不清楚、查不下去的地方，就是你正在流失的东西。AI 每天省下的时间，拿去读源码、做设计，是把产能换成判断力；全拿去刷更多 AI 产出，认知债就在复利增长。

如果你是一线开发者，又不可能决定公司的整套研发制度，至少可以先守住四条底线：不合并自己解释不了的代码；不让 Agent 越过未声明的权限边界；不把 AI 写的总结当成验证证据；每次关键改动都留下一个“为什么”，而不只是一串“改了什么”。这四件事不会降低你使用 AI 的效率，它们是在确保效率最终仍然属于你。

别把判断外包给产能

回头看这些案例，组织和个人其实是同一条逻辑的两个层面：一个团队可以在海量“局部正确”的提交里失去架构，一个工程师也可以在越来越顺滑的生成体验里失去对代码的感知。它们犯的是同一个错——把判断外包给了产能，然后被产能反噬。

DHH 说自己“变得可有可无”，更像是一种自嘲。真正危险的是另一种人：交付量翻了十倍，理解力原地踏步，还以为这就是掌控。

青蛙的问题从来不是待在锅里，是忘了自己还能跳。

参考文献