《AI工程:大模型应用开发实战》读书笔记-夜雨聆风

《AI工程:大模型应用开发实战》读书笔记

这本书对我最大的价值，不是告诉我又出现了哪些新工具，而是把 AI 应用开发从“玩模型”拉回到“做系统”。

AI 工程不是调几个 prompt，也不是接一个模型 API。它更像传统软件工程、ML 工程、产品工程的交叉地带：模型只是核心组件之一，真正决定产品能不能上线、能不能稳定、能不能赚钱的，是评估、数据、架构、成本、延迟、反馈闭环和分发能力。书里反复强调：工具会过时，但底层问题不会，比如模型为什么会幻觉、为什么评估困难、为什么 demo 容易产品难、为什么应用越关键越需要人在回路。

一、这本书真正想解决什么问题

表面上，这本书讲的是如何基于基础模型构建 AI 应用。

但它真正想解决的问题是：在模型能力快速变化的时代，工程师如何建立一套不被工具淘汰的 AI 应用开发方法论。

这和我现在很有关。因为我做 JingNote、DueSight、ShotZen，本质上不是在追逐“今天哪个模型最强”，而是在回答几个更现实的问题：

• 这个功能是否真的需要 AI？
• AI 错了，用户能不能接受？
• 这个能力是 demo，还是可以稳定交付？
• 成本、延迟、隐私、评估怎么处理？
• 大公司也能做时，我凭什么还能活下来？

如果只带走一个判断：AI 产品的难点不在 0 到 60，而在 60 到 95。demo 很容易，产品很难。

二、核心概念

1. AI 工程

这是什么

AI 工程不是训练模型，而是利用已有基础模型构建应用。

传统 ML 工程更像“造发动机”，AI 工程更像“用现成发动机造车”。你不一定需要知道每个零件怎么铸造，但你必须知道发动机的边界、油耗、故障模式，以及它和整车系统如何协作。

书中说得很清楚：传统 ML 工程围绕“开发 ML 模型”，AI 工程围绕“利用已有模型”构建应用。

用在什么场景

适合：

• 快速把模型能力接入产品
• 做 AI 写作、语音转文字、图片理解、知识问答、代码生成
• 基于 API 或开源模型做产品验证
• 独立开发者快速构建可用工具

不适合：

• 业务本身没有 AI 必要，只是为了蹭热点
• 没有明确用户问题，只想“加个 AI”
• 对稳定性要求极高，但没有评估和人工兜底
• 成本结构不清楚，调用越多亏越多

怎么用

我应该把 AI 工程看成一套产品系统，而不是一个模型调用。

最小系统应该包括：

• 输入：用户要解决的问题
• 模型：完成某个具体任务
• 上下文：用户数据、文档、历史记录
• 评估：输出是否满足要求
• 反馈：用户是否接受结果
• 成本：每次调用是否可持续
• 监控：上线后是否变差

实践步骤

1. 给每个 AI 功能写一句话定义：它帮用户完成什么动作。
2. 写出失败场景：模型错了会怎样。
3. 为功能设计 10 条测试样本。
4. 记录每次输出质量、耗时、成本。
5. 上线前先判断：这是产品能力，还是只是演示效果。

2. 评估

这是什么

评估是 AI 工程里最容易被低估、但最关键的部分。

传统软件里，函数输出错了，测试能发现。AI 应用里，输出可能“看起来对”，但事实错、格式错、语气错、成本高、延迟长、不可复现。

所以评估不是“模型好不好”，而是“这个模型在我的产品场景里够不够用”。

书中强调，评估用于选择模型、做基准测试、判断是否能部署，并在生产环境中持续发现问题。

用在什么场景

适合：

• 选择 GPT、Claude、Gemini、开源模型
• 比较不同 prompt
• 判断 RAG 输出是否忠实于资料
• 判断 AI 写作助手是否符合风格
• 判断语音转文字后的 AI 校正是否真的改善了质量

不适合：

• 只看公开排行榜
• 只凭几次主观体验判断模型
• 没有业务指标，只评“感觉不错”
• 测试集太少，只覆盖理想输入

怎么用

对我的产品，评估应该从“用户是否得到更好结果”出发，而不是从“模型分数高不高”出发。

比如 JingNote 的 AI 校正，不应该只看文本是否更通顺，还要看：

• 有没有删除原意
• 有没有错误补全
• 有没有把口语整理成可读笔记
• 处理速度是否足够快
• 免费额度下成本是否可控

ShotZen 如果做 AI 图片分类，也不能只看分类准确率，还要看：

• 是否减少用户整理截图的时间
• 是否误删重要截图
• 是否能让用户信任推荐结果

实践步骤

1. 为每个 AI 功能写 3 个核心评估标准：质量、成本、延迟。
2. 建一个 30 条真实样本的小型评估集。
3. 每次改 prompt 或换模型，都跑一遍。
4. 输出结果分为：可用、需人工确认、不可用。
5. 上线后收集用户修改、撤销、跳过行为，作为真实反馈。

3. RAG

这是什么

RAG 是给模型外接记忆。

模型本身像一个读过很多书但不一定记得最新内容的人。RAG 的作用是：先从外部资料库里找到相关内容，再让模型基于这些内容回答。

它解决两个问题：

• 模型知识过时
• 模型容易胡说

书中提到，RAG 最初是为了解决上下文长度限制，后来被广泛用于提升信息利用效率、响应质量并降低成本。RAG 的成败很大程度取决于检索器质量。

用在什么场景

适合：

• 知识库问答
• 读书笔记系统
• 个人资料库助手
• App 内帮助文档问答
• 技术文档查询
• 用户历史内容总结

不适合：

• 问题本身不依赖外部资料
• 数据质量差、没有结构化
• 用户需要强推理而不是查资料
• 检索结果本身不可靠

怎么用

RAG 的重点不是“向量数据库”，而是“能不能找对材料”。

对我更实际的用法：

• JingNote：用户历史语音笔记可以作为长期记忆
• 读书笔记：把 Kindle / 微信读书笔记变成个人知识库
• 技术博客：检索我过去文章，生成统一风格的新内容
• App 客服：基于隐私政策、订阅说明、FAQ 自动回答

实践步骤

1. 先收集 50 条真实问答，而不是先选向量数据库。
2. 把资料按场景拆块：功能说明、错误处理、用户案例、FAQ。
3. 用 BM25 / 简单关键词检索先做 baseline。
4. 再测试 embedding 检索是否真的更好。
5. 每次回答都保留引用来源，避免模型自由发挥。

4. 人在回路

这是什么

人在回路不是保守，而是产品成熟度管理。

AI 不是一开始就应该完全自动化。正确路径应该是：先辅助人，再部分自动化，最后才让 AI 直接面对用户。

书中提到“爬行-行走-奔跑”：早期必须有人参与；中期 AI 可以服务内部员工；成熟后才提高自动化程度，甚至直接服务外部用户。

用在什么场景

适合：

• 输出错误会带来损失
• 用户信任还没建立
• AI 能力不稳定
• 产品刚上线，缺少真实数据
• 需要逐步积累评估样本

不适合：

• 低风险、可撤销的任务
• 用户只是要灵感、草稿、建议
• 人工审核成本高于错误成本

怎么用

对我的 App，最现实的路径是：

• 先让 AI 生成建议
• 用户确认后执行
• 记录用户接受率
• 接受率足够高后，再考虑自动化

比如 ShotZen 不应该一开始就自动删除截图，而是先推荐“可删除截图组”，让用户确认。JingNote 不应该直接重写用户笔记，而是提供“原文 + AI 整理版”，让用户选择。

实践步骤

1. 所有 AI 输出默认可编辑、可撤销。
2. 记录用户是否接受 AI 建议。
3. 接受率低于 80%，继续人工确认。
4. 接受率超过 95%，考虑自动化部分低风险任务。
5. 对高风险动作保留最终确认，比如删除、发送、扣费。

5. 护城河：技术、数据、分发

这是什么

AI 产品越来越容易做，也越来越容易被复制。

如果一个产品只是“调用模型 + 套壳 UI”，它很快会变成大公司的一个功能。书中提到，AI 领域的竞争优势通常来自三类：技术、数据和分发。基础模型时代，大多数公司的核心技术相似，大公司的分发优势更强，因此独立开发者更应该重视数据和垂直场景。

用在什么场景

适合用来判断：

• 这个 App 值不值得做
• 做完后是否容易被复制
• 是否有长期积累
• 是否能形成数据反馈闭环
• 是否有渠道触达用户

不适合：

• 早期过度追求“护城河”
• 还没验证需求，就设计复杂壁垒
• 用技术复杂度冒充竞争力

怎么用

我现在做产品，要避免只做“模型 wrapper”。

更好的方向是：

• 用 AI 提升核心体验，但不把 AI 当唯一卖点
• 通过用户数据和使用习惯持续优化产品
• 用写作、Twitter、Reddit、App Store ASO 建立分发
• 做足够窄的场景，让大公司不愿意优先做

ShotZen 的护城河不应该是“AI 清理截图”，而是：

• 对截图场景理解更深
• 删除决策更可信
• App Store 截图、设计、增长闭环更强
• 用户整理行为数据不断优化推荐

实践步骤

1. 每个 App 写一句“如果苹果明天做了类似功能，我还剩什么”。
2. 找出一个大公司忽略的小场景。
3. 把用户每次选择、跳过、删除行为记录成产品反馈。
4. 建立内容分发渠道，而不是只依赖 App Store 搜索。
5. 每周检查：我是在积累资产，还是只是在堆功能。

三、对我真正有用的 5 个点

1. 不要迷信模型，先建立评估系统

Insight

模型更新很快，但我的产品不能靠“感觉这个模型更聪明”来迭代。没有评估集，每次换 prompt、换模型、换供应商，都是主观赌博。

我的理解

我以前容易把 AI 能力当成一个黑盒：试几次效果不错，就觉得可以上线。但真正的产品不是一次输出好，而是一百次、一千次都稳定在可接受范围内。

如何用在我身上

开发工作：

• 给 JingNote 的 AI 校正建立固定测试集
• 给 ShotZen 的图片分类建立真实截图样本集
• 每次修改 prompt 都跑一遍小评估

副业：

• App 的 AI 功能不能只写“powered by AI”
• 要能证明：用了 AI 后，用户更快、更省心、更愿意付费

生活：

• 以后判断一个工具，不只问“强不强”，还要问“它在我的场景里稳定吗”

2. Demo 容易，产品难

Insight

AI 最迷人的地方是 demo 效果惊艳。最危险的地方也是 demo 效果惊艳。

书里提到，很多团队一个月做到 80%，但从 80% 到 95% 又花了几个月。真正消耗时间的，是边角问题、幻觉、延迟、成本、异常输入。

我的理解

这句话对独立开发者尤其重要。因为我最容易被一个漂亮 demo 推着走，以为“这个方向能做”。但用户不会为 demo 付费，用户为稳定解决问题付费。

如何用在我身上

开发工作：

• 新功能先做 happy path，但不能停在那里
• 至少测试异常输入、空数据、长文本、网络失败、模型失败
• 做 App 时，发布前要问：这个功能在真实用户乱用时还能不能工作
• 不要把“我本地跑通了”当成“可以赚钱了”

生活：

• 降低对短期兴奋感的信任
• 每个想法先问：维护成本是什么

3. AI 功能越核心，容错率越低

Insight

如果 AI 只是辅助，用户可以容忍小错误。如果 AI 是核心功能，用户就会要求更高的准确性和可靠性。书里用 Face ID 这类例子说明：AI 越关键，用户对错误越敏感。

我的理解

这对产品设计很重要。不是所有 AI 功能都应该放在核心路径里。早期产品更适合把 AI 放在“增强体验”的位置，而不是让整个产品成败都依赖模型一次输出。

如何用在我身上

开发工作：

• JingNote 的核心价值是快速记录，AI 校正是增强
• DueSight 不一定要强行加 AI，除非能明显减少用户操作
• ShotZen 的核心价值是整理截图，AI 推荐是辅助

副业：

• 营销文案可以说 AI，但产品结构不能完全押注 AI
• 先做用户可控的 AI，再做自动化 AI

生活：

• 做决策时，把不可控因素放在辅助位，不要放在主路径

4. 数据比 prompt 更接近长期资产

Insight

Prompt 可以复制，UI 可以复制，模型 API 也可以复制。真正可能沉淀下来的，是用户数据、反馈数据、场景数据和分发渠道。

我的理解

我做独立 App，不能只追求“这个 prompt 写得很强”。更重要的是产品每运行一天，是否能积累一点别人没有的东西。

如何用在我身上

开发工作：

• 记录用户修改 AI 输出的地方
• 记录用户接受 / 拒绝 AI 建议的行为
• 形成小型偏好数据集

副业：

• 写作也是数据资产
• 推文、博客、用户反馈、App Store 评论，都应该进入产品迭代系统

生活：

• 任何长期系统，都要留下可复盘的数据
• 没有记录，就没有复利

5. 提示工程有用，但只会提示工程不够

Insight

提示工程是最容易开始的模型适配方式，不需要改变模型权重。但书里也提醒：问题不是提示工程没用，而是只懂提示工程不够。生产级 AI 应用还需要评估、统计、工程、数据集管理和实验追踪。

我的理解

这句话对现在的 AI 热潮很有价值。很多人把 prompt 当成全部，但真正能做出产品的人，会把 prompt 放进工程系统里管理。

如何用在我身上

开发工作：

• prompt 要版本化
• prompt 改动要有评估记录
• 不同模型要有对照实验

副业：

• 可以把自己的 prompt 系统变成内容资产
• 但不能把产品只建立在 prompt 上

生活：

• 不要停在“会用工具”
• 要把工具变成流程，把流程变成系统

四、经验、反直觉点和被忽略的细节

1. 最先进的模型，不一定最适合我的产品

模型选择不是排行榜第一就完事。真实产品还要看成本、延迟、隐私、功能、控制权、设备端部署。书中提到，模型选择需要先剔除硬属性不符合需求的模型，再基于公开信息缩小范围，最后用自己的评估流水线测试。

对我来说，JingNote 如果强调隐私和低成本，可能本地模型、小模型、混合架构比最强 API 更适合。

2. AI 幻觉不是 bug，而是生成机制的一部分

语言模型本质上是概率生成。只要某些错误输出概率不为零，它就可能出现。更麻烦的是，模型一旦做出错误假设，后面可能继续编造内容来圆这个错误。

这意味着我不能只靠“让模型认真一点”解决幻觉。产品上必须做引用、检索、约束输出、人工确认、失败兜底。

3. 公开基准测试只能参考，不能迷信

数据污染会让模型在基准测试上表现很好，但实际能力不一定强。一个模型考试高分，可能只是训练时见过类似题。

这对我选择模型很有提醒：不要直接把榜单成绩当成产品决策依据。我的 App 场景才是最终测试集。

4. 成本和延迟不是后期优化，而是产品设计的一部分

TTFT、TPOT、总延迟这些指标看起来偏工程，但其实直接影响用户体验。用户打开 App 等 5 秒，可能就走了。

AI 产品从第一天就要考虑：

• 哪些请求可以缓存
• 哪些任务可以异步
• 哪些场景必须快
• 哪些输出可以降级
• 哪些模型可以用小模型替代

5. “AI 自动化”不是越自动越好

独立开发者容易想象一个全自动系统，但用户真正需要的是可信、可控、可撤销。

早期产品更应该做：

• AI 建议
• 人类确认
• 记录反馈
• 再逐步自动化

完全自动化应该是结果，不应该是起点。

五、一句话总结

这本书真正改变我的地方是：以后做 AI 产品，我不能只问“模型能不能做到”，而要问“这个能力能不能被评估、被控制、被交付、被用户长期信任”。

2026.05.05 10:39
沪·赵巷

📌 声明：本文由 AI 辅助完成