分享
吴恩达老师「AI 工程技能地图」系列完整解读:构建 AI 应用 × 软件工程基础 × 驾驭编程智能体 × 塑造构建
输入“/”快速插入内容
吴恩达老师「AI 工程技能地图」系列完整解读:构建 AI 应用 × 软件工程基础 × 驾驭编程智能体 × 塑造构建
用户6116
用户6116
昨天修改
🔗 原文链接:
https://x.com/shao__meng/status/20985678...
meng shao · X · @shao__meng · 2026-09-12 08:22
📌 本文为转载,版权归原作者所有,全文以原文链接为准
吴恩达老师「AI 工程技能地图」系列
吴恩达老师在
DeepLearning.AI
- Andrew's Letters 连载的五封信「The AI Engineering Skills Map」,现在连载完成。出发点是一个实际问题:AI 让软件开发发生了根本性变化,但在充满炒作和噪音的环境中,开发者很难判断哪些技能真正值得投入学习,团队同样难以判断该招聘什么样的人。
这个技能地图的制作方法值得注意——它不凭个人经验的随笔,是基于三类证据的综合:
超过 10,000 条职位发布的大规模分析、数十次与 AI 专家/招聘经理/猎头的结构化访谈、以及问卷调查数据
。吴恩达将其类比为“对海量职位与专家访谈数据做聚类”,从中识别当下及近期最重要的技能。
一个重要的术语澄清:他谈的是“AI 工程技能”而非“AI 工程师”这个职位。这个区分类似当年“会用云”与“云工程师”的关系——全栈、数据、DevOps、机器学习工程师,乃至所有与软件打交道的角色,都需要这些技能,而不是只有一个新兴岗位独占。
总纲:四大技能板块及其内在逻辑
第一封信给出了地图的最高层结构,四个板块:
1.
构建与部署 AI 应用
——理解并驾驭 AI 系统本身
2.
软件工程基础
——AI 应用的“外壳”依然需要扎实的工程功底
3.
使用编程智能体
——把编码智能体用出高杠杆
4.
塑造构建
——决定该构建什么
这四者之间有一条清晰的递进逻辑:**AI 应用本身不可预测(板块一的核心挑战),它被包裹在传统软件系统之中(板块二),这两类系统越来越多地由编程智能体代为编写(板块三),于是人的价值重心从“写代码”上移到“决定写什么、为什么写”(板块四)**。后几封信分别展开了板块一、二、三、四的细节。
贯穿全系列还有一个反复强调的元技能:
持续学习
。吴恩达特别指出编程智能体“比其他任何顶级 AI 工程技能都演进得快”,因此掌握它不是一次性的学习,是一种持续实验、构建和更新工作流的例行习惯。
板块一:构建与部署 AI 应用
核心命题:AI 应用的输出不可预测。
你无法预知 LLM 会生成什么、模型会做出什么预测,而传统软件的行为是可确定的。这使得 AI 开发比传统开发更具迭代性——你无法完全提前规划,只能构建、观察结果、再决定下一步。第二封信中全系列最重要的一句话是:
“能够熟练决定下一步做什么,让你能基于不可靠的 AI 组件构建可靠的软件系统。”
围绕这个命题,展开为六项技能:
1. LLM 基础。
分词与生成机制、多模态模型的使用时机、上下文窗口内容的取舍、缓存命中、知识截止日期、推理努力水平、采样参数、工具调用——这些决定你能否为任务选对模型(或模型组合),以及何时该用微调、自托管等专门技术。
2. 用数据为模型提供基础。
RAG 是早期做法,如今已大大扩展。关键决策包括:什么放提示词里、什么让模型通过工具按需检索;选择向量索引、知识图谱还是结构化数据之上的语义层;把文本、PDF、HTML、图像转化为模型可用的输入;设计保持数据干净、新鲜的管道。
3. 构建智能体系统。
光谱从“预定义 LLM 调用序列的工作流”到“模型反复自主决定下一步的 agent harness”。需要决定串联哪些步骤、何时并行、何时用代码替代 LLM;设计 agent 循环时的工具(含 MCP、CLI、沙箱)、记忆架构、长会话上下文管理、多智能体编排的取舍;以及从原型到生产所需的护栏、对抗性输入防御、数据外泄风险规避和治理。
4. 评估驱动的开发。
这是吴恩达老师眼中
区分高手的最重要特质
——能否驱动一个有纪律的“评估/错误分析循环”。它难学,因为正确方法因项目而异、甚至因项目阶段而异。需要会读系统追踪、做探索性数据分析、结合产品与业务判断决定测量什么;知道何时用基于代码的确定性评估、何时用 LLM-as-a-judge、何时引入人工,甚至“评估你的评估”。其价值在于“让进步系统化,而非随机”。
5. 生产环境运维。
不可预测性加上成本与延迟,使 AI 运维不同于传统运维:可观测性、漂移检测、模型故障与安全事件(如提示注入)的快速响应;CI/CD 需要比传统软件更多的统计评估,测试投入应相对错误风险校准;以及通过模型选择、蒸馏微调、工作流简化来优化成本和延迟。
6. 机器学习基础。
吴恩达的观察很直白:“我认识的每一位擅长用 LLM 构建应用的工程师,都在一定程度上理解机器学习和深度学习。”偏差/方差、误差分析、数据工程这些经典概念,仍是驾驭“输出不确定系统”的核心思维框架——毕竟 LLM 本身就建立在监督学习和强化学习之上。
板块二:软件工程基础
这封信回应的是当下最具争议的问题:
既然智能体能写所有代码,为什么还要学软件工程?
吴恩达给出两个理由:
•
不懂权衡就无法引导智能体。
缺乏基础的开发者“氛围编程”时,智能体常在延迟、可用性、一致性、可靠性、可维护性、成本等方面做出糟糕的权衡——而开发者甚至不知道这些权衡的存在。掌握基础后,你才能用软件工程的精确语言告诉智能体该优化什么。
•
AI 内核需要软件外壳。
AI 能力通常嵌在更大的软件应用中,需要熟练工程师来塑造。
五大基础技能:
1.
构建全栈应用。
编码智能体让原本专注单一角色(前端、移动端)的开发者能承担全栈工作:UI 组件、缓存、页面渲染、API 设计、身份认证与状态管理、异步处理、数据持久化、测试、安全、无障碍。
2.
管理数据。
数据是地基且相对难改。从访问模式出发决定存什么、存多久;选择关系表/文档/键值/图等模型及基础设施;理解事务与并发;保障隐私与合规;随应用演进而演化数据架构。这里有一个很精彩的观察:“如果数据架构选择不当,AI 不会知道自己不知道什么”——数据管理需要大量人类提供的上下文,必须由既懂数据又懂 AI 工程的人来修正。此外,专为智能体(而非仅为人类)构建数据基础设施是一个快速演进的新领域。
3.
设计系统架构。
在理解全栈与数据组件之后才能决定如何组装:平台选择、前后端边界、状态放置、单体还是微服务、技术栈选型(有时需实验验证)。架构是移动目标——快速原型的简单架构未必适合生产,扩展后还要再变。
4.
让系统安全且可靠。
测试策略的配比、围绕故障设计(优雅降级、最小化爆炸半径)、“左移”安全(把安全提前到生命周期早期)。AI 工具能扫描漏洞、检查供应链风险、审查云配置,但用好它们仍需安全知识。
5.
扩展与生产运维。
SDLC、CI/CD、基础设施即服务;可观测性、告警、事故管理;负载理解、负载均衡、分片/索引/复制;以及版本控制、代码评审、技术债管理等长期维护能力。
结论部分的判断很克制也很明确:部分知识(如死记语法)正在过时,但深度理解软件原理的开发者,表现“远超”不懂原理的氛围编程者。
板块三:使用编程智能体
这是五封中信噪比最高的一封。吴恩达访谈了数十位顶尖 AI 工程师,结合自己团队的经验,总结出一个一致的高层工作流:
规划 → 执行 → 部署与监控
•
规划
:头脑风暴(调研、实验、理解现有代码库)→ 编写涵盖需求和架构的规格说明书 → 生成并审查执行计划,审视关键假设、安全性、是否过度工程。
•
执行
:在校准过的自主性水平上让智能体构建,通过自动化和/或人工检查验证输出。
•
部署与监控
:用 CI/CD 或人工关卡门控部署;再用智能体监视日志、发现问题、提出并执行改进。
两点重要的灵活性问题:各步骤的投入因项目而异——绿地原型的“规格”可能就是一个随手写的 prompt,而有大量用户的棕地项目则需要在规格和验证上投入多得多的工作量;工作流高度迭代,熟练者知道验证失败时如何引导智能体重构修复、监控发现问题时如何让智能体更新系统。