标准流程手册

解决什么问题

团队里最常见的文档债，不是没人写文档，而是文档写在了别人的脑子里。事故响应靠口头喊、发布步骤存在某个人的笔记里、新人入职全靠师傅带。结果是同一件事每次做法都不一样，出问题时没人知道「做到什么程度算完成」。

@kunlungrowth/sop-creator 要补的就是这个缺口：把零散的口头流程、事故经验、发布步骤整理成一份陌生人照着做也能做对的操作文档。

核心能力

这个技能扮演的角色是 SRE / 技术文档工程师，产出物有明确的工件类型 SopDoc，包含 definition_of_done、steps、verify、when_wrong、contact 等结构化字段。这意味着文档不是散文，而是可以被下游程序消费的——资料里提到可以直接交给 pptx-generator 生成培训幻灯片，或纳入 biz-onboarding 新人手册。

工作流程分五步：

• 选对文档类型：先问「这是干什么用的」，再决定是 Runbook、Playbook、Checklist、决策树、排障指南、ADR 还是 Onboarding 指南
• 套用固定骨架：每份文档至少包含 8 个板块，其中 Definition of Done 放在靠前位置且必须是可勾选清单
• 写动作而非描述：步骤写成「打开报表系统 → 核对字段 A/B/C → 点击发送」，而不是「发送前应审核报表以确保准确完整」
• 警告前置：不可逆操作的警告写在步骤之前，不藏在正文中间
• 把模糊词换成具体值：这是最容易被忽略的一环。比如「联系团队」要具体到「在 #ops-team 频道 @sarah」，「定期」要写成「每周一 9:00」

关键设计取舍

Definition of Done 被刻意放在文档靠前的位置，而不是结尾。理由是读者打开文档时，第一反应是「我怎么知道做完了」，而不是「有哪些步骤」。这也呼应了技能的目标：让不熟悉流程的人 10 分钟内把事情做对，并清楚验收标准。

分支判定也要求可判定。比如优先级处理不能写「尽快处理」，而要写成 若优先级=Critical：放下一切立即处理并通知主管；High：4 小时内；Normal：24 小时内；Low：归入周批处理。

适用边界

明确不适用的场景有两类：纯战略或政策论述（技能产出的是「动手做」的步骤，不是制度文件）；以及具有法律效力的制度——这类文档只能参考技能给的结构模板，正式版本以官方发布为准。

另外，技能输出包含两段：结构化的 SopDoc 工件，以及改进建议（格式选择理由、三条最该补的具体值、质量检查表勾选结果）。如果你手头的流程本身就很模糊，这份建议可能比文档本身更有价值。