AI 应用开发者路径

这条路径适合谁

这条路径适合下面几类学习者：

• 已经会写业务代码，但对大模型应用还停留在“会调个 API”阶段。
• 更关心产品落地，而不是亲自训练底座模型。
• 希望在 6 到 8 周内做出一个真正可演示、可评测、可继续迭代的 AI 应用原型。

如果你更想走“训练和系统工程”路线，可以优先看 LLM 工程师 0-1 路径。如果你更偏论文与实验设计，可以继续看 LLM 研究者进阶路径。

路径目标

走完这条路径后，你最好已经具备四项能力：

1. 能把模糊需求拆成可执行的 Prompt 与评测项。
2. 能搭一条最小 RAG 链路，而不是只会把文档“喂给模型”。
3. 能把模型包成一个可调用服务，并知道如何观测质量与延迟。
4. 能把 Demo 打磨成有明确场景边界的产品原型。

这条路线不要求你先学会大规模训练，但要求你尽快建立“应用闭环意识”。

8 周总览

第一阶段：先学会把需求写清楚（第 1-2 周）

第 1 周：建立 Prompt 基础观

核心任务：

• 阅读 Prompt Engineering 系统指南，理解任务定义、消息分层、few-shot 和结构化输出之间的关系。
• 自己选一个简单业务场景，例如 FAQ 助手、工单分流、摘要助手。
• 写出一版最小 Prompt，明确角色、任务、约束和输出格式。

建议输出：

• 一份 Prompt 设计说明。
• 一套至少 20 条的小型测试问题集。

这一周的重点不是“写出最强提示词”，而是学会把模糊需求转成清晰规格。

第 2 周：建立 Prompt 评测与迭代意识

核心任务：

• 阅读 LLM 评测方法论，理解为什么 Prompt 优化不能只靠主观体验。
• 用自己的测试集区分标准样本、改写样本、边界样本和风险样本。
• 做一次 Prompt A/B 对比，记录变化点和副作用。

建议输出：

• 一张失败类型表。
• 一份 Prompt 版本对比说明。

这一步会帮你建立应用开发里非常关键的习惯：任何提示词修改都应该能被回归验证。

第二阶段：把“会聊天”升级成“会基于知识回答”（第 3-4 周）

第 3 周：先建立 RAG 的系统认知

核心任务：

• 阅读 RAG 综述，理解召回、重排序、上下文组装在整条链路中的位置。
• 阅读 Lost in the Middle，建立“长上下文不等于高利用率”的意识。
• 选择一个真实知识源，例如产品文档、内部流程、技术笔记或论文卡片。

建议输出：

• 一张 RAG 系统流程图。
• 一份文档清洗与切块规则草案。

第 4 周：做出最小 RAG 原型

核心任务：

• 阅读 RAG 系统搭建实战，按文档清洗、切块、召回、重排序、回答生成的顺序搭建最小闭环。
• 准备一批基于知识库的问题，验证系统是否真的引用了正确证据。
• 记录至少 10 个失败样本，区分是检索问题还是生成问题。

建议输出：

• 一个可运行的最小 RAG Demo。
• 一份失败样本日志。

这一周结束后，你应该已经从“普通聊天机器人”走向“有知识边界的应用原型”。

第三阶段：把原型变成服务（第 5-6 周）

第 5 周：让应用真正可调用

核心任务：

• 阅读 LLM 推理服务搭建：vLLM、TGI 与 Ollama，理解本地原型、团队共享服务和线上 API 的差别。
• 为自己的应用选择一条部署路线，先跑通一个可访问接口。
• 明确接口输入输出协议，约定错误返回和超时行为。

建议输出：

• 一个最小 HTTP API。
• 一页部署与配置说明。

第 6 周：补齐评测、延迟与成本视角

核心任务：

• 为你的应用记录 TTFT、总响应时间、错误率和关键质量指标。
• 观察 Prompt、RAG、模型大小、上下文长度对延迟和成本的影响。
• 阅读 模型量化入门：INT8、INT4、GPTQ 与 AWQ，理解什么时候该用量化，而不是盲目换更贵硬件。

建议输出：

• 一张质量 / 延迟 / 成本三者关系表。
• 一份“当前瓶颈在哪”的分析笔记。

应用开发者不一定要亲自深挖底层系统，但必须知道问题在 Prompt、检索、服务还是资源配置。

第四阶段：把它做成一个能讲清价值的产品（第 7-8 周）

第 7 周：收敛场景，而不是继续泛化

这一步很重要。很多 AI Demo 在前几周看起来很有希望，但到了交付阶段会暴露一个问题：

它什么都能答一点，但没有一个场景真的做得足够好。

因此第 7 周建议你强制收敛：

• 明确目标用户是谁
• 明确不能做什么
• 明确成功指标是什么
• 明确最关键的 20 条高频任务

建议输出：

• 一页产品定义文档。
• 一套高频任务回归集。

第 8 周：完成交付与复盘

核心任务：

• 整理项目 README、接口说明、运行方式和演示流程。
• 准备一份复盘，回答“系统最大的失败模式是什么”“下一轮应该优先改哪里”。
• 如果你发现 Prompt 和 RAG 已经逼近上限，评估是否需要引入 LoRA 微调实战 作为下一阶段方向。

建议输出：

• 一个可演示的 AI 应用原型。
• 一份问题清单与下一步路线图。

推荐项目方向

如果你想减少选题成本，可以从这些方向中挑一个：

• 企业知识库问答助手
• 客服工单分流与回复辅助
• 技术文档摘要与问答助手
• 会议纪要整理与行动项提取工具
• 面向垂直领域的轻量 Copilot

项目最好满足三个条件：

• 问题边界清晰
• 输出价值可验证
• 失败模式容易记录

每周固定动作建议

为了让 8 周路线更稳，建议每周都保留这三个固定动作：

• 记录失败样本，而不是只收集成功案例。
• 把任何 Prompt 或 RAG 改动写进变更日志。
• 维护一套小而固定的回归集。

AI 应用开发最怕“今天感觉变好了，明天又说不清为什么变差了”。

里程碑检查点

第 2 周检查

你应该已经能：

• 把一个业务需求拆成 Prompt、输入、输出和评测项。
• 区分标准样本和边界样本。
• 解释为什么 few-shot 和结构化输出会直接影响产品稳定性。

第 4 周检查

你应该已经能：

• 跑通一个最小 RAG 原型。
• 说清楚切块、召回、重排序分别在解决什么问题。
• 找出至少几条“为什么系统答错”的具体原因。

第 8 周检查

你应该已经能：

• 交付一个别人可以真正试用的 AI 应用。
• 说明质量、延迟、成本三者的主要权衡。
• 给出下一轮是该继续优化 Prompt/RAG，还是该引入微调/工具链的判断。

常见误区

1. 一上来就追求“通用智能助手”，结果需求边界始终不清。
2. 只优化 Prompt，不做任何评测回归。
3. 只做 RAG，不做文档清洗和失败样本记录。
4. 应用已经到了交付阶段，仍然没有日志、接口说明和回滚方案。

走完这条路径后，下一步可以怎么继续

如果你完成了这条 8 周路径，后续通常会有两条很自然的延伸方向：

• 往“更强应用工程”走：继续学习 Agent 与工具调用实战：从 Function Calling 到 ReAct 工作流，把单轮问答升级成可执行工作流。
• 往“多模态应用”走：补 多模态 LLM 原理与应用：从 CLIP 到 LLaVA，建立截图理解、图像问答和文档理解的系统视角。
• 往“更强模型工程”走：补齐 LLM 工程师 0-1 路径 中的微调、推理优化和部署体系。

如果你想先把底层训练与系统观补完整，可以从工程路线继续；如果你更想把应用问题转成实验与论文阅读，也可以回到 LLM 研究者进阶路径。