很多人第一次把 Cursor、Claude Code、Codex 接到旧项目里，都会问一句：“帮我解释一下这个项目。”这句话看起来很自然，但实际效果通常不稳定：AI 会从 README 讲到目录结构，再泛泛总结一遍技术栈，听起来完整，却很难指导你下一步改哪里、怎么改、哪里不能碰。
AI 编程代码解释真正有价值的地方，不是把代码翻译成中文，而是帮你建立一张可操作的项目地图：入口在哪里，数据怎么流动，哪些模块风险最高，哪些地方改动前必须验证。尤其是接手旧项目、排查线上问题、准备小改动时，这套提问方式比让 AI “讲讲代码”更可靠。
这篇文章属于 AI编程工具专题 和 普通人AI实践专题。如果你已经看过 AI编程提示词模板 和 AI编程上下文管理，本文可以作为“读懂旧项目”的专门补充。
先不要让 AI 解释整个项目
旧项目最容易让 AI 读偏，因为文件多、历史包袱多、命名不统一。你一上来要求解释整个项目，AI 往往会根据少量入口文件做概括，忽略真正的业务路径。
更好的做法是先限定范围：
- 我要理解某个页面或接口，不是整个仓库；
- 我要准备修改某个功能，不是做技术选型报告；
- 我要知道调用链和风险点，不是要一段漂亮总结；
- 我要能验证理解是否正确，而不是只听 AI 解释。
比如你要改登录页，就不要问“解释这个项目”。可以改成：“请从登录页面入口开始，追踪表单提交、接口调用、状态更新、错误提示和权限跳转，最后列出修改登录逻辑前必须检查的文件。”
第一步：让 AI 找入口，而不是猜架构
代码解释的第一步是找入口。前端项目可能是路由、页面组件、表单组件；后端项目可能是路由文件、控制器、服务层、队列任务；脚本项目可能是 CLI 命令或定时任务。
请先不要修改代码。
目标：我想理解 [功能名称] 的实现。
请帮我找出这个功能的入口文件，并说明：
- 用户或系统从哪里触发它；
- 入口调用了哪些关键函数或组件；
- 哪些文件只是展示层，哪些文件包含业务逻辑；
- 你还需要继续阅读哪些文件才能确认调用链。这条指令的重点是“先找入口”。如果 AI 连入口都没找准，后面的解释再流畅也没用。Cursor 更适合边看文件边问局部问题，Claude Code 和 Codex 更适合让它们跨文件追踪调用链，但前提都是把入口锁住。
第二步：把调用链画成可检查清单
旧项目最难的不是单个函数，而是函数之间怎么连起来。让 AI 解释调用链时，不要只要自然语言总结，最好让它输出一张清单。
请按真实调用顺序列出这个功能的调用链：
1. 入口文件和入口函数
2. 关键参数从哪里来
3. 中间经过哪些模块
4. 数据写入或读取哪里
5. 返回结果在哪里被使用
6. 错误处理在哪里发生
每一步请附上文件路径和函数名，不确定的地方明确标注“需要确认”。这类输出更容易人工复核。你可以逐项打开文件确认，而不是被一段概括性解释带着走。尤其是用 Codex 做仓库级阅读时，要求它标注“不确定”，比要求它给出绝对结论更重要。
第三步：单独追踪数据流
很多 Bug 的根因并不在界面，而在数据流。比如字段名在前端叫 status，接口里叫 state，数据库里又叫 task_status；或者一个默认值在三处被处理，最后线上表现和你预期不一致。
读旧项目时，可以让 AI 专门追踪一个字段。
请只追踪字段 [字段名]：
- 它最早在哪里生成；
- 中途有没有转换、默认值、格式化或校验；
- 最终保存到哪里或展示在哪里；
- 哪些地方可能因为字段为空、类型变化、命名不一致而出错。这一步很适合用在表单、订单、权限、发布状态、标签、价格、用户角色等高风险字段上。它能帮你从“看懂页面”进入“看懂业务”。
第四步：让 AI 找风险点，而不是立刻给方案
很多人一读懂一点代码，就让 AI 直接“帮我优化”。这一步很危险，因为旧项目常常有历史兼容、线上数据、权限边界和隐含业务规则。更稳的顺序是先找风险，再决定是否修改。
基于刚才的调用链，请列出修改这个功能的风险点：
- 哪些文件改动后影响范围最大；
- 哪些逻辑可能被多个页面复用；
- 哪些输入需要兼容旧数据；
- 哪些地方缺少测试或日志；
- 如果只做最小修改，建议优先改哪里。这和站内之前写的 AI编程安全审查、AI编程验收清单 是同一套思路：AI 可以帮你提速，但你要先让它暴露风险，而不是让它凭直觉重构。
第五步：把解释变成修改前检查表
代码解释的最终目标不是“我听懂了”，而是“我知道下一步怎么安全行动”。所以每次让 AI 解释完旧项目，最好让它生成一份修改前检查表。
- 本次目标相关入口是否确认；
- 调用链是否覆盖前端、后端、数据层或外部接口；
- 关键字段是否追踪过来源和去向；
- 复用模块是否确认影响范围；
- 现有测试、日志、回滚方式是否清楚；
- 哪些问题仍然只是推断，不能当作事实。
如果检查表里还有太多“不确定”，就不要急着让 AI 改代码。先补上下文、运行项目、查日志、读测试，或者把问题缩小到一个更明确的文件范围。
三类常用提问模板
接手陌生模块
我准备接手 [模块名]，请先阅读相关文件，输出：
- 模块解决什么业务问题；
- 入口、核心逻辑、数据来源分别在哪里；
- 最容易出错的 5 个位置；
- 新人修改前应该先跑哪些检查。准备修 Bug
问题现象是：[描述现象]。
请先根据代码解释可能的触发路径，不要直接修改。
请列出：
- 可能涉及的文件；
- 需要验证的假设；
- 最小复现路径；
- 如果要修，最小改动点可能在哪里。准备做小功能
我想给 [功能] 增加 [小改动]。
请先解释现有实现，并判断：
- 应该在哪一层加逻辑；
- 是否会影响旧数据或旧页面；
- 有没有现成组件或工具函数可复用；
- 完成后应该怎么验收。老达点评：会提问的人，才真正用上 AI 编程工具
AI 编程工具最容易被低估的一点，是“读代码”。很多人只把它当作写代码机器，结果越改越乱；但如果你先让它帮你找入口、追调用链、理数据流、标风险点，再决定是否动手，旧项目会清晰很多。
对普通开发者、站长和内容型项目维护者来说，这种能力尤其重要。你不一定每天写大功能，但经常要接手历史代码、修一个小问题、看懂别人留下的脚本。把 AI 编程代码解释问对了，后面的修改、测试和交接都会轻很多。
