企业软件：让 AI 写代码前，先解决业务规则冲突

返回

Kevin Riedl

13 分钟 阅读 · 2026 年 10 月 12 日
最近审核 2026年10月12日

下一篇

退款功能看起来已经可以交给 AI 编程智能体：购买后未满 30 天，就符合退款条件。随后，销售转来一份 60 天退款承诺。财务询问金额是否超过 €5,000。客服则解释，客户成功团队一直可以批准例外。

工程师能写出判断条件。公司还得先就这个条件的含义达成一致。

这是一个虚构的企业流程。一位合规同事接受现有做法，另一位认为它违反了某项政策，可谁也找不到文件。销售的承诺来自一篇作者已经离职的 Confluence 页面。每个部门都希望新软件延续自己理解的规则。

业务规则冲突，是指针对同一项业务决策存在彼此不兼容的指令。要解决冲突，需要查证依据、找到有权决策的人，并明确争议个案该如何处理。生成更多代码无法补上这项决策权限。

企业系统同样有复杂的工程问题，安全和分布式状态就是例子。本文讨论的是更早的一道关口：公司愿意为哪一种系统行为负责。下文的退款期限和审批门槛均为示例公司规则，不代表法定退款权利。

先建立业务规则冲突清单

把各方主张分别记录下来，再整理成需求规格。一段流畅的文字可能掩盖分歧，一张小表却能把它暴露出来。针对每个待决定的问题，保留原始表述、来源版本和受影响的交易。

先核对适用范围。30 天的默认期限与已经确认的 60 天承诺，可以分别适用于不同的购买。财务审批回答的则是另一个问题。把两条指令判定为矛盾之前，先确认它们针对的是同一笔交易、同一项决定。

旧文档是需要核查的依据。文档年代久远，并不自动使客户承诺失效。同样，例外反复发生，也不能证明员工有权作出那些决定。找不到文件，意味着问题仍未解决。

NASA《系统工程手册》明确将利益相关方的冲突解决与决策权限的归属联系起来。这里也适用同一个基本方法：指出究竟哪项决定还没有作出。

为每项冲突指定负责人、决策期限和临时处理方式。如果一笔正在处理的退款受到尚有争议的销售承诺影响，就将它转入约定的复核流程。为这个队列安排负责人和升级处理时限，并兼顾适用的客户处理期限。

为每项决定明确权限归属

为具体决定选择负责人，并记录其授权范围。“由业务方决定”无法把责任落实到任何人。

Atlassian 的 DACI 框架区分了推动决策的人、批准决策的人、提供意见的人，以及需要获知结果的人。这样，协调者可以组织证据收集，而不会在无人察觉的情况下变成政策审批人。

在退款示例中，财务负责人决定付款审批规则。获得授权的商务和法务负责人确定哪些客户承诺适用。指定的政策负责人定义特殊情况，并明确谁有权批准例外。产品负责人在这些授权范围内协调最终流程。

按需参与的首席产品官，即 Fractional CPO，可以让未决事项变得清晰，并协调后续工作。这个角色本身不会自动获得豁免财务或合规要求的权限。如果一项决定需要多方批准，就分别写明审批人和审批顺序。

记录商定的规则、理由、必要审批、受影响的客户群体和生效日期。附上来源链接，并明确由谁持续维护。即使最初参与会议的人都已离开，产品负责人仍应能解释这条规则为什么存在。

协商受阻时，向具备相应权限的人提交一个具体选择。例如：“这些购买涉及有争议的 60 天承诺。在合同负责人确定适用范围期间，是否先将它们转入复核队列？”与笼统要求各方统一退款意见相比，这个问题更容易形成决定。

分别判断退款资格和付款审批

一笔退款即使符合退款条件，也可能必须获得财务批准后才能执行付款。把两个问题压成一个布尔值，很容易丢掉审批要求。

假设示例中的负责人批准了以下有限范围：针对一笔已结算、金额为正数的欧元购买，办理一次全额退款；该购买此前没有退款，也不存在正在处理的争议。其他情况转入另有负责人承担的复核流程。下面的决策表是建议性示例，并非生产政策，也不代表已经执行的退款系统。

在这个示例中，购买记录指明适用的已批准政策版本，以及 30 天或 60 天的期限。只有经过有权人员复核、确认该笔购买适用相应承诺后，才能采用 60 天期限。尚未确认的承诺继续留在复核流程。

计时从购买完成开始，到收到退款申请时结束。时间以 UTC 时间戳记录，并按每段 24 小时计算经过的天数。因此，“未满 30 天”不包括恰好 30 天。这些都是为示例明确选定的规则；你的公司仍须决定自己的起算事件、时区和边界。

经过时间为负数、时间戳缺失，或例外审批权限未经核实，都属于未解决的数据问题。已批准的例外必须指明对应购买，并在处理该申请时仍然有效。已经过期、被撤销、互相冲突或与个案不匹配的例外批准，应转入 REVIEW。NOT_ELIGIBLE 只描述本次政策判断；如果合同权利或强制性权利存在争议，应交由相应人员复核。

接下来单独判断付款审批。在这个示例范围内，门槛以已结算的欧元购买毛额为准。恰好 €5,000 并不大于 €5,000。在加入部分退款或其他币种之前，负责人必须先定义相应的金额口径。

在这个示例中，CSM 批准的超期退款例外，绝不能代替财务批准。“可进入付款前检查”也不表示资金已经付出。执行授权、重复申请和付款失败，仍需要工程实现与验证。

OMG 的决策模型与标记法（DMN）为表达决策提供了标准。团队也可以先用电子表格厘清这些条件，再选择执行引擎。

规则顺序需要单独检查。根据 Camunda 对命中策略的说明，Unique 最多允许一条规则匹配，First 返回第一条匹配规则的结果。两者都不会替公司决定哪项业务政策应当优先。

本文的表格用于解释规则，并非可执行的 DMN。实施前，应验证准备支持的所有输入组合。没有任何规则匹配时，需要定义结果；采用 Unique 时，兜底行不能与常规行重叠。通过调整行顺序消除表面冲突，可能在无人确认的情况下赋予某项业务主张优先权。

把有争议的边界写成验收示例

在开始实施之前，请负责人批准具体的输入与结果组合。以下示例用于检查前文作出的选择。它们是建议的验收案例，不是已经执行并通过的测试结果。

把这些示例附在决策记录中。开发者可以将获批的输入与结果组合转成测试；审核者也能从失败的测试追溯到它所保护的业务决定。

还应测试表格未覆盖的组合，包括无效输入和互相冲突的审批。当付款执行进入范围后，再补充其失败和重复执行案例。将这些控制与退款资格示例分开，避免把政策测试通过误认为付款集成已经安全。

让 AI 整理依据，并实施已经获批的决定

用 AI 查找矛盾、准备备选方案，并将获批决定转成代码和测试。编程智能体可以承担其中大量工作。规则依据什么权限生效，仍由组织决定。

决策前，可以让助手比较获准使用的来源材料，保留日期和原文，并标出缺失的定义。它可以发现一份文件写着“购买金额”，另一份却写着“退款金额”；也可以补出会上无人讨论过的 €5,000.01 边界案例。

可以这样提出分析任务：

比较这些退款资料。列出相互冲突的主张，并注明来源、版本、生效日期和受影响的客户群体。区分已记录的决定、假设和历史惯例。指出每个问题需要由谁解决。草拟边界案例；如果缺少有权人员作出的决定，就将预期结果保留为待定。

负责人批准规则后，再把带版本的决策记录和验收示例交给编程智能体。要求它遇到新歧义时明确提出，不要按文档的新旧或出现频率自行选择政策。仅从同一份含有未决问题的提示词生成测试，可能只是重复同一个假设。

我们的GitHub Spec Kit 生产实践指南讨论后续的规格、计划与实施流程。规格背后的业务争议有了负责人和明确结果，规格才更有用。

发布后继续维护决策依据

把已批准的规则发布到销售、客服和工程团队实际使用的位置。实施软件时，同步更新销售指引和客服说明。清晰标注已经被替代的材料，同时保留解释早期购买所需的历史记录。

NASA 的需求管理指南将获批变更与影响评估、可追溯记录联系起来。落实到这个流程，就是确定规则变化会影响哪些客户、操作指引和测试。

记录中应保留规则 ID、版本、负责人、审批依据和生效范围，并链接到验收示例与实施变更。新的 30 天政策可以适用于未来购买，而此前某个客户群体继续保留已经确认的 60 天期限。

为临时例外设置到期条件或复核触发条件。关注未决个案已经等待多久，以及员工为何将申请转入复核。反复出现的例外可能说明规则需要重新考虑，应通过可见的变更申请提交给规则负责人。

我们的面向 AI 的企业知识库指南讨论如何维护经过确认的知识。需求探索阶段指南则介绍如何通过更完整的合作流程，把产品问题转成双方认可的工作范围。

衡量 AI 编程是否改善了这个流程时，除了实施时间，还要跟踪等待决策的时间，以及规则澄清后造成的返工。如果代码写得更快，审批却仍无结果，交付瓶颈依然清晰可见。

从一项大家存在分歧的决定开始。带齐互相冲突的依据，找到有权决策的负责人，一起走查边界示例。团队由此获得明确的实施目标，也知道为什么可以信任它。

企业业务规则冲突：常见问题