AI 应用越来越容易做出一个能运行的原型，真正困难的部分开始转向：怎样让它在输入变化、数据不完整、成本受限的情况下仍然稳定工作。Andrew Ng 最近分享的 AI Engineering Skills Map，把「构建和部署 AI 应用」拆成六类能力，为这件事提供了一张清晰的检查表。
这张地图适合已经能调用模型、写一些工作流，却想继续提高系统可靠性的开发者。它关注的重点不只是模型知识，也包括上下文组织、评测、生产运维和机器学习基础。读完之后，你可以用它判断一个项目卡在哪里，也能更具体地安排自己的学习顺序。
AI 工程的核心难题
传统软件通常可以先定义输入、规则和输出，再按计划实现。AI 应用多了一个不确定性：你无法提前知道 LLM 会怎样生成文本，也无法完全预知监督学习模型对某个样本会给出什么预测。
这会改变开发方式。一个成熟的 AI 工程师往往会反复完成下面的循环：
- 先构建一小段可运行的软件。
- 观察输出、调用轨迹和实际错误。
- 根据中间结果选择下一步实验。
- 把有效的改动纳入评测和回归测试。
因此，AI 工程的价值不只在于「会用某个模型」，还在于能否把不稳定的 AI 组件放进一个可观察、可验证、可维护的系统中。
Andrew Ng 说明，这张能力地图来自大量职位描述、专家访谈和问卷反馈。它更像一份工程能力的全景图，不能直接当作唯一的课程顺序；不同岗位和项目会有不同的优先级。
六类能力
1. LLM 基础
理解模型的输入与输出机制，是判断模型边界的起点。至少需要知道：
- 输入如何被切分为 token，模型如何生成输出。
- 上下文窗口、知识截止时间、缓存命中和采样参数会怎样影响结果。
- 什么时候应该选择多模态模型，什么时候需要调整推理强度。
- 工具调用适合解决什么问题，模型选择与模型组合如何取舍。
这些知识会直接影响工程决策。例如，模型没有看到某段资料时，继续调整采样参数通常解决不了事实缺失；上下文太长时，盲目追加内容也可能增加成本并降低有效信息的比例。
在更高要求的场景，还需要理解微调、自托管和专用模型的适用边界。这里的重点并非记住每个模型的宣传参数，而是能解释某个模型为什么适合当前任务，以及它会在哪些输入上失效。
2. 用数据补足上下文
LLM 的表现高度依赖输入上下文。RAG 结合向量搜索曾经是常见起点，但实际工程需要在更多方案之间做选择：哪些信息应该直接放进 prompt，哪些信息应该让模型通过工具按需获取，数据应该用向量索引、知识图谱，还是结构化数据之上的语义层来表示。
数据准备也属于这项能力。文本、PDF、HTML 和图片都要先转成适合模型处理的输入，还要建立保持数据清洁和及时更新的处理链路。
可以把这一层理解为「上下文供应系统」：
- 数据入口：明确来源、权限、更新频率和格式。
- 数据处理：解析文档，清理噪声，保留标题、表格和关联关系。
- 数据检索：根据问题选择关键词、向量、图关系或结构化查询。
- 上下文组装：控制相关性、长度、顺序和引用信息。
上下文工程做得好，模型才有机会基于正确资料回答；做得差时，模型本身再强也会被错误、过期或互相矛盾的输入拖住。
3. 构建 Agent 系统
Agent 系统的范围很宽：一端是固定顺序的多个模型调用，另一端是由模型持续判断下一步行动的 Agent harness。工程师需要先决定系统属于哪一类，再设计流程。
常见的设计问题包括：
- 哪些步骤需要串行，哪些步骤可以并行。
- 什么时候使用普通代码，什么时候交给 LLM 判断。
- 工具列表应该包含哪些 MCP、CLI 或沙箱能力。
- 记忆怎样保存，长会话怎样管理上下文。
- 任务适合单 Agent，还是确实需要多 Agent 协作。
原文还强调了从原型走向生产时的安全要求。工具权限、回退路径、提示注入、数据外泄、对抗性输入和治理规则，都应当在系统设计阶段考虑。一个能完成演示的 Agent，不等于一个可以放心处理真实数据的系统。
4. 评测驱动开发
在 Andrew Ng 的经验里，优秀 AI 工程师最重要的特征之一，是能持续运行评测与错误分析循环。这个循环让团队把时间投入到更可能有效的方向上，减少凭感觉调 prompt 或换模型。
评测没有一套适用于所有项目的固定答案。可以根据风险和阶段组合使用：
- 确定性评测：用代码检查格式、字段、权限和规则。
- LLM-as-a-judge：让模型按明确标准比较开放式输出。
- 人工评审：在高风险或标准尚未稳定时保留人工判断。
评测本身也要被验证。需要检查评测集是否覆盖真实输入，评分标准是否稳定，自动评审是否偏向某种答案，以及评测结果能否解释产品体验中的问题。
一个实用的错误分析记录至少可以包含：输入样本、上下文、工具调用、模型输出、期望结果、错误类别和下一步实验。这样，系统改进就有了可比较的依据。
5. 运行生产系统
AI 软件进入生产环境后，除了正确性，还要面对不可预测性、成本和延迟。系统需要能够回答几个问题：实际用户遇到了什么，模型表现是否发生漂移，哪个环节变慢了，失败是否与安全事件有关。
因此，生产能力至少包括：
- 记录请求、响应、工具调用和关键评测信号，建立可用的可观测性。
- 监测质量变化、数据漂移、延迟和费用。
- 用回归测试与持续集成/持续交付检查重要路径。
- 为提示注入、越权调用和其他对抗性输入准备检测与响应方案。
- 在模型选择、蒸馏、微调和工作流简化之间做成本与延迟取舍。
传统软件的测试习惯仍然有用，但 AI 系统需要更多统计性的评估。测试投入应当和错误风险匹配：客服问答、内部搜索和医疗建议的容错边界显然不同。
6. 机器学习基础
现代 LLM 建立在监督学习、强化学习等机器学习技术之上，很多 AI 应用也仍然需要直接使用别人训练好的模型，或训练自己的模型。
机器学习基础的价值，在于帮助工程师理解模型与数据之间的关系。需要掌握的内容包括常见机器学习和深度学习模型、训练与推理速度、准确率取舍，以及为训练和评测准备数据的方法。
偏差与方差、错误分析、数据工程这些概念，也能帮助我们处理更广泛的不确定系统。它们提供了一套分析框架：问题来自数据、模型、上下文、评测标准，还是部署环境？只有把错误分到正确的层，后续改动才不会变成无效试错。
这张地图怎样指导工作
六类能力并不要求每个人同时达到同样深度。更实际的用法，是把它当作项目诊断表。
如果回答经常缺少事实，优先检查数据入口、检索方式和上下文组装；如果回答风格变化很大，检查模型参数、提示边界和评测集；如果 Agent 偶尔执行危险动作，检查工具权限、回退路径和对抗性测试；如果线上费用持续上升，则要把模型选择、缓存、上下文长度和工作流结构放在一起看。
团队分工也可以借用这张地图。应用开发者可能更关注 Agent 工作流和生产监控，数据工程师更关注上下文供应，机器学习工程师更关注模型训练与评测。边界可以分工，评测和错误分析则应该成为共同语言，因为它们连接了模型、数据、代码和产品体验。
结语
AI 工程的难点正在从「能否调用模型」转向「能否围绕不确定组件构建可靠系统」。LLM 基础帮助我们理解模型，数据能力帮助模型获得合适上下文，Agent 设计负责组织行动，评测推动改进，生产运维保证真实用户能稳定使用，机器学习基础则提供分析错误的底层框架。
如果要从今天开始练习，可以选择一个已有的 AI 原型，先补齐输入样本、输出记录和最小评测集，再根据错误分布决定下一步。这样学习每一项能力时，都能看到它对系统质量的具体影响。
Aide Hub 会继续分享 AI 助手、开发工具和软件工程实践。如果你正在构建 AI 应用，也可以从这六类能力中选一项，记录项目里最常见的失败模式。