流程自动化执行日志的价值，在于让一次规则触发的执行过程可以追溯、可以复盘。本文给出一份可直接参照填写的日志示例，以“一次规则触发的完整执行”为记录单元，按触发条件、输入数据、规则判断、执行动作、结果状态、异常与人工介入六段组织字段，并用“需求评审通过后自动创建测试任务”这一演示情景给出已填写的条目，逐项说明取值依据与迁移方法。
要点总览（TL;DR）
- 流程自动化执行日志以“一次规则触发的完整执行”为记录单元，按触发、输入、规则判断、执行动作、结果状态、异常与人工介入六段组织字段，同一条规则多次触发就产生多条日志，用执行批次号区分。
- 示例采用“需求评审通过后自动创建测试任务”的演示情景，给出正常执行、条件不满足跳过、失败后重试成功三条已填写日志，可直接对照填写。
- 必填字段以“缺了这条信息是否还能还原执行过程”为划分依据，异常信息与人工介入正常时可留空，一旦出现异常必须填写。
- 迁移到其他规则驱动流程时保留六段结构与四种结果状态，替换触发事件、输入数据和执行动作，条件复杂时增加分支明细，异常按失败类型分类。
- 本文覆盖规则明确、条件可判定的流程；AI 智能编排与系统接口对接的日志需求不在范围内，日志保留周期与权限需按组织实际确定。
示例要解决什么问题：日志记录的目标与字段框架
流程自动化跑起来之后，常见的问题是“结果不对但说不清哪一步出的问题”。执行日志要解决的就是这个问题：把一次规则触发拆成可核对的环节，让执行人、流程维护者和后续接手的人都能从日志里还原当时发生了什么。这份示例的目标有两个：一是让单次执行可追溯，能定位到具体是触发、判断还是动作环节出了偏差；二是让多次执行可复盘，能按规则、按时间段统计成功与失败的比例，判断规则本身是否需要调整。
记录单元建议统一为“一次规则触发的完整执行”。同一条规则在一天内触发多次，就产生多条日志，每条日志用执行批次号区分。这样做的原因是：流程自动化的问题往往与具体输入有关，按批次记录才能把输入数据和执行结果对应起来；如果把多次执行合并成一条汇总日志，出问题时无法定位到是哪一次输入导致的。
字段框架按六段组织，每段承担不同的记录任务。下表给出字段清单与必填划分，示例取值来自下一节的演示情景。
| 字段名 | 含义 | 必填 | 示例取值 |
|---|---|---|---|
| 执行批次号 | 本次执行的唯一标识，用于关联同一批次的所有记录 | 必填 | EXE-20250612-0037 |
| 规则名称与版本 | 触发的规则标识及配置版本，便于区分规则改动前后的执行差异 | 必填 | 需求评审通过自动建测试任务 v1.2 |
| 触发事件 | 触发本次执行的事件来源与事件类型 | 必填 | 需求工作项状态由“评审中”变更为“评审通过” |
| 触发时间 | 事件发生并被规则捕获的时间 | 必填 | 2025-06-12 10:14:22 |
| 输入数据 | 参与判断的业务对象及其关键字段值 | 必填 | 需求编号 REQ-1042；所属项目“支付网关”；优先级“高”；负责人“张明” |
| 规则判断 | 条件命中情况与判断依据 | 必填 | 命中：项目属于“支付网关”且优先级为“高” |
| 执行动作 | 实际执行的动作及作用对象 | 必填 | 创建测试任务 TASK-2087；发送通知给测试负责人“李华” |
| 结果状态 | 本次执行的最终状态 | 必填 | 成功 |
| 异常信息 | 失败或重试的原因描述 | 选填（异常时必填） | 首次创建超时，第 2 次重试成功 |
| 人工介入 | 是否有人工处理及处理内容 | 选填 | 无；或“流程维护者王强确认重试结果” |
| 执行耗时 | 从触发到结果落定的时间 | 选填 | 1.8 秒 |
必填与选填的划分依据是“缺了这条信息是否还能还原执行过程”。执行批次号、规则版本、触发事件、输入数据、规则判断、执行动作、结果状态这七项缺任何一项，复盘时都会出现断点，因此列为必填；异常信息、人工介入、执行耗时属于补充说明，正常执行时可以留空，但一旦出现异常就必须填写，否则无法解释状态变化的原因。
完整示例：需求评审通过后自动创建测试任务
以下情景为演示设定，用于说明日志的填写方式，不代表任何真实客户案例或实测结果。情景设定：某研发团队配置了一条规则，需求工作项评审通过后，若该需求属于核心项目且优先级为高，则自动创建测试任务并通知测试负责人；其他情况跳过并记录原因。
规则定义分三部分。触发条件：需求工作项状态由“评审中”变更为“评审通过”。判断条件：所属项目在核心项目清单内，且优先级为“高”。执行动作：在测试项目中创建测试任务，标题沿用需求标题并加“测试”前缀，指派给该需求的测试负责人，同时发送站内通知。
下面三条日志分别对应正常执行、条件不满足跳过、执行失败后重试成功三种情况。
日志条目一：正常执行
| 字段 | 取值 |
|---|---|
| 执行批次号 | EXE-20250612-0037 |
| 规则名称与版本 | 需求评审通过自动建测试任务 v1.2 |
| 触发事件 | 需求 REQ-1042 状态由“评审中”变更为“评审通过” |
| 触发时间 | 2025-06-12 10:14:22 |
| 输入数据 | 需求编号 REQ-1042；标题“支付回调重试机制优化”；所属项目“支付网关”；优先级“高”；测试负责人“李华” |
| 规则判断 | 命中。项目“支付网关”在核心项目清单内；优先级为“高”，两项条件均满足 |
| 执行动作 | 创建测试任务 TASK-2087，标题“支付回调重试机制优化-测试”，指派给李华；发送站内通知给李华 |
| 结果状态 | 成功 |
| 异常信息 | 无 |
| 人工介入 | 无 |
| 执行耗时 | 1.8 秒 |
日志条目二：条件不满足跳过
| 字段 | 取值 |
|---|---|
| 执行批次号 | EXE-20250612-0041 |
| 规则名称与版本 | 需求评审通过自动建测试任务 v1.2 |
| 触发事件 | 需求 REQ-1051 状态由“评审中”变更为“评审通过” |
| 触发时间 | 2025-06-12 11:02:07 |
| 输入数据 | 需求编号 REQ-1051；标题“帮助中心文案修订”；所属项目“官网内容”；优先级“中”；测试负责人“未设置” |
| 规则判断 | 未命中。项目“官网内容”不在核心项目清单内；优先级为“中”，不满足“高”的条件 |
| 执行动作 | 无动作执行，记录跳过 |
| 结果状态 | 跳过 |
| 异常信息 | 无（非异常，属条件未命中） |
| 人工介入 | 无 |
| 执行耗时 | 0.2 秒 |
日志条目三：执行失败后重试成功
| 字段 | 取值 |
|---|---|
| 执行批次号 | EXE-20250612-0055 |
| 规则名称与版本 | 需求评审通过自动建测试任务 v1.2 |
| 触发事件 | 需求 REQ-1063 状态由“评审中”变更为“评审通过” |
| 触发时间 | 2025-06-12 14:31:45 |
| 输入数据 | 需求编号 REQ-1063；标题“对账文件解析异常处理”；所属项目“支付网关”；优先级“高”；测试负责人“赵磊” |
| 规则判断 | 命中。项目与优先级条件均满足 |
| 执行动作 | 第 1 次尝试创建测试任务，调用超时未返回；第 2 次重试创建成功，生成 TASK-2091，指派给赵磊；通知发送成功 |
| 结果状态 | 成功（经 1 次重试） |
| 异常信息 | 第 1 次创建请求超时，超时阈值 10 秒；重试间隔 30 秒；第 2 次成功 |
| 人工介入 | 无（重试由规则自动完成） |
| 执行耗时 | 42.6 秒（含重试等待） |
三条日志放在一起可以看出记录单元的作用：条目一说明规则在正常路径上工作；条目二说明规则没有误触发，跳过原因写清楚后，业务方不会误以为漏建任务；条目三说明失败被捕获并自动恢复，异常信息里保留了超时阈值和重试间隔，后续排查同类问题时有据可查。
逐项解释：每个字段为什么这样填
照抄示例容易，理解取值依据才能在自己团队里填对。下表挑出容易出错的字段，说明填写理由和常见错误。
| 字段 | 示例取值 | 填写理由 | 常见错误 |
|---|---|---|---|
| 触发事件 | 需求 REQ-1042 状态由“评审中”变更为“评审通过” | 写清事件来源对象、字段和变更前后值，任何人读到都能定位到具体动作 | 只写“需求状态变更”，不写变更前后值，无法判断是否属于规则定义的触发点 |
| 输入数据 | 需求编号、标题、项目、优先级、测试负责人 | 只记录参与判断和动作执行的字段，保证输入与结果可对应 | 把整个工作项的所有字段都抄进来，日志冗长且关键值被淹没 |
| 规则判断 | 命中，并列出两项条件均满足 | 命中要写清命中了哪些条件；未命中要写清哪条不满足，便于判断规则是否过严 | 只写“命中/未命中”，不写依据，规则调整时缺少参考 |
| 结果状态 | 成功 / 跳过 / 失败 / 成功（经重试） | 四种状态对应不同的后续处理：成功无需干预，跳过需确认是否符合预期，失败需排查，重试成功需关注稳定性 | 把“跳过”记为“失败”，导致失败率统计失真；把重试成功直接记为成功，掩盖了不稳定问题 |
| 异常信息 | 超时阈值、重试间隔、失败次数 | 记录可复现问题的参数，而不只是“出错了” | 只写“系统异常”，没有错误类型和参数，排查时只能重新复现 |
| 人工介入 | 无；或写明介入人与处理内容 | 人工处理改变了执行结果时，必须记录是谁、做了什么，否则状态变化缺少解释 | 人工补建了任务但日志仍显示“失败”，后续统计与实际情况不符 |
人工介入字段的填写时机需要单独说明：当自动执行未能完成预期动作，由人补做或修正后，应在原日志条目上追加介入记录，写明介入人、介入时间和处理内容，并把结果状态更新为最终状态。这样做保留了“自动执行失败”这一事实，同时说明结果是如何被补救的。如果人工介入后直接改写原日志而不留痕迹，复盘时就无法区分规则本身的成功率和人工补救的比例。
规则判断字段的写法随条件复杂度变化。单条件规则写一行即可；多条件规则建议逐条列出条件名、实际值和判断结果，例如“项目在核心清单内：是；优先级为高：是”。条件之间存在与、或关系时，还要写明组合方式，避免后续维护者误读。
可迁移规律：换一条流程怎么改这份日志
这份示例的结构可以整体搬到其他规则驱动的流程上，需要替换的是具体内容，需要保留的是记录逻辑。迁移时按下面的清单逐项处理。
保留项
- 六段结构：触发、输入、规则判断、执行动作、结果状态、异常与人工介入，顺序不变。
- 记录单元：仍以一次规则触发的完整执行为一条日志，用执行批次号区分。
- 结果状态的四种取值：成功、跳过、失败、成功（经重试），统计口径保持一致。
- 规则版本字段：任何规则改动都对应版本号变化，日志与版本绑定。
替换项
- 触发事件：换成新流程的事件来源。例如“缺陷状态变更为已修复后自动通知测试人员”，触发事件就写缺陷编号、状态变更前后值。
- 输入数据：换成参与新规则判断和动作执行的字段。通知类流程通常只需要缺陷编号、标题、当前处理人；建单类流程还需要项目、优先级、指派人。
- 执行动作：写清动作类型和作用对象，例如“发送通知给测试人员王芳”“创建回归测试任务并关联原缺陷”。
新增项
- 条件分支记录：规则包含三个以上条件或存在嵌套判断时，在规则判断字段下增加分支明细，逐条记录每个条件的实际值与判断结果。
- 失败类型分类：异常信息按失败类型归类，例如调用超时、对象不存在、权限不足、数据校验不通过。分类后可以按类型统计，判断是偶发问题还是配置问题。
- 执行批次关联：同一业务对象短时间内触发多次执行时，在日志中记录关联批次号，便于看出是否存在重复触发。
迁移后的日志与流程配置之间要建立对应关系：规则名称与版本字段指向具体的配置记录，执行批次号指向本次执行的全部明细。这样在调整规则前后，可以对比同一类输入在不同版本下的执行结果，判断改动是否达到了预期。在研发管理平台中承载这类流程时，工作项的状态变更记录与流转历史可以作为触发事件和输入数据的来源，规则执行产生的任务、通知则落在对应的工作项上，日志条目与工作项记录相互对应，复盘时可以从任一侧查到另一侧。ONES 的工作项状态流转记录可以承担这一衔接作用，具体字段与入口以团队实际配置为准。
适用边界：这份日志示例覆盖与不覆盖的场景
这份示例适用于规则明确、条件可判定的流程自动化执行记录。判断标准是：触发事件能被系统捕获，判断条件能用字段值比较表达，执行动作是确定的操作。满足这三点的流程，例如状态变更后自动建单、到期自动提醒、字段满足条件后自动流转，都可以直接套用六段结构。
以下场景不在本文覆盖范围内，需要另行设计记录方式：
- 由 AI 智能编排驱动的流程。这类流程的判断依据可能来自模型输出，日志需要记录模型输入、输出与置信度等信息，记录需求归其他主题讨论。
- 系统接口对接与集成部署。这类场景关注请求响应、重试策略和部署版本，日志字段与本文的六段结构不同，归其他主题讨论。
- 需要审计级留存的场景。日志保留周期、访问权限分级和合规要求因组织而异，本文只提示核验方向：确认保留周期是否覆盖复盘和审计需要，确认谁能查看和导出日志，确认日志中是否包含需要脱敏的个人信息。这些口径需按组织实际确定，本文不给出统一标准。
使用这份示例时，建议先选一条规则简单、触发频率适中的流程试填一周，检查日志能否支撑一次完整的问题定位。如果定位过程中仍需要反复询问执行人当时的情况，说明输入数据或规则判断字段记录得不够，按第三节的常见错误逐项补齐即可。
常见问题
流程自动化执行日志和普通的系统运行日志有什么区别？
系统运行日志通常记录程序层面的调用、报错和性能数据，面向开发和运维排查技术故障。流程自动化执行日志面向业务流程，回答的是“这条规则为什么触发、判断了什么、对哪个业务对象做了什么、结果如何”。它需要记录业务对象的编号、字段值和状态变更，让流程维护者和业务方都能读懂。两者可以并存：技术异常的具体堆栈留在系统日志里，执行日志记录错误类型和关键参数，并指向对应的技术日志。
规则一天触发几百次，每条都记完整日志会不会太重？
记录量取决于流程规模和复盘需要，可以分层处理。高频且动作单一的规则，例如到期提醒，正常执行时只记批次号、触发事件、结果状态和耗时，输入数据保留业务对象编号即可；出现跳过或失败时再补全判断依据和异常信息。低频但影响面大的规则，例如自动建单、自动流转，建议每条都记完整字段。分层的前提是同一套字段定义，避免统计时口径不一致。
人工补做了自动化没完成的操作，日志应该怎么记？
建议在原日志条目上追加介入记录，写明介入人、介入时间和处理内容，并把结果状态更新为最终状态，同时保留“自动执行失败”这一事实。这样复盘时既能看出规则本身的成功率，也能看出人工补救的比例。如果直接改写原日志、把状态改成成功，失败率统计会失真，后续判断规则是否需要优化时缺少依据。
日志保留多久比较合适？
保留周期与流程的影响范围、复盘节奏和组织的合规要求有关，没有统一标准。可以从两个角度确定：一是复盘需要，例如按季度分析规则命中率和失败率，日志至少要覆盖一个完整的分析周期；二是追溯需要，涉及审批、发布等关键环节的流程，保留周期通常要覆盖相关记录的可追溯期限。确定后建议写入流程配置说明，避免不同规则各自为政。
在研发管理平台里落地这套日志，需要注意什么？
关键是让日志条目与工作项记录能够相互对应。触发事件和输入数据可以取自工作项的状态变更记录与字段值，执行动作产生的任务、通知落在对应工作项上，日志中的执行批次号与规则版本指向具体配置。这样从日志能查到工作项，从工作项也能回溯到触发它的规则执行。ONES 的工作项状态流转记录可以承担这一衔接作用，具体字段与入口以团队实际配置为准。落地前先确认平台能导出或查询到这些记录，否则复盘时仍需人工拼凑。
