## 让 AI 帮你看懂和检查 Workflow

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

接手别人创建的 Workflow，最难的往往不是点击哪个按钮，而是看不懂这张图为什么这样连、哪一步在等人、行动后会影响谁。本章用“每周项目风险汇总”说明一种更简单的工作方式：把 Workflow 的身份和业务目标告诉 AI，让它先画出人能看懂的流程，再帮助你检查风险。真正的修改、发布和运行放到下一章。

学完本章，你将能够：

- 用一段自然语言，让 AI 解释现有 Workflow 的正常路径和异常路径。
- 从流程图中找出 Agent 工作、人工确认、通知和结束位置。
- 在行动之前，确认输入、参与者、审批人、失败去向和预期结果。
- 看懂 AI 返回的流程图、实际读取来源、待确认事项和操作边界说明。

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

- **覆盖**：通过对话看懂和检查已有 Workflow；形成行动前的业务确认清单。
- **不覆盖**：要求读者执行后台命令、阅读配置代码或判断技术错误码。
- **假设**：你知道这项流程想解决的业务问题，也知道谁应该参与和拍板；Human / Desktop 修改普通未关联 Team 的 Workflow 时会校验创建时冻结的 creator，Team-linked Workflow 则按 Team ownership 处理。当前公共 Agent CLI 的 ordinary 修改/发布/归档路径尚未比较认证 Human member 与 creator，不能把 Agent 操作成功解释为 creator guard 已通过。

AI 可以在后台读取所选 Workflow，但必须明确本次实际读到的是草稿还是已发布版本。当前公开的 AI 读取入口每次只返回所选的一份内容，不能同时读取草稿和已发布版本，因此本章不要求也不接受版本差异结论。谁负责确认风险、什么情况可以对团队发布、多久没人响应需要人工介入，仍要由你和团队约定。

<!-- slot: 流程 -->
### 先看一张业务流程图

假设各项目的更新已经准备好，由你在发起本周汇总时一并提供。AI 给出的图不必照搬编辑器里的名称，但业务顺序、等待对象和结束位置必须一致：

![每周项目风险汇总业务流程：发起人提供更新，项目助理 Agent 整理并等待提交，字段不合格时由同一 Agent 修正重交，项目经理通过后通知频道并成功结束，驳回则失败结束](../../media/chapters/fig-16-01-ai-explains-workflow.svg){#fig-16-ai-explains-workflow width=96%}

先沿着“发起 → 等待项目助理 Agent 提交 → 人工确认 → 通知 → 完成”走一遍，再看两条异常路线：

1. 项目助理 Agent 提交的结果缺少约定字段时，提交会被拒绝，运行继续停在图中的同一个等待点；虚线表示同一 Agent 修正后重交，不是一条新的业务步骤。平台只能核对约定字段，不能自动判断内容在业务上是否充分。
2. 项目经理驳回，本次运行走到已设计的失败结束。运行中的审批只保存“通过或驳回”决定；若团队需要记录原因，要另设反馈收集步骤。

人工确认本身没有自动的强制响应时限。如果团队要求“当天 18:00 前没人处理就升级”，要把升级对象和处理方式写进运营约定；流程在此之前会保持等待。

Loop 的界面可能统一显示“等待”。“正在等指定 Agent 重新提交”或“正在等项目经理决定”是 AI 根据当前步骤翻译出的业务说明，不是平台另外创造的两种状态。

<!-- slot: 提示词 -->
### 再复制这段提示词

下面是一份可以复用的检查模板。Workflow 的名称可能重复，最好同时提供页面链接；其余方括号也要换成你的实际信息：

先明确一个安全边界：这段提示词只是对 AI 的行为约束，不会把它的工具变成平台强制的只读权限。当前公开的 Workflow 操作面同时包含读取和管理能力，所以仍要用检查前后的草稿修订、版本和运行记录加强核验；这些证据只能降低风险，不能绝对证明期间没有发生修改。

```text
请帮我检查下面这个 Workflow，先不要修改、发布或运行。

Workflow 名称或页面链接：[名称或链接]
业务目标：[这项流程要解决什么问题]
发起时由谁提供什么信息：[发起人与输入]
负责执行的 Agent：[Agent 或角色]
必须由谁确认：[审批人或角色]
最终结果发到哪里：[频道、任务或其他接收位置]

请用业务语言回答：
1. 如果名称对应多个 Workflow，立即停止并列出可区分的候选，让我选择，不要自行猜测。
2. 如果你没有读取权限，明确告诉我需要谁授权，不要根据历史内容推测。
3. 先画完整流程图，标明开始、Agent 工作、等待对象、人工决策、成功和失败结束。
4. 分别列出“等待指定 Agent 提交”和“等待审批人决定”；不要把所有等待都解释成通过或驳回。
5. 明确本次实际读取的是草稿还是已发布版本。当前读取入口不能同时取得两份内容，因此不要生成版本差异；如果从未发布，就明确写“只有草稿”。
6. 指出可能造成错误通知、重复外部动作或长期无人处理的地方。
7. 返回五项以内的待确认清单，并列出本次实际执行过的操作。如果你声明只做了读取检查，把它标为“AI 声明”，并尽量附上可核验依据，例如检查前后草稿修订、已发布版本标识是否变化，以及是否出现本次操作产生的运行或停止回执。发现并发变化，或无法取得这些依据时，明确写“无法仅凭本次回复证明未发生变更”。

得到我确认前，不要修改、发布、运行或停止任何 Workflow。
```

这段提示词要求 AI 先解释、后行动，也要求它在同名、无权限或没有已发布版本时停止猜测。

### AI 和人分别做什么

| 角色 | 负责什么 | 不应替谁决定 |
| --- | --- | --- |
| 你 | 说明目标、参与者、审批和异常要求；确认流程图 | 不需要手工处理技术细节 |
| AI 助手 | 读取所选 Workflow、说明实际读取来源、解释流程并列出风险 | 不替你决定业务风险是否可接受，也不虚构版本差异 |
| 项目助理 Agent | 整理你提供的项目更新并提交摘要 | 不替项目经理批准最终摘要 |
| 项目经理 | 确认或驳回本周摘要 | 不负责补齐或纠正汇总内容 |
| Loop | 保存版本、运行状态、等待与结果记录 | 不自动制定团队响应时限 |

<!-- slot: 配置 -->
### 运行前只确认五件事

你不需要看配置代码，只要让 AI 把下面五项用人类可读的卡片展示出来：

1. **本次范围**：汇总哪些项目、覆盖哪个时间段。
2. **参与者**：哪些负责人提供更新，哪个 Agent 汇总，谁最终确认。
3. **通知位置**：最终摘要发到哪个项目频道。
4. **异常去向**：信息缺失、Agent 结果不完整、审批驳回时分别找谁。
5. **读取来源**：本次实际读取的是草稿还是已发布版本；当前读取入口不能同时取得两份内容，所以不展示版本差异。

如果 AI 不能明确回答其中任何一项，就先补充需求，不要急着运行。

<!-- slot: 审批 -->
### 人工决策不能交给 AI 猜

本例有两类不同的确认：

- **发布确认**：由 Team 管理的可复用 Workflow 必须经 Owner 审批；Human / Desktop 对普通未关联 Team 的 Workflow 执行 immutable creator guard。当前 Agent CLI 缺少 member→creator 比较，AI 只能说明这项产品边界，不能拿 Agent 命令代替 Human / Desktop 的授权判断。
- **运行中的业务确认**：每周风险摘要由项目经理决定通过或驳回。

AI 可以说明本次实际读取的来源，但当前公开读取入口不能同时取得草稿和已发布版本，不能整理版本差异。它可以生成审批摘要、提醒等待人，但不能绕过 Owner，也不能把“长时间没人处理”当成默认通过。
运行中的业务审批只保存“通过或驳回”决定，不附带驳回原因。如果团队需要原因，应另设反馈收集步骤或在任务讨论中记录，不能让 AI 虚构一个理由。
这里“普通 Workflow 可直接发布”只描述不走 Team Owner 审批的路线。Human / Desktop 中，保存、修改元数据和直接发布仍受 immutable creator guard；Team-linked Workflow 继续走 Team ownership。公共 Agent CLI 当前未实施同一 member→creator 比较，所以不能宣称 Agent edit / publish 已受到相同保证，也不能把这项缺口写成合法绕行方式。

<!-- slot: 异常 -->
### 看到这些状态时怎么办

| 你看到的现象 | 它通常表示什么 | 可以继续对 AI 说什么 |
| --- | --- | --- |
| 找到多个同名 Workflow | 名称不足以唯一选择 | “列出所属团队、更新时间和页面链接，让我选择；不要继续操作。” |
| AI 无法读取 | 当前身份没有访问权限 | “告诉我应向谁申请什么权限，不要根据历史消息猜测内容。” |
| 只有草稿 | 这项 Workflow 从未发布 | “只解释草稿，并明确写出没有可运行的已发布版本。” |
| 一直显示等待 Agent | 指定 Agent 尚未提交符合约定字段的结果 | “只重述这里约定的必填字段；如果拿不到原 Agent 收到的提交错误，不要断言具体缺少哪些字段。请同一个 Agent 对照错误修正后重新提交。” |
| 等待项目经理 | 流程已到人工决策点 | “展示审批摘要和影响，不要替审批人决定。” |
| 运行失败 | 某一步无法继续，或走到了失败路线 | “用业务语言说明失败步骤、已完成动作和安全的下一步。” |
| 已请求停止但消息已经发出 | 外部可见动作可能已经发生 | “列出已经发生的动作；不要假设停止会撤回已发送消息。” |

排障时先问“已经发生了什么”，再决定重试。尤其是通知、建单或发布等外部动作，不能因为界面暂时没有结果就盲目再做一次。

### AI 应该给你的可见结果

一次合格的检查不应只回复“看起来没问题”，而应交付一张可以转发给同事的结果卡：

| 结果卡项目 | 本例应显示什么 |
| --- | --- |
| Workflow 身份 | 已按页面链接唯一定位“每周项目风险汇总” |
| 业务流程 | 发起 → 指定 Agent 提交摘要 → 项目经理确认 → 通知或失败结束 |
| 读取来源 | 本次实际读取的是草稿还是已发布版本；当前入口一次只返回一份内容，不提供版本差异 |
| 等待责任 | Agent 等待点由指定 Agent 恢复；审批等待由项目经理决定 |
| 风险提醒 | 审批没有自动响应时限；停止不能撤回已经发出的通知 |
| 操作边界 | AI 声明本次实际执行过的操作，并附可核验依据；无法核验时明确说明不能证明 |

“我没有修改”只是 AI 的声明，不是权威证明。检查草稿修订和已发布版本标识在前后是否变化，并确认没有本次操作产生的运行或停止回执，可以加强核验、降低风险，但仍不能绝对证明没有发生修改；如果期间有其他人并发操作，就更不能据此下结论。AI 无法取得依据时，也必须明确承认无法证明，而不是给出确定回执。

<!-- slot: 外部系统 -->
### 外部系统

本章的最终动作只是把摘要发到 Loop 项目频道，不连接外部系统。第 18 章会用代码托管场景说明：Agent 怎样管理订阅，以及代码托管服务成员怎样把符合条件的 Pull Request 活动投递到已授权目标。
代码托管订阅只负责投递消息，不会自动启动 Workflow；如果后续确实需要运行一项流程，应由具备权限的人或 Agent 基于投递结果明确发起，并先确认目标和权限。

### 业务收益怎样衡量

不要只用“大家觉得更清楚了”作为结果。选一项真实 Workflow，在改用本章模板前后每侧至少记录四周，或累计收集至少八次真实检查与接手记录：

- 新接手人讲清流程所需时间，目标从半小时以上降到 10 分钟以内。
- 因同名、版本不清或误解等待对象造成的误操作次数，目标为 0。
- 等待超过团队约定时限后，能明确找到下一位责任人的比例，目标为 100%。
- 复盘时需要反复询问“这一步是谁做的”的次数，是否持续下降。

这些是团队可以观察的改进目标，不是 Loop 自动承诺的服务等级。
样本不足时只记录现象，不宣称误操作已经达到 0%、责任识别已经达到 100%，也不判断趋势。

<!-- slot: 验收 -->
### 如何判断这套方法真的有帮助

- [ ] 不看配置代码，也能在 10 分钟内讲清正常路径、两条异常路线和最终结果。
- [ ] 能唯一定位 Workflow；遇到同名、无权限或从未发布时，AI 会停止猜测。
- [ ] 能指出 Agent 工作与人工决策的边界，不让 AI 替审批人拍板。
- [ ] 能确认范围、参与者、通知位置、异常去向和本次实际读取来源。
- [ ] AI 返回流程图、待确认项、操作声明和可核验依据；无法核验时会明确说不能证明。
- [ ] 团队能用接手时间、误操作和等待责任识别率衡量实际收益。

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

<!-- media: fig-16-01-ai-explains-workflow.svg -->
图 16-1 AI 把现有 Workflow 转成业务流程图：正常路径、人工决策与异常路线同时可见。

<!-- media: fig-16-02-visible-run-states.png -->
图 16-2 读者可见的四种状态卡片：等待指定 Agent、等待审批、失败结束、已完成。

### 小结

检查 Workflow 的第一步不是记住命令，而是让 AI 把流程讲清楚。先确认唯一身份、实际读取来源、图、角色、决策点、异常路线，以及操作声明能否被核验；这样既能降低使用门槛，也能避免“流程能跑，但业务含义没人看懂”。

下一章会继续使用这种对话方式，说明怎样让 AI 帮你发布、运行、停止和排障，并把后台细节保持为用户不可见的实现过程。