把口述流程整理成同事能照着执行的 SOP

要把口述流程整理成 SOP，先保留原始口述稿，明确初始状态，再为每个操作写上检查方法和来源。保留更正，为例外设置停止点，把缺少的操作信息留给流程负责人回答。

当你熟悉一项日常工作，却需要同事在没有你逐步讲解的情况下接手时，这种做法就有用。清晰的交接不只需要通顺的文字：读者还要能认出正确的记录，知道自己能改什么，并看出何时必须停止。

一条关于轻量流程文档的公开求助询问如何记录任务并维护说明。另一篇厂商社区中的观点帖区分了整理文档与提供实际流程知识。这些只是有限的问题线索，不能说明这种需求有多普遍，也不能证明某个 AI 工具的表现。

下方完整的工作坊案例为原创虚构内容。口述稿、表单、规则和修订均为教学编写；两张可编辑图是示意图，并非产品截图。本文未测试真实流程，未进行第二位读者试用，也未测试 AI SOP 产品。

选择足够完成任务的最简交接形式

如果一份小文档已经覆盖任务，就足够了。本案例采用结构化 SOP，是因为同一条信息有两条确认路径，而且缺少的值在之后的版本中会改变处理方式。它不依赖某个平台或 AI 起草工具。

保留完整口述稿

在判断更正影响了什么之前，不要先把口述者的更正删掉。下面是完整的原创口述稿，保留了自然的自我更正和一个未回答的问题。来源标签用于定位内容，并非录音时间戳。

原创虚构口述稿——Workshop 表单，示例 v1
为教学编写的材料，并非录音或真实操作制度。
S 标签标识同一份完整口述稿中连续的各段内容。

S01: 好，这次只是准备一条工作坊信息，交给内部审阅。你是信息编辑，我是协调人。工作坊负责人通过我来确认这项请求。这个任务不涉及发布信息、预订房间或邀请参与者。
S02: 你需要拥有示例 v1 的 Workshop 表单编辑权限，并能访问请求 W-14。表单中有一个 Day 字段，在这个练习里只表示星期几，并不是日历预订。打开 W-14。如果打不开，或者字段与这个版本不符，就停下来问我，不要自行把这些说明套用到另一张表单上。
S03: 初始状态下，Request 是 W-14，Room 是 Cedar，Capacity 是 4，Requested seats 是 3。Title、Day 和 Start time 都为空。Owner confirmation 是 Unknown，Status 是 Draft。这些就是示意图 A 中的初始值。只要其中任何一项不同，就先不要编辑，停下来问我应该使用哪个版本或哪条请求。
S04: 先比较 Requested seats（申请席位数）和 Capacity（容量）。这里申请 3 个席位，未超过容量 4 个席位，可以继续准备。如果申请席位数超过容量，就让 Status 保持 Draft，找我解决。不要自行改动任何一个数字，也不要换一个房间来凑条件。
S05: 在 Title 中填写 Intro workshop，文字必须完全一致。然后在 Day 中填 Wednesday。等等，不好意思，我说成以前的星期了。W-14 更正后的星期是 Thursday。用 Thursday，不用 Wednesday，并在备注中保留这次更正，让接手的人知道原因。
S06: 不要填写 Start time。我没有提供开始时间，这份口述稿也无法给出正确时间。请问我：“W-14 的 Start time 应该填写什么时间？”在我给出答案之前，让它保持空白。听起来合理的时间不等于答案。
S07: 现在读取 Owner confirmation。对信息编辑来说，这个字段是只读的；只有在工作坊负责人确认后，才由我更新它。不要自己把 Unknown 改成 Confirmed，也不要把输入标题当成负责人已确认。
S08: 如果 Owner confirmation 是 Unknown，就用 Save draft 保留标题和更正后的星期，检查 Status 仍为 Draft、Start time 仍为空，然后结束本轮交接。请我取得负责人确认并更新该字段，同时询问缺少的开始时间。等我更新字段后，重新打开 W-14，对照已保存的草稿，再检查请求身份、房间和容量。保留已经保存的标题和更正后的星期，不要以为它们应该再次变为空白。
S09: 在示例 v1 中，Start time 为空也可以开始内部审阅。但前提是 Owner confirmation 显示 Confirmed，且席位数检查通过；还要告诉审阅者，开始时间尚未解决。Ready for review 不代表已经排期或发布。发布不属于你的职责，也不在本流程范围内，即使后来补齐了时间也是如此。
S10: 所以，如果我更新后，Owner confirmation 变为 Confirmed，请在 W-14 上再读一次这个字段。核对 Title 为 Intro workshop，Day 为 Thursday，Room 为 Cedar，Capacity 为 4，Requested seats 为 3，Start time 为空。选择 Save for review。这个操作会把 Status 设为 Ready for review，不会发布信息。示意图 B 画的是满足条件后保存的目标状态，不是任何人已经实际执行过这些步骤的记录。
S11: 无论用了哪一种保存操作，保存后都要重新打开记录，再核对各项值和 Status。不要以为点了按钮就一定成功。如果保存失败，或者重新打开后值不一致，就停下来，把实际看到的差异告诉我，不要报告交接成功。不要试着换一个状态来绕过问题。
S12: 如果审阅交接成功，请把请求 ID、标题、更正后的星期、房间、申请席位数和容量两个数字、Confirmed 字段值，以及保存后的 Ready for review 状态交给我。加上这句话：“Start time 尚未解决，已留空。请在之后作出任何排期决定前补充。”同时保留从 Wednesday 更正为 Thursday 的记录。我接下来要做的是提供缺少的时间并安排审阅，不是让你发布。
S13: 如果 Owner confirmation 显示的既不是 Unknown，也不是 Confirmed，或者操作过程中其他值发生变化，只有在表单允许、且不会覆盖别人工作的情况下，才保持或退回 Draft；否则就不要改动记录。停下来请我核对解决。不要编出一个新的处理分支，也不要覆盖另一位编辑的修改。

口述者把星期更正为 Thursday。开始时间则不同：它从未被提供。SOP 应采用更正后的星期，同时把未回答的时间保留为问题。旧的 Wednesday 和猜出的“合理时间”都不应填进表单。

对照口述稿理解两张状态示意图

**示意图 A 是初始状态。**它呈现记录及其可见的值。为什么要核对容量、星期如何更正、确认值意味着什么，以及操作人员拥有哪些权限，都来自口述稿。

**示意图 B 是满足条件后的目标状态。**它说明：如果协调人更新了确认，且审阅保存成功，记录应显示什么。把它画出来不代表已经取得确认或已经保存。如果实际字段仍为 Unknown，操作人员应走 Draft 分支。

将这些来源引用与 SOP 放在一起。如果 AI 草稿加上“选择 09:00”或“把负责人标记为已确认”，它就在补入原口述没有提供的知识。删除这种添加，把问题交回协调人。

把完整 SOP 交给同事

下方流程重新组织了已经提供的知识，终点是经核验的审阅交接，或明确暂停。v1 允许时间留空的规则来自 S09，并不是对工作坊系统通常如何运作的猜测。

SOP：准备工作坊请求 W-14，交给内部审阅

**版本：**示例 v1，为教学虚构的版本。**流程负责人：**协调人。**操作人员：**信息编辑。**确认来源：**工作坊负责人，由协调人记录确认结果。**审阅者：**协调人，或由协调人安排审阅信息的人。

**目的与终点：**准备工作坊信息，并以 Ready for review 状态交接，或停在 Draft 状态。房间预订、排期、邀请和发布都不在本流程范围内。本案例唯一尚未给出的值是开始时间。

**开始前：**你需要拥有示例 v1 的 Workshop 表单编辑权限，并能访问请求 W-14。首次操作以示意图 A 的初始值为准。协调人更新确认后再回来时，应使用已保存的草稿，其中可能已经填好了标题和更正后的星期。如果表单改名或发生变化，不要继续套用这个版本的说明。[S01–S03, S08]

操作步骤

例外与停止条件

满足 Confirmed 条件后的审阅交接

只有实际核验了 P6 中的保存状态，才能使用这份交接内容。在本教学案例中，它是一份拟定的交接示例，并非已发送的消息。

W-14 — Intro workshop
Day: Thursday（由之前口述的 Wednesday 更正而来）
Room: Cedar
Requested seats: 3；Capacity: 4
Owner confirmation: Confirmed
Saved status: Ready for review
Start time 尚未解决，已留空。请在之后作出任何排期决定前补充。
仅为内部审阅准备，未执行发布。

若走 E1 分支，应改为报告 Draft 和 Owner confirmation: Unknown，并请协调人取得确认、更新字段及补充开始时间。不要原样套用 Confirmed 分支的交接内容。

**未决事项 U1：**W-14 的 Start time 应填写什么时间？**回答负责人：**协调人。**已提供的答案：**无。**当前处理：**表单留空；无论走哪条交接分支，都明确提出这个问题。[S06, S08–S09, S12]

给起草请求划清范围

附上完整口述稿及两张标好名称的画面参考，再使用类似下面的请求。用于你自己的流程时，应换成操作人员和流程负责人能够核实的材料。分享真实录音或截图前，可能需要先去除私人信息。

请把提供的流程口述稿和画面参考整理成一份 SOP 草稿，供另一位同事照着操作。
只准备文档，不要操作表单、联系任何人、安排日程或发布任何内容。

输入：
- 带来源标签的完整口述稿。
- 示意图 A：初始状态。
- 示意图 B：满足条件后的目标状态，并非流程已执行的证据。
- 口述稿中说明的表单版本和各个角色。

请返回：
1. 目的、操作人员、流程负责人、前置条件和终点。
2. 编号操作步骤，每一步都附预期状态和来源引用。
3. 条件分支、停止点和恢复条件。
4. 未解决的问题，以及应由谁回答、暂时怎样处理。
5. 完整交接示例，区分已准备、已保存、已核验和已发布。
6. 由第二位读者走查的计划，写明预期结果，但将实际观察和结论留空。

准确保留字段名、标题、请求 ID、房间、数字和状态的字面值。
采用口述者后来明确更正的星期；被替换的旧星期只保留在更正备注中。
不要从其他步骤推断已获得确认，也不要编造开始时间。

说明哪些指令来自口述，而非画面中可见的信息。
画面上的一个值本身不能确立业务规则。
如果某个步骤需要输入材料未提供的知识，请标明缺口并向流程负责人提问。
不要添加听起来合理的操作规则。

输出应对应所提供的表单版本。
标签或规则变化时，标明需要修订，不要默默地把旧流程套用过去。

请第二位读者走查草稿

把 v1 口述稿、示意图 A、示意图 B、SOP 和一份空白观察记录交给同事，请他们根据提供的状态，说出或模拟下一步。他们应能指出对应字段、说清条件并识别停止点，而无需原口述者临时补充规则。

若要用于真实流程，应先与流程负责人安排合适的练习环境。这里的静态示意图不能证明实际访问权限、保存是否持久、错误行为，或真实界面是否按这种方式工作。

下表是拟议的检查案例。预期结果来自已编写的材料。**尚未有第二位读者执行这些检查；所有实际结果栏均有意留空。**空白不代表通过。

记录具体哪条指令让人困惑，或哪项假设缺少依据，不要只写“不清楚”。流程负责人提供操作层面的答案，文档作者再修改受影响的步骤及其来源映射。只有之后填写完成的观察记录，才能说明第二位读者实际上能跟着完成哪些内容。

表单或规则变化时，修订操作说明

假设协调人提供了下面这份虚构的示例 v2 变更说明。这些版本标签仅用于教学，并非真实发布版本或发布日期：

R01: Owner confirmation 改名为 Owner approval。对信息编辑仍是只读字段。
Unknown 仍表示停在 Draft。
R02: Save for review 被 Send to review 替代。现在要求已经提供 Start time、
确认值为 Confirmed，并且容量检查通过。
Start time 为空就必须停在 Draft。
R03: W-14、Intro workshop、Thursday、Cedar、Capacity 4 和 Requested seats 3
均未改变。协调人仍未提供开始时间。
R04: Save draft 仍然可用。重新打开并核验草稿，再向协调人询问缺少的时间，
如有需要，也询问负责人确认。不要使用旧的审阅操作。
发布仍不在本任务范围内。

这份新来源同时改变了规则和标签。若只把旧 SOP 中的按钮名称换掉，P5 中仍会留下错误指令。

要一起更新 P1 的版本检查、P4–P7、E1 的恢复条件和 U1 的处理方式。示意图 B 是 v1 的目标状态；对于这条信息尚不完整的记录，它已不再是 v2 允许的状态。将它从 v2 流程中停用，并在交接修订版前取得对应版本的新参考。只改图注会掩盖新增的前置条件。

将 v1 与它的原始口述稿一起保留，便于说明旧指令的依据。请流程负责人确认新规则，再安排一次第二位读者的走查。上面的片段是为教学编写的修订示例；两个版本都未用于操作真实表单。

当每项操作都有来源、读者能识别当前版本，而且未解决的信息仍有明确负责人时，就可以把这份交接文档交给另一位读者尝试。将原始口述稿与流程说明一起保留，流程发生更正时，文档中的对应内容才能具体地更新。