Cognitive Debt vs Technical Debt
对比概述
Technical Debt 是系统未来更难修改；Cognitive Debt 是团队现在已经不理解系统为什么这样。AI 让代码生成变便宜后，技术债仍然存在，但更危险的债务上移到概念、词汇和理解层。
核心维度对比
| 维度 | Cognitive Debt | Technical Debt |
|---|---|---|
| 核心问题 | 团队不理解系统含义、边界和命名 | 系统实现选择让未来修改成本上升 |
| 债务位置 | 概念模型、领域词汇、上下文、团队理解 | 代码结构、依赖、测试、架构、重复实现 |
| AI 时代风险 | Agent 生成可运行但没人理解的代码 | Agent 更快制造或修复实现层债务 |
| 典型信号 | 名词漂移、边界模糊、功能能跑但解释不清 | 改一处坏三处、测试缺失、耦合过高 |
| 修复方式 | 重建词汇、模型、文档、例子和共同理解 | 重构、补测试、拆依赖、删除重复代码 |
| 主要后果 | 判断力退化，团队无法审查 AI 输出 | 维护成本升高，交付速度下降 |
| 更深层问题 | 系统意义失真 | 系统结构恶化 |
本质区别
Technical Debt 关注实现是否透支未来。代码能跑，但因为快捷实现、缺测试、错误抽象或耦合过高，未来修改会更贵。
Cognitive Debt 关注人是否还理解系统。代码也许能跑，测试也许能过，但团队不知道概念为什么这样命名、边界为什么这样划、规则为什么这样写。
在 AI 编程环境里，这个区别更重要。Agent 可以快速生成大量实现，也可以帮忙修复部分技术债。但如果人类失去对概念模型的理解，技术债的修复也会变成盲目机械操作。
为什么 AI 放大认知债务
AI 降低了写代码的摩擦，但没有自动降低理解代码的成本。
当 Agent 快速生成类名、函数名、状态机、配置和测试时，团队可能获得一个“看起来完整”的系统，却没有经历建立词汇、讨论边界、理解例外和承担权衡的过程。
这会产生几类认知债务：
- 命名看似合理，但不符合业务语言。
- 模块边界来自模型猜测，不来自领域事实。
- 测试覆盖行为，但没有表达概念不变量。
- 文档解释操作步骤，却没有解释为什么这样设计。
- 团队能让 Agent 继续改，却不能判断改动是否改变了领域模型。
与代码作为概念基础设施的关系
Code-as-Conceptual-Infrastructure 提供了一个更底层判断：代码不只是机器指令，也是人、业务、系统和 Agent 共享的概念基础设施。
因此，技术债和认知债的关系是：
- 技术债破坏代码的可修改性。
- 认知债破坏代码的可理解性。
- 当代码成为 Agent 的外部记忆和行动接口时，认知债会进一步破坏 Agent 的可靠性。
反模式
只让 Agent 清理代码味道
删除重复、拆函数、补测试有价值，但如果没有修正错误词汇和边界，系统只是变得更整洁，未必更正确。
把能运行当成能理解
AI 生成的代码能通过测试，不代表团队理解了它。测试只能证明某些行为成立，不能自动证明概念模型清楚。
用更多文档掩盖错误模型
如果概念本身错了，更多文档只会把错误固化。认知债的修复需要重新命名、重划边界和重建共享语言。
选择指南
优先处理 Technical Debt，当：
- 系统修改成本明显上升。
- 测试缺失、耦合过高、重复实现严重。
- Bug 主要来自实现细节和结构脆弱。
- 团队理解问题不大，但代码形态拖慢交付。
优先处理 Cognitive Debt，当：
- 团队无法解释核心概念和边界。
- 同一业务词在不同模块含义不同。
- Agent 生成的代码看似正确，但审查者只能凭感觉接受。
- 新人或 Agent 需要大量上下文才能避免误解。
在 AI 时代，健康的工程实践应同时避免两类债务：让 Agent 帮忙改善实现结构，也让人类持续维护概念模型。
相关概念
- Cognitive-Debt — AI 加速词汇产生但理解滞后导致的债务。
- Technical-Debt-Avoidance — 通过持续改进避免技术债务累积的策略。
- Conceptual-Model — 代码作为人类和工具理解领域的结构化表达。
- Vocabulary-Building — 将领域语言映射到技术实现中的过程。
- Ubiquitous-Language — 开发者与专家共建的共享语言。
- Compound-Engineering — 持续沉淀有效做法，减少重复错误。
- Essential-Complexity — 无法靠工具自动消除的领域复杂性。