把业务规则翻译成指令

一句话理解：需要判断的规则写进 Prompt，必须百分之百执行的规则交给程序；最重要的规则两边都要有：Prompt 让 Agent 理解并按规则行事，程序保证即使 Agent 出错，规则也不会被突破。

产品经理拿到的业务规则，通常散落在 SOP 文档、运营群聊、资深员工的脑子里。把这些规则“喂”给 Agent 时，最常见的做法是整段复制进系统提示词。结果往往是两种失败：一是规则写进去了，模型却在某个 5% 的情况下没遵守，而这 5% 恰好是一笔错误退款；二是规则写得太多太细，指令变得冗长矛盾，模型在真正需要判断的地方反而表现变差。

这一课给出一套方法：先给规则分类，再决定每条规则放在哪里、用什么方式写。

规则的两个维度

把每条业务规则放到两个维度上看：

• 确定性：这条规则能否写成明确的条件和结果？还是需要理解语义、结合上下文判断？
• 违反的代价：一旦被违反，是轻微的体验问题，还是资金、合规、安全问题？

这张图给出了四个象限的默认放法。关键原则只有一条：不要让模型独自承担“确定且高风险”的规则。

规则的六个去处

规则不只有“写进 Prompt”和“写成代码”两种去处。完整的选项如下：

去处	适合的规则	客服退款 Agent 的例子
指令（Prompt）	需要理解和判断的规则、做事的原则、沟通规范	结论必须有证据；数据不足时说明缺少什么
工具设计	“能不能做”这件事本身	不提供划款工具，Agent 就只能提交待审批的退款申请
程序校验	可以写成条件的硬约束、计算、格式与一致性	输出的订单号必须等于输入；退款金额不得超过可退余额
权限与审批	谁可以做、做之前需要谁同意	退款申请需主管审批后才能执行
Skill 与知识库	篇幅长、按场景使用、经常更新的方法和标准	各类退款场景的详细处置 SOP、类目适用范围说明
评测	验证规则是否真的被遵守	每条关键规则至少有 2 个对应的测试用例

工具设计是最常被忽略、也最有效的一种：最可靠的“禁止”，是根本不给能力。 详见 安全的工具设计。

把六个去处按作用归类，可以看得更清楚：

一份 SOP 的翻译示例

假设运营团队给出的「退款申请处理 SOP」原文是：

1. 订单签收超过 7 天的无理由退款申请，不予受理。
2. 优先查看该订单是否已经发生过部分退款。
3. VIP 客户的退款申请要优先处理。
4. 退款金额超过 500 元，需要主管确认后才能给客户答复退款事宜。
5. 不要向客户承诺退款到账时间。
6. 如果客户情绪激动，先安抚再说明情况。
7. 同一客户 30 天内第 3 次申请退款，按疑似异常订单流程处理。
8. 对外话术不得提及第三方服务商的名称。

逐条分析去处：

规则	类型	放在哪里	怎么落地
1. 签收超 7 天不受理	确定、中风险	程序 + 指令	程序计算签收后天数并作为字段传入；指令说明这个定义，便于模型解释
2. 优先查已退金额	流程判断	指令	写进流程步骤，并说明原因（漏掉已退金额会造成重复退款）
3. VIP 优先处理	定义不清	先澄清，再决定	“优先”指排队顺序、响应时限还是退款比例？排队顺序应由工单系统实现，不是 Agent 的事
4. 金额 > 500 元需主管确认	确定、高风险	程序 + 审批 + 指令	程序判断金额并强制 need_human_review = true；指令让模型在话术中不提退款结果
5. 不承诺到账时间	需判断、中风险	指令 + 程序抽检	指令写明原因与替代表述；程序检查话术中是否出现日期与“保证”类词语
6. 先安抚再说明	需判断、低风险	指令 + 示例	用 示例 演示语气
7. 30 天内第 3 次申请	确定、高风险	程序 + 指令	程序识别并切换到异常订单流程；指令说明该情况下需转人工
8. 不提第三方服务商名称	确定、中风险	程序 + 指令	程序用服务商名单过滤话术；指令同步说明

从这个例子可以看到三件事：

• 大部分高风险规则是“双重实现”的。 程序保证执行，指令让模型理解规则，从而在解释、话术和相关判断上表现正确。只写程序不写指令，模型会产出被程序反复拦截的结果；只写指令不写程序，规则就只是“大概率被遵守”。
• 翻译过程会暴露 SOP 本身的问题。 第 3 条“VIP 优先”对人来说似乎不言自明，对系统来说却完全无法执行。把规则写给 Agent，是一次绝佳的业务梳理机会，这正是产品经理的价值所在。
• 有些规则根本不属于 Agent。 排队顺序、工单分配是系统的职责，不要塞进 Agent 的指令里。

把规则写进指令的方法

确定要写进指令的规则，按下面的要求改写：

1. 条件明确。 用“当……时，……；否则……”的结构，把触发条件写成可判断的形式。

不好：遇到严重的情况要转人工。
更好：当退款金额超过 500 元、该订单已退款 2 次以上，或客户提到投诉升级、媒体、诉讼时，
      将 need_human_review 设为 true，并在 escalation_reason 中写明触发的条件。

2. 术语有定义。 “已退金额”“质量问题”“VIP”在业务中可能有多种理解，在指令或背景中给出定义。

3. 附上原因。 原因让模型能把规则推广到没有写到的情况。

不要在话术中提及第三方服务商的名称。
原因：与客户签约的责任方是我司，提及第三方服务商会引发责任归属的误解。
如果需要说明卡在哪个环节，使用“仓库处理环节”“支付渠道处理环节”等描述。

4. 说明例外与优先级。 两条规则可能冲突时，写清楚谁优先，例如“安抚客户时，也不能承诺到账时间”。

5. 把会变的数值放到指令外面。 500 元、7 天、3 次这类阈值，最好由程序计算后作为输入字段传给模型（例如 days_since_delivery: 9、over_amount_threshold: true），而不是让模型自己比较。这样阈值调整时只改配置，不需要修改和重新测试指令。

常见误区

• “规则写得越细，模型越听话。” 过细的规则会让指令冗长、互相冲突，模型在需要判断的地方反而表现变差。确定性的细节交给程序。
• “规则写进 Prompt 就算落地了。” 对高风险规则来说，Prompt 只是提高遵守概率。没有程序兜底，就要接受它在某个比例上被违反。
• “把 SOP 原文整段复制进去最保险。” 人写给人看的 SOP 充满默认前提和模糊表述，直接复制会把歧义一起带给模型。需要逐条翻译和澄清。

产品经理检查清单

• 业务规则是否已经逐条列出，并标注了确定性和违反代价？
• 每条高风险规则是否都有程序、工具或审批层面的保障？
• 翻译过程中发现的模糊规则，是否已和业务方澄清？
• 写进指令的规则，是否条件明确、术语有定义、附有原因？
• 阈值和数值是否由程序计算并传入，而不是让模型比较？
• 每条关键规则是否有对应的测试用例，验证它真的被遵守？

练习

翻译一份真实的业务规则（约 60 分钟）：

1. 找一份你所在业务的 SOP 或规则文档（或使用本课的退款申请处理 SOP，再补充 5 条你能想到的规则）。
2. 按本课的表格，为每条规则标注类型、去处和落地方式。
3. 找出至少 2 条定义不清的规则，写下你要问业务方的澄清问题。
4. 把需要写进指令的规则，按“条件明确 + 附原因”的要求改写成指令片段。

下一步

规则确定之后，还要约定 Agent 的交付物长什么样，让下游系统能够可靠地消费。下一课「输出契约」讲格式、字段与异常状态的约定。