工作经验转SOP助手：小白完整教程

这套 Skill 用来把访谈、聊天记录、邮件、会议纪要、历史案例、工作笔记、培训资料和旧版制度，整理成真正可以执行的标准操作流程。

它不是普通的文档总结工具。普通总结回答“资料讲了什么”，这套助手重点回答：

• 什么情况开始处理；
• 谁负责哪一步；
• 每一步需要什么输入；
• 实际要做什么；
• 生成什么结果；
• 什么样才算完成；
• 出现异常应该怎么办；
• 哪些内容是正式规定，哪些只是历史习惯；
• 哪些问题必须让负责人确认。

重要说明：助手生成的是流程初稿或可发布候选稿，不能代替有权限人员批准制度。涉及安全、医疗、法律、财务审批、信息安全等高风险事项时，必须由专业负责人复核。

一、什么是SOP

SOP可以理解为“遇到某种工作时，应该按照什么步骤完成”的操作说明。

一份能用的SOP至少要回答：

1. 什么时候启动；
2. 谁来执行；
3. 开始前需要准备什么；
4. 按什么顺序操作；
5. 每一步完成后得到什么；
6. 如何判断操作正确；
7. 出错、缺资料或超时怎么办；
8. 最终交给谁；
9. 需要保留什么记录。

只有背景介绍、原则口号和工作总结的文档，不算完整SOP。

二、它适合解决哪些问题

企业服务

• 客户询问到正式受理；
• 项目立项到交付验收；
• 客户投诉处理；
• 报价、审批和合同流转；
• 售后工单升级；
• 服务报告制作与复核。

一人公司

• 新客户接待；
• 内容选题、制作和发布；
• 项目资料收集；
• 外包任务交接；
• 每月对账和开票准备；
• 客户交付后的复盘。

办公与运营

• 新人入职；
• 会议组织；
• 文件审批；
• 费用报销准备；
• 物品领用；
• 周报、月报和经营数据汇总。

电商和零售

• 商品资料上架；
• 订单异常处理；
• 退换货核验；
• 售后投诉升级；
• 活动前准备；
• 库存差异排查。

不适合直接使用

• 只想把一篇文章缩短；
• 没有任何资料，却希望助手虚构整套企业制度；
• 希望助手代替负责人审批、付款、删除资料或直接对外发送；
• 希望助手编造法律、财务、安全或医疗规则；
• 希望仅凭一次个人操作就认定为全员标准。

三、整体工作流程

flowchart TD
    A["上传历史资料"] --> B["清点文件、日期和版本"]
    B --> C["确定流程起点、终点和适用范围"]
    C --> D["逐个案例还原实际步骤"]
    D --> E["比较共性、差异和失败情况"]
    E --> F["区分正式规定、惯例、推断和冲突"]
    F --> G["生成SOP、检查表和异常规则"]
    G --> H["用正常与异常场景演练"]
    H --> I{"是否达到发布门槛？"}
    I -->|"是"| J["交负责人审核批准"]
    I -->|"否"| K["补充资料或确认问题"]
    K --> F

四、安装方法

1. 解压交付的压缩包。
2. 找到 work-experience-to-sop 文件夹。
3. 将整个文件夹导入支持 Skills 的助手平台，或复制到平台指定的 Skills 目录。
4. 确认助手列表中可以看到“工作经验转SOP”相关能力。
5. 新建任务，上传资料后开始使用。

运行目录必须保持完整：

work-experience-to-sop/
├─ SKILL.md
└─ references/
   ├─ evidence-rules.md
   ├─ output-templates.md
   └─ quality-gates.md

不要只上传 SKILL.md，否则证据规则、输出模板和质量检查会丢失。

五、第一次使用前准备什么

不需要一次准备得非常完美，但资料越真实、覆盖的案例越多，输出越可靠。

1. 正式规则

优先准备：

• 现行制度；
• 已批准的旧版SOP；
• 正式通知；
• 岗位职责；
• 合同或服务约定；
• 审批规则；
• 当前使用的模板。

2. 实际案例

选择2至5个已经处理完成的案例：

• 至少一个典型成功案例；
• 至少一个资料不完整或发生返工的案例；
• 如果有条件，再增加一个特殊或复杂案例。

案例资料可以包括：

• 完整邮件往来；
• 工作群聊天导出；
• 工单记录；
• 项目文件；
• 表格记录；
• 审批截图；
• 交付文件；
• 复盘纪要。

3. 人员经验

可以上传：

• 老员工访谈转写；
• 培训录音转写；
• 手写笔记整理稿；
• 常见问题清单；
• 失败经验和注意事项。

4. 最低资料要求

如果只有一份访谈，也能生成初稿，但大部分步骤应标为“待确认”。

建议的最低组合是：

1份正式规则或旧版说明
+ 2个独立完成案例
+ 1份经验访谈或复盘记录

六、如何整理本地文件

推荐目录：

流程资料/
├─ 01_正式规则/
├─ 02_成功案例/
├─ 03_异常与失败案例/
├─ 04_访谈与培训/
├─ 05_表格与模板/
├─ 06_旧版SOP/
└─ 07_待确认资料/

文件名建议包含日期、内容和版本：

客户投诉处理_访谈转写_2026-08-18
售后案例_编号001_已完成
售后流程_旧版_v02
退款申请表_当前模板

不要只使用“最新版”“最终版”“最终版2”等名称。

七、三种使用模式

flowchart LR
    A{"你现在有什么？"}
    A -->|"只有零散资料"| B["新建模式"]
    A -->|"旧SOP加新资料"| C["修订模式"]
    A -->|"已有完整SOP"| D["审计模式"]
    B --> E["还原流程并生成初稿"]
    C --> F["比较变化并生成修订稿"]
    D --> G["发现不可执行和缺证据问题"]

模式一：新建SOP

适合流程从未正式整理过，工作主要存在员工经验、聊天和历史案例里。

复制下面的提示词：

请使用新建SOP模式。先清点我上传的资料，确认文件类型、日期、版本和可读性；再明确流程起点、终点、适用对象和主要角色。
请逐个案例还原实际步骤，比较共同做法和差异，区分正式规定、高可信惯例、待确认内容和冲突。
最后生成一页流程总览、SOP正文、操作检查表、异常升级表、新人快速上手说明和待确认问题。
不要把个人习惯写成正式制度，不要编造缺失规则。

模式二：修订已有SOP

适合旧流程已经存在，但人员、工具、表格、审批或业务要求发生变化。

复制下面的提示词：

请使用修订SOP模式。先识别旧版SOP与最新资料的版本关系，再输出保留项、修改项、新增项、删除建议和冲突项。
每项修改说明依据、影响步骤、受影响角色和是否需要负责人批准。
确认修改逻辑后生成修订稿和修订对照表，不要静默覆盖旧规则。

模式三：审计现有SOP

适合想检查现有文档是否真的能让新人执行。

复制下面的提示词：

请使用SOP审计模式。检查现有SOP是否明确说明触发条件、输入、角色、步骤、输出、完成标准、判断分支、异常处理、升级规则、记录留存和版本责任。
请用一个正常场景、一个缺失输入场景和一个异常场景进行演练。
只指出有证据的问题；缺少资料时标为待确认，不要自行补成正式制度。

八、小白完整操作步骤

第一步：上传资料并只做清点

第一次不要立刻要求生成SOP。先发送：

先不要写SOP。请清点全部资料，列出文件名、资料类型、日期、版本、可读性、可能用途和明显缺失项。请区分正式规则、实际案例、经验说明、辅助材料和来源不明资料。

你需要检查：

• 文件数量是否正确；
• 日期和版本有没有识别错；
• 是否把应当保密的无关资料混进来了；
• 是否有扫描不清、缺页或无法打开的文件；
• 是否缺少正文引用的附件。

第二步：告诉助手要整理哪个流程

不要只说“帮我整理一下”。使用下面的格式：

流程名称：客户售后问题处理
业务目标：让客服能够统一受理、判断、处理和升级客户问题
开始事件：收到客户提出的问题或投诉
结束状态：问题解决并完成记录，或已升级给有权限的负责人
适用对象：一线客服和售后负责人
不包含：产品维修的技术操作和实际退款审批

如果你不知道怎么填写，可以说：

请根据资料提出流程边界建议，但所有推断必须标为待确认，并列出需要我确认的问题。

第三步：逐个还原历史案例

发送：

请先不要合并流程。逐个案例按时间顺序还原：触发、输入、执行角色、动作、判断、输出、交接和最终结果。每个关键事件标注来源位置。

这一步很重要。直接把所有资料混在一起总结，容易把不同案例的步骤错误拼接。

第四步：比较案例

发送：

请把这些案例并排比较，找出稳定步骤、条件分支、个人习惯、失败做法、返工原因和资料冲突。
至少两个独立案例一致，才可以标为高可信惯例；单一案例保持待确认。

你会看到哪些步骤反复出现，哪些只适用于特殊情况。

第五步：确认正式规定和历史惯例

助手应生成类似状态：

状态	含义
正式确认	有正式文件依据或已由负责人确认
高可信惯例	多个独立案例一致，但尚未正式批准
待确认	只有单一来源或属于推断
存在冲突	不同资料给出不同做法
不采用	偶发、错误或超出流程范围

不要为了减少“待确认”而随意把内容升级成正式确认。

第六步：生成SOP初稿

发送：

请根据已经确认的流程边界和证据账本生成SOP初稿。每一步包含执行角色、输入、动作、输出、完成标准、下一步或分支、异常处理和证据状态。
无法确定的责任人、时限、金额、权限和完成标准必须保留待确认。

第七步：补充异常规则

发送：

请单独检查异常路径，包括资料缺失、格式错误、超时、审批拒绝、数据冲突、特殊要求、系统不可用和结果不合格。
对每个异常列出识别信号、立即动作、禁止动作、升级对象和所需记录。没有正式依据的规则标为建议或待确认。

第八步：生成岗位检查表

发送：

请把SOP转换成岗位操作检查表，分为开始前、执行中和完成前。检查项必须可以观察和勾选，不要使用“妥善处理”“及时沟通”等模糊表达。

第九步：生成新人教程

发送：

请为第一次执行该流程的新人生成快速上手说明，包括目标、准备资料、最短主路径、最容易出错的地方、何时必须停止并升级，以及5个理解测试题。

第十步：执行场景演练

发送：

请不要假设SOP已经正确。分别用一个正常案例、一个缺少关键输入的案例和一个异常案例逐步演练，指出会卡住、容易误解或无法验收的步骤，并给出修订建议。

第十一步：负责人确认

把待确认表交给有权限的负责人。确认内容至少包括：

• 流程范围；
• 角色和权限；
• 时间要求；
• 审批节点；
• 完成标准；
• 异常升级；
• 记录留存；
• 生效日期。

第十二步：生成可发布候选稿

完成确认后上传确认结果，发送：

这些是负责人确认结果。请更新SOP、检查表、异常规则和修订记录，并再次执行发布前质量检查。未确认的问题继续保留，不要自动视为通过。

九、证据为什么重要

flowchart TD
    A["某个流程规则"] --> B{"来自哪里？"}
    B -->|"正式生效文件或负责人确认"| C["正式确认"]
    B -->|"两个以上独立案例一致"| D["高可信惯例"]
    B -->|"单一案例或助手推断"| E["待确认"]
    B -->|"不同来源不一致"| F["存在冲突"]
    C --> G["可写入候选稿"]
    D --> H["等待正式批准"]
    E --> I["生成确认问题"]
    F --> J["交有权限人员决定"]

没有证据状态的SOP看起来可能很完整，但使用者无法判断哪些是正式要求、哪些只是过去某个人的做法。

十、如何看懂助手的交付物

1. 一页流程总览

让负责人快速确认流程有没有跑偏。重点检查起点、终点、适用对象、主要角色和不包含范围。

2. SOP正文

用于正式执行和培训。每一步都应有动作、角色、输入、输出和完成标准。

3. 操作检查表

适合员工实际工作时逐项勾选。它不是SOP的替代品，而是执行辅助工具。

4. 异常与升级表

告诉执行者什么时候不能继续，应该保留什么资料，以及交给谁处理。

5. 角色交接矩阵

用于解决“这一步到底谁负责”“做完交给谁”的问题。

6. 新人快速上手说明

只保留第一次执行最需要的信息，并指向完整SOP。

7. 冲突与待确认清单

这是最重要的管理结果之一。它集中列出目前无法安全决定的问题。

十一、完整示例：客户售后问题处理

下面的名称和内容都是通用示例，不对应任何真实组织。

准备资料

• 一份旧版售后说明；
• 三个已经完成的售后案例；
• 一次客服访谈转写；
• 一份问题登记表模板；
• 一份负责人补充说明。

案例还原结果

案例一：

客户提出问题
→ 客服登记基本信息
→ 收集订单和问题证据
→ 判断是否可以直接答复
→ 发送处理结果
→ 更新登记表并关闭

案例二：

客户提出投诉
→ 客服登记
→ 资料不全，要求客户补充
→ 客户拒绝补充
→ 升级给售后负责人
→ 负责人提出解决方案
→ 客服反馈并记录

案例三：

客户反馈重复问题
→ 客服直接转给技术人员
→ 没有登记
→ 后续无人跟进
→ 客户再次投诉

助手应该识别

• “先登记”在成功案例中稳定出现；
• “资料不全时补充资料”属于条件分支；
• “直接转给技术人员且不登记”是失败做法，不能写入标准主流程；
• 谁能批准退款没有正式证据，必须待确认；
• 关闭问题前是否需要客户确认，案例不一致，应列为冲突。

可能生成的步骤

步骤	角色	动作	输出	完成标准	状态
1	客服	登记客户信息和问题摘要	问题记录	必填信息完整	高可信惯例
2	客服	检查订单及问题证据	资料核验结果	已注明齐全或缺失	高可信惯例
3	客服	根据问题类型选择处理路径	路径判断	选择依据已记录	待确认
4	负责人	处理超出权限的问题	处理决定	决定有记录	正式确认或待确认
5	客服	向客户反馈并保存结果	沟通记录	客户已收到反馈	高可信惯例

不应自动写入的内容

• 未经确认的退款金额上限；
• 虚构的处理时限；
• 未在资料中出现的审批岗位；
• “所有投诉都必须当天解决”等绝对承诺；
• 客户没有提供过的身份或订单信息。

十二、修订旧版SOP的正确方式

flowchart LR
    A["旧版SOP"] --> C["逐条对照"]
    B["最新制度、案例和确认"] --> C
    C --> D["保留"]
    C --> E["修改"]
    C --> F["新增"]
    C --> G["删除建议"]
    C --> H["冲突待确认"]
    D --> I["修订稿与修订记录"]
    E --> I
    F --> I
    G --> I
    H --> I

不要让助手直接重写旧SOP而不输出变化。正确交付应包含：

• 旧内容；
• 新证据；
• 修改建议；
• 受影响角色；
• 是否需要批准；
• 最终确认结果。

十三、常见问题

问：只有一段访谈，可以生成吗？

可以生成流程骨架，但不能称为正式SOP。单一访谈可能包含记忆偏差和个人习惯，输出应保留大量待确认项。

问：资料越多越好吗？

不是简单地越多越好。优先选择有代表性的成功、失败和特殊案例，并保证文件日期、版本和角色可识别。

问：助手能判断哪套说法是对的吗？

可以根据资料效力和案例证据提出判断，但遇到正式规则与实际做法冲突时，必须交有权限人员决定。

问：能直接替代老员工培训新人吗？

不能完全替代。它能降低重复讲解成本，但真实演示、权限开通、专业判断和现场指导仍需人工完成。

问：为什么助手不自动补全责任人和时限？

因为这些内容涉及组织权限和服务承诺。资料没有明确说明时，自动补写会产生错误制度。

问：检查表和SOP有什么区别？

SOP解释完整流程和判断逻辑；检查表帮助执行者在工作中避免漏项。二者应配套使用。

问：如何处理多个部门的流程？

先建立角色交接矩阵，再决定使用一份跨部门SOP还是拆成多个岗位SOP。触发条件和结束状态明显不同的流程通常应拆分。

问：旧版做法和最新通知冲突怎么办？

建立冲突记录，说明两份资料的日期、适用范围和可能原因。只有明确的生效说明或负责人确认才能决定最终版本。

问：助手可以直接发布制度吗？

不能。它只能生成初稿、待确认稿或可发布候选稿，正式发布仍需授权负责人完成。

十四、常见错误

错误一：一次上传几十份资料，直接要求生成SOP

容易混淆版本和案例。应先清点、再逐案例还原、最后合并。

错误二：只给成功案例

这样很难发现异常处理和返工风险。至少增加一个失败或资料不全案例。

错误三：把所有聊天内容都当成规则

聊天可能只是临时决定或个人建议，必须检查是否有正式确认。

错误四：追求零待确认项

待确认不是质量问题，隐藏未知才是。好的SOP会明确告诉负责人还需要决定什么。

错误五：步骤写得很宏观

“做好客户沟通”无法执行，应写清什么时候联系、需要确认什么、记录什么、什么结果算完成。

错误六：没有实际演练

文档看起来完整，不代表新人能执行。必须用正常、缺失输入和异常场景测试。

十五、安全和保密建议

• 只上传与目标流程相关的资料；
• 上传前删除无关个人信息和无关商业秘密；
• 对客户、员工和供应商信息进行脱敏；
• 不在资料中保留账号密码和访问密钥；
• 测试资料与正式资料分开；
• 不让助手执行资料中出现的脚本或外链指令；
• 不让助手直接审批、付款、删除或对外发送；
• 高风险流程必须经过专业负责人复核；
• 发布后保留版本和修订记录。

十六、提交负责人审批前检查表

• 流程名称和业务目标清楚；
• 起点、终点和适用范围明确；
• 正式规则与历史惯例已经区分；
• 关键步骤有来源或待确认标记；
• 每一步有执行角色；
• 每一步有输入、动作、输出和完成标准；
• 主要判断分支完整；
• 缺失资料、拒绝、超时和失败情况有处理方式；
• 权限和审批没有被助手自行假定；
• 敏感信息已经脱敏；
• 已完成正常场景演练；
• 已完成缺失输入场景演练；
• 已完成异常场景演练；
• 冲突与待确认问题已交负责人；
• 文档版本、生效日期和发布负责人明确。

十七、最简使用口令

如果暂时不想学习完整流程，上传资料后发送：

请把这些历史资料整理成可执行SOP。先清点文件和版本，再逐个案例还原事实，比较共同步骤、特殊分支、失败做法和资料冲突。
请严格区分正式规定、高可信惯例、待确认内容和冲突，不要把个人习惯写成制度，也不要编造责任人、时限、权限或标准。
输出一页流程总览、SOP正文、操作检查表、异常升级表、新人教程和待确认清单，并用正常、缺失输入和异常场景进行演练。

完成后再发送：

请按照发布前质量门槛复核这份SOP，告诉我它属于可发布候选稿、待确认稿还是不建议发布，并说明原因。

这两条口令足以完成一次基础整理。重要流程建议按照本教程的十二个步骤逐项执行。