你的 AI 刚刚批量制造了技术债务。
AI 本该让你的代码库变得更好，结果却让它更糟。
自版本控制诞生以来，团队首次在加速交付的同时，也带来了更多故障。
AI 为工程团队做了三件事：更快地编写代码、更早地发现缺陷、构建当前团队无法独立完成的东西。
整个行业把全部赌注押在了第一件事上——速度，更快地输出更多代码。
但没人问过，当一个团队连自己一半的代码库都搞不明白时，将产出提升 3 倍会发生什么。
来源：https://www.faros.ai/blog/ai-acceleration-whiplash-takeaways
我以前见过这种情况。我们都见过。
20 世纪 90 年代末，企业级 Java 承诺“一次编写，到处运行”。公司把整个产品线都押注在上面。J2EE、EJB、中间件堆栈。
到 2005 年，在一款普通的企业级 Java 应用中更改一个按钮颜色，需要涉及 6 个包中的 14 个文件。Martin Fowler 称之为“企业病”。公司无法交付，无法招聘到理解系统的人，也无法重写，因为他们无法记录旧系统的功能。
修复花费了十年时间。轻量级框架、TDD、CI、敏捷。整个行业不得不围绕技术重建管理层。
AI 正在以更压缩的时间线做同样的事情。
我们让每个开发者都能每天生成数千行代码。编写提示词的开发者无法解释 AI 构建了什么。批准代码的审阅者没有真正阅读它。而继承代码的下一个开发者会将其视为黑盒——因为它就是黑盒。
我在遗留代码库和全新项目中都观察到了这一点。它们以相同的方式崩溃。
以下是我们在多个项目中观察到的 5 种失败模式。
AI 在真实代码库上的 5 种失败模式
1. AI 生成的代码量就是新的“堆人”策略。
每个 CTO 都买了 Cursor 的席位。每个董事会都问了 ROI。炒作周期在不到一年内跑完了全程。
但更多代码从来不是问题。
70% 的财富 500 强公司仍在运行超过 20 年的软件。这些代码库慢不是因为开发者打字慢，而是因为公司里没人理解代码中编码的所有业务规则。
让 AI Agent 访问那个代码库。它会生成能通过测试但违反无人记录契约的可用代码。
DORA 2026 年报告：AI 工具在干净的新项目上带来 35-40% 的效率提升。在遗留项目上，同样的工具，效率提升 10% 或更少。4 倍的差距。
瓶颈在于理解能力。AI 让情况更糟。
2. 理解债务是新的技术债务。
GitClear 分析了 6.23 亿次代码变更。自 2023 年以来，遗留重构下降了 74%。AI 工具生成新代码，而不是重用现有代码。一个通过的测试，一个关闭的工单。没有对现有系统进行整合。
Google 的 Addy Osmani 将其命名为“理解债务”：代码存在量与任何人能理解量之间的差距。
在 6 个月大的代码库中，你可以恢复。在 10 年历史、有未记录集成和业务逻辑分散在数百个文件中的单体应用中，你无法恢复。
技术债务是你知道不好的代码。理解债务是你根本无法评估的代码。AI 是第一种大规模生成第二类代码的技术。
3. 审查表演是新的橡皮图章。
在 Faros AI 的 22,000 名开发者数据集中，零审查合并的 PR 增加了 31%。中位审查时间增加了 5 倍，因为审查者无法跟上代码量。
更多输出，更少质量控制，没有人有权减缓速度。在 AI 出现之前，我们已经见过这种组织模式无数次了。现在它以机器速度运行。
Anthropic 发现，使用 AI 进行被动委托的开发者理解测试得分低于 40%。主动探究：65% 以上。同样的工具。变量在于人。
大多数团队使用 AI 来避免思考。这在生产环境中会反噬你。
4. 理解系统的人最没有动力将其喂给 AI。
我与一家 PE 支持的软件公司（年收入约 1500 万美元）的工程负责人聊过。他的团队在内部尝试了 Claude。他的原话是：“它做了一堆蠢事。”
他持怀疑态度是对的。
福特让经验丰富的工程师离开，却没有将他们的知识输入质量系统。三年后，付出了数十亿美元的保修成本，他们重新雇用了 350 名资深工程师。这些工程师重新训练了 AI，重建了质量流程。福特现在 16 年来首次在 JD Power 2026 年初始质量研究中排名第一。
他们的硬件工程副总裁：他们以为摄入设计需求就能产出高质量产品。但并没有。领域知识必须先到位。
掌握机构知识的人已经目睹了上一轮“效率”举措。他们知道流程文档化后会发生什么。中世纪行会出于同样的原因保密他们的方法。
5. 最需要 AI 的代码库恰恰是 AI 工作最差的地方。
中型市场 SaaS 平台、医疗系统、物流后端、金融服务产品——由多年前离开的开发者构建。
这些公司有付费客户、真实收入、值得保留的业务逻辑。它们有最大的表面积供 AI 加速。
今天销售的每个 AI 编码工具都假设代码库是干净的，架构是模块化的，开发者能给 Agent 足够的上下文。这个假设在 10 年历史的单体应用、未记录集成和无人记得写过的业务规则面前崩溃了。
根据 Gartner 的数据，74% 的 AI 举措无法超越试点阶段。模型没问题。代码库还没准备好。
真正能修复问题的方法
我们在一个真实项目中验证了这一点。两名工程师在一个遗留物流平台上工作。6 个月内合并了 330 个 PR。约 90% 的代码由 AI 生成。客户称他们为表现最好的团队。他们获得了两次酌情奖金。
这个结果来自准备，而不是更好的模型。在 AI 接触一行代码之前，做了三件事。
在提示之前先文档化。 我们称之为“第零步”。在任何 AI Agent 接触遗留代码库之前，扫描现有代码，生成 AI 可读的文档，让系统对工具变得可理解。Agent 无法推理它看不到的东西。福特的转型就是从这里开始的。他们带回了理解系统的人，记录了他们所知道的内容，然后才重新训练 AI。
定义区域。 80/20/0。80% 的样板代码（CRUD、测试、配置、文档）：AI 自由生成。20% 的业务逻辑和集成：副驾驶模式，AI 起草，工程师重写。0% 的认证、支付、加密、架构决策：AI 不得触碰。这种纪律防止了理解债务的累积。
在扩展之前先测量。 每次提交的成本、模型使用模式、AI 代码占比、每个团队的 DORA 指标。AI 之前建立基线，之后测量。没有这些数据，你就是在盲目飞行，重蹈 Faros 数据集中 22,000 名开发者经历的加速鞭打。
未来走向
微软投入了 25 亿美元。亚马逊投入了 10 亿美元。Anthropic 筹集了 15 亿美元。OpenAI 筹集了 40 亿美元。都瞄准同一个问题：让 AI 在已经存在的公司内部发挥作用。
市场聚焦于新项目，因为演示效果更好。最大的工程影响将来自那些代码库最丑陋、产品最老、管道在任何人听说过 LLM 之前就建立的公司。
瓶颈在于模型底层的工程系统。
P.S. 这就是我们在 Limestone Digital 做的事情。 我们将 AI 原生工程团队嵌入现有代码库。第零步、区域纪律、测量基础设施。如果你的 AI 试点在遗留代码库上卡住了，私信我。
