AI 写 SOP 的常见问题：步骤粒度怎么定

新同事做到第三步，抬头问了一句：「这个按钮在哪个页面？」——这句话基本宣告了这份 SOP 的失败。用 AI 起草的流程文档尤其容易出这种情况：句子通顺、层级清楚，但某一步把「核对信息」和「提交审批」压成了一行，执行的人只能停下来问。粒度有个可验证的线，也有固定的拆法；下面把这条线、拆解的五步，以及模型最容易帮倒忙的地方讲清楚。

一条线就能判断粒度：换个人能不能照着做完

标准只有一句话：一个刚入职、懂业务但不懂系统的人，照着这份文档能不能独立做完，中途不用问人。他会卡住，说明某一步太粗；他自己都觉得啰嗦，说明某一步太细。

这条线之所以管用，是因为它把「写得清不清楚」换成了「执行者会不会停下来」。停下来只有两种原因：信息不够，不知道该点哪里、该填什么值；或者判断权没交代，遇到例外不知道找谁。前者是粒度问题，后者是分支缺失，两种病要分开治。

先钉死执行人和触发条件，粒度才有参照

同一段流程，写给熟手和写给新人，篇幅能差三倍。熟手不需要「打开哪个系统」，新人需要。所以动笔前先写两行：谁执行（岗位、权限级别），什么时候开始（什么事件触发这份文档）。这两行不写，后面所有步骤都没有参照系，模型也会按「一个什么都懂的员工」来写，产出看着完整，实际处处跳步。

触发条件还要带上「不适用」的部分：金额超过多少要升级、跨部门的单子走另一份流程、系统维护窗口内改走线下。这些常被省略，因为写的人觉得大家都知道，而新人恰恰不知道。

五步拆完，每一步都留一件能验收的东西

拆解不是一次成型的，它分五步，每步产出不一样，缺一步后面就会空转：

第三步到第四步的跨度最大：主干写完，人会有「差不多成了」的错觉，而分支才是执行时真正用得上的部分。判断一份 SOP 成熟没成熟，看它有多少行是以「如果」开头的。

「注意核对」是原则，写成步骤才算数

原则描述态度，步骤描述动作。「注意核对信息」这句话，执行者无法判断做到什么程度算核对过；「把订单号与系统记录逐位比对，不一致就截图留存，并在备注里写清差异位」才是步骤。原则可以放在文档开头当背景，但不能占着步骤的位置。

同类说法还有「及时反馈」「确保准确」「按规范操作」。这些话在评审会上没人反对，落地时一句都用不上。改写方法只有一个：问「做到什么程度算完成」，答案就是步骤。

分支写不全，文档就只在顺利的时候有用

真实执行里卡住人的往往不是主干，是主干之外的岔路：审批被驳回要不要重新提交、系统提示单据已锁定怎么办、客户给的信息和系统记录不一致听谁的。这些情况占比不高，但每一次都要人去问，问一次就说明这份文档还没写完。

写分支有个省力的办法：让执行过的人回忆最近十次「做不下去」的时刻，一次记一条，凑成一张表。这比凭空设想异常情况可靠得多，也比让模型猜更接近现场。把拆解要求写进提示词时，可以明确要求它先列出所有可能的岔路，再由你删掉不符合实际的。

模型会替你补上它并不知道的系统细节

让它拆步骤，它会写出「登录业务系统，进入订单管理模块，点击导出」这种句子。听着像真的，实际系统里可能叫「单据中心」，也可能根本没有导出按钮。它没见过你们的界面，也没有权限表，只能按训练数据里见过的后台形态生成一个合理的版本。这类看起来完全合理的虚构在流程文档里格外危险，因为读的人会以为写的人核过。

可控的做法是把约束写死：只使用我提供的系统名、菜单名和角色名，缺信息的地方写成【待确认】并单列一张待补清单。产出的是一份带空洞的草稿，空洞比编造好补。流程很长时还要分段喂，一次塞进几十个步骤，前面定的规则到后面会被它忘掉，上下文能装多少内容决定了你该按章节给还是一次性全给。

写完之后，用一个人的卡点来验收

文档写完不算完。找一位没做过这件事的同事照着走一遍，你只记录、不解释。他在哪一步停了超过十秒、问了什么、翻了几次别的文档，这些就是需要改的地方。三轮试读之后还剩下的问题，通常已经不是粒度问题，而是流程本身设计得不合理——那要改流程，改文档解决不了。

如果这份 SOP 之后要交给智能体执行，粒度还得再细一档：人能从「处理异常」四个字里推断出做法，按步骤调工具的智能体不会，它只照字面执行，遇到没写的分支就停下或者乱走。

速查：粒度自检四条

• 换一个没做过的人，能不能不问人做完
• 每步都有输入和输出，做完能确认状态
• 驳回、超时、数据不符三类岔路都写了怎么办
• 「注意」「确保」「及时」这类词都换成了具体动作