用简单语言记录 AI 应用的业务规则

为什么模糊的规则会导致不可靠的应用

业务规则告诉应用在真实场景中应该怎么做。它们回答诸如谁可以批准请求、总额如何计算、以及当某个案件不在常规模式内时会发生什么等问题。

如果这些规则含糊不清，应用仍然必须选择处理路径，但它可能不会按你预期的方式选择。

拿一句规则举例："大额费用需要经理批准。" 对人来说这听起来清楚，但对构建者并不。什么算大额：$500、$5,000，还是超过某个团队预算就算？哪个经理：直接经理、部门主管，还是财务？如果两天没人回复，请求是等待、过期，还是转给别人？

这就是为什么模糊的规则会导致不可靠的应用。构建者只能像指令一样一致地执行。当措辞留有猜测空间时，应用今天可能这样处理，明天遇到略有不同的情况时又可能那样处理。

最大的问题通常出现在几个方面：

• 计算缺少细节，例如四舍五入、税费、折扣或日期范围
• 大家都假定但没人写下来的例外
• 没有明确负责人、顺序或回退的审批步骤

一个简单例子能说明问题。一位创始人在 Koder.ai 上构建内部报销应用，写了 "报销差旅费用，除非看起来异常。" 这听起来合理，但应用没有可靠方式判断什么是异常。一个员工的出租车被批准，另一个类似的被标记为异常，没人知道原因。

可靠的行为始于可以每次都按同样方式执行的规则。像 "大额、紧急、特殊情况" 这样的词需要被具体的限额、条件和动作取代。如果两个不同的人在应用规则时会得到相同结果，应用也更可能给出一致的结果。

清晰的业务规则是什么样子

一条清晰的业务规则只涵盖一个决策或一个动作，而不是一个完整流程。这点比大多数团队想象的重要。当一条规则试图同时涵盖审批、定价、例外和通知时，构建者不得不猜测哪一部分最重要。

一条好的规则读出来很容易。团队外的人不应该需要你的内部简写就能理解。把像 "快速通道、标准情况、经理签字" 这样的术语替换为确切说明会发生什么的平实语言。

大多数清晰的规则回答四个基本问题：

• 谁来做决定或采取动作？
• 规则什么时候适用？
• 应用中发生了什么变化？
• 接下来会怎样？

这种结构把规则和真实行为绑在一起。不要写 "大额订单需要复核，" 而要写 "如果订单超过 $5,000，销售经理必须批准，才能发货。" 一句， 一个决策，一个结果。

把相关规则分开也有帮助。审批规则应独立存在，发送邮件的规则应该独立，阻止发货的规则也应独立。这样每条规则更容易测试、更新和修复。

差别很容易看出：

"高级客户获得优先处理" 很模糊。

"如果客户有高级计划，工单创建时将其标记为高优先级" 很清楚。

第二种写法指出触发器、条件和在应用内的变化，告诉构建者什么才是可靠的行为。

如果你使用基于聊天的构建器，这类措辞能产生很大差别。清晰的规则不需要法律语言，只需要简单的词汇、一次一个想法，以及可以放在一句话里的预期结果。

用简单语言写计算规则

计算看起来常常很简单，直到有人去实现它。最稳妥的方法是以一句简单的话说明应用必须做什么。

一个好规则像这样："报销金额等于核准里程乘以里程费率。" 这比写 "计算差旅费" 或 "应用标准报销" 清楚得多。

在这句说明之后，明确列出应用应使用的每个输入。要足够具体，避免构建者猜测。

每个计算要定义的内容

对于每个计算，列明：

• 输入项，使用简单名称和单位
• 每个值来源于哪里
• 四舍五入规则
• 任何最小或最大值
• 若值缺失时应如何处理

小细节很重要。"将最终金额四舍五入到两位小数" 与先对每行项目四舍五入会得出不同结果。如果有上限，说明应用应当在上限处截断还是仅显示警告。

一条用简单语言写的规则可能如下："差旅报销等于核准里程 x $0.67。将最终金额四舍五入到两位小数。每次出差最高报销 $300。如果核准里程为空，不计算金额。将请求标记为不完整并要求用户输入里程。"

然后加一两个带真实数字的示例。示例比抽象公式更快暴露漏洞。

示例 1："如果核准里程是 120，报销为 120 x $0.67 = $80.40。因为低于 $300 上限，最终金额为 $80.40。"

示例 2："如果核准里程是 500，报销为 500 x $0.67 = $335.00。因为最高为 $300，最终金额为 $300.00。"

这种风格更容易让人审阅，也更容易被构建者转成应用行为。

在不混淆的情况下记录例外

大多数应用不会在主路径上失败，而是在边缘情况下出问题。

正常路径可能很简单，但真实工作包括截止后退款、VIP 客户、缺失文件和一次性批准。如果例外没写清楚，应用会自己填补空白，这正是结果不一致的起点。

写例外的简单方法是用简短的 if-then 规则。每条规则只关注一个条件和一个结果。

• 如果费用低于 $100，则自动批准。
• 如果费用低于 $100 但在 30 天后提交，则发送人工复核。
• 如果员工属于高层团队，则跳过 $100 限额并转到财务。
• 如果财务管理员将报销标记为紧急，则应用人工覆盖并将报销置于队列顶部。

这种格式让隐藏的逻辑变得可见，也有助于你在它们变成 bug 前发现重叠之处。

同样重要的是说明当两条规则冲突时哪条优先。比如客户可能同时符合折扣规则，但订单也可能落在节假日黑名单期间。用平实语言写出优先级："如果节假日黑名单规则与客户折扣规则冲突，则以黑名单规则为准。"

要对限额精确。日期、用户类型、地点、账户状态和人工覆盖往往会改变结果。不要写 "迟交需要批准，" 而写 "如果请求在事件发生后超过 14 个日历日提交，则需要经理批准。"

还要说明在每个例外情况下应用应向用户显示什么。好规则不会止步于决定，还会定义提示信息，比如 "提交晚于 14 天。需要经理批准" 或 "由财务管理员手动覆盖"。

当例外以这种方式写清楚时，不寻常的情况就不再不寻常，而变成可测试的常规行为。

逐步描述审批逻辑

审批逻辑最好以一系列决策来写，而不是模糊的政策。每一步都应该回答五个问题：谁执行、什么触发他们的复核、有哪些限制、他们有多长时间，以及他们决定后请求是什么状态。

先明确角色，而不是只写团队。不要写 "财务复核大额请求，" 要写 "财务经理可以批准、拒绝或退回任何超过 $5,000 的请求。" 这能消除猜测，使行为更容易实现。

然后为每一步定义触发条件。触发条件会把请求送到下一个人那里，可能基于金额、部门、风险等级、请求类型或它们的组合。

例如：

• 如果请求低于 $500，由团队负责人复核。
• 如果请求在 $500 到 $5,000 之间，团队负责人批准后由部门经理复核。
• 如果请求超过 $5,000，部门经理批准后由财务复核。
• 如果请求被标记为高风险，合规部门必须在最终批准前复核。

阈值需要精确边界。不要说 "大额" 或 "敏感"。要写清楚 "超过 $5,000"、"来自销售部" 或 "风险评分 8 或更高"。如果两个阈值可能同时适用，要说明哪一个优先。例如："高风险始终发给合规，即使金额很低。"

你还需要一个超时规则。如果没人响应，应用不应无限期停留。说明在固定时间后会发生什么，例如 48 小时或 3 个工作日。请求可以升级到审批人的经理、重新分配给备用审批人，或自动取消。

最后，为每个决定定义状态。保持标签简短且一致：

• Approved：请求继续或完成。
• Rejected：请求关闭，不再采取进一步行动。
• Sent back：请求人必须编辑并重新提交。
• Escalated：请求转给备用或更高级审批人。

当审批逻辑以这种方式书写时，构建者的猜测空间就小了，工作流也更可靠。

一个可复用的简单规则模板

如果想要一致的行为，就给每条规则相同的结构。混杂的写法常常造成混杂的结果。

一个简单格式适用于大多数场景：触发器、条件、动作、结果。它既短又清楚，便于他人稍后审阅。

每条规则一个单元

把每条规则保持在独立的一行、卡片或区块中。不要把好几个想法塞在同一段里。如果一条规则同时涉及定价、审批和例外，就很难测试也容易读错。

一个实用的模板如下：

Trigger: When [event happens]
Conditions: If [facts must be true]
Action: Then [the app does this]
Result: So [expected outcome]
Assumption: [anything not yet confirmed]
Example: [short sample input and output]

你不必每次都填齐所有字段，但保持相同顺序有助于别人快速浏览规则。

例如：

Trigger: When an employee submits an expense claim
Conditions: If the total is over $500 and no receipt is attached
Action: Then send the claim back for correction
Result: So incomplete claims are not forwarded to a manager
Assumption: Receipt is required for all claims above $500
Example: A $620 taxi claim without a receipt is returned to the employee

注意示例放在规则下方，而不是规则中间，这保持规则简洁。示例只是证明规则应如何表现。

清楚标注假设而不是把它们藏在句子里。像 "Assumption" 或 "Needs confirmation" 的小注记能让未决问题在构建前被审查清楚。

保持措辞一致也有帮助。总是用 "When" 开始触发器，用 "If" 开始条件，用 "Then" 开始动作。这样的小模式能减少混淆，尤其是在把规则转换为应用逻辑时。

一个快速测试很有用：别人能否测试这条规则？有没有人可能读错它？如果答案是否定或肯定，则需要收紧措辞。

示例：报销审批应用

员工报销应用是个好案例，因为策略熟悉且边缘情况容易暴露。员工可以申报餐费、打车、酒店和小额客户费用，但每笔申报都有限额、例外和审批步骤。这正是简单语言很重要的流程类型。

示例政策

把餐费规则这样写：员工在正常工作日的餐费每天最多可报销 $40。应用应将同一天的所有餐费凭证相加，并将总额与日限额比较，而不是逐条凭证对比。

如果员工周二早餐 $12、午餐 $22，则当日总额为 $34，申报通过。如果同日再加一笔 $15 的晚餐，总额变为 $49，则应用应标记超出限额。

再加一个例外：如果餐费发生在经批准的出差或客户会议期间，日限额提高到 $75。该例外仅在员工选择 Travel day = Yes 或 Client meeting = Yes 并填写简短备注（客户名或出差目的）时适用。

这比写 "特殊情况可允许" 更可靠，因为例外绑定了明确条件。

审批步骤

审批逻辑也可以保持同样的平实：

• 低于 $100 的申报由员工的经理批准。
• $100 到 $500 的申报先经理批准，再由财务批准。
• 超过 $500 的申报需要经理、财务和部门主管逐级批准。
• 任何标记为 "travel" 的申报即便金额低于 $100，也需要财务复核。

可以用几个简单案例测试规则。周常日的一笔 $36 餐费且附有凭证应被批准。出差日的 $60 餐费若标记了旅行并填写备注则应通过。常日的 $60 餐费应被拒绝或退回修改。$650 的酒店费应通过三步审批流。

目标是：用真实案例测试时，规则每次都应给出相同结果。

导致坏结果的常见错误

一条规则看起来对人清楚，但仍会让构建者困惑，这通常发生在文档含糊、把多个想法混在一起，或前后不一致时。

常见错误之一是把几条规则塞进一段长句。例如："经理审批差旅，除非金额很高，财务核凭证，紧急请求可跳过复核。" 这看似简洁，但掩盖了多个独立决策。把它们拆成独立规则，使每个动作都有明确触发和结果。

另一个问题是模糊用语。像 正常、大额、紧急、近期 之类的词只在被定义时才有用。如果 "大额费用" 指 $2,000 以上，就写清楚。如果 "紧急" 意味着需要在 24 小时内处理，也要写明条件。

缺失数据也是导致坏结果的重要原因。团队常描述顺利路径，却忘了说明信息不全或错误时应如何处理。如果请求没有金额、没有部门或没有凭证，规则应说明下一步。

最常造成麻烦的错误通常是：

• 在一段里混合多条规则
• 使用未定义的大小、时间或优先级术语
• 忘记错误情况和缺失字段的处理
• 未明确最终审批权限
• 半途更换同一事物的名称

最终审批权比许多团队想象的更重要。如果经理和财务复核意见不一致，谁做最终决定？如果没人拥有最终步骤，应用可能停滞或在流程中转圈。

术语变换会产生隐蔽错误。如果你开始称之为 "request"，后来又叫它 "submission" 或 "ticket"，读者可能以为是不同对象。选一个术语并在整份文档中保持一致。

在基于聊天的构建器里这点尤为重要，因为平实语言直接驱动行为。清晰的规则不必显得正式，只要具体、一致并完整。

构建前的快速检查清单

在把需求变成界面、流程或提示前，再做最后审查。现在做一次短检查可以省下修复奇怪行为的大量时间。

让每条规则都可测试。每条规则应以明确结果结束，比如是或否、批准或拒绝、收取费用或不收取。如果两个人读同一句话会给出不同答案，这条规则还需完善。

把每个计算都写清楚。命名输入、公式以及何时计算。补充四舍五入、货币、日期处理，以及当值缺失或为零时的处理。

把例外分开。先写默认规则，再把例外独立写出。主要的支出限额不应埋在承包商、紧急采购或预先批准出差的特殊情况中。

绘出完整审批路径。为每个阈值说明谁批准、接下来如何处理。对边界也要精确说明：规则是从超过 $500 开始，还是 $500（含）开始？

然后做个新人测试。把规则交给没参与过的人，让他们用自己的话复述。如果他们需要额外上下文，规则仍然太模糊。

一个小例子说明其重要性。"经理审批大额费用" 听起来清楚，直到有人问 $500 是否算大额。写成 "经理审批超过 $500 的费用。主任审批超过 $2,000 的费用。$500 或以下费用自动批准" 就更少出错。

把规则变成可运行的应用

规则清楚后，与每天使用该流程的人一起复核。经理、协调员、财务人员和审批人常会注意到文档中未写出的细节，这些细节通常决定应用是顺手还是令人恼火。

把规则文档当作工作指南，而不是一次性的草稿。它应说明会发生什么、谁来决定、有哪些例外以及信息缺失时应用应做什么。

在构建完整应用之前，用最近的真实场景测试几例。包含顺利通过的案例和混乱的案例：一条应通过的标准请求、一条缺失信息的请求、需要人工复核的例外，以及跨越支出限额或审批阈值的案例。

这一步可以提前发现漏洞。一条纸面上看似清楚的规则，遇到真实请求不符合预期时可能就会失效。

当这些场景都能按规则运行后，把它们放入构建器。如果你使用像 Koder.ai 这样的基于聊天的平台，清晰的规则集能让构建更快，因为你是在把已定义的流程翻译成界面、动作和审批，而不是在构建时临时决策。

上线后，将文档作为事实来源保留。当策略变化、添加新的审批人或更新限额时，先改文档再改应用。这样以后的修改更简单，也降低了不同人记忆规则不一致的风险。

一个小习惯有帮助：流程变更时就审查规则，而不是等到应用出问题才改。及早做小更新要比后来修复混乱行为容易得多。

如果文档保持最新，应用随着时间会更容易测试、改进并值得信赖。