提醒开关越加越多，相关配置却散落在工作流、消息中心各处，管理员改一条规则都要翻遍模块。规则中心把"何时由系统替谁做什么"抽成可测试、可发布的独立产品，而非把更多开关塞进一个页面。

项目管理软件做久了，总会收到几类很像的需求：需求进入“待评审”后通知产品负责人；缺陷超过截止日期后提醒经办人；所有子任务完成后自动关闭父工作项。

第一条需求很好做。在状态修改逻辑后面加一次通知，后台再放一个开关，很快就能上线。第二条也不难，增加一个每天扫描超期对象的任务。等第三条、第四条继续进来，问题才开始变味：有的规则藏在工作项类型里，有的挂在工作流步骤后面，有的写在消息中心，还有一些只有研发知道。

管理员想改一条规则，不知道应该去哪个页面；普通用户看到状态突然变化，不知道是谁改的；产品经理想回答“这个空间里到底有哪些自动操作”，只能把几个模块的配置拼在一起。

这时真正需要设计的已经不是更多开关，而是一款独立产品：让管理员把“什么时候，由系统替谁做什么”配置成一条可以测试、发布和解释的规则。

这就是自动化规则中心存在的原因。但它不是把所有通知和工作流后置动作都搬进一个页面，而是把其中已经需要独立触发条件、作用范围和运行记录的部分，提升为可以单独管理的规则。个人订阅和通用触达策略仍可以留在消息中心，特定步骤不可缺少的结果仍然属于工作流，真正跨出原配置边界的行为才进入自动化。

01 通知、步骤后置动作和自动化会重合，但不能混成一种配置

最容易让三者打架的，是一句看起来很简单的需求：缺陷“验证通过”后，通知提出人。

它至少有三种合理做法。

如果只是提出人订阅了缺陷状态变化，产品解决的是“我想收到哪些消息”。配置可以放在个人订阅或消息策略里，重点是接收人、渠道、合并、免打扰和送达结果。通知失败不应推翻已经成立的“验证通过”。

如果组织规定每一次“验证通过”都必须告知提出人，这条动作就和业务步骤绑在一起。它应该配置在“验证通过”的步骤执行后，跟随工作流一起发布和变更。无论用户从详情页、看板还是 API 执行这个步骤，都得到相同结果；但它不会自己观察截止日期，也不会因为另一条关联任务完成而启动。

如果规则变成“只有严重缺陷验证通过，并且来自外部客户时，通知客户协作群，同时创建一条复盘任务”，它已经拥有独立条件、跨对象动作和单独的停用需求，更适合做成自动化规则。此时“验证通过”只是触发时机，规则可以独立于工作流修改，也要拥有自己的负责人、测试和执行记录。

三者真正的边界，不看最后是不是发了一条消息，而看为什么启动、配置归谁、跟谁一起发布，以及失败后影响什么。

从产品层级看，通知与提醒是触达能力，工作流后置动作是步骤上的执行位置，自动化规则是独立的条件编排能力。 后两者都可以调用通知；工作流步骤成功可以触发自动化；自动化也可以执行一个合法流转步骤，并继续触发该步骤的后置动作。它们可以串起来，但不能各自保存一份“验证通过后通知提出人”，否则同一个人可能收到三条消息，管理员还找不到真正的配置来源。

页面名称和最终动作都不能决定归属。一条自动化规则即使最后只发通知，只要它可以独立设置条件、范围和启停，仍然是自动化；一条工作流后置动作即使带有简单条件，只要它只能依附某个步骤存在，仍然属于工作流。反过来，如果某个所谓“后置动作”失败后这次流转就不应该成立，例如目标状态、关键字段和下一负责人必须共同保存，那它就不该作为可异步失败的后置动作，而应该进入步骤的核心结果。

实际判断时，我会按这个顺序问：这件事是否与某个业务步骤不可分割，而且每次合法执行都必须发生？是，就归工作流步骤。否则，它是否只是接收人的消息偏好，业务判断已经固定？是，就归通知与提醒。只有当它需要独立条件、作用范围、跨对象动作、非工作流触发或单独运行治理时，才升级成自动化规则。

先把角色分开，后面的设计才不会混在一起：

规则中心出现后，也不意味着所有旧入口都要消失。通知订阅继续留在消息页面，固定后置动作继续跟随工作流，独立规则进入自动化中心；平台可以提供一张“自动行为清单”，让管理员看见它们分别来自哪里。如果工作流页面提供“创建自动化”的快捷入口，它编辑的也必须是规则中心里的同一个规则对象，不能悄悄复制第二份配置。

同一个事件产生两条通知也不一定是错的。例如组织要求发送一条不可关闭的验收通知，提出人又主动订阅了全部状态变化，两条消息代表的是两个不同意图。平台不应该只看文案相似就强行合并，但在发布新规则时，应提示相同触发时机、接收人和动作附近已经存在什么配置，并给出来源链接。所谓“一个权威来源”，限制的是同一业务意图不能被复制三次，不是限制一个事件只能产生一个后果。

02 先判断什么值得自动化，而不是看什么能够自动化

自动化最容易走向两个极端。一种是只敢发通知，最后变成另一个消息中心；另一种是什么都想让系统决定，连本来需要人承担责任的判断也塞进规则。

产品经理接到自动化需求时，我更建议先问三个问题：开始执行的时机能否明确观察，是否执行能否用数据判断，执行结果能否被系统确认。

“严重缺陷超过截止日期仍未解决时，通知质量负责人并创建一条风险项”适合自动化，因为时间、判断条件和跨对象动作都很明确。“版本延期时自动判断应该砍掉哪些需求”就不适合，它涉及业务价值、客户承诺和团队成本，没有一条稳定公式可以替代负责人做决定。

同样是系统自动做事，几种产品能力解决的问题也不同：

边界划清后，自动化的产品定位就简单了：它不是一名会思考的虚拟项目经理，而是一名严格按规则办事的执行者。

对于只在单个页面发送一条低风险提醒的需求，也不必急着建设规则中心。一个开关就能解决、配置不会增加、失败后人工补发也没有明显损失时，保留简单方案反而更好。只有当规则开始增多、跨对象、需要用户自行配置，或者用户必须知道“为什么执行”时，独立自动化产品才值得出现。

判断一项能力是否应该独立成产品，不看研发是否为它单独做了一个引擎，而看用户是否已经需要围绕它完成独立任务。当一条规则需要被查找、理解、测试、负责、观察和停用时，它就不再是某个功能背后的附属开关，而应该成为一个可以单独保存和管理的产品对象。

03 把一句需求拆开，才知道规则后台要保存什么

下面用一条规则贯穿全文：

一个严重缺陷处于“待验证”，当最后一个必要测试任务完成时，如果全部必要测试任务都已完成，系统自动执行“验证通过”。

这句话看起来已经很完整，但直接交给研发，至少还会出现七个问题：这条规则叫什么？在哪些项目里生效？什么叫“任务完成”？只检查严重缺陷吗？系统怎样执行验证通过？用谁的权限？失败后找谁？

因此，一条规则不只是“触发器、条件、动作”三个节点。作为可长期管理的产品对象，它至少需要保存七类信息：

触发器和条件很容易混淆。触发器只负责把规则叫醒，条件才决定这一次要不要做事。比如“任一必要测试任务完成”可以叫醒规则，但只有最后一个任务完成时，“全部必要测试已完成”这个条件才成立。

如果把所有判断都塞进触发器，管理员会得到几十个越来越具体的触发选项；如果所有事件都叫醒所有规则，系统又会产生大量无意义检查。更容易理解的产品设计是：触发器只描述明显的开始时机，条件负责继续检查这一次涉及的工作项。

动作也不应该只是“修改字段”。在前一篇状态机文章里，缺陷从“待验证”进入“验证通过”是一项业务步骤，可能要求验证结果、检查权限并记录谁完成了验证。自动化应选择“执行验证通过步骤”，而不是偷偷把状态字段改成另一个值。这样，手动操作与自动操作服从的是同一套产品规则。

04 流程图只是编辑器，完整产品还要覆盖规则的一生

很多自动化方案先画一张漂亮的拖拽画布，然后把项目称为“自动化中心”。但对管理员来说，画出规则只是一次任务的中间部分。

他真正要完成的是：找到已有规则，判断能否复用；新建并配置规则；用真实对象验证；确认影响范围后发布；上线后查看有没有命中；规则失败时定位原因；业务不再需要时停用并归档，同时保留必要的执行历史。

所以，一个能独立使用的自动化后台至少要覆盖四类工作面：规则列表、规则编辑、测试与发布、执行与诊断。

规则列表先帮助管理员做判断

管理员打开规则中心，第一眼不需要看规则流程图，而是要回答：哪些规则正在运行，谁负责，影响哪里，最近是否正常。

一行规则可以展示名称、启停状态、作用范围、业务负责人、上次运行时间和近期异常。列表还应支持按空间、对象类型、负责人和健康状态筛选。否则规则逐渐增多后，后台只是把过去散落在多个页面的混乱，搬进了一张更长的表格。

创建入口最好同时提供模板和空白规则。模板解决的是高频场景，例如“即将到期时提醒负责人”“所有子任务完成后关闭父项”；空白规则给高级管理员保留自由组合。模板不能生成一条无法理解的黑盒规则，选中后仍要展开成普通触发器、条件和动作，让用户能够继续修改。

编辑器用“当、如果、那么”说人话

管理员并不是在画系统架构，他是在表达一条业务规则。比起一上来展示节点类型，更自然的语言是：

• 当 哪件事发生；
• 如果 当前对象满足哪些要求；
• 那么 系统替我执行什么。

这三个部分可以用表单，也可以用流程图呈现。产品形态没有唯一答案。表单适合线性规则，填写成本低；画布适合分支较多的规则，能看见先后关系。真正重要的是，用户每选一个字段，都能看懂它来自哪个对象；每加一个动作，都能看到将修改谁。

作用范围、执行身份和异常负责人不应该藏在“高级设置”最深处。它们不决定规则逻辑，却决定事故半径。一个逻辑完全正确的规则，如果作用到错误空间，仍然是一条错误规则。

测试不是“语法检查通过”

管理员点击发布前，最想知道的不是表达式有没有写错，而是：它会命中哪些真实对象，会修改什么，哪些对象为什么没有命中。

规则测试至少应该给用户两个层次。第一层是预览：选择一条近期操作或一个测试对象，展示触发器是否匹配、每个条件的判断结果、准备执行的动作，但不产生真实修改。第二层是真实试运行：在明确提示后，对测试空间或指定对象执行一次，验证权限、字段映射、通知和外部连接。

这两个按钮必须写清后果。飞书项目公开资料里的“运行测试”会让字段、状态、人员修改和创建工作项等操作在当前空间真实生效。如果产品也采用这种方式，就不能只用一个轻飘飘的“测试”按钮让管理员误以为不会写数据。

发布确认页还应汇总作用范围、执行身份、可能修改的内容，以及能够估算时的近期命中量。低风险通知可以快速发布；跨空间批量修改、创建对象或调用外部系统的规则，则需要更强提示，必要时增加审核。

执行记录要回答“为什么没有发生”

只有失败日志还不够。自动化最常见的疑问其实是：“我明明改了状态，为什么规则没有运行？”

诊断入口需要沿用户的理解顺序回答：近期是否观察到匹配的触发时机，规则是否覆盖当前作用范围，哪个条件没有通过，动作执行到哪里，最终改了什么。未观察到触发时机时，不能伪造一条执行记录；规则已经开始判断后，则应为测试对象、近期异常和管理员主动追踪的对象保留条件结果。这样既能解释“为什么没发生”，也不必永久保存每一次无意义的过滤。

普通用户不需要进入规则后台，但他应该在工作项历史里看到“由自动化规则‘全部测试完成后验证通过’执行”，并能打开规则说明。自动化减少的是人工操作，不是操作的可解释性。

05 用一个缺陷，走完从配置到生效的过程

现在把前面的产品对象和页面串起来。

管理员先从规则列表新建一条空白规则，填写名称“全部必要测试完成后验证通过”，业务负责人选择测试流程管理员，作用范围限定为当前研发空间的严重缺陷。

在编辑器里，他完成三段配置：

1. 当 关联关系为“必要测试”的测试任务进入完成状态；

2. 如果 来源缺陷仍处于待验证、严重等级满足要求，并且全部必要测试任务都已完成；

3. 那么 对来源缺陷执行“验证通过”步骤，并在缺陷历史中记录自动化来源。

随后，他选择两条测试数据。缺陷 A 有三项必要测试，三项都已完成，预览结果显示三个条件均通过，准备执行验证通过。缺陷 B 还有一项测试进行中，预览停在“全部必要测试完成”条件，并明确显示“一共 4 项，已完成 3 项”。

这个“3/4”比一句“条件不满足”有用得多。前者告诉管理员应该检查哪条关系和哪个任务，后者只证明系统替他做了一次他无法复核的判断。

真实试运行时，如果执行身份没有完成验证的权限，系统应该在发布前暴露问题，而不是等第一次生产触发后才失败。管理员修正身份或缩小范围，再发布规则。

发布以后，普通用户看到缺陷进入验证通过，并在历史里看到规则名称；管理员在执行记录里看到触发对象、条件结果、执行动作和最终状态。到这里，一条自动化规则才真正形成产品闭环。

06 分支、关联对象和模板，都是被新问题逼出来的

第一版自动化只做“一个触发、几个条件、一个动作”并没有问题。高级能力应该在真实规则变复杂后逐步出现，而不是一开始就把编辑器做成编程工具。

当同一事件需要根据不同情况执行不同动作，产品才需要条件分支。例如严重缺陷全部测试完成后进入验证，高风险缺陷还要额外通知质量负责人。没有分支时，管理员只能复制两条规则，公共条件修改后还要维护两份。

当动作不再只修改触发对象，产品才需要关联对象分支。测试任务完成后要修改来源缺陷，父项关闭后要通知未完成子项的负责人，需求进入开发后要创建测试计划。此时编辑器必须持续提示“当前正在读取谁、准备修改谁”，否则用户很容易在父项、子项和关联项之间选错字段。

当多个团队反复创建相同规则，产品才需要模板。模板可以由组织管理员维护一份推荐逻辑，新空间从模板创建后再填写本地负责人和通知群。模板是减少重复配置的起点，不等于所有实例永远强绑定；是否跟随模板更新，需要像配置中心一样明确说明。

当规则跨空间复用，才需要更严格的作用范围、版本和变更影响分析。管理员修改组织级规则前，应看到哪些空间正在使用、近期大约命中多少对象、哪些字段或步骤在目标空间不存在。灵活度越高，发布前解释成本也越高。

这条演进路径有一个很实用的判断：如果一个高级能力还找不到明确的管理员任务，就先不要做。支持任意脚本、无限嵌套和复杂变量，看起来更像平台，实际可能把原本应该易懂的规则产品变成只有少数人敢维护的低代码开发环境。

07 可靠性问题最终也要变成用户能处理的产品状态

产品文章不需要展开消息队列和重试算法，但不能假装规则只会成功。只要系统开始替人修改业务数据，运行中的异常就必须被翻译成管理员看得懂、接得住的状态。

这里最重要的产品决定，是不要把所有异常都压成红色的“执行失败”。有些执行根本没有命中，有些被规则主动跳过，有些只完成了一部分，还有些系统暂时不知道结果。状态不同，管理员下一步要做的事也不同。

责任也要在产品里落到人。业务负责人解释规则为什么存在；空间管理员处理范围和权限；外部连接负责人维护账号与接口；平台管理员处理大面积积压或系统故障。把所有通知都发给最初创建规则的人，只是把责任设计推迟到事故发生以后。

08 主流产品的差异，不只在能配置多少动作

把 Jira、ONES、飞书项目和 TAPD 的公开资料放在一起看，它们都已经超过了“状态变化后发通知”这一层，但侧重点不同。

竞品比较的目的不是抄一张功能清单，而是检查自己的产品有没有漏掉用户任务。一个产品支持一百种动作，却没有负责人、测试和执行记录，管理员依然不敢放心启用；另一个产品动作不多，但规则能解释、能停用、出错有人接，反而更适合先进入生产。

公开手册能够证明的是产品暴露了哪些配置和运行行为，不能反推出内部采用什么技术架构。产品设计需要关心用户能否完成任务，技术方案则应在这些产品合同确定后另行设计。

09 从提醒开始，但第一版也要形成最小闭环

自动化产品不需要一次建成规则平台。更稳妥的方式是按照动作风险和管理复杂度逐步扩展。

第一阶段，做好单空间提醒。 支持少量状态变化和时间提醒，动作只发送通知。即使这一版很小，也应有统一规则列表、业务负责人、启停状态和执行记录。最小产品不是只有编辑表单，而是用户能创建、验证、观察和停止一条规则。

第二阶段，允许受控修改。 增加字段修改、状态流转和创建对象。因为动作开始改变业务数据，这一阶段必须补齐执行身份、真实试运行、冲突反馈和工作项历史。验收标准不是“动作调用成功”，而是用户能确认系统改了什么、为什么有权改。

第三阶段，连接更多对象。 增加条件分支、关联对象、外部连接和模板。此时一次执行可能影响多条工作项，需要展示预计影响范围、部分成功和人工处理入口。

第四阶段，进入组织治理。 当规则跨空间复用、数量持续增加，再建设版本、影响分析、健康状态、批量停用和所有者治理。规则数量还少、并且只作用于单个空间时，复杂的组织模板和审批流可能比规则本身更难维护。

每一阶段都应该有对应指标。提醒阶段看触发是否按时到达、用户是否能解释未触发原因；写入阶段看重复结果和冲突处理；连接阶段看部分成功是否及时解决；治理阶段看无负责人、长期失败和长期不命中的规则数量。没有这些基线，“自动化节省了多少人力”通常只是一句无法复核的宣传。

10 回到产品设计：先让规则可理解，再让它足够强大

设计一套自动化产品时，可以先用几个问题做检查：

自动化产品真正困难的地方，不是把“当、如果、那么”画成三个节点。那只是规则最容易看见的一部分。

更重要的是让一条规则从创建开始就有明确范围和负责人，发布前能够验证，运行后能够解释，业务不再需要时能够安全退出。做到这些，项目管理软件才不只是替用户少点几次按钮，而是开始可靠地执行团队已经明确的协作规则。

下一篇，我们再把这些规则连接到代码仓库、测试、流水线和发布系统。到那时，系统不仅知道“应该做什么”，还要知道代码是否真的合并、测试是否真的通过、制品是否真的部署。