“为什么都这么慢”是问错了。这种问法只会换来”大家要更专注”那种空话，外加又一次全员大会。有用的版本是把周期时间一段段拆开、把工作时间和等待时间分开，再找出”大部分总耗时其实是排队而不是动手”那一段。
为什么要盯着等待？因为排队几乎永远是真正的问题。在不主动管理流动的知识型团队里，流动效率（动手时间 ÷ 总耗时）通常只有 15%-25%——也就是说，一项任务从开始到完成，有 75%-85% 的时间根本没人在碰（数据出自 Lean Kanban University，引用于 2026 年 6 月）。优化”工作”只能抠出那一小块 15%；砍掉”等待”才能拿回另外那 85%。
下面这些 Prompt 强制做这种分解，点名等待 / 工作比最差的那一段，并给出排序好的修复方案——而不是把锅扣到某个团队头上。把它们粘进 ChatGPT（GPT-5.5）、Claude（Opus 4.7 / Sonnet 4.6）或 Gemini 3.1 Pro 都行，这三家处理一张阶段表都绰绰有余。识别出瓶颈之后，配合 流程改进 Prompt 设计真正的改动。
一句话速览
- 量等待，别量工作。 多数团队流动效率只有 15%-25%，瓶颈是最长的那条队列，不是干活最慢的那个人。
- 先分解（Prompt 1）、再拆等待 vs 工作（Prompt 2）、只修最堵那一段（Prompt 3）。优化非瓶颈阶段对吞吐量毫无帮助。
- Little’s Law（
cycle time = WIP ÷ throughput，Prompt 7）告诉你真正能缩短周期的 WIP 上限。 - 动手前先量基线——否则改完根本没法判断有没有效果。
这套 Prompt 适合用在哪
- 工程速度审计（DORA 交付前置时间、code review 等待、CI 时长）
- 客服工单时长分析
- 销售周期审计与管道漏水
- 招聘流水审计与 time-to-hire
- 审批链与交接审查
- 跨工具流程合并
该用哪个 Prompt
| 目标 | 用 Prompt | 输出 |
|---|---|---|
| 看清时间花在哪 | 1. 周期时间分解 | 阶段表 + 最大嫌疑 |
| 证明是排队不是干活 | 2. 等待 vs 工作 | 等待最重的 top 2 段 |
| 决定怎么修 | 3. 修法选项 | 4 种修法按 impact × effort 排序 |
| 止住反复打回 | 4. 返工率审计 | 根因 + 控制措施 |
| 精简审批 | 5. 审批链审计 | 可删 / 卡壳的审批 |
| 减少工具切换 | 6. 工具切换成本 | 合并清单 |
| 定 WIP 上限 | 7. Little’s Law 算 WIP | 每阶段 WIP 上限 |
| 落地方案 | 12. 瓶颈 → 路线图 | 90 天计划含 owner |
1. 周期时间分解
Workflow：[workflow]。Stages：[stages]。逐阶段估算：(a) 中位耗时、(b) 方差、
(c) 等待的主要原因（交接 / 审批 / 工具切换 / 返工）。输出按阶段排的表，
标出最大嫌疑那段，并给出每段占总周期时间的百分比。2. 等待 vs 工作时间
对 [workflow] 的每个阶段，把总耗时拆成 WORK time（动手）vs WAIT time（排队 /
等审批 / 等交接）。报告流动效率 = 总工作时间 / 总耗时。任何 wait > 自身 50%
的阶段都是瓶颈候选。点出 top 2，说明各自主要是哪种等待。3. 瓶颈修法选项
对 top 瓶颈阶段，提 4 种修法：(a) 删掉这阶段、(b) 与其他工作并行、(c) 自动化、
(d) 上游 pre-stage 预备。每种给：预计周期时间下降、实现成本、引入风险。
按 impact / effort 排序。4. 返工率审计
识别返工率高的阶段（活反复被打回上游）。根因诊断：(1) 上游输入不清、
(2) 缺交接文档、(3) 后期才发现约束、(4) 漏了验收检查。每条给 1 条预防性
控制 + owner。5. 审批链审计
这条流程有审批节点。审计：(1) 通过率 >= 95% 的审批（候选删除或改 opt-out）、
(2) 具体哪位审批人是瓶颈（OOO / SLA 违约）、(3) 因历史原因存在但没人记得为
什么的审批。给精简建议，以及删掉每个审批的风险。6. 工具切换成本
一项工作在这条流程里要跨多少工具？列出来。每个工具边界：上下文切换耗时、
复制粘贴、漏通知、手动同步状态。给合并建议，最有杠杆的那条放最前。7. WIP 限制建议
团队 work-in-progress 太多。用 Little's Law（cycle time = WIP / throughput），
基于当前吞吐量 [每周完成件数]，给每阶段一个 WIP 上限。把数学讲清楚，让团队
接受这个上限而不是反感它。不要过度工程。8. 工程速度审计
工程流程：open -> in-progress -> code review -> merged -> deployed。哪个阶段
最拖？常见嫌疑：code review 等待、CI 时长、deploy 门禁、环境可用性。按中位
等待时间排序 + 给最高杠杆的那个修复。把每个阶段映射到它影响的 DORA 指标
（交付前置时间、部署频率）。9. 工单时长分析
工单平均 [avg] 关闭。分解：triage -> 首次响应 -> 调查 -> 修复 -> 验证 -> 关闭。
找等待最长的阶段，给 1 个干预（话术模板 / 自动化 / 升级规则）+ 预计能缩短多少
关闭时长。10. 销售周期审计
销售流程：lead -> 合格 -> demo -> 提案 -> 成交。审计：(a) 阶段间转化率、
(b) 各阶段平均时长、(c) 商机是悄无声息死还是被明确拒。点出漏水最严重的阶段
+ 1 个能堵住它的销售动作改变。11. 招聘流水审计
招聘流水：sourced -> 电面 -> onsite -> offer -> accepted。审计：(a) 各阶段
中位时长、(b) 各阶段流失率、(c) 各阶段最常见流失原因。输出 3 个针对性修复，
按对 time-to-hire 的影响排序。12. 瓶颈 → 路线图
识别出的瓶颈 A、B、C（粘在下面）。请按 impact / effort 排优先级，输出 90 天
计划：M1 = 快赢（不引入新工具）、M2 = 流程改变（需要团队对齐）、M3 = 自动化
或工具合并。每月给一个 owner + 一个成功指标。
[粘贴瓶颈列表]容易踩的坑
- 直接问”为什么都这么慢”，而不分阶段拆周期时间。
- 优化非瓶颈阶段。总周期时间不下降，只是让活更早堆到真瓶颈前面（约束理论 101）。
- 把锅扣给某个团队。瓶颈是系统性的，团队只是下游。
- 忽视等待时间。工作时间通常是更小的那一块，却吃掉所有注意力。
- 改之前没量基线。没有起始的流动效率数字，就证明不了改动有没有效果。
- “为了透明加一个审批”。每个审批本质上都是一条排队队列。
常见问题
流动效率定多少算合理？ 多数知识型团队就在 15%-25%（其余都是等待）。管理得好的流程能到约 40%，世界级精益运营能超过 50%。别去追 100%——适度缓冲是健康的。光是从 15% 提到 30%，通常就能把周期时间砍掉一半。
为什么优化非瓶颈阶段没用？ 总吞吐量被最慢的那段卡死。把别的阶段提速，只会让活更早堆到瓶颈前面。这正是高德拉特约束理论的核心：要么改约束本身，要么你什么客户能感知的改进都没做。
没有时间数据怎么办？ 不用先上工具。让 AI 根据你的描述先估一版，再拿两三个阶段对照真实时间戳核对（PR 打开 vs 合并、工单创建 vs 首次回复、线索创建 vs 约到 demo）。粗略数字就足以暴露瓶颈，精度可以后补。
该用哪个 AI 模型跑这些 Prompt？ 截至 2026 年 6 月，任何当前一线模型处理阶段表都没问题。ChatGPT Plus（$20/月，GPT-5.5）、Claude Pro（$20/月，Sonnet 4.6 / Opus 4.7）、Google AI Pro（$19.99/月，Gemini 3.1 Pro）都行。多阶段推理、要粘大量上下文时，用”思考”模式（GPT-5.5 Thinking、Claude Opus 4.7）并喂真实时间戳。
Little’s Law 一句话是什么？
周期时间 = WIP ÷ 吞吐量。如果有 30 项在进行、每周完成 6 项，平均周期时间就是 5 周。在吞吐量不变的前提下把 WIP 降到 18，周期就降到 3 周。这就是为什么设一个 WIP 上限能在零额外成本下缩短交付。