AI 来之前，我们是怎么接手一个老项目的？
这个问题听起来有点傻。你可能会想，接手老项目不就是读代码、跑起来、改 bug、上线嘛。
用 Codex 用得不顺，根源就在这里：他们在 AI 时代跳过了那些看似傻但其实关键的步骤，结果传递给 AI 的上下文是空的，改完之后自己也没法判断对不对 。
场景介入
某天 leader 走过来，指着一个 GitLab 仓库，"你接一下这个项目，老王昨天离职了"
这个项目部门里几个核心业务都靠它跑，公司早期几位资深工程师好多年前写的，后来换了几拨维护者，也没人完整梳理过技术资料。
打开 README，几行部署命令加一张架构图，看两遍感觉像懂了又没懂。每个类都很长，散落着各种注释。去问 leader，文档没有，历史背景老王应该清楚，但他入职新公司了，估计不方便联系。
场景扩展
这个项目可能是每次发版都要提前拉全部门开评审会的核心服务。老项目最难的不是代码本身，是代码之外的那些东西 。
是那些"不要删"的注释，是那些早已离职、再也问不到的前辈，是那些每次你想动它、都不敢动的隐性约定，是那些六年前的设计决策，当时可能是对的，今天看起来像炸药......
这些东西代码里没写，也不会写。因为写它们的人觉得"这都是常识"。离职时也不会留下来，因为谁也说不清。这才是老项目改造的真实起点 。
面对这样的场景，人会怎么做？
假设你是那个接手项目的人，不急着写代码，而是先想办法了解它，通常会这么走。
1.找人聊
把项目里看到的疑点列一个清单，去问身边还在这个项目周边工作过的同事。问产品，问隔壁组的架构师，问运维。有些问题问不到答案，标记"未知"，先搁置。
2.把资料都翻找一遍
README、仓库里的 docs 目录、wiki、Confluence 里的旧设计文档、企微里的历史群聊记录、jira 里相关的 epic。不是要全部搞懂，是要把手头所有线索都扫一遍，有个整体的感觉。
3.Clone项目，浏览代码
不是从第一行读到最后一行，是看结构。有哪些模块？哪些是核心？哪些是工具类？哪些看起来是很久没人动过的老代码？哪些看起来是最近还在改的？脑子里画一张粗糙的地图。
4.搭建环境，把项目跑起来
这一步出奇的难。依赖 MySQL 版本有要求、Redis 的 key 格式需要特定配置、有一个对接的内部服务需要 VPN，可能要折腾一整天。但跑起来的那一刻心里就有底了，能用 debug 模式断点、能看到真实的数据流向、能观察请求进来之后的完整链路。
5.用curl访问几个核心接口
不是为了测业务，是为了验证项目确实跑通了、能看到输入输出、能复现问题。接口通了之后，才敢说"初步了解这个项目了"。
6.带疑问点深挖代码
前面梳理时留下的那些"未知"标记，现在带着具体的问题去翻代码。某个业务分支是什么时候加的？谁在调用这段逻辑？有没有类似功能的调用链路？这时候代码读起来不一样了，每一处都带着上下文在读。
7.画出核心链路
几张粗糙的手绘图。主流程从入口到出口、核心数据表之间的关系、依赖的外部服务。画完之后，整个项目才算在脑子里立起来。
8.动手处理任务
改的时候也不是一口气改完。先小改一处、跑通、看结果、确认没有副作用，再改下一处。每一步都带着前面建立的那份地图。
9.验收
curl 接口看主流程没有被破坏、跑了几个相关的业务场景、找人 review。然后才敢说"这个改造做完了"。
对AI来看，传统流程有什么区别
AI 没有改变这条链路，但它把每一步里人和 AI 的分工打乱了 。
在传统的流程里，这九步全部是人在做。有些步骤慢（比如画核心链路）、有些步骤繁琐（比如梳理接口）、有些步骤需要耐心（比如读一个陌生的业务分支），但都是人的事。
Claude Code 进来以后，每一步都在被重新分配。读 README 这种事，AI 一次能给你出个漂亮的摘要。画架构图这种事，AI 可以扫完整个仓库给你出一份 Mermaid。梳理接口清单这种事，AI 比你手动翻快十倍。
但也有一些事 AI 帮不上。比如"某某对接方是谁"，代码里没写的事 AI 说不出来。比如"这段逻辑删了会出什么事"，AI 只能猜，不能承担责任。比如"最终这个改造要不要上线"，这是人的决策，不是 AI 的。
所以用 Codex 用得好的工程师，其实就是在这条九步链路上，把人和 AI 的分工搞清楚的工程师 。
他们知道哪一步让 AI 冲在前面、哪一步自己必须守住、哪一步需要和 AI 来回确认。这种分工不是 AI 天生就会的，是经过一段磨合才建立起来的。
为什么前6步容易跳出
具体表现是这样
他们第一件事就是打开 Codex，贴一段代码问"这个项目是做什么的"。Codex当然能回答，但回答得浅。然后他们拿着这个浅层的认知，直接让 Codex 开始改代码。改完后跑不通，或者跑通了但没达到预期，或者看起来达到了但上线就炸了。然后他们回过头来怪 Codex："这玩意真没法用。"
但问题不在 Codex ，问题在于没有前六步打底，AI 就是瞎的 。它不知道这个项目有什么坑、哪段代码动不得、哪些历史约定存在。这些东西你不告诉它，它就永远看不见。
反过来，如果你扎扎实实把前六步做完，把了解到的东西整理成文档，然后把这些文档交给 Codex，它的表现会完全不同。它会基于你提供的上下文做判断，它给的方案会贴合这个项目的实际情况，它改的代码会知道哪些地方要绕开。
冷启动慢，飞轮转起来快
**冷启动永远慢，**你要先找人聊、翻资料、读代码、搭环境、跑起来、摸接口、画链路。这一通操作下来可能要一两天甚至一两周。这段时间你感觉什么都没产出，心里容易焦虑。
这种焦虑很正常，但你要知道，这不是浪费时间，是投资 。做完冷启动之后，你会进入一个飞轮。
你对项目的理解越深，后续的改造越轻松。你积累的文档越厚，下次打开代码时的心智成本越低。你和 AI 协作时提供的上下文越准，AI 给的方案越贴合。
第一个改造任务可能要磨两三天，第二个可能一天，第三个几小时就搞定。老项目改造的核心心法就一句话：熬过冷启动 。熬过去了，后面全是复利。
总结
老项目改造的真实链路 。九个步骤，从了解到改造，从头到尾。AI 没有推翻这条链路，只是改变了每一步里人和 AI 的分工。
70% 的时间花在了解上，30% 的时间才是动手 。这个比例和直觉相反，但它决定了你和 AI 协作能不能稳。
记住那个心态：熬过冷启动 。老项目改造不存在一口吃成胖子，但只要熬过起步阶段，后面越来越轻松。