吴恩达公布 AI 工程师技能地图：如何把充满随机性的模型做成可靠系统

生成式 AI 热潮进入 Agent 与企业落地阶段后，「AI 工程师到底该会什么」正在快速改写。

DeepLearning.AI 创始人、斯坦福大学教授 Andrew Ng（吴恩达）近日进一步拆解其 AI Engineering Skills Map，将「构建与部署 AI 应用」列为 AI 工程师最核心的高级能力之一，并拆成六大技能：LLM 基础、以数据 Grounding 模型、Agentic Systems、Evaluation-driven Development、生产环境运营，以及 Machine Learning 基础。

吴恩达指出，AI 软件与传统软件最大的差异，是输出具有不确定性。传统软件通常可以预期代码在特定输入下会产生什么结果，但开发者无法事先知道大型语言模型会生成哪一句话，也无法完全预测机器学习模型会做出什么判断。因此，AI Engineering 的核心能力是：如何利用本质上不可靠、具有概率性的 AI 元件，组合出一个可靠的软件系统。

吴恩达认为，正因模型输出不确定，AI 系统的开发流程也比传统软件更加迭代。优秀的 AI 工程师会不断建立一小段系统、观察结果、分析错误，再决定下一步应该修改 Prompt、数据、模型、工具、Agent 架构，还是评估方式。真正重要的能力，是看到中间结果后，能不能正确判断：下一个最值得做的实验是什么？这也解释了为什么吴恩达把 Evaluation 放到如此核心的位置。

第一项：LLM 基础

吴恩达认为，AI 工程师至少需要理解大型语言模型如何 tokenize 输入、逐步生成输出，以及模型在哪些情境可以信任、哪些地方容易失败。这延伸到实际开发 AI 产品时遇到的工程判断，例如：context window 应该放多少信息、多模态模型什么时候比纯文本模型更适合、cache hit 如何影响成本、模型知识截止日期、reasoning effort、sampling parameters，以及何时使用 tool calling。真正理解这些基础后，工程师才有能力判断应该选哪个模型，甚至是否应该同时混合多种模型。

第二项：以数据 Grounding 模型

过去谈到企业 AI，RAG 几乎等同于「把公司数据接进 LLM」。但吴恩达指出，vector search 只是早期的一种方式，现在 Grounding 的技术选项已经大幅增加。工程师必须决定哪些信息应该直接放进 Prompt，哪些应该让模型通过工具实时查询；不同数据也可能需要完全不同的表示方式。例如，文件搜索可能适合 vector index，但复杂实体关系可能更适合 knowledge graph；如果处理的是客户数据、订单与其他结构化信息，则可能需要建立 semantic layer。此外，工程师还必须把 PDF、HTML、图片与文字文件整理成模型可以有效使用的输入格式，并维护一套能确保数据干净、正确且持续更新的 pipeline。真正的能力因此不是「会不会做 RAG」，而是面对一种数据与一个查询需求时，知道该用哪一种方式把正确 context 交给模型。

第三项：构建智能体系统

吴恩达将 Agentic Systems 的范围定义得相当广。最简单的形式可以是预先定义好的 workflow，例如依序调用数次 LLM；更进阶的架构则是使用 agent harness，让模型反复观察目前状态、自行判断下一步，再采取行动。工程师需要决定哪些步骤应该串行、哪些可以平行、什么工作应该由传统代码处理，又有哪些问题值得交给 LLM。在 Agent loop 里，还要决定模型能调用哪些工具，包括 MCP、CLI、sandbox execution environment 等；长时间任务则涉及 memory architecture 与 context management。如果单一 Agent 不够，还要判断是否真的需要 multi-agent orchestration，而不是为了使用多 Agent 而增加系统复杂度。

Agent 的另一个问题是 Prototype 与 Production 之间存在巨大落差。吴恩达因此特别提到 guardrails、对抗式输入、数据外泄以及治理等问题。例如，一个可以读取公司内部数据并调用外部工具的 Agent，一旦遭遇 prompt injection，就可能把原本只是「聊天模型回答错误」的问题，升级成真正的资安事件。因此，Agent Engineering 不只是让模型获得更多自主能力，还必须理解模型究竟可以做什么、不可以做什么，以及做错时系统如何阻止它。此外，Agent 技术本身也仍快速演进，包括 voice agents、computer-use agents 以及 generative UI，都可能逐渐成为 AI 工程师需要掌握的新型态。

第四项：评估驱动开发

六项能力之中，吴恩达特别强调 Evaluation-driven Development。他甚至直言，依照自己的经验，判断一个人是否真正擅长开发 AI 系统，最重要的特征之一，就是对方能不能建立纪律化的：Eval → Error Analysis → Development 循环。原因很简单，模型本身具有随机性，因此开发者如果只是「感觉这个 Prompt 好像变好了」，整个开发过程很容易变成乱试。好的 evals 则能让团队系统性知道产品究竟改善了多少，以及下一步应该优先解哪一类问题。

开发者可能需要阅读系统 trace、检查大量模型输出、进行 exploratory data analysis，再搭配产品与商业理解，才知道真正值得衡量的指标是什么。评估方式本身也不只有一种。有些问题适合 deterministic、也就是直接用代码检查；某些主观品质问题则可能使用 LLM-as-a-judge；而在高风险场景下，仍可能需要 human-in-the-loop。甚至连「eval 本身准不准」也需要被评估。随着产品演进，eval system 本身也必须跟着迭代。这正是 AI 开发与传统软件测试最大的差异之一：测试不再永远存在唯一正确答案。

第五项：生产环境运营

AI 软件正式上线后，工程师不只要监控 uptime，也需要追踪实际使用情境中的模型表现。包括模型品质是否 drift、某类输入是否持续失败，以及是否出现 prompt injection 等资安问题。CI/CD 与 regression testing 同样需要调整。传统软件可能检查「输出是否完全符合预期」，但 AI 系统往往需要统计式评估，而且测试严格程度也应该随风险而变。例如，一个推荐餐厅的 AI 偶尔答错，与一个医疗系统偶尔答错，所需要的测试标准显然完全不同。

AI 应用另一个不能忽略的问题，是 inference cost 与 latency。产品使用者规模一旦上升，原本 Demo 阶段看似不重要的每次模型调用成本，都可能直接影响产品毛利。因此工程师必须知道如何混合使用模型，包括 model choice optimization、distillation、fine-tuning，以及简化 agentic workflow。这也是 AI Engineering 与纯 Prompt Engineering 之间的重要差异。

第六项：机器学习基础

在 ChatGPT 出现后，一度有人认为 AI 应用开发已经不再需要学传统机器学习。但吴恩达表示，自己认识真正擅长构建 LLM 系统的工程师，几乎都对 machine learning 与 deep learning 有一定程度的理解。一方面，LLM 本身就是利用 supervised learning、reinforcement learning 等方法训练而成；另一方面，很多实际应用仍然需要使用传统 ML 模型，甚至自行训练模型。工程师因此仍需要理解不同模型在 accuracy、training speed、inference speed 等方面的 trade-off。更重要的是，bias/variance、error analysis 与 data engineering 等经典机器学习概念，依然是理解「不确定输出系统」的重要思考框架。