拿到一个陌生的代码仓库，第一反应不是兴奋而是头皮发麻——这大概是多数开发者都有过的体验。目录里几十个文件，读源码吧不知道从哪看起，看文档吧文档比代码还长。这两年我一直在折腾一套 AI 学项目的流程，从最初“把 README 丢给AI让它总结”这种粗糙操作，慢慢打磨成一套完整路径：先让模型帮你搭骨架，再顺着调用链啃源码，最后跑起来复现并调试。这篇文章就是这套流程的完整记录，包括每一步的提问格式、我在实际使用中踩过的坑，以及哪些环节AI是真提效、哪些环节它只能帮你到这。适用对象很明确：刚接触开源项目无从下手的读者、进公司第一周要接手老项目的开发者、以及带学生做课题但不想一句句讲源码的导师。
1. 动手之前，先想清楚“学项目”到底要学什么
我在带新人时发现一个现象：大多数人拿到项目就直接打开代码文件开始从头读，读两三小时就放弃，因为完全没有目标和路径。用AI之前，第一件事不是打开对话框，而是明确你学这个项目图的是什么。
1.1 三层目标决定你怎么用AI
学一个项目通常是三个层次，每层对应的学习深度、时间和AI介入方式完全不同：
第一层是“能用”。把项目跑起来，知道它的输入输出、主要参数、常见用法，不求甚解。这时候AI的核心价值是当说明书解读器，帮你把冗长的README、官方文档压缩成一份“快速上手清单”。
第二层是“能改”。遇到具体需求能找到改动点，改完不影响原功能。这个阶段AI的价值从“摘要”变成“讲解”，你需要让模型带你读关键代码段、理解调用关系与数据流，而不是只看文档。
第三层是“能造”。理解项目的架构设计、模块划分、核心权衡，能把它抽象成可复用的方法论，在新场景里复现核心思路。到这个层级的项目往往至少精读了几个核心模块，AI在这里更多是“辩论对手”而非“讲解员”，你可以问它“为什么这里不用另一种方案”，让它列出取舍逻辑，再自己验证。
我自己的习惯是：接手一个项目后先花十分钟冷静判断自己需要到哪一层。只想跑个Demo，就绝不浪费两小时让AI给你逐行讲代码；而如果是核心模块要二次开发，那AI给你的概括性总结只能当热身。
1.2 AI真正高效的是哪几个环节
AI学项目的流程里，AI不是什么都会，它也有明显的强项和弱项。认清边界才能不浪费时间：
信息检索与摘要，AI是绝对强项。读文档、对比版本、总结模块用途，它的效率远超人工。一段五千字项目的README，人工读要十五分钟，AI压缩成五条要点的质量，基本能覆盖90%的信息。
断点阅读与概念解释，AI是好辅助。当你卡在某个回调函数看不懂时，把代码贴给它，让它解释上下文，比反复搜函数定义快得多。它还能在你没问的情况下指出你漏掉的关键逻辑，相当于一个随叫随到的陪读。
调试与试错，AI只给假设，验证靠自己。遇到报错时AI能根据经验给出方向，但它看不到你的真实运行环境，经常给出“看起来没问题”的答案。我的原则是：让AI当参谋，但最终一切以你的实际运行结果为准，别偷懒。
理解这个边界后，你就能明白整个流程的节奏：前期计划自己定，中后期阅读靠AI，最终验证自己来。
2. 第一阶段：先让AI给项目照一遍“CT”
这个阶段的目标是在动手读源码之前，先压缩项目信息量。很多人拿到项目就开始看代码，这是效率最低的路径。正确顺序是：文档 — 目录 — 依赖，让AI逐层帮你建立整体图景，再决定要不要深入细节。
2.1 把README和文档榨干：给AI的信息整理模板
我见过太多次“把README直接复制给AI然后问这个项目怎么用”的操作，结果AI给出泛泛而谈的废话。问题在于没有给模型设置输出规范。我现在用的是固定模板，实测效果稳定：
你是一名资深技术文档分析师。这是某项目的README和文档片段： [粘贴文档内容] 请按以下要求整理： 1. 用一句话说明项目核心功能 2. 列出项目运行所需的完整环境（语言版本、依赖服务、硬件要求） 3. 梳理项目的主要使用流程，按顺序编号 4. 标注项目中容易踩坑的隐含条件（如特定版本冲突、数据格式要求） 5. 如果文档里有不清楚的地方，明确写出“文档未说明”而不是猜测关键在第五点：要求AI区分“文档说了”和“文档没说”。AI有个很烦的毛病，就是会脑补信息。你如果不约束它，它会把没写的东西说得信誓旦旦。设定这个约束之后，你得到的摘要才具备可信度。
提取完摘要后，还需要让AI帮你做一件事：对照摘要检查你是否真的理解了。我会接着问“请用提问的方式测试我对项目的理解，像考官一样出五道题”。让AI出题、你作答、AI批改，这一轮下来，你对项目的整体认知会扎实很多。
2.2 让AI带你“逛”目录结构
目录结构是最被低估的学习资源。一个工程结构合理的项目，光看目录就能读懂七成设计思路。
