企业 AI 项目 Wiki · 需求与业务场景

业务规则

也常写作Business rule · 业务判断规则 · 业务约束 · 决策规则

定义

业务规则是由组织负责制定、采用或执行，用来界定业务概念、约束可接受状态与行为，或根据已知事实得出业务结论的可管理陈述。它应具有明确权威来源、适用范围、输入事实、结果、例外、优先关系和版本，使人员与系统能够一致判断、执行、解释和复核。

业务规则表达组织认定的必须、禁止或必然关系

“提高审批效率”是目标，“处理采购申请”是流程或能力，“金额超过部门限额的申请必须由预算负责人会签”才接近业务规则。规则把组织认可的概念、事实与判断关系说清楚，使相同条件在人员办理、系统实现、测试和审计中得到一致解释。

业务规则属于业务管辖，不属于某个软件。规则可以由人员手工执行、写进操作说明、配置在决策服务中或实现为代码；系统只是执行方式。把规则只留在 if 语句里，会丢失权威来源、业务理由、例外、版本和非技术人员的确认能力。

并非每条政策都能直接执行。政策可能表达方向或原则，规则需要足够具体，使组织能判断某个事实状态或行为是否符合要求。法律和合同也通常需要结合适用对象、日期、地区和有权解释形成内部可执行规则，项目团队不能自行作法律结论。

业务规则有哪些常见类型

提到业务规则，很多人先想到金额超过多少就升级审批。真实项目里的规则远不止条件分支：它还决定一个词怎样定义、一个对象何时有效、某个角色能不能行动，以及事实不足时应停在哪里。先分清规则类型，后面才知道该向谁确认、用什么方式实现。

定义性规则

规定业务概念、分类和事实必然怎样成立，例如“只有状态为已批准且未过期的授权才是有效授权”。它支持术语一致、数据解释和推理。

行为性规则

规定组织或角色必须做、不得做或在何种条件下可以做什么，例如“申请人与批准人不得为同一人”。违反后需要阻止、告警、例外批准或补救。

资格与适用规则

根据角色、对象、地区、时间、状态和证据判断谁或什么符合某项资格、政策、价格或处理路径。必须说明缺少事实时的结果。

分类与派生规则

从已有事实推导业务类别或属性，例如根据金额、品类和风险标记申请等级；派生结果要说明来源事实和有效时间。

计算规则

规定金额、费率、分值、期限或数量怎样计算，包括单位、精度、舍入、币种、日期边界、缺失值和计算顺序。公式只是表达形式，业务含义仍需说明。

决定与路由规则

把输入事实和业务知识组合成批准、拒绝、会签、升级、队列或下一处理人的结论。一个决定可能依赖多组规则和权威来源。

状态转换规则

规定业务对象在什么条件下可以从一个状态进入另一个状态、由谁执行以及产生什么记录；流程显示顺序，规则决定转换是否允许。

例外与覆盖规则

说明哪些正常规则可以在何种理由、权限、时限和证据下被覆盖，覆盖后怎样复核和回到正常状态。例外不能只写“特殊情况另议”。

一条可管理的业务规则要记录什么

一条判断句即使听起来合理，也未必能直接交给系统执行。团队还要知道它来自哪里、对谁生效、需要哪些事实、遇到例外怎么办，以及多年后怎样还原当时的决定。下面这些信息共同构成一条可以长期维护的规则。

稳定编号与规则名称

分配可引用 ID，用业务结论命名；不要用代码行号或决策表行号充当长期身份。

规则陈述与类型

用业务术语写出单一、明确、可执行的必要性、义务、禁止或推导关系，并标记定义、行为、资格、计算、决定等类型。

权威来源与负责人

记录法律、合同、制度、委员会决定、产品政策或业务授权，以及有权解释和批准的人；区分原始来源、内部转写和技术实现。

适用范围与生效时间

说明组织、地区、产品、角色、对象、渠道、币种、日期、版本和业务场景，包含开始、结束及过渡安排。

输入事实与数据定义

列出判断所需事实、来源、类型、单位、允许值、时效和缺失处理；输入含义不稳定时，规则结果也不可复现。

条件、结论与动作边界

分开判断条件、业务结论和系统可能执行的动作。规则得出“需会签”不等于系统已经发送任务或取得批准。

例外、优先与冲突处理

说明例外条件、覆盖权限、特定规则与一般规则谁优先、多个规则结论冲突时停止还是交由谁决定。

解释与通知

规定哪些角色需要看到适用规则、输入事实、结论理由和下一步，哪些内容因隐私、安全或反欺诈不能直接公开。

测试、版本和状态

记录代表例、边界、反例、验证负责人、草案/批准/停用状态、生效版和变更历史，使旧决定可以按当时规则重放。

怎样发现和确认真实业务规则

业务规则通常不会整齐地待在一份文件里。制度写了原则，授权表保存限额，办理人员掌握例外，旧系统又藏着多年形成的判断。发现规则的工作，是把这些线索放在一起核对，并让真正有权负责的人确认最终含义。

确定决定和业务对象
先列出项目必须一致回答的资格、金额、状态、路由和限制问题，明确谁对决定负责；不要从数据库字段或现有代码开始。
收集权威材料
核对法律法规、合同、制度、授权表、产品政策、表单、操作说明和历史决定，记录版本、生效范围与有权解释人。
访谈实际执行与监督人员
让办理人、批准人、合规、财务、运营和审计说明正常判断、例外、争议和补救，区分正式规则、地方做法、个人习惯与系统限制。
观察案例和运行记录
抽取批准、拒绝、退回、升级、撤回和异常样本，比较相同事实是否产生不同结果；差异可能揭示隐藏规则、数据问题或未经批准的偏差。
统一业务词汇
在写规则前定义申请、有效授权、工作日、金额、客户状态等术语和数据口径，解决同名异义与异名同义。
写出原子规则和依据
把复合段落拆成单一判断，关联权威来源和业务理由；不确定内容标为待确认，而不是在代码中自行选择。
用例子、反例和边界回放
让有权人员对典型、临界、缺失、冲突和例外事实逐项判断，确认规则集合得到唯一、完整或明确停止的结果。
批准基线并指定维护责任
记录当前有效规则集、优先关系、生效日期、批准人和变更入口；业务、规则管理员和技术实现者的责任分别明确。

决策表怎样帮助检查规则，而不是取代规则治理

当条件逐渐增多，纯文字很难看出哪些组合重叠、缺失或互相冲突。决策表能把输入和结论摊开检查，却不会自动证明其中的数字、优先级和解释已经获得授权。它是发现逻辑问题的工具，不是业务责任的替身。

输入列是否是稳定事实？
每列具有明确名称、类型、允许值、来源和时间语义，避免把自由文本或未经确认的模型输出直接当条件。
核对：业务词汇表与数据定义。
每一行条件是否互相可区分？
检查重叠条件会不会同时命中不同结论，以及是否用明确命中策略处理多条匹配。
核对：重叠分析与命中策略。
所有组合是否有结果？
缺口应有明确默认、资料不足、不可决定或人工处理结果，不能悄悄落入第一条或空值。
核对：完整性分析和未命中测试。
边界和单位是否精确？
大于、至少、日期截止、时区、币种、舍入和空值必须明确，防止临界值在不同系统中产生不同决定。
核对：边界值和单位测试。
输出是结论还是动作？
决策表可以得出“需会签”，执行任务、通知和写回仍需流程、权限与错误处理；不要把决定成功等同于副作用成功。
核对：决定—流程—动作映射。
来源、版本和解释是否保留？
每条逻辑能够回到规则 ID 和权威来源，运行结果记录规则集版本、输入与命中路径。
核对：决策日志与版本清单。

一组采购审批规则可以怎样表达

下面用一组独立构造、与任何客户无关的采购规则，把前面的结构连起来。重点不在具体金额或制度，而在于看清定义、职责分离、事实不足和优先关系怎样共同得出一个决定，以及这个决定为什么仍不等于系统动作已经完成。

BR-101：有效申请定义

在本构造规则集中，采购申请只有在申请人身份有效、成本中心有效、用途已填写且当前品类要求的证明齐全时，才属于可提交申请。

BR-102：职责分离

采购申请的最终批准人不得是该申请的申请人；代理提交时，实际操作者与被代理申请人都要记录，且代理不改变自批禁止。

BR-103：会签资格

当可提交申请的含税金额超过该成本中心当前直接批准限额时，业务结论为“需要预算负责人会签”；限额数值、币种和生效日由独立授权表提供。

BR-104：事实不足

若金额币种、成本中心限额或适用规则版本无法确认，系统不得推断会签结论，应停止提交或转有权人员处理并记录缺失事实。

BR-105：规则优先

若品类专项规则要求会签，即使金额未超过一般限额也需会签；若专项与法规或合同来源冲突，停止自动决定并进入合规处理。

决定与执行分开

规则集得出“可提交”“需会签”或“不可决定”。创建审批任务、通知负责人、占用预算和写入状态由流程与系统要求控制，并分别处理失败。

必要测试

覆盖限额下、等于、超过、币种缺失、规则切换日、申请人与批准人相同、专项规则、冲突来源和重复请求，并记录规则集、输入、命中规则与结果。

业务规则怎样形成可审计、可变更的基线

规则会随政策、产品和组织责任变化，问题不在于它会不会变，而在于变化之后还能不能说明新旧版本分别处理了哪些事项。把规则做成基线，是为了让报价、实现、验收和生产运行引用同一个可识别版本，也让历史决定能够按当时条件复核。

建立规则登记与词汇表
集中维护规则 ID、陈述、类型、术语、权威、负责人、范围、版本、状态、依赖、测试和实现位置，避免制度、表格、配置和代码各有一套。
分开业务所有权与技术实现
业务或合规权威批准规则含义，技术团队负责可靠实现并报告限制；规则平台管理员不能因能改配置就自动拥有政策决定权。
批准可识别规则集
报价、设计、验收和生产运行引用明确规则集版本及其来源快照，不使用“当前线上逻辑”作为无法复现的基线。
实现多处时保持一致
前端提示、后台校验、批处理、报表和 AI 工具如果都使用规则，应采用单一权威服务或自动一致性检查，避免用户看到和最终执行不同。
变更前完成影响分析
评估历史数据、进行中事项、接口、权限、通知、培训、测试、价格、AI 评测、回滚和生效过渡，并决定旧事项按旧版还是新版处理。
发布、监控和回退
新规则先通过边界与历史回放，发布时记录审批、版本和生效时间，监控决定分布、未命中、冲突和人工覆盖；异常时能停用或恢复已批准规则集。
保留决定可解释性
按隐私与保留政策保存决定时使用的输入事实、规则版本、命中逻辑、覆盖人和理由，使申诉、审计和问题复现不依赖当前规则。

业务规则怎样连接范围、流程、系统和验收

业务规则不是需求阶段的一份附件。它会继续影响系统需要哪些数据、流程在哪个节点分支、接口失败时能否继续、验收怎样构造边界条件，以及上线后由谁维护。项目各环节若引用的不是同一规则版本，单个功能都正常也可能得出不同业务结论。

项目范围

明确本期负责发现、整理、实现、迁移、测试和维护哪些规则，客户或第三方提供哪些权威材料，规则引擎和持续运营费用是否包含。

业务场景与流程

场景提供规则适用的角色、事实和结果；流程在需要判断的位置调用规则并根据结论路由，但不把所有判断埋进流程连线。

需求与设计

从规则派生校验、决定、提示、权限、数据、接口和解释要求；实现可以是人工、代码、配置、决策服务或组合，但须保持同一业务语义。

数据与集成

规则依赖的数据要有权威来源、类型、单位、时效和失败处理，第三方响应变化不能默认为业务规则改变。

测试与验收

从规则产生正例、反例、边界、缺失、冲突、优先、版本切换和权限测试，分别证明规则逻辑、系统动作和业务结果。

上线与运营

确认生产规则集、配置、缓存刷新、权限、监控、日志、人工覆盖、回退和负责人，防止代码上线而规则未同步。

交接与维护

移交词汇表、规则台账、权威来源、决策模型、测试集、发布历史、运行指标和修改流程，使接手团队能安全解释与更新。

企业 AI 中业务规则不能退化成提示词里的几句话

让模型读懂制度、解释规则很有价值，但“模型大概知道”不等于组织已经稳定执行规则。生成结果会受提示词、上下文和模型版本影响；一旦涉及权限、金额、禁止事项或不可逆操作，项目必须把解释能力与最终控制分开。

规则与知识材料分开

知识文档可以解释背景，正式规则要有批准陈述、适用范围和版本。模型从文档推测出的关系不能自动成为授权规则。

不能把高影响判断交给模型临场发挥

模型可以解释为什么一笔申请可能需要会签，却不应凭一次自然语言生成决定是否放款、开放权限或执行不可逆操作。金额阈值、自批禁止和授权边界应由可重复测试的规则或系统控制执行；模型的结论只能进入这些控制允许的位置。

AI 可以辅助但不自动拥有权威

AI 可从材料提取候选规则、解释命中理由或辅助分类，但候选必须由权威人员确认；模型置信度不能替代政策授权。

提示词与规则集分别版本化

提示词可指导表达和工具使用，业务规则作为独立基线维护。运行记录要能识别模型、提示词、知识、规则集和工具版本的组合。

输入事实必须可信

模型生成的类别、摘要或实体在进入高影响规则前，要有来源、结构校验、允许值和必要人工复核，防止把幻觉当作决定事实。

冲突与资料不足要停止

规则来源冲突、版本不明、必需事实缺失、输出超出权限或无法解释命中时，规定拒绝、追问、转人工或阻断动作，不让模型自行补全。

评测覆盖规则组合和对抗输入

除逐条正反例外，测试优先关系、边界、规则变更、提示注入、越权请求、相似措辞和重复运行，分别观察决定正确性与解释一致性。

人工覆盖也受规则治理

允许覆盖时明确角色、理由、时限、二次批准、记录和复核；“人工可以改”不能成为绕过安全和审计的通用后门。

业务规则容易与什么混淆

政策、流程、数据校验和代码条件都可能承载规则的一部分，因此现场沟通很容易把它们当成同一件事。区别不只是名称：一旦把实现方式当作规则本身，团队就可能找不到谁有权批准含义，也无法判断换系统后哪些业务约束仍须保留。

相关概念	与业务规则的区别
业务政策	政策表达方向、原则或治理意图，可能不能直接执行；业务规则把政策落实成可判断的必要、义务、禁止或推导关系。
法律或合同条款	它们是外部或双方权威来源；内部业务规则是组织在确认适用性和解释后形成的执行陈述，不能由项目团队自行替代法律判断。
业务需求	业务需求说明组织要达到的结果；规则约束达到结果时哪些状态、行为和判断可接受。
业务流程	流程组织事件、活动、角色、消息和顺序；规则决定某一步是否允许、如何分类或走哪条路径，同一规则可被多个流程使用。
操作规程	规程告诉人员怎样一步步工作，可引用许多规则；规则本身通常不规定所有操作顺序和界面动作。
数据校验	校验检查格式、范围或一致性，可以实现业务规则，也可能只是技术完整性检查。手机号格式正确不证明客户具备业务资格。
权限策略	权限策略控制主体对资源的访问与动作；它可以实现部分行为规则，但业务规则还覆盖定义、资格、计算和非访问决定。
算法或模型	算法规定计算过程，模型从数据产生输出；业务规则表达组织认可的约束或结论。模型输出是否可用于决定仍需规则。
决策表或规则引擎	决策表是表达和分析逻辑的形式，规则引擎是执行技术；它们不自动提供权威来源、语义、批准、例外和治理。
验收标准	验收标准规定某交付对象怎样判定通过；它可以检查规则是否正确实现，但不等于长期治理的业务规则本身。

依据与适用边界

本文解释企业项目中的业务规则：在组织业务管辖范围内，对术语与事实、允许状态、义务、禁止、资格、计算和决定作出的明确规则。它不是政策目标、法律原文、业务需求、业务流程、操作步骤、权限配置、数据校验、算法、决策表、规则引擎、验收标准或代码条件本身。法律、合同和政策可以成为规则权威来源，但转写与适用解释必须由有权业务、合规或法律人员确认。本文不提供法律意见，文中独立构造的规则也不直接适用于任何真实组织。