刚上手做 AI 应用，常见卡点是同一个问题不知道该改提示词还是该上检索：改了几版提示词答案还是不准，就怀疑是不是得上 RAG；反过来搭了一套知识库，发现问个格式问题它也在检索。这篇不给结论式的站队，而是给一套判断顺序：先看信息从哪来、再看成本与维护量，最后讲两条路怎么叠着用。
刚上手做 AI 应用，最常见的卡点是同一个问题不知道该改提示词还是该上检索。改了几版提示词答案还是不准，就怀疑是不是得上 RAG；反过来搭了一套知识库，发现问个格式问题它也在检索，白跑一圈还慢。这篇不给站队式的结论，只给一套判断顺序：先看信息从哪来，再看成本与维护量，最后讲两条路怎么叠着用。
判断顺序搞反了，后面全是返工。先把「缺的是指令还是资料」这一层分清楚，再决定动哪一边，能省掉很多来回试错。
先分清缺的是「指令」还是「资料」
提示词工程解决的是「怎么说」：任务描述、输出格式、示例、边界约束，知识本来就在模型里。RAG 解决的是「它不知道」：把企业私有文档、最新资料、内部规范喂进上下文再回答。两者改的不是同一个东西，所以症状也不一样。
| 症状 | 大概率缺什么 | 先动哪边 |
|---|---|---|
| 答得出来但格式乱、语气不对 | 指令 | 提示词 |
| 内容编造、引用不到内部资料 | 资料 | 检索 |
| 换了说法还是错，贴原文就对了 | 资料供给 | 检索 |
| 贴了原文仍然答不好 | 指令或模型 | 提示词 |
自测方法很简单：把资料原文直接手工贴进对话里。如果答对了，说明缺的是资料供给，方向在检索；如果贴了资料还是答不好，问题在指令设计或模型选择。这个动作十分钟就能做完，比先搭一套向量库划算得多。
- 误判的典型征兆：一上来就搭向量库，结果问「帮我把这段话改正式一点」也走一遍检索，白花时间和调用成本
- 任务本身就是开放生成（写文案、起名字），没有「正确答案出处」可检，这类不用碰 RAG
- 只有几页 FAQ 且几个月不变，直接写进提示词或做成结构化配置更省事
- 需要精确引用某份文件原文、或知识每天都在变，纯提示词追不上变化速度
走提示词这条路：先把手上的版本管起来
固定结构比堆词有效：角色与目标、输入变量、输出格式、禁止事项分开写，别揉成一大段散文。结构写清楚之后，你才知道是哪一块改了导致效果变化，而不是凭感觉整体重写。
- 拆出变量把每次会变的部分（用户输入、可选参数）单独拎出来，固定部分才叫提示词模板
- 写清输出契约规定字段名、类型、缺省行为，让下游代码能直接解析，而不是靠字符串截取
- 留小用例集十几二十条典型问题就够，覆盖正常、边界、异常三类，每次改动跑一遍
- 记录版本每次改动写一行说明改了什么、为什么改，回归时才知道哪一版退化的
结构化输出的具体写法可以到 /guides/prompt-structured 里对着做，别自己从零想模板。用例集和回归思路则在 /guides/prompt-version-regression-testing 里有完整说明。
走检索这条路：判断标准是资料量和更新频率
什么时候值得上 RAG：资料量已经大到塞不进上下文、内容会持续更新、需要给出处、多人共用同一份知识源。这几条满足得越多，检索的收益越明显；只满足一条，通常还有更轻的做法。
- 文档清洗
- 去掉页眉页脚、乱码、目录页，脏数据进库会一直污染召回
- 切片粒度
- 按语义段落切，别机械按字数割断一句话，粒度决定召回质量上限
- 元数据
- 来源、时间、权限三样带上，方便过滤和追溯，也方便做权限隔离
上检索之前先做进料，这三件事决定上限，比换模型更影响效果。链路怎么拆、每层做什么，可以对照 /guides/rag-retrieval 和 /guides/rag-architecture-layers 看。
| 维护动作 | 触发条件 | 谁来做 |
|---|---|---|
| 重建索引 | 文档更新 | 数据或工程侧 |
| 重跑切片 | 切片策略调整 | 工程侧 |
| 更新元数据 | 权限或来源变更 | 数据侧 |
| 回归评测 | 以上任一变动 | 应用侧 |
维护成本要提前认：文档更新了索引要重建，切片策略改了要重跑，这部分人力往往比第一次搭起来更贵。一家 5 人小团队如果没有专人管知识源，上了检索之后很可能变成没人维护的半成品。
两者叠加：检索负责给料，提示词负责用好料
RAG 的最后一公里仍然是提示词：召回内容怎么拼进上下文、怎么要求「只依据给定资料回答、资料里没有就说不知道」，这部分不写清楚，检索再准也答偏。很多人把召回做好了却忽略了拼装，最后怪检索不行。
- 纯提示词跑一版先确认指令和格式没问题，这是基线
- 手工贴资料验证把真实资料贴进去，看能否答对，判断缺口在哪
- 效果差才拆出检索资料量或更新频率确实撑不住手工贴，再建索引
- 回头打磨拼装提示词检索上线后，优化资料拼接方式和引用约束
成本视角要诚实：检索会增加调用与存储开销，别默认它一定更划算。具体单价口径到 /official-api 和 /tools/model-cost-calculator 按当时的数字核一遍，别拍脑袋估算。中转站之间的报价差异也可以到 /price-watch 看跟踪记录。
能力边界会互相迁移：换模型、改切片、改提示词任意一项变动，都要重跑同一套小用例，否则排查时分不清是哪一步退化的。把评测当成固定动作，比每次出问题再救火省力得多。
先问一句：这个答案需要一份模型没见过的资料吗？需要才谈检索，不需要就回去改提示词。下一步拿你手上效果最差的一个问题跑一遍上面的判断顺序，多半能省掉一次不必要的向量库搭建。想看已收录的中转站和工具怎么选，去 /sites 和 /tools 按当时的收录情况挑。→
常见问题
只想快速验证一个想法，先做哪个更省事？
先纯提示词。写一版指令，把相关原文手工贴进去试十几条典型问题，一两个小时能看出方向。如果贴了原文还答不对，说明不是资料问题，再往上加检索也只是放大原来的毛病。等纯提示词这条路明显卡在资料量或更新频率上，再动检索。
是不是上了 RAG 就不用管提示词了？
不是，反而更依赖。检索只负责把可能相关的片段捞出来，怎么裁、怎么排序、怎么在指令里要求「只依据给定资料回答」都是提示词的事。很多「RAG 答不准」的案例，追下去是召回内容被塞得太乱或没约束模型不许自由发挥，而不是检索本身没找到。
资料很少，还需要搭知识库吗？
看更新频率和是否要给出处。只有固定几十条问答、长期不变，写成结构化配置或直接进提示词更省事，也更好排查；一旦内容每周都在变、需要标明来源、或者要按权限区分谁能看到哪部分，检索这条路的维护成本才开始变得划算。
