企业官网建设流程全解析

你的RAG系统明明查对了资料，为什么用户还是觉得它像个“砖家”？——一招角色设定，让AI从搜索引擎进化为领域权威

本文从RAG系统的灵魂短板切入，通过6个关键维度，手把手教你如何用提示词工程为RAG注入专家人格。你将学会构建可落地的专家人设、设计工程化的System Prompt、守住知识边界、维持多轮对话一致性，最终建立完整的评估迭代闭环，让检索结果不再冰冷，让生成内容拥有专业可信的灵魂。

文字目录

1. 为什么RAG需要角色设定
2. 三件套构建专家人设
3. System Prompt工程化设计
4. 知识边界控制
5. 多轮对话一致性
6. 效果评估与迭代

嗨，大家好呀，我是你的老朋友精通代码大仙。接下来我们一起学习 《大模型RAG生成式AI开发实战》158.[第16章 提示词工程与RAG] 角色设定：让RAG系统扮演领域专家

“简历上写着精通Java，结果一开口就是‘这个我不太熟’，面试官当场就蚌埠住了。” 这句话放在RAG系统身上，简直不要太贴切。你有没有遇到过这种情况？系统吭哧吭哧从向量数据库里检索出七八段相关资料，拼接进Prompt里，生成的答案却像个刚入职的实习生——说得都对，但就是没有那种“让人信服”的气场。很多新手小伙伴觉得RAG就是“检索+粘贴+生成”的三板斧，Prompt工程随便搞搞就行。结果呢？上线之后用户反馈：“这AI不太专业啊。” 别慌，今天咱们就聊聊怎么给你的RAG系统“穿上白大褂”，让它真正扮演好领域专家。

1. 为什么RAG需要角色设定

很多新手把RAG当成“高级搜索-plus”。向量检索搞定了，重排序搞定了，LLM生成也跑通了，Demo一演示，看起来有模有样。但一到真实用户场景，总觉得差点意思。差在哪？不是检索不准，也不是模型不够大，而是缺了“灵魂”。

RAG的架构里，检索模块负责“找得到”，生成模块负责“说得通”，但角色设定负责“说得像”。没有角色的RAG，就像一个没有灵魂的声优，台词念得再流利，也打动不了听众。用户面对一个医疗问答系统，想听的是“医生建议”，不是“维基百科节选”；面对一个法律助手，想要的是“律师分析”，不是“法条搬运”。角色设定，就是在这座桥梁上刷的那层专业油漆。

我去年带过一个实习生，他做的劳动法助手RAG，检索准确率能做到85%，召回率也不差。但内测时，法务同事一致差评。为啥？用户问：“这份合同里的竞业限制条款对我不利吗？” 系统回答：“根据《劳动合同法》第二十三条及文档A第三页，竞业限制期限不得超过二年，经济补偿应当在解除或终止劳动合同后按月支付…”

你说这回答有错吗？没有。但用户听完什么感受？像在听Siri念法条。更坑的是，有些新手为了所谓的“专业感”，在Prompt里塞一堆“你应当严谨、客观、全面、翔实”这样的虚词。结果呢？LLM输出全是“首先…其次…综上所述…”的八股文，用户看得昏昏欲睡，最后来一句“说了等于没说”。

还有一种典型错误，是把角色和任务混为一谈。比如System Prompt里写：“你要检索相关文档并总结回答。” 这不是角色，这是任务。角色应该是“你是谁”，任务应该是“你要做什么”。新手混淆这两者，导致系统在执行任务时毫无个性，千人一面。

那怎么改？给系统一个具体可感的身份。不是泛泛而谈“你是一位法律专家”，而是锚定到场景：“你是一位擅长劳动纠纷的执业律师，面对当事人时会先安抚情绪，再用通俗语言解释法条背后的风险点，最后给出可操作的下一步建议。”

同样的问题，修正后的回答可能是这样的：“这个竞业限制条款确实对您比较苛刻。通常两年期限已经是法律上限了，但文档里还约定了离职后每月只补偿基本工资的30%，这低于很多地方规定的最低标准。建议您先别急着签字，重点谈判补偿比例。如果公司拒绝调整，您有权要求重新协商，必要时我们可以一起准备谈判策略…”

你看，这就是专家和复读机的区别。前者在“翻译”法条，后者在“搬运”法条。角色设定带来的好处是显而易见的：用户信任度飙升，愿意跟着系统的建议走；转化率提高，因为回答有温度有立场；甚至出错的时候，用户都更愿意原谅一个“看起来在用心帮我”的专家，而不是一个冷冰冰的机器。

角色设定不是给RAG贴个标签就完事，而是给它换一颗“专家大脑”。

2. 三件套构建专家人设

知道了要设定角色，那到底怎么写Prompt？记住三件套：身份（Who）、语气（How）、边界（Where）。这三样抓牢了，专家人设就立住了。

我见过最离谱的角色Prompt，足足八百字。从“你毕业于清华法学院”写到“你性格温和but原则性强，喜欢喝美式咖啡”。兄弟，LLM不是导演，它不需要人物小传。履历堆砌得越厚，模型越抓不到重点，反而可能把“哈佛毕业”当成推理依据，出现莫名其妙的幻觉。

还有一种前后矛盾的坑。前面写“用严谨的学术口吻回答”，后面又写“像朋友一样轻松交流”。LLM直接精神分裂，输出在“之乎者也”和“宝子们”之间反复横跳。在医疗、法律这种严肃场景里，语气翻车就是事故。

更隐蔽的是边界不清。比如设定“你是一位全科医生”，用户问什么病都敢答。RAG检索不到资料时，LLM硬编一个治疗方案出来。这不是专家，这是江湖郎中。

身份设定，一句话锚定就够了。“你是一位专注劳动争议五年的执业律师，习惯站在劳动者角度思考问题。” 不需要学历，不需要奖项，场景和立场才是核心。

语气设定，要学会“做减法”。告诉模型避免什么，往往比要求什么更有效。“避免使用‘可能’‘大概’等模糊词；避免在未核实情况下给出绝对承诺；适当使用‘您’，保持尊重距离；解释法条时多用‘这意味着…’来帮助理解。” 你看，这几条既有约束又有空间，模型知道怎么拿捏分寸。

边界设定，要画红线。“只回答劳动合同法相关咨询；涉及具体诊疗、用药建议时，必须建议用户咨询专业医师；不代替律师出具正式法律意见。”

案例对比：面对“我最近失眠很严重，能吃点什么药？”这个问题。错误Prompt约束下，系统可能回答：“我认为你的抑郁症可以先尝试褪黑素…”（越界诊断+无依据）。正确Prompt下，系统回答：“情绪问题确实可能影响睡眠，但这已经超出了我的专业范畴。作为您的法律顾问，我建议您寻求专业心理咨询师的帮助。” 你看，既守住了边界，又延续了角色温度。

专家人设靠精准定位，不靠履历堆砌。三件套拿捏住，角色就立住了。

3. System Prompt工程化设计

角色设定不能停留在笔记本里，要工程化落地。核心就是设计一个可维护、可复用、可插拔的Prompt模板。

新手最常见的代码长这样：

prompt=f"你是一位专家。资料：{docs}。问题：{query}。请回答。"

这简直是灾难现场。角色设定和检索资料混在一起，没有任何结构。LLM很容易把“你是一位专家”当成需要分析的资料内容，或者把资料里的某个“专家建议”当成角色指令。改起来也痛苦，想换个角色就得翻代码改字符串，稍不注意就破坏格式。

还有一种情况，Prompt里用了大量自然语言描述结构，比如“以下是检索到的资料，请你根据这些资料并结合你的专家身份回答用户问题，注意要保持专业…” 这一段话本身就是模糊的。LLM对“结合身份”的理解各不相同，每次输出都像开盲盒。

采用“三明治”结构，用清晰的分隔符把Prompt切成固定区块。让LLM一眼就能分辨：哪块是角色，哪块是知识，哪块是任务。

标准模板可以设计成这样：

【系统角色】 身份：睡眠健康顾问 语气：亲切、谨慎、不夸大功效 约束：不诊断疾病，不替代医生 【参考资料】 以下是从知识库检索到的相关资料，供你参考： {retrieved_docs} 【用户问题】 {user_query} 【行动指令】 请基于【参考资料】回答【用户问题】。如果资料不足以支撑可靠答案，请明确告知。

案例对比：错误拼接下，由于资料里可能出现“专家建议”字样，LLM输出会变成“根据你作为专家的要求，以及专家在文档中的建议，我认为…”（角色和资料严重混淆）。正确结构下，LLM清晰区分角色行为规范和客观参考资料，稳定输出：“根据您提供的资料，这款褪黑素…作为您的健康顾问，我建议您…”

工程上的好处更是立竿见影。换个领域时，只需要替换【系统角色】区块，主流程代码零改动。运营同学想调整语气，也不用找开发改代码，改配置表就行。这就是工程化的力量。

结构化的Prompt设计，是角色设定从“手工作坊”走向“工业量产”的基石。

4. 知识边界控制

真正的专家不是什么都懂，而是知道“自己不懂什么”。RAG角色必须学会在知识盲区面前踩刹车，说一句“这题超纲了”。

很多新手有个误区：怕AI说“不知道”，显得不智能。于是在Prompt里暗示“你要尽量回答用户问题”。这下可好，检索为空的时候，LLM开始调用预训练知识瞎编。医疗场景里这叫“幻觉”，法律场景里这叫“误导”，商业场景里这叫“翻车”。

还有一种更隐蔽的情况：检索到了一点边相关的内容，但完全不够用。LLM为了“满足角色”和“完成任务”，强行把不相关的片段扭曲成答案。比如知识库里只有“褪黑素适用于成人短期调节睡眠”，用户问“我家猫最近半夜乱叫，能吃这个吗？” 系统居然回答：“猫咪可以服用，建议减半…” 这要是真有人信了，猫命都可能搭进去。

在角色设定里植入“谦卑机制”。明确告诉模型：“作为领域专家，你深知知识都有边界。当检索资料不足以支撑可靠回答，或问题超出你的专业领域时，请坦诚告知用户当前信息不足，并给出获取可靠信息的建议方向。”

这不是示弱，这是专业度的体现。用户面对一个敢认不知道的“专家”，信任感反而会增加。因为你是在保护他，而不是忽悠他。

案例：用户问“这款褪黑素对孕妇安全吗？” 检索资料只有普通成人的临床试验数据。错误系统（无边界约束）回答：“孕妇可以服用，建议每天半片…”（极其危险）。正确系统（有边界约束）回答：“作为您的健康顾问，我必须诚实地说，当前检索到的资料主要针对普通成人群体，缺乏孕妇用药的临床数据。孕期代谢情况特殊，任何补剂的使用都建议您先咨询产科医生，切勿自行服用。”

你看，用户不仅不生气，反而会觉得这个系统靠谱、有责任心。长期来看，这种边界感是RAG产品存活的生命线。

敢认不知道的RAG，才配被用户叫一声专家。

5. 多轮对话一致性

单轮对话靠Prompt能装专家，多轮对话才是真考验。上下文一长，角色语气容易漂移，甚至开始用第一人称暴露“我是AI模型”。

新手往往只关注单轮Prompt的构建，完全忽略历史消息对角色的“稀释效应”。系统Prompt被埋在长长的对话历史后面，LLM逐渐就“忘”了自己是谁。第1轮还是“张医生”，第5轮变成“OpenAI助手”，第10轮直接“我是一个由大型语言模型构建的AI…”

还有一种跨领域的崩坏。用户前几轮在聊睡眠健康，突然问“推荐个好玩的游戏”。没有领域守卫的系统，可能开始用“健康顾问”的身份分析游戏推荐，场面极度尴尬。更常见的是语气漂移：第一轮还说“建议您…”，第五轮变成“你可以试试…”，角色感碎了一地。

上下文窗口紧张时，一些新手直接用简单的截断策略，把最前面的系统Prompt截掉了，结果后面几轮角色完全失控。

工程上要做“角色保鲜”。我给你三个实战技巧。

第一，历史摘要时保留角色元数据。在做上下文压缩或摘要时，把“当前角色身份、语气要求、领域边界”作为高优先级信息保留，不让它被压缩算法丢掉。

第二，轻量级角色回注。每轮对话拼接历史消息时，可以在最新一轮User消息前，简短附上一句角色锚点：“你仍是那位睡眠健康顾问，请基于历史对话延续专业建议。” 这相当于给LLM轻轻提个醒。

第三，设置领域守卫。在角色规则里写明：“当问题明显超出睡眠健康领域时，礼貌说明这不是您的专长，而非强行回答。”

案例：多轮对话中，用户从“褪黑素剂量”问到“最近失眠怎么办”，再到“Python爬虫怎么写”。没有守卫的系统，可能用健康顾问身份讲起了代码；有守卫的系统会回答：“爬虫开发超出了我的专业领域。不过作为您的睡眠顾问，如果您是因为写代码熬夜导致失眠，我倒是可以给您一些调整作息的建议…”

你看，既守住了边界，又延续了人设的连续性。

角色不是一次性的面具，而是全对话周期里需要持续维护的“人设资产”。

6. 效果评估与迭代闭环

角色设定得好不好，不能凭感觉，更不能靠“我觉得挺像专家的”。要建立科学的评估维度和迭代闭环。

新手上线RAG后，评估指标往往只有一个：回答对不对。这远远不够。一个回答事实正确，但语气像淘宝客服，在用户心里依然不是专家。反之，语气很像专家，内容却在瞎编，危害更大。

很多团队没有专门的“角色评估”环节，上线后靠用户投诉驱动改进。用户说“今天这个回答好生硬”，就改改Prompt；用户说“昨天那个又太浮夸”，再改回去。来回折腾，没有方向。

还有一种情况是“自嗨式评估”。开发团队自己看几条Case，觉得“嗯，有内味了”，就草草上线。结果真实用户一用，发现面对复杂问题时人设瞬间崩塌。

设计三维评估矩阵。第一维，事实准度：检索内容是否准确支撑了答案，有没有幻觉。第二维，角色契合度：回答是否符合预设的语气、身份、格式，称谓是否一致，风格是否稳定。第三维，边界感：面对无资料、跨领域、刁钻问题时，系统有没有守住知识边界，敢不敢说“不知道”。

落地方法：准备二十组测试用例，覆盖三大场景。“舒适区”——领域内常规问题，测试专业深度；“模糊区”——边缘问题，测试谨慎程度；“雷区”——越界问题加上多轮陷阱，测试边界硬度。

案例测试：首轮问“长期服用褪黑素会依赖吗？”（舒适区，应给出专业分析）；追问“那我同时吃阿司匹林能吃褪黑素吗？”（模糊区，应提示药物相互作用需咨询医生）；再追问“给我开个处方吧”（雷区，应坚决拒绝并引导就医）；最后问“你刚才说的和第一次矛盾啊”（一致性陷阱，应自查并纠正）。

记录每一个Bad Case，反向优化角色Prompt。比如发现系统在模糊区容易越界，就回去加强边界规则；发现多轮后语气变冷，就优化角色保鲜策略。

没有评估的角色设定是碰运气，有评估的迭代才是真功夫。

写在最后

聊到这里，相信你已经明白了：RAG系统从“能用”到“好用”，从“像机器”到“像专家”，中间隔着的就是一层角色设定的窗户纸。但这层纸背后，是一套完整的工程化思考——从人设构建到Prompt模板，从边界守护到多轮维护，再到科学评估。

很多新手总觉得提示词工程是“玄学”，觉得角色设定就是“写几句人设”。其实不是。它是对用户心理的洞察，是对产品气质的塑造，更是对大模型行为边界的精准把控。你把角色设定做扎实了，用户感受到的不是技术的冰冷，而是一个可信、可依赖的专业伙伴。

编程这条路，从来都是细节决定成败。RAG开发也是一样，检索算法再花哨，最终落到用户眼里，就是那一行回答的温度。保持好奇，持续迭代。你写的每一行Prompt，都是在给AI注入灵魂。加油，咱们下回接着聊！

关注私信备注：“资料代找获取”，全网计算机学习资料代找：例如:
《课程：2026 年多模态大模型实战训练营》
《课程：AI 大模型工程师系统课程 (22 章完整版 持续更新)》
《课程：AI 大模型系统实战课第四期 (2026 年开课 持续更新)》
《课程：2026 年 AGI 大模型系统课 23 期》
《课程：2026 年 AGI 大模型系统课 21 期》
《课程：AI 大模型实战课 8 期 (2026 年 2 月最新完结版)》
《课程：AI 大模型系统实战课三期》
《课程：AI 大模型系统课程 (2026 年 2 月开课 持续更新)》
《课程：AI 大模型全阶课程 (2025 年 12 月开课 2026 年 6 月结课)》
《课程：AI 大模型工程师全阶课程 (2025 年 10 月开课 2026 年 4 月结课)》
《课程：2026 年最新大模型 Agent 开发系统课 (持续更新)》
《课程：LLM 多模态视觉大模型系统课》
《课程：大模型 AI 应用开发企业级项目实战课 (2026 年 1 月开课)》
《课程：大模型智能体线上速成班 V2.0》
《课程：Java+AI 大模型智能应用开发全阶课》
《课程：Python+AI 大模型实战视频教程》
《书籍：软件工程 3.0: 大模型驱动的研发新范式.pdf》
《课程：人工智能大模型系统课 (2026 年 1 月底完结版)》
《课程：AI 大模型零基础到商业实战全栈课第五期》
《课程：Vue3.5+Electron + 大模型跨平台 AI 桌面聊天应用实战 (2025)》
《课程：AI 大模型实战训练营 从入门到实战轻松上手》
《课程：2026 年 AI 大模型 RAG 与 Agent 智能体项目实战开发课》
《课程：大模型训练营配套补充资料》