LLM 如何处理业务规则与工作流推理

为什么业务规则推理不仅仅是代码生成

当人们问一个 LLM 是否“能对业务规则进行推理”时，他们通常想要的是比“它能写一个 if/else 语句”更复杂的能力。业务规则推理是能够一致地应用策略、解释决策、处理例外并与当前工作流步骤保持一致——尤其是在输入不完整、凌乱或不断变化时。

推理 vs. 输出代码

代码生成主要关注在目标语言中产生有效语法。规则推理关心的是保留意图。

模型可以生成完全有效的代码，但仍然产出错误的业务结果，原因包括：

• 政策文本含糊不清（“最近客户”、“高风险”、“已批准的文档”）。
• 规则发生冲突，且优先级不明确。
• 边缘情况未被说明（部分退款、重复、周末/节假日）。
• 工作流状态会改变下一步该做什么（受理 vs. 审核 vs. 最终批准）。

换句话说，正确性不是“能否编译？”而是“是否与业务每次都会做出的决定一致，并且我们能否证明它？”

可以对 LLM 有何期待

LLM 可以帮助把政策翻译成结构化规则、建议决策路径并为人工提供解释。但它们不会自动知道哪个规则具有权威性、哪个数据源可信或案件当前处于哪个步骤。在没有约束的情况下，它们可能自信地选择一个看上去合理的答案，而不是受管控的答案。

因此目标不是“让模型来决定”，而是给它结构和检查点，使其能够可靠地协助。

本文其余部分将做什么

一个务实的方法看起来像一个流水线：

1. 将政策文本转换为可用的规则表示。
2. 跟踪工作流状态，使决策在各步骤间保持一致。
3. 使用提示模式来强制执行优先级、例外和解释。
4. 使用工具和检索来为决策提供依据（仅使用被批准的数据）。
5. 使用模式约束输出以减少歧义。
6. 验证、测试并监控，以便在发布前发现错误。

这就是聪明代码片段与能支持真实业务决策的系统之间的区别。

业务规则与工作流：一句话回顾

在讨论 LLM 如何“推理”之前，先把团队经常混在一起的两件事分开：业务规则 和 工作流。

什么是业务规则？

业务规则 是组织希望一致执行的决策陈述。它们以政策和逻辑的形式出现，例如：

• 资格：谁有资格获得某项权益、计划或功能？
• 定价：何时适用何种折扣？
• 审批：什么时候需要经理复核？
• 合规：必须记录、脱敏或阻止的内容？

规则通常以“如果 X，则 Y”的形式表达（有时带例外），并应产生明确结果：批准/拒绝、价格 A/价格 B、请求更多信息等。

什么是工作流？

工作流 是将工作从开始推进到完成的过程。它更关注“接下来该发生什么”，而不是决定“什么被允许”。工作流通常包括：

• 状态：提交 → 审核中 → 批准/拒绝 → 完成
• 步骤与移交：客户支持 → 财务 → 客户
• 基于时间的事件：提醒、SLA、14 天后自动取消
• 工件：表单、附件、理由码、审计记录

一个小示例：退款请求

想象一个退款请求。

规则片段： “购买后 30 天内允许退款。例外：数字下载一旦被访问即不可退款。例外：涉及争议的必须升级处理。”

工作流片段：

1. 客户提交请求（状态：submitted）。
2. 系统检查购买日期和产品类型（状态：under review）。
3. 若符合条件，发起退款并通知客户（状态：completed）。
4. 若为争议（chargeback），移交财务调查（状态：escalated）。

为什么规则比看上去更难

当规则发生冲突（“VIP 客户总能退款” vs. “数字下载永不退款”），依赖缺失的上下文（是否已访问下载？），或隐藏边缘情况（捆绑、部分退款、地区法律）时，规则就变得棘手。工作流增加了另一层：决策必须与当前状态、先前操作和截止日期保持一致。

LLM 的“推理”方式：基于模式匹配但需结构化引导

LLM 并不像人那样“理解”业务规则。它们是基于大量文本学习到的模式来生成下一个最可能的词。这就是为什么 LLM 在猜测时也能表现得很有说服力——或者在缺失信息时默默填充未提供的细节。

这一限制对工作流和决策逻辑很重要。模型可能应用一个“听起来正确”的规则（“员工总需经理批准”），即便真实政策有例外（“仅在超过 $500 时”或“仅对承包商”）。这是一个常见的失败模式：自信但错误地应用规则。

它们对业务规则仍有用的原因

即便没有真正的“理解”，当你把它们当作结构化助手来使用时，LLM 也能发挥作用：

• 总结 冗长政策，便于审阅；
• 映射 杂乱文本到一致字段（谁、什么、阈值、例外、生效日期）；
• 校验 拟议决策是否符合已声明规则（“哪一条支持此结论？”）。

关键是把模型置于不能轻易即兴发挥的位置。

限制模型的漂移

减少歧义的实用方法是受限输出：要求 LLM 以固定模式或模板回应（例如带特定字段的 JSON，或带必需列的表格）。当模型必须填写 rule_id、conditions、exceptions 和 decision 时，就更容易发现空白并自动验证输出。

受限格式也更容易表明模型不知道某些信息。如果某个必填字段缺失，你可以强制模型提出后续问题，而不是接受不牢靠的答案。

结论：LLM 的“推理”最好被视为在结构引导下的基于模式的生成——适合用于组织和交叉校验规则，但如果把它当作不可置疑的决策者就很危险。

把凌乱的政策文本转成可用的规则表示

政策文档是为人写的：目标、例外和“常识”往往混在同一段落里。LLM 可以总结这些文本，但当你把政策转成明确、可测试的输入时，它们遵循规则会更可靠。

什么是“可用”的规则

好的规则表示有两个特点：无歧义且可校验。

把规则写成你可以测试的语句：

• IF/THEN 用于决策（资格、路由、审批）；
• MUST / MUST NOT 表示强约束；
• MAY 表示允许选项（通常需要决定者来打破平局）。

规则可以以多种形式提供给模型：

• 纯文段要点（最快、仍有结构）；
• 表格（适合基于阈值的策略）；
• YAML/JSON（当你还想要受限输出和自动校验时最优）。

处理冲突和优先级

真实政策会发生冲突。若两条规则相互矛盾，模型需要清晰的优先级方案。常见方法：

• 具体优于通用（例外覆盖默认）；
• 较高权威胜出（法律/合规高于团队偏好）；
• 较新者胜出（新版本覆盖旧版本）；
• 显式优先级编号（最可靠）。

直接声明冲突规则或把优先级编码进去（例如 priority: 100），否则 LLM 可能会对规则进行“平均化”。

示例：把一段话转成规则列表

原始政策文本：

“年付计划在购买后 30 天内可退款。月付计划在 7 天后不可退款。如果账户显示欺诈或过高的争议率，则不得退款。企业客户退款超过 $5,000 需要财务批准。”

结构化规则（YAML）：

rules:
  - id: R1
    statement: "IF plan_type = annual AND days_since_purchase <= 30 THEN refund MAY be issued"
    priority: 10
  - id: R2
    statement: "IF plan_type = monthly AND days_since_purchase > 7 THEN refund MUST NOT be issued"
    priority: 20
  - id: R3
    statement: "IF fraud_flag = true OR chargeback_rate = excessive THEN refund MUST NOT be issued"
    priority: 100
  - id: R4
    statement: "IF customer_tier = enterprise AND refund_amount > 5000 THEN finance_approval MUST be obtained"
    priority: 50
conflict_resolution: "Higher priority wins; MUST NOT overrides MAY"

现在模型不会猜测哪些细节重要——它在应用一个你可以审查、测试和版本化的规则集。

跟踪工作流状态以保持模型一致性

工作流不仅仅是一组规则；它是事件序列，早期步骤会改变接下来该做的事。那种“记忆”就是状态：关于案件的当前事实（谁提交了什么、哪些已被批准、什么在待办、有哪些截止时间适用）。如果不显式跟踪状态，工作流会以可预测的方式失败——重复审批、跳过必需检查、撤销决定，或者因为模型无法可靠推断已发生的事情而应用错误的政策。

用通俗话解释“状态”是什么意思

把状态想象成工作流的记分牌。它回答：我们现在在哪里？已完成了什么？下一步被允许做什么？对于 LLM，提供清晰的状态摘要可以防止它重新审议过去的步骤或猜测。

如何将状态传给模型

调用模型时，除了用户请求外，还应包含一个简洁的状态负载。常用字段有：

• 步骤名称与状态（例如，manager_review: approved、finance_review: pending）；
• 稳定 ID（请求 ID、员工 ID），以免模型混淆案件；
• 时间戳（提交时间、最近更新），用于解决“最新者胜出”的情况；
• 标志（政策例外、缺失文档、需要升级）。

避免丢出所有历史消息。相反，提供当前状态加上关键转变的简短审计轨迹。

保持单一可信数据源

把工作流引擎（数据库、工单系统或编排器）当作单一可信来源。LLM 应该从该系统读取状态并提出下一步动作，但系统应当是记录状态转换的权威。这能减少模型叙述与现实发生偏离的“状态漂移”。

示例：审批流程的状态快照

{
  "request_id": "TRV-10482",
  "workflow": "travel_reimbursement_v3",
  "current_step": "finance_review",
  "step_status": {
    "submission": "complete",
    "manager_review": "approved",
    "finance_review": "pending",
    "payment": "not_started"
  },
  "actors": {
    "employee_id": "E-2291",
    "manager_id": "M-104",
    "finance_queue": "FIN-AP"
  },
  "amount": 842.15,
  "currency": "USD",
  "submitted_at": "2025-12-12T14:03:22Z",
  "last_state_update": "2025-12-13T09:18:05Z",
  "flags": {
    "receipt_missing": false,
    "policy_exception_requested": true,
    "needs_escalation": false
  }
}

有了这样的快照，模型就能保持一致：不会再次请求经理批准，会聚焦于财务检查，并能基于当前标志和步骤解释决策。

提示模式：提高规则遵从性和决策质量

一个好的提示不仅仅是询问答案——它要设定模型如何应用规则以及如何报告结果的期望。目标是可重复的决策，而不是华而不实的文案。

1) 角色提示：分配一个工作，而不是一种“氛围”

给模型一个与流程绑定的具体角色。三个互补角色通常效果很好：

• 政策分析师：解释规则文本并将其映射到当前案例；
• 验证者：检查决策是否满足要求并标记缺失输入；
• 执行代理：采取下一步工作流动作（创建工单、草拟邮件、设置状态）。

你可以按顺序运行这些角色（“分析 → 验证 → 执行”），或在一个结构化响应中请求三种输出。

2) 逐步指示（避免要求隐藏的链式思考）

不要请求“chain-of-thought”，而应指定可见的步骤和交付物：

1. 确认相关规则。
2. 从案件中提取所需输入。
3. 按优先级应用规则。
4. 给出决策和下一步。

这能让模型有条理地工作，同时专注于可交付的内容：使用了哪些规则以及产生了何种结果。

3) 要求结构化理由：规则 ID + 证据

自由形式的解释容易漂移。要求一个紧凑的理由，指向来源：

• 使用的规则 ID（例如，R-12、R-18）；
• 证据（引用政策文本片段和具体案件字段）；
• 假设（仅当输入缺失时）。

这能加快审查速度并帮助调试分歧。

4) 清单式提示模式：输入、决策、例外、下一步

每次都使用固定模板：

• 收到的输入： …
• 缺失的输入： …
• 决策： approve/deny/needs-review
• 规则引用： [R-…]
• 考虑的例外： …
• 下一步工作流动作： 更新状态 / 请求信息 / 升级

该模板减少歧义，并促使模型在做出不当操作之前暴露信息缺口。

使用工具与检索将决策落地到真实数据

LLM 可以在缺少关键事实时写出有说服力的答案。这对起草有用，但对业务规则决策有风险。如果模型必须“猜测”账户状态、客户等级、地区税率或限制是否已达上限，就会产生看似自信的错误。

工具把“推理”变为两步：先获取证据，再决定。

保持模型诚实的常用工具

在规则和工作流密集的系统中，少数工具能完成大部分工作：

• 数据库查询（客户档案、账户状态、权限、使用总量）；
• 政策/规则存储（已批准的规则文本、版本化流程、例外清单）；
• 计算器（费用、按比例计算、税费、时间窗口、阈值）；
• 工单 / 工作流 API（未结案件、SLA 计时器、审批、步骤完成）。

关键是模型不是在“凭空创造”运营事实——它在请求事实。

检索：只带入相关规则片段

即便你把所有政策都保存在中心库里，也很少需要把所有内容粘贴到提示中。检索可以根据当前案件只选出最相关的片段，例如：

• 与客户计划相关的取消政策；
• 基于国家/州的地区合规条款；
• 在存在争议时适用的例外规则。

这能减少矛盾并防止模型仅因为某条旧规则在上下文中早先出现就去遵循它。

将工具输出转为决策证据

一个可靠的模式是把工具结果视为模型必须在决策中引用的证据。例如：

1. 工具：get_account(account_id) → status="past_due", plan="Business", usage_this_month=12000
2. 工具：retrieve_policies(query="overage fee Business plan") → 返回规则："Overage fee applies above 10,000 units at $0.02/unit."
3. 工具：calculate_overage(usage=12000, threshold=10000, rate=0.02) → $40.00

现在，这一决策不是猜测：它是基于具体输入得出的结论（"past_due"、"12,000 units"、"$0.02/unit"）。以后审计时，你可以看到使用的是哪些事实和哪个规则版本——并在出错时修正对应部分。

受限输出：用模式减少歧义

自由文本灵活但也最容易导致工作流出错。模型可能给出“看上去没问题”的答案，但这类答案不可自动化（“看起来可以”）或在不同步骤间不一致（“approve” vs. “approved”）。受限输出通过把每个决策约束到可预测的形态来解决这类问题。

以 JSON 返回决策

实用的模式是要求模型以单个 JSON 对象回应，系统可以解析并路由：

{
  "decision": "needs_review",
  "reasons": [
    "Applicant provided proof of income, but the document is expired"
  ],
  "next_action": "request_updated_document",
  "missing_info": [
    "Income statement dated within the last 90 days"
  ],
  "assumptions": [
    "Applicant name matches across documents"
  ]
}

这种结构使输出在模型无法完全决定时仍有用。missing_info 和 assumptions 把不确定性转化为可操作的后续步骤，而非隐藏的猜测。

使用枚举来限制结果

为减少可变性，为关键字段定义允许值（枚举）。例如：

• decision: approved | denied | needs_review
• next_action: approve_case | deny_case | request_more_info | escalate_to_human

有了枚举，下游系统无需解释同义词或语气差异，只需基于已知值分支。

为什么模式让工作流更安全

模式像护栏一样：

• 强制必填字段，防止“部分回答”；
• 通过 reasons 更容易审计为何做出某决策；
• 支持可靠自动化：队列、通知和任务可以直接由 decision 与 next_action 触发；
• 支持校验：你可以拒绝不匹配模式的输出并要求模型重试。

结果是更少歧义、较少边缘故障，以及在工作流中能一致推进的决策。

验证策略：在发布前抓住错误

即便提示得当，模型也可能“听起来正确”却悄悄违反规则、跳过必需步骤或捏造数值。验证是把看似合理的回答变成可靠决策的安全网。

预检：在推理前验证输入

先验证是否有应用规则所需的最小信息。预检应在模型做任何决策之前运行。

典型预检包括必填字段（如客户类型、订单总额、地区）、基本格式（日期、ID、货币）和允许范围（非负金额、百分比上限为 100%）。若有失败，返回明确可操作的错误（“缺少 'region'；无法选择税率集”），而不是让模型猜测。

后检：把决策与规则校验

在模型产生结果后，验证它是否与规则集一致。

重点检查：

• 规则覆盖率： 决策是否引用或映射到适用规则，还是跳过了强制性政策？
• 矛盾检查： 输出是否与已给输入矛盾（例如在存在硬性阻断条件时仍返回“approved”）？
• 边界情况： 测试阈值（正好 $10,000）、空状态（“无先前违规”）和刚刚超过场景。

第二轮校验：刻意的复核步骤

增加一个“第二遍”来重新评估第一次答案。这可以是另一次模型调用，或用验证者风格的提示让同一模型只执行合规性检查而不发挥创造力。

一种简单模式：第一遍生成决策 + 理由；第二遍返回 valid 或结构化的失败列表（缺失字段、违规约束、模糊的规则理解）。

日志记录：让决策可审计

对每个决策，记录所用输入、规则/政策版本 和验证结果（包括第二遍发现）。当出错时，这能让你重现确切条件、修正规则映射并确认修复——而无需猜测模型“到底是什么意思”。

针对规则与工作流可靠性的测试与监控

测试基于规则与工作流的 LLM 功能，不是看“它生成了什么？”，而是看“它是否像细心的人那样为正确的理由每次都做出同样的决定？”好消息是：你可以用与传统决策逻辑相同的严谨性来测试它。

业务规则的单元测试（小而可预测的检查）

把每条规则当作一个函数：给定输入，它应该返回可断言的结果。

例如针对“30 天内未开封商品可退款”的退款规则，写出聚焦用例：

• 订单年龄 = 10 天，未开封 = true → 批准
• 订单年龄 = 10 天，未开封 = false → 拒绝
• 订单年龄 = 45 天，未开封 = true → 拒绝
• 边界情况：恰好 30 天、缺失 “未开封” 字段、冲突信号

这些单元测试能捕捉越界错误、缺失字段以及模型“好心填补未知”的行为。

工作流场景测试（多步骤、考虑时间的路径）

工作流在跨步骤状态不一致时会失败。场景测试模拟真实旅程：

• 路径测试：提交申请 → 请求材料 → 收到材料 → 决策
• 基于时间的边缘：7 天无响应则发送提醒；30 天后关闭案件
• 分支：客户升级、请求政策例外、检测到重复案件

目标是验证模型尊重当前状态并只执行被允许的转换。

构建“黄金集”示例库

创建一套经审定的真实（已匿名化）示例及确定结果（并附简短理由）。保持其版本化，并在政策变更时审查。一个小型黄金集（即使 100–500 个案例）也很有价值，因为它反映了真实世界的复杂性：缺失数据、措辞不一、边界决策。

生产监控（在客户察觉之前捕捉漂移）

追踪决策分布与质量信号随时间的变化：

• 漂移：批准/拒绝率在没有政策更新的情况下变化；
• needs_review 或转人处理的激增（通常是提示、检索或上游数据问题）；
• 按产品、地区或政策类别聚集的错误簇。

将监控与安全回滚配合：保留先前的提示/规则包，用特性开关发布新版本，并在指标回退时快速恢复。关于操作手册与发布门控，请参阅 /blog/validation-strategies。

Koder.ai 在此流水线中的定位

若你要实施上述模式，通常会在模型周围构建一个小型系统：状态存储、工具调用、检索、模式校验与工作流编排。Koder.ai 是一种实用方式，能更快地原型和发布这类有工作流支撑的助手：你可以在聊天中描述工作流，生成一个可运行的 Web 应用（React）及后端服务（Go + PostgreSQL），并通过快照与回滚安全迭代。

这对业务规则推理很重要，因为“护栏”往往在应用层而不是提示中：

• 规划模式 帮助你在执行前设计流程（状态、允许的转换、升级路径）；
• 模式约束响应 可以在 API 边界强制执行，只接受可解析的决策；
• 工具钩子（数据库读、政策检索、计算器、工单更新）可以作为显式端点实现，使“先取证据、再决定”成为默认；
• 源代码导出 可以避免原型变成关键生产时的厂商锁定。

限制、安全使用及何时保留人工复核

LLM 在应用日常政策时可能表现出色，但它们并非确定性的规则引擎。把它们当作需要护栏的决策助手，而不是最终权威。

LLM 常见的难点

三类失败模式在规则密集的工作流中经常出现：

• 罕见例外与边缘情况：若某例外一年只发生一次，训练数据中可能低频出现，除非在提示或检索中明确提供，否则容易遗漏；
• 长上下文与“埋藏的”约束：当关键细节散布在许多页面或消息中时，模型可能高估最近或最生动的文本，而忽视早前的约束；
• 数值精度与严格计算：总额、按比例、阈值与四舍五入规则容易漂移。对数学类使用工具并要求模型引用确切数字。

何时要求人工复核

在以下情况设置强制人工复核：

• 结果为高风险（资金流动、合规、安全、法律承诺、客户信用/资格）；
• 模型发出低置信号（请求猜测缺失输入、找不到政策依据或给出自相矛盾的推理）；
• 案例新颖（新产品、新地区、政策近期变更）或特别敏感。

让事情继续推进的升级路径

不要让模型“随意编造”，而要定义清晰的下一步：

1. 提出澄清问题（缺少日期、客户等级、司法管辖区、审批状态）；
2. 将提取的事实、拟议决策与引用一起路由给人工处理者；
3. 创建工单，当政策模糊或冲突时，以便在源头修正（并在以后自动检索）。

一个简单的采用框架

当你能对以下大多数问题回答 “是” 时，可以在规则密集的工作流中使用 LLM：

• 我们能否把决策落地到已批准的政策文本或系统数据？
• 我们能否约束输出（模式、允许动作、必需引用）？
• 我们能否在执行前进行验证（检查、阈值、单元测试、抽样）？
• 我们是否有人工升级路径来处理有风险或不确定的个案？

若不能，将 LLM 保持在草稿/助理角色，直到这些控制到位。