8 月 21 日，吴恩达发布 AI 工程技能地图第二篇：把「构建并部署 AI 应用」拆成六大子技能，并明确点出——「评估驱动开发（EDD, Evaluation-Driven Development）」是新手与老手的真正分水岭。配套案例：CVS Health 用「评估框架先行」把 AI 应用上线周期从 4 周压缩到 1.5 天。与此同时，他把 Prompt Engineering 从「区分性技能」中拿掉了——它已沦为基本素养。
🗺️ 本教程适合：想系统化提升 AI 工程能力、或给团队搭 AI 能力模型的个人与管理者。我们讲清六大子技能、EDD 三件套、可观测性与团队落地路径。
先搞懂：AI 工程师是「判断力工种」
吴恩达这一篇的核心判断：AI 工程师的能力模型，已经从「调 API / 写 Prompt」升级为「判断力」——知道问题在哪、评估什么、怎么迭代：
| 旧能力模型 | 新能力模型 |
|---|---|
| 会调模型 API | 会设计评估体系 |
| 会写 Prompt | 会诊断失败模式 |
| 能做出 Demo | 能稳定上线并迭代 |
| 靠感觉调参 | 靠数据驱动改进 |
| 单点技能 | 六大子技能组合 |
为什么是分水岭：没有评估体系，你只能「感觉变好了」；有了评估体系，你能说「从 82% 提到 91%，代价是延迟 +300ms」——可量化，才可决策、可汇报、可交接。
Step 1：六大子技能全景图
1 构建部署 AI 应用的完整技能栈
六大子技能（按生命周期）：
1. 问题定义与指标设计
· 把业务问题翻译成
可评估的指标
· 明确成功标准与红线
2. 数据与上下文工程
· 数据集构建、清洗
· 上下文组织（参考
《上下文工程》）
3. 评估驱动开发（EDD）
· 先建评估集，再写功能
· 持续回归，防止退化
（详见 Step 2）
4. 可观测性与监控
· 上线后能看见
失败模式与成本
· （详见 Step 3）
5. 错误分析与迭代
· 从失败样本中
提炼改进方向
· 形成改进闭环
6. 安全与治理
· 权限、合规、护栏
· 参考
《CISO 四问法》
《Agent 安全》
技能地图的价值：
· 个人：查漏补缺，
知道自己卡在哪
· 团队：能力盘点与
培训路径设计💡 对照自查：六大项里你哪两项最弱？通常团队最缺的是「评估」与「可观测性」——它们不直接产出功能，却决定功能能不能长期稳住。
Step 2：评估驱动开发（EDD）——分水岭
2 先建评估集，再写功能
EDD 三件套：
1. 评估集（Eval Set）
· 真实任务样本 + 期望
· 覆盖主要场景与
边界情况
· 20-50 条起手，
随迭代扩充
2. 评分器（Grader）
· 自动化打分
· LLM-as-Judge / 规则 /
人工抽样复核
· 与
《Agent 评测》
一脉相承
3. 回归闸门（Gate）
· 每次改动跑评估
· 分数不降才能合并
· 防止「修 A 坏 B」
工作流：
改代码 → 跑评估集 →
看分数与失败样本 →
分析 → 再改
为什么是分水岭：
· 新手：改完「感觉」行了
· 老手：改完「数据」说了算
· 评估先行，上线周期
反而更短（见 Step 4）评估集会被「过拟合」：同一批样本改多了，分数会虚高。定期扩充新样本、人工抽查 10%-20%，保持评估集的新鲜度。
Step 3：可观测性与错误分析循环
3 上线不是终点，是评估的开始
可观测性四件套：
1. 日志（带结构化字段）
· prompt / 响应 / 工具调用
· 耗时 / token 成本
2. 指标
· 成功率 / 延迟 / 成本
· 按版本 / 场景 / 用户群
分桶
3. 追踪（Trace）
· 一次请求的完整链路
· 定位「卡在哪个工具」
4. 失败样本库
· 自动收集低分/异常样本
· 按失败模式聚类
错误分析循环（每日/每周）：
收集失败 → 归类根因 →
（提示词？工具？数据？）
→ 设计修复 → 加进评估集
→ 回归验证
参考
《可观测性》
《反馈闭环》
把「看见失败」变成
基础设施而非事后补救💡 从最小集开始：先接「日志 + 失败样本库」两件，跑两周再决定要不要上完整追踪——别为观测而观测。
Step 4：案例拆解——CVS Health 怎么把 4 周压到 1.5 天
4 评估框架先行的实战收益
CVS Health 的实践：
· 业务：AI 应用上线
· 原流程：约 4 周
（边做边人工验收，
问题后置）
· 新流程：约 1.5 天
（评估框架先行，
问题前置）
关键动作拆解：
1. 上线前先定义评估集
· 业务规则转成可执行
的评估用例
2. 每次迭代跑评估
· 功能开发与验收并行
· 问题当场暴露
3. 评估结果作为
上线依据
· 「过了评估」= 可上线
· 不再靠人工反复试
为什么快了：
· 验收从「终点人工检查」
变成「全程自动闸门」
· 返工周期从「周」级
缩到「分钟」级
· 业务方看到的是
「可量化的达标」
启示：
评估不是「上线前的
加项」，而是「开发
方式本身」——把评估
前置，交付反而更快
与
《多 Agent 羊群效应》
同源：用结构化反馈
替代直觉注意前提：CVS 的快建立在「评估标准清晰、可自动化」的基础上。业务规则本身模糊的项目，先花时间把标准写清楚，再谈提速。
Step 5：Prompt 沦为基本素养——判断力才是壁垒
5 该把精力投到哪
吴恩达的第二篇明确把
Prompt Engineering 排除在
四大/六大区分性技能之外：
· 它不是不重要
· 而是「人人都会了」——
模型能力提升 + 工具
普及，让基础 Prompt
不再构成壁垒
精力该投的地方：
1. 评估设计
· 最稀缺、最值钱
2. 问题定义
· 把模糊需求变成
可测量目标
3. 数据与上下文
· 决定能力上限
4. 系统集成
· 工具、护栏、人审
闭环
能力自检：
· 能不能在 10 分钟内
说出「我的应用怎么
衡量好坏」？
· 能不能指出「最近一次
失败的根因」？
· 答不上来 → 从
EDD 和可观测性补起
与
《4D 培训框架》
互补：4D 教团队怎么学，
技能地图告诉团队学什么💡 别误解成「Prompt 不用学了」——而是「别把时间都花在这」。基础 Prompt 过关后，把增量时间投给评估与观测，回报率更高。
Step 6：团队落地路径与自查清单
6 从个人技能到团队能力
团队落地四步：
第一步：能力盘点
· 按六大子技能给成员
打勾
· 找出团队共同短板
第二步：建最小评估基座
· 首个项目落地评估集
+ 评分器
· 先跑通一条链路
第三步：定回归纪律
· 改动必跑评估
· 分数不降才合并
· 失败样本库周会过一遍
第四步：沉淀为模板
· 评估集模板
· 可观测性配置
· 错误分析流程
· 新项目直接复用
自查清单（每季度）：
□ 每个线上 Agent 有评估集？
□ 每次改动跑了回归？
□ 失败样本有根因分析？
□ 可观测性覆盖成本与
成功率？
□ 新成员能看懂评估与
观测体系？
判断标准：
团队 AI 能力的成熟度，
不是「用了多少模型」，
而是「评估与观测体系
有多扎实」最难的坎是「纪律」：评估体系建起来不难，难在每次改动都跑。建议从「合并前必须附评估分数」这个硬规则开始——用流程约束习惯。
常见问题速查
| 你遇到的现象 | 大概率原因 & 解决 |
|---|---|
| 评估集从哪来 | 从真实任务样本起步：20-50 条覆盖主场景 + 边界，随迭代扩充 |
| 分数虚高 | 评估集过拟合：定期加新样本，人工抽查 10%-20% 校准 |
| 上线后问题不断 | 缺可观测性：先接日志 + 失败样本库，跑起错误分析循环 |
| 团队没人会 EDD | 从小项目试点：选一个上线中的 Agent，先补评估集，跑通再推广 |
| Prompt 还要学吗 | 基础要过关，但别当主攻：把增量时间投到评估与观测上 |