“我们怎么变得更高效”这种 Prompt 只会得到空话。好的 Prompt 强制具体：工作到底在哪里等、谁交给谁、上周升级了什么、什么本来就不该开会。下面 15 个模板帮你越过空话——价值流图、摩擦清单、retro 深挖、自动化候选、还有那个尴尬的”这个角色还需要吗”。
适合哪些场景
运营负责人、工程经理、chief of staff、过了 10 人规模的创始人、接手停滞团队的 lead、任何想让 retro 真的产生变化的人。
什么时候不建议这样写 Prompt
别用在没抱怨的健康团队上——解决方案找问题会造成变更疲劳。也别用在危机事件——那要 post-mortem，不是流程重设计。
Prompt 结构公式
流程改进 Prompt 一定要带这六个要素：
- 角色：让 AI 扮演谁（PM、chief of staff、运营、财务分析、经理）。
- 上下文：公司 / 团队 / 项目 / 受众 / 之前发生了什么。
- 目标：一个具体可交付物——memo、邮件、talking points、表格、优先级清单。
- 限制：不能做什么（别有营销腔、别超出事实推断、别写 PII、控制字数）。
- 输出格式：编号小节、markdown 表格、Slack 友好的 bullet，或 1 页 memo。
- 示例 / 信号：1-2 行”好语气”示例，或一个可模仿的过往样本。
这套 Prompt 适合用在哪
- 周期时间悄悄变长后的季度流程 review
- 新人入职审计：为什么要 3 个月才能产出
- 老掉东西的跨团队交接
- 上季度 retro 产生了 12 个行动项、0 个真改的
- 创始人在问”团队时间到底花在哪了”
15 个可直接复制的 Prompt 模板
1. 价值流图（intake → done）
先跑这个。强制你写出每一步。
You are an ops consultant. Below is how work flows through {team / process}. Build a value-stream map. For each step: name | average time | wait time before | who owns | typical defect. Then identify the top 3 steps with the worst wait-time-to-work-time ratio. End with: "If you only fix one, fix this — and here is why."
Process description: {paste}可替换变量： team / process —— 团队或工作流名, paste —— 从 intake 到 done 的当前流程
优化建议： 输出太空加：“Wait time = time work sits doing nothing. Be ruthless about distinguishing wait from work.”
2. 摩擦清单（过去 2 周）
Below are notes / Slack threads / tickets from the last 2 weeks. Extract a "friction inventory" — every time someone said "this is annoying", "we always have to", "I wasted X time on". For each: friction description, frequency signal (how often it comes up), who feels it. Rank by total time lost across the team, not number of mentions.
{paste}3. Retro 深挖（非常规）
Below are retro notes from {N} retros. Most retros produce action items that never get done. Analyze: (1) Themes that repeat across retros (the unresolved ones), (2) Action items from past retros — which got done, which didn't, why, (3) Things people complained about but no action item was raised (the silent ones), (4) One change that would have the highest leverage. No "communicate better".
Retros: {paste}4. 交接审计
流程痛点大多发生在交接处。
Audit handoffs in {process}. For each handoff: from whom to whom, what is supposed to be passed (the artifact), what is often missing or wrong, how the receiver discovers the gap (immediately / next day / never). Score each handoff by failure rate. The top failure is the highest-ROI fix.
Process: {paste}可替换变量： process —— 流程名
5. 自动化候选
Below are recurring tasks the team does. For each: (1) Task description, (2) Frequency (daily / weekly / monthly), (3) Time per occurrence, (4) Inputs (where they come from), (5) Outputs (where they go), (6) Variability (always identical / minor variation / lots of judgment). Then rank automation candidates by (frequency × time) ÷ variability. Skip anything with high judgment — that's not automatable yet.
Tasks: {paste}6. 周期时间分解
For {workflow}, the cycle time is currently {time}. Decompose where that time goes: (1) Active work, (2) Waiting on people, (3) Waiting on systems, (4) Rework, (5) Context-switching. Use the data I provide. Then identify the single largest bucket and propose 3 reductions specifically for that bucket. Do not propose changes to the other buckets.
{paste}可替换变量： workflow —— 名称, time —— 当前周期时间
7. “为什么还在做这个”审计
找无人说得清的仪式。
List every recurring meeting / ritual / report / artifact this team produces. For each, ask: (1) Who originally requested it, (2) Is that person / need still here, (3) What decision does this enable, (4) What would break if we stopped. Categorize each as: Keep / Slim / Kill / Investigate. Be biased toward Kill.
List: {paste}8. 入职摩擦地图
A new hire just finished their first 30 days. Below are their notes on what was confusing, slow, missing, or broken. Group findings by: (1) Tools / access (the boring stuff that delays week 1), (2) Information (docs missing or stale), (3) Social (who do I ask), (4) Work intake (when do I get a real task). For each: severity (must-fix / nice-to-fix), owner, fix sketch.
Notes: {paste}9. “审批债”审计
Audit all approval gates in {process}. For each: (1) What is approved, (2) Who approves, (3) Median wait time, (4) Reject rate (real, not aspirational), (5) What changed in the last year that could let us delete this gate. Approval gates with > 95% approve rate are usually theater — flag them.
{paste}可替换变量： process —— 流程名
10. 沟通 / 会议负担审计
Below are 2 weeks of calendar + Slack data for {team}. Identify: (1) Meetings > 30 minutes that could be async, (2) Slack threads > 20 messages that should have been a doc + decision, (3) Recurring meetings with attendance < 50% (cancel candidates), (4) "Always Friday at 4pm" meetings that lose 30% of the room. End with: 3 specific calendar changes for next week.
Data: {paste}可替换变量： team —— 团队名
11. 工具栈审计
Below is our tool stack: {list}. Audit for: (1) Overlap (two tools doing the same job), (2) Underuse (license cost ÷ active users > $X), (3) Integration gaps (work that gets manually copied between tools), (4) Tools nobody can name an owner for. Recommend: keep / consolidate / drop.
{paste}可替换变量： list —— 当前工具栈 + 席位数
12. 季度流程回顾
Below is data from the last quarter: cycle time, ticket backlog, escalations, retros, post-mortems. Write a quarterly process retrospective with: (1) Trends (improved / stable / worsened with numbers), (2) Three biggest process learnings, (3) Three changes for next quarter (specific, measurable), (4) One process I commit to NOT changing because it works.
Data: {paste}13. “这个角色还需要吗”
尴尬但规模化后必须做。
A role / function exists: {role}. Audit whether it is still load-bearing: (1) What problem did this role solve when created, (2) Does that problem still exist at the same scale, (3) Where would the work go if the role moved or absorbed, (4) Hidden value the role creates that isn't in the JD (institutional memory, glue work, escalation buffer), (5) Recommendation: keep / re-scope / merge / sunset. Treat this analytically, not personally.
Context: {paste}可替换变量： role —— 角色 / 职能
14. 跨职能依赖映射
Below is what my team needs from other teams (and vice versa) over the last quarter. Map dependencies: (1) Strongest dependencies (we block each other often), (2) Asymmetric ones (we depend on them more than they depend on us — political risk), (3) Forgotten ones (we used to coordinate but stopped), (4) Manufactured ones (we ping them but don't really need to). Suggest one ritual to fix the top asymmetric dependency.
{paste}15. 先 pilot 再推广
别第一天就全员铺。
I want to change {process}. Help me design a pilot: (1) Smallest credible test (which team / scope / duration), (2) Success criteria (specific metric thresholds before rolling out), (3) Kill criteria (what we'd see that would make us scrap it), (4) Communication plan during pilot, (5) Decision date for go / no-go, (6) Rollback path if we ship and regret. End with one paragraph: "Why this is reversible, and why that matters."
{paste}可替换变量： process —— 要改的流程
容易踩的坑
- 问”怎么改进”而不指定具体流程——输出全是空话。
- 数提及次数而不是总损失时间——抱怨大 ≠ 痛点大。
- 不分解等待时间——周期时间大部分是等而不是干。
- 一改就全员铺——变更疲劳 + 没有学习循环。
- 把”应该自动化”当成结论——自动化是项目不是一句话。
- 产出 12 条 retro 行动项——真能落地的最多 3 条。
- 没”保持不变”那一列——什么都在变就没有稳定。
优化技巧
- 一切量化。没数字的”周期时间”是诗。
- 执着区分等待 vs 工作。砍等待便宜 10 倍。
- 按流程审计而不是按团队审计。一个团队多个流程，一次审一个。
- 每次只输出一个最高杠杆改动，不是列表。列表不会被执行。
- 自动化候选用 频率 × 时间 × 低变化性 排序，判断重的跳过。
- 每个改动都 pilot。“试过”比”讨论过”价值高 5 倍。
- 改完 90 天后再审一次。不测量就不知道有没有效。
FAQ
- 多久做一次流程改进？: 季度。月度太频繁会疲劳，年度让债务累积。
- 谁来跑这些 Prompt——经理还是 IC？: IC 说出摩擦（他们在受），经理排序并 pilot。两者都参与，AI 帮你看跨人的模式。
- leadership 不愿意排序怎么办？: 把周期时间换算成钱或产出。“每张 ticket 等 4 天” → “每季度少 2 个功能”。
- 产出可以公开吗？: 发现可以。角色审计（模板 13）和个人绩效信号不行。小心别贴进共享文档。
- pilot 该多大？: 最小可信测试——通常一个团队一个周期（sprint / 周 / 季度）。大爆炸推广失败率更高。
- AI 会发明不适合我们的流程吗？: 会。一定要给真实工作流步骤，别给抽象。任何”招人 / 买工具”的建议直接拒。