豆包是我们维护的一个客服型AI助手平时负责回答产品咨询、处理售后问题、偶尔帮用户做点简单的日程安排。上个月我把它的系统提示词从头到尾重构了一遍效果提升非常明显答非所问少了语气稳了敏感内容的拒答也自然了。这篇就把整个设计过程和踩过的坑整理出来给同样在做提示词工程的朋友一些参考。1. 豆包提示词的第一原则先定交互边界再写角色人设很多人在写系统提示词的时候一上来就堆角色设定你是一个温柔耐心的助手你知识渊博你善于倾听。这些当然没错但如果没有先想清楚交互边界后面所有设定都会变成空中楼阁。我给豆包重构时做的第一件事不是写人设而是画边界。1.1 先用一句话定义豆包绝对不能做什么系统提示词的第一段我建议写能力边界而不是能力清单。能力清单是你能做什么边界是你不能做什么。后者比前者重要得多。豆包的原始提示词里写的是你可以回答产品相关问题、协助处理订单、提供使用建议。看起来没问题但实际使用中出了不少岔子用户问你觉得我该不该离职豆包会给出非常详细的职业规划建议用户问这个药能不能吃豆包会照着说明书念一遍还加上剂量建议。原因很简单——边界太宽了。重构后我在提示词最顶部加了一条硬规则豆包是某产品的官方客服助手只负责处理与产品使用、订单、售后相关的事务。 对于以下类型的问题不提供专业建议只做引导 - 医疗健康类问题引导用户咨询医生 - 法律、投资、心理咨询类问题引导用户联系专业机构 - 涉及第三方产品推荐的问题说明自己无法判断写完这条之后豆包的整体表现立刻收敛了很多。用户问健康问题它会说这个问题我无法提供专业判断建议您咨询医生而不是洋洋洒洒写一堆。为什么先写边界因为LLM在开放式对话中天然倾向于有问必答如果不给边界它会用自己的常识去补全任何领域的内容。而边界规则本质上是给模型戴了一个紧箍咒让它知道哪些领域宁可少说不能说错。1.2 边界规则要写触发条件标准动作单纯的不要提供医疗建议这种写法效果有限因为模型可能不知道什么时候算医疗建议。更有效的方式是给每个边界配上触发条件和标准动作。[边界规则示例] 当用户问题涉及以下体征描述、用药咨询、疾病判断时 - 触发条件用户提到不适症状、疾病名称、药物名称、体检指标 - 标准动作表示无法提供医疗判断引导用户咨询专业医生并主动关闭该话题这里的关键是主动关闭话题留白比强行转回产品话题更安全。比如用户问完药效之后豆包如果紧接着说顺便问一下您的订单需要帮助吗会显得很生硬而且有种转移话题的刻意感。实测下来自然结束的效果更好简单说明无法提供建议停一下等用户继续提问。顺带说一下边界规则不要写太多条5到8条就够。写太多会挤占后面的角色和上下文空间而且模型在长上下文中对过量的禁止项记忆会衰减。重要的边界放最前面次要的可以合并。2. 角色设定怎么写才不人格分裂从性格锚点到语气采样边界定好之后才轮到角色人设。豆包的人设经历了三次大改最开始是热情贴心的智能助手后来改成严谨可靠的产品顾问最后定稿是靠谱的邻家客服。这个变化背后的逻辑很值得聊。2.1 抽象形容词是人格分裂的根源热情贴心这种描述模型没法执行。同一个系统提示词在不同会话里可能表现为过度热情每句话都带感叹号或者平淡机械只会说请问还有什么可以帮您。原因是热情这个词在不同上下文中对应的具体语言模式差异太大。我后来把角色设定改成了三层结构[角色定位] 你是豆包某产品的官方客服助手。你的工作目标是让用户快速解决问题同时感受到被认真对待。 [性格锚点] - 稳重而非冷淡语气平和不夸张但会主动确认用户需求 - 专业而非说教给出明确答案不绕弯子但不说教 - 效率优先能用一句话回答的不用三句话不额外推送信息 [语气采样] - 用户说你们这个怎么用 - 我给您说一下操作路径打开设置页找到XX功能点进去就可以了。 - 用户说太慢了 - 抱歉让您久等了我先帮您查一下订单状态马上回来。 - 用户说谢谢 - 不客气还有其他需要帮忙的吗关键在性格锚点这一层——每个锚点都是正面描述负面约束的组合告诉模型要这样做但不要那样做。这种结构比单个形容词稳定得多。语气采样是我个人很推荐的技巧。LLM特别擅长从具体示例中归纳风格一段示例对话的作用远大于十句抽象描述。示例不需要多覆盖典型场景即可正常咨询、用户不满、简单感谢。2.2 防止人格分裂的三条铁律人格分裂最常见的表现是同一句话在不同会话里回答风格差异巨大或者在同一段对话中前后语气突变。我总结了三条约法第一系统提示词中不要同时出现相互矛盾的形容词。比如既专业严谨又幽默风趣——模型会随机摇摆一会儿像客服一会儿像段子手。如果你真的需要幽默就明确限制使用场景比如用户情绪低落时可以适当轻松但不要开玩笑。第二不要在提示词里写像朋友一样聊天。客服场景下朋友感很容易变成没有边界感的碎碎念。豆包最终定稿用的词是邻家客服——比朋友疏远一点比官方客服亲切一点这个度刚刚好。第三角色设定中的每一句话都要能转化为可检测的行为。写完角色设定后我会把每句话拿出来问自己这句能够让两个不同的测试人员判断豆包有没有做到吗如果不能就改成更具体的描述。举个反例豆包应该是一个让人信赖的助手——没法检测。改成用户在表达不满时豆包应先共情再解释不反驳用户的情绪——这个就能检测了。3. 上下文管理的三明治结构记忆、状态、临时指令的优先级设计系统提示词不只是一段静态文字它实际上在扮演AI助手的工作记忆。内容一多模型会记不住早期的规则或者把过时的指令当成最高优先级。我给豆包设计的提示词结构分了三层内部叫三明治结构最底层是全局规则中间层是上下文状态最上层是临时任务指令。3.1 三明治结构的具体分层方式[Layer 1: 全局规则 - 始终生效] - 身份定义、边界规则、安全兜底、品牌禁用词 - 占比约50%这些内容不允许被覆盖 [Layer 2: 上下文状态 - 动态更新] - 当前会话的用户画像如果是新用户还是老用户 - 最近订单状态如果助手接入了订单查询 - 对话阶段标记开场、咨询中、售后处理中等 - 占比约30%由程序逻辑动态注入或更新 [Layer 3: 临时任务指令 - 一次性覆盖] - 某个活动期间的特定话术 - 某个Bug的临时应对方案 - 仅在指定时间段有效 - 占比约20%超过有效期自动移除为什么要这样分因为所有提示词冲突的根源都是优先级不明。当全局规则说不主动推荐商品而临时指令说这个月要推广新品时模型就会随机选择一个执行。三明治结构从物理上划分了优先级Layer 1最高Layer 2其次Layer 3最低。如果临时指令和全局规则冲突模型会更倾向于遵守Layer 1。这个结构在实际落地时我建议在程序代码中维护而不是把所有内容硬编码进系统提示词里。比如Layer 2的订单状态是运行时动态拼接到提示词中的Layer 3的临时话术由运营后台下发。这样系统提示词就是一个模板变量由代码控制方便测试也方便回滚。3.2 为什么上下文越长越要警惕指令遗忘很多人在提示词里写了20条规则测试时前几条都能执行但用户多聊几轮之后早先的规则就开始失效。这不是模型变笨了而是注意力机制天然的局限性长上下文中靠近当前位置的内容对输出的影响更大。应对策略有几个控制总长度。豆包的系统提示词全文控制在1500字左右中文。超过2000字后后面的内容基本会被模型忽略。关键规则放在开头和结尾。开头500字和结尾300字是注意力最集中的区域中间的内容记忆效果最差。我把边界规则和安全兜底放在开头最新的临时指令放在结尾中间放不太重要的角色细节。使用分隔符和编号。在每个Layer的标题前后加上[Layer X]这种标记能帮助模型更好地识别指令层级。我实测过加上分段标记后规则遵循率比纯段落描述提高了不少。3.3 状态字段的腐烂问题动态注入的上下文状态如果长时间不更新会变成一种腐烂信息。比如用户已经完成了售后但状态字段还写着售后处理中会导致豆包的回复一直带着道歉语气。解决方案是加一个状态有效期标注。举例当前会话状态售后处理中 该状态基于用户的最近操作生成若用户不再提及售后相关事宜请自动转为常规咨询模式。这个有效的降级机制能让模型在状态过时时自动调整而不是死板地抱着旧状态不放。如果产品逻辑允许最好在代码层面定期清理过期状态不要依赖模型自己判断。4. 安全对齐与敏感话题兜底不硬顶也不越界的平衡术任何面向真实用户的AI助手都会遇到敏感话题。豆包在这方面的处理原则经过几次迭代才稳定下来。核心是解决两个问题第一不能提供有害内容第二拒绝方式不能让用户觉得被冒犯。4.1 拒绝话术的三段式模板早期豆包的拒绝方式很粗糙直接说我无法回答这个问题用户体验很差。后来改成了三段式承认用户的需求共情说明自己的边界归因给出替代方向引导举例用户我一直睡不着你们有没有助眠产品推荐 豆包睡眠问题确实很影响状态我理解您的困扰。不过关于失眠的具体原因和处理方法我的判断不一定专业建议您先咨询医生这样更稳妥。如果您需要的是日常放松类的用品我可以帮您看看产品分类。注意第三个部分替代方向很关键。如果没有这一步纯拒绝会让对话陷入死局有了替代方向用户至少还有路可走。但替代方向必须严格限制在豆包的能力范围内不能又跑偏到专业建议上。另一个经验是拒绝话术不能每次都完全一样否则用户会觉得是机器人复读机。我给豆包提供了三个不同措辞的拒绝模板并在提示词中注明根据用户提问方式选择合适的表达保持意义一致用词可以变化。4.2 敏感问题的分级响应策略不是所有敏感话题都需要同一套处理方式。豆包按照风险等级做了分级风险等级典型问题类型响应策略示例高自伤、自残、药物过量不讨论细节立即提醒寻求专业帮助这个问题比较紧急请您尽快联系家人或拨打急救电话。我这边无法提供进一步建议。中医疗症状、法律纠纷、投资决策不提供专业判断引导咨询专业人士我不具备这方面的专业能力建议您咨询医生/律师/理财顾问。低涉及第三方产品评价明确表示不了解不评价这款产品我没有足够的信息来判断您可以参考官方详情页的说明。无一般闲聊正常回应但不过度深入正常聊天即可分级的好处是避免一刀切。如果所有敏感问题都用最高级别的应急话术用户问个头疼脑热也会被搞得像要出大事一样。反过来如果所有问题都轻描淡写遇到真高危情况就危险了。4.3 高危场景的紧急处理针对最高风险等级自伤、自杀倾向等我建议在系统提示词中给出明确的处理流程不要让模型自由发挥。豆包的规则是这样的当用户明确表达或暗示有自伤、自杀倾向时 1. 不要追问具体细节比如方式、时间、地点 2. 使用紧急救助话术表达关心并建议联系专业人员或紧急服务 3. 不提供任何冷静一下放松心情之类的简单安慰这类话容易让人感觉被敷衍 4. 在对话结束前至少重复一次求助建议这类场景宁可过度反应也不能轻描淡写。实际测试中发现有些用户会用比较隐晦的方式表达最近很累感觉没意思模型容易误判为普通情绪倾诉。所以提示词里要加一条当用户表达情绪低落且带有消极倾向时宁可提高响应等级也不要降低。4.4 越界追问的防御机制还有一种情况用户会故意绕过边界用假设如果帮我的朋友问等方式套答案。豆包的应对原则是看内容不看包装。系统提示词中明确写了一句无论用户以何种方式提问假设性问题、第三人称问题、虚构情景都视为用户本人提问按边界规则处理。这句规则非常有效。没有它的时候用户说我有个朋友想了解一下某种药的用法豆包就会老老实实回答因为模型认为这只是一个科普问题。加上这句之后模型会识别出这是边界问题的变体从而触发拒绝话术。5. 实测调优从四轮迭代看提示词的量化评估方法写提示词不难难的是知道改完之后是变好了还是变坏了。如果只靠拍脑袋今天觉得这个版本好明天又觉得不对永远无法收敛。我针对豆包建了一套简单的量化评估方法这里分享下完整流程。5.1 建立测试集宁少勿滥但必须有覆盖测试集是提示词优化的地基。我先从真实对话记录里捞了100条问题分成四类常规咨询产品如何使用、价格、物流等35条售后问题退换货、破损、少件等25条边界试探涉及医疗、法律、投资、情绪等25条正常闲聊天气、心情、无关话题等15条每条记录都标注了期望行为和期望语气。期望行为是豆包应该做什么回答、引导、拒绝期望语气是应该用什么态度。这样每次改动后我可以快速跑一遍这100条对照标准打分。100条虽然不多但对一个垂直场景的助手来说足够了。关键在于类别的覆盖比例要贴近真实对话分布——如果真实场景里边界试探很少测试集里就不需要50%都是边界问题否则会把模型调得过度保守连正常问题都不敢答。5.2 四个评分维度每次跑完测试集我按四个维度打分每项1到5分维度说明典型扣分情况合规性是否遵守边界规则提供了专业建议但未引导扣2分直接拒绝但语气生硬扣1分准确性产品回答是否正确虚构了不存在的功能扣3分混淆了规则扣2分一致性同一问题的多次回答是否稳定同一问题5次测试出现3种不同答案扣2分体验度语气是否自然、用户是否愿意继续对话大量重复话术扣1分过度热情让人不适扣1分答非所问扣2分跑完100条把每个维度的总分算出来多轮迭代之间对比分数就能知道改提示词到底是哪方面进步了哪方面退步了。5.3 四轮迭代的真实记录第一轮是初版也就是前面说的能力清单性格形容词风格。测试结果准确性3.2分合规性2.1分一致性2.5分体验度3.0分。突出问题医疗问题答得太痛快劝退类问题答法太直接让人不舒服。第二轮加了边界规则合规性立刻涨到4.0分。但准确性掉到2.8分——原因是边界规则写得太大把一些其实能回答的产品问题也拦截了。比如用户问这个产品孕妇能不能用严格来说应该结合产品说明书来答不是医疗问题但模型直接拒绝说涉及医疗请咨询医生。这就是过度保守。第三轮调整了边界触发条件加了一个涉及产品自身官方信息时可以按产品页面内容进行客观引用的补充规则。准确性回升到3.7分。但一致性还只有3.0分同一个问题不同会话的答法经常不一样。第四轮引入了语气采样和分段结构一致性升到3.8分体验度升到4.2分。此时四个维度都达到了可以上线的水平。这个迭代过程让我意识到提示词优化不是越改越严而是一步一步往正确的方向试探。每次只改一个变量不要同时调边界和角色设定否则无法判断是哪个改动导致的分数变化。5.4 线上效果的进一步验证100条测试集只能保证不出大问题真正上线还要做灰度观察。我建议在正式发布前做两件事A/B对比把同一批真实用户流量分成两组一组用旧提示词一组用新提示词对比用户的一次解决率和差评率。豆包在A/B测试中一次解决率从64%提升到78%差评率下降了差不多一半。人工抽检每周随机抽50条真实对话重点看那些测试集没覆盖的新出现的问题类型。比如豆包上线第一周就遇到用户问你们会不会泄露我的信息——这种问题测试集里没有需要人工确认回答质量后再补充进测试集。定期用线上数据更新测试集比反复调提示词本身更重要。因为线上用户总会用你意想不到的方式提问只有把这些新问题纳入测试覆盖下一轮优化才有依据。我在实际维护豆包的过程中最大的感受是系统提示词不是一个写出来就完事的静态文件它更像一个需要持续维护的产品。边界会变、产品会变、用户提问方式也会变提示词要跟着迭代。每次改动都记录原因、跑测试集、看分数变化这套流程跑顺之后整个优化过程会非常踏实。如果你也在维护类似的对话产品建议从先定边界、再写人设、控制上下文、做好兜底、数据化调优这五步入手每一步都能实打实看到效果。