---
name: fde-workflow-discovery
description: 按前线部署工程师（FDE，forward deployed engineer）的做法，为客户或团队的一条工作流写调研记录：跟岗观察和访谈问题、用泳道表列出当前步骤（执行人、工具、耗时、痛点）、输入输出数据、例外情况、AI 适合和不适合的环节、一个成功指标和一个小规模试点方案。适用于即将去客户或内部团队现场寻找 AI 能帮上忙的地方，或有人要工作流调研、流程梳理、现状流程图、跟岗观察提纲、AI 试点方案时。
---

# FDE 式工作流调研

前线部署工程师会和客户团队坐在一起，让产品在对方真实的系统和工作流里跑起来。最先做的调研，任何人都能做：在工作进行时观察，记下每一步的耗时和痛点，然后才决定 AI 放在哪里。人凭记忆描述自己的工作时，会漏掉各种变通做法和例外情况，而这些恰恰决定 AI 试点能否成功；现场观察才能抓住它们。

## 适用场景

- 在为客户或自己团队的流程提议 AI 工具或智能体之前。
- 团队说“我们想用 AI 做 X”，但没人梳理过 X。
- 试点停滞之后，找出当初漏掉的步骤。
- 不适用于一次给大量任务打分来挑选目标（先用 automation-opportunity-scan）。

## 需要准备

- 用一句话说清工作流，带上起点和终点（“从收到发票邮件到发票付款完成”）。
- 能接触到 2 到 3 位实际做这项工作的人，最好是在他们做的时候。
- 输入和输出的样例（表单、邮件、文件），去掉个人信息。
- 如果无法现场观察，就把问题当作访谈来问，并在流程图上标注“[来自访谈，未经观察]”。

## 步骤

1. **划定工作流的边界。** 写明起点、终点、参与的人和量（每周多少件）。一次调研只看一条工作流；如果它分叉成两件事，拆开。
2. **先跟岗观察，边看边问。** 观察 30 到 60 分钟的真实工作。当场问：“你在那里找什么？”“这一栏空着会怎样？”“这个做法是从哪里学来的？”“出错的时候你怎么办？”。记下各种变通做法：复制粘贴、额外的表格、便利贴、给同事发消息。
3. **用泳道表列出当前步骤。** 每一步一行：执行人、步骤、工具、每件耗时（分钟）、痛点（等待、返工、出错、枯燥）。按时间顺序排列。标出判断节点（“金额 > 5 万元 → 经理审批”）。
4. **列出输入和输出的数据。** 每一步输入什么信息（从哪里来、什么格式），输出什么。标出属于个人信息、机密或受监管的数据。
5. **收集例外情况。** 每 10 件或每 100 件里出现 1 次的情况：缺字段、格式特殊、有争议、加急。能数就数出来。例外通常最耗时间，也最容易让简单粗暴的自动化失灵。
6. **标出 AI 适合的环节。** 每一步三选一：AI 起草或提取、人来检查；AI 独立完成；保持人工。这个技能的默认规则：只有输出容易检查、出错后容易撤回的步骤，才让 AI 独立完成；凡是涉及钱、法律条款或对人的决定，都保留人工审批。
7. **定一个成功指标和一个试点。** 一个指标，基线取自流程图（每件耗时、出错率、周转时间）。试点：一个或几个步骤，2 到 4 周，小批量，客户方有一位具体负责人，并写明“继续 / 停止”的标准。

## 输出格式

```markdown
# 工作流调研 — [工作流]，[团队 / 客户]
**起点 → 终点：** [起点] → [终点] · **量：** [每周 n 件] · **观察：** [谁，日期] 或 [来自访谈]

## 泳道表：现状
| # | 执行人 | 步骤 | 工具 | 分钟/件 | 痛点 |
|---|---|---|---|---|---|
| 1 | [角色] | [步骤] | [工具] | [n] | [等待 / 返工 / 出错 / 无] |

## 输入和输出数据
| 步骤 | 输入（来源、格式） | 输出 | 敏感？ |
|---|---|---|---|

## 例外情况
| 例外 | 频率 | 现在怎么处理 |
|---|---|---|

## AI 适合的环节
| 步骤 | AI 的角色 | 人工检查 | 原因 |
|---|---|---|---|
| [#] | 起草 / 提取 / 独立完成 / 不用 | [谁检查] | [原因] |

## 成功指标
[指标]：基线 [n] → 目标 [n]

## 试点方案
- 范围：步骤 [#]，[量]，[周数]
- 负责人（客户方）：[姓名]
- 继续条件：[阈值] · 停止条件：[阈值]

## 待解决问题
- [问题]
```

## 示例

**输入：** “跟了禾润食品的应付会计陈磊一个小时。发票以 PDF 形式通过邮件发来（每周约 120 张）。打开邮件、保存 PDF 约需 30 秒。他把供应商、金额、采购订单号手动录入 ERP（每张约 4 分钟）；他说这活很枯燥，也会录错。发票上有供应商的银行账户信息。没有采购订单号的，他发邮件问采购员（写邮件约 2 分钟），然后等（约每 8 张有 1 张，要等 1–2 天）。超过 5 万元的需要经理林琳在 ERP 里审批。有些供应商发来的是扫描图片，更难辨认。”

**输出：**

```markdown
# 工作流调研 — 供应商发票录入，禾润食品应付组
**起点 → 终点：** 收到发票邮件 → 发票在 ERP 中审批通过 · **量：** 每周约 120 张 · **观察：** 陈磊，1 小时

## 泳道表：现状
| # | 执行人 | 步骤 | 工具 | 分钟/件 | 痛点 |
|---|---|---|---|---|---|
| 1 | 应付会计 | 打开邮件，下载 PDF | 邮件 | 0.5 | 无 |
| 2 | 应付会计 | 把供应商、金额、采购订单号录入 ERP | ERP | 4 | 枯燥、录错 |
| 3 | 应付会计 | 没有采购订单号时：发邮件问采购员，等待 | 邮件 | 2 + 等 1–2 天 | 等待 |
| 4 | 经理（林琳） | 超过 5 万元时：审批 | ERP | [待确认] | 等待 |

## 输入和输出数据
| 步骤 | 输入（来源、格式） | 输出 | 敏感？ |
|---|---|---|---|
| 2 | PDF 或扫描图片 | ERP 中的发票记录 | 供应商银行账户：是 |
| 3 | 没有采购订单号的发票 | 发给采购员的邮件 | 否 |

## 例外情况
| 例外 | 频率 | 现在怎么处理 |
|---|---|---|
| 缺少采购订单号 | 约每 8 张 1 张 | 发邮件问采购员，等 1–2 天 |
| 扫描图片而不是 PDF | [待确认：数量] | 更难辨认 |

## AI 适合的环节
| 步骤 | AI 的角色 | 人工检查 | 原因 |
|---|---|---|---|
| 2 | 把字段提取到核对页面 | 陈磊逐张确认 | 容易对照 PDF 检查；付款数据需要人把关 |
| 3 | 起草发给采购员的邮件 | 陈磊发送 | 风险低，省去打字 |
| 4 | 不用 | 林琳 | 支出审批保持人工 |

## 成功指标
步骤 2 每张发票耗时：基线 4 分钟 → 目标 1.5 分钟以内

## 试点方案
- 范围：步骤 2，选 2 家发来清晰 PDF 的供应商，3 周
- 负责人（客户方）：陈磊，同步告知林琳
- 继续条件：每张 1.5 分钟以内，且错误不比现在多 · 停止条件：错误增加

## 待解决问题
- 现在录错是怎么发现的？有多少错误一直到了付款环节？
- ERP 支持导入吗，还是只能手动录入？
```

## 发送前检查

- [ ] 工作流只有一个起点、一个终点，并写了每周的量。
- [ ] 泳道表每一行都有执行人、工具和耗时，或标注“[待确认]”。
- [ ] 例外情况都写了发生频率。
- [ ] 凡是涉及钱、法律条款或对人的决定的步骤，都保留了人工检查。
- [ ] 成功指标的基线取自流程图。
- [ ] 试点写明了客户方负责人和继续 / 停止的阈值。

## 常见错误

- 照着文件梳理“官方流程”，而不是实际的做法。变通做法才是真正的流程。
- 提议把整条工作流自动化。先挑耗时最明确、最容易检查的那一步做试点。
- 因为例外少见就忽略它们。人们是否信任试点，取决于例外。