六个月前，一位工程师在单个 sprint 中快速发布了七个功能，DORA 指标看起来完美无缺，晋升材料几乎自己写好了。但六个月后，当需要修改架构时，团队中没人能解释为什么某些组件存在或如何交互。原作者盯着自己的代码，像看着陌生人的作品。这不是科幻小说的场景，而是正在真实发生的「认知债务」问题。

什么是认知债务

《Cognitive Debt: When Velocity Exceeds Comprehension》一文提到了认知债务这个概念。简单说，当 AI 辅助开发让代码生产速度远超工程师对代码的理解速度时，就会形成这种债务。代码能正常运行，测试能通过，功能能发布，但团队对代码的内在逻辑和架构关系失去了清晰认知。这与传统的技术债务不同——技术债务会通过系统故障或维护成本显现，而认知债务隐藏在表面的运行正常之下，只存在于工程师的困惑中。

AI 生成代码的速度让工程师惊讶：一个简单的提示就能在几秒内生成数百行代码。但人类理解这些代码的速度却无法同步提升。就像用高速打印机打印出一本天书，虽然纸张堆满了桌面，但没人能读懂其中的字句。这种生产与理解的脱节，就是认知债务的核心。

为什么组织看不见债务

工程团队的绩效指标往往只关注可见的产出：故事点完成数、功能发布量、提交合并速度、代码审查 turnaround 时间。这些指标在传统开发时代很可靠，因为手动写代码时，生产过程本身就迫使工程师理解代码。但 AI 改变了这个前提：工程师可以快速生成代码，而无需深入理解。当组织用这些指标评估绩效时，认知债务就完全隐形了。

一位开发者在 Hacker News 上分享：「管理要求用 AI 生成文档，但实际仍需人工验证。时间被要求用于新功能，而非理解现有代码。」这正是问题所在——组织奖励速度，惩罚深度思考。工程师若花时间理解代码，就会在速度指标上落后；若只追求速度，认知债务就不断累积。

工程师的切身感受

「我写了一个 SaaS 项目过周末，Claude 快速实现功能，但三周后只能记得大致轮廓，找回上下文很痛苦。」一位开发者这样描述自己的经历。在手写代码时代，即使忘记细节，工程师通常还记得系统整体架构；但现在，AI 生成的代码让这种记忆变得脆弱。另一位开发者提到：「我经常不记得自己六个月前写的代码，它看起来就像别人的。」但这种感受在传统开发中同样存在，只是 AI 放大了问题。

更棘手的是代码审查环节。AI 生成的代码速度远超资深工程师的审查能力。审查者被迫在「深度审核导致速度瓶颈」和「快速通过可能遗漏问题」之间选择。大多数情况下，他们选择后者——毕竟组织压力要求快速交付。结果就是：代码被批准了，但审查者自己也不完全理解它。「团队的假设『已审查的代码是被理解的代码』不再成立。」

问题如何恶化

认知债务的累积会引发三种典型失效模式。首先，长期未修改的代码反而变得更危险。因为随着时间推移，理解它的工程师越来越少，代码变成「黑盒中的黑盒」。当系统出问题时，排查可能从十分钟变成四小时。其次，新工程师依赖 AI 生成代码，却缺乏手动实现的经验，导致未来架构能力缺失。正如一位评论者所说：「组织正在用本季度的功能交付，交易未来资深工程师的培养。」最后，当需求变化或系统故障时，团队缺乏必要的理解来应对，只能被动修复。

有意思的是，这种问题并非 AI 独有。Hacker News 上有评论指出：「传统开发中，我们也有『代码没人理解』的情况，比如收购来的遗留系统。」但 AI 加速了这个过程——过去需要几年积累的混乱，现在可能在几周内形成。一位工程师直言：「当 AI 能一键生成代码时，我们连『为什么这样写』的思考过程都省略了。」

如何应对

解决认知债务的关键在于改变工作方式。测试驱动开发被广泛认为是有效手段——通过详尽的测试覆盖边缘情况，即使不理解代码细节，也能确保功能正确。模块化设计也很重要：把系统拆成小块，每个模块只需理解局部，而非全局。一位开发者分享经验：「我让 AI 生成代码时，会要求它同步生成架构文档和设计思路，这样即使忘记细节，也能快速找回上下文。」

但现实很骨感。管理团队往往只关心速度指标，而忽视理解深度。正如原文所言：「系统优化了正确的东西，但它测量的东西已不再重要。」当组织只奖励产出量，不奖励理解力时，认知债务就不可避免。一位工程师在 Hacker News 上总结：「当 AI 能快速生成代码，而我们不再需要理解它时，工程师的角色就从『创造者』变成了『监督者』。但监督一个自己都不懂的系统，终究是场危险的游戏。」

认知债务不是技术问题，而是系统性问题。它提醒我们：在追求速度的同时，不能忘记理解是真正的生产力。否则，我们可能在代码堆成山的同时，却失去了驾驭它们的能力。