--- title: "企业业务规则冲突：让 AI 写代码前如何解决" canonical: https://wavect.io/zh/blog/enterprise-business-rule-conflicts/ language: zh description: "企业自动化之前如何解决业务规则冲突？通过退款决策表，明确规则负责人、政策版本、适用范围与验收示例，分别判断退款资格和财务审批，避免让 AI 替公司猜测政策。" image: "https://wavect.io/img/blog/headers/header_enterprise-business-rule-conflicts.png" author: ["Kevin Riedl"] published: "2026-10-12" updated: "2026-10-12" reviewed: "2026-10-12" --- # 企业软件：让 AI 写代码前，先解决业务规则冲突 [**返回**](/zh/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/zh/team/kevin-riedl/) [Kevin Riedl](/zh/team/kevin-riedl/) https://linkedin.com/in/wsdt 13 分钟 阅读 · 2026 年 10 月 12 日 最近审核 2026年10月12日 [**下一篇**](/zh/blog/github-spec-kit-production-guide/) 要点速览 解决业务规则冲突，应先记录各方主张及其来源，指定有权决策的负责人，明确生效范围和例外，并在实施前批准具体示例。本文的虚构退款流程把时间上的退款资格与财务审批分开：超期退款例外不能免除超过 €5,000 时所需的财务批准。尚未确定是否适用的客户承诺进入有明确负责人的复核流程。AI 可以暴露矛盾并实施已批准的规则，决策权限仍由组织赋予。 退款功能看起来已经可以交给 AI 编程智能体：购买后未满 30 天，就符合退款条件。随后，销售转来一份 60 天退款承诺。财务询问金额是否超过 €5,000。客服则解释，客户成功团队一直可以批准例外。 工程师能写出判断条件。公司还得先就这个条件的含义达成一致。 这是一个虚构的企业流程。一位合规同事接受现有做法，另一位认为它违反了某项政策，可谁也找不到文件。销售的承诺来自一篇作者已经离职的 Confluence 页面。每个部门都希望新软件延续自己理解的规则。 **业务规则冲突，是指针对同一项业务决策存在彼此不兼容的指令。**要解决冲突，需要查证依据、找到有权决策的人，并明确争议个案该如何处理。生成更多代码无法补上这项决策权限。 企业系统同样有复杂的工程问题，安全和分布式状态就是例子。本文讨论的是更早的一道关口：公司愿意为哪一种系统行为负责。下文的退款期限和审批门槛均为示例公司规则，不代表法定退款权利。 ## 先建立业务规则冲突清单 **把各方主张分别记录下来，再整理成需求规格。**一段流畅的文字可能掩盖分歧，一张小表却能把它暴露出来。针对每个待决定的问题，保留原始表述、来源版本和受影响的交易。 先核对适用范围。30 天的默认期限与已经确认的 60 天承诺，可以分别适用于不同的购买。财务审批回答的则是另一个问题。把两条指令判定为矛盾之前，先确认它们针对的是同一笔交易、同一项决定。 | 主张 | 需要收集的依据 | 尚待决定的问题 | | --- | --- | --- | | 购买后未满 30 天可以退款。 | 已批准的政策、生效日期，以及从哪个事件开始计时。 | 哪些购买适用这个期限？恰好到期时如何处理？ | | 销售承诺了 60 天退款。 | 带日期的销售页面，以及向相关客户实际作出的承诺。 | 哪些承诺适用？谁有权解决适用范围的争议？ | | 客户成功经理（CSM）可以批准例外。 | 授权文件和已经记录的例外案例。 | 谁可以批准例外？适用于什么理由、金额和具体购买？ | | 金额超过 €5,000 需要财务批准。 | 审批政策、金额的定义，以及现任规则负责人。 | 门槛针对购买金额还是退款金额？是否严格按“大于”判断？ | | 合规同事意见不一。 | 所声称的义务、其依据，以及有权解释该义务的人。 | 由谁确定解释？在此之前，正在处理的申请怎么办？ | 旧文档是需要核查的依据。文档年代久远，并不自动使客户承诺失效。同样，例外反复发生，也不能证明员工有权作出那些决定。找不到文件，意味着问题仍未解决。 [NASA《系统工程手册》](https://www.nasa.gov/reference/4-0-system-design-processes/) 明确将利益相关方的冲突解决与决策权限的归属联系起来。这里也适用同一个基本方法：指出究竟哪项决定还没有作出。 为每项冲突指定负责人、决策期限和临时处理方式。如果一笔正在处理的退款受到尚有争议的销售承诺影响，就将它转入约定的复核流程。为这个队列安排负责人和升级处理时限，并兼顾适用的客户处理期限。 ## 为每项决定明确权限归属 **为具体决定选择负责人，并记录其授权范围。**“由业务方决定”无法把责任落实到任何人。 [Atlassian 的 DACI 框架](https://www.atlassian.com/team-playbook/plays/daci) 区分了推动决策的人、批准决策的人、提供意见的人，以及需要获知结果的人。这样，协调者可以组织证据收集，而不会在无人察觉的情况下变成政策审批人。 在退款示例中，财务负责人决定付款审批规则。获得授权的商务和法务负责人确定哪些客户承诺适用。指定的政策负责人定义特殊情况，并明确谁有权批准例外。产品负责人在这些授权范围内协调最终流程。 按需参与的首席产品官，即 Fractional CPO，可以让未决事项变得清晰，并协调后续工作。这个角色本身不会自动获得豁免财务或合规要求的权限。如果一项决定需要多方批准，就分别写明审批人和审批顺序。 记录商定的规则、理由、必要审批、受影响的客户群体和生效日期。附上来源链接，并明确由谁持续维护。即使最初参与会议的人都已离开，产品负责人仍应能解释这条规则为什么存在。 协商受阻时，向具备相应权限的人提交一个具体选择。例如：“这些购买涉及有争议的 60 天承诺。在合同负责人确定适用范围期间，是否先将它们转入复核队列？”与笼统要求各方统一退款意见相比，这个问题更容易形成决定。 ## 分别判断退款资格和付款审批 **一笔退款即使符合退款条件，也可能必须获得财务批准后才能执行付款。**把两个问题压成一个布尔值，很容易丢掉审批要求。 假设示例中的负责人批准了以下有限范围：针对一笔已结算、金额为正数的欧元购买，办理一次全额退款；该购买此前没有退款，也不存在正在处理的争议。其他情况转入另有负责人承担的复核流程。下面的决策表是建议性示例，并非生产政策，也不代表已经执行的退款系统。 在这个示例中，购买记录指明适用的已批准政策版本，以及 30 天或 60 天的期限。只有经过有权人员复核、确认该笔购买适用相应承诺后，才能采用 60 天期限。尚未确认的承诺继续留在复核流程。 计时从购买完成开始，到收到退款申请时结束。时间以 UTC 时间戳记录，并按每段 24 小时计算经过的天数。因此，“未满 30 天”不包括恰好 30 天。这些都是为示例明确选定的规则；你的公司仍须决定自己的起算事件、时区和边界。 | 条件 | 资格结果 | 理由 | | --- | --- | --- | | 必要事实、适用政策或授权尚未明确；或者个案超出范围。 | `REVIEW` | 需要由有权复核的人补齐并确认决策依据。 | | 必要事实、适用政策和授权均已明确，且个案在范围内；申请时经过的时间少于获批期限。 | `ELIGIBLE` | 适用标准期限，或已经确认的 60 天承诺。 | | 必要事实、适用政策和授权均已明确，且个案在范围内；期限已过；针对该笔购买的有效例外已获批准。 | `ELIGIBLE` | 获授权批准的例外只改变时间上的退款资格。 | | 必要事实、适用政策和授权均已明确，且个案在范围内；期限已过；例外申请尚待决定。 | `REVIEW` | 由例外审批负责人作出决定。 | | 必要事实、适用政策和授权均已明确，且个案在范围内；期限已过；没有提出例外申请，或申请已被拒绝。 | `NOT_ELIGIBLE` | 已记录的政策依据没有赋予退款资格。 | 经过时间为负数、时间戳缺失，或例外审批权限未经核实，都属于未解决的数据问题。已批准的例外必须指明对应购买，并在处理该申请时仍然有效。已经过期、被撤销、互相冲突或与个案不匹配的例外批准，应转入 `REVIEW`。`NOT_ELIGIBLE` 只描述本次政策判断；如果合同权利或强制性权利存在争议，应交由相应人员复核。 接下来单独判断付款审批。在这个示例范围内，门槛以已结算的欧元购买毛额为准。恰好 €5,000 并不大于 €5,000。在加入部分退款或其他币种之前，负责人必须先定义相应的金额口径。 | 条件 | 下一状态 | 需要采取的行动 | | --- | --- | --- | | 资格结果为 `REVIEW`。 | 业务复核 | 交由指定负责人解决个案，并跟踪回复期限。 | | 资格结果为 `NOT_ELIGIBLE`。 | 规则判定结果 | 说明理由，以及对结果提出异议的途径。 | | 符合退款条件，金额为正数且不超过 €5,000。 | 可进入付款前检查 | 继续执行独立的付款控制流程。 | | 符合退款条件，金额超过 €5,000，但财务批准缺失、待定或无效。 | 等待财务批准 | 就该笔购买及金额申请必要审批。 | | 符合退款条件，金额超过 €5,000，且有效的财务批准已记录。 | 可进入付款前检查 | 继续执行独立的付款控制流程。 | | 符合退款条件，金额超过 €5,000，但财务拒绝批准。 | 审批问题升级处理 | 由有权负责人处理拒绝理由；系统不能悄悄改变退款资格。 | 在这个示例中，CSM 批准的超期退款例外，绝不能代替财务批准。“可进入付款前检查”也不表示资金已经付出。执行授权、重复申请和付款失败，仍需要工程实现与验证。 [OMG 的决策模型与标记法（DMN）](https://www.omg.org/spec/DMN/1.5/) 为表达决策提供了标准。团队也可以先用电子表格厘清这些条件，再选择执行引擎。 规则顺序需要单独检查。根据 [Camunda 对命中策略的说明](https://docs.camunda.io/docs/8.9/components/modeler/dmn/decision-table-hit-policy/) ，`Unique` 最多允许一条规则匹配，`First` 返回第一条匹配规则的结果。两者都不会替公司决定哪项业务政策应当优先。 本文的表格用于解释规则，并非可执行的 DMN。实施前，应验证准备支持的所有输入组合。没有任何规则匹配时，需要定义结果；采用 `Unique` 时，兜底行不能与常规行重叠。通过调整行顺序消除表面冲突，可能在无人确认的情况下赋予某项业务主张优先权。 ## 把有争议的边界写成验收示例 **在开始实施之前，请负责人批准具体的输入与结果组合。**以下示例用于检查前文作出的选择。它们是建议的验收案例，不是已经执行并通过的测试结果。 | 申请情况 | 预期结果 | 暴露出的决策点 | | --- | --- | --- | | 适用 30 天期限，已过 29 天 23:59:59，金额 €100。 | 符合退款条件；可进入付款前检查。 | 严格的时间边界。 | | 适用 30 天期限，恰好已过 30 天，没有例外。 | 不符合本政策的退款条件。 | 恰好 30 天与未满 30 天不同。 | | 已确认适用 60 天期限，已过 45 天，金额 €100。 | 符合退款条件；可进入付款前检查。 | 适用的客户承诺。 | | 已确认适用 60 天期限，恰好已过 60 天，没有例外。 | 不符合本政策的退款条件。 | 更长的期限也需要明确边界。 | | 适用 30 天期限，已过 31 天，有有效例外，金额 €6,000，尚无财务批准。 | 符合退款条件；等待财务批准。 | 例外改变退款资格，不改变付款权限。 | | 适用 30 天期限，已过 31 天，例外申请待定。 | 转入复核。 | 尚未答复的申请不等于批准。 | | 已过 10 天，金额 €5,000。 | 符合退款条件；可进入付款前检查。 | 恰好 €5,000 没有超过门槛。 | | 已过 10 天，金额 €5,000.01，尚无财务批准。 | 符合退款条件；等待财务批准。 | 超过门槛的第一个欧分。 | | 销售声称承诺了 60 天，但该承诺是否适用仍未确定。 | 转入复核，并指定负责人和期限。 | 缺少授权依据不能变成自动批准或自动拒绝。 | | 购买后政策发生变化，但该笔购买仍适用此前版本。 | 按记录中适用的版本判断。 | 新编辑的页面不会改写已经确定的政策依据。 | 把这些示例附在决策记录中。开发者可以将获批的输入与结果组合转成测试；审核者也能从失败的测试追溯到它所保护的业务决定。 还应测试表格未覆盖的组合，包括无效输入和互相冲突的审批。当付款执行进入范围后，再补充其失败和重复执行案例。将这些控制与退款资格示例分开，避免把政策测试通过误认为付款集成已经安全。 ## 让 AI 整理依据，并实施已经获批的决定 **用 AI 查找矛盾、准备备选方案，并将获批决定转成代码和测试。**编程智能体可以承担其中大量工作。规则依据什么权限生效，仍由组织决定。 决策前，可以让助手比较获准使用的来源材料，保留日期和原文，并标出缺失的定义。它可以发现一份文件写着“购买金额”，另一份却写着“退款金额”；也可以补出会上无人讨论过的 €5,000.01 边界案例。 可以这样提出分析任务： > 比较这些退款资料。列出相互冲突的主张，并注明来源、版本、生效日期和受影响的客户群体。区分已记录的决定、假设和历史惯例。指出每个问题需要由谁解决。草拟边界案例；如果缺少有权人员作出的决定，就将预期结果保留为待定。 负责人批准规则后，再把带版本的决策记录和验收示例交给编程智能体。要求它遇到新歧义时明确提出，不要按文档的新旧或出现频率自行选择政策。仅从同一份含有未决问题的提示词生成测试，可能只是重复同一个假设。 我们的 [GitHub Spec Kit 生产实践指南](/zh/blog/github-spec-kit-production-guide/) 讨论后续的规格、计划与实施流程。规格背后的业务争议有了负责人和明确结果，规格才更有用。 ## 发布后继续维护决策依据 **把已批准的规则发布到销售、客服和工程团队实际使用的位置。**实施软件时，同步更新销售指引和客服说明。清晰标注已经被替代的材料，同时保留解释早期购买所需的历史记录。 [NASA 的需求管理指南](https://www.nasa.gov/reference/6-0-crosscutting-technical-management/) 将获批变更与影响评估、可追溯记录联系起来。落实到这个流程，就是确定规则变化会影响哪些客户、操作指引和测试。 记录中应保留规则 ID、版本、负责人、审批依据和生效范围，并链接到验收示例与实施变更。新的 30 天政策可以适用于未来购买，而此前某个客户群体继续保留已经确认的 60 天期限。 为临时例外设置到期条件或复核触发条件。关注未决个案已经等待多久，以及员工为何将申请转入复核。反复出现的例外可能说明规则需要重新考虑，应通过可见的变更申请提交给规则负责人。 我们的 [面向 AI 的企业知识库指南](/zh/blog/ai-ready-company-wiki/) 讨论如何维护经过确认的知识。 [需求探索阶段指南](/zh/software-development-guide/what-is-a-discovery-phase/) 则介绍如何通过更完整的合作流程，把产品问题转成双方认可的工作范围。 衡量 AI 编程是否改善了这个流程时，除了实施时间，还要跟踪等待决策的时间，以及规则澄清后造成的返工。如果代码写得更快，审批却仍无结果，交付瓶颈依然清晰可见。 从一项大家存在分歧的决定开始。带齐互相冲突的依据，找到有权决策的负责人，一起走查边界示例。团队由此获得明确的实施目标，也知道为什么可以信任它。 ## 企业业务规则冲突：常见问题 ### 自动化之前，如何解决相互冲突的业务规则？ 逐项记录主张、来源、版本和受影响的交易。确认有权决策的负责人及必要审批，商定规则、生效范围和未决个案的处理方式，再批准具体示例，之后才进入实施。 ### 企业软件中的业务规则应该由谁负责？ 由对该项决定拥有授权的个人或角色负责。产品负责人可以协调流程；财务负责财务审批；相应的商务或法务负责人解决客户承诺问题。应记录授权范围和升级处理路径。 ### AI 能决定哪份政策文档正确吗？ AI 可以比较来源、识别矛盾，也可以应用已经明确批准的优先级规则。但生成一个答案，本身并不会赋予组织层面的决策权限。如果适用规则仍有争议，就应保留不确定性，并交给相应负责人处理。 ### 业务规则决策记录应包含什么？ 记录问题、规则 ID 和版本、负责人、来源、理由、审批、受影响的客户群体、生效日期、例外审批权限及验收示例。将记录链接到实施变更，并在变更时通知受影响的团队。 ### 每个企业流程都需要使用 DMN 引擎吗？ 不需要。讨论规则时，一张经过审核的小表格可能已经足够。是否引入执行引擎，是另一项架构决定。无论采用什么实现，都必须保留已批准的优先级，并处理事实缺失、条件重叠和未覆盖的情况。 ### 政策决定尚未明确时，团队应该怎么办？ 采用明确获得授权的临时处理流程，指定负责人、回复期限和升级处理方式。不要把不确定性变成自动拒绝或批准。临时流程必须考虑适用的客户义务，并在决定作出后重新评估。 产品战略 ## 接下来读什么 范围、产品市场匹配、可信版本与打造有用产品的关键决策。 [从这里开始**一条可衡量的产品市场契合之路**](/zh/blog/road-to-product-market-fit/) - [Scope 与 Armature：衡量智能体 API 采用，而不只是品牌提及](/zh/blog/scope-vs-armature-agent-api-adoption/) - [AI MVP 范围：验收标准、评测集与 SoW](/zh/blog/ai-mvp-scope-template/) - [2026 年在奥地利做一个 AI MVP 要多少钱？](/zh/blog/ai-mvp-cost-austria-2026/) - [我们交付的产品：结果基准能证明什么](/zh/blog/products-shipped-failure-benchmark/) - [一条可衡量的产品市场契合之路](/zh/blog/road-to-product-market-fit/) [下一篇文章**Scope 与 Armature：衡量智能体 API 采用，而不只是品牌提及**](/zh/blog/scope-vs-armature-agent-api-adoption/) [**返回**](/zh/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/zh/team/kevin-riedl/) [Kevin Riedl](/zh/team/kevin-riedl/) https://linkedin.com/in/wsdt 13 分钟 阅读 · 2026 年 10 月 12 日 最近审核 2026年10月12日 [**下一篇**](/zh/blog/github-spec-kit-production-guide/)