不少讲 Claude API 提示词的文章，都会整理一大堆“通用 Prompt”。但真到了知识库问答这个场景里，核心问题往往不是“怎么让模型回答得更漂亮”，而是另一件更实际的事：怎样让 Claude 只依据知识库回答，证据不够时不乱猜，回答能追溯来源，而且碰到多份文档说法不一致时也能处理得清楚。

所以，这篇文章不做 Claude 提示词合集，而是围绕“Claude API + 知识库问答”这条真实业务链路，整理一套可以直接复用的提示词模板，包括输出格式、无答案时怎么处理、文档冲突怎么判断，以及 API 调用时如何拼装内容。

说明：这里提到的 Claude API，指的是通过 API 方式调用 Claude 模型能力。如果你使用的是 ClaudeAPI 这类第三方 Claude API 兼容接入服务，需要注意它们并不是 Anthropic 官方服务。具体能力、价格、额度、线路、发票、技术支持等信息，都应以对应平台的最新说明为准。

---

一、Claude API 做知识库问答，难点不只是“回答问题”

知识库问答表面上看并不复杂：用户提一个问题，系统检索相关文档，然后 Claude 根据文档生成回答。但在实际业务里，如果提示词写得太宽泛，很容易出现一些麻烦。

1. 模型会补全知识库里没有的信息

如果提示词只是简单写一句“请根据以下资料回答问题”，Claude 很可能会结合常识或上下文进行补充说明。对开放式问答来说，这有时不算坏事；但放到企业制度、产品手册、技术文档这类知识库里，风险就很明显了。

比如用户问：“这个功能是否支持批量导出？”知识库里只写了“支持单条导出”。如果没有提前限制回答边界，模型可能会推断出“可能支持批量导出”。这类看似合理的补充，其实就是知识库问答里最常见的幻觉。

2. 引用来源容易不稳定

很多知识库系统都希望答案后面能带上“来源文档”“段落编号”或者“原文链接”。但如果提示词没有把引用格式说清楚，模型可能只会写一句“根据文档说明”。这种回答对用户来说可信度不够，产品侧也很难做溯源展示。

换句话说，引用不是装饰，而是知识库问答能不能被信任的关键部分。

3. 多份文档之间可能互相打架

企业知识库里经常会有版本冲突：旧制度还没下线，新制度已经上传；产品文档和客服 FAQ 口径不一致；不同版本的技术文档对 API 参数描述也可能不一样。

一个好用的 Claude API 知识库问答提示词，不能只告诉模型“请回答”，还得告诉它：遇到冲突时先看什么、怎么排序、什么时候不能自行判断。否则模型很可能会挑一个看起来顺手的答案直接输出。

---

二、最小可用的 Claude API 知识库问答提示词模板

如果你只是想先快速上线一个基础版本，可以先用下面这个系统提示词模板。

你是一个知识库问答助手。你的任务是根据用户提供的知识库片段回答问题。

请遵守以下规则：
1. 只能基于【知识库内容】回答，不要编造知识库中没有的信息。
2. 如果知识库内容不足以回答问题，请明确说明“根据当前知识库无法确认”。
3. 如果问题表达不清，或缺少必要条件，请先提出澄清问题。
4. 回答应简洁、准确，避免无依据的推测。
5. 每个关键结论后都要标注引用来源，引用格式为：[来源：文档名/段落ID]。

输出格式：
- 直接结论：
- 依据说明：
- 引用来源：
- 如无法确认，请说明缺失的信息：

这个模板的重点，并不是让 Claude “更会说话”，而是先把边界立住：只能基于知识库回答；材料不够就明确说无法确认；关键结论必须带来源。对于 FAQ、帮助中心、产品说明这类知识库来说，这个版本已经能覆盖不少基础问答场景。

---

三、增强版提示词模板：加入追问、冲突处理与不确定性表达

如果你的知识库内容比较多，里面还涉及制度、技术、售后、产品版本等复杂情况，那就更建议使用增强版模板。

你是一个严谨的知识库问答助手，负责基于检索到的知识库片段回答用户问题。

## 核心目标
根据【知识库内容】给出准确、可追溯、不过度推断的答案。

## 回答边界
1. 只能使用【知识库内容】中的信息回答。
2. 不得把常识、经验、猜测或外部知识当作事实。
3. 如果知识库没有直接证据，请说明“根据当前知识库无法确认”，不要强行回答。
4. 如果可以给出部分答案，请明确区分“已确认信息”和“无法确认信息”。
5. 如果用户问题缺少关键条件，例如版本、地区、角色、时间范围、产品型号，请先追问。

## 检索片段使用规则
1. 只引用与问题直接相关的片段。
2. 不要把相邻但无关的内容拼接成结论。
3. 不要从一个片段过度推导另一个片段没有说明的内容。
4. 如果多个片段表达一致，可以合并回答，并列出多个来源。
5. 如果多个片段冲突，请不要自行裁决为唯一答案，应按冲突处理规则输出。

## 多文档冲突处理规则
当知识库内容存在冲突时：
1. 优先采用更新时间较新的文档。
2. 在更新时间相同或无法判断时，优先采用权威层级更高的文档，例如正式制度、官方产品手册、管理员公告。
3. 如果仍无法判断，请列出冲突点，并提示用户确认适用版本或业务场景。
4. 不要隐藏冲突，也不要只选择对回答最方便的来源。

## 输出格式
请严格按照以下格式输出：

### 直接结论
用 1-3 句话回答用户问题。

### 依据说明
说明结论来自哪些知识库片段，必要时解释适用条件。

### 引用来源
以列表形式列出来源，格式为：
- [文档名｜段落ID｜更新时间]

### 不确定性或需补充信息
如果存在无法确认、条件不足或文档冲突，请在这里说明。

这个版本更适合生产环境。它不只是规定“应该怎么回答”，还把“什么时候不能回答”“什么时候要追问”“文档冲突怎么处理”都写进去了。知识库问答要稳定，很多时候靠的正是这些失败场景下的约束。

---

四、不同知识库类型的提示词模板变体

不同类型的知识库，风险点并不一样，所以提示词也不应该完全照搬一套。

1. FAQ 知识库：优先短答，避免过度展开

FAQ 场景通常追求快速解答，用户更想要直接答案，而不是一大段解释。可以在系统提示词里加上：

如果问题可以由 FAQ 直接回答，请优先给出简短结论。
不要扩展 FAQ 中没有覆盖的政策、条件或例外情况。
如果 FAQ 只回答了部分问题，请说明未覆盖部分。

这类写法比较适合客服机器人、帮助中心、售前咨询等场景。

2. 产品手册知识库：强调版本与适用范围

产品功能经常会随着版本、平台、套餐或权限变化。如果不提醒模型检查这些条件，它很容易默认“所有用户都适用”。建议加入：

回答产品功能问题时，必须检查知识库中是否包含版本、平台、套餐、权限或配置前提。
如果缺少这些条件，请不要默认适用全部用户，应提示用户补充版本或使用环境。

这个变体更适合 SaaS 产品文档、硬件说明书、App 帮助文档等场景。

3. 内部制度知识库：严禁推测，必须标注依据

制度类问答对准确性要求更高，比如报销、考勤、审批、权限这些问题，一旦答错就可能带来实际影响。所以提示词要更严格：

回答制度、流程、报销、考勤、权限、审批类问题时，必须严格基于正式制度文件。
不得根据常见公司规则或一般经验补充。
如果存在旧版和新版制度，以知识库中标注的生效时间为优先判断依据。

这类模板适合 HR、财务、法务、行政制度问答。

4. 技术文档知识库：区分事实、示例与建议

技术文档里经常同时出现参数说明、示例代码和最佳实践。它们都很有用，但性质并不一样。最好让模型在回答时区分清楚：

回答技术问题时，请区分：
1. 文档明确规定的事实；
2. 文档提供的示例；
3. 基于文档可得出的操作建议。

如果涉及 API 参数、错误码、版本兼容性，必须引用对应文档片段。

这类提示词适合开发者文档、SDK 文档、API 文档问答。

---

五、Claude API 调用时如何拼装 system、messages 与知识片段

在 Claude API 知识库问答里，比较推荐的做法是：把长期有效的规则放进 system，把用户问题和检索出来的知识片段放进 messages。下面是一个简化示例，实际字段可以根据你使用的 SDK 或兼容平台做调整。

{
  "model": "claude-xxx",
  "system": "你是一个严谨的知识库问答助手。只能基于知识库内容回答；证据不足时说明无法确认；关键结论必须引用来源。输出格式包括：直接结论、依据说明、引用来源、不确定性或需补充信息。",
  "messages": [
    {
      "role": "user",
      "content": "用户问题：当前套餐是否支持批量导出？\n\n【知识库内容】\n片段1：文档名：产品功能说明；段落ID：P-12；更新时间：2024-05-10；内容：基础套餐支持单条数据导出，专业套餐支持批量导出。\n片段2：文档名：套餐权限表；段落ID：T-08；更新时间：2024-06-01；内容：批量导出功能仅对专业套餐和企业套餐开放。"
    }
  ],
  "temperature": 0.1,
  "max_tokens": 800
}

比较理想的输出可以是：

### 直接结论
如果用户使用的是基础套餐，则不支持批量导出；专业套餐和企业套餐支持批量导出。

### 依据说明
产品功能说明中提到基础套餐仅支持单条数据导出，专业套餐支持批量导出。套餐权限表进一步说明，批量导出仅对专业套餐和企业套餐开放。

### 引用来源
- [产品功能说明｜P-12｜2024-05-10]
- [套餐权限表｜T-08｜2024-06-01]

### 不确定性或需补充信息
如果需要判断某个具体账号是否可用，还需要确认该账号当前所属套餐。

这里有个关键点：不要把整套知识库原文一股脑塞给模型。更合理的做法是，先让检索系统筛出和问题最相关的片段，再交给 Claude 生成答案。提示词负责规定“怎么使用证据”，检索系统负责“把材料找准”。

---

六、参数与提示词如何联动优化

参数不需要设置得很复杂。对知识库问答来说，真正重要的是稳定、准确、可追溯，所以参数通常要偏保守一些。

1. temperature 建议偏低

知识库问答建议使用较低的 temperature，比如 0 到 0.3。这样可以减少模型自由发挥，让回答更稳定。

如果是创意写作，温度高一点没问题；但制度、技术、客服问答这类场景，随机性太高显然不合适。

2. max_tokens 要覆盖结构化输出

如果你要求模型输出“直接结论、依据说明、引用来源、不确定性”，那就要给够输出空间。max_tokens 太小，很可能导致答案被截断，或者引用来源还没输出完就结束了。

3. 复杂问题可以拆成两步

用户问题比较复杂时，可以先让模型判断材料是否足够，再让它生成正式答案。这样做虽然多了一步，但能明显降低证据不足时强行回答的概率。

第一步，先判断知识库是否足够回答：

请先判断知识库内容是否足以回答用户问题，只输出：
- 是否足够：是/否/部分足够
- 缺失信息：
- 相关来源：

第二步，再根据判断结果生成最终答案。尤其是制度、权限、版本兼容这类问题，这种拆分会更稳妥。

---

七、常见错误与反例

错误 1：提示词写得太开放

反例：

请根据以下资料回答用户问题，尽量详细。

问题就在“尽量详细”这几个字。它会鼓励模型扩写，知识库没有提到的信息，也可能被模型用常识补上。

更好的写法是：

请只基于知识库内容回答。知识库没有明确说明的信息，不要推测，并说明无法确认。

错误 2：没有规定引用格式

如果只写“请注明来源”，模型输出往往不稳定。有时写文档名，有时写“根据资料”，有时干脆漏掉。最好直接把格式规定清楚，比如：

每个关键结论后必须使用 [来源：文档名/段落ID] 标注依据。

错误 3：忽略多版本冲突

反例：

如果多个文档都相关，请综合回答。

“综合回答”听起来没问题，但在多版本文档里很容易出事。模型可能会把旧文档和新文档混在一起，最后生成一个看似完整、其实口径混乱的答案。

更稳的做法是，让模型先按更新时间、权威层级排序；如果仍然判断不了，就把冲突点列出来，让用户确认适用版本或业务场景。

错误 4：检索片段堆得太多

有些系统会把大量相似片段全部传给 Claude，觉得材料越多越安全。但实际效果未必好，片段太多反而会让模型抓不住重点。

更好的方式是只传入高相关片段，并且在每个片段里保留文档名、段落 ID、更新时间、权威级别等元数据。这样模型不仅知道内容是什么，也知道这些内容该如何被引用和比较。

---

八、一页总结：推荐直接使用的知识库问答模板

如果只保留一个 Claude API 知识库问答提示词模板，可以直接用下面这个版本：

你是一个严谨的知识库问答助手。请根据用户提供的【知识库内容】回答问题。

规则：
1. 只能基于知识库内容回答，不得编造、猜测或使用外部知识补充事实。
2. 如果知识库内容不足，请说明“根据当前知识库无法确认”。
3. 如果用户问题缺少关键条件，请先追问，例如版本、时间、地区、权限、产品型号等。
4. 每个关键结论都必须有引用来源。
5. 如果多个文档冲突，优先使用更新时间较新、权威级别较高的文档；仍无法判断时，列出冲突并提示用户确认。
6. 不要把无关片段拼接成结论，不要把推断当事实。

输出格式：
### 直接结论
### 依据说明
### 引用来源
- [文档名｜段落ID｜更新时间]
### 不确定性或需补充信息

Claude API 用来做知识库问答时，提示词的价值不只是让答案看起来更专业。更重要的是，它要建立一套清晰可执行的回答规则：有证据就回答，有冲突就说清楚，有缺口就追问，无法确认就明确拒绝编造。

这比单纯收集一堆提示词模板更有价值，也更适合真正落地到企业知识库、产品文档和技术问答系统中。