想做 AI 工程师，别只学提示词：一条适合国内学习者的 7 阶段路线
从 Python 和后端基础开始，依次补齐大模型原理、API、RAG、Agent、评测和部署。海外资源已替换成更适合国内学习和落地的方案。
很多人想转 AI 工程师，第一反应是学提示词、背几个框架、做一个聊天机器人。
这些都不够。
AI 工程师真正要解决的是一整条链路：把模型接进业务，给它补上知识，让它调用工具，测清楚效果，最后控制成本并稳定上线。
下面这条路线分成 7 个阶段。它参考了一份英文学习路线，但把不适合国内学习和工作的地方重新改了一遍：视频平台、模型服务、学习资料和部署环境，都尽量换成国内读者更容易访问、申请和落地的选择。
先说时间。已经能独立写后端、部署服务的人，可以把它当成半年到一年的系统补课。零基础不要把“8 到 12 个月”当成承诺，能不能完成，取决于每周投入时间，以及你是否真的做项目。
第 0 阶段：软件工程基础
如果你还不能独立写一个简单后端服务，这一步不要跳过。
需要掌握什么
- Python 基础、虚拟环境、包管理和调试
- HTTP、REST API、JSON、鉴权和错误处理
- Git、分支、提交记录和代码协作
- Linux 命令行，以及最基本的 Docker 使用
国内学习替代
Python 可以从廖雪峰的 Python 教程开始：
https://www.liaoxuefeng.com/wiki/1016959663602400
API 设计直接看 FastAPI 中文文档：
https://fastapi.tiangolo.com/zh/
Git 不要只学“上传代码”。建议把 Git 官方书的中文版本完整过一遍：
https://git-scm.com/book/zh/v2
这一阶段的交付物
做一个能真正运行的小服务：
- 提供两个以上 REST 接口
- 有参数校验和错误返回
- 用 Git 管理代码
- 用 Docker 启动
- 写一份 README，让别人能照着跑起来
如果这件事做不到，后面的 RAG 和 Agent 项目大概率会停留在复制代码。
第 1 阶段：先弄懂大模型在做什么
你不需要一开始就训练大模型，但要建立一个基本判断框架：
- Token 是什么
- 上下文窗口为什么会影响效果和成本
- Transformer 的注意力机制大致怎样工作
- 为什么模型会产生幻觉
- 预训练、指令微调和推理有什么区别
更适合国内读者的资料
《动手学深度学习》有中文版本，适合边学边用 Python 和框架实现：
https://github.com/d2l-ai/d2l-zh
如果想进一步理解大语言模型的训练、数据和推理，可以看 Datawhale 的《Happy-LLM》：
https://github.com/datawhalechina/happy-llm
英文课程和海外视频可以作为补充，但不要把“能不能打开某个平台”变成学习门槛。真正重要的是，你能不能解释一次模型调用为什么失败，而不是记住多少个提示词模板。
第 2 阶段：模型 API 和提示词工程
这一阶段不要把提示词当成玄学。把它当成接口设计的一部分。
你需要学会：
- 明确输入和输出格式
- 设计结构化输出
- 让模型调用工具
- 处理超时、限流和重试
- 记录请求、响应、Token 消耗和错误
- 区分系统提示、用户输入和外部资料
国内适配方式
不要只绑定一家海外模型服务。建议先选一个国内平台跑通完整链路，再用第二家服务做兼容性测试。
可以从这些官方文档中任选一个开始：
- DeepSeek API 文档：https://api-docs.deepseek.com/zh-cn/
- 阿里云百炼：https://help.aliyun.com/zh/model-studio/
- 智谱开放平台：https://open.bigmodel.cn/dev/api
学习重点不是“哪个模型最强”，而是把模型调用封装成你自己的服务层。这样以后更换模型时，只需要替换适配器，不必重写业务逻辑。
国内环境下要额外注意
- API 余额、并发限制和模型上下文长度会直接影响项目成本。
- 用户资料、合同、病历和企业内部文档，不要默认发送到第三方服务。
- 需要处理敏感数据时，优先研究脱敏、私有化部署或本地模型。
- 不同模型的函数调用、JSON 输出和多模态接口并不完全兼容，不能只看宣传页。
第 3 阶段：RAG，先把资料找对
RAG 不是“上传一个 PDF，然后让模型回答”。真正难的是检索链路：
- 文档怎么切分。
- 表格、标题和层级怎样保留。
- Embedding 如何选择。
- 召回多少内容。
- 排序是否需要重排模型。
- 答案能不能回到原始片段。
- 错误答案怎样被评测出来。
项目建议改成国内场景
不要一开始就做“全网知识问答”。选一批你真正熟悉的中文资料：
- 公司内部制度
- 某个行业的公开规范
- 产品说明书和售后手册
- 你自己整理的课程笔记
- 政府公开文件或行业标准
做一个带引用片段的中文问答系统，至少完成三件事：
- 回答后显示依据来自哪一段资料
- 找不到依据时明确说不知道
- 用 30 到 50 个问题做一套固定评测集
这比做一个“看起来什么都能答”的机器人更接近真实工作。
第 4 阶段：Agent 和工作流
Agent 的核心不是让模型自由发挥，而是让它在边界内完成多步任务。
先理解一个最小循环：
读取任务 → 选择动作 → 调用工具 → 观察结果 → 再决定下一步
学习顺序
不要一上来就做多 Agent。建议按下面的顺序递进：
- 先做一个能调用天气、搜索或内部 API 的单 Agent。
- 再加状态保存和人工确认节点。
- 最后再研究多 Agent 分工。
如果你想快速搭建中文可见的工作流，可以先看 Dify 中文文档：
但低代码平台只能帮助你验证流程。要做正式产品，还需要自己处理权限、日志、重试、任务队列、数据保存和失败恢复。
MCP 可以作为工具连接协议来学习，但不要把“支持 MCP”当成项目完成。你仍然要检查每个工具能访问什么数据、有什么权限，以及调用失败时会发生什么。
第 5 阶段：评测和可观测性
这是 Demo 和产品之间最容易被忽略的一段。
至少要记录：
- 每次请求的输入和输出
- 使用的模型与版本
- Token 和费用
- 延迟、超时和错误
- 检索到的资料片段
- 用户是否接受答案
- 哪些问题经常答错
评测不要只看“我试了一次，感觉挺好”。你需要建立固定问题集，分别测召回、引用、格式、事实准确性和拒答边界。
国内项目尤其要考虑数据流向。能自建就优先自建日志和追踪系统；不能自建时，先确认服务商的存储位置、保留时间、权限和删除机制。敏感业务不要把完整用户输入直接扔进第三方监控平台。
第 6 阶段：部署和成本控制
最后一段决定项目能不能留下来。
需要补齐的内容包括：
- Docker 镜像和环境变量
- Linux 服务管理
- 反向代理和 HTTPS
- 日志、监控和告警
- 数据库备份
- 并发、限流和队列
- 模型降级与重试
- 每日和每月费用上限
Docker 和 Kubernetes 仍然是通用基础。国内部署时，可以根据团队现有环境选择阿里云、腾讯云、华为云、火山引擎或自有服务器，不必照搬海外教程里的云厂商方案。
成本控制也要改成真实的人民币预算：
- 简单分类和抽取任务，优先使用便宜模型。
- 复杂推理只交给更贵的模型。
- 缓存重复请求。
- 限制单次输入长度和最大输出长度。
- 给每个用户、项目和接口设置额度。
- 记录每次调用的实际成本，而不是月底才看账单。
最后做什么项目，才能证明你真的会
证书和课程列表不能证明你能交付。更有效的是做三个小而完整的项目：
项目一：中文资料 RAG
围绕一个真实主题，做检索、引用、拒答和评测。资料不要随便从网上抓，先确认使用范围和版权边界。
项目二：能调用两个真实工具的 Agent
例如让 Agent 读取企业内部资料，再调用一个业务 API，最后生成结构化结果。重点展示权限控制、失败重试和人工确认。
项目三：带评测和成本面板的上线服务
不需要很大，但要能回答这些问题：
- 哪些问题答错最多？
- 每次请求花多少钱？
- 模型升级后效果有没有变差？
- 出现异常时，能不能定位到具体请求？
这条路线最容易踩的坑
第一，只收集课程，不交付项目。
第二，把国外平台和模型名当成能力本身。平台可以替换，工程能力不能替换。
第三，只做 Demo，不做权限、评测、成本和故障处理。
第四，拿海外案例的美元价格、云服务和获客方式，直接套到国内业务里。国内项目还要考虑实名、合规、付款、数据保存、客户采购流程和本地部署要求。
第五，把“模型回答得很像”误认为“系统可靠”。AI 工程的价值，往往体现在它知道什么时候该查资料、什么时候该拒答，以及出了问题能不能找到原因。
真正值得完成的，不是七个阶段的打卡，而是一条从输入到上线的完整闭环：你能把模型接进业务，能测出它哪里不行，也能让它在预算和权限范围内稳定运行。
来源：https://x.com/_jaydeepkarale/status/2091884749757546924?s=52