夜雨聆风站在 2026 年 5 月回望，AI Engineering 从一个争议性概念变成了行业标配。算法岗位不得不回答一个问题：当「造模型」和「用模型」成为两种完全不同的工程范式时，算法岗位的定位是什么？
ML Engineer 在造引擎，AI Engineer 在造车。更准确地说——ML Engineer 在优化 loss function（损失函数），AI Engineer 在优化 user experience（用户体验）。这不只是分工变化，是工程范式本身的断裂。
0. 为什么这个区分不只是换 title
2023 年之前，如果你想做一个「AI 产品」，你需要一个 ML Engineer：写数据管道、调超参、训练模型、部署推理服务。整个链条的核心是模型本身。
2023 年之后，OpenAI 把 GPT-4 做成 API，所有人突然发现：你不需要造引擎了，你只需要知道怎么开这辆车。这不是渐进式演化，是范式断裂。
Chip Huyen 在《AI工程：大模型应用开发实战》（O'Reilly, 2024）开篇就点明了这件事：
"The model-as-a-service approach has transformed AI from an esoteric discipline into a powerful development tool that anyone can use."
这句话的潜台词是——AI Engineering 是一个全新的学科，不是 ML Engineering 的子集。
Applied LLMs（Eugene Yan 等 6 位一线实践者合著，2024）说得更直接：
"While the barrier to entry for building with AI has been lowered, creating products and systems that are effective—beyond a demo—remains deceptively difficult."
门槛降了，但天花板没降。只是天花板的位置变了。
到了 2026 年 5 月，The Pragmatic Engineer 发了重磅分析《State of the software engineering job market in 2026》，核心观点：AI engineering boom 仍在加速，同时 vibe coding 和 agentic engineering 正在融合——这意味着 AI Engineer 的角色边界还在持续扩展。
1. 本质分野：Model-Centric vs Model-API-Centric
ML Engineering 范式
↓
↓
↓
↓
↓
↩ 数据漂移触发重训
AI Engineering 范式
↓
↓
↓
↓
↓
↩ 根据评估结果调优 Prompt / Context
工业实例对比
ML Engineering 范式实例——Netflix 推荐系统
Netflix 的推荐引擎是典型的 ML Engineering 产出物。整个系统由数百个 ML 模型组成：用户画像模型、内容特征提取模型、协同过滤模型、排序模型。ML Engineer 的核心工作是：收集用户行为数据（播放、暂停、跳过、评分）→ 提取特征（用户偏好向量、内容属性向量）→ 训练排序模型 → A/B 测试 → 部署推理服务 → 监控模型衰减 → 数据漂移时触发重训。整个迭代周期以周计，因为重训一个大规模排序模型需要大量 GPU 时间。核心资产是训练数据和模型权重。
AI Engineering 范式实例——Klarna 客服 AI（2024）
瑞典支付公司 Klarna 在 2024 年部署了一个 AI 客服系统，基于 OpenAI 的模型。AI Engineer 的工作不是训练模型，而是：设计对话流程的 prompt 模板 → 接入公司知识库做 RAG → 定义 guardrails 防止越界回答 → 设计评估框架持续监控对话质量 → 根据用户反馈迭代 prompt 和检索策略。两个月内处理了 2/3 的客服对话，效果等同 700 名全职客服。核心资产是prompt 模板、知识库索引、评估 pipeline。
关键对比
总之：ML Engineer 的核心能力是「让模型学会」，AI Engineer 的核心能力是「让模型听话」。
2. Chip Huyen 的 10 章目录揭示了什么
直接看下《AI工程》的目录结构本身就是一份行业宣言。
《AI Engineering》目录结构（10 章）
★ 评估两章居前 · ◆ RAG+Agent 同章 · ▲ Fine-tune 在 Prompt 之后
可以看到：
- 评估占了两章（Ch3-4），排在 Prompt Engineering 之前。
这里的潜台词是：AI Engineering 的最大瓶颈不是「怎么构建」，而是「怎么知道它好不好用」。传统 ML 有 loss function 这个锚点；LLM 应用没有。你的输出是开放式的——一篇文章、一段对话、一个代码补全——你怎么判断它「对不对」？这个问题比技术实现难得多。 - RAG 和 Agents 放在同一章（Ch6）。
RAG 是给模型注入外部知识，Agent 是让模型自主调用工具。两者本质是同一件事：扩展模型的 context——不只是 token 层面的 context window，而是能力层面的 action space。 - Finetuning 排在 Ch7，而不是 Ch2。
这说明 Chip 认为：对 AI Engineer 来说，fine-tuning 是「高级手段」，不是「默认手段」。先试 prompt，再试 RAG，实在不行才 fine-tune。这是工程务实主义。
Applied LLMs 的作者们在同一思路上加了一个关键补充：
"Don't fall into the trap of 'AI Engineering is all I need'"
AI Engineering 解决应用层问题，但底层的数据工程、模型理解、系统架构能力仍然不可或缺。两者是互补，不是替代。
3. 评估：AI Engineering 的「死亡谷」
Chip Huyen 把全书前 40% 的篇幅给了评估。
3.1 为什么评估是最大的瓶颈
传统 ML 的评估有一个天然锚点：你有标签。分类问题看准确率，回归问题看 MSE，推荐系统看 CTR。指标是确定的、可量化。
LLM 应用的评估面对的是一个完全不同的问题：你的输出是开放式的自然语言。
你让模型写一段文案，「好」的标准是什么？ 你让模型回答一个医疗咨询，「对」的边界在哪里？ 你让模型做一次法律文书审查，「完整」怎么量化？
"The more AI is used, the more opportunities there are for catastrophic failures, and therefore, the more important evaluation becomes."
这形成了一个悖论：AI 能力越强，用的人越多，场景越复杂，评估越难，失败代价越大。
3.2 评估方法论的四层光谱
LLM 评估路径光谱
自动化 ↑ —————————— 可靠性 ↑
① 精确匹配
有标准答案时使用 · 局限性大
② 相似度评分
Embedding 距离 · 粗糙但可自动化
③ LLM-as-Judge
增速最快 · 有 position / verbosity bias
④ 人工评估
最可靠 · 最贵 · 边界案例必备
① 精确匹配（Exact Match）
适用于有标准答案的场景：信息抽取、结构化数据转换、代码生成（可跑测试验证）。其核心局限是：LLM 输出是自然语言，同一个意思有无穷种表达方式。「巴黎是法国首都」和「法国的首都是巴黎」语义完全相同，但精确匹配判为不匹配。
② 相似度评分（Similarity Scoring）
用 embedding 模型计算输出与参考答案的余弦相似度。优点是可完全自动化、成本低。缺点是粗糙——embedding 空间的「近」不等于语义上的「对」。一段完美但措辞不同的答案可能得分低，一段有事实错误但用词相似的答案可能得分高。
③ LLM-as-Judge（用 LLM 评判 LLM）
这是 2024-2026 年增长最快的方向。核心思路：用一个更强的 LLM（通常是 GPT-4 或 Claude）评判另一个 LLM 的输出质量。
Chip 在书中详细分析了 LLM-as-Judge 的三种偏差：
- Position Bias（位置偏差）
：Judge 倾向于选择排在前面的选项。你把 A 放第一个和把 B 放第一个，结果可能不同。 - Verbosity Bias（冗长偏差）
：Judge 倾向于认为更长的回答更好，即使短回答更准确。 - Self-Enhancement Bias（自我增强偏差）
：GPT-4 作为 Judge 时，倾向于给 GPT-4 自己的输出打更高分。
Applied LLMs 的作者们对此的评价非常清醒：
"LLM-as-Judge can work (somewhat), but it's not a silver bullet."
他们的实践建议是：不要用 LLM-as-Judge 替代人工评估，而是用它做初筛——大规模自动化筛选出可疑输出，然后人工复核边界案例。
"Simplify annotation to binary tasks or pairwise comparisons."
与其让标注员给输出打 1-5 分（主观性强、一致性差），不如问两个简单问题：「这个回答是否可接受？」或者「A 和 B 哪个更好？」——二元判断的一致性远高于多级评分。
④ 人工评估
最可靠但最贵。Chip 的建议是：不要试图用人工评估覆盖所有 case，而是聚焦在三类场景：新功能上线前的 gate review；自动化评估标记出的边界案例；定期的随机抽样质量审计。
3.3 评估不是技术问题，是流程问题
的最大敌人不是方法论缺失，是流程缺失。
Production 评估流程（Applied LLMs）
↓
↓
↓
↓
↩ LLM-as-Judge 救不了产品 · 修流程才是护城河
"An LLM-as-Judge Won't Save The Product—Fixing Your Process Will."
- 「The intern test」（实习生测试）
：如果你公司的实习生能通过看输出发现问题，那你的评估流程就缺了基本功。很多团队花大量精力搞自动化评估，却连每天看 10 个真实输出这种基础工作都不做。 - 过度优化某些 eval 会伤害整体性能
：如果你只盯着某一个指标（比如 faithfulness），可能在其他维度（比如 helpfulness）上退化。评估需要平衡。 - Reference-free evals 和 guardrails 可以互换使用
：不需要参考答案的评估方法（比如检查是否有害、是否包含敏感信息）和 guardrails 本质上是同一件事，可以用同一套系统实现。
3.4 真实工业中的评估实例
Case 1：医疗 AI 的评估困境
某医疗科技公司用 LLM 辅助医生写病历摘要。评估标准包括：准确性（不能遗漏关键诊断信息）、简洁性（不能冗长）、合规性（不能包含未确认的诊断）。他们发现：精确匹配完全不适用；相似度评分有帮助但不可靠；LLM-as-Judge 表现最好，但需要精心设计 rubric，且 Judge 模型需要定期更换以避免 self-enhancement bias。最终方案：LLM-as-Judge 做日常监控 + 每周人工抽检 50 个 case 做校准。
Case 2：金融风控 AI 的评估实践
某银行的 AI 系统用于审查贷款申请材料的一致性。评估维度：事实一致性、完整性、合规性。他们的做法：构建了 500 个标注过的 golden test set；用 assertion-based unit tests 覆盖明确规则；用 LLM-as-Judge 处理模糊判断；每次模型升级前跑完整测试集，任何指标下降 >2% 就阻断发布。
这就是 AI Engineering 真正的护城河。 Prompt 谁都会写，RAG 谁都会搭，但能在 production 中持续验证和改进系统质量的团队才称得上有可持续发展观。
4. Agent：从「调 API」到「造系统」的临界点
如果 RAG 是 AI Engineering 的「Hello World」，Agent 就是它的分水岭。
4.1 Agent 的定义与架构
Chip 在 Ch6 中把 Agent 定义为：
"An agent is anything that can perceive its environment and act upon that environment."
这个定义来自经典 AI 教科书，但用在 LLM 语境下有了新含义——Agent 的「感知」是读取用户输入和工具返回，「行动」是调用 API 和执行代码。
Anthropic 在 2024 年 12 月发布的《Building Effective Agents》中做了一个重要区分：
"Workflows are systems where LLMs and tools are orchestrated through predefined code paths. Agents, on the other hand, are systems where LLMs dynamically direct their own processes and tool usage, maintaining control over how they accomplish tasks."
这个区分至关重要：Workflow 是人在设计流程，Agent 是模型在设计流程。
Agent 核心循环
↓
↓
↓
↓
↓
↓
↩ 多轮迭代
感知 = 用户输入 + 工具返回 · 行动 = API 调用 + 代码执行
整体行为不可从单步推导 → 需要评估框架
4.2 Agent 的失败模式
Chip 指出了 Agent 的三类失败模式，每一类都值得深入：
规划失败（Planning Failures）
"Invalid tool: the agent generates a plan with a tool that isn't in the tool inventory. Valid tool, invalid parameters: it calls a tool with wrong parameters. Valid tool, incorrect parameter values: it calls with right parameters but wrong values."
还有一种更隐蔽的失败——目标失败（Goal Failure）：Agent 未能达成目标，或解决了任务但没有遵循约束条件。例如：规划从旧金山到印度、预算 5000 美元的两周旅行，Agent 可能给你规划去越南，或花销远超预算。还有一个常被忽视的约束是时间——截止日期之后才完成，那就没什么用。
工具失败（Tool Failures）：调用不存在的工具；参数格式错误；工具返回异常但 Agent 没有处理；工具选择不当（应该用计算器却用了搜索引擎）。
效率问题（Efficiency）：不必要的多轮调用；重复计算；每次调用都用最贵的模型。
4.3 深层问题：当 Engineering 遇到涌现性
这里有一个深层问题值得展开：当你的系统行为不可完全预测时，「engineering」的含义本身在变。
传统软件工程建立在确定性之上：给定输入，输出是确定的。ML Engineering 引入了统计不确定性：给定输入，输出是概率分布。AI Engineering（尤其是 Agent）引入了涌现不确定性：系统的整体行为不能从单个组件的行为推导出来——你给 Agent 一个任务，它可能用 3 步完成，也可能用 30 步，可能做得很好，也可能完全跑偏。
"Create a planning dataset where each example is a tuple (task, tool inventory). For each task, use the agent to generate a K number of plans."
然后计算：生成的计划中有多少是有效的？对一个任务，Agent 需要生成多少个计划才能得到一个有效计划？所有工具调用中有多少是有效的？无效工具被调用的频率？有效工具被错误参数调用的频率？
这意味着：你不能用传统 QA 的方式验证一个 Agent 系统。 你需要的是评估框架（evaluation framework），不是测试用例（test cases）。
5. 技能栈对比：数学深度 vs 工程广度
ML Engineer 技能栈
深度在底部 ↑
AI Engineer 技能栈
广度在顶部 · 自上而下 ↓
ML Engineer 的深度在底部——理解梯度下降、attention 的数学本质。
AI Engineer 的广度在顶部——模型能力边界、用户需求、系统架构、安全合规、成本控制。
ML Engineer 像机械工程师，需要精确计算每个零件的应力。AI Engineer 像建筑师，需要协调结构、功能、美学、成本、法规——单个维度的深度可能不如机械工程师，但综合复杂度更高。
6. 组织冲击：谁在招什么人
岗位变迁时间线
- 2018-2022
：ML Engineer 需求爆发，核心职责是把 research 论文变成 production 系统。 - 2023
：AI Engineer 岗位哑光亮登场。 - 2024
：Chip Huyen 出版《AI Engineering》，给这个角色建立了完整的学科框架。 - 2025
：AI Engineer 成为主流岗位，各大公司（包括非科技公司）开始大规模招聘。 - 2026 年 5 月
：The Pragmatic Engineer 最新数据显示 AI engineering boom 仍在加速，vibe coding 和 agentic engineering 正在融合。
行业分工两层架构
Foundation Model Provider
OpenAI · Anthropic · Google · Meta · 字节 · 阿里
训练 · 对齐 · 推理优化
↓ API ↓
Application Layer
所有调用 API 的公司
AI Engineer（主力）
Prompt · RAG · Agent · 评估 · 集成
少量 ML Engineer
Fine-tune · 领域模型 · 数据管道
2026：AI Engineer 岗位增速 > 纯 ML Engineer
很多 AI Engineer 的实际工作是「高级 prompt 调参」。但这不代表这个角色技术含量低——正如很多后端工程师的实际工作是「高级 CRUD」，但能写出高可用、高性能、可维护的后端系统的人极少。
AI Engineer 的真正价值不在 prompt 本身，在围绕 prompt 构建的整个工程体系：评估、监控、安全、成本优化、用户体验、harness工程。 Prompt 只是冰山一角。
2026 年的新变化
到 2026 年 5 月，出现了几个新趋势：
- Vibe coding + Agentic engineering 融合
：开发者不再手动写每一行代码，而是用自然语言描述意图，AI Agent 生成代码、跑测试、修复 bug。这模糊了「写代码」和「用 AI」的边界。 - Forward-deployed engineering 回潮
：大厂重新重视「驻场工程师」角色——不是写代码，而是深入客户现场，用 AI 工具快速搭建定制化解决方案。这本质上是 AI Engineer 的商业化形态。 - AI 用量成本失控
：多位 Pragmatic Engineer 读者报告 token 支出暴涨，成本优化从「nice to have」变成「生存问题」。这催生了 AI Engineer 的一个新子方向——LLM Cost Engineering。
7. 对从业者的务实建议
已经是 ML Engineer 的人
不要慌。 你的底层能力（数据思维、系统设计、工程严谨性）是 AI Engineer 最缺的东西。你需要补的是：
理解 foundation model 的能力边界（不需要理解训练细节，但要理解推理行为） 学会 prompt engineering（这比你想象的需要更多技巧） 掌握评估方法论（这是你在新世界最大的差异化优势）
你比纯软件工程师转 AI Engineer 有天然优势——你理解「模型不是确定性的」这件事的心理模型。很多纯 SWE 转过来的人会本能地用确定性思维去套 LLM，然后被现实反复打脸。
想入行的人
学习路径对比
传统 ML · 自下而上 ↑ ↑ ↑ | AI Engineering · 自上而下 ↓ ↓ ↓ |
入行建议：不要从 fine-tuning 开始
不要从 fine-tuning 开始。 从 prompt engineering 和 RAG 开始，建立对模型能力的直觉，然后往 Agent 和评估方向深入。
AI Engineering 的技能树是自上而下的——先学会用，再学会造。这和传统 ML 正好相反（传统 ML 是自下而上：先学数学，再学算法，再学框架，最后才做应用）。
Applied LLMs 的作者们给出的最务实建议：
"Choose the smallest model that gets the job done."
没必要一上来就用最强模型。 先用小模型跑通流程，评估效果，确认瓶颈在哪里，再决定是否升级模型。很多人把 80% 的精力花在选模型上，但实际上 prompt 设计和 context 构建对效果的影响远大于模型选择。
给团队负责人
别把 AI Engineer 当成「会写 prompt 的软件工程师」。 这个角色需要的综合能力包括：产品直觉、系统架构、数据工程、评估科学、安全合规。它更像是一个「技术产品经理+系统架构师」的混合体。
招人的时候，不要看他能不能写出惊艳的 prompt——那东西半小时就能学会。看他能不能设计出一个可持续迭代、可评估、可监控的 AI 系统。
8. 结语：范式断裂之后
每一次技术范式的断裂，都会重新定义「工程」的含义。
「工程」含义的范式迁移
机械工程
马车修理 → 内燃机
↓
软件工程
桌面 → 分布式
↓
AI 工程
训练 → 应用
模型成为基础设施 → 重心从「造模型」转向「用模型造产品」
汽车发明后，机械工程从马车修理变成内燃机设计。 互联网出现后，软件工程从桌面应用变成分布式系统。 Foundation Model 出现后，AI 工程从模型训练变成模型应用。
AI Engineering 不是 ML Engineering 的降级版，是它的后继者。 正如 ML Engineering 不是 Data Science 的降级版，而是它的后继者。
核心洞察只有一句话：当模型本身变成基础设施，工程的重点就从「造模型」转向「用模型造产品」。 谁能最快完成这个认知切换，谁就站在下一波浪潮的前面。
