接手没文档的祖传代码?先问AI这3个问题

同事离职，你接手他的项目：三万行代码，没文档，注释停在两年前，下周产品就要你改需求。硬着头皮从第一个文件读起，读了一周，只记住几个类名，改一处报三处，越看越不敢动。如果你正在这种祖传代码里泡着，今天这套方法能把你的一周压成三天。

先纠正一个认识：很多人把 AI 当成能一口吞下整个项目的神，把代码库整个压缩包扔过去问"这项目是干嘛的"。现在的模型一次吃不下几万行，硬塞只会得到一段车轱辘话。正确的用法是把 AI 当向导：你问路，它带路，路还得你自己走。读老代码的顺序也不是从第一行读到最后，而是先摸结构、再跟主流程、最后看改动点。AI 的价值，是把"找到该看哪里"的时间从几天压到几分钟。

第一问：这个项目的入口在哪，模块怎么分

把目录树、pom.xml 或 package.json、application.yml 这几个文件喂给 AI，问它：入口在哪，一共几个模块，谁依赖谁。这些配置文件信息密度极高，几百行就能让 AI 画出整个项目的骨架。让它输出一张模块依赖图，你十分钟后就知道：这是个前后端不分离的老系统，核心逻辑全挤在 service 目录里，common 目录谁都在用、动不得。第一天把这层搞清，后面不再迷路。

第二问：一个请求从进来到落库，经过哪些类

别问"这个项目怎么运作"，太大了。挑一条最核心的业务链，比如"用户下单"，把 Controller 那个文件先给它，再顺着它点到的类一个个贴过去，问它：这条调用链上每一步做了什么。让它按顺序输出：接收参数、校验、查库存、算价格、写订单、发消息，再生成一张时序图。看文字容易晕，看图一眼就懂。第二天跟通两三条主链路，这个系统在你脑子里就立体了。

第三问：如果我改这里，会影响哪里

到了真正要动手的时候，这一问最值钱。把你要改的方法连同调用它的上层代码贴给 AI，问：我改这个方法的返回值，会波及哪些地方。它会替你翻遍你没想到的调用方——凌晨两点还亮着的 bug，多半就藏在你以为没人用的那个分支里。改之前问一遍，等于让 AI 替你做了一次影响面排查。注意，它的答案要当线索不当结论，每个点到的位置都亲手点进去确认。

三天路线图

第一天只做第一问，产出一张模块图加一页说明，能向别人讲清"这系统分几块"就算过关。第二天跟主流程，挑两条最挣钱的业务链，产出时序图。第三天做改动演练：拉个分支，把下周要改的需求先在本地改一版，让 AI 帮你查影响面，再跑通编译。三天下来，你对这个项目的把握，超过当初写它的人。

三个坑，踩了白干

一，AI 会一本正经地编造不存在的类名和方法名，尤其是老项目的自定义框架，它没见过就靠猜。它说"调用了 UserService"你就得去搜，搜不到就是编的。二，一次贴太多文件，重点被稀释，一次给三五个文件、问一个具体问题，效果最好。三，公司项目里有账号密钥、客户数据的代码，别往公网模型里贴，先脱敏，这条没有商量余地。

工具和成本

免费的方案完全够用：DeepSeek、豆包、通义的网页版，贴文件提问都行；VS Code 里装 CodeGeeX 插件，选中代码直接问，免费。愿意花钱提效的，Cursor 免费版每月有限额，Pro 版二十美元一个月，能自动索引整个仓库，第二问、第三问的体验好一档。学校服务器有闲置显卡的，Ollama 加 Qwen Coder 本地部署，代码不出校门，零成本。

说句实话：AI 读不懂祖传代码里那些"你不懂业务就别动"的暗坑，它能给你地图，不能替你踩雷。三天读懂的真意思是：三天知道哪能改、哪别碰、改了怎么验证。真正的理解只来自你自己动手——改一次，跑一遍，看一次结果。AI 把你从"迷路"里捞出来，路还是要你走，但至少，方向对了。

这里是科研创新社，每天一篇，写编程、AI 和科研里那些说明书不告诉你的实操细节。关注我，明天见。

你接手过最离谱的祖传代码是什么样的？变量名叫 a1a2a3 的，还是两千行一个方法的？评论区聊聊，点赞最高的我写成选题。

下期预告：明天回到科研创作——实验数据散在十几个 Excel 里，导师要最新版你翻半天？四条规矩把科研数据管起来。