同一件事做到第三遍，就把它写成技能——我的 WorkBuddy 自建技能实践

同一件事做到第三遍，就把它写成技能。这是我用 WorkBuddy 半年后最笃定的一条习惯。

攒提示词和写技能，是两件事

前三个月我走的是"攒提示词"的路子：把好用的说法存进备忘录，用的时候翻出来改一改。到后来备忘录里躺了四十多条，但真正会再用的不到十条。

原因很直白——提示词只写了"做什么"，没写"什么时候不能用"。

技能不一样。技能是一份能被执行的文件，除了操作步骤，还必须写清适用边界、前置条件和踩过的坑。两者的差别，类似随手记的命令和一份能交给别人跑的脚本。

图 1

我判断"该不该做成技能"的三条线

不是所有重复劳动都值得沉淀。我用三条线筛：

1. 做过三遍以上。只做过一两次的，路径还没稳定，做出来大概率要返工。
2. 存在"只有我知道"的隐含条件。比如要复用浏览器登录态、要读某个固定路径、输出必须满足某个格式约束——这类隐含条件不写下来，下次必然重踩。
3. 出错的代价高。会给客户看的东西、会写进系统的数据，都值得把校验步骤固化进技能。

三条里中两条，我就动手。

一个技能里我必写的四块内容

一、适用与不适用

这块我认为比操作步骤更重要。

只写"能做什么"，技能就是个陷阱——下次遇到形似而神不似的场景，它会被误用，然后你还得花时间排查为什么不对。把"不适用"写清楚，等于提前把边界钉死。

二、前置条件

权限、依赖、登录态，缺一样技能就跑不起来。

我习惯写成清单：需要本机已登录哪个账号、需要哪个命令行工具、需要哪条路径存在。看着啰嗦，但省下的正是"我上次明明跑通了，这次为什么报错"的那半小时。

三、标准操作路径

命令、参数、顺序。要具体到可以直接复制执行，不能写成"打开系统后按提示操作"这种无法落地的描述。

四、踩坑与报错原文

这一条是我踩了半年才想明白的。

反面写法是"注意不同系统路径格式可能不同"——半年后你自己也看不懂当时撞了什么墙。

正面写法是把报错原文贴进去，再写一句结论。比如某个接口在参数格式不对时会返回一句很迷惑的错误信息，实际原因完全在别处。只有把这句原文留着，下次看到才能三秒回想起来。

举例：一个"看起来很简单"的技能

以"从会议回放链接生成结构化纪要"这件事为例，它的生长轨迹是这样的：

• 第一遍：我一边听回放一边手敲，花了四十分钟。
• 第二遍：我写了一段提示词，把素材丢进去让它整理，但输出格式每次都不一样，还得自己重新拆。
• 第三遍：做成技能，并在里面写死了三件事：
  1. 先确认这场会议有没有回放链接——没有就别走这条路，这是适用边界；
  2. 输出必须是三段式：结论 / 待办 / 待确认，待办项必须带责任人和时间点；
  3. 待办的责任归属必须人工复核一遍，不能直接采信。

第三条就是典型的"踩坑固化"。第一次我图省事，把它拆的待办直接转发出去了，结果有两条责任人标错了。这个坑写在技能里之后，就再没犯过第二次。

技能会自己组合出新技能

做到十几个以后我发现，新技能往往是老技能的组合。

会议那条链路（抓回放 → 出纪要）再配上"写入资料库并归档"，就成了一条完整流水线；表格那条链路（读模板 → 填值 → 回读校验）配上"批量上传"，就能直接对外交付。

所以完全不需要一上来就规划大而全的体系。先把单点做扎实，组合是自然长出来的。

图 2

技能要写"实测日期"

我在每个技能的顶部都会写清：哪一天、在什么环境、对什么对象实测通过。

作用只有一个：半年后我一眼就知道这个技能还有效，还是需要重新验一遍。没有这个字段，你会对一堆技能的有效性产生集体怀疑，最后干脆不用了。

我现在的工作流

1. 手上出现第三次重复 → 先在待办里记一行，但当场不写技能（正在做的时候写出来容易变成流水账）。
2. 每周挑一条，把当次完整的操作路径连同踩过的坑一起落成技能。
3. 下次直接调用，人只做判断，不做搬运。
4. 调用时发现不对 → 当场回改技能，绝不拖到"下次一起改"。

图 3

一点体会

写技能这件事，本质上不是在给 AI 写说明书，而是在给未来的自己省时间。

而未来的自己有一个特点：他完全不记得今天踩过什么坑。所以坑必须写下来，而且要用当时的原话写。

判断标准可以很简单：如果这份技能明天交给一个不认识我的人，他能不能独立跑通？ 能，就说明写到位了。

本文为个人使用经验总结，示例均为通用办公场景，不涉及任何客户信息。