大多数 SOP 是为合规背书写的，不是给人用的。它们躺在没人点开的 Confluence 页面里，满是”ensure that X is done”这种没法执行的句子。而 SOP 烂掉的头号原因是没人真正拥有它——一旦 SOP 属于”公司”，就没人负责把它维护准确。下面这些 Prompt 强制做到：每步一个具名 owner、动词开头的步骤、每步带成功检查、一个复审日期、再加一份边界情况附录——这样写它的人请 PTO 时，流程照样跑得起来。要做岗位级知识交接，可配合 交接文档 Prompt。
一句话总结
- 下面每个 Prompt 产出的 SOP 都带：具名 owner、动词开头的编号步骤、每步成功检查、升级路径、复审日期——这正是被忽视的 SOP 缺的五样东西。
- 发出前，把每个
[方括号占位符]换成你真实的流程、岗位、工具和政策。输入越具体，输出越不空泛。 - 该用哪个模型： 填这些模板任何主流模型都行，但对于又长又结构化的流程，Claude（Opus 4.7 / Sonnet 4.6）在遵循多段格式要求上往往最稳；较短的 SOP，GPT-5.5 和 Gemini 3.1 Pro 也都好用。
- 给每份 SOP 定复审节奏：变动快的流程每季度复审，稳定的流程每年复审。没 owner、没复审日期的 SOP，本身就已经过期。
这套 Prompt 适合用在哪
- 新人入职
- 客服 / 运营流程
- 工程 on-call runbook
- 合规流程
- 客户面工作流
1. 一页 SOP 模板
为 "[流程]" 起一份 1 页 SOP。结构：1 句目的、一个具名 owner 角色、触发条件、
5-9 个编号步骤（每步以动词开头）、每步一个成功标准、升级路径、复审日期。
全文 ≤400 字。2. Day-1 入职 SOP
为新 [岗位] 起一份 day-1 入职 SOP。输入：[团队]、[工具]、[权限清单]。
输出：8 个编号步骤、每步 owner、耗时、每步成功检查。
包含"buddy 不在时怎么办"的兜底。3. 客服 ticket 分流 SOP
起一份客服 ticket 分流 SOP。输入：[ticket 类别]、[严重度等级]、[SLA]。
输出：编号分流步骤、严重度决策树、点名到人的升级路径、各严重度等级的响应时间目标。4. On-call runbook
为 [服务] 起一份 on-call runbook。触发：[告警]。输出：6 个步骤、每步要查的日志或指标、
3 个最常见原因、dashboard 链接、明确的"什么时候叫醒下一位工程师"阈值。5. 退款 / 拒付 SOP
起一份退款 SOP。条件：[政策]。输出：编号资格检查、决策矩阵（自动 / 人工 / 升级）、
客户回复模板、每条路径的日志留存要求。6. 发布 / 部署 SOP
为 [服务] 起一份发布 SOP。输入：[CI 系统]、[环境]、[回滚方式]。
输出：发布前 checklist、部署步骤、发布后验证、回滚触发条件、沟通节奏（谁、何时、被告知什么）。7. 合规 / 审计 SOP
为 "[控制项]" 起一份合规流程。参照框架：[SOC 2 / GDPR / HIPAA]。
输出：谁执行该控制、多久执行一次、每次要留存的证据、复核路径、控制失败时的升级步骤。8. 客户 onboarding SOP
起一份从合同签字到首次价值时刻的客户 onboarding SOP。
输出：6 个阶段、各阶段 owner、各阶段成功检查、沟通触点、推进到下一阶段的门槛条件。9. SOP 边界附录
下面是 "[流程]" 的 SOP。请加一份边界附录：当前 SOP 没覆盖的 top 6 边界情况、
每个怎么处理、应链接在现有哪一步下。
[粘贴 SOP]10. SOP 简化
下面这份 SOP 太长。请砍到 ≤50% 长度，且不丢任何关键步骤。同类步骤合并。
每个保留步骤加 1 行成功检查。
[粘贴 SOP]11. SOP 可测试性检查
下面是一份 SOP。逐步标出是否可测试（别人能验证你做了没）。
把不可测试的步骤重写成带具体、可观察检查的版本。
[粘贴 SOP]12. SOP → checklist 转换
把这份 SOP 转成"10 分钟能在真实工单上跑完"的 checklist。
输出 ≤12 个 checkbox、每条 ≤15 字。结尾再给 1 行"任何一条没通过就……"。
[粘贴 SOP]怎样一次就拿到能用的 SOP
- 喂真实流程，别喂流程的概念。 把你真实的工具名、岗位头衔、严重度等级、政策原文填进方括号。
[政策]留空只会得到通用模板；填上你真实的 30 天退款窗口，才能得到能用的草稿。 - 要求每一步都有成功检查。 这是杠杆最高的一条指令。“第 4 步：通知客户”无法验证；“第 4 步：发送退款确认邮件；成功 = 邮件出现在工单线程里”任何人都能核对。
- 要求步骤动词开头。 “确保账户已关闭”把动作藏起来了；“在 Admin > Users > Deactivate 关闭账户”才告诉操作员具体怎么做。
- 把复审日期写进文档里。 变动频繁的流程（客服、发布）每季度，稳定的（合规、财务）每年。把 owner 角色和下次复审日期放到顶部，别埋进没人看的元数据。
- 能一页就一页。 长 SOP 会被略读、被忽视。草稿太长就用第 10 个 Prompt 砍短，或拆成两份流程。
容易踩的坑
- 每步没具名 owner——“团队”等于没人，于是没人维护。
- 步骤不是动词开头（“ensure that X is done”）——读者执行不了。
- 没成功标准——操作员做完第 4 步，不知道自己有没有真做完。
- 没边界情况或”if 分支”——第一个奇怪场景就把 SOP 打穿。
- 没标日期 / 版本号——读者分不清是不是现行版。
- 没复审节奏——流程变了，SOP 没变，团队就悄悄不再信它。
常见问题
起草 SOP 该用哪个 AI 模型？ 短 SOP 任何主流模型都能搞定。但长、多段、格式严格的流程（owner、步骤、检查、升级、复审日期一次到位），Claude Opus 4.7 和 Sonnet 4.6 在遵循复杂指令上往往最稳。GPT-5.5 和 Gemini 3.1 Pro 也很强；用你手头有的那个，套同一套 Prompt 结构即可。
SOP 多久复审一次？ 经验法则：变动快的流程（客服分流、发布、on-call）每季度复审，稳定的（合规、财务、入职）每年复审——一旦底层流程或工具有变，立刻重审。把下次复审日期和 owner 角色放在每份 SOP 顶部。
为什么大多数 SOP 最后都没人用？ 反复出现的失败点是”归属”：当 SOP 属于”公司”而非某个具名角色，就没人维护、它慢慢过期、团队也就不再信任。第二个元凶是篇幅——长文档会被略读。上面的 Prompt 通过强制单一 owner、把输出压紧，同时对付这两点。
AI 会不会编出我其实没有的流程？ 会，这正是风险所在。模型会用听起来合理的通用步骤填补空缺。务必把真实政策、工具、严重度等级填进方括号，再用第 11 个 Prompt（可测试性检查）标出人没法验证的步骤——那些通常就是被编出来的。
SOC 2 / GDPR / HIPAA 这类合规 SOP 能交给 AI 写吗？ 可以用它出初稿和结构（第 7 个 Prompt），但上线前必须由合格的人对照你真实的框架义务，逐条核实每个控制项、证据要求和频率。把 AI 产出当起步草稿，永远别当权威合规文本。