AI Engineering Roadmap

导言

这份六页 PDF 与其说是“学习路线图”，不如说是一套 AI 应用工程判断法：先找到结构化、问答、摘要等能交付价值的任务；承认模型输出有波动；把真实用户反馈变成评测集；最后只在评测证明简单方案不够时，逐步增加检索、工具、工作流、Agent 或微调等复杂度。

本文逐页解释图中的观点，同时区分三件事：页面明确表达了什么、它对工程实践意味着什么、哪些口号不能按字面当成技术事实。原 PDF 没有附数据集、实验方法或参考文献，因此曲线和阶梯只能当作概念图，而不能当成性能证据。

{ width=100% }

自绘小黑示意图：先明确任务，把用户失败样本送回评测；只有评测证据证明“简单方案不够”，才打开更复杂、更昂贵的下一阶。

六页共同主线

六页可以串成一个闭环，而不是六张互不相干的海报：

1. 先选任务：判断 LLM 适合承担哪些输入到输出的转换。
2. 尽快交付基线：首版的意义是获得真实反馈，不是证明方案已经成熟。
3. 接受实验波动：换模型或加技巧可能退化，单次演示不能代表稳定质量。
4. 建立评测飞轮：把目标、失败样本和用户反馈编译成可重复评测。
5. 识别系统模式：RAG、工具调用、结构化输出、Workflow 与 Agent 都是在改变模型可见上下文或可执行动作。
6. 按证据升级：从最简单的调用开始，只有当前瓶颈被评测确认后才增加复杂度。

这条主线最有价值的地方是把 AI Engineer 的工作重心从“追逐最新模型和术语”，移到 定义成功、构造反馈、控制实验和管理系统复杂度。

第 1 页：LLM 真正适合什么

第一页标题是 *What Are LLM’s Useful For?*，副标题刻意反对 hype，列出六类朴素的企业用例：

• 数据结构化：把文本、图片或文件里的字段提取成数据库可接收的记录。
• Agent：让模型通过外部 API 对现实系统执行动作。
• 问答：接入外部数据源，根据用户问题组织答案。
• 摘要：把长文本压缩成更短的表达。
• 分类与标注：给文件或记录添加标签，便于检索、路由和统计。
• 翻译：把内容从一种语言转换到另一种语言。

页面在强调什么

六项任务看似不同，实际上围绕三种能力展开：变形、判断和行动。摘要、翻译、字段提取属于输入到输出的内容变形；分类和问答需要基于上下文做判断；Agent 则把判断接到 API，使输出不再只是文本，而能改变外部状态。

这也解释了副标题里的商业判断：企业更容易为 可嵌入既有流程、输入输出清楚、节省人工步骤 的能力付费，而不是为一次惊艳但不可重复的聊天演示付费。真正的产品单位不是“调用一次 LLM”，而是一个有输入契约、输出契约和失败处理的业务步骤。

不能照字面理解的地方

PDF 没有提供收入、客户数量或 ROI 数据，因此“这些用例正在赚钱”是作者的经验性主张，不是页面证明的统计结论。六项也不是封闭清单：代码生成、信息检索、内容审核和多模态理解都可以拆进这些基本动作，但是否产生价值仍取决于准确率、风险和集成成本。

“Agent 等于 LLM 加 API”也只是最小直觉。生产系统还需要权限、幂等、超时、审计、人类确认和回滚；否则模型能够调用 API，并不等于它能够安全地完成业务事务。

第 2 页：好应用来自反馈与评测

第二页 How Good AI Apps Get Built 画了一条先降后升的折线。左半段叫 Vibes-Only Trough：首版发布后表现不好，团队凭感觉换了一个模型，结果反而更差。右半段叫 Eval Slope：加入赞踩和用户反馈后，团队建立评测；新模型先过评测，线上数据也不断回流，质量才持续改善。

页面在强调什么

这页反对的是 vibe-based development：看几个案例、觉得新模型更聪明、就直接替换生产配置。因为提示词、模型版本、检索结果和工具路径相互耦合，新模型在公开榜单上更强，也可能在你的数据分布上退化。

折线中的真正转折点不是“换到了更好的模型”，而是团队开始积累三种资产：

1. 用户信号：赞踩、人工纠正、重试、放弃和升级到人工等行为。
2. 失败样本：能稳定复现错误的输入、上下文、系统版本和期望结果。
3. 评测规则：把“好不好”转换成可重复的判定、评分或业务指标。

OpenAI 把这套过程概括为 Specify → Measure → Improve：先定义什么叫好，再在真实条件下测量，最后从错误中改进；其中真实样本、罕见但高损失的边界案例和领域专家审核都很重要。[^openai_evals]

工程上的落地

一个最小评测记录至少应保存：

case_id
input
required_context
expected_behavior
forbidden_behavior
model_and_prompt_version
tool_or_retrieval_trace
grader
score
failure_reason

赞踩本身不是 ground truth。用户可能因为语气、速度或结果不合预期而点踩，所以仍需抽样复核并标注失败类型。最稳妥的做法是把线上反馈转成候选用例，由领域专家确认后再进入回归集。

第 3 页：AI 工程是一门实验工程

第三页 AI Engineering Is Experimental 用一条剧烈波动但长期向上的曲线表示质量随时间变化，并说明：LLM 具有概率性，工程师需要频繁试验新技术，而多数试验不会成功。

页面在强调什么

局部失败与长期进步可以同时成立。一次提示词修改、模型替换、检索参数调整或工具重构都可能让某类样本变好、另一类样本变坏。团队的能力不在于避免所有失败，而在于让失败变得便宜、可观测和可回滚。

因此每次实验都应固定：基线版本、代表性数据、评价标准、成本与延迟口径、随机性设置和回滚条件。没有这些控制变量，曲线上的升降只能说明“结果变了”，不能说明是哪项改动造成的。

图的证据边界

这是一张示意图：横轴只有时间，纵轴只有质量，没有刻度、样本量、误差条或数据来源。图中粉色叉号可以理解为未奏效的实验，但不能据此推断失败率、质量增速，或“波动会随时间增大”。作者在表达工作形态，不是在报告实验结果。

正确接受失败

“多数实验不工作”不等于可以随意试。恰恰相反，失败率高意味着更需要小改动、版本化、离线评测、灰度发布和可回滚配置，让每次失败都贡献一条可复用证据。

第 4 页：评测是产品飞轮的中枢

第四页 It’s The Evals, Stupid 把 Evals 放在中心。上方有两个外部变化：新的 Prompt/System Design 技巧和新模型出现；它们都先通过评测。评测改善产品，产品带来分发，分发增加使用，使用产生数据，数据再回流到评测。

页面在强调什么

评测有两个方向：

• 防守方向：模型、提示词、检索器或工具升级时，检查旧能力是否回归。
• 进攻方向：从用户失败中发现新的质量维度，把产品经验沉淀成下一轮优化目标。

这就是为什么页面把 eval 称为 AI Engineer 的“单元测试”。类比的准确部分是：两者都能固定预期、重复运行、拦截回归。类比不准确的部分是：生成式系统的输出通常不是唯一字符串，Agent 还会跨多轮调用工具并改变状态，因此评测常要结合确定性检查、规则评分、模型评分、人工审核、轨迹检查和业务结果。

Anthropic 对 Agent 评测的总结也强调，多轮工具调用、状态变化和中间结果使其比单轮问答更难评估；有效方案通常要组合多类 grader，并审计评测任务本身是否公平。[^anthropic_agent_evals]

飞轮成立的条件

图中“使用 → 数据 → 评测”的箭头不会自动发生。只有满足以下条件，使用量才会变成质量资产：

1. 日志能关联输入、模型版本、检索内容、工具轨迹和最终结果。
2. 用户反馈经过隐私、权限和保留周期治理。
3. 失败被归因成可行动类别，而不是只统计平均分。
4. 评测集保持代表性，并防止团队只优化已知题目。

否则更多分发只会带来更多未整理日志，并不会自动形成数据飞轮。

第 5 页：术语背后都是上下文与控制

第五页 It’s All Prompt Engineering 把六个热门术语解释成对 prompt 或调用过程的扩展：

页面术语	页面给出的直觉	更严格的工程解释
RAG	从某处取信息，放进 prompt	检索器从外部知识源选择证据，生成器基于问题与证据回答；原始 RAG 工作还显式区分参数化与非参数化记忆。[^rag]
Tool Calling	给 LLM 一份可执行 action 菜单	模型输出结构化调用意图，运行时校验参数、执行 API，再把结果送回模型。
Structured Outputs	要求 LLM 返回指定形状	通过 schema 约束或校验输出，使下游程序能可靠消费；失败时仍需拒绝、重试或修复策略。
Workflows	多次 LLM 调用，停止点写死	代码预先规定步骤、分支和停止条件，模型只完成其中的局部判断。
Agentic Loop	工具结果回到 prompt，LLM 决定何时停	模型在“计划/行动/观察”循环中动态选择工具和下一步，同时受权限、步数和终止守卫约束。
Reasoning	用 thinking 标签促使模型思考	对现代 reasoning model，推理通常还是模型能力和结构化 effort/mode 控制；不能把可见标签当作通用实现。

页面在强调什么

作者想做的是 去神秘化：这些模式最终都会改变下一次模型调用所看到的消息、可用动作或停止条件。用这个视角，RAG 是先检索再补上下文；Tool Calling 是把动作描述给模型并回送执行结果；Workflow 和 Agentic Loop 则决定由代码还是模型控制下一步。

Anthropic 给出了一个很有用的严格区分：Workflow 的路径由预定义代码编排，Agent 的过程与工具使用由模型动态决定。两者都属于 agentic system，但在可预测性、灵活性、延迟和成本上不同。[^anthropic_agents]

标题为什么不能照字面接受

“都是 Prompt Engineering”是教学压缩，不是系统边界。RAG 需要索引、检索和证据治理；工具调用需要执行器、权限和副作用控制；结构化输出需要 schema 与解析；Agent 需要状态、循环、预算和审计。这些组件会影响正确性，即使最终结果都进入模型上下文，也不能把它们缩减成“把提示词写好”。

同样，RAG 论文证明的是检索增强生成在其知识密集型任务与实验设置中的效果，并不证明任意数据库接入都能提高质量。[^rag] 本页适合作为术语地图，不足以替代每种机制的独立设计与评测。

第 6 页：从最简单方案开始

第六页 The Staircase To Optimization Hell 给出一条由浅入深的阶梯：Zero-Shot、Few-Shot、Chain of Thought、Temperature、Workflows、Evaluators、Agentic Loops、LLM Routers、Fine-Tuning、Sampling。页面建议：开发新功能时从顶部开始，向下每一步都更复杂、更昂贵。

页面在强调什么

它表达的是一个很好的默认策略：先证明问题，再为瓶颈付费。可以把阶梯重写成一组带退出条件的实验：

1. Zero-Shot：只给清晰目标、上下文、约束和输出格式；若已达标就停止。
2. Few-Shot：当错误来自风格、边界或映射不清时，加入少量代表性示例。
3. 推理与采样控制：当任务需要多步判断或稳定性分析时，比较 reasoning effort、temperature 或多样本策略的质量—成本变化。
4. Workflow 与 Evaluator：当任务可以分解、存在明确中间检查或可迭代改进时，引入固定编排和评价器。
5. Agent 与 Router：只有步骤无法预先写死，或任务分布确实需要按能力/成本路由时，才让模型获得更大的控制权。
6. Fine-Tuning：当稳定的大规模数据证明行为差距无法通过上下文和系统设计解决，并且收益能覆盖训练、部署和维护成本时再考虑。

阶梯不是普遍成本排名

图中的顺序适合作为 复杂度警告，但不是严格的技术偏序：

• 普通 temperature 调节几乎没有系统复杂度，位置未必应低于 Chain of Thought。
• Router 可能增加架构复杂度，却通过把简单请求送给小模型来降低单次成本。
• Fine-Tuning 前期成本高，但在高吞吐、稳定任务上可能减少长 prompt 和重复推理成本。
• Sampling 如果只是常规解码并不比微调复杂；如果指 Best-of-N、多候选投票或搜索，成本才会随样本数增长。
• 对现代 reasoning model，直接要求输出长 Chain of Thought 未必是最佳控制方式；更稳妥的是固定任务目标，通过模型支持的 reasoning effort/mode 做同任务对照评测。[^openai_reasoning]

因此不要机械地“走完十级”。正确做法是：每一级都先写出它针对的失败类型、预期改善、额外成本和停止条件。没有失败证据，就不下楼。

可执行路线

把六页合成项目流程，可以得到一张更稳健的 AI Engineer 工作清单：

1. 定义任务契约：输入是什么，输出给谁消费，哪些错误不可接受。
2. 建立最小基线：用最简单的模型调用完成端到端路径，记录质量、延迟和成本。
3. 收集真实失败：上线受控入口，保存可复现的输入、上下文、版本和结果。
4. 建设评测集：覆盖常见样本、关键边界和高损失失败；组合确定性、模型和人工 grader。
5. 单变量实验：一次只改变模型、prompt、检索、工具或编排中的一个主要因素。
6. 评测后升级：只有新方案在代表性用例上通过质量、延迟、成本与风险门槛才推广。
7. 持续回流：把线上新失败转成回归用例，让产品经验成为团队的长期资产。

最容易误读的两句话

“一切都是 Prompt Engineering” 不应被理解为基础设施不重要；它只是在提醒我们追踪“什么进入上下文、谁控制下一步”。“越往下越贵” 也不是固定排名；真正的比较对象是同一任务、同一评测集上的边际质量收益与全生命周期成本。

总结

这份 PDF 最核心的观点不是“AI Engineer 应该学哪些名词”，而是：

• 价值从明确、可集成的任务产生。
• 质量从反馈、评测和受控实验产生。
• 复杂度必须由失败证据和评测收益来证明。

如果只记住一句话，可以记成：先让一个简单方案跑通，再让真实失败教你下一步该加什么。

参考资料

• Matt Pocock, AI Engineer Roadmap, 用户提供的 6 页 PDF，文件元数据显示创建于 2025-03-27；本文逐页视觉核对，原始文件 SHA-256 为 52bed19e34f54246fddcbf05d3781f2a9a2c07b95ba0020c91f884deef593b09。
• AI Hero：PDF 页脚标注的作者站点。

[^openai_evals]: OpenAI, How evals drive the next chapter in AI for businesses。该文把上下文化评测概括为 Specify、Measure、Improve，并强调真实样本、边界案例与领域专家。
[^anthropic_agent_evals]: Anthropic, Demystifying evals for AI agents。
[^rag]: Patrick Lewis et al., Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks，2020。
[^anthropic_agents]: Anthropic, Building effective agents。
[^openai_reasoning]: OpenAI, Model guidance。官方建议在相同代表性任务上比较 reasoning 模式的质量、token、延迟和成本，而不是在 prompt 中要求模型“更努力思考”。