★ FEATURED ARTICLE 公共服务AI的落地难我这两年感触特别深。很多团队拿着业内头部模型做出来的Demo在内部评审时效果惊艳一放到真实服务窗口或者热线场景里立刻原形毕露。问题不在模型本身而在Agentic AI的“行为可控性”——它不仅要会说话还要会办事、懂得边界、知道什么时候该闭嘴。作为提示工程架构师我过去一年里在多个公共服务场景里反复打磨围绕提示设计总结出6个能真正提升Agent落地成功率的技巧。这篇文章不谈空泛概念全部是可以在实际项目里直接套用的思路和模板。1. 公共服务场景下Agentic AI的特殊性为什么通用技巧总翻车先说清楚一个很多团队容易忽视的点服务类Agent和通用聊天助手完全是两种物种。通用聊天助手追求的是“答得多”而公共服务Agent追求的是“答得准且不越权”。这一字之差提示词的设计逻辑就完全不同。1.1 演示顺利、上线翻车的三个真实现场我参与过的模拟项目X初期接入某政务服务中心的在线咨询窗口。测试阶段大家用的都是精心构造的“标准问法”比如“失业金申领需要什么材料”。Agent回答得干净利落领导很满意。上线第一天真实用户提问是这样的“我户口在A区工作在B区社保交在C区失业金到底找哪个区领”“上个月刚被裁公司欠了两个月工资我还算不算失业”“我父母不会用手机能不能帮我爸妈问”Agent立刻开始暴露问题要么把跨区政策张冠李戴要么在“欠薪是否影响失业身份”这种法律交叉问题上自行发挥要么干脆答非所问地推荐了一堆不相干的事项。第二个现场同样典型。某街道便民服务号接入Agent后用户问“办居住证要多久”Agent能答。但用户紧跟着一句“你们这个流程太麻烦了能不能加快”Agent居然回答“您可以向上级部门投诉”这类带有评价性质的内容。在公共服务里Agent绝对不能对政策或者流程做主观评价哪怕用户诱导也不行。第三个现场是热线场景。用户一口气问五个问题Agent只回答了第一个后面四个被它在内部规划时悄悄丢掉了。这在对话式Agent里尤其常见——模型为了把单轮回答做得“完整”会主动忽略难以并行处理的多重诉求。1.2 提示工程架构师的两种角色冲突这三个现场揭示了一个核心矛盾提示工程架构师在公共服务AI项目里实际身兼两职。一个是“翻译官”把业务部门千奇百怪的政策文件翻译成模型能执行的结构化指令另一个是“安全阀”随时准备拦截模型在边界之外的行为冲动。前者要求深度理解业务流程后者要求预判模型的错误倾向。而绝大多数团队失败是因为只做了翻译官忽视了安全阀的职能。我自己在项目里最常被问的一句话是“明明模型能力已经很强了为什么还需要你写这么多提示词”我的回答一般是模型能力决定上限提示词决定下限。公共服务场景不允许频繁触碰下限因为每翻车一次背后都是一个真实用户的服务体验损失。1.3 Agentic AI落地的核心命题是“信任”公共服务AI是否被接受不取决于模型能通过多难的评测集而取决于窗口工作人员和用户是否愿意把Agent当回事。信任一旦被一次离谱回答击碎就很难重建。因此提示词设计的终极目标不是“让模型更聪明”而是“让模型更可靠”。这种可靠体现在三层响应是否符合事实准确性、行为是否在授权范围内合规性、以及当它不确定时能否诚实表达透明度。接下来的6个技巧就是围绕这三层逐一展开的。2. 技巧一把角色边界写进系统提示而不是靠微调兜底公共服务Agent最容易翻车的地方不是知识不够而是角色不清。模型一旦没有明确的“能做什么、不能做什么”的界限就会在对话中自行“发挥”。很多团队对此的第一反应是上微调但微调周期长、成本高而且只能缓解部分症状。真正性价比最高的第一步是把边界条件严丝合缝地写进提示词。2.1 角色设定的三段式结构我给公共服务Agent设计角色提示时坚持三段式你是谁、你服务谁、你被禁止做什么。这三段缺一不可而且顺序不能颠倒。第一段“你是谁”交代Agent的身份定位这里要刻意避免抽象化描述。不要写“你是智能客服助手”而要写“你是某政务服务中心在线咨询窗口的办事引导员负责解答办事条件、所需材料、办理时限、收费标准等流程类问题”。第二段“服务谁”明确服务对象是办事群众而不是领导、不是后台审批人员。这决定了语言的通俗程度和信息颗粒度。面向办事群众的回答要口语化、步骤化、可操作而不是引用条文原文。第三段“禁止做什么”这是公共服务场景的命门。我的做法是把常见的越界行为逐条列出来比如“不得对政策优劣做出评价”、“不得承诺办理时限之外的加急结果”、“不得使用确定性语气描述尚未公布的调整信息”。2.2 为什么“禁止列表”比“允许列表”更有效早期我在某个社保咨询Agent中试图枚举Agent“可以回答”的所有问题类型结果发现枚举根本做不完——成千上万个政策细节怎么可能列得尽后来我调整思路反向枚举“禁止做的事”并把每个禁止项和背后的理由绑定。例如“不得推测审批人员的主观判断。理由实际审批中存在裁量空间Agent的推测会造成误导。”“不得建议用户通过非公开渠道反映诉求。理由不符合服务流程规范。”“不得替用户填写表格内容。理由用户信息只能由本人确认后提交。”绑定理由很关键。单纯写“禁止推测”是个空壳模型不知道为什么不许写上理由之后模型在面对相似场景时能做更稳妥的语义迁移。这就是“为了什么而禁止”比“禁止什么”更有约束力的原因。2.3 实操示例某便民窗口Agent的角色提示片段以下是我在模拟项目X中实际使用的角色提示做了脱敏处理。它的特点是每条规范都附加了“为什么”方便模型真正理解边界存在的意义你正在为“XX区便民服务中心线上咨询窗口”提供自动应答服务。 你的用户是前来办事的普通群众他们可能对政务流程不熟悉你需要用简洁、通俗、分步骤的方式说明办理流程。 服务原则 1. 只依据知识库中已有的政策文件和办事指南作答不自行推理政策倾向。 2. 涉及具体个人数据的业务如补办证件、修改信息引导用户到线下窗口或官方线上申办入口办理不得尝试代填。 3. 如果用户情绪激动或表达不满先共情、后引导不使用“您消消气”等居高临下的语气。 4. 如果问题超出你的知识范围明确回答“暂时无法确认”并建议用户拨打咨询电话进一步确认严禁编造答案。 禁止事项 - 不得评价政策、流程或工作人员的是非优劣。理由你没有立场做价值判断。 - 不得告知用户“找关系”“越级反映”等非正式途径。理由信息必须来自正式渠道。 - 不得承诺“一定能办成”“肯定没问题”。理由最终结果取决于审批环节。有了这个层面的约束模型回答的稳定性会有一个质的提升。这里有个小提醒不要把这些规范直接贴在用户可见的位置那是给模型看的不是给用户读的。2.4 我踩过的坑全量角色提示出现的“机械感”曾有一版提示词把所有边界都写得很细结果Agent回答任何问题都像在背台词连最简单的“营业时间是几点”都要先说一遍“根据相关政策文件”。原因在于我在系统提示里过度强调“政策依据”模型每句回答都试图引用一遍。这是边界与自然表达之间的平衡问题。我最后的处理手法是额外加一条“除非涉及具体条件或时限否则不要重复提及‘根据政策文件’这一来源只有在回答包含争议性或因人而异的内容时才须说明依据”。这样既保住了可靠性也挽救了对话体验。3. 技巧二给Agent装上“自我检查清单”让它在回答前先过一遍卡点第二类常见故障是Agent把原本用于“生成文本”的能力错误地用于“生成事实”。尤其在公共服务领域一段看似流畅的回答里可能藏着三处事实性错误。既然是“链式思考”的Agent我们完全可以在它的思考链路中插入强制检查环节。3.1 检查清单在提示词中的具体形态传统做法是在提示词末尾加一句“请确保回答准确”。这种话基本无效因为它太模糊。真正的自我检查清单必须具体到“检查哪些项”并落实到步骤里。我在提示词中常给Agent内置这样一段思考指令在你给出最终回答之前请按如下清单逐一自查并将自查结果写到草稿区不展示给用户 1. 这个回答涉及的政策依据是否能在本知识库中找到对应原文如果找不到标注“存疑”。 2. 回答中是否包含“可能”“也许”之外的猜测性表述如有删除或改为“以窗口答复为准”。 3. 是否存在把A区政策套用到B区情形的风险特别注意户口、社保、工作地跨区情况。 4. 是否有直接打印“不能办”“不行”而没有给出替代路径的表述如有补充办不成时的下一步操作。 5. 是否包含了具体的时间承诺、费用承诺、结果承诺如有核实承诺是否有据可依。这五条清单看起来简单但内部逻辑是经过设计的第一条管事实第二条管语气第三条管应用场景第四条管服务体验第五条管法律风险。一条清单同时覆盖五个维度比让模型“认真一点”有效得多。3.2 让模型在草稿区“自我审讯”一种低成本的推理矫正许多服务Agent框架是支持“先规划再回答”的比如ReAct模式中模型会先生成Thought再生成Action。我们要做的就是把上面的排查清单嵌入Thought阶段。我常把这个过程称作“自我审讯”因为它不是单纯检查措辞而是模拟一个审查员对Agent生成的回答逐条发起质疑。例如针对“户口在A区能不能在B区办身份证”这个问题模型在草稿区的自查就应当触发第3条规则核对知识库中“异地办理”的条件是否齐全若信息不足则应改为“需要进一步确认您是否符合异地办理条件”而不是直接拍板。3.3 实测效果错误拦截率提升的对照我在某社区事务受理咨询项目里做过一组对比实验。同一套知识库、同一个基座模型唯一区别是一组加了上述自查清单另一组不加。用200条人工构造的高难度问题做测试涉及跨区、例外情形、模糊表述等结果如下指标无自查清单有自查清单事实性错误率14.5%6.0%越权承诺类回答7.5%1.5%主动承认无法回答的比例8.0%27.5%用户满意度模拟评分1-53.44.2数据能说明一些问题。尤其是“主动承认无法回答的比例”这一栏有自查清单后大幅上升。这恰恰是公共服务AI最需要的品质——知道自己不知道并把这个状态清楚地传递给用户。3.4 防坑提醒自查清单不要超过五条我试过加到八条、十条效果反而变差。原因有两点一是模型在长上下文中会逐渐“稀释”对靠后指令的关注度清单过长后半段形同虚设二是草稿阶段的计算开销增长明显响应延迟从原来的1.2秒拉到2.5秒用户体感上会觉得Ant在“思考人生”。控制在五条以内是我反复测试后得到的“甜点区间”。真要加第六项就该考虑把它合并到前五项中的某一条去而不是简单堆叠。4. 技巧三用“示例库”喂出稳定的行为模式而不是靠描述指挥提示工程里最容易被低估的工具是少量示例。公共服务业务往往是长尾分布高频问题可能只有几十个但长尾问题有上千种变体。描述性指令管住主干示例则负责给模型“打样”让它知道长尾场景具体该怎么应对。4.1 为什么公共服务Agent特别需要示例“打样”政务服务语言和日常语言之间有一道隐形的鸿沟。用户说“我老公的社保卡丢了还能报销吗”这句话的潜台词可能是“我以家属身份代办社保卡挂失期间看病能否走手工报销”。模型如果没有见过类似的问法转换很容易只针对字面意思作答——建议补办社保卡却漏掉了关键的手工报销指引。追根溯源问题在于模型把“社保卡丢失”和“社保卡挂失期间报销”视为两个无关主题而示例的作用就是建立这类“表面表述”与“真实意图”之间的映射。你不需要写一万个示例通常只需要在每个高风险主题下准备三到五组“用户口语问法 标准服务应答”就能明显改善。4.2 示例的三种类型正向、反向和边界我提示工程里的示例库通常分三类正向示例是“遇到这种情形应当这样回答”展示的是标准服务动作。例如用户问“办理公积金贷款账户余额不够能不能贷”示例回答应包含“贷款额度与账户余额相关具体可贷额度需结合月缴存额、缴存时长等因素测算您可以使用官方测算工具进行估算”。反向示例是“禁止出现的回答”。例如用户问“你们周末上班吗”模型绝不能回答“建议您工作日再来咨询”因为窗口有延时服务。反向示例的价值在于做“语义刹车”直接告诉模型这里是误区。边界示例最微妙它展示的是“部分对、部分不对”的场景。比如“新生儿出生后多久可以参保”这类有明确时限的问题模型回答时要给出时限范围但不得在这个时限之外做延伸判断。边界示例能有效防止模型把规则绝对化。4.3 示例在提示词中的排版与权重技巧我在书写示例时有一条不成文的规范正向示例放最前反向示例紧跟其后边界示例放最后每组示例前用一行说明它的意图。注意一个细节示例不是越多越好但要保证“图文并茂”。一条好的示例应当包含“用户提问”“模型回答”“回答依据”三部分。如果你只给问答对模型学到的可能只是表面的语言组织方式补上“回答依据”模型才能真正理解为什么要这么答。以下是我常用的模板【用户提问】 “现在还能办独生子女证吗我孩子都10岁了。” 【回答依据】 知识库条目关于独生子女证的历史政策说明。该证件已停止新办但可申领相关补助或证明。 【标准回答】 “目前该证件已不再新办。如果您的孩子已满10岁且符合条件可以申领‘独生子女父母奖励费’或开具相关证明具体材料请以窗口告知为准。” 【解释为什么这样回答】 如果只答“不能办”用户体验很差需要同时给出替代路径才符合“办事有出口”的服务原则。这种带注释的示例相当于同时给模型做了“动作示范”和“动作解析”比给一二十条干巴巴的问答对学习效率更高。4.4 避坑示例与知识库的一致性检查我踩过一个具体坑某次我在示例里写了某个业务材料清单但知识库里实际要求的是另一份材料。模型学习示例之后回答得非常流畅但事实是错的。这属于典型的“示例污染”。因此现在我对示例库有一条硬性要求每一条示例必须先跑一遍知识库一致性校验。简单操作就是拿示例里的关键实体材料名、时限、条件去知识库里逐个检索有对不上的立刻改掉。这个校验一步不能省因为它动辄影响Agent在核心问题上的正确率。5. 技巧四把“不知道”设计成一种有路可走的回答公共服务AI最怕的不是说“不知道”而是打死不承认不知道。客服场景尤其如此——群众问的问题一旦超出知识库模型为了维持“全能形象”就会生硬地编造信息。在普通闲聊场景这也许无伤大雅在办事咨询场景里就是事故。5.1 “不知道”也要有服务温度我见过很多Agent的“拒答话术”是冷冰冰的“抱歉我暂时无法回答您的问题”。这个话术的问题在于它提供了零信息量。一个人跑到线上窗口问问题得到一个“无法回答”就走等于这个渠道没有产生任何服务价值。所以我设计的不确定回答遵循“三件套”结构先说明当前无法给出确切答复的原因是知识库缺失、信息不完整还是需要人工判断再给出用户下一步可以做的具体动作拨打哪个电话、去哪个窗口、准备哪些材料最后补充提问“您是否需要我帮您查询相关事项的办事指南”。这个结构的核心是让“失败”的回答依然保留服务出口不让用户在Agent这里走入死胡同。5.2 把“置信度自评”写进提示词要让模型诚实地承认“不知道”必须从提示词层面授予它“承认不知道的权限”。很多模型之所以强行作答是因为它被训练的默认行为是“尽可能帮用户”。我们要主动纠正这种倾向。我会在系统提示中写入如果你对问题涉及的办事条件、材料或时限没有把握禁止猜测。你必须使用以下句式 “关于这个问题我目前掌握的信息还不足以给出准确答复。为避免误导建议您拨打XX电话工作时间9:00-17:00或到XX窗口现场咨询。您可以先参考我们已公开的办事指南[链接]。” 当你对回答有信心时不受此句式限制可以正常作答。关键在于要给模型一个“可以正常作答”的豁免通道。如果没有这个豁免模型会过度保守连简单问题都用拒答模板。置信度自评的精髓是“区分确定与不确定并为不确定保留体面的退路”。5.3 多轮对话中的“不知道”管理有一个很微妙的情况用户先问“提取公积金需要什么材料”Agent答了用户接着问“如果我是外地户口离职后多久能全额提取”Agent其实不知道“全额”具体指什么——政策里只有“提取金额以账户实际余额为准”的说法。这时Agent如果直接否认自己刚才的回答“不全”会破坏对话信任。我在多轮对话处理中的一个有效设计是允许Agent在转人工之前补一句“刚才提到的是常规情况针对您说的外地户籍离职提取可能有额外限制我需要帮您核实后再答复”然后再触发转人工或知识库二次检索。这比直接说“我刚才漏了一条”要自然得多。5.4 实际的转人工兜底策略公共服务场景不接受“Agent永远在线”的执念。换句话说转人工不是失败而是主动的服务分级。我在提示词里专门设计过触发转人工的条件当用户连续两次追问同一个不确定点、当用户情绪明显升级、当用户明确要求“找人工”这三种情况必须触发转人工。同时我要求Agent在触发转人工时把当前对话的要点自动整理成一段结构化摘要用户问了什么、Agent已给出哪些信息、还缺什么这样人工坐席接入后不需要让用户重复叙述。提示词中有一句专门针对这个需求“在转人工的瞬间你需要在内部记录中列出用户的原始问题、你最后一次给出的回答、以及你尚未确认的信息。”这一步让转人工不再是冷冰冰的“正在为您转接”而是真正的有温度交接。6. 技巧五让Agent学会“主动追问”别让用户在模糊问题上做选择题公共服务咨询的另一个高频翻车点是用户在信息不全的情况下对Agent发问而Agent直接基于不完整的信息给出了答案。比如“办退休要什么材料”——这里的“办退休”至少分“企业职工正常退休”“灵活就业人员退休”“特殊工种提前退休”等多种情形材料完全不同。如果Agent直接拉一个通用清单出来用户照着准备到了窗口大概率缺材料。6.1 问题澄清的目的不是为难用户而是减少往返主动追问有两个目的一个是检察信息缺口另一个是控制对话轮次。好的追问应当让用户在“最多一到两次”的补充说明后就能得到完整解答。如果追问变得冗长繁琐用户会烦躁。我在提示词中设计追问逻辑的时候用的是“最小信息集”的思维先识别当前问题最关键的区分维度是哪个只围绕这个维度发起追问。例如“办退休”的关键区分维度是参保类型和退休类别“社保转移”的关键区分维度是转入地和转出地“居住证办理”的区分维度是“本人居住”还是“家庭居住”。6.2 区分“确定性追问”和“发散性追问”我按追问的确定性程度把问题分成两类。确定性追问是指选项明确、用户只需选择题型的例如“您属于以下哪类参保人员1. 企业职工 2. 灵活就业人员 3. 机关事业单位人员”。发散性追问是指需要用户自由描述的例如“您能简单描述一下您和申请人的关系吗”。提示词训练中我倾向于把所有追问尽量设计成确定性选择题因为这样既能降低用户的回答成本又能保证信息落到模型可处理的范畴。只有在确定性追问无法覆盖场景时才使用发散性追问。6.3 追问在提示词中的逻辑实现我在任务指令中一般会给出类似这样的规则块判断用户的提问是否信息充分 - 如果缺少回答所需的必要条件例如办理地点、申请人身份、业务类型必须先追问不得直接作答。 - 追问时每次最多只能问一个问题优先问最关键的一个。 - 当只差一个条件即可回答时使用如下句式“您的问题我可以解答不过需要先确认一下________”。 - 当缺少多个条件时先问区分度最高的那个答完再问下一个不要一次性抛出一串问题。“每次最多只能问一个问题”这条是我反复加粗强调的。模型如果不加限制很容易生成“请提供A、B、C、D四项信息”用户一看要提供四个信息直接流失。而一次问一个虽然对话轮次变多但完成率反而更高。6.4 追问的边界不要审问用户公共服务场景对“被审问感”特别敏感。用户会觉得我明明只是问个办事流程你怎么反过来问我这么多。所以我设计追问话术时会频繁使用“先给答案、再确认条件”的软性结构。比如用户问“我能不能申请公租房”Agent不说“需要确认您的收入、社保、户口情况”而是先说“公租房申请需要同时满足收入、社保和户籍方面的条件为了帮您判断是否符合可以先告诉我您的户籍所在地吗”这样既给用户信息又引导用户补充关键条件不让人感觉被审问。7. 技巧六为Agent设计“回复后校验”让每一次回答都自动过一遍安全网前五个技巧集中在“生成前”的控制最后一个技巧则是“生成后”的校验。Agent式AI有一个别人容易忽略的操作细节模型在输出之前其实还可以对已经生成的内容做一次内部复核。提示词工程完全可以强制启用这个环节。7.1 二次校验提示的具体设计我在Post-processing环节加入一段“回答自检”指令让它对已经生成的回复进行逐项复查。注意这一步和技巧二中的“自查清单”有区别自查清单发生在思考阶段作用于回答生成之前二次校验发生在文本生成之后是对最终输出文本的“终审”。二者配合一次管逻辑一次管表达。二次校验提示模板如下请对刚刚生成的最终回复执行以下终审 1. 是否存在“肯定能”“一定可以”等绝对化承诺词汇如有替换为“以最终审核结果为准”。 2. 是否出现未在知识库中直接支持的数据或条款如有直接删除。 3. 是否包含了最多三条以上的连续建议如有压缩为最核心的两条。 4. 回答长度是否超过250字如是精简为三个自然段以内。 5. 是否回答了用户原始问题中的每一个诉求点检查是否有遗漏。这里我还会加一条隐藏的防幻觉策略让模型在回答末尾追加一个机器可读的“置信度标签”这个标签不展示给用户只在日志中记录。比如在回复结尾追加一行“CONF:[high/medium/low]”如果你的回答完全依据知识库原文且无推测则标记high若含有基于政策的归纳演绎标记medium若存在无法确认的内容但并未回避标记low。这个置信度标签是我做后续数据分析和提示词迭代的重要依据。7.2 代码实现中的提示词承载方式二次校验既可以在模型内部完成也可以用代码控制。如果用的是支持多轮调用的Agent框架我习惯把校验放到外层代码中用第二个LLM调用只负责“审查第一个LLM的输出”。这种方式比在同一个上下文里让模型“自己审自己”更干净因为自审会受到第一遍生成时的思维惯性影响换成独立的审查调用更容易看出问题。外层校验提示可以写得很轻量你是一名服务质量审查员。以下是系统对用户问题的回答请从事实准确性、完整性、合规性三个维度审查输出“通过”或“不通过”不通过时附一句原因不要修改回答。只有当审查判断为不通过时才会进入重写流程由原Agent根据审查意见重新生成一版。这一套流程执行下来虽然会增加约10%到20%的延迟但在公共服务场景里这0.5到1秒的代价换来的可靠度提升是完全值得的。7.3 二次校验的“成本边界”第二校验也不是越重越好。我在多次测试后发现并非所有请求都需要走“生成-审查-重生成”的完整链路。更轻量有效的做法是先让原Agent在生成时附带置信度标签只有置信度标为medium或low的回答才触发第二轮独立审查high置信度的回答直接放行。这样能把平均延迟增加控制在5%以内同时把高风险回答的拦截率拉到50%以上。7.4 实操中的一个意外收益一个意外发现是二次校验环节不仅拦截了错误还显著改善了回答的“官僚气”。审查模型往往会指出“回答过于官方、冗长”于是重写版本更加口语化。有一次用户问“我是外地人在上海租房能办居住证吗”第一次生成的回答里叠加了大量政策条文引用措辞非常拗口。审查模型给出的理由是“信息准确但用户难以快速理解”重写后的回答变成“凭房屋租赁合同备案和本人身份证就可以申请。您需要先让房东配合完成租赁备案再带着材料去居住地所属的社区事务受理中心办理。”同样的信息表达方式完全不同。经过这一层Agent的亲和度和准确度双双提升。8. 六个技巧如何组合使用一条可落地的提示词架构流水线单点技巧讲完了但很多读者可能会困惑这些技巧到底是全塞进一个系统提示词就够了还是要分散到不同环节这节我给出一个整体组合的建议顺序和结构。8.1 从需求分析到提示词成稿的流程在实际操作中我搭建一个公共服务Agent的提示词遵循五步流水线第一步业务勘察和窗口工作人员、业务骨干聊收集高频问题和长尾问题形成知识库条目。第二步分类定级把问题清单按“简单查询/流程引导/多条件判断/需人工介入”四类划分。第三步角色提示初稿生成包含边界、服务对象和禁止事项的系统提示。第四步示例注入为每个问题类别配置三到五组带解释的示例并做知识库一致性校验。第五步叠加二次校验配置自查清单、置信度标签和独立审查逻辑。这里有一个常见误区试图在一轮对话里同时完成所有事情。这会导致提示词上下文极度膨胀模型处理不过来后面的指令被“掩埋”。我处理的原则是“分层安置”把永久性规则放在系统提示中把参考示例放在少样本槽位中把每次对话特有的限制放在用户消息前缀中。8.2 一条推荐的整体提示词骨架这里给出一条可复用的整体结构按顺序组合各模块[系统提示层] - 角色与边界技巧一 - 服务原则与禁止事项技巧一 - 不确定时的拒答模板技巧四 - 追问策略技巧五 [少样本示例层] - 正向示例3-5条 - 反向示例2-3条 - 边界示例1-2条技巧三 - 每条示例均带解释性注释 [交互前注入层] - 本次对话的上下文摘要如有 - 用户当前诉求的一级分类标签 [生成控制层] - 求助自查清单技巧二 - 置信度标签要求技巧四/六 [输出处理层] - 二次校验规则技巧六 - 转人工触发条件与摘要交接话术技巧四这个骨架里我特别强调“不要试图在一个提示词里完成所有事”要根据你的Agent框架能力把不同模块拆到不同调用阶段让每一层只承担一种职责。如此既方便调试也便于后续逐层优化。8.3 测试与迭代方法论提示词设计完成后离“见效”还有一段路。我的测试方法论是先洗一批真实历史咨询记录作为评测集这批数据要保留原始问法决不能人工修改成“规整问法”。然后按五个维度打分事实准确率、漏答率用户问两个点只答一个、拒绝率该答不答、越界率不该答却答了、体验分模拟用户主观评价。迭代方式上不要一上来就改一大堆提示词。每轮只动一个变量。例如这轮加了转人工条件下轮再调追问数量避免多个变量纠缠在一起分不清是谁起的作用。改完之后必须用小批量回归测试验证没有在别的场景引入新问题——公共服务Agent最怕“按了葫芦起了瓢”。9. 写在最后提示工程架构师在公共服务AI项目里的真正职责做了这么多项目我越来越确认一件事提示工程架构师的核心价值不是“写词”而是“设计决策规则”。公共服务AI能不能落地本质上是能不能把业务规则、边界条件、风险容忍度这些散落在人脑里的经验转译成一套模型可以稳定执行的决策框架。我也见过不少团队在提示词上花了很大力气但最后项目还是失败了。原因大多不在技巧本身而在组织协同业务部门只把需求丢过来就不闻不问技术部门把Agent当成纯算法问题提示词阶段已经太晚。所以如果你正要在团队里推动类似的公共服务Agent项目我建议从第一天就把“提示词评审”纳入需求流程让业务骨干在写提示词之前就参与到边界规则的定义里而不是等项目上线了再回来补课。六条技巧可以帮你解决“模型层面”的稳定性但真正决定一个公共服务AI能否长期运转的是你有没有把它当作一个持续运营的服务来对待。投票时我会建议在每次迭代上线前后把Agent的历史回答抽样返回给一线窗口人员抽查哪怕只是一周抽五十条都能发现很多坐在办公室里永远发现不了的问题。最后分享一个我在项目里一直在执行的细节每个版本的提示词都要留一份“变更记录”。标注什么日期、谁改了什么规则、为什么改。公共服务项目往往人员流动频繁如果提示词的演进过程没有留痕后来接手的人会把之前踩过的坑重新踩一遍。把提示词当成代码来维护把它每一次演变背后的业务原因写清楚这大概是我能给出的最朴素、也最有用的建议。
阅读完成 · 觉得有帮助？
