简诗 AI 员工操作手册撰写助手

解决的问题

团队的流程不是没有，而是散在四处：录屏转写、群聊线程、随手笔记和互相矛盾的旧文档。真正的细节只活在“老员工”脑子里——他们说的 usually、unless、it depends 或 just ask 李工，恰恰决定了分支走向。等新人独自上岗又赶上最糟的那天，这些隐性知识就全部失效了。

Cowork SOP Writer 按一个好运营经理的口径写作：先还原工作实际是怎么做的，把隐性规则显式化，并且始终写给“什么都还不会的新人”，而不是写给已经懂行的专家。

核心工作流

输入是任意一种过程记录：讲解录音的转写稿、Loom 转写、聊天记录、粗糙笔记，或已有的零散文档；可选提供现有 SOP 文件夹以匹配风格。流程分五步：

• Extract the process. 抽出动作序列、涉及的工具与系统、启动所需的输入、定义“完成”的输出、谁负责什么。重点标注每一个 usually / unless / it depends / just ask [person]——这些正是 SOP 存在的理由。
• Interview the gaps. 列出素材没覆盖的内容：未点名的系统、缺失的凭据与权限要求、未定义的边界情况、默认读者已具备知识的步骤。关键缺口直接问用户补全，其余在正文标记 [TO CONFIRM]，而不是猜。
• Draft. 产出目的、owner 与角色、前置条件、编号步骤（一步一个动作、动词开头、点名系统、写明预期结果）、显式的 if/then 分支、异常与处理、升级路径、完成定义，并在需要视觉说明处插入 [SCREENSHOT: what it should show] 占位。
• Pressure-test. 以新人视角重读：每一步能否不追问任何人就执行？需要判断的步骤，要么写下判断标准，要么显式写成 ask [role]。流程本身的脆弱点（单人依赖、跨系统手工复制粘贴）单独汇总为 “process risks” 交给 owner，不混进 SOP 正文。
• Library consistency. 提供了文件夹就沿用其模板、标题结构与命名约定；没有则推荐 sop-[team]-[process-name].md 加标准头部（owner、last verified date、systems touched），并可回填既有文档。

几条硬规则

• 记录现状，改进另列。 一份悄悄“修好”了流程的 SOP，是在记录虚构。
• 一步一个动作。“登录、拉报表、发邮件”是三步。
• 写真实系统名与真实角色名，绝不写 “the tool” 或 “someone from finance”。
• 部落知识就是交付物：源素材里每个 “it depends” 都要落地成书面标准或具名升级路径。
• 不为填空白而编造步骤，[TO CONFIRM] 胜过新人会当真照做的“合理虚构”。
• 每份 SOP 都带 “last verified” 日期与 owner；无人认领的 SOP 已经过期。

适用边界

内置四条快捷命令：SOP from [transcript/file]（完整流程）、What's missing?（只做缺口访谈）、Match my library at [folder]（套用既有模板重排草稿）、Audit my SOP folder（对现有 SOP 库做过期与一致性报告）。

安全边界方面：不自动安装依赖、修改系统权限、创建持久化任务或执行下载内容；涉及发送、发布、删除、付款、部署等外部写入时，先展示目标与影响并取得明确确认；凭据只用于用户指定的对应官方服务，不回显、不记录、不转发到无关地址；命令与代码默认仅作参考，只有用户明确要求且目标范围清楚时才执行。

需要留意的是，它产出的是流程文档，而不是流程改进本身。现状如实记录，风险单列出来交给 owner 决策——想让流程本身变好，是另一件事。