Your AI Team Is Building Debt Your CFO Can’t See. Here’s the Ledger.

你的 AI 团队正在积累 CFO 看不见的债务，这是你的账目清单。

Your AI Team Is Building Debt Your CFO Can’t See. Here’s the Ledger. The same tools driving your team’s productivity are generating an entirely new class of technical debt. Here’s what it costs — and what you can do about it. 你的 AI 团队正在积累 CFO 看不见的债务，这是你的账目清单。那些推动团队生产力的工具，同时也正在产生一种全新的技术债务。以下是这些债务的代价，以及你可以采取的应对措施。

Your AI pilot worked. Velocity is up. Ticket counts are down. The team is shipping faster than they have in years. The business case for expansion is obvious. And somewhere in the code your team just generated, a debt clock is running that your current metrics can’t see. 你的 AI 试点项目成功了。开发速度提升了，工单数量减少了。团队交付产品的速度达到了多年来的最高水平。扩张的商业理由显而易见。然而，在你团队刚刚生成的代码中，某个地方正运行着一个债务时钟，而你目前的指标却无法察觉。

Technical debt has a new face. It accumulates faster than the original, compounds across categories, and doesn’t show up in your quality dashboard until something breaks. Executives who understand what’s accumulating won’t be blindsided when it comes due. The ones who don’t will be surprised — twice: once by the incident, and again by the cleanup cost. 技术债务有了新的面孔。它比传统债务积累得更快，在不同类别间产生复合效应，并且在系统崩溃之前，它不会出现在你的质量仪表盘上。那些了解债务积累情况的高管，在债务到期时不会被打个措手不及。而那些不了解情况的人则会感到两次惊讶：第一次是因为事故发生，第二次是因为高昂的清理成本。

The Original Technical Debt, in Thirty Seconds

三十秒了解原始技术债务

Ward Cunningham coined the term in 1992 [1]. The metaphor: taking coding shortcuts to ship fast is like taking a financial loan. You gain velocity now, pay maintenance interest later, and eventually pay down the principal through refactoring. The debt was in the code itself — messy logic, missing documentation, duplicated functions. A developer could read the code and find it. A team could plan to eliminate it. That framework worked because the debt was legible. You could see it. You could measure it. You could schedule it away. Ward Cunningham 在 1992 年提出了这个术语 [1]。这个比喻是这样的：为了快速交付而采取代码捷径，就像申请金融贷款。你现在获得了速度，以后要支付维护利息，最终通过重构来偿还本金。债务存在于代码本身——混乱的逻辑、缺失的文档、重复的函数。开发人员可以阅读代码并找到它，团队可以计划消除它。那个框架之所以有效，是因为债务是“可读”的。你可以看到它，可以衡量它，也可以将其排入日程表并消除它。

AI breaks that. The new debt isn’t legible. It doesn’t live in code you can read. It lives in your team’s cognition, in your agents’ memory states, and in the interaction complexity between dozens of AI processes running simultaneously. And it accumulates in six distinct categories that require six distinct responses. AI 打破了这一点。新的债务是“不可读”的。它不驻留在你可以阅读的代码中，而是存在于你团队的认知中、AI 代理的内存状态中，以及数十个同时运行的 AI 进程之间的交互复杂性中。它在六个不同的类别中积累，需要六种不同的应对方案。

Six Flavors of AI-Era Technical Debt

AI 时代技术债务的六种表现

1. Cognitive Debt: Your Team Is Losing Their Mental Map 1. 认知债务：你的团队正在丢失思维导图

The MIT Media Lab monitored participants’ brain activity while they wrote with AI assistance. The result: AI-assisted users showed the weakest neural engagement of any group. When they switched back to working without AI, they underperformed — including struggling to recall their own recently-generated work [2]. 麻省理工学院媒体实验室监测了参与者在 AI 辅助下写作时的脑部活动。结果显示：AI 辅助用户的神经参与度是所有组别中最低的。当他们切换回没有 AI 的工作模式时，表现不佳——甚至难以回忆起自己刚刚生成的工作内容 [2]。

For executives, the translation is this: teams that rely heavily on AI to generate code (or other work where the thinking was outsourced to the AI) are building work they don’t fully understand. This isn’t a skill or motivation problem. It’s structural. The brain disengages when the machine does the thinking. Lack of code review is deceptively easy—and AI-based code review may or (I and my colleagues would argue) may NOT be good enough. 对于高管来说，这意味着：过度依赖 AI 生成代码（或将思考外包给 AI 的其他工作）的团队，正在构建他们并不完全理解的工作成果。这不是技能或动力问题，而是结构性问题。当机器负责思考时，大脑就会“离线”。缺乏代码审查变得极其容易——而基于 AI 的代码审查可能（我和我的同事认为）并不足够可靠。

The business consequence arrives slowly, then suddenly. Velocity looks like 2-3x — until something breaks in code nobody fully understands, or a feature needs to change in a module the team is now afraid to touch. The productivity gain becomes a productivity trap. Amazon’s internal “deep dive” review of a “trend of incidents” with “high blast radius” attributed to “Gen-AI assisted changes” — which led to a new policy requiring senior engineer sign-off on all AI-assisted code before production deployment — is an early example of this consequence appearing at scale [3]. 商业后果会缓慢显现，然后突然爆发。开发速度看起来提升了 2-3 倍——直到代码中无人完全理解的部分出现故障，或者团队现在不敢触碰的模块需要修改功能。生产力提升变成了生产力陷阱。亚马逊内部对“生成式 AI 辅助变更”导致的“高影响范围”事故趋势进行了深入审查，并出台了新政策，要求所有 AI 辅助代码在生产部署前必须经过高级工程师签字，这是该后果在大规模应用中显现的早期案例 [3]。

2. Intent Debt: The “Why” Is Evaporating 2. 意图债务：“为什么”正在消失

When a human engineer makes an architectural decision, they usually know why. When an AI generates code, the reasoning behind every choice goes undocumented — because nobody wrote it down and the AI doesn’t keep notes unless explicitly instructed to do so. Future developers (or future AI agents) trying to modify that code have to guess. 当人类工程师做出架构决策时，他们通常知道原因。当 AI 生成代码时，每个选择背后的逻辑都没有记录——因为没有人写下来，而且除非明确指示，否则 AI 不会做笔记。未来的开发人员（或未来的 AI 代理）在尝试修改这些代码时只能靠猜。

When AI agents guess, they guess statistically: the most plausible answer from their training, not the most accurate answer for your specific system (here my drumbeat: “plausibility does not equal correctness”). If your system has unusual constraints, rejected conventions, or specific business rules that aren’t obvious from the code, the agent rediscovers the “obvious” approach your team already rejected — and nobody remembers why it was rejected. Intent debt is the gap between what the code does and why it does it [4]. AI development widens that gap faster than any development methodology that came before it. 当 AI 代理进行猜测时，它们是基于统计学进行猜测：即从训练数据中得出最“合理”的答案，而不是针对你特定系统最“准确”的答案（我再次强调：“合理性不等于正确性”）。如果你的系统有不同寻常的约束、被拒绝的惯例或代码中不明显的特定业务规则，AI 代理会重新发现你团队已经拒绝过的“显而易见”的方法——而没人记得当初为什么要拒绝它。意图债务就是代码“做了什么”与“为什么这么做”之间的鸿沟 [4]。AI 开发拉大这一鸿沟的速度，超过了以往任何开发方法论。

3. Agentic Debt: Your Agents Are Running Up Bills You Can’t See 3. 代理债务：你的 AI 代理正在产生你看不见的账单

This is the new operational risk that most AI governance frameworks haven’t addressed yet. AI agents — software that takes autonomous action on your behalf — can accumulate three kinds of problem without any visible failure signal: 这是大多数 AI 治理框架尚未解决的全新运营风险。AI 代理（代表你采取自主行动的软件）可以在没有任何明显故障信号的情况下积累三种问题：

• Prompt Drift: Updating one agent’s configuration inadvertently degrades related agents that share elements of that configuration. The coupling is invisible. You changed something. Something else broke. The connection isn’t obvious. 提示词漂移： 更新一个代理的配置会无意中削弱共享该配置元素的关联代理。这种耦合是隐形的。你改动了某处，其他地方却坏了，而这种关联并不明显。
• State Rot: An agent designed to maintain memory over time gradually fills that memory with stale, irrelevant data. It was built to remember. Nobody told it what to forget. Its past corrupts its present. 状态腐烂： 一个旨在长期保持记忆的代理，会逐渐用陈旧、无关的数据填满内存。它被设计用来记忆，但没人告诉它该忘记什么。它的过去正在腐蚀它的现在。
• Zombie Loops: An agent stuck attempting an impossible task keeps consuming API credits without failing visibly. It just runs. The invoice arrives. The work doesn’t. 僵尸循环： 一个陷入尝试不可能任务的代理，在没有明显故障的情况下持续消耗 API 额度。它只是在运行。账单来了，但工作没完成。

Unlike the technical debt Cunningham described, agentic debt doesn’t fail suddenly. It degrades: 95% of expected output becomes 85%, then 70%, while the system continues to run and look superficially healthy. By the time the pattern is visible, significant cost and quality loss have already accumulated [5]. 与 Cunningham 描述的技术债务不同，代理债务不会突然崩溃。它会逐渐退化：预期产出的 95% 变成 85%，然后是 70%，而系统仍在运行，表面上看起来很健康。当这种模式显现时，巨大的成本和质量损失已经积累完毕 [5]。

4. Orchestration Debt: Networks of Agents Are Networks of Risk 4. 编排债务：代理网络即风险网络

If your team is running more than a handful of AI agents, this is already accumulating. You might also think about it as “complexity debt”. Two agents interacting have one relationship. Ten agents have 45 potential interaction pathways. Twenty have 190. Those interactions produce emergent behaviors that weren’t designed, that don’t appear in any specification, and that resist debugging because they depend on the sequence and content of prior agent interactions. This is the multi-agent version of microservices debt: a system too complex to… 如果你的团队运行的 AI 代理超过少数几个，这种债务就已经在积累了。你也可以将其视为“复杂性债务”。两个代理交互只有一种关系。十个代理有 45 种潜在的交互路径。二十个则有 190 种。这些交互会产生非设计预期的涌现行为，它们不会出现在任何规范中，且难以调试，因为它们依赖于先前代理交互的顺序和内容。这是微服务债务的多代理版本：一个过于复杂而无法……