要让Claude编写标准操作流程,请按照你实际的做法逐步描述这个流程,包括涉及的工具、系统和确切名称,并要求Claude将其格式化为带有清晰起点和终点的编号步骤。指出任何例外情况、常见错误,或下一步取决于某个条件的决策点,并要求Claude标记出任何因你没有说明而需要猜测细节的步骤。在把它当作最终版本之前,先对照真实流程通读一次草稿,最好是在实际执行任务的同时进行。
发布于
免费课时 · 无需注册账号认识 Claude为什么是 Claude？6分钟开始免费课时要点总结
- 具体描述流程的实际做法,而不是精简的摘要版本。你因为对自己来说是自动的而跳过的步骤,恰恰是新员工需要书面记录下来的步骤。
- 给Claude真实的名称:具体的工具、准确的字段、要登录的系统。一个说"更新系统"的步骤对于还不知道是哪个系统的人来说毫无用处。
- 明确指出决策点。一个有分支的流程,"如果请求金额低于500美元,做X;否则,做Y",需要把这个分支明确说出来,而不是仅靠只有你才有的背景来暗示。
- 要求一个清晰的起点和终点。一份没有说明任务何时开始、何时真正结束的标准操作流程,会让读者猜测自己是否完成了。
- 在发布之前,边执行任务边通读一次草稿。一份在屏幕上看起来不错但跳过了某个步骤的标准操作流程,只有当有人真正按顺序尝试遵循它时才会变得明显。
- 把正常情况和例外情况分开。把例外情况埋在主要步骤中间,会让人在例外不适用的百分之九十的时间里更难跟上通常的情况。
复制即用
今天就能用的提示词
从流程演示中获得第一份草稿
我将逐步描述我如何完成[任务],包括涉及的确切工具和系统。[尽可能详细地演示这个流程,包括工具名称、字段名称,以及你在过程中检查的一切]。把这个变成一份编号的标准操作流程,有清晰的起点和任务完成的清晰终点。标记出任何因我没有说明而你需要猜测细节的步骤。
按照你实际的做法描述这个流程,包括那些你通常不会大声说出来的小的习惯性检查;这些往往是新员工缺失的步骤。
添加一个步骤依赖的决策点
这是我的标准操作流程草稿:[粘贴你的草稿]。第4步实际上根据一个条件分支:如果[条件],下一步是[X];否则是[Y]。重写第4步以清楚说明这个分支,这样遵循该流程的人在继续之前就能知道哪条路径适用于他们。
对真实流程中的每一个分支都这样做;把决策点隐藏在单一步骤中的标准操作流程,是人们走错路最常见的原因。
把正常情况和例外情况分开
这是我为[任务]写的标准操作流程草稿:[粘贴你的草稿]。把所有只适用于异常情况的内容,比如[描述例外情况],抽出来放到最后一个单独的"例外情况"部分,这样主要的编号步骤就只描述正常情况。在主要步骤中保留一个简短的指引,说明如果当前情况不符合正常模式该去哪里查看。
这样可以让通常的路径容易遵循,而不是强迫每个读者都要在只适用于一小部分情况的例外情况中费力摸索。
对标准操作流程进行压力测试以找出漏洞
请像你从未做过这项任务、第一次按照它去做那样,阅读这份标准操作流程草稿:[粘贴你的草稿]。在每一步,告诉我任何你需要知道但没有说明的内容、任何未定义的术语,或者任何你在进入下一步之前会不确定自己是否正确完成了该步骤的地方。
这能揭示出因为你已经了解这个流程而对你来说看不见的漏洞;全新的视角能捕捉到熟悉感所掩盖的东西。
在流程变化后调整标准操作流程
这是我们现有的[任务]标准操作流程:[粘贴当前的标准操作流程]。流程发生了变化:[描述现在有什么不同]。更新这份标准操作流程以反映新流程,并准确指出哪些步骤发生了变化,以便团队能看出和他们已经熟悉的版本有什么不同。
指出发生了什么变化,而不是悄悄替换掉旧步骤,能帮助那些记住了之前版本的人注意到实际有什么不同。
结构
一份可遵循的标准操作流程真正需要什么
正是这些部分,让不熟悉某项任务的人能在第一次尝试时就正确完成它。
清晰的起点和终点
准确说明任务何时开始,以及它真正完成时是什么样子。一份没有明确终点的标准操作流程,会让读者猜测自己是完成了还是漏掉了一步。
为真实的工具使用真实的名称
使用你团队实际使用的系统、字段和工具的真实名称,而不是泛泛的描述。"打开请求"只有在读者已经知道请求在哪里时才有用;要说明具体系统。
明确说明决策点
如果流程根据某个条件分支,就直接在该步骤中说明,而不是让它隐含在上下文中。隐藏的分支是人们走错路最常见的原因。
把例外情况与主要步骤分开
让正常路径保持简短清晰,把例外情况移到它自己的部分。把例外情况埋在主要步骤中的标准操作流程,会让通常的情况更难跟上。
你跳过的那些步骤
为什么你会用一句话描述的流程不是该给Claude的流程
如果有人问你为这项任务做了什么,你大概会用一两句话概括:"我检查请求,核实账户,然后处理退款。"这个概括是准确的,但它也遗漏了新员工实际需要的几乎所有东西,因为你自动完成的那些小检查、你瞥一眼的具体字段、你在继续之前总会确认的事情,由于反复做而对你来说变得不可见了。对于第一次做这项任务的人来说,它们并不是不可见的。
正是这个漏洞让第一份标准操作流程草稿即使在技术上是正确的,也显得很薄弱。Claude只能写下你告诉它的内容,如果你描述的是流程的精简摘要版本,你得到的就是一份格式化为编号步骤的精简摘要,而不是一份不熟悉这项工作的人能够遵循的真正流程。解决办法是像引导站在你身边的新员工那样叙述这个流程,包括那些感觉太显而易见以至于不值得提及的部分。
有一个有用的技巧可以揭示那些看不见的步骤,那就是真正执行一次任务,同时大声叙述它,或者在提示中尽可能接近这种做法,而不是事后从记忆中概括它。那些习惯性的检查,在你走过这个实时流程时往往会自然地浮现出来;而当你事后从记忆中回想时,它们往往会消失,因为记忆保留了概括,却丢掉了让那个概括成立的那些小动作。
常见错误
是什么让标准操作流程在第一次真正被使用时失败
正是这些漏洞,把一份看起来合理的文档变成了经不起真实、不熟悉用户考验的文档。
模糊的工具指代而非真实名称
"在系统里记录更新"对于还不知道是哪个系统、哪个界面、哪个字段的人来说毫无意义。每次都要说明具体的工具。
隐藏的决策埋在一个步骤里
如果某个步骤秘密地依赖于一个未说明的条件,读者就无法知道哪条路径适用于他们的情况,直到已经太晚而难以轻易改道。
没有说明任务的终点
如果标准操作流程没有说明"完成"是什么样子,读者就只能猜测应该继续下去,还是漏掉了最后写下的步骤之后应该有的一步。
例外情况与主要步骤混在一起
放在正常步骤中间的例外情况,会迫使每一个读者,包括处于正常情况的那些人,在继续之前先弄清楚它是否适用。
把相关材料放在一起
为什么标准操作流程应该和相关文档放在一起
标准操作流程很少单独存在。它通常会引用一份必须遵守的政策、一份它所取代的旧版本,或是一份针对不同但相关任务的相关流程,在起草过程中把这些文档放在一起,比孤立地写标准操作流程然后指望它和其他一切保持一致,结果会更一致。Claude的项目功能让你可以把一组相关文件放在一个地方,这样关于标准操作流程的每次对话都可以引用同样的背景材料,而不需要你每次都重新粘贴,这一点在support.claude.com的项目帮助页面上有记录。
当标准操作流程需要与一份独立于流程本身而变化的政策文档保持一致时,这一点最为重要。如果政策设定了一个阈值,比如决定哪条审批路径适用的金额,把政策和标准操作流程放在同一个项目里,就意味着将来对其中一个的更新更容易对照另一个来检查,而不是几个月后才发现流程和它本应实现的政策已经悄悄脱节了。
当团队为同一任务的不同变体维护多份相关标准操作流程时,这也很有帮助,比如一份针对标准请求的流程和另一份针对加急请求的流程。同时看到两者,更容易让共享的步骤表述保持一致,并让它们之间的差异是刻意的而非偶然的,这一点在两个人各自更新本应是同一基础流程的不同版本时,比听起来更重要。
发布之前
在标准操作流程成为官方版本之前要检查什么
边实际执行任务边通读草稿,而不只是坐在桌前阅读它。一个在屏幕上看起来完整的步骤,往往会发现漏掉了你自动完成的某个小动作,而这个漏洞在你双手放在键盘上时比从头到尾默读时要明显得多。
把每一个工具名称、字段名称和系统指代,与此刻屏幕上实际显示的内容对照检查。界面会变化,一份仍然引用已被重命名的按钮或已被淘汰的系统的标准操作流程,会让新员工去寻找一个不再存在的东西,这是比缺少一步更糟的失败,因为它看起来像是他们自己的错误,而不是文档的错误。
如果可能的话,把草稿交给一个从未做过这项任务的人,观察他在哪里犹豫。那个真正不熟悉这个流程的人停下来问"等等,我在这里该做什么?"的地方,是标准操作流程真正存在漏洞的最可靠信号,比你自己重新阅读更可靠,因为你无法让自己忘记这个流程,从而像那个人一样去阅读它。
Claude能很快把详细的流程演示变成一份干净、编号的流程,但判断这份流程是否真正符合工作实际的完成方式,以及它是否足够完整,能让一个新手不问问题就能遵循,仍然只有针对实际任务的真实试运行才能确认。
常见问题
在Claude起草标准操作流程之前,最重要的要告诉它什么?
按照你实际的做法演示这个流程,包括真实的工具和字段名称,以及那些你通常不会大声说出来的小的习惯性检查。那些看不见的步骤正是新员工真正需要的。
我应该如何处理一个取决于条件的步骤?
在该步骤中明确说明分支:如果某个条件成立,做一件事;如果不成立,做另一件事。隐藏在单一步骤中的决策,是人们走错路最常见的原因。
例外情况应该和主要的编号步骤混在一起吗?
不应该。让正常路径保持简短,把例外情况移到一个单独的例外情况部分,并在主要步骤中保留一个简短的指引,说明如果当前情况不符合正常模式该去哪里查看。
我怎么知道我的标准操作流程草稿是否真的有漏洞?
边实际执行任务边通读它,或者请Claude像一个不熟悉这个流程的人那样阅读它,并标记出任何未定义的内容。两种方法都能揭示出你已经了解这个流程后就看不见的漏洞。
Claude能帮助让标准操作流程与相关政策文档保持一致吗?
按照support.claude.com的项目帮助页面所描述的那样,把两者放在同一个Claude项目里,能让你在起草过程中更容易引用政策,也更容易在之后检查两者之间是否出现偏差。
标准操作流程应该怎样说明任务何时完成?
说明一个清晰的终点:任务真正完成时究竟是什么样子。没有这个,读者就只能猜测自己是完成了,还是漏掉了本应出现在最后写下的步骤之后的一步。
在真实流程发生变化后,我应该如何更新标准操作流程?
把现有的标准操作流程给Claude,描述现在有什么不同,并要求它准确指出哪些步骤发生了变化。这能帮助那些记住了旧版本的人注意到实际有什么不同,而不是重新学习整份文档。
标准操作流程草稿在发布前应该由谁来审查?
如果可能的话,找一个从未做过这项任务的人。他犹豫的地方,或者问接下来该做什么的地方,比你自己重新阅读更能可靠地说明真实存在的漏洞,因为你无法像一个不熟悉这个流程的人那样去阅读它。