索未 · 阅读｜周读·深度书评

7.31 | 周读 | 《AI Engineering》Chip Huyen

过去几年，很多人学习人工智能的起点，是研究怎样写出一个更好的提示词。

我们尝试给模型设定角色、补充背景、提供案例、限定格式，希望只需修改几句话，就能让 AI 生成更准确、更稳定的结果。

提示词当然重要。

但当 AI 真正进入内容生产、客户服务、数据分析、软件开发、知识管理和企业自动化之后，一个越来越明显的问题出现了：

提示词只能改善一次调用，无法独立解决整个 AI 应用的可靠性问题。

模型选错了，提示词再精细也很难补救；没有评估标准，输出质量只能依靠感觉；检索数据混乱，RAG 反而可能把错误信息更稳定地送进模型；Agent 权限过大，一次错误判断就可能演变为真实操作风险；系统没有监控，企业甚至不知道 AI 在什么条件下开始失效。

Chip Huyen 的《AI Engineering》讨论的，正是如何跨过这道分界线：

从“会调用模型”，走向“能够设计、评估、部署和持续改进 AI 应用”。

这本书不是一本提示词技巧合集，也不是教读者从零训练大模型。它关注的是一个更现实的问题：

当企业已经可以使用现成的基础模型时，应该怎样把模型转化为真正可用的产品和业务系统？

01 从机器学习工程到 AI 工程

Chip Huyen 将 AI 工程概括为：使用已经可以获得的基础模型构建应用的过程。

传统机器学习项目通常需要经历数据采集、特征设计、模型训练、部署和监控。基础模型改变了这个起点。开发者不一定需要从头训练模型，可以通过模型 API、开源模型、提示词、检索增强、微调和工具调用，快速构建新的应用。

因此，AI 应用开发的主要矛盾发生了变化。

过去的问题常常是：

我们能不能训练出一个模型？

现在的问题更多是：

面对大量可选模型，我们应该选哪个？怎样知道它是否适合当前任务？怎样控制质量、成本、延迟和风险？

《AI Engineering》由此建立了一套完整框架，内容覆盖基础模型、评估方法、模型选择、提示工程、RAG、Agent、微调、数据集工程、推理优化、系统架构和用户反馈。O'Reilly 页面将其标注为一本 534 页的中高级技术书，核心目标不是介绍单一工具，而是解释如何基于基础模型设计和部署完整应用。

这也是"AI 工程”与单纯使用 AI 工具之间最重要的差别。

使用 AI 工具，是完成一次任务。

AI 工程，则要确保同一类任务能够在不同用户、不同数据、不同时间和不同运行环境下，持续产生可以接受的结果。

02 这本书真正讨论的不是模型，而是系统

第一次接触 AI 应用时，我们很容易把注意力全部放在模型上。

哪个模型参数更多？

哪个模型基准测试分数更高？

哪个模型推理能力更强？

哪个模型上下文窗口更长？

这些问题并非不重要，但《AI Engineering》反复强调：模型只是 AI 系统中的一个组成部分。

一个真实的 AI 应用还可能包括：

• 用户输入与权限验证；
• 系统提示和任务指令；
• 企业知识库；
• 文档切分与检索系统；
• 模型路由；
• 工具调用；
• 安全护栏；
• 缓存系统；
• 输出审核；
• 成本和延迟控制；
• 日志、监控与告警；
• 用户反馈；
• 人工接管机制。

书中最后形成的 AI 应用架构，也不是简单地把用户输入发送给模型，而是逐步增加上下文增强、护栏、模型路由、缓存、Agent 模式、监控和反馈系统。作者同时提醒，每增加一个组件，系统可能变得更强，但也会增加复杂度并引入新的失败方式。

这带来一个很重要的认识：

AI 应用的质量，不能只用模型能力解释。

同一个模型，在不同系统中可能产生完全不同的结果。

一个能力并非最强的模型，如果配合高质量数据、明确的任务边界、可靠的评估和完善的反馈系统，可能比一个更强但缺少工程控制的模型更有业务价值。

03 第一个核心观点：评估不是最后一步，而是整个 AI 工程的起点

很多 AI 项目的典型流程是：

先选择一个热门模型，开发功能，投入使用，最后再看看效果怎么样。

《AI Engineering》提出了几乎相反的顺序。

在选择模型、改写提示词、建设 RAG 或部署 Agent 之前，应当先明确：

• 这个应用要解决什么问题；
• 什么结果可以被视为合格；
• 哪些错误可以接受；
• 哪些错误绝对不能发生；
• 如何衡量准确性、完整性和一致性；
• 用户愿意等待多长时间；
• 单次调用成本上限是多少；
• 什么情况下必须转交人工。

作者用了两个完整章节讨论评估。书中指出，基础模型能够生成开放式答案，这使其比传统分类或预测模型更难评价。对于开放式输出，很难只依靠一个准确率指标判断质量，因此往往需要结合功能正确性、参考答案相似度、人工评价、AI 评审和成对比较等多种方法。

作者也明确提醒，AI 评审具有主观性，不能脱离所使用的评审模型理解其分数，最好与精确评估或人工评估结合。

这部分内容给我的最大启发是：

没有评估集，就没有真正意义上的 AI 优化。

假设一家企业用 AI 生成产品介绍。

如果团队只是随机查看几篇内容，然后评价“感觉还可以”，那么后续无论更换模型、修改提示词还是增加知识库，都很难知道系统是否真正改善。

更合理的方式，是预先建立一组代表性任务，并为每项任务规定检查标准，例如：

事实是否准确，参数是否与数据源一致，是否遗漏关键限制，是否出现未经证实的承诺，是否符合品牌语言规范，是否需要人工修改，以及最终是否可以直接发布。

只有建立稳定的测试集，团队才能比较不同模型、提示词和检索方案。

因此，AI 工程的第一项能力不是写提示词，而是：

把模糊的“质量不错”，转化为可以检查、记录和比较的标准。

04 第二个核心观点：不存在脱离任务的“最佳模型”

很多模型排行榜试图回答一个简单问题：

哪个模型最好？

但企业真正需要回答的是：

哪个模型最适合当前任务？

一个模型可能擅长复杂推理，却在结构化信息提取上成本过高；一个模型可能生成能力很强，却无法满足特定的数据部署要求；另一个模型速度很快，但在长文事实一致性方面表现不足。

模型选择至少需要综合考虑：

• 任务能力；
• 指令遵循；
• 事实一致性；
• 输出稳定性；
• 结构化输出能力；
• 安全性；
• 延迟；
• 单次费用；
• 上下文需求；
• 数据隐私；
• 部署方式；
• 工具调用能力。

《AI Engineering》指出，公共基准测试可以帮助排除明显不合适的模型，却很难直接告诉企业哪个模型最适合自己的应用。更有效的方法，是根据真实任务建立企业自己的评估流程，相当于建立一张内部模型排行榜。

这意味着，企业不应只维护一份“当前使用的 AI 模型名单”，而应建立一张更完整的模型—任务匹配表。

例如，同一家企业可以采用：

• 快速低成本模型处理分类和信息提取；
• 推理模型处理复杂分析；
• 多模态模型检查图片和文档；
• 私有化模型处理特定敏感数据；
• 备用模型应对主模型不可用或质量下降；
• 人工流程接管高风险任务。

模型不再是企业一次性采购的软件，而更像一组需要持续评估和调度的能力资源。

未来的 AI 竞争，并不只是拥有某个最强模型，而是能否根据任务选择正确模型，并让多个模型在成本、速度和质量之间形成合理组合。

05 第三个核心观点：提示词应当被当作系统配置，而不是个人诀窍

提示工程是书中的重要部分，但作者没有把它包装成某种神秘技巧。

从工程角度看，提示词更接近软件配置、产品规则和操作流程。

一个用于生产环境的提示词，至少需要做到：

• 指令清晰；
• 上下文充分；
• 输入输出边界明确；
• 复杂任务适当拆分；
• 示例具有代表性；
• 输出格式可以验证；
• 不同版本可以追踪；
• 修改后可以重新评估；
• 能够防范提示注入和信息泄露。

书中专门讨论了提示词组织、版本管理、越狱、提示注入和防御性提示工程。这说明提示词一旦进入真实业务，就不能继续以“某位员工电脑中的一段文字”存在，而应当被纳入版本控制、测试、权限和变更管理。

这与很多企业目前的做法存在明显差距。

现实中，一套重要的 AI 工作流可能依赖某个人保存的提示词。员工离职、模型升级或者业务规则变化后，没有人知道原始提示为什么这样写，也无法判断修改是否影响结果。

真正的工程化做法应该包括：

• 给提示词分配名称和版本；
• 记录适用模型；
• 说明输入字段；
• 定义输出结构；
• 保存测试案例；
• 记录修改原因；
• 对比修改前后的合格率；
• 建立回滚机制。

提示词仍然重要，但它的价值不在于偶然写出一句“神奇咒语”，而在于成为一项可维护、可验证、可复用的企业资产。

06 第四个核心观点：RAG 首先是检索工程，不是模型魔法

检索增强生成，也就是 RAG，是当前企业 AI 应用中最常见的方案之一。

它的基本逻辑并不复杂：

先从外部知识库中找到与问题有关的信息，再把这些信息交给模型生成答案。

这样做可以让模型使用企业文档、产品资料、知识库和最新数据，而不是只依赖预训练阶段形成的知识。

但 RAG 并不会自动消除幻觉。

如果检索到的内容不相关、已经过期、彼此矛盾或者缺少关键上下文，模型仍然可能根据错误材料生成一个语言流畅的答案。

《AI Engineering》指出，RAG 的效果高度依赖检索器质量。关键词检索工具实施成本较低，可以形成有力基线；基于 Embedding 的语义检索计算更复杂，但在适当场景中可能取得更好效果。书中也把检索优化、多模态检索、Agent 和记忆系统放在同一条能力演进路径中讨论。

因此，企业建设 RAG 系统时，不能只问：

“应该选择哪个向量数据库？”

更需要问：

• 文档是否经过清理；
• 内容是否存在多个版本；
• 哪个版本具有最高权威性；
• 文档应该怎样切分；
• 标题、时间、来源和权限是否保留；
• 检索结果是否覆盖关键事实；
• 是否需要关键词与语义混合检索；
• 模型能否明确引用信息来源；
• 检索失败时应当怎样处理；
• 敏感文档是否会被错误提供给无权限用户。

RAG 项目的核心资产，不是向量数据库本身，而是企业是否建立了高质量、可治理、可追溯的知识体系。

从这个角度看，RAG 既是 AI 工程，也是内容治理、知识管理和信息架构工程。

07 第五个核心观点：Agent 的价值来自工具，风险也来自工具

普通对话模型主要生成文字。

Agent 则可以获得工具，并尝试完成多步骤任务。

它可以搜索资料、读取文件、调用接口、生成代码、更新数据、创建任务，甚至操作其他业务系统。

这使 AI 从“回答问题”走向“执行任务”。

《AI Engineering》把 Agent 理解为运行在特定环境中、能够使用工具并进行规划的系统。模型负责分析任务、比较可能路径并选择行动；记忆和反思机制则帮助它跟踪进度和调整计划。

但书中同时提出一个非常关键的警告：

工具越多，Agent 能力越强；自动化程度越高，失败的后果也可能越严重。

一个只会生成文案的模型，即使出错，通常还需要人复制和发布。

一个能够直接更新网站、发送邮件、修改价格或调用支付接口的 Agent，一旦理解错误，后果会迅速从“错误答案”变成“错误行动”。

因此，Agent 部署不能只研究规划能力，还必须同步设计：

• 工具白名单；
• 最小权限；
• 参数校验；
• 操作前确认；
• 高风险步骤人工审批；
• 调用次数限制；
• 预算限制；
• 异常中止；
• 完整操作日志；
• 人工接管；
• 失败后的回滚机制。

对于企业而言，判断一个任务是否适合 Agent，不应只看它能否自动完成，还要评估：

一旦执行错误，企业能否及时发现、阻止和恢复？

这可能是 Agent 时代比“模型是否聪明”更重要的问题。

08 第六个核心观点：不要在没有证据时增加系统复杂度

技术团队很容易被新概念吸引。

看到提示工程，就重写全部提示词；看到 RAG，就建设向量数据库；看到 Agent，就把原有流程改造成多 Agent 协作；看到微调，又准备收集数据训练专用模型。

但复杂并不等于先进。

《AI Engineering》的章节顺序隐含了一条很实用的开发路径：

先定义应用，建立评估，再优化提示；根据实际失败原因决定是否增加检索、Agent 或微调；进入生产环境后，再持续处理数据、推理成本、延迟、监控和用户反馈。

这条路径的重点不是要求所有企业完成全部步骤，而是：

每增加一层复杂度，都应该有清楚的失败证据和收益依据。

一个任务通过清晰提示词就能稳定完成，就没有必要立即微调模型。

一个知识库用关键词搜索已经能够提供准确结果，就不一定需要复杂的向量检索。

一个固定的自动化流程可以用传统程序实现，就不必强行加入自主规划 Agent。

一个高风险任务缺少稳定评估和回滚机制，就不应追求完全自动执行。

因此，我更愿意把 AI 应用成熟度理解为一条渐进式路线：

单次模型调用 → 结构化提示 → 评估体系 → 外部知识检索 → 安全护栏 → 模型路由 → 工具调用 → Agent → 微调与专用模型。

这不是必须逐级完成的固定流程，而是一种控制复杂度的方法。

每次升级之前，都应回答三个问题：

现在的系统具体在哪里失败？

新增组件能解决这个失败吗？

新增组件带来的收益是否大于成本和风险？

09 第七个核心观点：数据优势最终来自反馈闭环

当越来越多企业都可以调用相似的基础模型时，模型本身很难长期构成独占优势。

真正可能形成差异的，是企业拥有的：

• 专有业务数据；
• 高质量任务样本；
• 评估标准；
• 用户反馈；
• 失败案例；
• 人工修改记录；
• 业务流程经验；
• 对特定场景的长期理解。

《AI Engineering》最后专门讨论用户反馈，是因为生产环境中的真实反馈可以帮助团队发现模型在实验阶段没有暴露的问题，并逐步形成数据飞轮。作者认为，AI 工程正在比传统机器学习工程更接近产品工作，其中一个原因正是产品体验和反馈数据越来越重要。

例如，企业使用 AI 生成内容时，不应该只保存最终文章，还可以记录：

• 模型生成了什么；
• 人工删除了什么；
• 人工增加了什么；
• 哪些事实被纠正；
• 哪些表达不符合品牌规范；
• 哪些内容最终被采用；
• 哪些内容发布后效果更好；
• 哪些错误重复出现。

这些数据的价值，远高于简单统计“生成了多少篇文章”。

因为它们能够告诉企业：

AI 在哪些任务中真正节省了时间，在哪些任务中只是把工作从写作转移成审核，以及哪些问题值得通过提示词、检索、模型更换或流程调整来解决。

10 对普通 AI 使用者有什么启发

虽然《AI Engineering》具有较强技术属性，但它并不只适合程序员。

即使不亲自编写 AI 应用，普通使用者也可以从中获得三项重要能力。

不再把一次成功当作稳定能力

AI 偶尔生成一篇好文章，不等于它已经能够稳定承担内容生产。

判断 AI 能力，需要用不同输入重复测试，观察平均质量和失败边界。

不再把错误全部归因于模型

AI 输出不好，可能是模型问题，也可能是指令不清、上下文不足、数据错误、检索失败、任务拆分不合理或审核标准缺失。

只有定位具体失败环节，优化才有意义。

不再迷信复杂工具

学习 AI 不是尽可能多地安装工具、搭建工作流和创建 Agent。

真正的目标是用最低的必要复杂度，可靠地解决一个现实问题。

11 对企业 AI 落地有什么启发

企业使用 AI 时，最容易犯的错误是从工具开始，而不是从任务开始。

看到某个 AI 产品很流行，就购买账号；看到竞争对手部署知识库，就立即建设 RAG；看到 Agent 能够执行任务，就希望一次性实现全流程自动化。

更合理的起点，是先建立一张任务清单。

每项任务至少说明：

• 业务目标；
• 使用人员；
• 当前流程；
• 月处理量；
• 人工耗时；
• 错误成本；
• 所需数据；
• 是否涉及敏感信息；
• 可接受延迟；
• 最低质量标准；
• 人工审核要求；
• 预期收益。

然后再决定使用通用模型、专业模型、传统自动化、RAG、Agent，还是继续保留人工处理。

这一思路能够避免一种常见现象：

企业部署了很多 AI 功能，却无法说清楚它们究竟提高了多少效率、减少了多少错误，或者创造了什么新的业务价值。

AI 工程最终仍然要回到工程的基本原则：

目标明确，输入可控，过程可观测，结果可评估，错误可恢复。

12 这本书有哪些阅读门槛

《AI Engineering》并不是一本轻松的 AI 科普读物。

它涉及概率、Embedding、模型评估、检索算法、微调、量化、推理指标和系统架构。没有编程或机器学习基础的读者，部分章节可能比较吃力。

但这并不意味着非技术读者必须跳过整本书。

可以采用三层阅读方式。

第一层重点阅读第一章、评估章节和最后的系统架构章节，理解 AI 工程的整体框架。

第二层阅读提示工程、RAG 和 Agent 部分，理解常见 AI 应用模式。

第三层再进入微调、数据集工程和推理优化，补充更深层的技术知识。

这本书也存在技术书籍不可避免的局限：

AI 模型、开发框架和产品接口变化非常快，具体工具与实现方式可能不断更新。因此，它最值得长期保留的并不是某个模型名称或框架操作，而是评估、数据、成本、反馈、监控和复杂度管理等相对稳定的工程原则。

13 我对这本书的进一步判断

读完这本书，我认为 AI 工程真正要解决的，并不是如何让模型显得更聪明。

它要解决的是：

怎样让一个具有概率性、会产生错误、能力不断变化的模型，进入需要稳定结果的现实系统。

传统软件通常按照明确规则运行。

基础模型则可能面对相同输入产生不同表达，也可能在缺少信息时继续生成看似合理的答案。

因此，AI 工程不能追求绝对消除不确定性，而应建立一套管理不确定性的机制：

• 用评估发现错误；
• 用数据改善表现；
• 用检索补充知识；
• 用护栏限制行为；
• 用权限控制风险；
• 用监控发现异常；
• 用反馈持续迭代；
• 用人工审核承担最终责任。

从这个角度看，AI 工程不只是技术岗位的变化，也是一种新的组织能力。

它要求产品、技术、内容、数据、安全、法务和业务人员共同定义什么是正确结果、什么风险不能接受，以及什么情况下应该停止自动化。

未来企业之间的 AI 差距，未必主要来自是否能够访问最先进的模型。

更可能来自四个方面：

谁拥有更清晰的任务定义，谁建立了更可靠的评估体系，谁积累了更高质量的业务数据，谁能用更低风险把 AI 接入真实流程。

14 本周实践：建立一张最小 AI 应用评估表

选择一个正在使用 AI 完成的真实任务，例如：

• 撰写文章；
• 整理资料；
• 回复客户；
• 分析数据；
• 提取文档信息；
• 生成产品说明；
• 检查网站内容。

准备 20 个具有代表性的测试案例，然后为每个输出记录：

• 是否完成任务；
• 事实是否准确；
• 是否遗漏重要信息；
• 是否符合格式要求；
• 是否需要人工修改；
• 人工修改时间；
• 响应时间；
• 单次费用；
• 是否出现严重错误；
• 最终是否采用。

不要急着更换模型或增加工作流。

先用这张表理解当前系统究竟表现如何。

这一步看起来没有生成一篇新内容，也没有搭建一个新 Agent，却可能是整个 AI 应用建设过程中最有价值的一步。

因为从这一刻开始，我们不再只是“使用 AI"。

我们开始真正地管理 AI。

15 结语

《AI Engineering》最重要的价值，是把 AI 从充满想象力的演示环境，带回真实、复杂并且需要承担结果的生产环境。

它提醒我们，模型能力只是起点。

一个真正可用的 AI 应用，还需要任务设计、模型选择、评估体系、数据工程、检索系统、安全护栏、成本控制、监控反馈和持续维护。

提示词并没有过时。

但提示词只是整个 AI 系统中的一层。

当 AI 开始进入企业流程，我们需要关心的不再只是：

“怎样让模型回答得更好？”

而是：

“怎样让整个系统在面对变化、错误和不确定性时，仍然保持可用、可控和可改进？”

这正是从 AI 使用者走向 AI 工程思维的分界线。

也是个人与企业真正开始建立 AI 能力的起点。

· · ·

本期互动

你现在使用 AI 最多的任务是什么？

在实际使用过程中，你遇到的最大问题是答案不准确、结果不稳定、缺少业务知识，还是无法接入真实工作流程？

欢迎留下你的实际场景。很多 AI 问题，只有放回具体任务中，才能找到真正有效的解决方案。

下期预告

周读：《Hands-On Large Language Models》

下一期将从 AI 应用系统继续向模型内部推进，讨论 Token、Embedding、Transformer 和 RAG 究竟怎样工作，以及普通 AI 使用者为什么也需要理解这些基础概念。

标签

#人工智能, #AIEngineering, #AI 工程, #大语言模型, #基础模型, #AI 应用, #提示工程, #RAG, #AIAgent, #模型评估

推荐阅读:

未来一年，我为什么要重新建立自己的知识体系：从 AI、成长到商业实践的 52 周阅读计划

周读｜《Designing Multi-Agent Systems》Victor Dibia！

周读：《AI Agents in Action》Micheal Lanham!