Simon Willison在2026年8月12日的博客里，引用了软件工程师Florian Herrengt的一篇文章。文章讲了一个虚构场景：一个bug被AI改了四次都没修好，团队去问写这段代码的人，对方说"我也不知道，我问问Claude"。原文点名的AI是Claude，而那个怎么都修不好bug的工具叫Fable，是作者虚构出来的名字，现实中并不存在。
这条引用没有配真实公司、真实事故或真实数据。它是一篇评论文章里的假设场景，不是调查报道。但它戳中的问题是真的：团队把"理解系统"这件事外包给AI之后，代码写得快，出故障时可能没人说得清问题出在哪。
场景里到底发生了什么
原文描述的项目层层叠叠，服务套服务。没人能完整讲清数据从哪来、流向哪去。
两个工程师坐在屏幕前，看着AI噼里啪啦生成一堵文字墙。谁都不知道这些话对不对，但AI表现得很自信。
这段读起来像段子，指向的却不是"AI写错代码"这种老问题。老问题有解——重新审查、重新测试就行。这个场景里没有代码错误，只有一群人集体说不清楚系统在干什么。
认知债务和技术债务，不是一回事
技术圈说了很多年"技术债"：代码潦草、架构没优化，但只要有人记得当年为什么这么写、坑埋在哪，债是可以还的。
AI辅助编程带来的是另一种债。代码可能能跑、逻辑复杂，但没人能讲清数据流向和系统边界。故障发生那一刻，账本本身就没了，无处可查。
| 对比项 | 传统技术债 | AI认知债务 |
|---|---|---|
| 代码质量 | 潦草、未优化 | 可能能跑、逻辑复杂 |
| 设计取舍 | 有人记得 | 没人说得清 |
| 故障时能做什么 | 找到人问、查文档 | 连数据流向都讲不清 |
| 偿还方式 | 重构、补文档 | 需要重新理解整套系统，成本更高 |
这也是为什么"AI正在消灭软件工程中产阶层"目前只能算趋势判断，没有就业数据支持。能支撑的结论更窄：AI辅助编程正在拉开团队之间的能力差距——有测试、有审查、有架构约束的团队，和无监督依赖AI生成代码的团队，风险完全不在一个量级。
谁该在意，接下来看什么
这条隐忧对不同人的分量不一样。
普通开发者靠AI快速交付功能，短期效率提升是真实的。但代码合并之后，谁来负责讲清楚它为什么这么写，这个问题不会自动解决。
工程负责人要担的是另一头责任：稳定性、预算、事故问责。评估AI编程工具时，光看代码产量不够，至少要多盯几个指标——故障恢复要多久、代码审查能不能审出真问题、系统边界谁能讲清楚、团队知识有没有留下来。这几项跟不上，生成速度越快，系统失控来得可能也越快。
接下来值得观察的，是有没有团队真的因为一次说不清楚的故障，付出实际代价——修复时间拉长、被迫回头补文档、甚至推倒重写。目前这类案例还没有公开数据支撑，只是Herrengt这篇文章提出的一种警示性推演，值不值得当真，取决于你团队里AI生成的代码，有没有测试和审查兜底。