开篇词｜怎么用 Claude Code 改好一个跑了几年的老项目？

Robert

讲述：张浩AI版大小：10.91M时长：09:32
你好，我是 Robert。
在正式开始之前，先聊聊我做这门课的初衷。
Claude Code 出来这两年，大家都在用它改自己手上的代码。从写新功能、改 bug、加测试，到现在很多工程师也开始拿它动那个跑了几年的老系统。
但很多人改着改着会发现，效果跟自己预期差距挺大。同样的工具、同样在改老代码，有人改出来又稳又快，有人改完一上线就出问题。有人觉得 AI 真的能帮到自己，有人觉得 AI 比自己还能添乱；有人在做第三个任务时已经摸出门道，有人改了三个月还是心里没底。同一个工具，用法不同，结果差得很远。
差的不是 AI，差的是用法。这件事是有体系的，只是大部分人还没把这个体系用起来。
这门课要做的事，就是把我这两年改老项目踩过的坑、用过的提示词、跑过的工作流、以及沉淀出来的一套打法，系统讲一遍。学完之后，你用 Claude Code 或者其他主流 AI 编程工具，改一个跑了几年的老项目，就能用得对、用得稳、用得越来越省力。
大家都在踩同一种坑你应该也有类似的体感。这两年业界其实已经在认真讨论“AI 改造老项目”这件事，踩过坑的不只是你和我。
Google 的 Addy Osmani 给出了一个词叫 Comprehension Debt（理解债），指代码产出速度和团队真正理解代码的速度之间的差距。AI 帮你写代码越多，这个差距越大。Anthropic 自己做了一项 52 人的对照实验，AI 辅助开发者在代码理解测试上比对照组低 17%，debugging 方面差距最大。
Sonar 的开发者调研给出了另一组数据：42% 的代码是 AI 辅助生成的，但 96% 的开发者不完全信任 AI 的输出，只有 48% 每次都 review。结果是普遍存在的 Verification Debt（验证债），改完跑通了测试、看着 diff 也没问题，到生产环境才发现坏了。
Florida International University 的研究给 AI 在老项目里的失效方式起了个名字叫 Brownfield Tax（棕地税），具体表现是 context 超过 40% 后模型质量下降，跨 session AI 记不住昨天的决策，AI 不知道老代码为什么这样写所以提的“现代方案”跟现有架构不兼容。
这些不是论文里的概念，是我们日常都遇到过的事。Claude Code 写新代码用得越多，你越能感觉到改老代码这件事有点不一样。
我自己也踩过的一个典型坑业界讨论的现象，我自己也踩过，而且踩得还挺典型。
半年多前我带着 Claude Code 去改一个公司内部老系统，跑了五六年、业务逻辑盘根错节那种。我把任务丢给 Claude Code：加一个字段，调整几处相关业务逻辑。它给的方案专业、代码干净、测试也写了。我 review 一遍没发现问题，上线。
那天晚上监控告警来了。
炸的不是我让它改的部分，是另一个看似毫不相关的接口。翻代码才发现，那个字段在六年前被一个早已下线的对接方用过，当时有个隐性约定。AI 不知道这件事，代码里也没写，只有当年做这个对接的同事知道，他半年前就离职了。
我一边回滚一边想，问题不在 AI，在我。不是它不够聪明，是我把它当成“能自动理解项目的开发者”了。但它不可能自动理解，那些代码之外的历史、隐性约定、踩过的坑，我不告诉它，它就是瞎的。
那次之后我换了做法。动手之前先花时间告诉它项目是什么、哪些地方有雷、哪些接口不能碰。一开始觉得这是额外成本，跑通几次发现：这些时间不是成本，是投资。前期传递得越充分，后面它帮我做的事越多越稳。
后来我摸出来的几件事踩过几次类似的坑之后，我慢慢摸出来一件事。AI 在老项目里不是“更强的开发者”，更像一个“上下文缺失的实习生”。
这个实习生技术能力可能比你强。代码写得比你快，算法比你熟，开源项目看得比你多。但他有一个致命短板，他对你公司这个项目一无所知。面对这样一个实习生，你不会直接把复杂任务扔给他自己搞，你会先带他熟悉项目、告诉他哪些地方不能动、给他明确的小任务、让他做完给你看、你 review 完才让他继续。
视角立住之后，这件事的瓶颈就清楚了。老项目改造用 AI，真正的瓶颈不是 AI 能做什么，是你能传递多少。围绕“传递”这件事，我摸出来的打法分三层。
理解层：你和 AI 一起读懂这个项目。用 SonarQube 扫债务地图、用 git log 看历史脉络、用 Seam 识别方法找改造关键入口。让 AI 用 CLAUDE.md 装上下文、用 SKILL.md 装专项技能、用 MCP 扩展感知能力。人的理解和 AI 的理解，是两件事，都要做。
约束层：看见不等于听话。今天你让 AI 加个字段，它顺手重构整个类；明天让它修个 bug，它把项目编码风格全改了。所以你得告诉它哪些地方不能动、哪些规矩必须守、哪些设计模式这个项目不用。约束写清楚了，AI 的产出自然可控。
验证层：AI 改完跑通了测试，你 review 觉得没问题，但你测试覆盖本来就不全、review 本来就看不到所有路径。你没法靠“感觉没问题”判断一个改动安不安全。所以改造之前要把现有行为锁住，改造之后用基准对照。不是靠信心，是靠基准。
三层加起来，让 AI 看见、让 AI 听话、让 AI 可信。这三层做到位，AI 能完成 80% 到 90% 的工作。剩下 10% 到 20%，质量把关、流程正确、最终决策这些，必须由你来做。
业界其实也在分别讨论这三层，有人讲 Strangler Fig、有人讲 Characterization Tests、有人讲 SDD Brownfield、有人讲 Harness Engineering。每一块都有价值，但拼起来是散的，中文社区几乎没人系统讲过。这门课要做的就是把这些碎片拼成一个完整的、可执行的方法论。
这门课你要走的路讲清楚方法论，接下来讲整门课怎么设计。
这门课不教 Claude Code 的全部功能，而是带你跑通“老项目改造”这件事。但这件事其实不只一种形式，所以我们会沿着老项目改造的三种形式展开，难度依次递进。
第一种形式：公司内的老项目。代码是公司的、bug 是公司的、方向是业务定的。这是大多数工程师日常面对的场景。整门课前五部分（01-23 讲）是以 Spring AI 这个真实开源项目作为镜子，带你完整走过“摸项目 → 建护栏 → 拆需求 → 跑通改造”全流程。镜子是别人的代码，但学到的方法论是套到你公司那个老系统上用的。
第二种形式：基于开源做需求。代码不是你的，但用法是你的。运维做内部巡检平台先看 Prometheus 生态，后端接工作流引擎先看 Temporal，算法做 RAG 先看 LlamaIndex。先看看开源里有没有现成的，再基于它二次开发，这是工程师的标准动作。第六部分（24-29 讲）演示从一句话需求到完整跑通的全流程，基于开源 Hermes Agent 控制平面做二次开发，产出一个 7×24 不间断运行的真实自动化测试系统。
第三种形式：挑战开源。代码不是你的，bug 也不是你的，你做贡献，让自己的名字进入别人的项目。这同样是老项目改造，只是改造的对象是别人的老项目。第七部分（30-32 讲）带你基于一个真实活跃的 Rust 开源项目，跑通两个 PR + 一个 issue，收获一个真实可点击验证的开源 contributor 身份。简历上多这一行，在 AI 时代尤其值钱。
最后，我们还会针对整门课做总结复盘，让你真的把这门课带回你自己的项目和工作里。
三种形式背后是同一套方法论：读懂陌生代码、找到改造点、用 Claude Code 高效产出、保住质量。整门课所有的动作都在训练这套姿势，我们把它放进三种不同的项目载体上去强化，最终内化为你自己的专业能力。
推满载大卡车的飞轮最后，在课程正式开始之前，我想告诉你一件事。
即便方法论摸熟了，老项目改造永远不可能像新项目那样丝滑。任何一次老项目改造，都像推动一辆满载的大卡车。冷启动的时候特别慢，你要花时间让 AI 读懂上下文、建立约束、锁定基准，感觉进展缓慢。
但只要推动起来，飞轮就开始转了。CLAUDE.md 积累得越完整，AI 对项目的理解越深；SKILL.md 写得越好，改造的标准化程度越高；验收体系越成熟，你敢放手让 AI 做的事就越多。推到第三个任务的时候，你会发现自己已经不再需要手把手带 AI。
冷启动过去了，飞轮越转越快、越转越轻松，这就是这门课要帮你建立的节奏。
跟着课程一讲一讲走，不要跳。前面五部分把方法论建起来，中间两部分把方法论铺到不同形式上，最后一部分把方法论带回你自己的项目。每一讲都有具体提示词、具体工作流、具体 review 重点，你可以照着跑。
老项目改造这件事做久了你会发现，它不容易，但也不像很多人说的那样难到碰不得。难在它有历史、有包袱、有你看不见的约束，但只要你按课程中的这套体系来，AI 就会越做越熟。
改得好老项目的人，是真的在长能力。愿你通过这门课完善 AI 能力体系，沉淀实战判断力，从容领跑 AI 开发新时代！
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
深入了解
翻译
英语
中文简体
法语
德语
日语
韩语
俄语
西班牙语
解释
总结
2026-05-07给文章提建议
仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《Claude Code 企业级老项目改造实战》，新⼈⾸单¥59
立即购买
登录后留言
精选留言

由作者筛选后的优质留言将会公开显示，欢迎踊跃留言。
收起评论