AI 技能地图

AI 工具更新得太快了。

很多时候，不是我们不愿意学，而是不知道该先学什么。

最近，吴恩达老师分享了一张 AI 工程技能地图，刚好回答了这个问题。

他的团队分析了 10,000 多个招聘职位，也访谈了 AI 专家、招聘经理和猎头，最后归纳出四项能力：构建和部署 AI 应用、软件工程基础、使用 Coding Agents，以及塑造构建过程。

我看完最大的感受是：这看起来是一张技能地图，实际上讲的是 AI 时代开发者的职责正在发生什么变化。

它的适用范围也不只限于「AI 工程师」。只要你正在用 AI 构建产品，都可以拿这 4 项能力检查一下自己的短板。

1. 构建和部署 AI 应用

AI 应用与传统软件有一个明显区别：输出并不完全可预测。

普通程序接收固定输入，执行确定的逻辑，通常会得到相对确定的结果。

大语言模型、机器学习模型和 Agent 工作流不同。同一个问题换一种上下文、换一批检索资料，结果就可能发生变化。

工程上的完整链路更接近：

输入与上下文
→ 模型或 Agent 处理
→ 生成结果
→ Evals 评估
→ 错误分析
→ 调整系统
→ 再次验证

如果缺少后面的评估和错误分析，团队只能靠“这次看起来还不错”判断系统质量。

一旦进入真实业务，输出漂移、检索错误、工具调用失败等问题就会慢慢冒出来。

这些正是第一项能力“构建和部署 AI 应用”需要解决的问题。

这项能力既包括 LLM、上下文工程、RAG、智能体工作流、机器学习和深度学习，也包括怎样使用统计方法衡量、引导和约束系统输出。其中绕不开的两个环节，是评估（evals）和错误分析。

开发者不能只知道系统用了哪些模型和组件，还要理解数据怎样进入系统、模型基于什么生成结果、哪些环节容易失败，以及发生错误后怎样定位和修正。

把这项能力放到实际项目里，Demo 和可交付应用之间的差距就很具体了。

现在做一个 AI Demo 的门槛确实很低。

写好提示词、调用模型接口，再让 Coding Agent 补齐代码，很快就能看到一个可以运行的结果。

但 Demo 只需要应付手里的几个输入。可交付的应用要面对不断变化的用户、数据和使用场景。

输入稍微变化、上下文变长、检索数据没有及时更新，结果都有可能发生波动。

进入工程阶段以后，我们面对的问题不再只是“模型能不能给出一次正确答案”。还要知道它在一批真实任务中的错误率、错误类型，以及每次调整到底让系统变好了还是变差了。

只会写提示词，接触到的更多是 AI 的接口层。能够持续衡量、分析和约束模型输出，才有机会把一个不稳定的 AI 组件做成可以交付的应用。

2. 软件工程基础

软件工程基础解决的是系统怎样在现实约束中长期运行。

工程化软件需要在成本、扩展性、可靠性和速度之间做取舍，安全与隐私又会增加额外约束。技术栈、系统架构、数据存储和测试方案，背后都有具体代价。

理解这些基础，开发者才知道哪些权衡真实存在，也能用更精确的工程语言给 Coding Agent 提供上下文。

但是到了真正的落地，我的感受是：AI 可以把代码生成得越来越快，但软件开发的生命周期并没有消失。

需求怎么拆、技术栈怎么选、系统架构怎么设计、数据放在哪里、安全和隐私怎么处理、怎样测试、部署以后怎样监控，这些问题依然存在。

Vibe coding 同样要面对这些问题。区别在于，很多决策被 Coding Agent 默默替你做了。

如果开发者不了解软件工程，就很难发现 Agent 在哪里选错了。它可能为了开发速度牺牲可维护性，为了少写一些代码忽略扩展性，也可能设计出暂时能用、后面却很难迁移的数据结构。

最后生成了一大堆代码，界面也能打开，但换一个环境就跑不起来。需求稍微调整，原来的结构又需要大改。

我觉得，自己玩的工具和可以交付的软件，差距往往就在这些看起来“不够 AI”的基础工作里：能不能测试，能不能维护，出了问题能不能定位，成本和可靠性是否可控。

Coding Agent 可以执行技术方案，却不能替开发者承担技术方案的后果。

3. 使用 Coding Agents

有效使用 Coding Agent，需要先建立一套关于它怎样工作的心智模型。

开发者要理解 Agent 的能力边界，管理它能看到的上下文，在规划和执行之间做取舍，并通过规格说明、测试、验证器或 evals 帮助它完成闭环。任务变复杂以后，还会涉及多 Agent 协作、文件冲突和生产环境安全。

这些能力并不是多掌握几种提示词写法，而是决定人和 Agent 怎样分工。

放到实际项目中，我更关心另一个问题：Coding Agent 的能力越强，错误决策的成本也会被一起放大。

上下文给错了、规格说明含糊、执行过程中没有验证器，Agent 依然可以非常努力地工作。只是它可能沿着错误方向写出更多代码，直到整个项目越来越难收拾。

所以使用 Coding Agent，不只是会给它下指令，还需要知道：

• 怎样拆解任务和管理上下文
• 什么时候先规划，什么时候直接执行
• 哪些步骤可以放手，哪些节点需要人工介入
• 怎样用测试、验证器和 evals 检查结果
• 什么时候应该停止、回滚或重新规划

以前，开发者需要亲手解决大量实现问题。现在越来越多实现可以交给 Agent，但任务定义、技术取舍和结果验收，仍然需要人来负责。

这也是我对“会用 Coding Agent”的理解。

衡量标准不该只是它帮你写了多少代码，还要看你能不能让它在明确边界里推进，并且用可验证的结果完成闭环。

4. 塑造构建过程

当 Coding Agent 可以根据清晰的规格快速完成实现，工程师的工作会自然向上游移动。

需要参与决定的不再只有代码怎样实现，还包括应该构建什么、为什么构建，以及规格里应该写什么。这要求工程师理解产品、业务背景和客户目标，知道什么时候应该先做 MVP 获取反馈，什么时候需要放慢速度处理可靠性问题。

“塑造构建过程”是我觉得容易被低估的一项。它意味着工程师不能只等产品经理给出一份完整需求，然后负责把功能做出来。

我的延伸是，除了产品思维，工程师也需要补上一定的市场和营销视角。

这里的营销不只是“怎么宣传”，还包括：谁会使用这个产品，他为什么愿意改变原来的工作方式，通过什么渠道发现产品，什么结果会让他继续使用或愿意付费。

这点我深有体会。如果只站在工程师视角设计产品，很容易把大量时间花在架构、功能完整度和技术细节上。最后做出来的东西工程味很重，用户却不知道它究竟解决了什么问题。

产品角色也一样。不了解实现成本和技术边界，需求就可能一直停留在概念层。

AI 没有简单地让某个角色取代另一个角色。它正在让角色之间的边界变得更模糊。 工程、产品、业务和用户反馈，需要更早地进入同一个构建过程。

最后，也是最重要的：持续学习

支撑前面四项能力的，是持续学习的习惯。

AI 仍在快速变化，工具、模型和实践方式都会继续更新。持续学习不是把一套固定工作流背下来，而是保持尝试、验证和调整，让自己的方法跟着实际变化。

但我理解的持续学习，也不是每天追一个新模型、收藏一批新工具。

更有效的方式，是借助 AI 把每次项目经验留下来：规格说明、错误样本、evals、测试用例、技术决策和失败原因。

下一次遇到类似任务时，这些内容可以直接进入新的工作流。否则用了很多 AI 工具，也做了很多项目，每次还是从头开始。

现在开发者需要负责的范围更大了：既要理解 AI 的不确定性，也要守住软件工程质量；既要会驾驭 Agent，也要参与决定什么值得构建。

问题定义、工程判断、结果验收和对用户的理解，会越来越直接地决定一个产品能不能交付。

希望能帮助到大家，对大家有用。

谢谢你愿意认真看到这里。

愿你始终对世界保持好奇。

引用来源

• 吴恩达老师：《The AI Engineering Skills Map》：用于四项技能、研究资料范围以及相关能力说明。