AI 编程时代为什么认知债可能成为新的技术债？
AI 编程时代，认知债可能成为新的技术债，因为代码生成成本快速下降后，真正稀缺的资源变成了人类判断：团队能否理解系统、确认产品意图、审查风险，并对长期运行负责。代码可以在几分钟内重写，组织却不能以同样速度重建知识和信任。
来源反映的是工程领导经验，不是行业普查
一篇由 Reddit 帖子链接的会议纪要，记录了多家科技公司十余位工程领导在多伦多 CTO 晚餐中的讨论。他们谈到 AI 回报、招聘、代码审查、认知债和供应商锁定。
这是一组经过整理的现场观点，参与者数量有限，也没有公开抽样和量化方法。因此，它能显示管理者正在面对哪些问题，却不能证明所有公司已经形成一致结论。
技术债与认知债的差别
技术债主要存在于代码和架构中，使系统越来越难修改；认知债存在于团队的共享理解中，使人越来越难判断该如何修改。当代码生成速度远高于人的学习速度时，代码可能仍然整洁，团队对它的理解却持续下降。
过去，设计和实现过程会迫使开发者接触边界、调试失败并形成心智模型。AI 可以跳过大量实现摩擦，也同时跳过了部分学习过程。
为什么它现在变得更重要
AI 让增加功能、创建内部工具和重构代码变得便宜。原本需要讨论“构建还是购买”“是否值得长期维护”的项目，可能在一个下午就出现可运行版本。快速成果削弱了团队停下来做长期判断的动力。
生成代码越多，评审者需要理解的变更越多。最终，系统瓶颈不再是输出，而是能够识别错误假设、架构影响和业务风险的人类判断。
认知债如何表现为组织成本
| 表面现象 | 背后的认知缺口 | 组织后果 |
|---|---|---|
| 合并请求激增 | 评审者无法跟上变更上下文 | 审查排队或质量下降 |
| 功能快速上线 | 没有人掌握完整设计理由 | 维护与事故处理变慢 |
| 非工程人员可提交代码 | 边界与责任没有同步调整 | 工程师变成被动守门人 |
| 代码可随时重写 | 产品意图没有独立来源 | 系统行为逐步漂移 |
| 工具使用率上升 | 能力模型和晋升标准未更新 | 贡献评价与职业路径混乱 |
| 团队依赖统一模型 | 不了解工作流的锁定 | 迁移和中断风险集中 |
代码评审成为新的吞吐瓶颈
当实现主要由 AI 辅助完成，工程师的工作会向审查、风险判断和系统设计迁移。会议中有团队甚至把招聘面试从写代码转向代码评审，因为这更接近实际工作。
如果生成速度超过评审速度，组织只有三个选择：让变更排队、降低审查标准，或改进风险分流。单纯要求现有评审者处理更多补丁，会积累疲劳并降低判断质量。
审查劳动为何容易被低估
实现者或提出需求的人容易因功能上线获得可见成果，审查者则主要通过阻止事故创造价值。被避免的问题不会出现在产品演示中，因此审查常被视为阻碍速度。
当非工程人员也能生成合并请求时，这种激励错位会更明显。工程师可能承担验证和生产风险，却没有获得与产出者同等的认可。
把共享理解变成正式交付物
团队应要求关键系统具备可共享的事实来源，包括领域规则、不变量、接口契约、架构决策、故障模式和所有权。它们不仅服务人类，也为代理提供稳定上下文。
文档数量不是目标。真正有价值的工件应明确什么必须成立、哪些行为禁止出现，以及改变规则需要谁批准。
采用规格驱动的开发方式
会议讨论和后续 Reddit 评论都提到，用类似 RFC 的规范提炼最重要的规则与不变量。代理可以根据这些规则生成和检查代码，但规范本身必须经过人类产品与工程判断。
- 先写清用户目标、系统边界和非目标。
- 将关键业务规则写成规范性语句。
- 把可执行部分转成验收、契约和属性测试。
- 让生成代码逐项映射到规格。
- 在变更后核对代码、测试和规范是否仍一致。
不要让所有人都成为无边界提交者
AI 让产品经理或设计师完成低风险修改成为可能，这可以缩短反馈周期。但权限应与任务复杂度匹配：文案、样式和隔离良好的配置，与认证、支付和数据迁移不能采用相同流程。
适合的做法是按风险设置允许修改的区域、自动门槛和必须参与的责任人。扩大贡献范围不等于取消系统所有权。
用智能分流缓解评审压力
会议参与者提出对合并请求进行置信度或风险评分，只把真正需要判断的部分突出给人类。这一方向有潜力，但目前仍是探索，而不是已经解决的问题。
可靠分流至少要结合变更范围、模块关键度、权限与数据影响、测试证据、依赖变化和历史缺陷。模型评分不能成为自动放行高风险代码的唯一依据。
建立验证基础设施
要让人类不必逐行检查每个大补丁，组织必须于验收测试、变异测试、功能开关、可观察性、灰度发布和回滚。信任应来自多层证据，而不是对生成工具的熟悉感。
AI 功能还需要稳定评测集。模型或供应商发生变化时，团队可以重复运行同一组评测，判断质量、成本、延迟和安全是否退化。
设立技术健康责任
讨论中出现了专门“技术健康团队”的设想：一部分工程师增加功能，另一部分删除、重构和维护，并让两类工作获得同等价值认可。
是否建立独立团队取决于组织结构。更普遍的原则是技术健康必须有负责人、预算和路线图，而不能只依赖开发者在功能间隙自发清理。
更新工程师能力与评价体系
当代码生成不再稀缺，系统分解、审查判断、产品理解、风险建模和跨团队协调会更重要。招聘和晋升标准应反映这些能力，而不是继续只统计提交和功能数量。
同时要保留技术基本功。没有足够的软件工程知识，就无法判断生成代码是否正确，也无法在代理失败时接管系统。
关注评审者的认知负荷
频繁在多个复杂系统和功能之间切换，会迅速消耗注意力。组织不能把“让工程师多看一些 AI 代码”当作免费容量。
可以通过模块所有权、评审轮值、合并请求限流、安静工作时段和风险分级减少上下文切换。持续超负荷会导致倦怠，也会迫使评审者降低标准。
用结果而不是代衡量回报
AI 不能只看许可证、令牌或生成代。组织需要建立采用前基线，再观察从需求到稳定上线的周期、变更失败率、事故、返工、评审等待和维护投入。
如果提交增加但评审队列、故障和人员疲劳同步上升，产出并没有真正改善。认知债正是连接“更多代码”和“更差系统结果”的中间成本。
减少供应商与工作流锁定
认知债也可能存在于工具链。业务团队围绕单一模型产品构建大量技能和流程，却不了解底层依赖；一旦服务中断或价格变化，问题仍会回到工程团队。
可以通过内部统一接口、可迁移的提示与评测资产、清晰降级方案降低锁定。真正难迁移的往往不是模型端点，而是围绕它形成的隐性工作习惯。
结论
认知债之所以可能成为新的技术债，是因为 AI 把代码从稀缺产物变成廉价产物，却没有让系统理解、产品意图和责任判断同样廉价。未来维护能力取决于这些知识是否被团队掌握并外化。
组织需要把共享理解、规格、评审、评测和技术健康作为正式，更新权限和人才评价，并控制人类判断的负荷。生成更多代码不是终点；团队能够解释、验证和长期拥有这些代码，才是真正的工程产出。
