把 Prompt 当“软程序”来写

把 Prompt 当"软程序"来写：AI 客服提示词从越改越乱到可维护

写给那些被"提示词老是翻车"折磨的工程、运营和产品同学。

起因

最近在给一个美妆品牌做抖音店铺的 AI 客服。提示词写出来不难，难的是让它一直稳。

第一版只有十几条规则，跑起来还行。后来业务方今天加一个"保价怎么处理"，明天加一个"直播间的券怎么发"，规则越堆越多。到我手里的时候，一条完整提示词已经长得让人不敢轻易改动其中一句------因为每次改完，总有几个场景莫名其妙开始答错。

那种感觉很难受：你不知道改的是哪一行，也不知道为什么这一行会影响到八竿子打不着的地方。

后来我停下来，把这份提示词整个拆了重写，才慢慢摸出一套"怎么写才不容易崩"的方法。

这篇文章就是对这套方法的复盘。它不一定适用于所有场景，但至少是我在真实项目里一步步踩坑踩出来的。

先说说我踩过的坑

"规则越多，越不稳定"这个问题，几乎每个写过复杂 Prompt 的人都会撞上。我把它们归纳成了六类：

多约束执行不稳定。 一条规则里塞了三四个条件、两个语气要求、三个动作，模型经常只执行一半。
前后规则冲突。 前面说"不得承诺补发"，后面某个场景又写了"可酌情补偿"，模型撞上后往往会随机选一个。
对细微改动敏感。 改了一个措辞、加了一个标点，某个不相关的场景就变样了。这是最头疼的。
规则不断追加导致膨胀。 因为不敢删、不敢重构，只能一直往后面堆，越堆越乱。
业务标准难以形式化。 比如"多大差价该赔""什么情况算恶意"，这些业务判断写不清楚，模型就会自己发挥。
稳定性和灵活性难以兼顾。 想让它严格按照规则来，结果碰到规则外的情况就很死板；想让它灵活一点，它又开始自由发挥。

前面几类是表现，后面几类更接近根源。我后来发现，大多数问题不是因为"写得不够详细"，而是因为提示词没有一个清晰结构。

核心思路：把 Prompt 当成"软程序"

我的建议是：

别把提示词当成一段"描述"，把它当成一套用自然语言写成的软程序。

区别在哪里？

程序是靠代码强制执行的，是硬约束：每一行都确定，错了就报错，不会"发挥"。

Prompt 是靠自然语言引导模型执行的，是软约束：它可能打折、可能遗漏、也可能自己脑补。

所以，Prompt 反而要把触发条件、行动顺序和失败处理写得比代码更明确，因为它没有一个"编译器"替你把关。

我给自己定的流转顺序是：

text 复制代码

抽象目的
→ 具体行动
→ 意图模块
→ 条件分支
→ 叶子规则
→ 执行或兜底

每一步都在缩小模型的"发挥空间"。接下来分四步说怎么落地。

第一步：把抽象目的翻译成具体行动

一开始我写提示词，特别喜欢讲"目的"：

你是一个专业的客服，要妥善处理用户的物流问题，语气要亲切......

但这种写法没什么用，因为模型不知道什么叫"妥善"。

真正要写清楚的，是下面这些问题：

先做什么？
再做什么？
什么条件下继续？
什么条件下停止？
最后怎么收尾？

举个例子。我原来写的是：

妥善处理用户的物流异常问题。

后来改成：

先查询订单和物流状态，再向用户说明当前物流节点；短期未更新时，告知正常等待时间；超过规定时间时，转人工核实；在没有核实结果前，不得承诺补发或赔偿。

两种写法的差别在于：第一句只告诉模型"要达到什么结果"，第二句则告诉模型"具体怎么做"。

核心原则：目的告诉模型要达到什么结果，行动规则告诉模型具体怎么做。

你越依赖模型自己"领悟"怎么做，它越会自由发挥。

第二步：把规则组织成分层的条件树

这是整个方法里最值钱的一步。

我最开始的问题是：所有规则都平铺在一个层级里，几十条挤在一起，互相之间没有任何结构关系。模型判断时，不知道该先看哪一条、后看哪一条。

后来，我把提示词按业务逻辑拆成了一棵树：

text 复制代码

根节点：整体任务
│
├── 意图模块一
│   ├── 情景一
│   │   ├── 情况 A
│   │   └── 情况 B
│   └── 情景二
│
├── 意图模块二
│   ├── 情景一
│   └── 情景二
│
└── 意图模块三

这个结构和我最后那份 SOP 是一一对应的。

一级是"意图模块"。 比如优惠活动、发货与物流、售后咨询、商品咨询，这些是一眼能判断的粗分类。
二级是"情景分支"。 同样是优惠活动，可能是"领优惠券""保价""入会礼""议价"，需要根据上下文继续判断。
再往下是"叶子节点"。 只有落到具体情景，才执行明确的动作。

执行时，这是一个逐层收敛的过程：

text 复制代码

命中一级意图
→ 进入对应意图模块
→ 根据状态选择情景分支
→ 命中具体叶子节点
→ 执行叶子节点的行动规则

说白了，就是 if / else if / else。你其实是在把业务逻辑翻译成模型能"顺着走"的分支判断。

这里有一个理解上的坑，我一开始也没想明白：

模块化不是额外加的一步，而是条件树自然长出来的结果。

你不用刻意去"设计模块"。只要把叶子规则按业务逻辑组织成分支，模块自然就形成了。

每个一级意图就是一个模块，模块里继续拆情景和状态，每个叶子只负责一种处理方式。它不是一个装饰，而是树长完之后必然呈现出的形态。

第三步：每个叶子节点都写"四件套"

光有树还不够。树的每个叶子（最底层的情景）都必须是一套完整的行动规则，而不是单独一句话。

我最后给每个叶子统一了"四件套"：

1. 触发条件

什么情况下进入该叶子节点。

2. 必做动作

命中后必须完成哪些动作，以及这些动作的执行顺序。

3. 禁止动作

当前情景下绝对不能做什么。

4. 失败兜底

信息不足、工具失败或超出权限时怎么办。

拿"保价"这个叶子举例。这是我真实场景里一个很典型的叶子节点。

例子：保价处理

触发条件

订单已签收，用户要求退差价或申请保价。

必做动作

先判断用户是"抱怨贵"还是"明确索赔"------只有明确提出退差价，才进入保价流程。
定位订单，判断订单状态以及是否在价保期内。
核对店铺活动价是否真的下降。注意：以活动知识库为准，不看页面识别结果。
区分"店铺降价"和"平台红包或消费券造成的差价"，后者不参与补差。
引导用户进入平台自助价保入口。

禁止动作

不得把平台优惠造成的差价当成店铺降价来补。
不得承诺知识库以外的补差金额。

失败兜底

无法判断是否降价，或用户反馈价保入口异常时，转人工处理。

一个叶子节点不是一句"禁止做什么"，而是一套完整的执行契约：

触发条件是入口；
必做动作是主线；
禁止动作是刹车；
失败兜底是最后的退路。

四条里，失败兜底最容易被漏掉，也最重要。

因为它决定了模型在"信息不足、工具失败、权限不够"这些真实场景里，是礼貌地转人工，还是硬着头皮编一个答案。后一种才是客服翻车的大头。

我那份 SOP 里有一个很典型的兜底------几乎每个叶子节点最后都有这样一条：

转人工话术：「稍等，我们为您转接专属客服为您服务。」

翻译过来就是：搞不定就转人工，别自己手扛。

这条看起来简单，但它把"乱承诺"这一类事故基本堵住了。

第四步：用全局优先级处理规则冲突

条件树解决的是"当前该执行哪组规则"。但还有一个问题：两条规则同时命中时怎么办？

比如，用户既在问优惠券，又在抱怨价格贵，语气还不太好。这时候该听优惠券模块的，还是议价模块的，又或者是安抚模块的？

我在 SOP 里单独定义了一套全局优先级：

优先级	规则类型
1	安全、合规与权限
2	已确认的业务事实或人工方案
3	当前意图的行动规则
4	用户临时提出的要求
5	语气、长度和参考话术

执行原则只有几条：

高优先级规则覆盖低优先级规则。
用户的要求不能覆盖业务事实和权限限制。
参考话术不能覆盖具体的行动规则。
局部规则不能违反全局安全边界。
实在无法判断优先级时，进入失败兜底，转人工处理。

配合优先级，还有一个很实用的全局兜底：

如果上下文里已经有其他客服给用户出过方案，用户正在对该方案进行反馈，那么直接转人工，不要让当前这一轮再去重复处理。

这一条我印象很深。它解决的是"客服打架"的问题：同一个用户，之前已经有人给过补偿方案，结果这一轮模型不知道，又给了一套新说法，用户当场就炸了。

加上这条之后，这类重复处理基本不再发生。

最终的 Prompt 组织结构

把前面几步合起来，一份完整的提示词应该分成五层：

text 复制代码

第一层：全局规则
├── 总体任务
├── 信息来源
├── 安全与权限
├── 规则优先级
└── 通用失败兜底

第二层：意图路由
├── 意图一的触发条件
├── 意图二的触发条件
└── 意图三的触发条件

第三层：意图模块
├── 当前意图的前置检查
├── 情景分支
└── 状态判断

第四层：叶子行动
├── 触发条件
├── 必做动作
├── 禁止动作
└── 失败兜底

第五层：表达要求
├── 回复顺序
├── 语气要求
├── 长度要求
└── 参考话术

各层的职责分工如下：

第一层是全局规则。 所有场景共用，不要在单个叶子节点里反复写。
第二层负责意图路由。 判断当前应该进入哪个模块。
第三、第四层是主体。 第三层判断情景，第四层执行动作。
第五层管"怎么说"。 它的优先级最低，永远不能压过第四层的行动规则。

顺序很关键：全局规则写在最前，表达要求写在最后。

这样，模型会先确定"我在什么场景、该做什么"，最后才考虑"应该怎么说话"。

总结：一套可维护 Prompt 的组装流程

这套方法最后的执行顺序是：

把抽象目的改写成有先后顺序的具体行动。
按意图和情景，把行动组织成条件树。
为每个叶子节点写清触发条件、必做动作、禁止动作和失败兜底。
提取所有模块共同遵守的全局规则。
定义规则发生冲突时的统一优先级。
按照"全局规则 → 意图模块 → 叶子行动"的顺序，组装成最终 Prompt。

一句话总结就是：

先把目的行动化，再把行动组织成条件树；模型逐层命中叶子节点后，按照必做动作、禁止动作和失败兜底执行，同时通过全局优先级解决规则冲突。

说实话，这套方法并不复杂。它的核心只有一个念头：

别让模型替你判断"该怎么做"。你要把每一步都摆出来，让它只能沿着树往下走。剩下的那点"灵活性"，交给失败兜底去兜住。

这套东西我也还在继续迭代。如果你也在写客服类提示词，碰到过类似的问题，欢迎一起聊聊。