不少讲 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文档名产品功能说明段落IDP-12更新时间2024-05-10内容基础套餐支持单条数据导出专业套餐支持批量导出。\n片段2文档名套餐权限表段落IDT-08更新时间2024-06-01内容批量导出功能仅对专业套餐和企业套餐开放。}],temperature:0.1,max_tokens:800}比较理想的输出可以是### 直接结论 如果用户使用的是基础套餐则不支持批量导出专业套餐和企业套餐支持批量导出。 ### 依据说明 产品功能说明中提到基础套餐仅支持单条数据导出专业套餐支持批量导出。套餐权限表进一步说明批量导出仅对专业套餐和企业套餐开放。 ### 引用来源 - [产品功能说明P-122024-05-10] - [套餐权限表T-082024-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 用来做知识库问答时提示词的价值不只是让答案看起来更专业。更重要的是它要建立一套清晰可执行的回答规则有证据就回答有冲突就说清楚有缺口就追问无法确认就明确拒绝编造。这比单纯收集一堆提示词模板更有价值也更适合真正落地到企业知识库、产品文档和技术问答系统中。
Claude API 知识库问答提示词模板与优化方法
不少讲 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文档名产品功能说明段落IDP-12更新时间2024-05-10内容基础套餐支持单条数据导出专业套餐支持批量导出。\n片段2文档名套餐权限表段落IDT-08更新时间2024-06-01内容批量导出功能仅对专业套餐和企业套餐开放。}],temperature:0.1,max_tokens:800}比较理想的输出可以是### 直接结论 如果用户使用的是基础套餐则不支持批量导出专业套餐和企业套餐支持批量导出。 ### 依据说明 产品功能说明中提到基础套餐仅支持单条数据导出专业套餐支持批量导出。套餐权限表进一步说明批量导出仅对专业套餐和企业套餐开放。 ### 引用来源 - [产品功能说明P-122024-05-10] - [套餐权限表T-082024-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 用来做知识库问答时提示词的价值不只是让答案看起来更专业。更重要的是它要建立一套清晰可执行的回答规则有证据就回答有冲突就说清楚有缺口就追问无法确认就明确拒绝编造。这比单纯收集一堆提示词模板更有价值也更适合真正落地到企业知识库、产品文档和技术问答系统中。
