黑箱转向（三）：认知债——团队知道得越来越少吗

Lingming — Mon, 02 Mar 2026 11:45:57 -0500

一次故障发生在周五深夜。代码风格整洁，测试也不少，但值班工程师无法回答三个问题：这个重试为什么设置为五次？两个状态字段为何必须一起更新？删除某段兼容逻辑会影响哪一批旧客户？

问题不是代码不可见，而是让团队安全修改它的知识没有留在可调用的位置。上一篇把生成拐点定义为实现吞吐超过保证吞吐。本篇讨论这种落差积累后的一个结果：认知债。

认知债不是“没人读过全部代码”

大型系统本来就不需要每个成员理解所有细节。健康的抽象允许团队只掌握与职责相称的部分。若把“不知道每一行”都算作债务，模块化本身就会成为问题。

本文采用一个更窄的定义：

认知债，是团队为了安全解释、修改和恢复系统所需要的知识，与当下能够及时调用的知识之间的缺口；这项缺口把成本和风险推迟到未来。

这个定义包含两个限制。第一，缺少的必须是未来任务真正需要的知识，而不是任何可能知识。第二，它必须产生延迟成本，例如变更更慢、审查失真、事故恢复困难或关键人员离开后风险上升。

因此，认知债不能仅凭代码行数、AI 生成比例或主观陌生感判断。它需要在具体任务中表现出来。

它与技术债、意图债有什么不同

技术债通常位于软件制品中：重复逻辑、脆弱依赖、缺少测试、不合理耦合。即使没人意识到，它们仍可能通过分析和重构被发现。

认知债位于团队与系统的关系中。同一份代码，对长期维护者可能没有认知债，对刚接手且没有文档的团队却可能风险很高。

还可以进一步区分意图债：系统保留了“做了什么”，却没有保留“为什么这样做”、替代方案为何被拒绝、哪些假设可能过期。意图债是认知债的重要来源，但两者不完全相同。团队也可能拥有设计记录，却缺乏把它应用到当前故障的能力。

债务	缺口主要在哪里	常见表现
技术债	代码与架构制品	改动牵一发而动全身、缺陷反复出现
认知债	团队可调用的心智模型	接手慢、审查无法质疑、事故定位困难
意图债	决策理由与约束记录	不敢删除旧逻辑、反复争论已解决问题

三者会相互强化，但治理手段不同。重构可以减少技术债，培训和轮岗可以减少认知债，决策记录和需求追踪更适合处理意图债。

AI 如何增加认知债

AI 并不是唯一来源，却会放大几种积累机制。

先有答案，后补问题模型

工程师在充分理解领域之前就得到可运行实现，容易把熟悉的代码形状误认为正确的问题模型。系统可以通过当前测试，却没有人能说明未测试的边界。

生成批量大于学习批量

一个人可能逐行编写时顺便形成局部心智模型；一次接受数百行跨模块变更时，这种伴随学习不会自动发生。阅读者如果只确认表面合理，就把理解成本推给未来维护。

设计理由停留在临时对话

模型对话可能包含关键约束、失败尝试和方案取舍，但最终仓库只保存代码。聊天记录即使被保留，也常常过长、含噪且难以检索，不能直接等同于设计文档。

能做出来被误认为能够维护

代理可以在熟悉基准上完成任务，却未必掌握组织内部历史、合规规则和运行经验。团队若因为生成成功而削弱人工所有权，故障发生时会发现工具和人都缺少完整上下文。

AI 也可能减少认知债

认知债不是使用 AI 的必然结果。同一种工具也能解释陌生模块、生成调用图、比较方案、补充测试、整理事故记录或把隐性知识转成可搜索文档。

关键差别是它承担哪一种角色：

替代角色：直接交付答案，人类跳过建模与质疑；
脚手架角色：帮助人类建立、检查和外化心智模型。

2026 年一项针对本科软件工程项目的初步定性研究把类似现象称为 comprehension debt。研究从学生反思记录中识别出黑箱式接受、上下文不匹配和绕过验证等积累模式，也观察到把 AI 用作理解脚手架的缓解模式。它提供了有用线索，但样本来自教学项目，不能直接外推到所有专业团队。

怎样观察认知债

认知债目前没有公认的单一指标，也不适合用一个分数制造虚假精确。可以组合观察以下信号。

修改前的预测能力

在查看测试结果之前，维护者能否预测改动会影响哪些模块、数据和用户？预测长期偏差，说明心智模型与实际系统脱节。

接手与解释成本

新成员完成一个真实变更需要多久？审查者能否用自己的话解释关键不变量？如果只有提示操作者能够继续工作，知识并未真正进入团队。

事故诊断能力

平均恢复时间上升不一定来自认知债，但事故中反复出现“没人知道为什么”“只能试着回滚”“不敢动这段代码”，是更直接的定性证据。

决策理由覆盖

高风险模块是否保存了关键约束、被拒方案和有效期限？文档数量不是重点，能否在需要时找到并验证才是重点。

审查的质疑密度

审查是否只剩格式和测试通过，还是有人挑战需求、权限、失败方式与可运维性？完全没有异议的大批生成变更，不一定代表质量极高，也可能代表审查者没有形成模型。

怎样偿还，而不是制造文档仓库

缩小生成批量。 让每次变化足够小，使审查者能解释其目的、边界和风险。
要求教回。 合并前由负责人不用模型复述关键数据流、不变量和失败模式。
保存决策，不保存全部对话。 把长对话压缩为简短的架构决策记录，并说明假设何时需要复查。
让测试表达性质。 除了示例输入输出，还记录为什么这个性质重要，以及哪些区域尚未覆盖。
轮换真实所有权。 通过结对、值班和跨人审查检验知识能否转移。
删除不必要实现。 AI 让增加代码很便宜，更需要把删除、合并和依赖收缩当作正式工作。
在事故后更新模型。 复盘不仅修 bug，还要说明此前哪条理解错误、怎样让下一位维护者更早发现。

这些做法的目标不是让每个人背下系统，而是让关键知识不只存在于某次生成会话、某个人的记忆或一个无法验证的解释里。

结语：债务来自延迟，而不是无知本身

工程师永远会对系统有所不知。健康工程的目标不是消灭未知，而是把未知放在合适边界内，并为重要未知配置验证和恢复机制。

认知债出现于另一种情况：团队今天接受了自己尚未理解、也没有外部证据充分约束的变化，把解释和维护成本推迟给未来。AI 让这种借款更容易，也能帮助偿还。决定方向的不是工具是否生成代码，而是组织有没有把理解视为需要持续维护的共同资产。

延伸阅读与参考资料

上一篇：《黑箱转向（二）：生成—验证落差，真正的拐点》；下一篇：《黑箱转向（四）：控制不可读之物，需要哪些证据》。

认知债 on Lingming 灵明