第1节：开篇，怎么用CC改好一个老项目

现在我们用Codex从写新功能、改 bug、加测试但很多人改着改着会发现效果跟自己预期差距挺大。同样的工具、同样在改老代码有人改出来又稳又快有人改完一上线就出问题。有人觉得 AI 真的能帮到自己有人觉得 AI 比自己还能添乱同一个工具用法不同结果差得很远。Comprehension Debt理解债指代码产出速度和团队真正理解代码的速度之间的差距。Verification Debt验证债42% 的代码是 AI 辅助生成的但 96% 的开发者不完全信任 AI 的输出只有 48% 每次都 review。Brownfield Tax棕地税AI 在老项目里的失效方式具体表现是 context 超过 40% 后模型质量下降跨 session AI 记不住昨天的决策AI 不知道老代码为什么这样写所以提的“现代方案”跟现有架构不兼容。Codex - AI实习生AI 在老项目里不是“更强的开发者”更像一个“上下文缺失的实习生”这个实习生技术能力可能比你强。代码写得比你快算法比你熟开源项目看得比你多。但他有一个致命短板他对你公司这个项目一无所知。面对这样一个实习生你不会直接把复杂任务扔给他自己搞你会先带他熟悉项目、告诉他哪些地方不能动、给他明确的小任务、让他做完给你看、你 review 完才让他继续。老项目改造用 AI真正的瓶颈不是 AI 能做什么是你能传递多少。围绕“传递”这件事我摸出来的打法分三层。理解层 你和 AI 一起读懂这个项目。用 SonarQube 扫债务地图、用 git log 看历史脉络、用 Seam 识别方法找改造关键入口。让 AI 用 AGENT.md 装上下文、用 SKILL.md 装专项技能、用 MCP 扩展感知能力。人的理解和 AI 的理解是两件事都要做。约束层看见不等于听话。今天你让 AI 加个字段它顺手重构整个类明天让它修个 bug它把项目编码风格全改了。所以你得告诉它哪些地方不能动、哪些规矩必须守、哪些设计模式这个项目不用。约束写清楚了AI 的产出自然可控。验证层AI 改完跑通了测试你 review 觉得没问题但你测试覆盖本来就不全、review 本来就看不到所有路径。你没法靠“感觉没问题”判断一个改动安不安全。所以改造之前要把现有行为锁住改造之后用基准对照。不是靠信心是靠基准。三层加起来让 AI 看见、让 AI 听话、让 AI 可信。这三层做到位AI 能完成 80% 到 90% 的工作。剩下 10% 到 20%质量把关、流程正确、最终决策这些必须由你来做。