大模型应用开发学习路线
这条路线写给已经会编程，想做大模型应用开发、RAG 或 Agent 工程的人。它不要求你先把所有知识学完。不同背景的学习节奏差别很大，所以这里不按月份排任务，只看五个能检查的结果：
- 我准备投什么岗位？
- 我能不能把一条最小的模型应用链路跑通？
- 我要把 RAG、Agent 还是 Deep Research 做成主项目？
- 我有没有评测、失败案例和技术取舍证明这是自己做的？
- 我能不能脱离稿子说清项目，并接住后续追问？
学习路线不是一张课程表。每一步都有完成标准：留下能运行的代码、评测或失败记录，就继续；还说不清，就先回去补。
先看全局：五个关口，不按月份
| 关口 | 要解决的问题 | 过关证据 | 下一步 |
|---|---|---|---|
| ① 定岗位和主线 | 知道自己学什么，也知道哪些暂时不学 | 一类目标岗位、一组 JD、一条主项目线 | 补最小闭环 |
| ② 跑通最小闭环 | 从请求、模型或工具调用走到结果和错误处理 | 可运行代码、数据流说明、一个失败记录 | 选项目线 |
| ③ 做深一条项目线 | 不停在调 API 和跑 Demo | 完整链路、评测集、对照实验、bad case | 整理项目证据 |
| ④ 补齐项目证据 | 证明这是你做的，而不是背的 | 职责、基线、选型、结果、代价和边界 | 练项目追问 |
| ⑤ 练到能接追问 | 把“会做”变成“现场讲得清” | 30 秒主线、90 秒展开、连续追问与事实自检 | 投递和持续复盘 |
不要用别人的学习时长判断自己是否落后。开发经验、每周投入、目标岗位和项目难度都会改变节奏。这里只看产出，不给统一倒计时。
关口①：先定岗位和主线
先找一组真正想投的 JD，不要先拿一张技术全景图逐项学。相同的“大模型应用开发”，实际工作重心可能完全不同。
| JD 经常出现的任务 | 建议主线 | 你要优先证明什么 |
|---|---|---|
| 企业知识库、检索问答、文档处理、搜索与推荐 | RAG | 解析、切分、召回、重排、引用、评测和上线约束 |
| 工具调用、业务自动化、工作流、记忆、多智能体 | Agent | 状态、工具契约、停止条件、幂等、安全和可观测 |
| 长任务调研、多源证据、报告生成、Agent 训练与评估 | Deep Research | 任务拆解、证据校验、长任务恢复、成本和评估治理 |
如果 JD 同时写了知识库、Agent 和评测，也不代表你要同时做三个项目。选一条作为主项目，其他能力只补到可以和主链路协作。
不确定应用岗和算法岗怎么选，先看应用开发岗与算法岗的区别；不知道 JD 里的词对应什么工作，看大模型岗位画像和JD 逐条解读。
过关标准： 你能说清一类目标岗位的主要产出，选定一条主项目线，并列出现阶段明确不学的内容。
关口②：跑通一个最小闭环
这一步不是为了写简历，而是建立工程手感。你需要亲手看见请求怎样进入模型，模型怎样返回结构化结果或工具调用，失败又怎样被记录和收口。
建议按这个顺序完成：
- 掌握 Token、上下文、幻觉、Embedding 和模型调用的基本语义，可以从LLM 应用基础概念开始。
- 亲手调用一次大模型 API，处理超时、错误和配置，不把密钥写进代码。
- 用Function Calling跑通“模型给出调用意图，代码执行工具，结果再回填”的完整循环。
- 按主线选一个最小练习：最小 RAG或最小 Agent。
- 故意制造一次失败：检索不到、工具超时、参数不合法或循环不停，再根据日志找到失败位置。
不要在这一步追求复杂页面或大而全的框架。最小闭环只需要留下三样东西：一份能复现的运行说明，一张从请求到结果的数据流，一条真实的失败与修复记录。
过关标准： 不看代码也能画出数据流；结果错了时，知道应该先检查模型输入、检索、工具、状态还是返回结果。
关口③：做深一条项目线
项目阶段最容易犯的错，是 RAG、Agent 和 Deep Research 都跑了一遍，但每一条都没有评测、失败和技术取舍。正确做法是选一条主线，沿完整工程链路向下做。
RAG 主线：适合知识库、检索与企业问答
按“解析与入库 → 切分与索引 → 检索与重排 → 生成与对话 → 评测与上线”推进。
- 系统学习：RAG 智能问答系统
- 项目验收：25 道 RAG 项目面试题
- 必须留下的证据：资料样本、解析质量检查、评测集构造、基线、对照实验、bad case、引用与权限边界
不要把“用了向量库”当项目亮点。面试官更关心的是：资料为什么检索不到，你怎样定义正确，改了哪一层，哪些问题仍然解决不了。
Agent 主线：适合工具调用、业务自动化与状态工作流
按“架构与规划 → 工作流与状态 → 工具与安全 → 记忆与存储 → 多智能体与评估”推进。
- 入门实操：AI 编程与 Agent 实操
- 项目验收：25 道 Agent 项目面试题
- 必须留下的证据：工具 Schema、状态转移、停止条件、超时与重试决策、副作用防护、Trace 和任务级评估
如果一个流程可以由代码明确写死，就不要为了显得智能而交给 Agent。一个合格的 Agent 项目，不仅能成功调工具，还要在工具失败、重复执行或权限不足时安全收口。
Deep Research 主线：适合多源调研、长任务与研究报告
建议先有基本检索和 Agent 循环经验，再进入“问题边界与研究闭环 → 长任务执行 → 研究工具与稳定性 → 数据构造与训练 → 上线成本与评估”。
- 系统学习：Deep Research Agent 项目
- 项目验收：25 道 Deep Research 项目面试题
- 必须留下的证据：任务契约、拆解与重规划、证据链、停止条件、长任务恢复、成本归因与结果过程双层评估
这条线不是“多搜几次”。它要证明系统知道什么任务值得长程研究，会核验证据，也会在证据不足或成本失控之前停下。
过关标准： 三条线里选一条作为主项目，能画完整数据流，有自己构造的评测或验收方法，有至少一个失败案例，也说得清方案的适用边界。
关口④：把项目变成可核验的证据
项目能跑不等于能写进简历。每一句项目描述都在向面试官作出承诺：这是我负责的，我知道为什么这样做，我有证据说明结果。
在写简历前，先为主项目整理一份“项目材料清单”：
- 问题和边界： 服务谁，处理什么资料或任务，什么明确不做。
- 个人职责： 哪些模块由你设计和实现，哪些来自框架、平台或其他人。
- 完整链路： 从请求进入到最终结果，数据、状态和工具怎样流转。
- 基线和定义： 改之前是什么方案，评估指标怎样定义，数据怎样构造。
- 实验与因果： 改了什么，为什么改，是否有对照或消融，不把多个变量的结果算到一个模块头上。
- 失败复盘： 什么样的输入仍然失败，怎样发现，怎样降级或收口。
- 工程代价： 方案对延迟、成本、并发、权限和维护复杂度有什么影响。
- 适用边界： 数据扩大、权限收紧或预算减少时，哪些设计需要重做。
没有真实数字，就写评测方法、待验证项和当前边界；不要把别人的召回率、延迟或成本写成自己的成果。可以先看项目深挖方法和大模型简历怎么写，再用简历项目预演检查哪句最容易被追穿。
过关标准： 随机指向简历里一句项目描述，你都能找到对应的架构、代码、评测、日志、失败或设计记录；没做过的部分会明确说没做过。
关口⑤：练到能说，也能接追问
不要等项目“完美”才开始练面试。做完一个模块，就可以用对应项目题反向检查设计缺口。
一次有效练习包含五个动作：
- 先不看答案，用 30 秒说出结论和边界。
- 再用 60 到 90 秒展开完整链路，不堆名词。
- 回答连续追问：为什么这样选，怎样证明，哪里失败，如何上线。
- 把答案换成自己的项目事实，删掉所有无法核验的数字和经历。
- 回到项目补评测、日志或 bad case，而不是只把口述稿写得更漂亮。
按主项目进入 RAG 25 题、Agent 25 题或Deep Research 25 题。项目题负责检查完整工程讲法；某个单点知识不会，再回851 道基础题库定向补课。
然后用面经与教学复原检查面试节奏，用按公司查真题收窄目标范围。题库不需要从第一道背到最后一道，你只需要让每一句简历主张都有对应的证据和追问准备。
过关标准： 从本项目主线随机抽题，能先独立给出短答案，再用自己的项目事实展开；被问到没有做过的部分时，会明确区分已实现、设计方案和待验证项。
三种常见起点，怎么调整
| 你的起点 | 可以快进的部分 | 必须补的缺口 | 先看什么 |
|---|---|---|---|
| Java、Go、Python 后端 | 接口、数据库、并发、日志和服务稳定性 | 模型失败模式、检索评测、工具调用和结果不确定性 | 后端经验怎样迁移 |
| 研究生或有算法基础 | 模型概念、论文和评估原理 | API 工程、状态、异常处理、权限、部署和真实失败复盘 | 研究生怎样规划 |
| 只有课程 Demo 或调 API 经历 | 不需要再做一个同类 Demo | 一条主项目的评测、bad case、安全、成本和上线边界 | 项目怎样从 Demo 做深 |
如果 Python 代码还影响你完成最小闭环，再定向补Python 和大模型工程栈。不要在没有明确项目需求时，单独花很长时间“把 Python 学完”。
什么时候可以开始投递
不需要等到所有模块都完美。但在把主项目写进简历前，至少应该能回答下面这组问题：
- 我投的是什么岗位，这个项目和 JD 哪些要求直接对应？
- 项目解决什么问题，为什么不用更简单的方法？
- 我具体负责什么，哪些能用代码、日志、图或评测证明？
- 基线和评估方法是什么，最后结果怎样解读？
- 哪类输入仍然失败，系统怎样发现、降级或拒答？
- 延迟、成本、权限或数据规模变化时，方案要怎样调整？
这些问题如果大部分还只能用名词回答，先回到项目补证据。如果能用真实项目事实说清，就可以边投递、边根据面试反馈修正路线。
最容易走偏的五种方式
- 把 75 道项目题从头背到尾。 它们应该是项目验收表，不是新的八股文。
- 三条项目线都做，每条只跑通。 一条有评测和失败复盘的主项目，比三个浅 Demo 更能支撑追问。
- 追框架名称，不记数据和状态怎样流动。 框架会换，输入、状态、工具、失败和评估不会消失。
- 复用别人的指标和故事。 没有做过的数字宁可不写，否则一层追问就会被拆穿。
- 只写口述稿，不回项目补缺口。 面试练习暴露的空白，最终应该变成评测、日志、设计记录或明确边界。
下一步从哪里开始
| 你现在的状态 | 直接做什么 |
|---|---|
| 还没确定应用岗还是算法岗 | 先看应用岗与算法岗的区别 |
| 会编程，但没有调过模型和工具 | 从亲手调用大模型 API开始 |
| 已经跑过 RAG 或 Agent Demo | 从RAG、Agent 与 Deep Research 三条项目线选一条做深 |
| 项目能跑，但不知道怎样证明效果 | 回到对应的 25 道项目题，从评测、bad case 和上线边界开始补 |
| 项目写进简历，但一被追问就卡住 | 用简历项目预演找出证据最弱的那句话 |
| 面试已经开始 | 结合面经与教学复原和按公司查题定向复盘 |
如果你能独立完成前四个关口，就先自学走。真正卡在项目设计、评测、简历证据或面试反馈时，再判断是否需要更系统的指导，也可以先看自学和训练营分别解决什么问题。