业务规则写在提示词里有什么问题？

把业务规则直接写进提示词，是几乎每个做 Agent 的人都走过的第一步，包括我。"你是一个单据审核助手，金额超过五千需要经理审批，发票抬头必须与单位名称一致……"最初几十条规则时一切安好，等规则涨到上百条、跑了几个月之后，问题一个接一个冒出来。复盘下来，我认为有四个根因。

根因一：规则是散落的，不是集中的

提示词会被复制。这个 Agent 一份、那个工作流一份、某个同事本地又改了一份。同一条规则在三个地方有三种表述，改的时候永远漏一处。规则一旦失去"唯一权威副本"，一致性就只能靠运气。代码世界早就明白的道理——配置要集中管理、要有单一事实来源——在提示词工程里被我们默默丢掉了。

根因二：结论无法追溯

模型说"这笔单据不通过"，依据是什么？是提示词第 40 行那条规则，还是它训练语料里的某种常识，还是纯粹的幻觉？没人说得清。更麻烦的是它会给你编一个条款出处，格式工整、语气笃定。审核类场景里，一个不能解释的正确结论，价值远低于一个能解释的结论——因为你无法在它出错时定位问题，也无法向被审核的人交代。

根因三：更新靠人工，且没有回归

制度改了，谁去改提示词？改完之后，怎么确认旧的判断没有被破坏？写代码我们有测试回归，改提示词大多数时候是"改完读一遍，感觉没问题就上"。我吃过一次亏：往提示词里加了一条新例外，结果另一类原本判得好好的单据开始出错——两条规则在自然语言层面产生了只有模型"看得见"的干扰，我隔了一周才发现。

根因四：规则和判断被同一个黑盒执行

这是最根本的一条。规则写在提示词里，意味着"规则的存储"和"规则的执行"都托付给了一个概率模型。温度调得再低，采样就是采样；上下文一长，中间的规则就是会被稀释。前三个问题某种程度上都是这一条的衍生物。

提示词是个好的沟通界面，但它是个糟糕的规则库。

出路：把规则请出提示词

我后来的做法是把两件事拆开：规则以结构化形式单独维护（每条带条件、结论、条款出处），由确定性引擎执行；模型只做它擅长的事——把非结构化的输入抽取成结构化事实，把结构化的判决翻译成人话。规则改动必须先跑完整的评测集，全部通过才允许生效，否则宁可不改。

这套做法并不新，本质上是把软件工程里最朴素的纪律——单一事实来源、可追溯、回归测试——重新请回到 AI 应用里。模型很新，纪律很旧，而恰恰是旧纪律让新模型真正能干活。