在微信读书里刷到了《做对判断：AI产品从0到1》这本书，从内容里可以看出作者是一位亲手做过AI产品的人。自从ChatGPT横空出世，我就一直断断续续追着大模型的进展跑。最近这三个月，我用 Claude Code 写一个物探领域的 RAG 项目，做得热火朝天，也踩了好多坑，看到这本书里也写到了RAG，就仔细翻着读完了。
AI产品与传统软件的最大不同
AI产品与传统软件最大的差别是不确定性：技术选型、PRD、评测、运营、留存，每一样都要在不确定的前提下做判断。
因为结果不可重现，作者认为传统PRD不够用了，一份AI产品的PRD要多回答几个问题：
- 模型用哪个？
- Prompt怎么写？
- 评测怎么跑？
- 效果不好怎么迭代？
- 什么情况下走兜底？
全书的主要内容基本都是从“结果不可重现”这一条展开的。
几个概念：MCP、RAG、Agent、Skill
书里给这几个概念打了一套比方：
- MCP是AI的手脚——连接的通道，解决怎么连接和调用外部世界；
- RAG是AI的参考资料——让AI有领域知识；
- Agent是AI的自主执行能力——拆解复杂任务并逐步完成。
- skill 则是做事的方法。
MCP的概念，我以前也大概知道一点点，可以看我之前的 MCP与A2A笔记，Agent工程上有三大范式：ReAct（边想边做）、Plan-and-Execute（先想后做）、Reflexion（执行+反思）。现在直接使用别人做好的智能体框架，知不知道这些范式好像也没多大用。
RAG 的入门我曾写过一篇非常简单的文章：《基于LangChain搭建一个PDF问答程序》，当时还不知道claude code，查看各种资料手搓而成。
让我印象最深的几个观点
1. 结果不可重现是一切的根源
AI产品不一样：
平常软件的结果是确定性的，但AI产品有一个最大的不同，每次的结果都不一样。 你优化了prompt，有些数据可能好了，有些又变差了。
作者提醒软件开发人员：Prompt要版本化管理，改错了能回退；任何变更要跑评测，因为“你觉得是优化”不一定真是优化；要设计兜底策略，因为AI一定会犯错。
2. RAG：看起来容易，做起来全是坑
全书有一章写RAG，也是我比较感兴趣的部分。
作者先讲了自己的经历：做一个法务智能助手，它能生成“看起来正确、实际上错误”的回答。
这种回答实际上比“明显胡说八道”危险百倍。
明显胡说，用户一眼看穿，最多浪费一次提问；看起来正确，用户会当真，然后照着一个错的东西去做决定。法律、医疗这类领域，后果很严重，让用户失去信任，产品也就完蛋了。
之后作者给了RAG失败的八条真相：
| 失败原因 | 书中给出的对应做法 |
|---|---|
| 数据源本身就是垃圾 | 没人审过的文档不入库 |
| 分块策略拍脑袋 | 不同类型文档用不同切分规则 |
| 只靠一层向量检索 | 多路召回 |
| 召回结果不稳定 | query改写，top-k放大 |
| 回答时胡编 | 强制基于参考资料回答，引用校验 |
| 没有评估体系，全凭感觉 | 改了参数就要跑评估 |
| 目标定得太大 | RAG适合有边界、有文档、有标准答案的场景 |
| 上线后不运营 | 不断维护，尤其要重视bad case |
细心的人可能会发现：这八条里，没有一条提到“模型不够强”或“算法不够先进”。
作者还单独提到了权限控制：让AI自己控制不输出敏感内容，是不可靠的。正确做法是三步——身份识别、带权限的检索（这一步就把用户看不到的东西过滤掉了）、生成前兜底校验。而且权限方案第一版就要设计好，不能上线后补。
失败的RAG项目长什么样，是想做一个万能的产品：把公司所有文档接进来，让员工什么都能问——结果是什么也答不好。
书里还给了一份九条“上线前检查清单”：
- 知识源是否经过审核
- 默认检索是最新有效版本
- 标注权威性，制度 > 通知 > 会议纪要 > 个人笔记
- chunk是否语义完整
- 要有标注的测试集
- 关键结论必须可追溯，注明引用来源
- 检索前进行权限过滤
- bad case要回流分析
- 明确谁来负责知识更新
最后还有个工厂场景：知识库不是文档而是结构化数据，这就是混合RAG——查询类的转成SQL去数据库查，非结构化的走传统RAG，两路融合生成答案。难点在路由判断，作者团队用同义词映射表做query改写来解决。
3. 简单方案先行，复杂方案兜底
关于技术选型，作者有个反直觉的观察：
技术选型中最常见的错误，不是“选错了”，而是“选多了”。
大家都喜欢高大上：RAG要上最复杂的多路召回加重排序，Agent要做最灵活的多步推理，大模型挑最新的。但是，复杂度上去了，却未必好用、未必值得维护。
作者给的原则是“简单方案先行，复杂方案兜底”：先用便宜的方法解决大部分问题，剩下的交给贵的方法。例子是“关键词预匹配（命中率40%）+ LLM分类器兜底”。
在“RAG还是Agent”这个问题上，书里给了几个判断维度：任务确定还是开放？需不需要连接外部系统？知识来源是什么？需要频繁更新的技术文档用RAG；任务复杂、多步、需要动态决策才上Agent。
还有一个清醒剂：大模型不是万能的。一次调用至少3-5秒，还会超时，烧的都是钱。高频实时的结构化任务（预警、阈值判断）交给规则引擎或轻量模型；低频复杂的生成任务（分析报告、根因推理）才用大模型。有些场景，7B-14B的小模型就够了。
4. 评测是AI产品的生命线
评测这部分，我在做SeisQuery的时候感受最强烈。
任何prompt或模型变更，无论看起来多“显然是优化”，不跑评测不上线。
因为“你感觉应该不错，可能对某几题有改善，但可能会让很多题效果下降”。
评测体系分三层：检索层看命中率和排序质量；生成层把正确的片段喂给LLM看回答的准确率、完整性、格式；用户体验层收集真实反馈。
迭代节奏分三个频率：
- 高频——任何变更提交前自动跑核心评测集；
- 中频——每周跑一次全量评测；-
- 低频——每月请业务专家人工评测、分析bad case趋势。
作者会做对照实验的三组设计：传统流程baseline（没有AI怎么做）、简化版AI、完整版AI。这三组能回答两个关键问题：AI比传统方案好多少？工程化值不值？作者说这个对比数据在向客户汇报时极有说服力。
5. Prompt是核心交付物
AI产品里，Prompt也代码，甚至比代码更核心。要版本化管理、变更要跑评测、生产环境和测试环境的prompt分开管理。
看到这里，我在 SeisQuery 项目里也进行了实践：把 Prompt文本 单独抽出来，放到 git 仓库管理，每次改动加个版本号，写清楚“为什么改”。
还有一点容易忽略：Prompt 调试时同时改多个地方，效果反而变差。我在项目里试过一次性改 4、5 处 Prompt，测试结果准确率反而掉了几个点——不同地方之间会相互影响。养成“一次只改一处，改完就跑评测”的习惯后，调试效率反而高了。
6. PRD 写法：AI PRD 八步法
作者提出了一套“AI PRD八步法”落地工具，我先完整记下来：
- 价值判断——用户的痛点是什么？为什么必须用AI？能力边界在哪？
- 目标拆解——业务目标 + 可衡量的模型目标
- 需求与流程设计——明确哪一步是用户操作、哪一步是AI执行
- 模型选型——用什么模型，为什么
- Prompt工程——版本管理，记录改动原因和效果
- 评测系统——测试集、指标、达标标准
- 兜底策略——低置信度怎么办？主模型失败切备用吗？
- 产品能力设计——V1对话式，V2再加表单；等待过程如何设计？
7. 增长与留存：狼来了的故事
作者给了一组扎心的自家数据：注册账户400人，真正持续使用的不到30人。翻后台日志发现大部分人用一次就走了。流失原因就三类：文件解析失败、回答太泛泛、超时太久。结论是第一次如果体验不成功，几乎没有第二次机会。
关于留存有两个提神的判断：AI产品的逻辑是让用户用完即走；看一个AI产品好不好，只看它替用户创造了多少不可替代的价值——用户留下来的唯一原因是，离开你他得花更多时间做同样的事。
还有一个预警的例子：作者把AI预警阈值调低后，每天推40-50条预警，用户直接关掉了通知——典型的“狼来了”效应；控制在3-5条，用户反而会响应。
后来我顺手查了下，再扯远一些，这个效应在别的领域有更大的数据佐证：网络安全分析师每天面对3000多条告警只能处理约38%，其中仅16%是真实攻击；医疗领域超过85%的临床告警被医生直接忽略，甚至引发过致命错误。可见这不是AI时代的新问题，是所有监控系统的老毛病。
我做RAG时踩的坑
读到RAG那一章时心情比较复杂。SeisQuery是我用Claude Code做的物探RAG问答系统，写了三个月。下面挑几条印象最深的说说体会，技术细节不方便展开。
数据源良莠不齐
书里说“没人审过的文档不入库”，听起来理所当然，但现实里你拿到的docx就是打不开。Word的空错性很强，python-docx不一定能打开。文件里的目录不规范、样式乱用，什么情况都会发生。
query改写是把双刃剑
刚看完query rewrite的论文，我就动手试，结果反应变慢了不说，整体效果反而变差（有个别题效果有所改善）。我只能先把这个选项关掉，以后再优化。
没有评估体系就别上线
我准备了三套数据，20题、30题、32题，一共82题。评估非常花时间，评估20题要20分钟，82题就要1个多小时，这还是LLM稳定的情况下。有个反应又快又准的本地LLM，会让RAG开发效率提升很多。