2026 年 8 月 14 日至 9 月 11 日，吴恩达（Andrew Ng）与 DeepLearning.AI 连发五封信，用一万多条职位发布、数十场专家与招聘经理访谈、以及问卷数据，"聚类"出一张《AI 工程技能地图》（The AI Engineering Skills Map）。
地图回答的是"该学什么"，却很克制地不回答另一个问题：从哪一格开始学？学到什么程度算够？
这篇是它的落地版。三个交付物：
- 一张 20 格自评表（四大顶层能力 × 全部细分项，每格一句"过关判定问题"）；
- 逐格的 "学什么—怎么练—什么算过关" 路径；
- 一份 12 周计划表 + 三个必做项目 + 七个反模式。
阅读前请先分清两类内容：细项定义、引用、方法论全部来自吴恩达原文（文末附来源）；自评表的判定问题、12 周计划、练手项目的验收标准是本文为教学目的所做的延伸设计，不是吴恩达官方口径。站内已有一篇从"是什么/可不可信"角度写的深度研究（《吴恩达〈AI 工程技能地图〉全解》），建议作为前置阅读，本篇不重复那部分论证。
一、3 分钟看懂地图
1.1 四大顶层能力
| 顶层能力 | 一句话理解 | 细分项数 |
|---|---|---|
| ① 构建和部署 AI 应用 | 把一个"里面有模型"的东西真正做成能跑、能维护的产品 | 6 |
| ② 软件工程基础 | 决定取舍的手艺：架构、数据、安全、规模化 | 5 |
| ③ 使用编程智能体 | 与"替你写代码的 AI"协作，并知道哪些活不能交出去 | 5 |
| ④ 塑造构建 | 决定"该做什么、为谁做、何时算够" | 4 |
合计 20 项细分能力——这正是下文自评表的 20 格。
1.2 一条公理：输出不可预测
整张地图立在一句话上。吴恩达在 Part 1 写道：
AI 应用与非 AI 软件的关键差异在于，前者的输出更不可预测。向 LLM 提问，你不知道会拿回什么；训练一个深度学习算法，你不知道它在新样本上会做什么预测。相比之下，传统软件的行为更可预测。
由此推出一条完整因果链，这是理解全图的钥匙：
输出不可预测
→ 无法预先规划整个流程
→ 构建必然是高度迭代的：做一小块 → 观察 → 决定下一步
→ 每一轮迭代的收益，取决于"下一步决策的质量"
→ 于是「验证能力」（知道自己错在哪）+「判断力」（知道该改什么）成为杠杆点
吴恩达对这幅图的自我描述也很直白：他们是"对一个由海量职位数据与专家访谈构成的数据集做了一次聚类"。
1.3 两条主线：上下文与验证
把 20 格竖着看，会浮现两条贯穿线：
- 上下文线：LLM 基础 → Grounding 与检索选型 → Agent 的上下文管理 → 并行 Agent 的状态协调 → AGENTS.md / CLAUDE.md 驻留上下文。回答"模型此刻应该看见什么"。
- 验证线：evals 与误差分析 → 行为/功能验证 → 评测集与 LLM-as-a-judge → 智能体式代码评审与安全审计 → CI/CD 中的统计评估与发布门禁。回答"我怎么知道它对了"。
值得注意的是："提示工程"没有出现在地图里（它被并入了更大的"上下文工程"），而 evals 出现在每一条线上。这就是这张地图隐含的技术判断。
1.4 一个必须澄清的术语：技能 ≠ 岗位
吴恩达特别声明他谈的是 AI 工程技能，而不是"AI 工程师"这个岗位，理由是一个云计算类比：
今天所有开发者都应该知道如何与云协作，但只有较少一部分人拥有"云工程师"的头衔。同样，所有开发者——全栈工程师、数据工程师、DevOps 工程师、机器学习工程师，以及 AI 工程师——都将需要 AI 工程技能。
这句话把地图的适用范围从"想转行做 AI 的人"扩大到了所有写软件的人，也顺带说明了为什么 Part 5 会把"产品决策""沟通领导"算进工程能力：当 PM、设计师也开始写软件，角色边界本来就在融化。
二、核心工具：20 格自评表
2.1 打分口径（0–3 四档）
| 分数 | 含义 |
|---|---|
| 0 空白 | 不知道有这回事 |
| 1 见过 | 看得懂别人怎么做，自己没独立做过 |
| 2 够用 | 能在真实项目里独立完成一次，并能说出取舍 |
| 3 能教 | 能给别人定标准、写规范、带人做 |
2.2 逐格自评（判定问题为本文设计）
① 构建和部署 AI 应用
| # | 细分项 | 过关判定问题（能不加准备地答上来，即 ≥2） |
|---|---|---|
| 1 | LLM 基础 | 这个任务该用哪个模型、上下文窗口怎么取舍、什么时候该上微调或自托管？ |
| 2 | 用数据为模型提供依据（Grounding） | 哪些信息写进 prompt、哪些交给工具按需检索？为什么用向量索引而非知识图谱（或反之）？ |
| 3 | 构建智能体系统 | 这个任务是 workflow、agentic workflow 还是 open-ended agent？为什么？ |
| 4 | 评估驱动开发 | 如果系统今天答错了，我什么时候能知道？我的评测集覆盖了哪几类失败模式？ |
| 5 | 生产环境运维 | 我的可观测性看到的是"日志"还是"性能与漂移"？一次模型升级，回归门禁拦得住吗？ |
| 6 | 机器学习基础 | 这个系统是偏差问题还是方差问题？数据要怎么清洗与迭代？ |
② 软件工程基础
| # | 细分项 | 过关判定问题 |
|---|---|---|
| 7 | 全栈开发 | UI、缓存、API、鉴权、状态、异步、持久化，哪一层是当前瓶颈？ |
| 8 | 数据管理 | 访问模式决定存储选型了吗？数据该存多久、怎么保证干净与新鲜？ |
| 9 | 系统架构 | 单体还是微服务、状态放在哪、前后端边界在哪——依据是什么？ |
| 10 | 安全与可靠性 | 失败时会优雅降级吗？爆炸半径有多大？安全左移做到了哪一步？ |
| 11 | 规模化与生产运行 | 发布策略、CI/CD、告警、事故管理、技术债——哪些已经自动化了？ |
③ 使用编程智能体
| # | 细分项 | 过关判定问题 |
|---|---|---|
| 12 | 引导工作流 | 这个任务该写多细的 spec？该拆成哪些"可验证的步骤"？ |
| 13 | 启用自主性 | 这次的自主性档位是"盯着做""委派一大块"还是"给定目标循环到成功"？为什么？ |
| 14 | 审阅工作成果 | 我用什么证据判断它做完了——测试、截图，还是评测集？够不够？ |
| 15 | 定制智能体及其环境 | 住留上下文（AGENTS.md）里写了什么？有哪些 hooks 在替我跑重复流程？ |
| 16 | 编程智能体基础 | 它怎么检索代码库、上下文怎么被消耗、什么时候会跑偏？ |
④ 塑造构建
| # | 细分项 | 过关判定问题 |
|---|---|---|
| 17 | 驱动构建循环 | 下一步是做原型、MVP、加功能还是企业级重构？依据是什么？ |
| 18 | 产品决策 | 规格没覆盖的那部分，我凭什么做决定？用户同理心从哪来？ |
| 19 | 沟通与领导 | 我能不能向市场/财务/法务解释清这件事可行或不可行？ |
| 20 | 高自主权的主人翁意识 | 我是按"任务完成度"还是按"创造的价值"衡量自己的工作？ |
2.3 怎么读这张表
- 优先补最薄的一格，而不是把最强的一格练到满分。 20 格全部勉强"够用"，一定好过硬撑两格、其余空白——AI 应用是复合系统，短板决定系统能不能上生产。
- 分水岭在第 4 格。 吴恩达在 Part 2 里把话说得极重："在我经验里，区分'擅长构建 AI 系统的人'与'不擅长的'，最重要的特质就是能否驱动一个严谨的 evals / 误差分析循环。"他同时承认这很难："我发现这是项棘手技能，因为正确做法因项目、甚至因项目阶段而异。"
- 第 17–20 格不是软技能鸡汤。 它们之所以被立项为"能力"，是因为当前大多数组织还没人知道 AI 能做什么，于是"识别问题、提出方案、执行落地"成了稀缺动作（Part 5 原文）。
三、逐格教学：学什么、怎么练、什么算过关
3.1 构建与部署 AI 应用（第 1–6 格）
这组的核心心法：AI 系统的可靠性不来自"换个更强的模型"，而来自用统计手段测量、引导和治理（Part 1 原文："understanding the building blocks of AI… and, importantly, how to use statistical techniques to measure, steer, and govern AI systems"）。
| 格 | 怎么练（本文建议） | 过关标志 |
|---|---|---|
| 1 LLM 基础 | 给同一个任务跑 3 个模型 × 2 档推理强度，记录质量/延迟/成本三角；故意构造会触发知识截止与缓存失效的查询 | 能画出一张"我的任务的模型选型表"并解释理由 |
| 2 Grounding | 把同一份数据分别做成"塞 prompt""向量检索""结构化查询"三版，测回答准确率 | 能说清每类数据为何选择某种表示 |
| 3 智能体系统 | 用 workflow（固定链路）与 agent（自主决策）各实现一遍同一任务，对比成功率与成本 | 能画出控制流图与上下文流向图 |
| 4 评估驱动开发 | 见下方"四步练习法" | 能拿出一份 ≥20 条、含失败分类的评测集，并知道它何时会失效 |
| 5 生产运维 | 给一个真实应用接上追踪与成本仪表，做一次"故意让模型退化"的演练 | 漂移/退化能在 24 小时内被系统而非用户发现 |
| 6 ML 基础 | 补偏差/方差、误差分析、数据工程三件套；手训一个小模型并做误差分析 | 面对不确定输出，能说出该调数据还是调模型 |
第 4 格的"四步练习法"（自下而上的误差分析，来自 evals 社区的通用做法）：
- 先分析，别先写测试：抽 20–50 条真实的生产 trace / 会话，逐条人工标注"这条对不对、错在哪"；
- 编码归类：把失败模式做成标签（开放式编码 → 归纳成类），统计每类占比——这一步决定了你该写哪些评测；
- 按需选评测手段：确定性代码评测（能用规则判的）、LLM-as-a-judge（定性输出）、人在环（高风险/低置信）；
- 校准你的评测本身：定期故意让评测集"红"一次，确认它真的能抓到问题，而不是稳定地给高分。
吴恩达在原文里强调，评测要"结合产品与商业洞察来决定测什么"，并且要"评估你的评测，以持续迭代它"（Part 2）。这与上面的第 4 步是同一件事。
3.2 软件工程基础（第 7–11 格）
这封信的核心论点不是"软件工程还重要"这种老话，而是一个更锋利的判断（Part 3 原文）：
靠"感觉"写代码的新手，会让编程智能体在延迟、可用性、一致性、可靠性、可维护性、简洁性和/或成本上做出糟糕的权衡——大多数情况下，开发者甚至不知道这些权衡存在。
也就是说：Agent 不会替你消除取舍，只会替你消除"发现取舍"的机会——除非你自己懂。
练法：拿一个你熟悉的系统，填下面这张取舍表，再问 Agent"你是按哪一列做的决定"。
| 维度 | 我的应用优先级 | Agent 可能默认的选择 | 我要怎么纠正 |
|---|---|---|---|
| 延迟 / 成本 | 追求"能跑" | ||
| 一致性 / 可用性 | 忽略并发与故障 | ||
| 可维护性 / 简洁性 | 过度抽象或过度堆砌 |
过关标志：能用软件工程的精确语言向 Agent 下指令（"这里必须幂等""这个查询要加索引，因为读多写少"），而不是"让它再优化一下"。吴恩达的结论很直接：
部分编码知识——比如记住语法——正在过时。但深刻理解软件如何运作的开发者，会大幅跑赢那些不懂取舍就 vibe coding 的人。
3.3 使用编程智能体（第 12–16 格）
这是全系列可操作性最强的一封。先记住那条被反复验证的高层工作流：
规划（Planning）
├─ 头脑风暴：研究、做实验、理解既有代码库
└─ 写规格（spec）：需求 + 技术设计 + 架构 → 生成执行计划
└─ 人只做两件事：质询关键假设 / 检查安全性、过度工程与其他缺口
执行（Execution）
├─ 让 Agent 构建（自主性档位可调）
└─ 用自动化 + 人工检查验证产出
部署与监控（Deployment & Monitoring）
├─ 部署（CI/CD 或人工 Gate 把关）
└─ 用 Agent 读日志、暴露问题、提出并执行改进
两个容易被忽略的性质：项目差异极大（绿地原型可能一句提示词就是 spec；棕地项目加大量用户，spec 需要重投入），且高度迭代（验证失败要引导重建；监控发现问题要回到上一步）。
四项失败模式（原文列举，值得贴在显示器旁）：
- 把简单方案过度工程化；
- 缺少显式验证流程而失去严谨性；
- 没达到目标就停下；
- Agent 的动作破坏文件或生产数据。
吴恩达还给社交媒体上的流行叙事泼了一盆冷水（Part 4 原文）：
目前，超长时程任务的实际效用——尤其是相对于其成本而言——被夸大了，超过了现实。相反，大多数有效的编程智能体使用，是一个复杂、高度迭代的过程，而能够以高水平判断进行干预，往往能带来好得多的结果。
过关标志：你能说出这次为什么选这个自主性档位；你能把任务拆成"可验证的步骤"；你的关键动作（生产写库、密钥、支付、删除）走的是权限与 Gate，而不是提示词里那句"请不要"。
3.4 塑造构建（第 17–20 格）
最后一封信把视角从技术推到身份（Part 5 原文）：
当你精通 AI 工程时，你最好的作品不会是"仅仅实现别人写好的规格"，而是主动塑造构建。
四项能力中，最容易被误读的是"产品决策"——它不要求你转岗做 PM，而是要求你补全规格没覆盖的部分：产品直觉、基本设计感、基本商业感（GTM、市场规模、单位经济、P&L），而这一切"扎根于用户同理心"，并通过 2–3 个用户的非正式访谈、数百份问卷、大规模 A/B、海量行为分析持续打磨。
过关标志：给你一个模糊需求，你能在一周内拿出可验证的原型并获得真实用户反馈；你能说清这个项目的关键指标是什么。
四、三条起点不同的路径
地图面向所有人，但每个人起点不同，补齐顺序也应不同。
路径 A｜有工程背景的开发者（工程师 / 后端 / 全栈）
- 优势：第 7–11 格多半已有 2–3 分。
- 补齐重点：① 的 2、3、4 格（Grounding / 智能体 / evals），③ 全部，④ 的 17、18 格。
- 一句话策略：把"会写代码"换成"会定义验收标准"。你的瓶颈不再是实现，而是"说不清什么叫对"。
路径 B｜数据 / 产品背景（数据分析师、PM、设计师）
- 优势：第 18 格（产品决策）、19 格（沟通）往往已有 2 分以上；数据管理与指标定义也通常在线。
- 补齐重点：② 的 7、9、11 格到 1 分即可（能读懂取舍、能和 Agent 说清约束），③ 全部到 2 分，① 的 1、3、4 格到 2 分。
- 一句话策略：不需要成为工程师，但需要能独立跑通一次"规格 → Agent 构建 → 验证 → 上线"的完整闭环。吴恩达在 Part 5 明确提到，PM 与设计师正在获得 AI 工程技能并参与构建软件——这条路径是被地图认可的正道。
路径 C｜团队管理者 / 技术负责人
- 用法一：能力盘点。让团队成员各自对 20 格打 0–3 分，你会看到真实的"结构性缺口"（通常集中在 evals 与生产运维，而不是模型调优）。
- 用法二：招聘与面试。把第 4、14 格（评测与审阅）做成面试的实操题，比问"用过哪些框架"有效得多。
- 用法三：给"塑造构建"配权限。地图第 20 格要求高自主权，但多数组织里这受权限结构限制，不只是个人意愿。如果你是管理者，"鼓励主人翁意识"若不配套授权，等于没有。
五、12 周计划表（本文建议节奏，非官方）
前提：每周投入 6–8 小时；每阶段必须有可验收的交付物，没有交付物就不算完成。
| 周次 | 主题 | 交付物 | 验收标准 |
|---|---|---|---|
| 1 | 地图校准 | 20 格自评表 + 目标岗位 JD 对照 | 能说出自己最薄的三格 |
| 2 | LLM 基础 | 模型选型对比表（3 模型 × 2 推理档） | 能解释每次选择的取舍 |
| 3 | Grounding | 三种上下文供给方式（prompt / 检索 / 结构化）对比实验 | 有量化对比结论 |
| 4 | 智能体系统 | 同一任务的 workflow 版 + agent 版 | 画出控制流与上下文流 |
| 5–6 | 评估驱动开发 | ≥20 条评测集 + 失败模式分类表 | 做一次"让评测集变红"的校准实验 |
| 7 | 生产运维 | 可观测性 + 成本仪表接入 | 退化能在 24h 内被系统发现 |
| 8 | 软件工程基础补课 | 取舍表（延迟/一致性/可维护性…） | 能用工程语言给 Agent 下约束 |
| 9 | 规格驱动开发 | 一份真实 spec + 执行计划 + 验证证据 | 有截图/测试作为"完成"的证据 |
| 10 | Agent 定制 | AGENTS.md + 至少 2 个 hooks + 技能裁剪 | 一次同类任务耗时明显下降 |
| 11 | 部署与监控 | CI/CD + 人工 Gate + 回归门禁 | 一次新版本发布可回滚 |
| 12 | 塑造构建 | 一次完整项目复盘 + 指标定义 | 能说清创造了什么价值（而非完成了什么任务） |
现实提醒：如果你的项目是棕地系统或已有真实用户，第 5–7 周的时间通常要翻倍——吴恩达本人也承认 spec 与 evals 的投入强度"因项目阶段而异"。
六、三个必做项目（把技能装进作品集）
项目 1｜带 evals 的 RAG 或 Agent 应用
- 最低配置：能跑通的问答或任务执行 + 追踪日志 + 评测集。
- 验收：能说出 5 类失败模式；评测集 ≥20 条且经过一次校准；能解释为何部分评测用代码、部分用 LLM-as-a-judge。
项目 2｜规格驱动的 Agent 开发全流程
- 选一个有多种约束的需求（有并发、有权限、要审计），完整走一遍"规划 → 执行 → 部署监控"。
- 验收：产出可读的 spec（需求/技术设计/架构）+ 执行计划 + 验证证据 + 一份复盘（记录哪些假设在中途变了，以及如何回写上下文）。
项目 3｜生产化改造
- 给项目 1 或 2 加上：可观测性、成本仪表、回归门禁、以及关键动作的权限 Gate。
- 验收：一次"故意注入的故障"被门禁或告警拦住；能报出每次调用的成本。
七、七个反模式（照着抄会踩的坑）
- 不懂取舍就 vibe coding——Agent 替你做的每个权衡，都会在延迟、一致性、成本上留下账单。
- 评测集自欺——从不校准的评测集，会让你稳定地误以为系统是好的。
- 没有显式验证流程——这是吴恩达列出的失败模式之一：Agent 会"没达到目标就停下"，而你可能不知道。
- 超长时程自治崇拜——把"让它自己跑几小时"当目标，而不是把"高判断力介入"当目标。
- tokenmaxxing——把 token 用量当生产效率指标。吴恩达的建议：超过基础规模就给应用装上成本仪表，并在架构上保留可移植性，不要被单一模型供应商锁定（他甚至建议第一个原型阶段就让应用能跑多个 LLM 供应商）。
- 过度工程化——为一次性脚本写 spec、搭 evals、上抽象层。
- 在"塑造构建"上等指令——等一份像素级完美的设计再动手，等于把自己降级为 Agent 的搬运工。
八、结语：今天就能做的一件事
这张地图最容易被执行坏的方式，是把它当成又一份"20 项全能"的焦虑清单。它真正的用法朴素得多：对着你正在构建的东西，逐格核对。
如果只留一个动作，就留吴恩达在 Part 2 埋下的那个判断——把它变成对你自己系统的一句提问：
如果这个系统今天答错了，我什么时候能知道？
如果答案是"等用户告诉我"，那么下一步该投入的不是更强的模型，而是第 4 格。
当写代码被大幅自动化，工程师的价值锚点从"写得出来"迁移到了"判断得准"。地图不完美——它后视（输入是已发生的招聘信息）、由课程机构发布、颗粒度不齐——但它把一个靠焦虑驱动的问题，变成了一个可以逐格核对的清单。
这就够了。开始填表吧。
参考来源
吴恩达 / DeepLearning.AI 一手原文（2026）
- The AI Engineering Skills Map（Part 1），08-14，LinkedIn / The Batch
- The AI Engineering Skills Map Part 2 — AI Applications: What You Need to Know to Build and Deploy AI Applications In Real Life，08-21
- Part 3 — Fundamentals: Why Software Engineering Fundamentals Remain Essential for AI Developers，08-28
- Part 4 — Coding Agents: How to Use Coding Agents Effectively from Planning to Execution and Monitoring，09-04
- AI Engineering Skills Map: Shaping the build（Part 5），09-11
- What Comes After Tokenmaxxing?，08-07
站内相关 7. 深度研究｜吴恩达《AI 工程技能地图》全解：当代码不再稀缺，工程师靠什么立足（09-12，前置阅读） 8. 控制流归谁，上下文给谁：Agent 工程的四条第一性原理（智能体架构与上下文，对应第 3、15 格） 9. 大模型能力提升路线图：从"堆参数"到训练全栈 + 外层程序（对应第 1、6 格）
实操资源（用于第 4 格的练习法） 10. Hamel Husain，AI Evals: Everything You Need to Know 及其误差分析笔记（hamel.dev） 11. Anthropic Engineering，Effective context engineering for AI agents / Building Effective Agents / Writing effective tools for agents 12. DeepLearning.AI，Agentic AI 课程（吴恩达亲授，含 evaluating agentic AI 模块）
说明：本文第 2 节的自评判定问题、第四节的三条路径、第五节的 12 周计划与第六节的三个项目验收标准，均为本文作者在吴恩达原文框架上的延伸设计，已尽量与原文口径对齐，但不代表吴恩达或 DeepLearning.AI 的官方建议。
读者留言
COMMENTS 暂无还没有留言，来说第一句？