Back to Details

sop-creator

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

SOP & Runbook Creator

SOP & Runbook 创建指南

Create practical documentation that people actually follow.
创建真正有人会遵循的实用文档。

Philosophy

核心理念

Nobody reads 50-page docs. Make it scannable, actionable, and impossible to misunderstand.
Core principles:
  • Scannable - Headers, bullets, tables. No walls of text.
  • Actionable - Every step is something you DO, not something you "consider"
  • Specific - Numbers, names, thresholds. No "as needed" or "when appropriate"
  • Testable - Clear success criteria. How do you know it worked?
  • Maintained - Owner, last updated, review schedule
没人会读50页的文档。 要让文档易扫描、可执行、绝无歧义。
核心原则：
  • 易扫描 - 使用标题、项目符号、表格。避免大段文字堆砌。
  • 可执行 - 每一步都是具体动作，而非“考虑事项”
  • 具体明确 - 包含数字、名称、阈值。杜绝“按需”或“视情况而定”
  • 可验证 - 明确成功标准。如何确认操作生效？
  • 可维护 - 标注负责人、最后更新时间、审核周期

SOP Categories

SOP 分类

Pick the right format for your use case:
根据使用场景选择合适格式：

Tech/Engineering

技术/工程类

TypeWhen to Use
RunbookEmergency response, incidents, on-call
Deployment PlaybookReleases, migrations, maintenance
Troubleshooting GuideDebugging, diagnosis trees
How-To GuideOne-off setup, configuration
ADRArchitecture decisions
类型使用场景
Runbook应急响应、事件处理、值班场景
Deployment Playbook版本发布、迁移、维护操作
Troubleshooting Guide调试、诊断流程
How-To Guide一次性配置、设置操作
ADR架构决策记录

Operations/Business

运营/业务类

TypeWhen to Use
Process SOPRepeatable business workflows
ChecklistQuality control, verification
Decision TreeComplex if/then scenarios
Handoff DocRole transitions, shift changes
类型使用场景
Process SOP可重复的业务工作流程
Checklist质量控制、验证环节
Decision Tree复杂的分支场景
Handoff Doc角色交接、班次轮换

Content/Creative

内容/创意类

TypeWhen to Use
Production WorkflowContent creation pipelines
Review ProcessApproval workflows
Publishing ChecklistPre-launch verification
类型使用场景
Production Workflow内容创作流水线
Review Process审批工作流程
Publishing Checklist发布前验证

General

通用类

TypeWhen to Use
Standard SOPAny repeatable process
Quick ReferenceCondensed version of longer SOP
Onboarding GuideNew person ramping up
类型使用场景
Standard SOP任何可重复流程
Quick Reference长篇SOP的精简版本
Onboarding Guide新员工入职培训

Universal Structure

通用结构

Every SOP needs at minimum:
markdown
undefined
每份SOP至少包含以下内容：
markdown
undefined

[What This Does]

[文档用途]

TL;DR: One sentence - what, when, who.
TL;DR： 一句话说明——内容、适用场景、负责人员。

Definition of Done

完成标准

This is complete when:
  • [Primary outcome]
  • [Verification step]
  • [Any handoff/notification]
满足以下条件即视为完成：
  • [核心成果]
  • [验证步骤]
  • [交接/通知事项]

When to Use This

适用场景

[Trigger conditions]
[触发条件]

Prerequisites

前置条件

[What you need before starting]
[开始前需准备的事项]

The Process

操作流程

[Numbered steps - the actual work]
[编号步骤——具体执行动作]

Verify Completion

完成验证

[Return to Definition of Done, confirm all checked]
[对照完成标准，确认所有项已勾选]

When Things Go Wrong

异常处理

[Common issues and fixes]
[常见问题及解决方法]

Questions?

疑问咨询

[Who to contact]

**Definition of Done is the most important section.** Put it near the top. Make it a checklist. Be specific.
[联系人员]

**完成标准是最重要的部分。** 放在靠近顶部的位置，做成检查清单，内容要具体。

Writing Rules

写作规则

Be Specific

内容要具体

Don't WriteWrite Instead
"Contact the team""Message @sarah in #ops-team"
"Wait until ready""Wait until status shows 'Complete' (~5 min)"
"Review carefully""Check items A, B, C in the dashboard"
"As appropriate""If value > 100"
"Regularly""Every Monday at 9am"
"Soon""Within 2 hours"
错误写法正确写法
"联系团队""在#ops-team频道给@sarah发消息"
"等待准备就绪""等待状态显示‘完成’（约5分钟）"
"仔细审核""检查仪表盘中的A、B、C项"
"视情况而定""当数值>100时"
"定期""每周一上午9点"
"尽快""2小时内"

Action-First Steps

动作优先的步骤

markdown
undefined
markdown
undefined

Bad

错误示例

"The report should be reviewed before sending to ensure accuracy and completeness of all data fields."
"发送前应审核报告，确保所有数据字段准确完整。"

Good

正确示例

  1. Open the report in [System]
  2. Verify these fields are populated:
    • Customer name
    • Amount
    • Date
  3. Click "Send"
undefined
  1. 在[系统]中打开报告
  2. 验证以下字段已填写：
    • 客户名称
    • 金额
    • 日期
  3. 点击“发送”
undefined

Warnings Come First

警告前置

markdown
undefined
markdown
undefined

Bad

错误示例

  1. Delete the old records Note: This cannot be undone
  1. 删除旧记录 注意：此操作不可撤销

Good

正确示例

WARNING: This permanently deletes records. Export first if needed.
  1. Delete the old records
undefined
警告： 此操作将永久删除记录。如需保留请先导出。
  1. 删除旧记录
undefined

Decision Points are Clear

决策点清晰明确

markdown
undefined
markdown
undefined

Bad

错误示例

"Handle the request based on priority level"
"根据优先级处理请求"

Good

正确示例

If priority is:
  • Critical: Drop everything, handle now, notify manager
  • High: Handle within 4 hours
  • Normal: Handle within 24 hours
  • Low: Add to weekly batch
undefined
若优先级为：
  • 紧急： 暂停手头工作，立即处理并通知经理
  • 高： 4小时内处理
  • 普通： 24小时内处理
  • 低： 加入每周批量处理任务
undefined

Format Selection Guide

格式选择指南

Ask yourself:
  1. Is this for emergencies? → Runbook
  2. Is this a complex multi-phase project? → Playbook
  3. Is this a simple repeated task? → Standard SOP or Checklist
  4. Does it have lots of if/then branching? → Decision Tree
  5. Is it for debugging? → Troubleshooting Guide
  6. Is it recording a decision? → ADR
  7. Is it for someone new? → Onboarding Guide
问自己以下问题：
  1. 这是用于应急场景吗？ → Runbook
  2. 这是复杂的多阶段项目吗？ → Playbook
  3. 这是简单的重复任务吗？ → 标准SOP或检查清单
  4. 包含大量分支场景吗？ → 决策树
  5. 这是用于调试吗？ → 故障排查指南
  6. 这是记录决策吗？ → ADR
  7. 这是给新人用的吗？ → 入职指南

Metadata (Keep it Light)

元数据（简洁为主）

yaml
---
title: [Clear name]
owner: [Person or team]
last_updated: [Date]
review_schedule: [quarterly/annually/as-needed]
---
That's it. No document IDs, version matrices, or approval chains unless you actually need them.
yaml
---
title: [清晰名称]
owner: [负责人或团队]
last_updated: [日期]
review_schedule: [季度/年度/按需]
---
这样就够了。除非确实需要，否则无需添加文档ID、版本矩阵或审批链。

Templates

模板

Each template is in 
references/
:
TemplateUse For
runbook.mdIncidents, emergencies, on-call
standard-sop.mdAny repeatable process
how-to-guide.mdOne-off tasks, setup
onboarding-guide.mdNew person ramping up
decision-tree.mdComplex if/then flows
checklist.mdQC, verification
All templates have Definition of Done as the primary success criteria.
所有模板位于
references/
目录下：
模板用途
runbook.md事件处理、应急响应、值班场景
standard-sop.md任何可重复流程
how-to-guide.md一次性任务、配置操作
onboarding-guide.md新员工入职培训
decision-tree.md复杂分支流程
checklist.md质量控制、验证环节
所有模板均以“完成标准”作为核心成功准则。

Quality Checklist

质量检查清单

Before publishing:
  • Can someone unfamiliar follow this?
  • Are all steps actionable (verbs, not descriptions)?
  • Are specifics provided (names, numbers, thresholds)?
  • Is there a clear "done" state?
  • Is the owner/contact info current?
  • Has it been tested recently?
发布前确认：
  • 不熟悉流程的人能否遵循此文档？
  • 所有步骤均为可执行动作（动词开头，而非描述性语句）？
  • 是否包含具体信息（名称、数字、阈值）？
  • 是否有明确的“完成”状态？
  • 负责人/联系信息是否最新？
  • 近期是否经过测试？

Anti-Patterns

反模式

Kill these:
  • "Per company policy..." (just state what to do)
  • "It is recommended that..." (just say "do X")
  • "Please ensure..." (just say "check X")
  • Passive voice ("the form should be submitted" → "submit the form")
  • Describing what to do instead of showing it
  • Walls of text with no structure
  • Screenshots that will be outdated in a month
Do these:
  • Start with the most common path
  • Put edge cases at the bottom
  • Link to related docs instead of duplicating
  • Use tables for reference info
  • Use checklists for verification steps
  • Include "I'm stuck" escape hatches
杜绝以下做法：
  • “根据公司政策……”（直接说明要做什么）
  • “建议……”（直接说“执行X操作”）
  • “请确保……”（直接说“检查X项”）
  • 被动语态（“表单应被提交” → “提交表单”）
  • 只描述做法而非展示步骤
  • 无结构的大段文字
  • 很快会过时的截图
推荐做法：
  • 从最常见的流程路径开始
  • 把边缘案例放在底部
  • 链接到相关文档而非重复内容
  • 用表格展示参考信息
  • 用检查清单做验证步骤
  • 包含“遇到问题时”的求助渠道