当我们谈论技术债务时，习惯性地将目光投向代码质量、架构腐化以及那些为了赶交付而留下的技术债息。Martin Fowler 多年前提出的技术债务四象限（故意与无意、审慎与鲁莽）至今仍是分析代码层债务的经典框架。然而，随着生成式 AI 大幅加速代码生产，一个更为全面的视角正在浮现 —— 技术债务、认知债务与意图债务组成的三层债务模型，正在重新定义软件健康的衡量方式。
从技术债务到三重债务的演进
传统技术债务的核心隐喻来自金融领域：为了当下的交付速度，我们向未来 “借款”，随后需要支付利息来偿还。代码中的坏味道、重复逻辑、紧耦合架构，都是这种债务的具体表现。在相当长的时间里，技术债务几乎是软件质量话题的同义词，团队通过重构、架构演进和代码审查来管理这笔债务。
但 AI 辅助开发带来了根本性变化。生成式 AI 能够以惊人的速度产出代码，甚至可以自动修复已有的技术债务。这并没有消除问题，反而催生了两种更为隐蔽的风险。arXiv 论文《From Technical Debt to Cognitive and Intent Debt》首次系统性地提出了这一三重债务模型，将技术债务的内涵从代码层扩展到了知识层与意图层。
认知债务：团队共享心智模型的腐蚀
认知债务描述的是团队对系统理解能力的衰减。当 AI 快速生成大量代码时，人类开发者往往接受这些产出而停止追问 “为什么这样设计”。久而久之，团队中形成了所谓的 “机器之心智替代”—— 代码可以运行，但没有人能完整解释系统的运作逻辑。
认知债务的典型症状包括：新成员 onboarding 时间显著延长，每次代码改动都可能导致意外的回归缺陷，团队依赖少数关键人物来理解核心模块，以及面对复杂业务逻辑时的集体性盲目。这种债务的危险之处在于它难以量化。代码可以由静态分析工具检测，但团队对系统的集体理解程度缺乏直接的度量手段。
意图债务：决策理由的缺失与湮灭
如果说认知债务关注的是 “团队是否理解系统”，那么意图债务则聚焦于 “我们为什么要这样构建系统”。意图债务产生于设计决策、业务约束和架构原则未被显式记录或有效传达的场景。当这些 “为什么” 被遗忘或从未被捕获，系统演进就失去了方向锚点。
在 AI 辅助开发的语境下，意图债务的影响被进一步放大。AI 代理需要明确的指令才能产生符合预期的输出，如果最初的业务目标和设计约束没有被文档化，AI 就会基于不完整甚至错误的理解进行 “推理”，导致系统悄然偏离原始愿景。架构决策记录（ADR）、业务规则文档和设计原则清单，都是对抗意图债务的有效工具。
三层债务的交互机制与工程量化
三重债务并非孤立存在，它们之间存在复杂的增强关系。技术债务会加剧认知债务 —— 混乱的代码结构使得理解系统更加困难；认知债务反过来又会催生更多的技术债务 —— 不理解的团队更容易做出短视的设计决策；意图债务则像隐藏的暗流，当团队不清楚系统应当达成什么目标时，所有层面的债务都可能同步恶化。
在工程实践中，可以从以下几个维度进行量化评估。针对技术债务，静态分析工具提供的代码复杂度、圈复杂度和重复代码覆盖率仍是基础指标。针对认知债务，团队可以追踪平均 onboarding 时长、关键模块的代码 owner 分布以及技术方案评审中 “无法解释清楚” 的比例。针对意图债务，架构决策记录（ADR）的完整率、业务规则文档的更新频率以及设计评审会议的决策留存率都是可操作的度量。
AI 时代的债务管理策略
面对三重债务模型，团队需要调整管理策略。首先，不能将 AI 视为技术债务的万能解药 —— 它擅长清理代码，却可能加速认知和意图债务的积累。其次，应当将 “交付理解” 视同 “交付功能”，在每个迭代中留出知识共享和决策记录的时间。第三，文档应当由人类撰写而非委托 AI 代笔，因为撰写过程本身就是团队对齐认知的关键环节。
最后，定期的 “系统可解释性” 练习值得引入实践 —— 让不同成员轮流讲解自己未参与开发模块的设计逻辑，这种交叉知识传递是控制认知债务的有效手段。技术债务可以用重构偿还，但认知和意图债务的偿还需要持续的组织文化投入。
资料来源：arXiv 论文《From Technical Debt to Cognitive and Intent Debt: Rethinking Software Health in the Age of AI》；Martin Fowler 技术债务四象限原文。