吴恩达拆出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 架构，还是评估方式。
换句话说，AI 开发很难在项目开始前就完全规划完毕。真正重要的能力，是看到中间结果后，能不能判断下一次最值得做的实验是什么。这也解释了为什么他把 Evaluation，也就是评估能力，放到如此核心的位置。
第一项：不只会调 API，还要懂 LLM 底层行为
第一项是 LLM foundations。吴恩达认为，AI 工程师至少需要理解大型语言模型如何 tokenize 输入、逐步生成输出，以及模型在哪些情境可以信任、哪些地方容易失败。
这也延伸到今天实际开发 AI 产品时会碰到的工程判断，例如 context window 应该放多少信息、多模态模型什么时候比纯文本模型更适合、cache hit 如何影响成本、模型知识截止日期、reasoning effort、sampling parameters，以及何时使用 tool calling。真正理解这些基础后，工程师才有能力判断应该选哪个模型，甚至是否应该同时混合多种模型。更进一步，工程师也需要知道什么情况值得做 fine-tuning，以及什么时候应该自行部署模型，而不是一直依赖外部 API。
第二项：Grounding 的重点是把对的数据交给模型
第二项是 Grounding models with data。过去谈到企业 AI，RAG 几乎等同于「把公司资料接进 LLM」。但吴恩达指出，vector search 只是早期的一种方式，现在 grounding 的技术选项已经大幅增加。
工程师必须决定哪些信息应直接放进 Prompt，哪些应该让模型通过工具即时查询；不同数据也可能需要完全不同的表示方式。例如，文件搜索可能适合 vector index，但复杂实体关系可能更适合 knowledge graph；如果处理的是客户资料、订单与其他结构化信息，则可能需要建立 semantic layer。
此外，工程师还必须把 PDF、HTML、图片与文字文件整理成模型可以有效使用的输入格式，并维护一套能确保数据干净、正确而且持续更新的 pipeline。真正的能力因此不是「会不会做 RAG」，而是面对一种数据与一个查询需求时，知道该用哪一种方式把正确 context 交给模型。
第三项：Agent 不是让模型自己跑，而是架构设计
第三项是目前产业最热门的 Building agentic systems。吴恩达把 Agentic Systems 的范围定义得相当广。最简单的形式可以是预先定义好的 workflow，例如依序调用数次 LLM；更进阶的架构则是使用 agent harness，让模型反复观察当前状态、自行判断下一步，再采取行动。
真正困难的地方在于架构选择。工程师需要决定哪些步骤应该串行、哪些可以并行、什么工作应该由传统代码处理，又有哪些问题值得交给 LLM。在 Agent loop 里，还要决定模型能调用哪些工具，包括 MCP、CLI、sandbox execution environment 等；长时间任务则涉及 memory architecture 与 context management。如果单一 Agent 不够，还要判断是否真的需要 multi-agent orchestration，而不是为了使用多 Agent 而增加系统复杂度。
Agent 真正难的是上生产环境
Agent 的另一个问题，是 Prototype 与 Production 之间存在巨大落差。Demo 能跑一次，并不代表可以放心交给数十万名用户。吴恩达因此特别提到 guardrails、对抗式输入、资料外泄以及治理等问题。
例如，一个可以读取公司内部资料并调用外部工具的 Agent，一旦遭遇 prompt injection，就可能把原本只是「聊天模型回答错误」的问题，升级成真正的资安事件。因此，Agent Engineering 不只是让模型获得更多自主能力，还必须理解模型究竟可以做什么、不可以做什么，以及做错时系统如何阻止它。
此外，Agent 技术本身也仍快速演进，包括 voice agents、computer-use agents 以及 generative UI，都可能逐渐成为 AI 工程师需要掌握的新形态。
第四项：最能区分优秀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 也必须跟着迭代。
第五项：上生产后，成本与延迟都是工程问题
另一项核心能力是 Operating in production。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 之间的重要差异。前者最终仍需要对产品的可靠性、延迟与单位经济负责。
第六项：机器学习基础并没有过时
最后一项是 Machine Learning foundations。在 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 等经典机器学习概念，依然是理解「不确定输出系统」的重要思考框架。
这篇文章最早出现在链新闻 ABMedia。