企业官网建设流程全解析

做RAG（检索增强生成）的朋友，肯定都遇到过这种场面：知识库里明明写着“支持批量导出”，模型却一本正经地告诉你“可以调用导出接口”，还顺手编了个不存在的参数名。更夸张的是，你问它“这个功能收费吗”，它能从一份完全不相关的产品手册里“推理”出一套定价逻辑。这不是模型变笨了，而是RAG链路里检索和生成两个环节只要有一个掉链子，AI就开始自由发挥、胡说八道。我这两年调了不少RAG问答系统，真正让我从“不停换模型”转向“稳定输出”的，不是什么高深架构，而是把提示词从一句话扩成一组带硬约束的模板。尤其对程序员来说，模板一旦规范起来，不光问答准确率提高，连排查问题、写代码示例的效率都能翻倍。这篇文章就把我实际在用的五个RAG提示词模板分享出来，顺便把背后的设计逻辑和踩坑记录一并交代清楚，小白照着抄就能用。

1. 为什么RAG还是会胡说八道：先搞清楚病根

很多人的第一反应是换更大的模型，或者调高温度参数，其实方向错了。RAG的标准流程很简单：把用户问题转成向量，从知识库检索出最相关的几个片段，再把片段和问题一起丢给大模型生成答案。看似没有技术含量，但“检索”和“生成”每一步都有自己的坑，幻觉大概率就藏在这两条缝里。

1.1 检索不准：内容没捞对

我见过一个知识库项目，文档是几十篇技术白皮书的混合体，切块的时候按每512个字符硬切。结果一个问题抛过来，检索到的片段把“配置环境变量”和“部署集群”两段无关内容粘在一起，模型顺着错误上下文开始发挥，答案自然离谱。这里的关键是：向量检索帮你筛选的只是“语义相似”，不是“逻辑正确”。切块过大，片段里混入噪声；切块过小，语义不完整；embedding模型选得不合适，专业术语相似度拉不开；topK设置得太小，唯一包含答案的片段没被召回。这些问题最后都会变成模型生成时的“隐形炸弹”。

1.2 生成太自由：模型不老实

就算检索片段没问题，大模型也不会老老实实照着念。它的训练目标是预测下一个token，在生成时会不断挑“概率最高”的内容。如果提示词里没有明确说“只能依据检索片段回答”，它就会自动切回闭卷考试模式，把训练时见过的相似内容补进来。我举个印象很深的例子：某设备说明书里写道“故障代码E02表示温度过高”，用户问“E02怎么解决”，模型居然回答“请检查传感器连接，必要时更换主板”。这后半句完全是模型自己脑补的，因为训练数据里见过类似的维修手册。这个问题的根源就是生成阶段没有约束，“自由发挥”对普通聊天是优点，对RAG问答就是灾难。

1.3 提示词的桥梁作用

提示词在这里扮演的是“翻译官”和“紧箍咒”：先让模型分清哪部分是检索资料、哪部分是用户问题，然后强制它只使用检索资料，最后规定资料不足时该怎么办。很多开发者到现在还觉得提示词只是“请你根据资料回答”这种一句话的事，结果模型经常把资料和问题混在一起理解。实际测试下来，结构化的模板能把幻觉率明显压下去，准确率提升非常可观。这就是为什么接下来这五个模板值得你反复打磨，它们本质上是把“怎么约束模型”这件事变成了可复制的套路。

2. 五个可以直接抄的RAG提示词模板

这五个模板是我在不同场景里落地验证过的，覆盖了大部分RAG问答的常见需求。你不用死记，重点看每个模板的“约束结构”，然后照着改场景关键词就行。

2.1 模板一：忠实引用模板：禁止模型自己发挥

适用场景：企业知识库、产品FAQ、客服自动回复。这类场景的答案必须和官网文档、内部规范保持一致，不能有任何个人发挥。

完整提示词示例：

你是一个企业知识库问答助手。我会给你一段【检索资料】和用户问题。 【检索资料】 {context} 【用户问题】 {question} 回答要求： 1. 只能依据【检索资料】回答，不得使用资料之外的信息。 2. 如果资料足够，用简洁的中文直接给出答案，并注明答案对应的原文片段。 3. 如果资料不足以回答，明确说“根据现有资料无法回答”，不要猜测。

为什么这个模板好用？关键在于“把检索资料单独标记成一个独立段落”，让模型先把资料当成参考上下文，而不是聊天内容的一部分。我还特意加了“注明依据片段”的约束，这样模型在生成时就不敢随便凑答案。实际用的时候，有两点要注意：资料建议放在用户问题前面，模型先看到参考资料再看到问题，不容易被问题带偏；约束条款不要超过五条，超过之后模型执行率会断崖式下降。

2.2 模板二：诚实边界模板：让AI敢于说“不知道”

适用场景：法律、医疗、金融这类严谨领域。在这些场景里，错误的确定性答案比“不知道”危险得多。

完整提示词示例：

你是专业的法律咨询助手。下面是从法条库中检索到的【相关条款】。 【相关条款】 {context} 【用户问题】 {question} 请严格按以下规则回答： - 只有条款与问题直接相关时，才引用条款给出结论。 - 如果检索条目与该问题不相关，请说明“当前检索到的资料与您的问题关联度不足”，并建议用户重新描述问题。 - 禁止自行补充法条内容。 - 如果资料里明确说明了适用范围或例外情况，请一并转述。

这个模板的核心设计是“给模型一条安全出口”。很多开发者的误区是觉得模型说“不知道”是系统失败，实际上对用户来说，一个明确的“资料覆盖不到”远比瞎说一个结论更负责任。另外这个模板对“转述例外情况”做了强制要求，防止模型只挑对用户有利的片段。我测试下来，加上这条之后，法律和金融场景的回答置信度明显提升。

2.3 模板三：结构化输出模板：带引用来源地回答问题

适用场景：员工服务台、研究助手、需要把回答接入自动化流程的场景。结构化的最大好处是方便程序解析，你可以直接把模型输出的JSON喂给后端做二次校验。

完整提示词示例：

你是研究助手。根据提供的【文档片段】回答问题，并输出如下JSON格式： { "answer": "最终答案", "evidence": ["来源片段1", "来源片段2"], "confidence": "high/medium/low" } 【文档片段】 {context} 【问题】 {question} 规则： 1. evidence必须是从文档片段中提取的原文或可追溯摘要，禁止编造。 2. 如果文档片段与问题无关，answer填写“资料无法回答”，confidence设为low。

为什么这个模板对程序员友好？因为evidence字段可以直接对应到前端展示的“来源引用”，方便用户点开查看。confidence字段则可以用于筛选低质量回答，实现自动化质检。不过结构化输出对模型要求更高，如果模型服务支持强制JSON格式，优先开启；如果每次都夹杂解释性文字，可以在模板末尾加一句“只输出JSON，不要输出任何其他内容”，但别重复太多次，否则模型容易干脆输出空JSON。

2.4 模板四：多文档综合对比模板：处理资料冲突

适用场景：同时检索到多份内容矛盾的文档，比如不同版本的产品规格、竞品分析、跨部门制度。这种场景用普通模板非常容易翻车，因为模型会自作主张帮你“融合”冲突信息，最后弄出一个两不靠的答案。

完整提示词示例：

我将提供多个【文档片段】，它们来自不同资料，内容可能存在冲突。 【文档片段1】 {context_1} 【文档片段2】 {context_2} 【用户问题】 {question} 需要完成： 1. 找出与问题相关的所有片段。 2. 列出各片段的核心观点，并标明来自哪个片段。 3. 如果片段之间结论矛盾，请明确指出差异，并归纳冲突点，不要强行融合。 4. 最终输出格式：相关结论、冲突点、推荐判断。

这个模板的巧妙之处在于，它把“指出矛盾”变成了任务的一部分，而不是让模型去回避。模型一旦被要求“列出冲突点”，它就必须老老实实引用不同片段的原文，这样用户能一眼看到版本差异。实际应用中，我还会在提示词开头加一句“资料覆盖可能不完整”，否则模型容易误以为给到的几个片段就是全部真相。

2.5 模板五：代码生成与解释模板：程序员专属

适用场景：读取项目文档、API文档、代码库问答。程序员用RAG最大的痛点是模型脑子里装的API签名不够新，经常用旧接口生成代码，看起来能跑，一编译就报错。

完整提示词示例：

你是编程助手。下面是从项目文档中检索到的【参考资料】。 【参考资料】 {context} 【任务】 {question} 请按下面步骤回复： 1. 先简要说明任务要求。 2. 如果参考资料中有相关API或示例，基于参考资料写出代码，请勿使用参考资料之外的API。 3. 代码必须用代码块包裹，并标注语言。 4. 如果参考资料中没有相关信息，请明确说“文档中未找到对应API”，并建议用户查阅具体章节，不要猜测API签名。 5. 代码示例中出现的函数名、参数必须来自参考资料；如果补充了必要解释，请与代码主体区分。

代码场景额外要加一句杀手锏：“优先使用资料中出现的函数签名，即使你记得更常用的写法，也请以资料为准。”这句话能压制模型强烈的“祖传记忆”。我见过太多反面案例：文档里明明用的是ctime参数，模型硬是给改成timestamp，因为在它记忆里timestamp才是主流。加了这个约束后，代码与文档的匹配度会高很多，程序员复查代码的时间大幅缩短。

3. 模板背后的提示词设计原理：参数、结构与调优

模板不是随便拼几句命令。你要理解它为什么有效，才能在遇到新场景时灵活调整，而不是永远抄作业。

3.1 三个关键要素：角色、任务、约束

我总结RAG提示词模板的骨架是三段式：角色定义、任务描述、硬性约束。角色定义决定模型的语气和知识背景，比如“你是企业知识库助手”会让模型自动切换到专业模式；任务描述明确“做什么”，比如“回答用户问题并输出JSON”；硬性约束是模板的核心，它告诉模型“不能做什么”，比如“禁止使用资料之外的信息”。很多模板效果差，是因为只写了角色和任务，没有硬性约束。你观察上面五个模板会发现，每一段都有类似于“禁止”、“必须”的词汇，这些都是给模型的规则，不是建议。模型对“请尽量”这类模糊词的理解很弱，对“必须”“禁止”的理解才比较可靠。

3.2 temperature、top_p 如何配合

提示词模板不是唯一的变量，生成参数同样会影响幻觉率。RAG场景的temperature建议设置在0到0.3之间，代码生成甚至可以调到0.1。temperature越高，模型越愿意“创造”，自然就越容易编造内容。top_p同理，建议调低至0.7左右，限制候选词范围。我之前有过一次对比：同一套模板，temperature从0.7降到0.1之后，法律问答的幻觉率降了一截，代价是回答略显枯燥，但对知识库问答来说，枯燥恰恰是优点。总结就是：模板负责“划定边界”，参数负责“降低不确定性”，两者缺一不可。

3.3 如何根据反馈快速调优模板

模板也需要迭代。我的调优流程很简单：收集badcase，判断是检索问题还是生成问题，检索问题去改切块和召回参数，生成问题去改提示词，然后再回归测试。举个例子，原模板写“请根据资料回答”，模型经常绕过资料自由发挥。我把这句话改成“只允许使用资料中的事实回答，禁止使用资料之外的任何信息”，效果立刻改善。这背后的原理是：越是明确的否定句，越能抑制模型的默认行为。另外，如果发现模型经常输出无关内容，可以检查是不是检索片段太长，把无关上下文也带进去了。记住：很多“提示词不好用”的case，实际是前面的检索已经烂了，提示词救不回来。

4. 实操案例：把模板真的接进RAG链路里

光有模板不够，你得知道怎么把它拼进现有代码。这里我给一个最小化的落地流程，方便你快速复制。

4.1 一个最小化落地流程

RAG的处理链路大致是：文档加载、文本切块、向量化、存入向量库、用户问题向量化、检索topK片段、拼接提示词、调用模型。这里不扯框架，直接给一个伪代码级别的思路，你用任何RAG框架都能套：

def build_prompt(query, docs): context = "\n\n".join([d["content"] for d in docs]) template = """你是企业知识库问答助手。我会给你一段【检索资料】和用户问题。 【检索资料】 {context} 【用户问题】 {question} 回答要求： 1. 只能依据【检索资料】回答，不得使用资料之外的信息。 2. 如果资料足够，用简洁的中文直接给出答案，并注明答案对应的原文片段。 3. 如果资料不足以回答，明确说“根据现有资料无法回答”，不要猜测。 """ return template.format(context=context, question=query)

然后在检索步骤之后，把检索到的docs按相似度排序，截取前3到5个片段填进context字段。关键点是：context长度一定要控制。如果你检索出来20个片段，一股脑全塞进去，模型很容易被无关内容干扰，指令遵守率也会下降。建议先按相似度排序，保留最相关的3到5段，每段再按字数截断到300到500字以内。

4.2 提示词拼接的细节

拼接环节有四个细节直接影响效果。第一，模板里的变量命名不要用“上下文”这种模糊词，用“【检索资料】”这种清晰标记，模型更容易区分。第二，用户问题放在最后，检索资料放前面，这个顺序更稳。第三，如果问题类型固定，可以在模板里加一个示例输出，帮助模型对齐格式。第四，上下文超过模型窗口时，优先丢弃相似度最低的片段，不要随意截断中段内容，否则答案的上下文会支离破碎。这些细节在你实际写代码的时候，就是决定模型乖不乖的分水岭。

4.3 有模板 vs 无模板的效果对比

我拿某设备说明书做了个简单测试，问了五个典型问题，结果差异非常直观：

上表里的无模板也不是完全没写提示词，只是用了最普通的“请回答以下问题”。对比下来，五个模板的价值不只是“规范生成”，更重要的是让AI学会在资料不足时“闭嘴”。这种能力直接决定RAG系统能不能用在生产环境。

5. 常见问题与排查技巧实录

最后这部分是实践里最容易踩的坑，我整理成一份速查表，你按图索骥就行。

5.1 模型还是不遵守怎么办

如果你发现模型偶尔还是自由发挥，先别急着换模板。排查顺序是：第一，确认检索回来的片段里是否真的有正确答案；如果检索就没捞对，提示词再怎么改也没用。第二，检查生成参数，确保temperature在0.3以下。第三，检查提示词是否被长上下文稀释，也就是片段太多，模型找不到重点。第四，尝试把约束条款提到最前面，并在每条约束前加“重要：”前缀，让模型知道优先级。实测下来，“把约束前置”对指令遵循弱的模型很有效。

5.2 引用了不存在的来源怎么办

结构化输出模板里的evidence字段偶尔会混入不存在的来源。解决办法有两个层面：提示词层面，要求“evidence必须直接引用原文，禁止概括”；代码层面，把模型返回的evidence与数据库里的片段做比对，如果片段不匹配直接丢弃。我现在的做法是双保险，既在提示词中约束，又在代码里做一层filter。很多时候模型给出的来源是“看起来很像”的伪原文，代码校验能立刻拦住。

5.3 模板太复杂导致效果变差

提示词模板不是越长越好。有段时间我追求“完美”，给模板加了七八条规则，结果模型的执行率反而下降。后来我意识到，模型对复杂指令的处理能力有限，尤其是在上下文又长又乱的时候。核心约束保持在3到5条最理想。如果你确实需要处理复杂任务，可以在主模板外再加一层“前置指令”模板，先提炼检索内容，再做主任务，而不是把所有要求压在同一段话里。

5.4 代码场景的特殊坑

代码生成的幻觉最难察觉，因为代码能运行并不代表逻辑正确。常见的是模型补全了文档里不存在的函数参数，或者自动“修复”了一个压根不存在的bug。我的处理方法是：在提示词里明确要求“所有变量名、类名、函数签名必须来自参考资料”，另外在代码产出后，用脚本提取代码中的import和函数名，回知识库比对一遍，缺失的直接标记为警告，让程序员人工确认。这样即使模型哪天“上头”了，错误也逃不过最后一关。

我个人在实际操作中体会最深的是，提示词模板并不是万能灵药，它的效果上限取决于检索质量。如果你花一个晚上调模板，不如先花两小时把topK召回的数据打印出来看看，是不是连正确答案都没进候选池。最后再分享一个小技巧：开发阶段可以把“检索片段”和“最终回答”一起打进日志，每次出问题都能立刻定位是检索环节还是生成环节，长此以往，你的调优效率会是别人的好几倍。