研发流程规则配置的粒度，可以按“一个规则只回答一类判断”来划分：触发条件、适用范围、动作和例外分别配置，条件层用字段与状态组合，动作层只做一件事，例外单独成条并声明优先级。规则数量增多、出现优先级冲突时，用“全局默认→项目/团队→特殊场景”的分层加唯一优先级编号收敛冲突，同一判断只保留一处定义，其余通过引用复用，规则体系才能长期可维护。
要点总览（TL;DR）
- 粒度划分按“一个规则只回答一类判断”执行：触发条件、适用范围、动作、例外分开配置，动作层一条规则只做一个动作。
- 规则增多后用“全局默认→项目/团队→特殊场景”三层加唯一优先级编号收敛冲突，冲突按条件重叠、动作互斥、顺序依赖三类判定。
- 同一判断只保留一处定义，高频条件组合与标准动作抽取为公共集，其余规则引用复用，变更前先查引用清单确认影响范围。
- 流程负责人、规则配置人、评审人、使用团队各担其责，规则清单、优先级登记表、例外说明和变更记录是维持可维护性的基础交付物。
- 上线前和较大变更后用五项检查核对：单一判断、优先级唯一、无重复定义、例外显式、变更可追溯。
粒度划分的核心答案与操作步骤
粒度划分的判断标准只有一条：一条规则只承担一类判断。所谓“一类判断”，指这条规则回答的是“什么条件下、对哪类对象、做什么动作”中的一个明确命题。如果一条规则同时写了多个触发条件、多个适用团队和多个动作，它在被修改时就会牵一发动全身，冲突也难以定位。按四要素拆分，是把一条复合规则还原为可独立管理的配置单元。
| 要素 | 回答的问题 | 配置内容示例 | 拆分边界 |
|---|---|---|---|
| 触发条件 | 什么事件或状态变化时判断 | 工作项状态从“开发中”变为“待测试” | 只描述事件本身，不写动作 |
| 适用范围 | 对哪些项目、团队、工作项类型生效 | 项目A的缺陷类工作项 | 范围与条件分开配置，便于复用 |
| 动作 | 命中后执行什么 | 自动指派给测试负责人 | 一条规则只做一个动作 |
| 例外 | 哪些情况不执行或改走其他路径 | 紧急缺陷跳过测试指派，直接通知值班人 | 例外独立成条，显式声明优先级 |
从粗到细的拆分按三步推进，每一步都有明确的输入、动作、输出和完成标志。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 第一步：定判断对象 | 现有流程文档、口头约定、历史工单中的流转习惯 | 把每条规则归到“状态流转、字段校验、通知指派、审批触发”等判断类别 | 规则分类清单 | 每条规则能说清它回答哪一类判断，不再出现“综合规则” |
| 第二步：定条件字段 | 规则分类清单、工作项字段定义 | 为每条规则列出触发事件与适用范围字段，条件之间用“且/或”明确关系 | 条件配置表 | 条件可被独立读取和测试，不依赖动作描述才能理解 |
| 第三步：拆动作 | 条件配置表 | 把一条规则中的多个动作拆成多条规则，每条只保留一个动作 | 规则条目集 | 每条规则的动作字段只有一个值，修改动作不影响条件 |
拆分完成后，规则条目会明显增多，这是正常结果。条目增多换来的是每条规则可读、可测、可单独停用。接下来要解决的是这些条目之间的优先级关系，以及如何避免同一判断被反复配置。
规则分层与优先级设计：冲突如何收敛
规则数量增多后，冲突的根源通常不是规则写错，而是多条规则同时命中同一对象。分层结构让“谁优先”在配置阶段就确定下来，而不是等运行时报错再排查。建议分三层：全局默认层放组织级通用规则，项目/团队层放局部差异，特殊场景层放临时或例外安排。层与层之间是覆盖关系，同层之内靠优先级编号区分。
优先级编号建议采用“层级码+序号”的固定格式，例如全局层用G开头、项目层用P开头、特殊场景用S开头，序号在同层内唯一。编号一旦分配不再复用，规则停用后保留编号并标记失效，避免历史记录指向错误规则。唯一性约束要落到登记表上：同一编号只能对应一条规则，同一判断在同一层级只能有一条生效规则。
| 冲突类型 | 典型表现 | 判定方法 | 收敛动作 |
|---|---|---|---|
| 条件重叠 | 两条规则的条件范围有交集，同时命中同一工作项 | 把两条规则的条件字段逐一比对，找出交集对象 | 合并为一条规则，或收窄其中一条的适用范围 |
| 动作互斥 | 同一对象被要求同时指派给两个人或进入两个状态 | 检查命中后的动作结果是否互相排斥 | 保留高层级动作，低层级规则下沉为条件更窄的例外 |
| 顺序依赖 | 两条规则都需执行，但先后顺序影响结果 | 梳理动作之间的前置关系，确认是否存在状态依赖 | 用优先级编号固定执行顺序，或拆成前后两个触发点 |
冲突出现后的收敛动作有三种。合并适用于条件高度相似、动作一致的规则，把条件取并集、动作保留一份。下沉适用于局部团队的特殊要求，把它从全局层移到项目层，并收窄适用范围。显式例外适用于确实无法合并的场景，单独建一条例外规则，写明触发条件、覆盖对象和生效期限，并在登记表中标注它覆盖了哪条基础规则。三种动作的共同要求是：收敛后基础规则仍然保留，例外只做增量覆盖，不复制基础规则的全部内容。
避免重复配置：复用与引用机制
重复配置有两个明显信号。一是相同条件配了不同动作，说明条件被反复抄写，动作却各自为政，后续改条件要改多处。二是相同动作配了多个条件，说明动作逻辑被复制，条件稍有差异就新增一条规则。发现这两类信号，就应把公共部分抽出来单独定义。
公共条件集的做法是把高频出现的条件组合命名保存，例如“进入测试阶段且属于缺陷类”，其他规则直接引用这个条件集，不再逐字段重写。公共动作同理，把“通知测试负责人”“写入待验证状态”等动作定义为可复用动作，规则只负责声明条件与动作的绑定关系。抽取时按使用频次排序，出现三次以上的条件组合或动作就值得抽取。
引用与继承要有边界。可以复用的部分包括：稳定的条件组合、标准动作、组织级通知模板、通用字段校验。必须独立配置的部分包括：涉及审批权限的规则、跨项目的特殊流转、有法务或合规要求的例外、临时性的流程调整。判断标准是变更频率与影响面：一处改动会影响多个团队的，适合抽取复用；只服务单一场景且经常调整的，保持独立反而更安全。
变更前的影响范围检查是复用机制的必要配套。修改一条公共条件集之前，先查引用清单，列出所有引用它的规则、所属项目和生效状态；修改公共动作之前，确认是否有例外规则依赖它的执行结果。检查完成后在登记表中记录变更原因、影响规则数量和回归验证结果，便于后续追溯。
角色分工与交付物
规则体系能否维护，取决于职责是否落到具体角色。流程负责人定边界，规则配置人做拆分与配置，评审人校验冲突与重复，使用团队反馈例外需求。四类角色不必对应四个岗位，小团队可以兼任，但每类职责要有明确的责任人。
| 角色 | 主要职责 | 关键交付物 |
|---|---|---|
| 流程负责人 | 确定规则覆盖的流程范围、分层结构和优先级总原则 | 流程边界说明、分层方案 |
| 规则配置人 | 按四要素拆分规则、分配优先级编号、维护引用关系 | 规则清单、优先级登记表 |
| 评审人 | 检查条件重叠、动作互斥、重复定义和例外合理性 | 评审记录、冲突处理结论 |
| 使用团队 | 提出例外需求、反馈规则误判和遗漏 | 例外说明、问题反馈单 |
规则变更走固定流程：提出变更申请并说明影响的判断类别，配置人评估引用范围并给出修改方案，评审人核对冲突与重复，流程负责人确认分层归属，发布后在登记表更新版本和生效时间。紧急例外可以先行生效，但要在约定时间内补评审，避免例外长期游离在体系之外。
规则最终要落到工作项的状态流转和字段变化上执行。ONES 的工作项类型、状态流转和字段配置可以承载条件与动作的绑定，规则清单和优先级登记表则作为配置之外的说明文档同步维护，让配置改动有据可查。
示例：一条需求流转规则的粒度拆分
假设初始有一条粗规则：“需求评审通过后，自动流转到开发中，指派给开发负责人，并通知产品经理；紧急需求除外。”这条规则同时包含了触发事件、适用范围、三个动作和一个例外，任何一处调整都要改整条规则。
按四要素拆分后，得到以下规则集合（示例情景，用于说明拆分方法）：
| 规则编号 | 触发条件 | 适用范围 | 动作 | 备注 |
|---|---|---|---|---|
| G-001 | 需求状态变为“评审通过” | 全部项目 | 流转到“开发中” | 全局默认 |
| G-002 | 需求状态变为“评审通过” | 全部项目 | 指派给开发负责人 | 引用公共动作“按角色指派” |
| G-003 | 需求状态变为“评审通过” | 全部项目 | 通知产品经理 | 引用公共动作“状态变更通知” |
| S-001 | 需求标记为“紧急”且状态变为“评审通过” | 全部项目 | 跳过G-002的指派，通知值班开发 | 显式例外，优先级高于G-002 |
拆分后出现的冲突是：紧急需求同时命中G-002和S-001，一个要求指派给开发负责人，一个要求跳过指派。处理方式是给S-001分配更高的优先级编号，并在例外说明中写明它覆盖G-002，G-002本身保持不变。这样普通需求走默认路径，紧急需求走例外路径，两条规则的维护互不干扰。
进一步抽取公共条件后，“需求状态变为评审通过”被定义为条件集C-01，G-001、G-002、G-003和S-001都引用它。后续如果评审通过的状态名称调整，只改C-01一处，四条规则同步生效。公共动作“按角色指派”和“状态变更通知”也各自只定义一次，规则条目只保留条件与动作的绑定关系。
完成检查：规则体系是否可维护
粒度划分和冲突处理是否到位，可以用下面这组检查项逐条核对。建议在规则上线前和每次较大变更后各执行一次，检查结果记入规则登记表。
| 检查项 | 核对方法 | 通过标准 |
|---|---|---|
| 每条规则只承担一类判断 | 逐条阅读规则，看是否同时包含多个动作或多个判断类别 | 每条规则的动作字段只有一个值 |
| 优先级唯一且无歧义 | 对照优先级登记表，检查编号是否重复、是否有规则未登记 | 编号唯一，同一判断在同层只有一条生效规则 |
| 不存在重复定义 | 按条件组合和动作分别归并，查找相同条件不同动作、相同动作多条件的情况 | 高频条件与动作已抽取为公共集并被引用 |
| 例外显式声明 | 检查每条例外是否写明覆盖对象、触发条件和生效期限 | 例外可追溯到被覆盖的基础规则 |
| 变更影响可追溯 | 抽查最近几次变更，看是否记录了引用范围和回归结果 | 每次变更都能列出受影响的规则与项目 |
五项全部通过，说明规则体系具备了基本的可维护性：新增规则有位置可放，冲突有编号可判，重复有引用可查，例外有记录可追。若某项不通过，优先回到对应环节修正，而不是靠增加更多规则来掩盖问题。
常见问题
规则拆得越细越好吗？拆到什么程度可以停？
拆分的停止条件是“可独立修改、可独立停用、可独立测试”，并非越细越好。一条规则如果只承担一类判断、动作字段只有一个值，并且修改它不会连带影响其他判断，就达到了合适的粒度。继续往下拆，比如把同一个动作里的通知对象再拆成多条规则，只会增加条目数量和登记负担，对冲突定位没有帮助。
实际操作中可以用一个简单判断：当某条规则需要改动时，能否只改这一条而不动其他规则。能，就说明粒度合适；不能，说明它还混着多类判断，需要继续拆。
全局默认规则和项目层规则同时命中时，按什么顺序执行？
按分层覆盖关系执行：特殊场景层优先于项目/团队层，项目/团队层优先于全局默认层；同层之内按优先级编号顺序执行。这样“谁优先”在配置阶段就已确定，运行时不需要临时判断。
需要注意两点。第一，高层级规则只做增量覆盖，不复制基础规则的全部内容，基础规则保持原样，便于追溯。第二，如果两条规则属于顺序依赖而非覆盖关系，比如一条负责流转状态、另一条负责在流转后发通知，应拆成前后两个触发点，用触发时机区分，避免仅靠编号强行排序。
临时性的流程调整怎么配置，才不会污染长期规则体系？
临时调整放在特殊场景层，单独建例外规则，并写明三件事：触发条件、覆盖的基础规则编号、生效期限。到期后由规则配置人复核，确认转为正式规则、并入项目层，还是直接停用。
例外规则停用后保留编号并标记失效，编号不复用，避免历史记录指向错误规则。如果临时调整涉及审批权限或合规要求，即使期限很短也应走一次评审，防止例外长期游离在体系之外。
规则变更后怎么确认没有引发新的冲突？
变更前先查引用清单：列出引用该条件集或动作的所有规则、所属项目和生效状态，评估改动波及的范围。变更后在登记表记录变更原因、影响规则数量和回归验证结果。
回归验证的重点是条件重叠和动作互斥两类冲突：把改动涉及的条件字段与同层其他规则逐一比对，确认没有新增交集；确认命中后的动作结果不互相排斥。顺序依赖类冲突较难通过静态比对发现，建议在测试环境中用典型工作项走一遍流转路径确认。
小团队也需要分层和优先级编号吗？
规则数量少时，分层可以简化。比如只保留全局默认层和例外层两层，优先级编号也只需在例外层内唯一。判断是否需要完整三层结构的依据是：是否存在多个项目或团队有各自的局部差异。只有单一团队、流程一致时，把差异做成例外即可。
无论规模大小，两条约束建议保留：同一判断只保留一处定义，例外显式声明覆盖对象。这两条是后续规则增多时能够平滑扩展的基础，早期省掉，后期补起来成本更高。
