Sop Writer

把口头描述的流程写成可执行的SOP文档，含角色分工与异常处理。 当用户提到「写SOP」「流程文档」「操作规范」「标准作业程序」时使用。

SOP流程文档生成器 (ym-sop-writer)

把口头、聊天式或逐条列出的流程描述，整理成可执行的标准作业程序（SOP）。先按模板做访谈式补全，补齐关键字段后再落文档，不替用户编造流程细节。

何时使用

• 用户说「写SOP」「流程文档」「操作规范」「标准作业程序」时
• 用户贴出一段流程描述（口头的、聊天的、或逐条列的），说「帮我把这个写成 SOP」
• 用户已有流程但缺少异常处理、职责划分，想补全成可下发文档

运行前提

• 依赖：无第三方依赖，纯文本生成，不读取本地文件、不联网
• 不操作任何业务系统，只产出 SOP 文档文本
• 不替代公司制度文件的合规审核
• 输出语言与用户一致，正文用中文，岗位名与系统名保持用户原称

输入契约

项	必需	说明
流程描述	必需	口头 / 聊天 / 逐条均可，说清大致步骤
参与角色	可选	可多个；不提供时先问
执行频率	可选	如每日 / 每周 / 按需
易错点补充	可选	用户知道的坑，优先写进异常分支

缺失处理：

• 缺触发条件 / 输入材料 / 判断点 / 异常处理 / 交付物中任一项 → 先提问补齐，一次问齐，不超过 5 个问题
• 缺角色 → 问清谁执行、谁审核、谁知会
• 描述过粗（如「按之前那样做」）→ 追问具体动作，不自行假设
• 已给的信息若前后矛盾（如说周五交又说过完节交）→ 在提问里一并指出，请用户确认以哪个为准

访谈式补全示例

用户给：「每周让组员交周报，周五交，交给我看看，然后存档。」 缺失字段识别：

• 触发条件：已知「周五」（部分明确）
• 输入材料：未说用什么模板、从哪来
• 判断点：未说「交给我看看」算完成的标志
• 异常处理：完全没提（组员不交 / 交晚怎么办）
• 交付物：未说存档形式与位置
• 角色：只说「我」和「组员」，未定岗位名

一次提问（4 个，不超过 5 个）：

1. 您和组员的岗位分别是什么，由谁最终归档？
2. 周报用什么模板、从哪获取，提交前要不要您先确认？
3. 组员周五没交或交晚了，怎么办？
4. 归档存到哪（系统 / 共享盘 / 群文件），以什么形式？

收到回答后再落 SOP，绝不自行假设「应该发邮件」之类业务规则。

执行步骤

1. 解析输入 — 把用户描述拆成步骤草稿，标出已有字段与缺失字段。
2. 对照模板查缺 — 拿 templates/sop-template.md 的字段清单逐项比对，记录缺触发条件 / 输入材料 / 判断点 / 异常处理 / 交付物哪些。
3. 一次问齐 — 把缺失项整理成不超过 5 个问题一次发出，禁止边写边猜、禁止编造。
4. 补全字段 — 收到回答后填入；仍拿不准的字段标注「待补」并在修订记录说明来源。
5. 产出正文 — 套模板生成：适用范围 → 角色职责表(RACI) → 步骤表(S1、S2…) → 附件清单 → 修订记录。
6. 补异常分支 — 每步必须有「异常时怎么办」；确实没有写「无已知异常，出现即上报」并标注待补。
7. 写区分要点 — 若有两步易混，在步骤表后写「区分要点」说明差异，避免执行者混淆。
8. 自检 — 对照 references/sop-quality.md 六条判据逐条过，确认新人只看文档能走完。

输出格式

Markdown，结构如下：

text

# 【流程名称】标准作业程序 (SOP)
## 1. 适用范围（适用 / 场景 / 不适用）
## 2. 角色职责表 (RACI)
## 3. 步骤表（步骤 / 操作 / 判断条件 / 异常时怎么办 / 交付物）
## 4. 附件清单
## 5. 修订记录

一个补全后的精简示例（沿用上文周报访谈）：

text

# 周报表提交标准作业程序 (SOP)
## 1. 适用范围
- 适用：各业务线周报负责人（各组组长）
- 场景：每周五 18:00 前
- 不适用：法定节假日按行政通知顺延

## 2. 角色职责表 (RACI)
| 角色(岗位) | 执行(R) | 审核(A) | 知会(I) |
|---|---|---|---|
| 周报负责人 | 是 | | 是 |
| 部门主管 | | 是 | |
| 行政助理 | | | 是 |

## 3. 步骤表
| 步骤 | 操作 | 判断条件 | 异常时怎么办 | 交付物 |
|---|---|---|---|---|
| S1 | 系统导出本周清单，按模板填完成情况 | 系统可登录且数据已同步 | 无法登录：报 IT 并群内报备，顺延不超 1 小时 | 周报草稿 |
| S2 | 草稿发部门主管确认 | 主管 30 分钟内回复 | 超时：电话提醒一次，仍无回按已知会提交 | 经确认周报 |

## 4. 附件清单
- 周报模板（知识库「周报」分类）

## 5. 修订记录
| 版本 | 日期 | 修改人 | 变更说明 |
|---|---|---|---|
| v0.1 | 【填写】 | 【填写】 | 初稿 |

完整带异常细节的版本见 templates/sop-template.md 第三节。步骤统一用 S1、S2 稳定编号，后续修订只加新号不改旧号，方便其他文档引用。

RACI 填写要点

角色职责表用 RACI 四态标注，每个角色对每一步至少占一态，避免「都负责等于都不负责」。

• R（Responsible 执行）：实际动手做这一步的人，通常唯一。
• A（Accountable 审核）：对结果拍板、担责的人，每步有且仅有一个。
• C（Consulted 被咨询）：执行前需先听其意见的人，双向沟通。
• I（Informed 知会）：事后被告知结果的人，单向通知。

填写规则：

• 岗位写具体名（「部门主管」「IT 支持」），不写「相关人员」「有关部门」。
• 同一步里 R 与 A 尽量不是同一人，形成执行与审核分离。
• 若某角色全程只知会，也应在表中列出，保证职责无遗漏。
• 一个岗位可能跨多步承担不同态，逐行标清即可。

步骤表填写提示

步骤表是 SOP 的核心，按以下要点逐列填写，可显著降低执行偏差：

• 操作列：写「动词 + 宾语 + 关键参数」，例如「从系统导出本周清单」而非「整理数据」；能写出具体菜单/字段名就写，写不出标注「以实际系统界面为准」。
• 判断条件列：写「满足什么算这步做完」，例如「主管 30 分钟内回复」；没有判断条件这步就无法自检，必须补。
• 异常列：按「现象 + 动作」写，例如「系统无法登录：报 IT 并群内报备，顺延不超 1 小时」；确实无异常写「无已知异常，出现即上报」并标注待补。
• 交付物列：写具体产出物名，例如「周报草稿」「经确认周报」，不写「完成」「搞定」。
• 易混步骤：在两步之间补「区分要点」，点明差异，例如「S1 产出草稿不对外，S2 产出才是可提交版」。

验收用例

• 输入：一段 5 句话的口头流程（故意缺异常处理）→ 先收到补全提问（不超过 5 个），补齐后产出的 SOP 每步有异常分支、职责表具体到岗位。
• 边界：用户说「按之前那样做」→ 追问具体动作，不写成引用失效的步骤。
• 边界：无任何角色信息 → 提问补齐，不写「相关人员」。

能力边界

• 不做流程审批系统、不画泳道图（以文字表格为主）。
• 不替代公司制度文件的合规审核，只把流程写清楚。
• 不操作业务系统、不验证系统真实界面，截图级细节由执行者按当前版本自补。
• 不跨次存储历史 SOP，除非用户要求保存到指定位置。

常见坑

1. 写成制度腔不像操作手册 — 现象：满篇「应严格遵守」「加强协作」却无可执行动作。原因：把目标当步骤写。规避：每条步骤写成具体动作加判断点，对照 references/sop-quality.md 反例表改写。
2. 漏异常分支一执行就卡 — 现象：步骤只写正常路径，卡住没人知道怎么办。原因：默认一切顺利。规避：每步必填异常分支，没有就写「无已知异常，出现即上报」并标注待补。
3. 职责写「相关人员」等于没写 — 现象：职责表写「相关人员负责审核」。原因：怕写错岗位名。规避：问清具体岗位，写到「部门主管」「IT 支持」这种程度。
4. 步骤写「按之前那样」引用失效 — 现象：步骤是「按上周的方式处理」。原因：用户描述本就模糊，直接照抄。规避：遇这类引用一律追问具体动作，改写为可独立执行的步骤。
5. SOP 与实际系统界面脱节 — 现象：写「在系统里点提交」但没说哪个菜单、什么按钮。原因：写作者不了解真实界面。规避：系统级细节标注「以实际系统界面为准，执行者按当前版本核对」，不杜撰按钮名。
6. 步骤无编号无法引用 — 现象：用「然后」「之后」串步骤，别处想引用找不到锚点。原因：没编号。规避：统一用 S1、S2 稳定编号，修订时不改旧号只加新号。
7. 编造流程细节 — 现象：用户没说异常处理，自己编一套看似合理但不符合实际。原因：想让文档「完整」。规避：拿不准的标注「待补」并提问，不替用户决定业务规则。

目录说明

• templates/sop-template.md — SOP 正文模板，含字段清单、填写说明与填好的 3 步示例
• references/sop-quality.md — 好 SOP 的 6 条判据与制度腔 / 操作腔反例对照
• scripts/ — 预留（本技能为纯文本生成，当前无脚本依赖）