360 Secure SkillHub
360 安全技能中心

Sop Writer

把用户口头、聊天或逐条列出的流程描述整理成标准作业程序(SOP)文档,结构含适用范围、RACI角色职责表、带异常分支的步骤表、附件清单与修订记录。信息不全时一次提出不超过5个问题补齐,遇到「按之前那样做」等模糊表述会追问,不自行编造业务规则。

liuyuming0823
liuyuming0823
热度 15.73
最近更新 2026-09-19 01:50:31
分类:效率依赖:纯提示词应用场景:工作流 / 模板

安装技能

复制下面的话术发给你的 Agent,它会通过 secure-skills 检索并安装该技能。

执行命令安装此 skill: npx secure-skills-cli add ym-sop-writer-ch
Metadata
name
ym-sop-writer
slug
ym-sop-writer
display_name
SOP流程文档生成器
display_name_en
SOP Document Writer
displayName
SOP流程文档生成器
description
把口头描述的流程写成可执行的SOP文档,含角色分工与异常处理。 当用户提到「写SOP」「流程文档」「操作规范」「标准作业程序」时使用。
description_zh
把口头描述的流程写成可执行的SOP文档,含角色分工与异常处理。
description_en
Turn verbal workflows into executable SOP documents with roles and exceptions.
summary
把口头描述的流程写成可执行的SOP文档,含角色分工与异常处理。
category
business-ops
version
0.1.0
author
刘玉明
tags
["写SOP","流程文档","操作规范","标准作业程序"]
trigger
["写SOP","流程文档","操作规范","标准作业程序"]
agent_created
true

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,结构如下:

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

一个补全后的精简示例(沿用上文周报访谈):

# 周报表提交标准作业程序 (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/ — 预留(本技能为纯文本生成,当前无脚本依赖)