AI 工程技能地图:未来开发者最该补的四块能力

来源：Andrew Ng · The AI Engineering Skills Map链接：https://x.com/andrewyng/status/2088302050706686198

TL;DR

1. 1. AI 工程技能不是某个新岗位的专属门票，而是所有开发者都要补的一层能力。
2. 2. AI 应用最难的不是“怎么调用模型”，而是“怎么让不稳定的输出变得可评估、可修正、可上线”。
3. 3. Vibe coding 真正的问题不是用了 AI，而是不懂工程基础的人无法给 AI 足够好的上下文。
4. 4. Coding Agent 越能写代码，工程师越要往上走：从“照着需求做”变成“判断需求该不该这样写”。
5. 5. 在 AI 工具快速变化的环境里，持续试新工具、更新工作流，本身就是一项核心技能。

一、这不是“AI 工程师”的地图，而是所有开发者的升级地图

Andrew Ng 团队分析了 10,000 多条招聘信息，又访谈了 AI 专家、招聘经理和招聘人员，最后把 AI 工程能力聚成了四类：

1. 1. 构建与部署 AI 应用
2. 2. 软件工程基础
3. 3. 使用 Coding Agent
4. 4. 定义要构建什么

这里最重要的判断是：AI 工程技能不等于 AI 工程师岗位。

就像今天几乎所有开发者都要懂一点云服务，但不是每个人的岗位都叫 Cloud Engineer。AI 工程也一样，它会变成全栈、数据、DevOps、机器学习工程师的共同底层能力。

“所有开发者——全栈工程师、数据工程师、DevOps 工程师、机器学习工程师——都将需要 AI 工程技能。”

二、AI 应用的一等问题，不是调用模型，而是治理不确定性

传统软件大体是确定的：输入 A，通常得到结果 B。

AI 应用不一样。你给大模型一个提示词，并不能百分百知道它会回什么；你训练一个模型，也不能完全确定它在新样本上的行为。

所以，构建 AI 应用的关键能力不是“会不会接 API”，而是能不能把不可预测的输出变得可度量、可调试、可治理。

这就是为什么 Andrew Ng 特别强调：

1. 1. eval：评测系统行为是否达标
2. 2. error analysis：分析错误来自哪里
3. 3. loop：把评测和修正变成开发主循环

可以把它理解成 AI 时代的“质量控制系统”。传统测试更像判断“对不对”，AI eval 更像判断“整体表现有没有漂移、风险是否可接受”。

“核心技能在于懂得驱动有纪律的评测和错误分析闭环。”

三、Vibe coding 最大的问题：不是 AI 写代码，而是人给不出好上下文

很多人以为 AI 时代不需要软件工程基础了。Andrew Ng 的判断相反：越依赖 Coding Agent，越需要懂工程基础。

原因很简单：

1. 1. 不懂软件工程，就看不见系统里的取舍：成本、性能、可靠性、安全、隐私、可维护性。
2. 2. 看不见取舍，就给不出准确上下文。
3. 3. 给不出上下文，Agent 就会按默认方式做决定。
4. 4. 默认决定往往不是你真正想要的系统设计。

所以，软件工程基础在 AI 时代的价值变了：过去是帮你“手写好代码”，现在是帮你“给 Agent 造一个好约束场”。

换句话说，好的工程师不是简单让 AI 写，而是用精确的工程语言告诉 AI：哪些边界不能碰，哪些指标优先，哪些 tradeoff 可以接受。

“懂软件工程基础，让你能用精确的工程语言转向 Coding Agent，做出好的权衡。”

四、工程师的工作重心，正在从“交付需求”变成“定义需求”

如果需求已经非常清楚，Coding Agent 会越来越擅长把它做出来。

这意味着工程师的价值会往上移动：不只是实现需求，而是参与判断“这个需求到底该怎么定义”。

旧模型是：

1. 1. 产品或设计给出很细的需求
2. 2. 工程师照着实现
3. 3. 交付结果

新模型是：

1. 1. 工程师理解业务目标和用户问题
2. 2. 参与定义规格和约束
3. 3. 操控 AI 工具快速实现
4. 4. 用评测和反馈验证结果

这也是为什么 Andrew Ng 把 product sense、业务上下文和客户目标放进 AI 工程技能里。未来的工程师不再只是“把东西做出来的人”，而是“判断什么值得做、怎么做才有效的人”。

“我们作为工程师的工作，正在转向决定 spec 里应该放什么。”

五、会用 Coding Agent，不是会打提示词，而是会搭协作系统

真正熟练使用 Coding Agent，至少包含三层能力：

1. 1. Context 管理：让 Agent 看到必要的代码、约束、目标和取舍顺序。
2. 2. 闭环验证：提供测试、eval、检查器，让 Agent 能自己发现问题并修正。
3. 3. 进化 routine：持续试新工具、更新流程，而不是守着一套很快过期的最佳实践。

这里还有一个容易被低估的能力：知道什么时候要写清楚 spec，什么时候没必要。

小改动可以直接执行；复杂系统要先规划；涉及生产数据库、权限、资金、用户隐私的任务必须有保护边界。会用 Agent 的人，知道什么时候放手，也知道什么时候必须介入。

“熟练使用 Coding Agent，不仅是掌握当下最佳实践，更是拥有持续试新工具、进化工作流的 routine。”

六、这张地图还不是操作手册

这篇文章更像一个方向图，不是完整教程。它指出了 AI 工程技能的四个方向，但还有几个问题没有展开：

1. 1. 每项技能到什么程度才算“够用”？
2. 2. 全栈、数据、DevOps、机器学习工程师的优先级是否一样？
3. 3. 团队如何评估和培养这些能力？
4. 4. 在 AI 工具快速变化的环境里，这张地图多久需要更新一次？

这些问题，Andrew Ng 也提到会在后续文章中继续展开。

七、延伸理解：这张地图背后的几条底层规律

1. 1. eval 闭环和 MLOps 里的 offline evaluation + online monitoring 很接近：一个负责开发态验证，一个负责上线后监控。【锚点：ML Test Score (Breck et al., 2017) · 学术共识】
2. 2. “治理不可预测输出”可以看作一种反脆弱设计：系统不是假装没有不确定性，而是通过不断评测和修正，从不确定性中变强。【锚点：Antifragile · 学术共识】
3. 3. “定义要构建什么”对应产品发现里的 empowered team：工程师不是功能工厂的交付者，而是问题空间的共同探索者。【锚点：Empowered (Cagan, 2020) · 实操】
4. 4. Agent 的 context 管理，可以用“有限理性”理解：决策者只能在有限信息里做判断，所以你给它构造什么信息环境，决定了它能做出什么质量的判断。【锚点：Bounded Rationality (Simon) · 学术共识】
5. 5. 持续试新工具的 routine，符合快速变化环境中的学习迁移规律：越会跨工具、跨领域迁移方法的人，越不容易被单一工具淘汰。【锚点：Range (Epstein, 2019) · 学术共识】