学习如何用简单语言记录 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 规则。每条规则只关注一个条件和一个结果。
这种格式让隐藏的逻辑变得可见,也有助于你在它们变成 bug 前发现重叠之处。
同样重要的是说明当两条规则冲突时哪条优先。比如客户可能同时符合折扣规则,但订单也可能落在节假日黑名单期间。用平实语言写出优先级:"如果节假日黑名单规则与客户折扣规则冲突,则以黑名单规则为准。"
要对限额精确。日期、用户类型、地点、账户状态和人工覆盖往往会改变结果。不要写 "迟交需要批准," 而写 "如果请求在事件发生后超过 14 个日历日提交,则需要经理批准。"
还要说明在每个例外情况下应用应向用户显示什么。好规则不会止步于决定,还会定义提示信息,比如 "提交晚于 14 天。需要经理批准" 或 "由财务管理员手动覆盖"。
当例外以这种方式写清楚时,不寻常的情况就不再不寻常,而变成可测试的常规行为。
审批逻辑最好以一系列决策来写,而不是模糊的政策。每一步都应该回答五个问题:谁执行、什么触发他们的复核、有哪些限制、他们有多长时间,以及他们决定后请求是什么状态。
先明确角色,而不是只写团队。不要写 "财务复核大额请求," 要写 "财务经理可以批准、拒绝或退回任何超过 $5,000 的请求。" 这能消除猜测,使行为更容易实现。
然后为每一步定义触发条件。触发条件会把请求送到下一个人那里,可能基于金额、部门、风险等级、请求类型或它们的组合。
例如:
阈值需要精确边界。不要说 "大额" 或 "敏感"。要写清楚 "超过 $5,000"、"来自销售部" 或 "风险评分 8 或更高"。如果两个阈值可能同时适用,要说明哪一个优先。例如:"高风险始终发给合规,即使金额很低。"
你还需要一个超时规则。如果没人响应,应用不应无限期停留。说明在固定时间后会发生什么,例如 48 小时或 3 个工作日。请求可以升级到审批人的经理、重新分配给备用审批人,或自动取消。
最后,为每个决定定义状态。保持标签简短且一致:
当审批逻辑以这种方式书写时,构建者的猜测空间就小了,工作流也更可靠。
如果想要一致的行为,就给每条规则相同的结构。混杂的写法常常造成混杂的结果。
一个简单格式适用于大多数场景:触发器、条件、动作、结果。它既短又清楚,便于他人稍后审阅。
把每条规则保持在独立的一行、卡片或区块中。不要把好几个想法塞在同一段里。如果一条规则同时涉及定价、审批和例外,就很难测试也容易读错。
一个实用的模板如下:
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 并填写简短备注(客户名或出差目的)时适用。
这比写 "特殊情况可允许" 更可靠,因为例外绑定了明确条件。
审批逻辑也可以保持同样的平实:
可以用几个简单案例测试规则。周常日的一笔 $36 餐费且附有凭证应被批准。出差日的 $60 餐费若标记了旅行并填写备注则应通过。常日的 $60 餐费应被拒绝或退回修改。$650 的酒店费应通过三步审批流。
目标是:用真实案例测试时,规则每次都应给出相同结果。
一条规则看起来对人清楚,但仍会让构建者困惑,这通常发生在文档含糊、把多个想法混在一起,或前后不一致时。
常见错误之一是把几条规则塞进一段长句。例如:"经理审批差旅,除非金额很高,财务核凭证,紧急请求可跳过复核。" 这看似简洁,但掩盖了多个独立决策。把它们拆成独立规则,使每个动作都有明确触发和结果。
另一个问题是模糊用语。像 正常、大额、紧急、近期 之类的词只在被定义时才有用。如果 "大额费用" 指 $2,000 以上,就写清楚。如果 "紧急" 意味着需要在 24 小时内处理,也要写明条件。
缺失数据也是导致坏结果的重要原因。团队常描述顺利路径,却忘了说明信息不全或错误时应如何处理。如果请求没有金额、没有部门或没有凭证,规则应说明下一步。
最常造成麻烦的错误通常是:
最终审批权比许多团队想象的更重要。如果经理和财务复核意见不一致,谁做最终决定?如果没人拥有最终步骤,应用可能停滞或在流程中转圈。
术语变换会产生隐蔽错误。如果你开始称之为 "request",后来又叫它 "submission" 或 "ticket",读者可能以为是不同对象。选一个术语并在整份文档中保持一致。
在基于聊天的构建器里这点尤为重要,因为平实语言直接驱动行为。清晰的规则不必显得正式,只要具体、一致并完整。
在把需求变成界面、流程或提示前,再做最后审查。现在做一次短检查可以省下修复奇怪行为的大量时间。
让每条规则都可测试。每条规则应以明确结果结束,比如是或否、批准或拒绝、收取费用或不收取。如果两个人读同一句话会给出不同答案,这条规则还需完善。
把每个计算都写清楚。命名输入、公式以及何时计算。补充四舍五入、货币、日期处理,以及当值缺失或为零时的处理。
把例外分开。先写默认规则,再把例外独立写出。主要的支出限额不应埋在承包商、紧急采购或预先批准出差的特殊情况中。
绘出完整审批路径。为每个阈值说明谁批准、接下来如何处理。对边界也要精确说明:规则是从超过 $500 开始,还是 $500(含)开始?
然后做个新人测试。把规则交给没参与过的人,让他们用自己的话复述。如果他们需要额外上下文,规则仍然太模糊。
一个小例子说明其重要性。"经理审批大额费用" 听起来清楚,直到有人问 $500 是否算大额。写成 "经理审批超过 $500 的费用。主任审批超过 $2,000 的费用。$500 或以下费用自动批准" 就更少出错。
规则清楚后,与每天使用该流程的人一起复核。经理、协调员、财务人员和审批人常会注意到文档中未写出的细节,这些细节通常决定应用是顺手还是令人恼火。
把规则文档当作工作指南,而不是一次性的草稿。它应说明会发生什么、谁来决定、有哪些例外以及信息缺失时应用应做什么。
在构建完整应用之前,用最近的真实场景测试几例。包含顺利通过的案例和混乱的案例:一条应通过的标准请求、一条缺失信息的请求、需要人工复核的例外,以及跨越支出限额或审批阈值的案例。
这一步可以提前发现漏洞。一条纸面上看似清楚的规则,遇到真实请求不符合预期时可能就会失效。
当这些场景都能按规则运行后,把它们放入构建器。如果你使用像 Koder.ai 这样的基于聊天的平台,清晰的规则集能让构建更快,因为你是在把已定义的流程翻译成界面、动作和审批,而不是在构建时临时决策。
上线后,将文档作为事实来源保留。当策略变化、添加新的审批人或更新限额时,先改文档再改应用。这样以后的修改更简单,也降低了不同人记忆规则不一致的风险。
一个小习惯有帮助:流程变更时就审查规则,而不是等到应用出问题才改。及早做小更新要比后来修复混乱行为容易得多。
如果文档保持最新,应用随着时间会更容易测试、改进并值得信赖。