怎么变成
AI ENGINEER🚀 2026 实操版

📖 这本书怎么读

👆 完整版在 wiki 上长这样：左边 8 章随便点，不用注册不要钱 → jiangren.com.au/wiki

💬 看着看着有问题，扫码来问

Amelia 会拉你进群。群里有人答转行问题，每周还发 AI 大事盘点。

CHAPTER 01

🧭 岗位真相：AI Engineer 是什么、不是什么

说白了：模型不用你训练，你的活儿是把 Claude、GPT 这些现成的大模型攒成能用的产品。每天干的事就是写 prompt、搭 RAG、调 API、上线、盯 token 账单，然后被 PM 追问"幻觉怎么办"。不刷 Kaggle，不写 paper。这岗位 2023 年才出现，现在澳洲招聘网站上已经到处都是了。

💬 举个例子，同样做一个客服机器人，两条路差多远：

CHAPTER 02

💰 先说钱：全球行情与四地薪资带

大部分人最关心的就是钱，所以放最前面。先把一件事说死：AI Engineer 的缺口是全球性的，不是哪一国的局部行情 —— 下面四个市场的数据全部来自公开报告，来源都标了。

📈 增长有多猛：三个市场，同一条曲线

🇦🇺 分地区深看一站：澳洲（我们自己的市场，数据最细）

LinkedIn 同一份报告还给了两个信号：AI Engineer 高频技能是 LangChain、RAG、PyTorch（前两个本书 B 部分整章讲）；美国岗位集中在旧金山、纽约、达拉斯 —— 但远程岗的开放度在持续提高，这对全球华人是实打实的机会。

💵 四个市场的真实薪资带（各自货币，别换算着比）

注意口径：美国是含股票的总包、澳洲是不含养老金的 base、中国均值被高薪样本拉高（所以同时给中位和顶薪两条线）。大厂样本另算：Levels.fyi 上 Google AI Engineer 中位总包 $280K、OpenAI $555K。

⚖️ 为什么值这个价：AI 溢价是全球现象

数据来源：Seek 2026 Q1 / LinkedIn Salary Insights / Hays IT Salary Guide，base 不含 super；完整分析见 wiki 第 1 章

CHAPTER 03

🗺️ AI Engineer 到底需要会什么：官方能力地图

一条公式先记住（这是匠人学院官网能力测试的框架，基于 AI 行业招聘趋势与 Anthropic、OpenAI 等头部公司工程实践整理，已有 2,300+ 人完成测试）：

注意顺序：Full-stack 排第一，官方标注"更重要"。很多人以为转 AI Engineer 是绕开写代码的捷径 —— 恰恰相反，这个岗位最基础的要求就是会 coding：AI 能力最终要做成能上线的产品功能，承载它的是实打实的工程。五大支柱 77 项技能：

🧱 地基：Full-stack 的 23 项（没有它，后面全是空中楼阁）

☁️ 另外三根柱子，别等用到才补

🚀 AI Engineering Core 的学习主线：从 4 件套进场

第五根柱子 23 项最多，但别被吓到 —— 入场主线就是下面 4 件，串起来能做出 80% 的 AI 产品，本书 B 部分按这个顺序一章章讲透；剩下的（Memory、Guardrails、语义缓存、Harness、Skills 范式、微调…）都在第 7-12 章里按需展开：

🧰 2026 技术栈全景表（每类学到哪一档，一眼看清）

"必学"档全部在本书 B/C 部分有对应章节；工具名会过时，档位思维不会 —— 每半年按这个框架重排一次自己的清单。

CHAPTER 04

🔌 LLM 基础：它怎么工作、API 怎么调、账单怎么算

LLM 说穿了就是一个超大号的"下一个词预测器"。你输入 "The capital of Australia is "，它算出每个可能的下一个词的概率（Canberra 0.85、Sydney 0.08…），按概率抽一个，接上去再算下一个，循环到结束。整个"对话"就是几百到几万次预测串起来的。听起来很笨，但参数堆到万亿级之后，"预测下一个词"突然涌现出推理、写代码、创作的能力 —— 这就是大模型的全部秘密。

📏 Context window：模型一次能"看"多少

Context window 是模型一次能处理的最大 token 数，超了就被截断，截在哪取决于你的代码 —— 这是常见 bug 来源。三个实操要点：

⚡ API 五分钟跑通（这就是你上班第一天干的事）

以 Anthropic SDK 为例，Claude / GPT / Gemini 的 SDK 风格几乎一样。最小调用：

import Anthropic from '@anthropic-ai/sdk';
const client = new Anthropic();

const response = await client.messages.create({
  model: 'claude-sonnet-4-6',
  max_tokens: 1024,
  messages: [{ role: 'user', content: '用一句话解释 RAG 是什么' }]
});
console.log(response.content[0].text);

Python 版一样简单（两种语言任选其一精通即可）：

import anthropic
client = anthropic.Anthropic()

response = client.messages.create(
    model="claude-sonnet-4-6", max_tokens=1024,
    messages=[{"role": "user", "content": "用一句话解释 RAG 是什么"}]
)
print(response.content[0].text)

多轮对话要自己维护历史（API 是无状态的，它不记得上一轮）：

const history = [];
async function chat(userMsg) {
  history.push({ role: 'user', content: userMsg });
  const res = await client.messages.create({
    model: 'claude-sonnet-4-6', max_tokens: 1024, messages: history
  });
  history.push({ role: 'assistant', content: res.content[0].text });
  return res.content[0].text;
}
await chat('我在墨尔本');
await chat('附近有什么大学？');  // 这次它知道"附近" = 墨尔本附近

Streaming 必开（不开的话用户等 5-10 秒才看到第一个字，产品里基本是死刑）：

const stream = await client.messages.stream({ ...同上参数 });
for await (const event of stream) {
  if (event.type === 'content_block_delta') process.stdout.write(event.delta.text);
}

System prompt 管角色和边界，比在 user message 里写"请扮演…"强 10 倍（新手最常见的错）：

await client.messages.create({
  model: 'claude-sonnet-4-6', max_tokens: 1024,
  system: '你是匠人学院的客服助手。只回答课程、报名、支付问题，其他话题礼貌拒绝。',
  messages: [{ role: 'user', content: '今天 AI 股票涨了吗？' }]
});
// → "抱歉，我只回答匠人学院相关问题…"

💸 账单怎么估（老板一定会问你）

价格三年降了 5-10 倍，但生产场景照样能给小公司打出几千刀一个月。心算公式：调用次数 × (输入 token × 输入单价 + 输出 token × 输出单价)。一个真实例子，内部知识库 RAG、每天 1000 次查询、每次 4K 输入 + 500 输出：

📐 Context window 一览（实操三件事在前面讲过）

💵 完整价格表（背下数量级就行，具体数字会变）

注意两个规律：output 比 input 贵约 5 倍（所以要限 max_tokens）；cached input 约是原价 1/10（所以 caching 必开）。

🧯 出错怎么办：重试与生产就绪

API 会给你 429（限流）和 5xx（服务端错），生产代码必须带指数退避重试：第一次等 0.5 秒、第二次 1 秒、第三次 2 秒，三次还不行就走降级（换备用模型或排队）。再配一份上线前自查（公开课 14 条清单的精华版）：

🤔 模型选型工程：任务定型号，路由管生产

🤔 模型怎么选：别再纠结"谁最聪明"

2026 年的现实是 Top 3 模型在大部分日常任务上 90% 以上重叠，差异在特定能力、价格和生态。按任务对号入座：

要做什么？
├── 客服聊天 / 通用 RAG        → Claude Sonnet（性价比 + tool use 干净）
├── 复杂代码 / Code review     → Claude Opus（一小时省 5 小时人工）
├── 数学 / 严格 reasoning      → GPT-5 开 reasoning mode
├── 长视频 / 跨多文件分析       → Gemini Pro（2M context 没人能比）
├── 实时语音对话产品           → OpenAI Realtime API
└── 高 QPS 简单任务（分类/提取） → Haiku / Gemini Flash 二选一

🏪 三家旗舰怎么分工（每家的独门绝活）

🧠 像工程师一样选型（公开课方法论）

新手问"哪个模型最好"，工程师按这个顺序问自己五个问题：

1. 我的任务是什么类型？（聊天 / 代码 / 摘要 / agent / 分类 / 高风险）
2. 错一次的代价高不高？
3. 用户能不能接受 2-5 秒等待？
4. 要不要调工具、读长 context、输出 JSON？
5. 现在是 demo 预算还是 production 预算？

这五个问题没想清楚，模型对比就只会停留在"网上大家都说它强"。不同任务吃的能力完全不一样：

生产环境的标准答案是三层路由，不让最贵的模型干所有事：

怎么客观对比：准备 20 条高频真实任务 + 10 条边界 case + 10 条高风险 case，相同 system prompt、相同检索结果、相同输出要求，给每个候选模型打这张记分卡：

任务完成率   30%   核心任务是不是真做完了（不是"听起来聪明"）
延迟        20%   首 token 时间 + 完整响应时间
成本        15%   单次成本 + 日均成本（含重试和 fallback）
结构稳定性   15%   JSON 稳不稳、字段缺不缺
安全        10%   会不会越权、幻觉、泄漏
接入成本    10%   SDK / 日志 / 限流 / retry 顺不顺手

🚪 选完型还要会"路由"：LLM Gateway（生产标配）

公司一旦有 3 个以上 AI 功能，就不该让每处代码直连模型 API 了 —— 中间加一层 gateway，统一做路由、灰度、降级、PII 清洗和记账。配置长这样（公开课原版）：

routes:
  chat-default:
    primary: claude-sonnet          # 主力
    canary:
      model: gpt-5
      traffic_percent: 5            # 新模型先切 5% 流量
    fallback: gemini-flash          # 主力挂了自动降级
    pii_scrub: true                 # 出门前洗 PII
    budget:
      per_tenant_daily_usd: 50      # 每租户日预算，超了熔断
kill_switch: env.LLM_GATEWAY_OFF    # 一键全局关闸

核心收益：换模型不改业务代码（改配置就行）、新模型用 5% 流量验证再放量、每个团队/租户的成本看得见。面试聊到"你们怎么管多个模型"，把这套讲出来就是 production 信号。

✍️ Prompt Engineering：写得好比换大模型还省钱

一个 Sonnet 配好 prompt，效果能追平 Opus 配烂 prompt，价格只有 1/5。这不是段子：把 system prompt 从 100 字改到 500 字、加 3 个例子，换一档便宜模型，质量还往上走 —— 内部所有 AI 功能都做过这种 A/B。所以写 prompt 的时间投入回报率比写代码还高。

🎭 三个角色，别放错位置

API 的 messages 里只有三种角色：system（开发者写的指令：角色、边界、输出格式）、user（用户的实际输入）、assistant（模型的历史回复）。新手最容易犯的错是把指令全塞进 user message：

// ❌ 错：指令和用户问题混在一条 user 里，权重一样
messages: [{ role: 'user',
  content: '你是客服。只回答课程问题。\n用户问题：今天天气怎么样？' }]
// 模型可能照常聊天气

// ✅ 对：指令进 system，user 只放数据
system: '你是匠人学院客服。只回答课程、报名、支付问题，其他礼貌拒绝。',
messages: [{ role: 'user', content: '今天天气怎么样？' }]
// 模型严格拒答

这不是玄学：Anthropic 和 OpenAI 都在训练时专门把 system 刻成"指令"、user 刻成"数据"，这条边界写进了模型权重。

🪜 三档手段：直接问 → 举例子 → 让它先想

📦 Structured Output：让模型吐 JSON 进数据库

生产里 90% 的调用最后要解析成结构化数据。两条主流路：

// 路 1：XML 标签（Claude 推荐，训练数据里见得多，错误率最低）
请分析简历，按以下格式返回：
<analysis>
  <skills>...</skills>
  <years_of_experience>...</years_of_experience>
</analysis>

// 路 2：JSON Schema 强制（OpenAI structured output）
response_format: { type: 'json_schema', json_schema: {
  schema: { type: 'object', properties: {
    skills: { type: 'array', items: { type: 'string' } },
    years_of_experience: { type: 'integer', minimum: 0 }
  }, required: ['skills', 'years_of_experience'] }
}}
// 底层用语法约束解码，比 prompt 里写"请返回 JSON"可靠 100 倍

🏭 生产环境 prompt 必须做的 4 件事

// src/common/prompts/resume-analysis.prompts.ts
export const RESUME_ANALYSIS_PROMPT = {
  version: '1.2.0',
  defaultModel: 'claude-sonnet-4-6',
  temperature: 0,
  maxTokens: 800,
  system: `你是简历分析师...`,
  template: (resume) => `请分析以下简历：\n\n${resume}`
};

📖 把例子写全：few-shot 和 CoT 实操

Few-shot 的完整样子（注意例子专挑边界情况）：

分类评论情感：

例子 1："这个课程节奏太快了" → 负面（抱怨节奏）
例子 2："老师讲得很清楚但作业有点多" → 中性（混合反馈）  ← 边界 case
例子 3："超级喜欢这个 instructor！" → 正面（明确赞许）

现在分类："内容还可以但是价格偏高"

CoT 的完整样子（先推理再判断，数学题准确率 ~60% → ~92%）：

判断下面这道题的答案对不对：
题：小明有 5 个苹果，吃了 2 个，又买了 3 个，现在有几个？
学生答：8 个

请先一步步推理，再给最终判断（对 / 错）。

XML 输出的解析端（Claude 路线配套代码）：

const text = response.content[0].text;
const skills = text.match(/<skills>(.*?)<\/skills>/s)?.[1]?.trim();

🗂️ 5 个模式的完整模板（直接抄）

// 模式 1 分类
分类下面 [对象]，类别：[A / B / C / 其他]
[few-shot 例子，覆盖边界]
[新对象]
→ 只输出类别名，不解释

// 模式 2 提取
从下面文本提取以下字段：
- field_a: …    - field_b: …
用 XML 返回，缺失字段写 null

// 模式 3 改写
将下面文本改写成 [风格]，保持核心信息不变。
风格要求：[3-5 条具体约束]

// 模式 4 总结
将下面文档总结成 [N 条要点 / 200 字以内]
要求：包含 [维度 X / Y / Z]；不要营销腔和模板化语言

// 模式 5 决策
基于以下信息和规则，判断 [是否做 X]
信息：…   规则：[规则列表]
先列推理步骤，再给最终判断

🏛️ System Prompt 设计（公开课 641 行的精华版）

Agent 时代 system prompt 不再是一句"你是个助手"，而是一份小型规范文档。看过 Claude Code、GPT Agent Mode、Gemini CLI 的泄露版 prompt 之后，能提炼出一个通用骨架 —— 四区结构：

<BACKGROUND>    身份、环境信息、当前日期（身份锚定）
<INSTRUCTIONS>  行为规则，按优先级分层（必须 / 应该 / 禁止）
<TOOL_GUIDANCE> 每个工具什么时候用、什么时候不用、默认参数
<OUTPUT>        输出格式模板 + 一个正例一个反例

写的时候盯住一个词：高度（altitude）。写太死（硬编码每种情况）一改需求就碎；写太虚（"请专业地回答"）模型没有可执行信号。最优点是"足够具体能指导行为，又留了发挥空间的启发式"。几个拿来就能用的模式：

## 退款 Policy
Allowed：查询退款进度；解释退款规则；提交退款申请单
Not Allowed：直接承诺退款金额；修改订单状态；处理 30 天以上的争议（转人工）

🧩 10 个设计模式全列（前面详讲了 3 个，这是完整工具箱）

// 模式 2 / 5 / 10 的骨架（其余见公开课 system-prompt-design 全文）
# Priority Levels
CRITICAL: [必须遵守]   IMPORTANT: [重要规则]   Note: [建议]
NEVER: [绝对禁止]      ALWAYS: [必须执行]      PREFER / AVOID: [取舍]

## [工具名称]
When to use: [场景]    When NOT to use: [反场景]
Parameters: param1 (required) ...    Example: [调用示例]

If [初始尝试失败], then: 1.[调整] 2.[再调整] 3. If still fails, [兜底]
After completing [任务], verify by: [自检步骤]; If verification fails, [修正]

📄 一份完整的生产级 System Prompt 长什么样（客服 Agent 全文骨架）

把 10 个模式拼起来就是这个 —— 注意它同时用了身份锚定、工具规范、负面约束、格式模板和示例驱动：

You are CustomerBot, an AI customer service agent for TechStore.

## Identity
Name / Role / Company / Languages: English, Chinese

## Available Tools
### lookup_order — 按订单号查详情
  Parameters: order_id (required, 格式 ORD-XXXXXX)
### search_products — 搜商品目录（query 必填，category/in_stock 可选）
### create_ticket — 复杂问题开工单（category / priority / description）

## Response Guidelines
1. 简短问候  2. 先识别意图再调工具  3. 用工具拿准确信息
4. 回答简洁可执行  5. 结尾给下一步或追问

## Safety Rules
- NEVER 未验证身份就给订单详情
- NEVER 直接处理退款（开工单代替）
- NEVER 承诺配送时间
- 安全类投诉一律升级人工

## Output Format
默认 100 词以内；多项用 bullet；结尾必有下一步。

## Examples
User: Where is my order ORD-123456?
Assistant: [calls lookup_order] 在途，预计 1 月 20 日送达。
要我发 tracking 链接吗？

🧠 Context Engineering：管好模型那扇注意力窗（2026 新必修）

🧠 比 RAG 更大的概念：Context Engineering（2026 面试新宠）

下一章要讲的 RAG 只管"检索什么"，Context Engineering 管的是模型在推理那一刻能看到的一切：system prompt、工具定义、检索文档、对话历史、工具输出。这是 2026 年 JD 里的新高频词，核心认知就几条：

一个可以直接套的最小 context 模板：

<SYSTEM>   角色、约束、输出格式
<TASK>     目标、成功标准、限制
<TOOLS>    工具列表 + 使用说明
<FACTS>    结构化事实 / ID / 来源
<HISTORY>  相关轮次的简短摘要（不是全文）

📉 退化有多真实：基准数据（背两个数就够）

🗜️ 压缩怎么做：三方案量化对比（少见的硬数据）

来源：Factory Research（2025-12）。另一个反直觉结论：盯着"单次请求 token"省小钱会亏大钱 —— 省 0.5% token 如果换来 20% 的重新检索，总账是亏的。要优化的是 tokens-per-task，不是 tokens-per-request。

CHAPTER 08

📚 RAG：让 AI 懂你公司的数据（面试必考）

模型训练数据有截止日期，它不知道你公司的代码库、客户工单、产品文档。要让它知道，两条路：fine-tune（把数据训进权重 —— 贵、慢、改一次重训一次）或者 RAG（每次提问时先去外部存储找相关内容，塞进 prompt）。99% 的场景选 RAG：数据改了立刻生效、答案可追溯、不用 GPU、还能做权限隔离。

整条链路就 5 步：

用户提问 → ① 问题转向量 → ② 向量库搜最相似的 top-k 片段
        → ③ 拼 prompt（"基于以下资料回答：[片段]，用户问：[问题]"）
        → ④ 喂给 LLM 生成答案 → ⑤ 返回用户

听起来简单，但每一步的细节都能让你翻车。挨个拆：

✂️ 第一步切片（最容易翻车的一步）

向量库存的不是整本文档，是切片（chunks）。切得好搜得准，切得烂答非所问。默认起手参数背下来：

chunk_size = 1000     # 每块约 1000 字符 ≈ 250 token
chunk_overlap = 200   # 相邻块重叠 20%，防止一个事实被切成两半谁都答不全

三种切法：固定大小（会切断句子和代码块）、按文档结构切 H1/H2/H3（结构化文档好用）、递归切（先按章节、太大再按段落再按句子 —— 大部分场景的默认选择）。每个切片必须带 metadata：来源文件、章节、更新时间、权限级别 —— 这些之后会救命。

🧭 第二步 embedding + 第三步存库

Embedding 模型把文字变成一个一千多维的向量，语义相近的文字在向量空间里距离近。默认起手 text-embedding-3-small（便宜够用生态熟），中文重的项目换 BGE-M3 或 Voyage。黄金规则：文档和查询必须用同一个 embedding 模型 —— 听着像废话，但"后期想换模型却没重新 embed 全部文档"是生产环境的经典事故。

向量库选型一句话：已经在用 Postgres 就上 pgvector，已经在用 MongoDB 就上 Atlas Vector Search（我们内部就这么干的），不想运维就 Pinecone，本地玩 demo 用 Chroma。pgvector 长这样：

CREATE TABLE doc_chunks (
  id BIGSERIAL PRIMARY KEY,
  content TEXT NOT NULL,
  embedding vector(1536),
  source TEXT, access_level TEXT
);
CREATE INDEX ON doc_chunks USING hnsw (embedding vector_cosine_ops);

SELECT content, source, 1 - (embedding <=> $1) AS similarity
FROM doc_chunks
WHERE access_level = 'public'    -- 权限过滤，别让用户 A 搜到用户 B 的数据
ORDER BY embedding <=> $1 LIMIT 5;

🎯 第四步检索：从"能用"到"生产级"的三连击

朴素版 RAG（直接取相似度 top-5）在真实数据下准确率只有 60-70%。三招连上去：

这是内部简历/工单 RAG 的真实数字，全程没换模型没换 embedding。第三招是 Query 改写：用户问"我能用 Claude 写论文吗"，先让 LLM 改写成"Claude 学术写作政策 / 论文使用条款"等 3 个查询各搜一次再合并 —— 对中文 RAG 提升尤其大。

📝 第五步拼 prompt：两条生死线

你是匠人学院的客服。基于以下资料回答用户问题。
如果资料里没有相关信息，直接说"这个问题我没有资料"，不要瞎编。

资料：
[chunk 1 — 来源: pricing-faq.md]
...
[chunk 2 — 来源: refund-policy.md]
...

用户问题：{user_query}

🚑 RAG 翻车对照表（真实事故复盘）

🔧 每一步的完整工具箱

切片三种方法对比（前面给了结论，这是完整对照）：

import { RecursiveCharacterTextSplitter } from '@langchain/textsplitters';

const splitter = new RecursiveCharacterTextSplitter({
  chunkSize: 1000,
  chunkOverlap: 200,
  separators: ['\n\n', '\n', '。', '. ', ' ', '']   // 中英文混合
});
const docs = await splitter.createDocuments([fullText]);

每个 chunk 的 metadata 长这样（之后做权限隔离、按时间排序、来源引用全靠它）：

{ pageContent: "Claude Sonnet 的 input 价格是 $3/M tokens...",
  metadata: {
    source: "anthropic-pricing.md",
    section: "Sonnet pricing",
    last_updated: "2026-04-01",
    access_level: "public" } }

Embedding 模型选型表：

const res = await openai.embeddings.create({
  model: 'text-embedding-3-small',
  input: ['Claude Sonnet 的价格是...']
});
const embedding = res.data[0].embedding;  // [0.012, -0.045, ...] 1536 维

向量库选型表：

三连击的代码。Hybrid 融合用 RRF 算法（不用调参）：

def rrf_merge(vector_results, keyword_results, k=60):
    scores = {}
    for rank, doc in enumerate(vector_results):
        scores[doc.id] = scores.get(doc.id, 0) + 1 / (k + rank)
    for rank, doc in enumerate(keyword_results):
        scores[doc.id] = scores.get(doc.id, 0) + 1 / (k + rank)
    return sorted(scores.items(), key=lambda x: -x[1])

Reranker（召回 top-50 重排出真 top-5）：

const reranked = await cohere.v2.rerank({
  model: 'rerank-3',
  query: userQuery,
  documents: top50Chunks.map(c => c.content),
  topN: 5
});

Query 改写（对中文 RAG 提升最大的一招）：

原 query：我能用 Claude 写论文吗？
让 LLM 先改写成 3 个查询，各搜一次再合并：
- Claude 学术写作政策
- Claude 论文使用条款
- 用 Claude 生成 academic 内容是否允许

全部拼起来，生产级 RAG 的完整架构（这个图面试画出来就是加分项）：

Documents (PDF/MD/Web) ──▶ Ingestion（切片+embed）──▶ Vector DB + BM25 索引
                                                          │
User Query ──┬─ 向量检索 ──┐                              │
             ├─ BM25 检索 ─┼──▶ RRF 融合 ──▶ Reranker ──▶ top-5
             └─ Query 改写 ┘                    │
                                       LLM + Prompt（带兜底指令 + 来源标注）
                                                │
                                           最终答案（可引用、可追溯）

🧬 没数据怎么办：合成数据（训练集和评估集的救星）

做 eval 或微调时经常缺标注数据 —— 用 LLM 生成合成数据是标准解法，但乱用会污染整个体系。公开课给的 6 步 pipeline：

① 找缺口（哪类 case 没覆盖：长输入？方言？对抗性提问？）
② 写生成 prompt（指定场景、口径、难度）
③ LLM 裁判先过一遍质量（不合格的丢弃）
④ 去重（embedding 相似度去掉换汤不换药的）
⑤ 难度打标（easy / medium / hard / adversarial 四层）
⑥ 版本化入库（记录生成模型、prompt 版本、日期）

🖼️ 多模态：先 preprocess，再喂模型

图片、音频、视频别一股脑塞给多模态模型 —— 又贵又不稳。生产套路是先用专门工具预处理成文本，再走标准 LLM 流程：

每个产物至少带 5 个 metadata 字段：来源、时间戳、处理工具、置信度、权限级别 —— 和 RAG chunk 的 metadata 纪律一致。

🦾 工具与 Agent：让 AI 不只回答，而是去干活

前面几章模型都只在"出文字"。但生产里 70% 的 AI 产品最终要让它去做事：查数据库、调 API、发邮件、订会议室。机制叫 Tool Use（Anthropic 叫法）或 Function Calling（OpenAI 叫法），核心一句话：模型不直接执行，它只说"我想调这个工具、参数是这些"，执行权在你的代码手里 —— 这就是安全边界。

User: "我们公司 2025 年总营收多少？"
  ↓ 模型看到你注册的工具列表，决定调用：
    query_database(sql="SELECT SUM(amount) FROM orders WHERE year=2025")
  ↓ 你的代码执行 SQL（做完安全检查），拿到 1250000
  ↓ 把结果塞回模型
  ↓ 模型："公司 2025 年总营收是 $1,250,000"

多步任务就是把这个过程包进 while 循环（叫 agent loop）。比如"下周一还有 10 人会议室能订吗"，模型会连调 4 个工具：查空闲时段 → 列 10 人会议室 → 交叉比对 → 下订单。代码骨架：

async function runAgent(query) {
  const messages = [{ role: 'user', content: query }];
  let res = await client.messages.create({ tools, messages, ... });

  let step = 0;
  while (res.stop_reason === 'tool_use' && step++ < MAX_STEPS) {  // 必须设上限！
    messages.push({ role: 'assistant', content: res.content });
    const results = await executeTools(res.content);   // 你的执行函数，带白名单校验
    messages.push({ role: 'user', content: results });
    res = await client.messages.create({ tools, messages, ... });
  }
  return res.content[0].text;
}

🔌 MCP：写一次工具，到处能用

MCP（Model Context Protocol）是 Anthropic 推的协议，2025 年已成事实标准。解决的问题：以前每个客户端（Claude Desktop / Cursor / 你自己的应用）都要重写一遍工具适配，MCP 让你 server 写一次，所有兼容客户端直接用。而且大量现成 server 拿来就用，不用造轮子：filesystem（文件读写）、postgres（SQL）、github（issue/PR）、slack（发消息）、playwright（浏览器自动化）。面试里"写过 MCP server"已经是一个加分信号 —— 这也是为什么第 17 章的项目 2 要求你写一个。

🏭 生产 Agent 的 5 个必答题

🔩 完整代码：从工具定义到一次往返

const tools = [{
  name: 'query_database',
  description: '执行 SQL 查询订单数据库。只允许 SELECT。',
  input_schema: {
    type: 'object',
    properties: { sql: { type: 'string', description: 'A SELECT-only SQL query' } },
    required: ['sql']
  }
}];

let response = await client.messages.create({
  model: 'claude-sonnet-4-6', max_tokens: 1024, tools,
  messages: [{ role: 'user', content: '我们 2025 年总营收？' }]
});

if (response.stop_reason === 'tool_use') {
  const tb = response.content.find(b => b.type === 'tool_use');
  const result = await db.query(tb.input.sql);        // 你执行（带白名单校验）
  const final = await client.messages.create({
    model: 'claude-sonnet-4-6', max_tokens: 1024, tools,
    messages: [
      { role: 'user', content: '我们 2025 年总营收？' },
      { role: 'assistant', content: response.content },
      { role: 'user', content: [{ type: 'tool_result',
          tool_use_id: tb.id, content: JSON.stringify(result) }] }
    ]
  });
}

多步任务实际跑起来什么样（订会议室，4 次工具调用一气呵成）：

User: "下周一的 AI 会议要 10 人会议室，还订得到吗？"

1. check_calendar_availability(date='下周一')   → 5 个空闲时段
2. list_meeting_rooms(capacity_min=10)          → 3 个 10 人房
3. cross_check(时段, 房间)                       → "Room A 14:00-15:00 可订"
4. book_room(room='A', start='14:00')           → booking_id=xyz
5. 生成回复："已订 Room A 14:00-15:00，编号 xyz"

这套"先想、再做、看结果"的循环有个名字叫 ReAct（Thought → Action → Observation），现代推理模型内部已经自带。但你要懂它 —— agent 卡住时让它把 thought 打出来，你能看到"它哪一步想岔了"，这是 debug agent 的入口。

🔌 MCP server：30 行写一个

from mcp.server import Server
from mcp.types import Tool, TextContent

server = Server("my-tools")

@server.list_tools()
async def list_tools():
    return [Tool(name="get_weather",
        description="Get current weather for a city",
        inputSchema={ "type": "object",
            "properties": { "city": { "type": "string" } },
            "required": ["city"] })]

@server.call_tool()
async def call_tool(name, arguments):
    if name == "get_weather":
        weather = await fetch_weather(arguments["city"])
        return [TextContent(type="text", text=str(weather))]

写完配置一下，Claude Desktop / Cursor / 任何兼容客户端都能直接用 —— 这就是"写一次到处用"。

🎨 工具设计原则（公开课 tool-design 章精华）

📦 Agent Skills 范式：2026 年值得押注的新抽象

Anthropic 推的 Skills 把"教 AI 干一类活"封装成一个文件夹，正在成为继 MCP 之后的又一个事实标准。理解它有个好类比：大模型是 CPU，运行时是操作系统，Skills 就是装在系统上的 App。

my-skill/
├── SKILL.md          # 怎么干这类活：流程、判断标准、红线
├── scripts/          # 可执行脚本（模型可以直接调）
├── templates/        # 产出物模板
└── data/             # 参考数据 / 例子

👥 Multi-Agent 与框架选型：什么时候值得上

💸 先看账单再谈架构：token 倍数表

所以行业共识是 80% 场景 Workflow（写死流程）就够了，路径能穷举就别上自主 agent。一个真实的对照案例：某电商客服从 200 多条规则的引擎迁到 Agent —— 规则维护成本降了 70%、长尾问题解决率从 45% 升到 82%，但 API 成本涨了约 3 倍。这买卖值不值，取决于长尾客诉对你值多少钱 —— 这种 trade-off 思维才是面试官要听的。

🕵️ Multi-agent 的真正价值：context 隔离，不是角色扮演

🧰 7 大框架一张表（公开课横评）

👥 多 Agent 协作：专业分工还省钱

单个 agent 干跨领域复杂任务效果差，拆给多个专业 agent 反而又好又便宜 —— 因为每个 agent 可以用最合适档位的模型：

            Coordinator（拆任务、派活）
           ／        ｜         ＼
   Research        Writer      Reviewer
   找资料+查RAG     写初稿       审事实+改格式
   用 Haiku(便宜快) 用 Sonnet    用 Opus(最严格)

总成本 < 让 Opus 一个人全干，质量还不降

框架选型：新手起步用 CrewAI（role 分工最直观、代码最少），要复杂状态机用 LangGraph，OpenAI 生态用 Swarm。

起步代码就几行（CrewAI）：

from crewai import Agent, Task, Crew

researcher = Agent(role="researcher", goal="...", llm="gpt-5-mini")   # 便宜快
writer     = Agent(role="writer",     goal="...", llm="claude-sonnet-4-6")  # 质量

crew = Crew(agents=[researcher, writer],
            tasks=[Task(description="...", agent=researcher),
                   Task(description="...", agent=writer)])
result = crew.kickoff()

CHAPTER 11

🧪 评估：怎么知道你的 AI 产品到底好不好

先把一个误区掰了：很多人以为 AI 工程师的日常是 fine-tune 模型。99% 的场景你不需要 fine-tune。它贵（一次几千刀）、慢（改数据就重训）、难回滚，还大概率被下一代基础模型直接反超。正确顺序是：先用 RAG + Prompt 把效果做到 80%，通常这就够用了。

🔬 Eval：AI 产品的"测试"，不做不能上线

不写测试的代码不能 ship，不做 eval 的 AI 产品也不能 ship。不做的后果很具体：prompt 改了一版，准确率从 90% 悄悄掉到 70%，没人发现，直到用户投诉。LLM 没法用传统断言测（"马尔代夫在哪"有一百种正确说法），所以分三档：

{ "input": "马尔代夫在哪？",
  "must_contain": ["印度洋"],
  "must_not_contain": ["大西洋", "太平洋"] }

📈 一张表看懂 eval 为什么值钱（真实数据）

最后上线的是 v2.0：质量略降一点，成本砍到 1/4。没有 eval，你根本做不出这种决策 —— 这张表就是"AI 产品工程化"和"拍脑袋调 prompt"的分水岭，也是面试讲项目时最值钱的素材。

🔧 真要 fine-tune：完整实操

数据准备是 JSONL，一行一条对话，100 条精挑的起步，质量远比数量重要（100 条干净的 > 5000 条噪声大的）：

{"messages":[{"role":"system","content":"..."},
             {"role":"user","content":"..."},
             {"role":"assistant","content":"理想回复"}]}

file = client.files.create(file=open('train.jsonl','rb'), purpose='fine-tune')
job = client.fine_tuning.jobs.create(
    training_file=file.id, model='gpt-5-mini',
    hyperparameters={'n_epochs': 3})
# 等几小时到几天，然后：
client.chat.completions.create(model='ft:gpt-5-mini:my-org::abc123', ...)

注意 fine-tuned 模型的推理价格通常是 base 的 2-3 倍。数据不能出公司的，走开源路线：单张 A100 80G 能跑 Llama 8B 的 QLoRA，5K 样本练 4-8 小时，推理用 vLLM 起服务。

⚖️ LLM-as-a-Judge：裁判 prompt 全文

你是一个公正的评估员。下面是用户问题、参考答案、被测答案。

问题：{question}
参考答案：{reference}
被测答案：{actual}

请按以下维度打 1-5 分：
- 准确性：被测答案和参考答案的事实一致性
- 完整性：是否包含所有关键信息
- 清晰度：表达是否清楚

只返回 JSON：{"accuracy": int, "completeness": int, "clarity": int}

裁判和人工评分的一致率在 80-90%，跟两个人类评审之间的一致率差不多 —— 所以生产 eval 默认用它。进阶用法（公开课 llm-judge 章）：多裁判投票去单裁判偏差、给裁判塞 rubric（评分细则）比裸打分稳、裁判输出也要抽查防"裁判幻觉"。

🔁 Regression：改 prompt 必跑，每天也跑

# .github/workflows/llm-eval.yml
on:
  pull_request:
    paths: ['src/common/prompts/**']   # prompt 文件一动就触发
jobs:
  eval:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm install && npm run eval
        env:
          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}

内部规矩：prompt 改动必须过 eval baseline 才能 merge。另外每天早上定时跑同一批 50 个 query —— 模型服务商悄悄升级底层时，分数漂移会先于用户投诉暴露出来（低于 baseline 5% 就告警叫人）。

🛠️ Eval 工具对照

🧑‍⚖️ 裁判也会偏心：5 类 bias 和对策（面试加分项）

LLM-as-a-Judge 好用，但裁判模型自己有系统性偏见。公开课整理的 5 类 + 对策：

两个保底动作：给裁判塞 rubric（评分细则）能把评测方差降 40-60%，比裸打分稳得多；关键评测用多裁判投票 + 人工抽查 10%，防"裁判幻觉"。一致性检验用 Spearman 相关 / Cohen's κ 对齐人工标注 —— 能说出这两个词，面试官就知道你真做过 eval。

🛡️ 生产部署：上线之后不挂的四件套

前面把"做出来"讲完了，这章讲"上线后不挂"。JD 里写的 "production experience"、面试问的"真的上过线吗"，考的就是这四样：Latency（快不快）、Cost（贵不贵）、Observability（出问题查得到吗）、Safety（挡得住坏人吗）。它们互相牵制 —— 压延迟通常涨成本，加安全又加延迟，工程师的活就是找平衡。

⚡ Latency：只要首字快，用户就觉得快

关键指标是 TTFT（首个 token 出现的时间）：500ms 以内体验极佳，超过 3 秒用户开始骂，超过 10 秒再也不来了。只要流式开着 + TTFT 小于 1 秒，哪怕全文要出 30 秒，用户主观感受都是"快"。优化按性价比排序：开 streaming（必做）→ 开 Prompt Caching（一行代码，延迟降一半）→ 砍输入 token（top-k 从 10 改 5、精简 system prompt）→ 简单任务换小模型 → 多个独立调用并发跑而不是串行（快 3 倍，注意别撞 rate limit）。

// Prompt Caching：就这一行的事
system: [{ type: 'text', text: longSystemPrompt,
           cache_control: { type: 'ephemeral' } }]   // ← 加这个

💰 Cost：从裸奔到全套优化，账单能降 60-80%

混合路由的思路：先用 Haiku 花 $0.0001 判断这个问题难不难，简单的留给 Haiku 自己答，难的才给 Sonnet。前提是算清盈亏点 —— 分类成本要远小于模型差价，否则别加这层。另外成本必须监控到"每个用户、每个接口"粒度，看到突涨马上查，一般不是被刷就是某个用户的查询异常。

🔍 Observability：LLM 应用的 debug 比传统难 10 倍

输出不确定、调用链长（改写→embedding→检索→重排→生成）、错误形态五花八门（拒答/幻觉/格式错/慢/贵）。标配是三层 trace：请求层（哪个接口、总耗时、总花费）→ 调用链层（embedding 80ms、检索 15ms、重排 180ms、生成 1.8s）→ 细节层（prompt 内容、token 数、缓存命中、TTFT）。必打的字段里最关键的一个：

{
  trace_id: 'abc-123',
  prompt_version: 'resume-analysis@1.2.0',  // ← 出问题能立刻定位是哪版 prompt 干的
  tokens: { input: 1500, output: 450, cached: 1200 },
  cost_usd: 0.012, latency_ms: 1820, ttft_ms: 380,
  feedback: null   // 用户点踩写这里，是 eval 集的天然来源
}

🚨 Safety：四道闸

把四件套拼起来，一个真正 production-ready 的 AI 接口长这样（伪代码，50 行装下全部）：

@Throttle(30/min)                          // ① rate limit
async chat(dto, user) {
  if (await moderate(dto.message).flagged)  // ② 输入审核
    throw new ForbiddenException();
  const clean = redactPII(dto.message);     // ③ PII 脱敏
  const chunks = await rag.retrieve(clean, {
    accessLevel: user.role, topK: 5 });     // ④ 检索带权限过滤
  const res = await trace(() =>             // ⑤ 全链路 observability
    retryWithBackoff(() => llm.chat({
      promptVersion: 'chat@1.2.0',          // ⑥ prompt 版本
      system: PROMPTS.chat.system,          // ⑦ caching 命中
      chunks, userMessage: clean })));
  if (await moderate(res.text).flagged)     // ⑧ 输出审核
    return { response: '抱歉，无法生成相关内容' };
  return { response: res.text };
}

📊 TTFT 体验基准（背这张表）

并发是最容易忘的免费优化（注意别撞 rate limit，入门档一般 50 RPM）：

// ❌ 串行：3 个独立调用排队跑
const summary = await llmCall(p1);
const tags = await llmCall(p2);
const sentiment = await llmCall(p3);

// ✅ 并发：快 3 倍
const [summary, tags, sentiment] = await Promise.all([
  llmCall(p1), llmCall(p2), llmCall(p3)
]);

💰 两个进阶省钱件：Batch API 和智能路由

Batch API：三家都有，半价，但 24 小时内才返回 —— 给"可以隔夜"的任务用（每晚的内容审核、离线评估、历史数据回填）。我们的 daily-eval 就走 batch，一个月省 $200。

智能路由：先用便宜模型花 $0.0001 判断难度，简单的自己答，难的才升级：

async function smartRoute(query) {
  const difficulty = await haiku.classify({
    system: '判断 query 难度：simple / complex',
    messages: [{ role: 'user', content: query }]
  });
  return difficulty === 'simple'
    ? await haiku.chat(query)      // 80% 走这
    : await sonnet.chat(query);    // 20% 走这
}

🩺 凌晨 3 点告警怎么排（debugging playbook）

"AI 接口时延突然飙到 30 秒" —— 这是面试真题也是迟早会遇到的真事故。排查顺序：

🔐 安全防护的落地代码

// 内容审核双向过
const inputCheck = await moderate(userMsg);
if (inputCheck.flagged) throw new Error('Input violates policy');
const response = await llm.chat(userMsg);
const outputCheck = await moderate(response);
if (outputCheck.flagged) return '抱歉，无法生成相关内容';

// PII 脱敏（送给模型服务商之前）
function redactPII(text) {
  return text
    .replace(/\b1[3-9]\d{9}\b/g, '[PHONE]')
    .replace(/\b[\w.-]+@[\w.-]+\.\w{2,}\b/g, '[EMAIL]')
    .replace(/\b\d{15}|\d{18}\b/g, '[ID]');
}

// 异常 query 监控（攻击的前兆）
const SUSPICIOUS = ['ignore previous', 'system prompt', 'admin password'];
if (SUSPICIOUS.some(k => userMsg.toLowerCase().includes(k))) {
  await alertSecurityTeam({ user_id, msg: userMsg });
}

安全建模的思维方式（公开课 security 章）：先画清楚 trust boundary（用户输入、检索内容、工具输出都是"不可信区"），然后在三个关口设防 —— 输入侧（审核 + 脱敏）、输出侧（审核 + 格式校验）、工具侧（白名单 + 权限 + 人工确认）。

🗺️ 安全建模：5 类威胁对照表（贴在工位上那种）

配套思维：把系统画成 5 层信任边界（用户输入 → 检索内容 → 模型输出 → 工具调用 → 外部系统），每条边界跨越处设一道检查 —— 这张图面试画出来比背十个名词管用。

🗄️ 数据治理：分级 + 保质期

配 TTL（保质期）纪律：临时文件 24 小时-7 天删、pipeline 中间结果 1-3 天删 —— "存着万一有用"是合规事故的标准开场白。

⚙️ 长流程自动化：state machine + 重试四件套

AI workflow 一旦超过三步（抓取 → 分析 → 生成 → 审核 → 发布），就该按状态机管理而不是一串 await：六个状态 pending → running → waiting_review → succeeded / failed → cancelled，每步落盘可恢复。重试策略四件套：最大次数（3 次封顶）、指数退避、幂等键（重试不会重复扣款/重复发邮件）、升级路径（重试用尽进死信队列叫人）。盯五个指标：队列积压、单步 P95 耗时、重试率、死信数、人工介入率 —— 还有全章最该记住的一个：cost per successful task（失败的重试也烧钱，按"成功一单的全成本"算账才真实）。

CHAPTER 13

⌨️ AI 编程工作流：这才是你每天 8 小时在干的事

前面 9 章讲的是"做 AI 产品"，这章讲"用 AI 干活" —— 2026 年的 AI Engineer 默认用 Claude Code / Cursor 写代码。这章全部是我们自己团队的实测数据和翻车记录，包括两个真实生产事故。

📊 先给数字：值不值？

注意第一个数字的另一半真相：首月 review 通过率是降的 —— 产出快了，质量闸必须跟上（见下文 5 道闸），否则只是把 bug 生产得更快。

🧰 工具分工：不是选一个，是各干各的

任务粒度决定用哪个：一行到一个函数 → Cursor 补全；一个文件内 → Cursor chat；跨文件一个 feature → Claude Code 整任务委托；探索式"这 bug 在哪" → Claude Code 开放调查。

📜 规则分层：让 AI 懂你团队的"宪法"

AI 编程工具的效果一半取决于你给它的规则文件。我们的真实分层（省 60% token 的来源）：

个人层   ~50 行    自己的口味：commit 风格、语言偏好
项目层   ~600 行   CLAUDE.md 团队铁律：架构边界、禁止事项、部署流程
         （反例：曾经写到 2000 行，每次对话白烧 5K token，砍到 600）
技能层   ~400 行/个  按需加载的 Skill：只在干对应活时才进 context

💥 两个真实事故（敢讲翻车才是真干过）

🚧 5 道质量闸（拿走就能用）

🎨 AI 产品思维：用户要的是 trust，不是 wow

很多技术好的 AI 产品死在体验上。核心认知一句话：AI 产品的 UX 竞争的是信任，不是新奇感 —— 用户第一次被惊艳，第二次就开始问"它说的对吗"。

🧩 四块 UX pattern（设计 AI 功能照这个清单过）

📐 该追的 5 个产品指标

任务成功率（不是"回答了"而是"解决了"）、refine 率（多少回答需要用户返工 —— 高了说明首答质量差）、放弃率（用户中途关掉）、反馈率（点赞点踩参与度，是 eval 集的天然来源）、来源点击率（用户验证你的引用 —— 这是信任的直接信号）。这 5 个指标接上第 11 章的 eval 体系，就是 AI 产品的完整质量闭环。

🎓 免费怎么学，付费怎么学（说实话版）

先把利益相关说在前面：这本书是匠人学院出的，我们有付费课。但下面这句话是真的 —— 自驱力强的人，靠免费内容完全够上岸。付费买的从来不是知识本身，是节奏、反馈和同侪。

🆓 免费路径（这本书技术部分的全部内容都免费有）

💰 付费阶梯（每一档买的是什么，说清楚）

📄 简历与面试：怎么写才像干过活的

"熟练使用 ChatGPT，能用 prompt 解决问题"
"了解 LangChain / LlamaIndex 等 AI 框架"
"对大语言模型有浓厚兴趣"

设计并上线内部知识库 RAG（Claude + pgvector + rerank）：
- 1200 份文档接入向量检索，日均 800+ 查询
- hybrid search + reranker 把准确率 71% → 92%
- prompt caching + 模型 routing 把月成本 $580 → $145

Production-Ready（能直接上手干的）：
  • LLM API: Anthropic SDK, OpenAI SDK
  • RAG: pgvector / MongoDB Atlas Vector Search
  • Embedding: OpenAI text-embedding-3, Voyage
  • Tool Use / MCP: 写过 5+ MCP servers
  • Prompt: 版本管理 + eval 驱动改进
  • Observability: Langfuse traces 配置
  • Production: rate limiting, PII redaction, caching

Familiar（了解过、写过 demo 的）：
  • Multi-Agent: CrewAI / LangGraph 写过 demo
  • Fine-tuning: 跑过 OpenAI fine-tune + Llama LoRA
  • Vision: GPT-4V / Claude Vision 简单用过

🎤 技术面试 5 大题型（全部带考察点）

🌏 哪里投（不只澳洲）

AI Engineer 是全球性缺口，渠道按你的目标市场组合：LinkedIn（全球通用，关键词盯 "AI Engineer"，开 actively looking）、Seek（澳洲本地一号）、Boss 直聘 / 拉勾（国内主战场）、Wellfound（全球 startup）、公司官网直投（绕过中介）、内推（所有市场都是最有效渠道）。在澳洲的话，这五类公司在集中招人：

✅ 30 天启动清单（打印 A4 版可打勾）

🧭 写在最后：工具会过时，这五样不会

AI Engineer 是要求变化最快的岗位，今天精通的工具半年后可能被替代。但这本书反复出现的五种能力，会用 5 到 10 年：写好 prompt、设计 RAG 和 agent 架构、做 eval、控制成本和延迟、防住滥用和隐私泄漏。具体用哪个向量库、哪个框架会变，原理不变。