第七章：如何把现成用例改成自己的工作流

本章导读

会用一个现成用例，只能说明你已经有了起点；真正能持续产生价值的，是把它改造成适合你自己工作的那一版。

很多人停在“照着跑通一次”这个阶段，结果过一段时间就不用了。原因通常不是用例本身不行，而是它始终还是“别人的方案”。一旦平台不同、流程不同、表达习惯不同，它就很难真正融入你的日常工作。

这一章要讲的，就是如何把一个现成用例，逐步改造成自己的工作流。重点不是推倒重来，而是在保留有效结构的前提下，逐步替换不适合你的部分。

7.1 如何替换平台

很多用例的核心方法是通用的，但落地平台未必适合你。

例如：

原用例基于飞书，但你主要用企业微信
原用例依赖某个内容平台，但你实际发布在别的平台
原用例面向海外数据服务，但你实际使用国内数据源

这时候最容易犯的错误，就是把“平台”误认为“方法”。实际上，一个用例真正重要的通常不是它接了哪个平台，而是它解决了什么流程问题。

你在替换平台时，建议先问自己三个问题：

原平台在这个用例里承担什么角色
我的平台能否承担同样的角色
哪些地方只是接入差异，哪些地方会影响整个流程结构

比如一个平台只是承担“接收消息”这个角色，那替换时重点是输入入口；如果它还承担“协作沉淀”“权限控制”“结果分发”，那替换时就不能只看消息层面。

换句话说，替换平台不是机械替换名字，而是重新确认它在整个工作流里扮演的功能位置。

7.2 如何修改 Prompt

Prompt 是最容易被修改的部分，也是最容易被改坏的部分。

很多人一看到别人的 Prompt，就想全部重写，结果反而把原本有效的结构拆掉了。更稳妥的做法是：先识别原 Prompt 里哪些是通用骨架，哪些是场景细节。

通常可以这样拆：

通用骨架：角色、任务边界、输出要求、限制条件
场景细节：行业词汇、平台名称、业务对象、表达风格

改 Prompt 时，优先改场景细节，谨慎改通用骨架。

例如你可以先替换：

输出对象
行业背景
任务输入形式
结果展示方式
语气风格

而不要一开始就把整个角色设定、执行逻辑和限制条件全部重写。因为很多稳定性，其实恰恰来自这些你以为“看起来普通”的结构部分。

更实用的原则是：

先局部替换
每次只改一类信息
改完就验证
能保留的结构尽量保留

这样改出来的东西，通常更稳。

7.3 如何加入自己的规则

一个现成用例之所以还不够“像你的工作流”，通常是因为它还没吸收你的工作规则。

这些规则可能包括：

你平时的表达习惯
你团队内部的固定格式
你所在行业的敏感边界
你在判断结果时最看重的标准
你不希望它做出的某些默认假设

这些规则一旦补进去，用例的可用性通常会明显提升。

你可以优先加入这几类规则：

输出格式规则
表达风格规则
信息保留与删减规则
判断优先级规则
不允许触碰的边界规则

例如：

优先输出可直接发给团队的版本
结论必须基于原材料，不允许补充未确认事实
风格尽量简洁，不写空泛套话
如果信息不足，明确指出，不自行补全
涉及风险判断时，只做整理，不替代最终决策

这些规则并不复杂，但它们会明显决定结果是不是“能真正拿来用”。

7.4 如何沉淀成长期流程

一个用例只有反复使用，才会逐渐从“技巧”变成“流程”。

要把它沉淀成长期流程，关键不是一次改得多完美，而是让它满足三个条件：

能重复使用
结果大致稳定
你愿意持续维护

如果一个用例每次都要重新解释背景、重新补充规则、重新整理输入，那它很难真正进入你的日常工作。相反，如果你已经能让它在某一类任务上稳定发挥，那就应该开始考虑把它固化下来。

长期流程通常会逐步形成这些特点：

输入形式越来越标准
输出格式越来越固定
规则越来越清晰
复用成本越来越低
人工修改量越来越少

也就是说，长期流程不是一开始就设计出来的，而是在一次次使用中被收敛出来的。

所以更现实的目标不是“第一次就做成完整系统”，而是先把一个能反复跑通的小流程稳定下来。

7.5 如何让团队成员也能复用

当一个用例只对你自己有效，它还只是个人工具；当别人也能顺利使用，它才开始变成团队资产。

让团队复用的关键，不在于你自己多熟练，而在于别人能不能低成本理解并使用。

通常要满足这几个条件：

场景边界清楚
输入要求明确
输出格式固定
规则写得足够明白
别人不需要猜你心里的默认前提

你可以把团队复用理解成“把隐性经验显性化”。

很多个人用法一旦给别人用就失效，原因往往不是工具变了，而是原来很多判断都在你脑子里，没有写出来。别人一接手，就不知道哪些信息是重点，哪些结果算合格，哪些地方不能越界。

所以，如果你真的想让一个用例进入团队协作，至少要补清楚这几类信息：

这个用例是干什么的
什么情况下适合用
需要提供什么输入
输出应该长什么样
什么时候必须人工介入

一旦这些信息写清楚，团队复用才有基础。

本章小结

把现成用例改造成自己的工作流，重点不是推翻原方案，而是分层改造：

先替换不适合你的平台
再修改与你业务相关的 Prompt
然后加入自己的规则
最后通过反复使用把它沉淀成长期流程

如果进一步希望团队也能使用，那就要把原本只存在于你脑子里的经验写出来，变成别人也能理解和复用的规则。

这一步做完之后，OpenClaw 对你来说就不再只是一个“能试一试的工具”，而会开始变成真正进入工作流程的一部分。