客户最常问的三句是：「能不能做成 AI？」「准不准？」「多少钱？」。这篇按真实交付经验给边界。

一、RAG 知识库

• 适合：资料多且相对稳定（产品手册、内部制度、SOP），用户问题分散但都能在资料里找到答案
• 不适合：资料本身没有答案（需要推理和经验）；资料极度时效（每天变，数据源要接 API 而不是文档）

我做的：文档切分 → 向量入库 → 检索 → 让模型基于检索结果作答，并给出出处。

必须做的一件事：给答案标出处。不能溯源的 RAG 在内部场景是危险的——用户分不清「模型说的」和「制度写的」。

验收指标：先准备 30-50 条真实问题作为测试集（我出初稿，你筛掉不像真会问的），跑一遍看命中率；命中率按「答案正确」判定，不是只检索到了文档。通过线在开工前商定、写进验收单——这个测试集就是你的验收标准，谁出题、怎么算对，都提前写死。

二、智能体（Agent）

• 适合：多步、规则明确、需要调用外部系统（查订单、填表单、发通知）
• 不适合：任务边界模糊、错了代价很大（转账、删数据）却要求全自动

我的做法：把「必须可靠」的部分做成确定性流程（工具调用、参数校验、落库），把「需要理解」的部分交给模型；不确定就转人工，不硬撑。

交付时我一定给你：完整的工具调用日志和失败回退路径，你能看清每一步为什么这么做。

三、工作流自动化

• 适合：跨系统搬运数据、表单、提醒、对账这类「不需要智能，只需要可靠」的事
• 不适合：流程本身没定，或者每一步都要人判断

我的建议：先用工作流把流程跑顺，再决定哪一步值得换成 AI。顺序反了会返工。

四、常见坑（都是我自己踩过的）

1. 数据没准备好就开始做——清洗和对齐占的时间常常超过开发。开工前先给我 3 份真实样例数据。
2. 把「能演示」当「能用」——演示是挑好的路径，验收要拿随机数据和极端情况。
3. 模型换版本就崩——提示词、检索参数、工具描述都要版本化，这部分我会一起交付。
4. 成本没算——我会提前给你一版大致的调用量/费用估算，避免上线后账单超预期。

相关阅读

• 博客：RAG 知识库实战：检索不准，问题多半不在大模型——检索质量的坑在哪、怎么排查。
• 博客：RAG 接进业务系统，权限和评测绕不过去——上线前评测与权限这两道关。