AI 应用工程
理解概率性组件如何工作，并用数据、评估和生产机制把不稳定输出约束到可接受范围。
Technical Learning Guide · 2026
AI Engineering Skills Map
从“写代码”走向“主导构建”
基于 Andrew Ng 连续发布的 5 篇 AI Engineering Skills Map 系列，重组为一份面向实践的中文学习手册。重点不是工具清单，而是如何把不确定的模型、Coding Agent 与确定性的工程约束组合成可交付、可验证、可运营的产品。
01
总体结论：价值正在向判断与闭环上移
一句话结论：AI 降低了代码实现成本，但没有降低正确决策、系统设计、结果验证和生产责任的难度；这些能力反而成为工程师的新瓶颈。
这套技能地图来自对超过 10,000 个职位、数十次结构化访谈、问卷及其他在线数据的综合分析。它讨论的是广义的 AI Engineering skills，不是某一个岗位名称。全栈、数据、DevOps、机器学习与 AI 工程师都会用到它。
| 过去的主要价值 | AI 时代的主要价值 | 变化原因 |
|---|---|---|
| 手工实现需求 | 定义需求与验收条件 | Agent 能更快生成实现，但无法替你决定“正确目标” |
| 熟记语法与 API | 理解系统边界与取舍 | 实现知识可被即时调用，架构判断仍依赖上下文 |
| 逐行检查代码 | 验证行为、数据与风险 | 生成规模增大后，人无法靠阅读每一行代码兜底 |
| 按任务完成开发 | 主动推动价值闭环 | 个人交付半径扩大，角色边界开始融合 |
AI 工程能力 = AI 系统深度 × 软件工程判断 × Agent 驾驭能力 × 产品与业务责任
其中任何一项接近 0，整体交付能力都会被显著拉低。
其中任何一项接近 0，整体交付能力都会被显著拉低。
02
能力地图：四个域不是并列清单，而是依赖关系
AI Engineering Skills
├─ 1. Building & Deploying AI Applications
│ ├─ LLM / Grounding / Agents
│ └─ Evals / Production / ML foundations
├─ 2. Software Engineering Fundamentals
│ ├─ Full stack / Data / Architecture
│ └─ Security / Reliability / Operations
├─ 3. Using Coding Agents
│ ├─ Plan / Execute / Verify
│ └─ Context / Autonomy / Environment
└─ 4. Shaping the Build
├─ Build loop / Product decisions
└─ Communication / High agency
软件工程基础
知道系统有哪些取舍，才能给 Agent 足够准确的架构语言、边界和约束。
Coding Agent
把意图转换为规划、执行、核验和部署闭环，合理分配人类注意力与 Agent 自主性。
主导构建
决定做什么、为什么做、何时验证和何时停止，让更快的实现真正转化为用户价值。
关键依赖：软件工程给 Agent 提供约束语言，AI 工程给系统提供不确定性治理方法，产品判断决定优化方向，Coding Agent 则把三者放大。
03
AI 应用工程：用可靠系统包裹不可靠组件
AI 应用与传统软件的根本差异是输出不可预先确定。因此，开发不是“把完整计划一次实现”，而是连续观察中间结果，再决定下一步。优秀工程师的核心能力是让改进方向可测、可解释、可重复。
LLM 基础
理解 token、生成机制、上下文窗口、缓存、知识截止、推理强度、采样和工具调用；据此选择模型组合，以及何时微调或自托管。
数据接地
判断内容应直接放入提示词、按需检索，还是通过工具访问；能在向量索引、知识图谱、结构化数据语义层之间选择，并保持数据清洁与新鲜。
Agentic 系统
在固定工作流与自主 Agent harness 之间选择；设计串并行、工具权限、记忆、长会话上下文、降级路径，以及单 Agent 或多 Agent 架构。
评估驱动开发
从 trace 与错误样本中定义指标；组合确定性检查、LLM-as-a-judge 与人工判定，让每次修改都由误差分布而非直觉驱动。
生产运营
处理模型漂移、延迟、成本、对抗提示和安全事件；建立观测、统计回归、风险分级、告警与事故响应机制。
机器学习基础
掌握监督学习、强化学习、深度学习、偏差—方差、误差分析与数据工程，用统一框架理解模型训练和评估取舍。
观察收集真实输入、输出、trace 与失败样本
度量建立基线，按错误类型和业务风险分桶
改进只改一个主要变量，回归后再进入下一轮
常见偏差：先换更大的模型、先增加复杂 Agent、先做微调，却没有错误数据集和基线。没有评估闭环的“优化”，很容易只是把问题从一个位置移动到另一个位置。
04
软件工程基础：Agent 越会写代码，判断越重要
Coding Agent 能补足局部实现经验，但不会自动知道你的业务优先级。不了解基础，就无法意识到延迟、可用性、一致性、可靠性、可维护性、简单性与成本之间存在取舍，更无法准确指挥 Agent。
| 能力模块 | 需要掌握的内容 | Agent 时代的作用 |
|---|---|---|
| 全栈应用 | UI、渲染、缓存、API、认证、状态、会话、异步、持久化、测试、安全、可访问性 | 把跨层修改拆成可核验的边界，避免“能运行但不正确” |
| 数据管理 | 访问模式、数据模型、事务、并发、一致性、生命周期、隐私与治理 | 为业务与 Agent 构造可靠的事实来源；错误的数据架构会让 AI 不知道自己缺什么 |
| 系统架构 | 前后端边界、状态位置、系统拆分、单体/微服务、技术栈与演进 | 根据项目阶段选择“当前足够好”的结构，而非让 Agent 默认过度设计 |
| 安全可靠 | 测试策略、故障处理、优雅降级、爆炸半径、供应链与云攻击面 | 把安全左移，给 Agent 设置权限、验证和不可跨越的红线 |
| 规模与运营 | CI/CD、发布策略、IaaS、观测、告警、事故、负载均衡、分片、索引、复制 | 从“生成完成”延伸到“线上持续正确、稳定且经济” |
新的学习重点：语法记忆的权重下降，系统机制与权衡语言的权重上升。你的目标不是比 Agent 更快地敲代码，而是比它更清楚什么不能错、为什么这样设计，以及证据是什么。
05
使用 Coding Agent：从提示技巧升级为工作流设计
有效使用 Coding Agent 的稳定框架仍是计划、执行、部署与监控，只是注意力从逐行编码转向需求、架构、上下文、验收和风险。不同项目的规划深度不同：绿色原型可以轻，已有用户的存量系统必须重。
Planning研究 → 理解代码库 → 规格 → 技术设计 → 执行计划
Execution分步实现 → 自动测试 → 行为核验 → 修正
Deploy & Monitor门禁发布 → 观测日志 → 发现问题 → 重新规划
指挥工作流
在速度、成本、技术风险和人工投入间取舍；决定何时调研、写多细的规格、如何分解为可核验步骤，以及何时回到上游重新规划。
开启适度自主
根据风险选择互动式协作或大块委派；管理会话上下文、关键假设、并行 Agent 与权限门禁，让自主范围与可恢复性匹配。
验证工作结果
以功能、行为、截图、评估集、安全扫描和架构检查作为证据；能自动化的尽量自动化，高风险环节保留人工判定。
定制 Agent 环境
配置 Skills、Plugins、MCP、hooks 与 CI/CD；维护 AGENTS.md 等长期上下文，积累会话经验，同时清理过期规则与 Agent 生成债务。
理解 Agent 原理
理解代码检索、上下文管理、工具调用、子 Agent、模型与 harness 的关系，以识别过度设计、提前停止、验证不足和破坏性操作等失效模式。
人类注意力调度
真正稀缺的是人类判断。并行会话越多，越要用明确所有权、状态、产物和验收标准控制认知负载。
| 风险等级 | 适合的自主性 | 最低门禁 |
|---|---|---|
| 低：独立原型、可丢弃代码 | 目标式委派，可长循环 | 能运行、关键截图、基础测试 |
| 中：共享仓库、非关键功能 | 分阶段委派，每阶段核验 | 单测/集成测试、diff、静态检查、可回滚 |
| 高：生产数据、权限、支付 | 最小权限、小步执行、人工批准 | 隔离环境、审计日志、安全测试、发布门禁与恢复演练 |
06
主导构建：不只实现规格，还要参与定义规格
当个人开发半径被 AI 扩大，产品、设计、工程与项目管理边界开始融合。工程师不需要变成完整的产品经理，但要能在信息不完整时推进项目，并对价值结果而非任务完成负责。
驱动 Build Loop
快速决定下一步：做技术实验、原型、MVP、增加功能，还是投入企业级建设；用小批次交付保持速度，以指标推动成熟产品。
做产品决策
理解用户需求、基本设计、市场、单位经济与损益；在无规格时能写出规格，在规格未覆盖处能做合理选择。
沟通与带动
与产品、设计、市场、财务和法务对齐；解释技术可行性和边界，帮助组织理解 AI 带来的新实践。
高主动性所有权
主动发现机会、提出方案、端到端执行；在模糊与挫折中持续推进，并用创造的价值而非完成的任务衡量工作。
用户同理心的证据：2–3 位用户的快速访谈、数百份问卷、A/B 实验或大规模行为数据都可以。方法规模不同，但共同点是让决策接触真实用户，而不是仅由团队内部想象。
07
统一工程闭环：四类能力如何协同
5 篇文章共同指向一个更高层模型：AI 工程师的核心产物不是代码，而是一个不断收敛的决策—执行—证据闭环。
01 · Direction
定义价值与风险
谁的问题？当前替代方案是什么？成功指标是什么？错误的代价有多大？
02 · Specification
把意图变成可验证规格
需求、非功能约束、数据边界、权限、架构、验收样例和停止条件。
03 · Delegation
让 Agent 在边界内执行
拆分任务、装配上下文与工具、配置自主性、隔离高风险操作。
04 · Evidence
收集行为证据
测试、评估集、trace、截图、指标、用户反馈、成本与延迟。
05 · Decision
基于证据决定下一步
修复、简化、扩展、重构、回滚或停止；沉淀新知识进入下一轮上下文。
高质量交付 = 清晰目标 + 受控自主性 + 可执行约束 + 多层验证 + 快速反馈
不是：更长提示词 + 更多 Agent + 更多 token。
不是：更长提示词 + 更多 Agent + 更多 token。
08
边界与误区：这张地图不能替你做什么
| 误区 | 问题 | 更稳妥的方法 |
|---|---|---|
| “用了 Agent 就是 AI 工程” | 工具使用不等于能治理模型不确定性 | 至少建立任务成功率、关键错误率、成本和延迟基线 |
| “先做复杂多 Agent” | 通信、状态与失败面同时增加 | 先证明单 Agent 不够，再按可独立核验的边界拆分 |
| “所有结果都让 LLM 打分” | 判断器也会偏差、漂移与迎合 | 事实与规则优先确定性检查，主观质量再引入模型与人工 |
| “Agent 能修复测试，所以测试可信” | Agent 可能修改测试以适配错误实现 | 关键验收由独立上下文、不可变样例或外部系统提供 |
| “规划越长越专业” | 原型阶段会增加无效成本并固化错误假设 | 让规划深度与不可逆性、影响面和恢复成本匹配 |
| “完成需求就是成功” | 可能更快地交付一个无人需要的功能 | 把产品指标与用户证据放入完成定义 |
需要额外补足：领域知识与真实 ground truth 在技能地图中被分散在数据、评估和产品判断里，但在医疗、金融、法律等高风险场景应单独提升为一级能力。系统可能技术上稳定，却稳定地产生错误业务结论。
09
12 周学习路径：面向已有 Agent 项目经验
这条路线不从“再学一个框架”开始，而是把已有 Java 自研 Agent 项目升级为可评估、可运营、可说明架构取舍的作品。每周都必须留下可展示的证据。
第 1–2 周 · 基线
建立系统与评估画像
选一个已上线 Agent；补齐架构图、核心用户任务、20–50 条真实/合成评估样例、成本与 p95 延迟基线。输出：design.md、eval-set.jsonl、基线报告。
第 3–4 周 · Grounding
重做上下文与数据链路
比较 prompt 注入、工具检索、向量检索与结构化查询；记录命中率、答案正确率和 token 成本。输出：对照实验和失败样本分类。
第 5–6 周 · Agent Loop
约束自主性与工具风险
明确计划、行动、观察、停止状态；加入超时、重试、幂等、权限白名单和降级路径。输出：状态机、故障注入结果与权限矩阵。
第 7–8 周 · Software
补齐生产工程底座
完善 API 契约、数据模型、异步任务、缓存、集成测试、安全扫描、CI/CD 与回滚。输出：ADR、测试金字塔和演练记录。
第 9–10 周 · Coding Agent
搭建可复用开发工作流
写项目级 Agent 说明、任务模板和验证命令；让 Agent 完成一个真实迭代，记录人工介入点、返工率和交付时间。输出：前后效率对比与复盘。
第 11–12 周 · Product
验证用户价值并包装作品
访谈 3–5 位用户，定义北极星指标，迭代一轮；整理 10 分钟演示、技术决策、线上指标和失败案例。输出：可用于面试的端到端案例。
每周固定节奏：20% 阅读原理，60% 改造真实项目，20% 整理证据。判断是否学会的标准不是“看完”，而是能否在自己的系统中做出一次有数据支撑的取舍。
10
实战项目：企业知识任务 Agent
项目目标
构建一个能读取企业文档、回答问题并执行受控任务的 Agent。重点不是功能数量，而是展示四大能力域如何形成完整闭环。
| 阶段 | 必须产物 | 验收证据 |
|---|---|---|
| 问题定义 | 用户故事、非目标、风险等级、成功指标 | 访谈记录；至少一个被放弃的需求及原因 |
| 架构 | 系统边界、数据流、模型/工具选择、ADR | 能解释准确率、延迟、成本与复杂度取舍 |
| Grounding | 解析、索引、检索、权限过滤与新鲜度管道 | 检索 recall、引用正确率、越权测试 |
| Agent | 状态机、工具 schema、停止条件、重试与降级 | 正常、失败、超时、重复调用的 trace |
| 评估 | 版本化数据集、确定性规则、模型评分与人工抽检 | 每次变更的回归曲线及错误分桶 |
| 生产 | CI/CD、指标、告警、成本预算、回滚手册 | 故障演练、p95 延迟、单次成功任务成本 |
| 价值 | 真实用户试用与下一步决策 | 任务完成时间、成功率、采用率或节省成本 |
面试表达模板：先讲业务问题与失败成本，再讲为何选择当前架构；展示评估数据和一次失败迭代，最后说明上线指标与下一步取舍。这样的证据比罗列框架名称更能体现 AI Engineering 能力。
11
能力自测：从“会用”到“能负责”
| 能力域 | 入门：会实现 | 熟练：会权衡 | 进阶：能负责 |
|---|---|---|---|
| AI 应用 | 能接入模型、RAG、工具 | 能按错误分布选择改进手段 | 能长期治理质量、成本、漂移与安全 |
| 软件工程 | 能完成全栈功能 | 能解释架构和数据取舍 | 能设计演进路径、故障隔离和生产运营 |
| Coding Agent | 能用 Agent 生成代码 | 能设计上下文、任务分解和验证 | 能组织并行执行、权限与团队级知识沉淀 |
| 主导构建 | 能按规格交付 | 能补全规格并基于用户反馈迭代 | 能发现机会、对齐团队并对业务结果负责 |
完成标准
- 能用 3 分钟解释系统的主要不确定性及如何度量。
- 能指出至少 3 个真实架构取舍，并说明为何当前阶段这样选择。
- 能展示 Agent 输出的独立验证证据，而不是只展示最终页面。
- 能说明哪些操作禁止 Agent 自主执行，以及失败后的恢复路径。
- 能把一次用户反馈映射到规格、实现、评估和指标的变化。
12
个人能力差距判断：已有 Java Agent 项目该补什么
你已经做过多个自研 Java Agent，并有部署上线经验，因此不需要再从“调用模型 API”或“认识 Agent 框架”开始。下一阶段应把隐性的开发经验变成可重复、可度量、可向面试官证明的工程体系。
| 优先级 | 能力缺口 | 升级动作 | 完成证据 |
|---|---|---|---|
| P0 | 评估与错误分析 | 为一个线上 Agent 建立版本化评估集、错误分类和回归门禁 | 至少 50 条样例；每次迭代能展示指标变化与回归结果 |
| P0 | Agent 可观测性 | 统一记录计划、工具调用、参数、模型响应、成本、延迟与停止原因 | 能从一次失败请求还原完整因果链，而非只看报错文本 |
| P0 | 上下文工程 | 区分长期规则、任务上下文、检索数据与会话状态，设置预算和淘汰策略 | 上下文变短或成本下降时，任务成功率不下降 |
| P1 | 自主性治理 | 按工具副作用分级权限；补齐幂等、超时、重试、人工门禁和恢复路径 | 故障注入后不会重复写入、越权操作或无限循环 |
| P1 | 产品指标 | 把“模型效果好”改写成任务成功率、人工接管率、单次成功成本与用户采用率 | 一次技术迭代能映射到至少一个用户或业务指标 |
| P2 | 开发 Agent 工作流 | 沉淀项目规则、任务模板、验证命令、ADR 和会话复盘 | 另一位开发者或新 Agent 会话能稳定复现同等质量 |
减少框架横向收集
除非现有架构无法满足明确需求，否则不要把时间消耗在多个 Agent 框架的 Hello World 对比上。框架切换很难直接形成高级工程证据。
把一个系统做透
围绕同一个线上系统完成评估、数据、架构、安全、成本、监控与用户价值闭环。纵向深度比功能数量更接近高级岗位要求。
最短升级路径：从现有 Agent 中选一个失败样本最多、业务价值最清晰的项目；先冻结 50 条评估样例，再改系统。这样两周内就能从“我做过 Agent”升级为“我能用证据持续改进 Agent”。
13
可复用工程模板：把判断固化为 Agent 可执行上下文
模板的目的不是增加文档数量，而是把关键决策变成执行与验证的共同接口。小项目可以每项只写几行，高风险项目再逐步加深。
A. AI 功能规格卡
Problem：谁在什么场景遇到什么问题？当前替代方案是什么？
Outcome：成功后哪个可观察指标改变？基线与目标是多少？
Scope：本轮做什么 / 明确不做什么？
Inputs：允许的数据源、权限、新鲜度与隐私边界。
Behavior：3–5 个黄金样例 + 关键反例。
Failure：哪些错误可接受？哪些必须拒答、降级或转人工？
Constraints：p95 延迟、成本、可用性、安全与兼容性。
Done：自动测试、评估阈值、人工门禁与上线证据。
Outcome：成功后哪个可观察指标改变？基线与目标是多少？
Scope：本轮做什么 / 明确不做什么？
Inputs：允许的数据源、权限、新鲜度与隐私边界。
Behavior：3–5 个黄金样例 + 关键反例。
Failure：哪些错误可接受？哪些必须拒答、降级或转人工？
Constraints：p95 延迟、成本、可用性、安全与兼容性。
Done：自动测试、评估阈值、人工门禁与上线证据。
B. Agent 任务委派卡
- 目标：只写期望状态，不预设无依据的实现。
- 上下文：相关文件、架构约束、历史决策。
- 边界：禁止修改项、数据权限、外部副作用。
- 步骤：先调查并报告，再按可核验单元执行。
- 验证：必须运行的命令、测试与视觉证据。
- 停止：遇到哪些情况必须暂停并请求判断。
C. 评估样例卡
- 输入：真实任务、上下文与用户角色。
- 期望：事实、行为、格式和禁止项。
- 判定：确定性规则 / 模型评分 / 人工。
- 严重度：普通、重要、不可接受。
- 来源：线上失败、用户反馈、合成边界。
- 版本：首次出现、修复版本、回归状态。
D. 上线决策表
| 门禁 | 问题 | 可接受证据 |
|---|---|---|
| 质量 | 核心任务是否达到阈值，是否出现严重回归？ | 冻结评估集结果、关键失败样本 |
| 安全 | 能否越权、泄露数据或被提示注入操纵？ | 攻击样例、权限测试、依赖扫描 |
| 可靠性 | 超时、限流、工具失败时系统如何退化？ | 故障注入、重试与降级 trace |
| 经济性 | 成功任务的真实成本是否可持续？ | 模型、检索、工具与人工成本拆分 |
| 恢复 | 错误发布后能否快速发现并回退？ | 告警规则、回滚演练、责任人 |
14
面试验证题：证明你具备 AI Engineering 判断力
高质量回答应包含具体项目背景、备选方案、取舍依据、验证证据和结果。只说“用了某框架”通常无法证明能力。
| 面试问题 | 回答应覆盖的证据 |
|---|---|
| 你的 Agent 最严重的一类失败是什么？如何发现？ | 错误分桶、发生频率、业务影响、代表样例 |
| 为什么选择当前 Grounding 方案，而不是纯向量 RAG？ | 数据形态、查询类型、权限、新鲜度、实验结果 |
| 如何证明一次优化真的有效？ | 冻结评估集、基线、单变量实验、统计与回归 |
| 哪些任务允许 Agent 自主完成，哪些必须人工批准？ | 副作用、权限、可逆性、爆炸半径和恢复成本 |
| 如何处理工具超时、重复调用和部分成功？ | 幂等键、状态机、重试策略、补偿事务与 trace |
| 模型升级时如何避免线上质量悄悄下降？ | 版本化输入、离线评估、影子流量、灰度与告警 |
| 何时选择工作流，何时选择自主 Agent？ | 任务确定性、步骤可枚举性、动态信息与风险 |
| 如何降低成本而不明显损害效果？ | 路由、缓存、上下文裁剪、小模型、并发与工作流简化 |
| 描述一个你主动放弃的功能。 | 用户证据、机会成本、指标预期和停止条件 |
| Coding Agent 在你的开发流程中如何被验证？ | 任务规格、自动化检查、独立验收、人类介入点 |
STAR+：场景 Situation → 目标 Task → 行动 Action → 结果 Result → 证据 Evidence → 取舍 Trade-off → 复盘 Learning
准备方法：从一个真实项目中准备 3 条故事——一次架构取舍、一次线上失败、一次基于用户反馈改变方向。三条故事应共享同一套系统背景，使回答呈现纵向深度。
15
资料来源与阅读顺序
- 01 · The AI Engineering Skills Map
总纲：四个一级能力域、研究方法与价值变化。 - 02 · Building and Deploying AI Applications
AI 应用：LLM、Grounding、Agent、评估、生产与机器学习基础。 - 03 · Software Engineering Fundamentals
工程底座：全栈、数据、架构、安全可靠与生产运营。 - 04 · Using Coding Agents
Agent 工作流：规划、执行、部署监控，以及五项关键驾驭能力。 - 05 · Shaping the Build
角色升级：驱动构建、产品决策、沟通带动与高主动性所有权。 - Andrew Ng 官方 Writing 索引
系列文章的官方索引与发布日期。
说明：正文为面向学习与实践的结构化转述，并补充工程化推导、风险边界、12 周路径和项目方案；不等同于逐句翻译。