12 周学习路线

时间安排

每天约 2 小时：30 分钟学习、75 分钟实现或实验、15 分钟记录。每周约 14 小时，其中一次学习时段用于复盘和补欠账，不额外堆积任务。

每周只抓一个主要目标。超时时缩小功能范围；不要通过取消验证来赶进度。

周计划

前两周除了认识概念，还要用现成工具完成小实验；第 3 周开始把能力映射到真实业务。参见能力主线与业务拆解。工具体验与自行开发互相补充，不把所有能力都从零实现作为入门条件。

周次	学习主题	实践任务	验收证据
1	应用类型、业务任务、AI 辅助开发	拆解三个 AI 功能；用 AI 完成现有项目的一项小改动	三张拆解卡、改动说明、验证记录
2	RAG / Workflow / Agent / AI Coding 的关系与工具体验	再拆解三个功能；用现成工具做 Workflow、RAG 和只读 Agent 小实验	六张卡、三项小实验记录，能说明固定步骤与自主选择的区别
3	用户需求、业务拆解、现状基准	选题；尽量访谈两位目标用户；收集 20 个样例；逐步标注输入、规则、例外与责任人	一页需求说明、业务拆解表、现状记录
4	Prompt / Context / Workflow / Agent 设计	用四张设计卡做最小验证；理解模型调用、结构化输出和校验；建立不使用 AI 的对照方法	设计卡、同批样例对比、失败清单、是否继续的决定
5	React 交互、Node.js 接入、流式输出	打通输入、请求、结果和编辑流程	可完整操作的第一版
6	上下文、取消、超时、保存	完善多轮修改和失败恢复；固定第一版范围	录屏或操作记录、关键场景测试
7	外部知识与检索	按项目需要接入文档；若不需 RAG，则做独立小实验	检索案例、来源引用、无答案案例
8	评测、检索与生成错误分离	样例扩展到约 50 条，保留独立验收集	基线、调整版对比和错误分析
9	Workflow、工具调用与授权	接一个真实或模拟工具，用固定流程完成任务	工具参数验证、权限和失败测试
10	Agent 边界、执行状态、重复执行	仅在确有需要时增加自主工具选择；否则巩固 Workflow	是否需要 Agent 的书面判断、执行过程记录
11	可观测性、费用、部署与隐私	记录运行指标，部署受控试用版本	运行说明、费用记录、关键问题修复
12	用户试用、价值验证、项目表达	邀请 3–5 位目标用户；修复高影响问题并复盘	试用记录、演示、项目说明、后续计划

访谈与试用人数是练习建议。没有用户时可以先用自己验证，但必须注明局限，不把自测称为用户验证。

分阶段门槛

第 4 周结束：值得继续吗

• 有清楚的用户、任务和失败定义。
• 有一批实际输入，并知道数据是否可用。
• 已比较简单方案，知道 AI 带来了什么增益。
• 没有效果时，允许换场景或改需求。

第 8 周结束：功能有效吗

• 用户能完成一次完整任务。
• 输出正确性不仅靠格式判断。
• 可以复现失败，并区分检索、生成、校验和交互问题。
• 有未参与日常调整的样例用于验收。

第 12 周结束：别人能使用和维护吗

• 有实际使用记录和明确限制。
• 能把失败或人工修改转成经审核的评测样例，并用回归结果判断是否发布修改。
• 能处理关键异常和权限边界。
• 能说明费用、耗时和质量的取舍。
• 有运行、配置和排障说明。

并行保持的基础能力

继续练习 TypeScript、浏览器、异步编程、接口设计、SQL、测试和调试；这些是项目底座。

Python 暂不占用主线。从第 9 周起，若样例处理或评测工具确实需要，可将每周 1–2 小时学习时间用于 Python 文件操作、数据处理和脚本运行。

第一周逐日安排

天	两小时内的主要任务
1	阅读应用全貌，选三个熟悉的业务功能
2	完成第一张产品拆解卡，找出它的输入、输出和失败方式
3	完成另外两张卡，比较实现方式
4	在现有 React 项目选一个小需求，写出验收条件
5	用 AI 辅助分步实现，审查每次关键改动
6	检查正常、异常和边界行为，修复问题
7	记录耗时、返工、错误与下周调整

第一轮之后怎样分支

• 喜欢工程与产品交付：深入服务端、数据处理、部署、评测和系统集成。
• 喜欢产品与业务：深入用户研究、流程设计、效果核算和试点推进。
• 喜欢模型与实验：补数学、机器学习、PyTorch，再进入微调和模型优化。

根据实际做项目的感受选择，不需要提前学习所有分支。