代码不是你写的，写的人已经离职了。

前面几篇讲的都是”你自己写的代码”。

这一篇讲一个更让人头皮发麻的场景：

老板拍拍你肩膀：”这个项目以后你负责。”

你打开文件夹，看到：几十个文件夹，几千行代码，没有文档，注释寥寥无几，最后一次提交是两年前。

写这段代码的人，已经不在公司了。

你随手点开一个文件，看了三分钟，脑子里只有三个问题：

• 它到底从哪儿开始跑的？
• 这段是干嘛的？
• 我改这一行，会不会炸掉别的地方？

这就是俗称的”祖传代码“。

好消息是：这恰恰是 AI 最能帮上忙的场景之一。

坏消息是：如果你用错方法，AI 会把你带进更深的坑。

这一篇，把接手老项目的完整打法讲清楚。

一、先纠正一个致命误区

新手接手老项目，第一反应通常是：

从第一个文件开始，一个一个读过去。

这是最慢、也最容易放弃的方式。

几千行代码，你按文件顺序读，读到第三个文件就晕了——因为你不知道这些东西之间是什么关系。

还有一种更常见的错误：

把整个项目一股脑丢给 AI，问一句”这项目是干嘛的？”

AI 会给你一段听起来很专业、但基本没用的概述。 而且大部分工具根本装不下你整个项目。

这里有一条必须刻在脑子里的原则：

AI 只知道你给它的那一屏。

它看不到你没贴的文件，看不到数据库里的数据，看不到服务器上的配置。

你贴什么，它答什么。你贴得没头没尾，它就编得有头有尾。

所以理解老项目，不是”把活丢给 AI”，而是你带路，AI 解说。

二、剥洋葱五层法：接手老项目的正确顺序

记住这个顺序：入口 → 地图 → 主线 → 数据 → 细节。

每一层没搞清楚之前，不要进下一层。

第一层：找入口——程序从哪儿开始跑

这是唯一正确的起点。

任何项目都有一个”第一行被执行的代码”。可能叫 main、app、index、server，也可能藏在某个启动脚本里。

找不到入口，后面全是瞎逛。

如果你自己找不到，就把项目根目录的文件列表贴给 AI，让它告诉你入口最可能是哪个。

文件名清单怎么拿？在项目文件夹里截个图、或者把文件名手动列一列都行。这一步不需要贴任何代码。

第二层：画地图——项目分成哪几大块

拿到入口后，别急着往下钻。

先搞清楚这个项目一共分几大块，每块干什么。

通常一个项目会有这么几类文件夹，名字千奇百怪，但角色就这几种：

• 页面 / 界面
• 业务逻辑
• 数据存取
• 工具函数
• 配置

把目录结构贴给 AI，让它帮你给每个文件夹标注”这块大概是干什么的”。

这一步的产出，应该是一张你自己能画出来的草图。画不出来，说明还没懂。

第三层：走主线——追一个完整功能，从头走到尾

这是最关键的一层。

不要试图理解所有功能。挑一个最核心的功能，把它从头到尾走一遍。

比如”用户下单”，从头到尾走一遍是这样的：

• 点击”提交订单”按钮
• 请求发到哪（哪个接口）
• 哪个函数接住了这个请求
• 它又调用了谁（下游逻辑）
• 数据最终存到哪（哪张表）
• 给用户返回了什么

走通一条主线，你对这个项目的理解就超过 60% 了。

因为其他功能，大概率是同一套路的复制。

第四层：看数据——数据从哪来，到哪去

老项目最容易搞错的地方，往往不在逻辑，而在数据。

搞清楚三件事：

• 数据存在哪（哪几张表 / 哪些文件）
• 谁在写（哪个功能在往里写）
• 谁在读（谁在依赖这份数据）

特别留意那些”被很多地方读、但只有一个地方写”的数据——那通常是整个项目的命脉，改它风险最高。

第五层：抠细节——到这一步才开始逐行读

前四层都清楚了，你再回头看具体某个函数的实现，会发现读起来轻松得多。

顺序反过来，就是灾难。

三、让 AI 解说的正确姿势：三个要求

贴代码给 AI 让它解释，大部分人只会说一句”这段代码是干嘛的？”

得到的回答通常是逐行翻译：

“这一行定义了一个变量，这一行是一个循环，循环里判断了……”

你自己都能看出来，这不叫理解。

要让 AI 说人话，加上这三个要求：

要求一：先说”它在整体里干什么”，再说”它怎么做的”

先要一句话的职责概括，再要实现细节。顺序不能反。

要求二：用大白话打比方，不要用术语堆砌

明确告诉它：”假设我完全不懂这个技术栈，请用生活化的比方解释。”

要求三：主动指出可疑和过时的地方

老代码里一定有坑。让 AI 顺便标出：哪里写法过时、哪里可能有隐患、哪里的命名和实际功能对不上。

第三点尤其值钱。因为它会引出下面这个话题——

四、老代码四大坑：AI 也会被骗

AI 读老代码时会犯的错，和人一模一样：它相信代码表面的样子。

这四个坑，你得心里有数：

坑一：名字骗人

一个函数叫 checkUser，你以为它只是”检查用户”，结果它顺手改了数据库、发了短信、还写了日志。

老项目里，函数名和实际功能对不上，是常态而不是意外。

AI 看到这个名字，也会顺着名字理解。所以永远别只看名字，要看它实际做了什么。

坑二：注释过期

注释写着”此处返回全部订单”，代码早就改成”只返回未支付订单”了。

注释是两年前的，代码是上个月的。

代码不会骗人，注释会。 两者冲突时，永远信代码。

坑三：同一段逻辑抄了好几份

老项目里经常有三四个长得几乎一样的函数，只有细微差别。

你改了其中一个，以为修好了。结果线上跑的是另一个。

所以改之前，一定要搜一下：这段逻辑是不是还有别的副本。

坑四：藏起来的调用

最阴险的一类。

你以为这个函数没人用了，准备删掉。结果它被好几处地方用着：

• 一个定时任务在调用它
• 一个配置文件里写着它的名字
• 某个几乎没人访问的老页面也在用

这类调用，AI 完全看不到——因为你没贴给它。

删之前，先全项目搜一遍这个名字。搜索框，是老项目里最重要的工具。

五、动手改之前，必做”三查”

理解只是第一步。真正的考验是：你要改它。

老项目改动的黄金法则是：

不懂全部，也能安全改动。

怎么做到？改之前，做完这三查。

查一：查引用——这东西被谁用着

要改的这个函数、这个变量、这张表，全项目搜一遍它的名字，看看有多少处在用。

• 只有 1 处用 → 风险低，可以放心改
• 有 10 处用 → 要小心了，你改的是公共部件
• 搜出来一堆，还有配置文件里的 → 先别动，去问人

这一步是纯手工的，AI 帮不了你，因为它看不到你没贴的文件。但它是最重要的一步。

查二：查影响——改了会波及什么

把这段代码 + 所有调用它的地方，一起贴给 AI，问它：

“如果我把这里改成 XX，会有哪些地方受影响？有没有我没注意到的连带后果？”

注意：必须把调用方也贴上。只贴被改的那段，AI 只能猜。

查三：查退路——出事了怎么退回去

改之前，把原始代码整段复制一份存起来，或者用版本管理工具提交一次。

老项目最怕的不是改错，是改错了还回不去。

六、边读边攒：给项目补一份说明书

这是最容易被跳过、但回报最高的一件事。

你花了两天搞懂的东西，三周后会忘掉一大半。

所以从第一天开始，就建一个文件，边读边记。不用写得多正式，记这五样就够：

1. 入口在哪个文件
2. 各文件夹分别是干什么的（一句话一个）
3. 主流程走一遍是怎样的（用箭头连起来那种）
4. 数据存在哪几个地方
5. 踩过的坑 / 反直觉的地方（这条最值钱）

第 5 条尤其重要。 那些”看着像 A，其实是 B”的地方，正是你未来最容易再次踩进去的。

下次再问 AI 任何关于这个项目的问题，都可以把这份笔记贴在前面当背景——AI 立刻从”外人”，变成”看过说明书的同事”。

回答质量的差别，大到你会后悔没早点开始记。

提示词模板盒子

以下模板可直接复制使用，方括号内替换成你自己的内容。

模板一：找入口（第一步，不贴代码）

我接手了一个别人写的老项目，现在完全不知道从哪儿开始看。

下面是这个项目根目录的文件和文件夹清单：
[粘贴文件名列表]

请你告诉我：
1. 程序的入口最可能是哪个文件？为什么？给出第一、第二可能
2. 这几个文件夹分别大概承担什么角色（一句话一个）
3. 我应该按什么顺序打开这些文件，才最快搞懂这个项目
4. 有哪些文件是我暂时可以完全不用管的

我是新手，请用大白话说，不要用架构术语。

模板二：项目地图（第二层）

这是我接手项目的目录结构：
[粘贴目录树]

请帮我做一张"项目地图"：
1. 把这些文件夹归类成几大块（例如：界面层、业务层、数据层、工具、配置）
2. 每一块用一句话说明它负责什么
3. 用文字画出这几大块之间的调用关系（谁调谁，用箭头表示）
4. 指出哪一块是这个项目的"核心"，也就是我必须先搞懂的

请输出成我能直接抄进笔记的格式。

▸ 追一条主线：把相关代码段按序贴给 AI，让它讲清执行过程、指出断层、用箭头图总结（原模板四）。 ▸ 生成项目笔记：让 AI 整理入门笔记（入口/目录/主流程/数据/坑点），直接存文件（原模板六）。

模板三：解说一段陌生代码（最常用）

下面这段代码是我接手的老项目里的，我完全不知道它在干什么。

请按以下顺序回答，不要打乱：
1. 【一句话职责】这段代码在整个系统里负责什么（一句话，说人话）
2. 【打个比方】用一个生活中的例子来类比它做的事
3. 【分段说明】把它切成几个逻辑段落，每段说明在干什么（不要逐行翻译）
4. 【输入输出】它需要什么、产出什么
5. 【依赖】它调用了哪些外部东西（其他函数、数据库、接口、配置）
6. 【可疑之处】哪里写法过时、哪里可能有隐患、哪里的命名和实际功能对不上

前提：假设我完全不熟悉这个技术栈，请避免术语堆砌。

代码如下：
[粘贴代码]

▸ 改动前影响评估：把要改代码+调用方贴给 AI，评估影响与风险，并要求它指明风险（原模板五）。

速查卡：接手老项目五句口诀

1. 剥洋葱   —— 入口 → 地图 → 主线 → 数据 → 细节，顺序不能乱
2. 走主线   —— 追通一个功能，理解度立刻过半
3. 信代码   —— 名字会骗人，注释会过期，只有代码不说谎
4. 先三查   —— 查引用、查影响、查退路，缺一不改
5. 边读边记 —— 笔记贴给 AI，它就从外人变成同事

最后

这一篇的核心，压缩成一句话：

接手老项目的本事，不是”全都读懂”，而是”没全懂也能安全动手”。

没有人能完全读懂一个几千行的祖传项目，老手也不能。

老手和新手的区别只在于：老手知道哪些必须搞清楚，哪些可以先放着。

入口必须清楚，主线必须走通，改动前必须三查。

其余的，用到再说。

下篇预告

第75篇《调试实战——一个真实 Bug 全流程》。 前面四篇拆开讲招式，下一篇串起来打一遍：还原一个真实场景——用户反馈”报表少了几条数据”，没报错、数据大、代码是别人写的，全程记录每一步贴了什么、信哪条。包括走错的两步弯路。看十篇方法论，不如走一遍。 我们下篇见。