吴恩达:AI 工程技能地图

THE AI ENGINEERING SKILLS MAP

EDITOR'S NOTE

8  月 14 日，吴恩达（Andrew Ng）在 X 上发布了「AI 工程技能地图」（The AI Engineering Skills  Map）。一周后（8 月 21 日前后），他又发布了系列第二篇，把地图中的第一项技能「构建与部署 AI  应用」拆解成六个子领域逐一展开。本文将这两篇文章合并译出，按发布顺序排列，方便读者一次读完整个框架的「总览 +  第一章」。按吴恩达的预告，后续还会有针对另外三项技能的展开文章，本号也会持续跟进翻译。

这份技能地图不是拍脑袋列出来的。吴恩达团队分析了超过  10,000 份招聘启事，对 AI  专家、招聘经理和猎头做了数十场结构化访谈，再辅以问卷和其他公开数据交叉验证——用他自己的话说，相当于在一个由职位信息和专家访谈组成的大数据集上跑了一次「聚类」。他还表示会随着  AI 的演进持续更新这份地图，并开放了社区问卷邀请从业者共建。

有几点值得在阅读前提示：

第一，Prompt Engineering 没有上榜。这大概是整份地图最有信息量的「留白」。前两年被热炒的「提示词工程师」，在  1 万份招聘启事的聚类结果里没能成为独立技能项；取而代之的是「善用 Coding Agent」和「塑造构建方向」这两项在 2022  年根本不存在对应招聘类别的能力。已有评论敏锐地指出：四项技能中至少三项，本质上都是「在一个你无法完全掌控的系统之下做判断」的判断力技能，而不是「更快产出更多代码」的产能技能。

第二，全文的题眼是一句话：用不可靠的 AI 组件，构建可靠的软件系统。两篇文章反复回到同一个逻辑起点——AI  应用与传统软件的根本区别在于输出不可预测，因此开发过程必然高度迭代，而驱动迭代的引擎就是 Evals  与错误分析闭环。吴恩达直言，这是他眼中区分 AI 系统构建者水平高下的最重要特质。如果你只想从两篇文章里获得一点启发，应该就是它。

第三，与本号此前内容多有呼应。第二篇在「构建  Agentic 系统」一节中明确使用了 Agent Harness 的概念——工作流（Workflow）与 Harness  构成一个光谱，前者按预定义顺序执行 LLM 调用，后者让 LLM 自主决定下一步。读过本号此前 Agent Harness  文章的读者，应该会对这一节比较熟悉。

译者的一点观察：这份地图最大的价值，在于它给出了一个反直觉的判断——AI  时代最稀缺的是「懂得如何度量、引导和治理不确定性的人」。机器学习基础被放在第二篇的压轴位置也别有深意：偏差/方差、错误分析、数据工程这些「老」概念，恰恰是应对不确定系统的通用思维框架。工具会过时，框架不会。

以下为正文。译文中 AI 行业通用术语（Agent、Evals、Prompt、Token、RAG、Fine-tuning 等）保留英文原词。

PART 01

第一篇

AI 工程技能地图

我很高兴向大家推出「AI  工程技能地图」。与 2022 年相比，AI  已经彻底改变了我们构建软件的方式。谁掌握了驾驭这场变革的技能，谁就能获得大量令人兴奋的项目与工作机会。但在当下这个嘈杂、充斥着炒作的 AI  信息环境里，究竟哪些技能最值得学？为此，我和团队一起梳理出了这份 AI 工程技能地图，希望帮助两类人：(i)  开发者——明确学习的优先级；(ii) 雇主——招到真正有实力的开发者。

我们分析了超过 10,000 份招聘启事，对 AI 专家、招聘经理和招聘人员进行了数十场结构化访谈，并通过问卷调查和其他公开数据加以佐证。综合下来，最重要的四项 AI 工程技能是：

你可以把我们的研究过程通俗地理解为：在一个由海量职位信息和专家访谈组成的大数据集上做「聚类分析」，找出当下乃至不远的将来最重要的技能。

关于术语，先做个说明：我谈的是「AI  工程技能」（AI Engineering skills），而非「AI 工程师」（AI  Engineer）这一职位，因为前者的覆盖面要广得多。就像今天所有开发者都得会用云，但只有少数人的头衔叫「云工程师」。同理，未来所有开发者——全栈工程师、数据工程师、DevOps  工程师、机器学习工程师，当然还有 AI 工程师——都需要掌握 AI 工程技能。

构建与部署 AI 应用。AI 应用与传统应用最关键的区别在于：前者的输出是不可预测的。给 LLM 一个 Prompt，你无法预知它会返回什么；训练一个深度学习模型，你也无法预知它在新样本上会给出怎样的预测。相比之下，传统软件的行为要可预测得多。

真正擅长构建与部署  AI 应用的人，既要理解 AI 的各种基础组件——比如 LLM、上下文工程（Context Engineering）、RAG、Agentic  工作流、机器学习与深度学习——更重要的是，还要懂得运用统计方法去度量、引导和治理 AI  系统，让它们的行为更可预测。其中的核心功夫，就是能否驱动一套严格的 Evals（评测）与错误分析闭环。

软件工程基础。对软件的运作原理理解得越深，构建效率就越高。软件工程的本质是在成本、可扩展性、可靠性、速度等维度之间做权衡，而安全与隐私又让问题进一步复杂化。

掌握了软件工程基础，你才能意识到「究竟存在哪些权衡可做」。有了这层认知，你在选型技术栈、设计系统架构、设计数据存储、制定测试方案等环节都能做出更好的决策。反观那些缺乏经验的开发者，只会用  Vibe Coding 的方式让 Coding Agent 糊出一个方案，却完全不清楚 Agent  背后替他们做了哪些权衡——这些权衡往往很糟糕，因为他们根本不知道该给 Agent  提供什么上下文。而掌握软件工程基础的人，可以用软件工程的精确语言去引导 Coding Agent，做出正确的取舍。

善用 Coding Agent。高效使用  Agentic 编程，如今已是每个开发者的必备技能。掌握这项技能，意味着你对 Agent  的工作原理有清晰的心智模型：了解它的局限、知道如何绕过这些局限，并能快速地引导它——拿捏好何时介入、何时放手——从而在不浪费大量时间和  Token 的前提下构建出健壮的软件。

这要求你懂得如何管理  Coding Agent 的上下文，如何在规划与执行之间权衡，如何通过提供验证器（Verifier）或 Evals 帮助 Agent  自主闭环。你还需要知道怎样基于一份清晰的 Spec 来协作（以及什么时候不必如此正式）、如何编排多个 Agent  协同工作，并且规避各种坑——比如别让 Agent 把你的生产数据库搞砸。Agentic 编程演进极快，所以善用 Coding Agent  不仅意味着掌握当下的前沿实践，还意味着建立一套持续尝试新工具、随最佳实践变化而迭代工作流的习惯。

塑造构建方向。只要  Spec 足够清晰，Coding Agent 按图施工的能力正在飞速提升。于是，工程师的工作重心正在转向「决定 Spec  里该写什么」。工程师不应再指望别人递来一份像素级精确的设计稿，自己只管照做。相反，高效的 AI 工程要求你具备产品  sense，理解业务背景与客户目标，从而真正参与到「构建什么」的塑造与推进中来。

AI   也给了你前所未有的机会，去承担更大的主导权、发挥更强的自主性。你可以主动发现有价值的问题与机会，并以负责任的方式付诸行动。要抓住这样的机会，你得知道如何推动项目向前走——比如，什么时候该快速做出  MVP 拿给用户测试，什么时候又该放慢脚步、花更多时间精雕细琢。

支撑上述所有技能的，是持续学习的心态。AI 变化太快，我们必须不断学习、不断升级自己的技能，跟上新的最佳实践。

DeepLearning.AI  的核心使命，就是帮助开发者掌握这些 AI 工程技能。关于这四项技能，我还有很多想说的，后续会陆续发文逐一展开，并分享一份更详细的 AI  工程技能地图。展望 AI 工程的未来，我对我们所有人即将构建出的东西无比兴奋，也希望你能在这个未来中扮演激动人心的角色。

PART 02

第二篇

AI 工程技能地图——

构建与部署 AI 应用

我此前发布过我们的 AI 工程技能地图，其中最顶层的四项技能是：(i) 构建与部署 AI 应用；(ii) 软件工程基础；(iii) 善用 Coding Agent；(iv) 塑造构建方向。本文将详细展开第一项。

要真正擅长构建与部署 AI 应用，你需要掌握以下六个方面：

这张技能地图，是我们在分析大量招聘启事、开展结构化专家访谈并收集问卷反馈的基础上梳理而成的。

AI  应用与传统软件最关键的区别在于：前者的输出更难预测。LLM  会输出什么、监督学习算法会给出怎样的预测，你事先都无从知晓。正因为这种不确定性，构建 AI  系统远比构建传统软件更依赖迭代——你很难提前把整个过程规划清楚。熟练的 AI  工程师的工作方式是：先构建一版软件，仔细审视其表现，再决定下一步尝试什么；每一步怎么走，都高度取决于上一步的中间结果。正是这种「决定下一步做什么」的判断力，让你能够用不可靠的  AI 组件，搭建出可靠的软件系统。具体而言，这需要掌握：

LLM 基础。理解  LLM 如何对输入做 Token  化、如何生成输出，你才能判断什么时候可以信赖它、什么时候它可能翻车。这些知识还能帮你判断何时该用多模态模型、如何权衡上下文窗口里该放什么内容，并对缓存命中、知识截止日期、推理强度（Reasoning  Effort）、采样参数，以及何时启用 Tool Calling  等特殊能力做出合理推断。吃透这些基础，你才能选对模型（或模型组合），并在必要时用上 Fine-tuning、自托管部署等进阶手段。

用数据锚定模型（Grounding）。LLM  需要高质量的输入上下文，才能产出有用的结果。基于向量检索的 RAG 是早期为 LLM  提供相关上下文的尝试，但如今用数据锚定模型的技术手段已经大大丰富。举例来说，你需要决定：哪些信息直接放进 Prompt，哪些交给 LLM  通过工具按需检索；哪种数据表示更契合你的数据形态和查询模式——向量索引、知识图谱，还是架在结构化数据（如客户记录）之上的语义层。你还要把各种文档（文本、PDF、HTML、图片）加工成  LLM 可直接使用的输入，并搭建数据管道，保证数据的干净与新鲜。只有摸清获取数据的完整「技术菜单」，你才能更好地为 LLM 提供相关上下文。

构建 Agentic 系统。Agentic  系统是一个光谱：一端是按预定义顺序执行一串 LLM 调用的工作流（Workflow），另一端则是基于 Agent Harness、让 LLM  自主决定下一步行动的系统。你需要做出架构选择——哪些步骤串联、哪些并行，什么时候用代码解决、什么时候交给 LLM——并把工作流或 Harness  工程化落地，配好 Fallback 机制。在设计 Agent 循环时，你还要决定：模型可以调用哪些工具（包括 MCP、CLI  和沙箱执行环境）、采用怎样的记忆架构、如何在长会话中管理上下文，以及什么样的任务需要多 Agent 编排、什么样的任务单 Agent  就够了。你还需要把有潜力的原型打磨成可靠、安全、可上生产的  Agent——这意味着理解护栏（Guardrails）机制与对抗性输入，识别并规避数据外泄等关键风险，同时做好治理。

Agentic 工作流仍在快速演进。了解与你的应用领域相关的前沿技术——比如语音 Agent、Computer Use Agent 或生成式 UI（Generative UI）——同样会让你受益匪浅。

评测驱动开发。以我的经验，判断一个人是否真正擅长构建  AI 系统，最重要的特质就是：他能否驱动一套严格的 Evals  与错误分析闭环来牵引开发。这套闭环能让你不断把精力聚焦在最可能出成果的方向上。我发现这项技能相当难精通，因为「正确的做法」因项目而异，甚至在同一项目的不同阶段也大不相同。

构建好的  Evals 本身就是一门很深的技术活。你可能需要翻看系统的 Trace  和输出、做探索性数据分析，再结合产品与业务洞察，来决定到底该度量什么。你还应当熟悉 Evals  的各种选项：什么时候用确定性的（基于代码的）评测，什么时候用  LLM-as-a-Judge，什么时候需要人工介入（Human-in-the-Loop），以及如何「评测你的评测」，让 Evals  本身持续进化。这些评测最终会汇入一个驱动后续开发的迭代闭环，让进展变得系统化，而不是靠碰运气。

生产环境运维。运营  AI  软件与运营传统软件不同，根源在于三点：不可预测性、成本与延迟。首先，你要会搭建可观测性机制，掌握系统在真实使用中的表现：追踪性能、检测漂移（Drift），并对模型故障和安全事件（比如对抗性的  Prompt 注入）快速响应。其次，AI 系统的回归测试和 CI/CD  比传统软件更依赖统计化的评测，而测试投入的力度，应当与出错的风险大小相匹配。此外，你还得懂如何搭配各种优化手段——模型选型优化、蒸馏与  Fine-tuning、Agentic 工作流精简——来压低成本、降低延迟；当你的应用要服务海量用户时，这一点尤为重要。

机器学习基础。现代  LLM 正是用机器学习技术（包括监督学习与强化学习）构建的。我认识的每一位擅长基于 LLM  做开发的工程师，都对机器学习和深度学习有相当深度的理解。而且，许多应用本身仍离不开机器学习——要么用别人训练好的模型，要么自己动手训练。这要求你熟悉主流的机器学习与深度学习模型，了解它们在准确率、训练速度、推理速度等方面的取舍，并懂得如何为训练和评测准备好数据。偏差/方差（Bias/Variance）、错误分析、数据工程——这些机器学习的经典概念，本就是应对「输出不确定的系统」的核心思维框架，在  AI 系统开发的方方面面依然是关键的决策依据。

要成为构建与部署 AI 系统的高手，需要学的东西很多——这是一个技术纵深相当可观的领域。但你学到的每一分，都会让你在 AI 工程之路上更进一步，构建出更激动人心的应用。与这些技能相辅相成的，是软件工程能力。我会在后续文章中展开这一话题。