我给公司做AI Agent，提示词从"场景枚举"到"元原则"的实战踩坑记录
做了半年AI智能体开发，最大的教训是：你给AI背的答案越多，它在生产环境翻车越狠。
一个真实的bug，让我重新思考提示词设计
我在做供应链入库异常处理的AI Agent。有一天系统报了一个异常——仓库收到的货和采购单不一致，图片也对不上。
Agent自动联系了供应商，供应商回了一句： "本来就没有这个配件。"
然后Agent做了什么呢？它直接把这句话当成事实，结案了。理由是"供应商已确认无此配件"。
问题是：供应商说"本来就没有"，这只是他的说法，不是事实。我们采购单上写了有这个配件，仓库也拍了照片，怎么能因为对方一句话就结案？
这个bug让我意识到：我之前设计提示词的方式从根上就错了。
我最初怎么写提示词——场景枚举法
一开始我的思路很直觉：遇到一个场景，就写一条规则。
如果供应商说"已补发" → 记录补发信息，等待物流单号
如果供应商说"明天发" → 记录承诺时间，设置跟进提醒
如果供应商说"帮你问问仓库" → 标记为等待中，48小时后跟进
如果供应商说"本来就没有" → ？？？
每次测试发现新的case，我就加一条规则。提示词越写越长，从几百字膨胀到几千字。
三个痛点很快暴露出来：
第一，场景永远写不完。 供应商的表达千变万化——"给你寄一个""重新发""单号XXX""快递显示已签收"——每种说法都需要一条新规则。
第二，换个说法就懵了。 同样是"补发"的意思，"给你寄一个"和"重新发"表述不同，Agent无法识别。规则是精确匹配的，但人类语言是模糊的。
第三，规则互相冲突。 写到上百条规则的时候，改一条会影响另外三条。维护成本指数级增长。
我当时的感受是：我在用"死记硬背"的方式教AI，教得越多它越死板。
转折点：从"教答案"到"教判断方法"
我后来想明白了一个关键问题：为什么供应商说"已补发"可以推进，但说"本来就没有"不能直接结案？
表面上看是两种不同的场景，但底层其实是同一个判断维度——这句话是承诺还是声称？
- "已补发""明天发给你""单号是XXX" → 这些是承诺，供应商给出了可验证的行动
- "本来就没有""是新版的""厂家换包装了" → 这些是声称，供应商在陈述一个我们无法直接验证的"事实"
承诺型的话可以推进，因为后续可以验证（有没有物流单号、货到了没有）。声称型的话不能直接采信，因为谁主张，谁举证——供应商说"本来就没有"，他需要提供证据，我不能直接结案。
这个区分一出来，上面那些场景全部被覆盖了。 不需要一条条写规则，Agent只需要学会一个判断方法：先判断这是承诺还是声称，承诺可推进，声称要核验。
这就是我说的**"元原则"**——不是告诉AI"遇到X做Y"，而是告诉它"怎么判断X属于哪类"。
元原则的三个特征
我后来总结了一个标准，判断一个原则是不是够"元"：
第一，生成能力。 好的元原则能覆盖没见过的新场景。供应商说"快递显示已签收"——Agent没见过这种说法，但它能判断：这是一个可验证的信息，属于承诺型。不需要我提前写规则。
第二，抗变体能力。 "补发了""已经寄出""单号XXX"，表述完全不同，但都指向同一个判断维度——是否包含可验证的承诺。元原则不关心具体措辞，关心的是底层结构。
第三，可解释性。 出了问题可以追溯。Agent结案结错了？我可以去查：它在"承诺vs声称"这个判断环节是怎么判的？是把声称误判成了承诺吗？排查路径清晰。
四步思考链：让Agent"想"了再做
光有"承诺vs声称"这一个判断维度还不够。我在实践中发现，Agent犯错往往不是因为判断维度错了，而是思考过程跳步了。
比如Agent正确判断了"供应商说补发"是承诺型，然后直接结案了——但它忘了检查：补发到哪个地址？补发几个？物流单号是什么？承诺本身没问题，但信息不完整就结案，照样翻车。
所以我设计了一个强制的四步思考框架：
第一步：理解意图。 不是理解字面意思，是理解真实意图。供应商说"这批货本来就是这样的"，表面是在描述状态，真实意图可能是在推责免赔。
第二步：判断确定度。 不是所有判断都一样确定。"供应商提供了物流单号SF123456"——高确定度，可以直接推进。"供应商说厂家换包装了"——中确定度，需要追问要证据。"供应商含糊其辞不正面回答"——低确定度，转人工。
第三步：检查前置条件。 在决定行动之前，强制检查：方案明确吗？信息完整吗？信息来源可靠吗？特别是信息来源检查——Agent要写一个地址或单号的时候，必须回答"这个信息从哪来的？"如果说不清来源，就是编造，禁止使用。
第四步：输出前自检。 这是最关键的一步。模型没有天然的自我质疑能力，你必须用强制提问来触发。我设计了三个自检问题：这是承诺还是声称？我有数据支撑吗？如果我判断错了后果严重吗？任何一项不通过，不结案。
确定度分级：解决"要么处理要么转人工"的困境
之前系统只有两个状态：AI处理 或 转人工。结果是大量中间地带的case被一刀切到人工，AI的自动处理率上不去。
我引入了三档确定度：
- 高确定度：信息完整、证据充分、符合常见模式 → 直接处理
- 中确定度：基本判断清楚但缺少关键信息 → 先追问再决策（不是直接转人工）
- 低确定度：信息矛盾、超出认知范围、判断错误后果严重 → 转人工
"追问"这个中间状态是关键。 很多case不需要转人工，只需要Agent多问供应商一句"请提供物流单号"或"请确认补发地址"。这一个改动就显著降低了人工介入率。
示例的角色转变：从"答案库"变成"思考演示"
我最初的提示词里放了13个示例，每个示例都是"遇到这种情况→这样处理"的标准答案。
结果呢？示例越多，系统越脆弱。 因为Agent在"背答案"而不是"学方法"。遇到示例没覆盖的场景，它就不知所措。
后来我把示例从13个砍到3个。但每个示例不再是"标准答案"，而是一个完整的思考演示：
供应商说："是新版的，厂家换包装了"
思考过程：
1. 理解意图：供应商在解释货物与图片差异的原因
2. 类型判断：这是声称型——"厂家换包装"是供应商的说法，我方无法直接验证
3. 确定度：中等——有解释但无证据
4. 检查：businessData中是否有版本更新记录？→ 没有
5. 自检：如果我直接采信，万一不是换包装而是发错货呢？→ 后果严重
结论：按"待开发处理"结案，让业务人员核实是否确实换了包装
这种示例教的不是"这种情况怎么处理"，而是"怎么想这个问题"。 Agent看到的是判断过程，不是映射关系。遇到新场景，它可以用同样的思考方式来推理。
回头看：设计者思维的三个转变
做了半年提示词迭代，我觉得最核心的认知变化是三个：
从"给答案"到"教方法"。 不要想"遇到这个情况应该怎么做"，要想"判断这类情况的方法是什么"。
从"穷举场景"到"发现结构"。 不要想"还有哪些场景没覆盖"，要想"这些场景背后的共同模式是什么"。当你发现规则越写越多的时候，停下来，问自己：这些规则背后共同在判断什么？
从"控制输出"到"引导推理"。 不要想"怎么让它输出我想要的"，要想"怎么让它学会自己推导出正确答案"。
一句话总结这套方法论的核心：
场景会变，原则不变。教AI判断方法，比教它背答案更抗造。
这套思路能迁移到其他领域吗
我自己验证过，这套方法论不只是适用于采购异常处理。任何需要AI做判断决策的场景都可以用：
- 客服退款 → 核心判断维度是"诉求是否合理 + 证据是否充分"
- 内容审核 → 核心判断维度是"意图是否有害 + 影响范围多大"
- 销售线索评估 → 核心判断维度是"需求真实性 + 匹配度 + 紧迫度"
第一步永远是：找到你这个领域的底层判断维度。别急着写规则，先问——这个领域的决策，本质上在判断什么？
找到了判断维度，四步思考框架、确定度分级、示例设计这些工程层面的东西都是可以复用的。
作者从事AI Agent开发，专注于供应链和ERP领域的智能化落地。如果你也在做企业AI应用，遇到提示词设计的问题，欢迎交流。
