第3讲｜如何用 AI 快速读懂陌生项目的标准流程

专栏：AI 编程提效实战 30 讲
标签：AI编程 / 项目分析 / 提效流程 / 工作流

先说结论

陌生项目最浪费时间的，不是代码难，而是你一上来就想“直接改”。

很多人接到旧项目、临时支援需求、线上问题排查时，第一反应是先搜关键词、点来点去、边看边猜。结果半小时过去，入口没找准，调用链没理清，AI 也只能跟着你一起猜。

真正高效的做法不是让 AI 直接解释整个仓库，而是给它一个固定的读项目流程，让它先帮你完成三件事：

1. 找入口

2. 理链路

3. 收敛问题

这样你才会更快知道应该看哪里、不该看哪里，以及下一轮要问 AI 什么。

上面这张图就是我现在常用的标准流程。先别急着写代码，先把项目读懂的动作做对，后面的需求拆解、改动方案和 Bug 定位都会顺很多。

为什么很多人读项目越读越乱

你可能也有过这类场景：

• 刚进一个新仓库，目录一大堆，不知道从哪里下手

• 想让 AI 帮你解释代码，但自己给不出有效上下文

• 搜到一堆方法名和类名，却不知道哪个是真正的业务入口

• 看了 Controller，又跳到 Service，再跳到 Mapper，最后还是没搞清主链路

这类低效不是因为你不会读代码，而是因为动作顺序错了。

读陌生项目最容易犯的错有三个：

1. 先看实现细节，再找业务入口

2. 先问 AI“这项目是干什么的”，却不给目录和关键代码

3. 一次想看懂全部模块，没有先限定范围

AI 在这里不是替你“自动理解项目”，而是帮你做结构化分析。前提是你先把问题切成它能处理的几步。

我现在固定使用的 4 步流程

第 1 步：先圈定本次要解决的业务问题

不要一上来就让 AI 看整个项目。

正确顺序是先确定这次到底要解决什么问题，例如：

• 补一个订单取消原因字段

• 定位某个接口为什么偶发超时

• 看懂登录鉴权链路

• 接手一个支付回调相关需求

如果你连当前业务问题都没有圈定，AI 只能给你一堆泛化总结，实际没法落地。

你可以直接这样问：

你现在是我的项目分析助手。
当前目标：我需要快速搞清订单取消相关链路，后续要补一个“取消原因记录”能力。
我会分批提供项目目录、接口代码和核心服务代码。
请你始终围绕“订单取消链路”分析，不要泛泛介绍整个项目。
输出时重点说明：入口、状态流转、依赖模块、可能的风险点。

这一句的作用，是先把 AI 的注意力钉在具体问题上。

第 2 步：先看目录和模块分层，不急着读细节代码

很多人会直接把一大段代码扔给 AI。其实更高效的第一批材料，往往是：

• 根目录结构

• 目标模块目录

• controller / service / repository 的类名列表

• 配置文件和路由信息

因为这一轮的目标不是读实现，而是判断：

1. 项目按什么方式分层

2. 目标业务大概落在哪个模块

3. 主入口大概率在哪里

可以直接套这个模板：

我会给你一个后端项目的目录结构和关键类名。
请先分析：
1. 这个项目的主要分层
2. 与订单取消最相关的模块
3. 我下一步应该优先读哪几个类
输出格式：
1. 三句话总结
2. 关键模块清单
3. 建议阅读顺序

这一步的目标，不是“懂业务”，而是先获得导航图。

第 3 步：围绕入口类，追一条最短主链路

拿到目录导航后，不要继续发散。

你现在要做的是只追一条链路，例如：

Controller -> Service -> Domain Logic -> Repository -> 外部依赖

只要这条最短主链路走通，你就已经比“随机乱看”强很多。

这一轮你可以把关键代码分批给 AI，然后要求它只回答 4 个问题：

1. 这一层做了什么

2. 下一跳去哪

3. 哪些条件分支最关键

4. 哪些地方值得我亲自再核对

示例提示词：

下面是订单取消接口相关的 Controller 和 Service 代码。
请只围绕这条链路分析：
1. 外部请求从哪里进入
2. 关键参数在哪里校验
3. 状态变更在哪一层发生
4. 数据最终写到哪里
如果遇到你无法确认的地方，请明确标注“不确定”，不要自行补全业务假设。

很多人会忽略最后一句，但这句很重要。读项目时，AI 最危险的不是“没回答”，而是“很自信地猜错了”。

第 4 步：让 AI 帮你收敛成可行动清单

如果前三步做完，通常你已经知道这条链路的大概结构了。

这时不要直接让 AI 生成代码，而是先让它输出一份可行动清单，比如：

• 我已经确认的事实

• 还没确认但高度相关的点

• 接下来要补看的类和配置

• 如果要改代码，最可能影响的模块

可以直接这样问：

基于前面的目录和代码分析，请帮我输出一份“继续接手订单取消需求”的行动清单。
要求包含：
1. 已确认的调用链
2. 仍需补看的模块
3. 改动前必须核对的边界条件
4. 如果下一步要让 AI 参与写代码，提示词里必须补充哪些信息

这一步的价值，在于把“我大概看懂了”变成“我接下来具体做什么”。

一个可直接复用的读项目提示词模板

如果你经常接手新项目，可以直接保存下面这个模板：

你现在是我的项目接手分析助手。
当前目标：快速读懂 {业务问题/需求点} 对应的项目链路，不急着写代码。

我会分批提供：
1. 项目目录结构
2. 关键接口/服务代码
3. 相关日志或报错信息

你的任务：
1. 先判断主要模块分层
2. 帮我找最可能的业务入口
3. 只追一条最短主链路
4. 标出关键条件分支、状态流转和外部依赖
5. 对无法确认的地方明确标注“不确定”

输出格式：
1. 三句话总结当前理解
2. 主链路拆解
3. 仍需补充的信息
4. 我下一步建议查看的文件顺序

这个模板最适合的场景，不是“彻底分析整个系统”，而是快速接手一个具体问题。

我建议你再加两个限制条件

如果你希望结果更稳，我建议额外补两条限制：

限制 1：每轮只分析一批材料

不要一次贴 20 个文件。

原因很简单：

• 你自己也很难校验

• AI 更容易混淆不同模块

• 输出会越来越泛

更好的方式是每轮只给一类材料：

• 第一轮给目录

• 第二轮给入口类

• 第三轮给核心服务

• 第四轮给依赖模块或日志

限制 2：强制 AI 标注“不确定项”

这是读陌生项目时最实用的一条。

很多时候，真正重要的不是 AI 已经解释出来的内容，而是它告诉你：

• 这里缺少上下文

• 这里无法判断真实业务含义

• 这里需要继续看配置或数据库表结构

只要它肯老老实实承认不确定，结果就比“看起来完整但掺了猜测”的回答靠谱得多。

一套更接近真实工作的使用顺序

如果你今天就要接手一个陌生项目，可以按这个顺序走：

1. 先明确本次需求或问题范围

2. 把目录结构丢给 AI，先拿导航图

3. 找到入口类后，只追一条主链路

4. 让 AI 输出已确认事实和未确认问题

5. 你再决定是继续读代码，还是进入需求拆解/方案设计阶段

这套流程最大的价值不是“更快读完整个项目”，而是更快进入有效状态。

因为接手陌生项目时，最怕的不是慢，而是一直在错误路径上消耗时间。

写在最后

如果你觉得 AI 帮你读项目总是不稳定，先别急着换工具。

先检查一件事：

你有没有把“读项目”这件事，拆成固定步骤和固定问法。

当你先让 AI 帮你找入口、理链路、收敛问题，而不是直接让它“解释整个项目”，它才更像一个靠谱的协作助手。

下一讲，我会继续写：如何让 AI 生成更可靠的重构方案。

如果你正在做旧项目维护、接手新模块或排查复杂链路，这一讲建议先收藏，后面会反复用到。