公共服务Agent落地难？六个提示词技巧提升AI行为可控性

公共服务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条人工构造的高难度问题做测试（涉及跨区、例外情形、模糊表述等），结果如下：

数据能说明一些问题。尤其是“主动承认无法回答的比例”这一栏，有自查清单后大幅上升。这恰恰是公共服务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的历史回答抽样返回给一线窗口人员抽查，哪怕只是一周抽五十条，都能发现很多坐在办公室里永远发现不了的问题。

最后分享一个我在项目里一直在执行的细节：每个版本的提示词，都要留一份“变更记录”。标注什么日期、谁改了什么规则、为什么改。公共服务项目往往人员流动频繁，如果提示词的演进过程没有留痕，后来接手的人会把之前踩过的坑重新踩一遍。把提示词当成代码来维护，把它每一次演变背后的业务原因写清楚，这大概是我能给出的最朴素、也最有用的建议。