第2节:老项目改造真实路径
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 协作能不能稳。记住那个心态熬过冷启动。老项目改造不存在一口吃成胖子但只要熬过起步阶段后面越来越轻松。