“为什么都这么慢”问错了——这种问法只会换来”大家要更专注”那种空话和又一次全员大会。对的问题是把周期时间一段段拆开、把工作时间和等待时间分开，然后找出”60% 的总耗时其实是排队而不是动手”那一段。下面这些 Prompt 强制做这种分解，点名等待 / 工作比最差的那一段，并给出排序好的修复方案——而不是把锅扣到某个团队头上。识别完瓶颈之后做改进可配合 流程改进 Prompt。
这套 Prompt 适合用在哪
- 工程速度审计
- 客服工单时长分析
- 销售周期审计与管道漏水
- 招聘流水审计
- 审批链与交接审查
- 跨工具流程合并
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）算 throughput vs WIP。给每阶段一个 WIP 上限。把数学讲清楚，让团队接受这个上限，而不是反感它。不要过度工程。8. 工程速度审计
工程流程：open → in-progress → code review → merged → deployed。哪个阶段最拖？常见嫌疑：code review 等待、CI 时长、deploy 门禁、环境可用性。按中位等待时间排序 + 给最高杠杆的那个修复。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 + 一个成功指标。
{粘贴瓶颈列表}容易踩的坑
- 直接问”为什么都这么慢”而不分阶段拆周期时间
- 优化非瓶颈阶段——总周期时间不下降，只是给瓶颈让出更多余量
- 把锅扣给某团队——瓶颈是系统性的，团队只是下游
- 忽视等待时间——工作时间通常比等待时间短，却吃掉所有注意力
- 改之前没量基线——改完没法判断有没有效果
- “为了透明加一个审批”——每个审批本质上都是排队