1. 课程导入与全景认知
在开始学习具体规则之前，先建立一张“地图”非常关键。Jira 自动化规则（Automation for Jira）本质上是事件驱动的条件—动作引擎：当某个业务事件发生时，系统判断是否满足预设条件，若满足则执行一系列动作。而流程治理则是围绕工作流、状态、字段、权限、规则建立可预期、可审计、可维护的秩序。两者结合，才能让 Jira 从“记录工具”变成“流程执行平台”。
很多团队第一次接触自动化时，容易把它当成“万能胶”：哪里不顺就加一条规则。结果规则数量膨胀、触发条件重叠、动作互相覆盖，最终没人敢改。要避免这种局面，需要先理解自动化的价值边界：它擅长处理确定性高、重复性强、判断条件清晰的事务，例如状态流转后的字段赋值、到期提醒、跨项目同步、审批结果回写；它不擅长处理需要复杂人工判断、跨系统强一致事务或高频批量计算的任务。把这些边界想清楚，后续的规则设计才有取舍依据。
本节核心认知：自动化规则解决“重复动作与一致性”，流程治理解决“规则该不该存在、由谁维护、如何演进”。没有治理的自动化会变成技术债，没有自动化的治理则难以落地。
从 Jira 生态的位置来看，自动化规则位于业务事件与执行动作之间。上游是问题创建、字段变更、状态流转、评论、附件、冲刺开始等事件源；下游是字段更新、状态转换、通知、创建子任务、调用 Webhook、发送邮件等动作。规则本身不改变 Jira 的数据模型，但它能改变数据流动的路径和时机。因此，理解自动化必须同时理解 Jira 的工作流、权限方案、字段配置和项目角色，否则规则很容易被权限拦截或与工作流校验冲突。
下面这张全景图展示了自动化规则在 Jira 生态中的位置，以及本课程后续要覆盖的主要知识域。图中左侧是事件源，中间是规则引擎的判断与执行，右侧是动作与治理闭环，底部是贯穿始终的治理维度。
理解这张图后，再来看适用场景。自动化规则最适合三类场景：第一类是状态驱动的一致性维护，例如问题从“待处理”转为“处理中”时，自动记录开始时间并通知负责人；第二类是跨项目、跨角色的信息同步，例如客户支持项目创建高优先级问题时，自动在研发项目创建关联任务并回写链接；第三类是时间与阈值驱动的提醒，例如问题超过 3 天未更新时提醒经办人，超过 7 天升级给项目经理。这三类场景的共同点是：触发事件明确、判断条件可枚举、动作结果可验证。
反过来，以下情况应谨慎使用自动化：需要人工判断的复杂决策、涉及财务或权限的强一致操作、高频批量数据处理、以及没有明确责任人的“无人认领”规则。一个实用的判断标准是：如果这条规则失效，业务是否能被人工兜底？如果答案是否定的，说明它已经进入关键路径，必须配套监控和告警，而不是默默运行。
治理视角的提醒：每条自动化规则都应能回答四个问题——谁负责、为什么存在、触发条件是什么、失效后如何发现。回答不了，就说明它还不具备上线条件。
从学习路径上看，本课程会沿着“认知—配置—治理—实战”推进。先掌握触发器、条件、动作三要素，再学习分支、智能值、查找问题等进阶能力；随后进入流程治理，讨论命名规范、作用域划分、权限控制、变更记录和监控指标；最后通过跨项目同步、审批流、SLA 提醒等综合案例，把规则设计与治理动作串起来。需要强调的是，自动化规则不是越多越好，可维护性本身就是设计目标之一。一条命名清晰、条件收敛、动作单一的规则，远比十条互相纠缠的规则更有价值。