先说一个反直觉的结论：大部分人学 AI 失败，不是因为不够努力，而是因为顺序错了。
我见过太多人从《深度学习数学基础》开始，啃完线性代数啃反向传播，三个月后还在推导公式，一次模型都没跑起来。也见过另一批人，上来就调 API 做 Demo，做得很漂亮，但换一个需求就无从下手——因为不知道能力边界在哪。
这两种失败其实共享同一个根源：缺少一个把"知道"和"做到"连接起来的中间层。
四阶段路线
我把这条路径拆成四个阶段，每个阶段有明确的产出物。没有产出物就不算过关。
| 阶段 | 目标 | 时间 | 产出物 | 常见陷阱 |
|---|---|---|---|---|
| 1. 会用 | 理解模型能力边界 | 1-2 周 | 3 个能跑的 Demo | 沉迷调 Prompt 技巧 |
| 2. 会接 | 把模型接入真实系统 | 1 个月 | 1 个完整应用 | 忽视成本与延迟 |
| 3. 会改 | 掌握检索、编排、评测 | 2-3 个月 | 1 个开源项目 | 跳过评测直接上线 |
| 4. 会训 | 微调与自建能力 | 3 个月+ | 1 个微调模型 | 一上来就要训模型 |
阶段一：会用，关键是建立"边界感"
这个阶段的目标不是学会所有 Prompt 技巧，而是搞清楚什么能做什么不能做。
最有效的练习方式是"挑衅式测试"：拿到一个模型，专门找它做不好的事情。
- 给它一道需要多步推理的数学题，看它第几步开始胡说
- 给它一份 5 万字的文档，看它从第几页开始遗忘
- 让它数一段话里有几个 "r"，看它是否直接编答案
- 同一个问题问三遍，看答案一致性如何
你会很快建立起直觉：它是一个概率驱动的、上下文有限的、没有真实世界反馈的模式匹配器。这个认知比任何 Prompt 模板都重要。
判断一个人是否真正理解大模型，不要问他会不会写 Prompt，问他"这个需求用模型做，哪部分一定做不好"。
阶段二：会接，工程复杂度才是真门槛
从 Demo 到产品，中间隔着一整个工程世界。
这是我在这个阶段写下的最小可用骨架，它解决的问题是：怎么让一次模型调用不至于拖垮整个服务。
import asyncio
from dataclasses import dataclass
@dataclass
class CallResult:
text: str
tokens: int
latency_ms: int
class ResilientClient:
"""带超时、重试与降级的模型调用封装。
生产环境里，模型 API 是整条链路上最不可靠的一环：
延迟抖动大、限流频繁、偶发 5xx。必须主动兜底。
"""
def __init__(self, client, timeout_s: float = 15.0, max_retries: int = 2):
self.client = client
self.timeout_s = timeout_s
self.max_retries = max_retries
async def complete(self, prompt: str, fallback: str = "") -> CallResult:
for attempt in range(self.max_retries + 1):
try:
return await asyncio.wait_for(
self._raw_call(prompt),
timeout=self.timeout_s,
)
except (TimeoutError, ConnectionError) as e:
if attempt == self.max_retries:
# 最后一次仍失败：返回降级结果，绝不让异常穿透到用户
return CallResult(fallback, 0, 0)
await asyncio.sleep(2**attempt) # 指数退避
return CallResult(fallback, 0, 0)
async def _raw_call(self, prompt: str) -> CallResult:
resp = await self.client.chat(prompt)
return CallResult(resp.text, resp.tokens, resp.latency_ms)这里有三个容易被忽略的点：
- 超时必须显式设置。模型 API 的 P99 延迟可能是均值的 10 倍，不设超时会拖垮整个线程池。
- 重试要指数退避。连续重试会加重限流，适得其反。
- 降级路径是设计出来的，不是兜出来的。想清楚"模型挂了用户看到什么"，这个答案不能是报错页。
阶段三：会改，检索与评测是分水岭
到这一步，你已经有应用了。接下来的问题变成：为什么它有时候答得很好，有时候离谱？
答案通常是上下文。而这正是 RAG（检索增强生成）要解决的。
但我要泼一盆冷水：大部分 RAG 系统做不好，问题不在模型，在检索。
我见过最典型的错误是把文档按固定长度切片，然后直接向量化。这个做法在 demo 上能跑，在生产上一定翻车——因为固定长度切片会切断语义单元。
# ❌ 常见但错误的做法：机械切片
chunks = [text[i : i + 500] for i in range(0, len(text), 500)]
# ✅ 按语义结构切片，保持段落完整性
def semantic_chunk(doc: str, max_len: int = 800) -> list[str]:
"""先按标题切分，再对超长段落做二次分割。"""
sections = re.split(r"\n(?=#{1,3} )", doc)
chunks = []
for section in sections:
if len(section) <= max_len:
chunks.append(section)
continue
# 超长段落按句子边界递归分割，保留标题作为上下文前缀
title = section.split("\n")[0]
for piece in split_by_sentence(section, max_len - len(title)):
chunks.append(f"{title}\n{piece}")
return chunks把标题作为前缀拼进每个切片，这个技巧的收益远超调 embedding 模型。原因是它给每个切片补回了被切掉的上下文。
阶段四：会训，但大概率你现在不需要
微调是这条路上最被高估的环节。
我的建议是：在你能量化证明"Prompt + RAG 解决不了"之前，不要碰微调。
微调真正适合的场景只有三类：
- 需要极短的固定格式输出（如分类、抽取），且延迟要求苛刻
- 需要注入大量长尾知识，而这些知识放不进上下文
- 有明确的、可规模化的评测集，且当前方案在评测上明显落后
除此之外，微调带来的收益往往抵不上它引入的维护成本——数据版本、训练脚本、模型托管、回归测试，是一套全新的工程体系。
每周投入建议
假设你每周只有 10 小时（有本职工作），我建议这样分配：
- 3 小时读：读论文摘要和官方博客，不读全文，抓结论和边界
- 5 小时做：写代码、跑实验，这是唯一能形成肌肉记忆的部分
- 2 小时写：把学到的写成文章或笔记，写不清楚说明没懂
写作这一步最常被跳过，但它的价值最高。费曼学习法不是鸡汤——你能讲清楚的程度，就是你真正理解的程度。
下一步
如果你正处在阶段一到阶段二之间，建议接着看这篇 Agent Skills 工程化实践，它讲的是怎么把一次性的模型调用，组织成可复用、可测试的能力单元。