# 第 4 课练习：把“处理慢”拆成具体等待

[English](README.en.md)

打开 [waiting.csv](waiting.csv)。你的任务是判断哪一段等待值得进一步研究，并说明数据还不能告诉你什么。20 行与入门北辰 JSON 按 `event_id` 对齐；专家等待和处理总时长沿用入门记录，查找、审批和分段坐标是**新增合成设定**。这不是补找出的真实日志，不能用新增字段证明入门案例原本就有这些等待。

## 读懂字段

| 字段 | 含义 |
| --- | --- |
| `source_type` | `intro_linked_synthetic_extension`：与入门记录对齐的合成扩展 |
| `event_id` | 与入门数据相同的事件编号 |
| `search_start_min` / `search_end_min` | 查找等待的起止坐标，单位分钟 |
| `expert_start_min` / `expert_end_min` | 专家等待的起止坐标 |
| `approval_start_min` / `approval_end_min` | 审批等待的起止坐标 |
| `search_wait_min` / `expert_wait_min` / `approval_wait_min` | 三段等待时长 |
| `total_wait_min` | 三段等待之和 |
| `resolution_min` | 整个任务的处理时长，包含等待及其他工作 |

坐标从各任务自己的第 0 分钟起算。本扩展刻意将查找→专家→审批设为依次发生、互不重叠；实际工作可能并行或多次往返，不能照搬这种相加法。零分钟表示本合成记录该段没有等待，不表示真实系统已证明没有瓶颈。

## 逐步计算

1. 逐行检查各段 `end − start = wait`，以及三段和等于 `total_wait_min`、等待不超过 `resolution_min`。找出最长等待的一条，写出最先想查的问题，不据时长直接诊断设备。
2. 按列求和：查找 **140**、专家 **367**、审批 **200**，总等待 **707 分钟**。三段占总等待分别约 **19.8% / 51.9% / 28.3%**。分母是所有记录的等待分钟，不是 20 条任务，也不是总处理时长。
3. 总处理时长为 **1,753 分钟**，平均 **87.65 分钟**。707 / 1,753 ≈ **40.3%** 只表示本扩展的等待占处理时长，不能写成审批占比。审批占总等待是 200 / 707 ≈ **28.3%**。
4. 写两个竞争解释，例如专家容量不足、原始信息不完整导致反复确认；分别列出还需什么证据才能区分。最长的一段不一定最容易改变，也不一定适合由 AI 处理。
5. 提出下一步及停止条件：先补哪些记录、比较资料改进与流程改进、何种证据会支持继续或换方案。这里只写建议，不冒写客户认可。

## 自检与判断边界

含专家等待的 12 / 20 = **60%** 是任务比例，不是专家等待分钟比例。E-013 在入门记录中专家等待为 **46 分钟**；逐步事件 03 另写 42 分钟，两者来源不同，不能平均或偷偷改成一致。入门 JSON 没有审批分段，不能拿这里新增的 200 分钟当原事件的观测证据。

这组数据支持练习分母、分段与调查问题，不能证明某个产品将缩短处理时长或达到 30% 改善。独学可用计算表和待查问题完成；如有同伴，请其检查一个分母和一个超出来源的结论。

下一课学习人机协同：把你选中的任务步骤转成用户看得懂的状态、拒绝和接手路径。