AI 工程师角色画像：愿景、边界与祛魅

与 tech 线《FDE 认知》模块的区别：那门课讲国内语境下 FDE 岗位怎么干；本课用全球市场数据回答"这个角色到底是什么、不是什么"——先看清全球共识，再谈中国打法。

开场钩子

一位从业者(@thewhychain)的原话：

"我入职过两次 'AI engineer' 岗位。JD 里写的是 RAG 和 embeddings，实际工作是 80% 提示词工程 + 胶水代码 + 监控。那些 JD 描述的是野心，不是你每天干的事。"

这节课给你三样东西：角色的核心定义、不是什么、以及 JD 与现实之间的落差地图。看完你就能判断：一个岗位、一个项目、一段经历，到底是不是真正的 AI 工程。

AI 工程师的核心责任是把 AI 集成进产品：

即使简单到"从图片里抽取属性"这种用例，专业做法也远超一次 API 调用：

这十条就是"原型思维"与"生产思维"的分界线。评估（第 1–3 条）是其中被验证最多的差异化能力。

FDE 报价和排期时，用这个阶梯估工作量——客户说"就是个 RAG"和"就是个调用"之间差 5 倍。

与 ML 工程师：职责高度相似。区别只在模型归属——ML 工程师拥有模型权重，AI 工程师通过 API 用第三方模型。把"调用本地模型"换成"调用 OpenAI"，其余一样。这是转型成本最低的路径，ML 工程师只需补：评估能力。

与数据科学家：数据科学家聚焦模型创造（翻译需求为 ML、设计数据集、训练）；AI 工程师做科学+工程但没有真正的建模——模型已经存在，大部分精力在提示词调优而非模型训练。数据科学家要补的是工程能力（测试、CI/CD、部署）。

AI 工程师不做的：从零造模型、定制模型架构、重度特征工程。

AI 工程师聚焦的：AI 系统的工程最佳实践、提示词设计与版本化、AI 与产品的集成、评估与监控。

在大型组织里：AI 职责常由现有数据科学家（提示词调优、验证框架）+ ML 工程师（工程化、部署）分担，最终才会专职招聘 AI 工程师。LLM 不是万能解，传统 ML 工作仍在继续。

一线从业者报告的三类真实工作形态：

编排者（约 50%）：RAG 管道、向量库、agent 工作流——带长期记忆的本地助手、Slack 会话问答、线框图转 UI 的 agent、多租户后端（每用户向量命名空间 + token 预算）
评估专家（约 40%）：LLM-as-judge、黄金数据集、幻觉检测、生产指标（Recall@K、每查询延迟、每千次请求成本）
效率包装者（约 10%）：语义缓存、token 优化、多提供方限速兜底、模型路由（简单任务用便宜模型）

日常与假设的对照：

你以为	实际
整天写提示词	写根据上下文动态生成提示词的代码
调 OpenAI API	建带兜底、监控、成本追踪、多提供方的系统
训练模型	很少。用预训练模型 API 或开源权重
在 notebook 里工作	迁向生产 API（FastAPI/Go）+ Docker + CI/CD

真实的调试循环：为什么 LLM 在 50 步 agent 链里无视了某条指令？哪个检索块导致了幻觉？如何在不伤质量的前提下压缩 token？多提供方限速怎么兜？

"复合岗"问题：很多 "AI Engineer" 实际是 ML 工程师 + MLOps + 数据工程三合一，或才是真正的 LLM 编排。看职责，别看 title——带 "platform" 或 "data" 的 title 基本是抛硬币。

B4 趋势研判与战略卡位：全球数据确认"评估"是差异化技能、Agent/集成是主流形态。FDE 给自己定位时，避开"训练模型"叙事，主打"生产交付 + 评估"。
D2 沟通翻译与预期管理：向客户解释"AI 工程师不是调 API 的"，就用第二节那十项工程化动作——它们正是报价单上该列的工作项。
S2 场景定义与要素拆解：复杂度阶梯（调用/RAG/Agent）是场景拆解时估算工作量的通用标尺。