## 用证据衡量 Workflow 价值

Run 显示 `succeeded`，只说明已发布图按自己的合同走到成功终点。
它不能证明客户问题解决、人工负担下降，也不能证明外部动作没有重复。

度量 Workflow，要把运行证据与业务系统结果放在同一张指标卡里，并提前写清分母、窗口、来源、Owner、使用动作和反指标。

<!-- slot: 目标 -->
### 本章目标

学完本章，你将能够：

- 把业务结果、流程质量、运行信号和风险反指标分开度量。
- 为每个指标写出可回放的分子、分母、时间窗口和数据来源。
- 用 PlanVersion、Invocation、Run、Activation、Effect、事件与外部结果卡解释变化。
- 让指标触发具体管理动作，而不是只生成一张无人负责的报表。

<!-- slot: 边界 -->
### 适用边界

- **覆盖**：团队围绕一个或一组 Workflow 建立的指标卡、复盘和改进行动。
- **不覆盖**：宣称 Loop 已提供自动业务 Dashboard，或把 Prometheus 等服务指标直接当作业务价值。
- **假设**：团队能读取自己有权访问的 Workflow 运行记录，并能从业务权威系统取得必要、脱敏的结果数据。

平台能提供精确版本、调用来源、运行状态和子记录等证据；客户满意、回款、缺陷质量或审批正确性仍来自业务系统与人工基准。
两者都缺一不可。

<!-- slot: 流程 -->
### 从业务问题到管理动作

![Workflow 度量闭环：先固定目标与指标卡，再分别采集业务结果、流程质量、运行证据和风险反指标；按同一窗口解释差异，形成保持、改版、降级或退役动作，并由 Owner 跟踪](../../media/chapters/fig-33-01-workflow-measurement-loop.svg){#fig-33-workflow-measurement-loop width=96%}

一次有效复盘按以下顺序进行：

1. **写业务假设**：例如“减少需求评审等待”，而不是“提高自动化率”。
2. **冻结指标卡**：先写口径再看数字，避免看到结果后改分母。
3. **收集两类证据**：Loop 侧记录版本、Invocation、Run 与等待点；业务侧记录真实结果、质量和外部影响。
4. **按同一窗口对齐**：说明时区、进入样本的时间和迟到结果怎样归属。
5. **同时看反指标**：速度提升时检查错误、打扰、人工接管和敏感数据暴露。
6. **作出动作**：保持、修改草稿、限制适用范围、暂停 Schedule 或退役；每项动作有 Owner 和截止日期。
7. **下个窗口验证**：新版本与旧版本分开统计，不把版本变化后的结果混成一条趋势。

<!-- slot: 提示词 -->
### 复制这段指标卡提示词

```text
请帮助我为一个 Workflow 准备运营指标卡，不要假设存在自动业务 Dashboard。

业务目标：[要改善的真实结果]
Workflow 与批准版本：[名称、PlanVersion 或可核验版本]
观察窗口：[开始、结束、时区]
适用样本：[哪些请求进入分母]
Loop 侧可用证据：[Run、Activation、Effect、事件、审批等]
业务权威来源：[工单、CRM、财务或人工基准]
业务 Owner：[member_ref 或 role_code]
运营 Owner：[member_ref 或 role_code]

每个指标必须返回：名称、目的、分子、分母、排除项、时间窗口、来源、Owner、目标或基线、触发的管理动作、反指标。
无法从现有证据计算的项目写“不可计算”和缺口，不要估算。
最后把结果分成业务结果、流程质量、运行信号和风险反指标四组，并给出下一窗口的行动项。
```

### 一张可复用的指标卡

| 字段 | 填写要求 |
| --- | --- |
| 指标与目的 | 一句话说明它回答哪个业务问题 |
| 分子 / 分母 | 都写集合定义，不只写百分比名称 |
| 时间窗口 | 开始、结束、时区和迟到结果归属 |
| 版本范围 | 精确批准版本；跨版本必须分组 |
| 数据来源 | Loop 证据、业务系统或人工基准 |
| Owner | 谁解释、谁能改口径、谁执行动作 |
| 基线与目标 | 样本不足时只保留基线，不造目标 |
| 管理动作 | 达到、未达到或异常时分别做什么 |
| 反指标 | 哪种伤害可能被主指标掩盖 |

<!-- slot: 配置 -->
### 四层指标示例

以下示例以“需求评审准备 Workflow”为对象。数值需要用团队真实基线填写：

| 层次 | 可回放定义 | 来源与使用动作 | 反指标 |
| --- | --- | --- | --- |
| 业务结果 | 窗口内在承诺日期前形成明确评审结论的请求数 ÷ 窗口内进入评审且资料齐备的请求数 | 产品系统结果卡；连续下降时检查范围、Owner 与资料门槛 | 为按时而草率通过，或把难例移出分母 |
| 流程质量 | 结果卡中版本、审批、缺失项、决定和后续 Owner 全部可核验的数量 ÷ 本窗口应产出结果卡的数量 | Loop 与业务结果卡对账；缺证据先修流程 | 只补表格，不改善实际决策 |
| 运行信号 | 成功 Run 的完成时间减去对应 Invocation 的接受时间，并报告中位数、第 90 百分位、失败、取消和仍等待数量 | Invocation、Run 列表与详情；长尾上升时定位 Activation、Effect 和事件 | 只看中位数，忽略长等待和被取消样本 |
| 风险反指标 | 结果不明、未经批准写入、重复外部动作或人工接管次数 ÷ 本窗口高影响动作尝试数 | 行动结果卡与外部回执；任一越权事件立即复盘 | 因害怕记录而少报事件 |

不要把“自动化覆盖率”单独当作目标。
如果团队为了提高覆盖率，把不适合的请求强行送进 Workflow，等待、例外和风险都会转移到看不见的地方。

### 证据怎样对齐

每条聚合结果至少保留以下关联：

- Workflow 与精确 PlanVersion。
- Invocation、Run 与调用来源；来源只应解释为 `manual` 或 `schedule`。
- 关键 Activation、Effect、审批决定、callback 或事件位置。
- 业务系统中的安全引用、外部回执或人工基准。
- 指标窗口、提取时间、查询人和口径版本。

业务数据与 Loop 证据连接时使用最小必要的安全引用，不把完整客户记录、薪酬、合同或凭据复制进指标表。

<!-- slot: 审批 -->
### 谁可以修改指标口径

指标口径变化不是一次 Run 中的业务审批。
它是团队治理决定：业务 Owner 批准目标与分母，数据 Owner 确认来源和字段，运营 Owner 维护计算与例会，风险或合规负责人确认反指标。

改口径时保留生效日期和旧定义。不要把历史数据无说明地按新口径重算，再声称趋势改善。
若指标用于人员评价、财务承诺或合规结论，还应按组织制度增加独立复核。

<!-- slot: 异常 -->
### 常见度量陷阱

| 现象 | 错误结论 | 处置 |
| --- | --- | --- |
| 只统计成功 Run | 成功率很高 | 把失败、取消、等待和未进入 Workflow 的适用请求列入相应分母 |
| 版本混在一起 | 本月整体改善 | 按精确 PlanVersion 分组，再解释流量结构变化 |
| 业务结果迟到 | 当周没有价值 | 预先规定迟到结果归属，保留未成熟样本 |
| 外部结果不明 | 当作失败后重试 | 先按完整意图身份核验；证据不足就单列并人工接管 |
| 小样本波动 | 一次上升就是趋势 | 同时报样本量和区间，只记录事实 |
| 主指标变好、反指标变差 | 自动化成功 | 暂停扩大范围，调查错误、打扰、越权或数据泄露 |
| 数据源缺字段 | 用 AI 估算 | 标记不可计算，补来源或取消该指标 |

<!-- slot: 外部系统 -->
### 外部业务结果必须回到权威来源

工单关闭、客户续约、付款状态或权限变化，应以对应系统的权威状态为准。
Agent 自述“已完成”和 Run 成功状态都不能替代外部证据。

凭据由 App 连接保管；指标表只记录系统、对象的安全引用、结果与核验时间。
外部查询失败时保留“未取得”状态，不用旧缓存冒充当前结果。

### 例会怎样使用数字

运营例会不逐条朗读报表，只回答四个问题：

1. 哪个业务结果发生了有意义的变化，证据是否成熟。
2. 哪个等待点、版本或输入质量解释了变化。
3. 有无反指标越线，是否需要立即限制或暂停。
4. 本窗口决定保持、改版、降级还是退役，Owner 和期限是什么。

附录 B 提供一份 45 分钟例会议程和决策记录。

<!-- slot: 验收 -->
### 指标体系验收

- [ ] 每个指标都有分子、分母、排除项、窗口、时区和版本范围。
- [ ] 业务结果来自权威系统或人工基准，不以 Run 成功代替。
- [ ] Loop 证据能定位到精确版本、Run 和关键等待或副作用记录。
- [ ] 每个指标都有解释 Owner、口径 Owner 和触发的管理动作。
- [ ] 主指标至少配一个能揭示质量、风险或打扰的反指标。
- [ ] 失败、取消、仍等待和结果不明不会从分母中静默消失。
- [ ] 口径变更保留旧定义、生效日期和跨版本解释。
- [ ] 无法计算的项目明确写缺口，不用 AI 估算。

<!-- slot: 媒体槽位 -->
### 媒体槽位

<!-- media: fig-33-01-workflow-measurement-loop.svg -->
图 33-1 从业务假设、四层证据到管理动作和下个窗口验证的度量闭环。

### 小结

好的指标卡不是一组漂亮数字，而是一份可回放的决策合同。
它把 Loop 运行证据、业务结果、反指标和 Owner 连起来，并明确数字变化后要做什么。

下一章将把这些证据放进权限、审计、例会和退役机制。