【制造·硬件】同一套流程手工跑了 5 轮之后，我把它做成了 WorkBuddy 技能

一、起点：一套每周要手工跑三轮的流程

我在做电池保护板（PCM）的行业里，最近在参加一个 AI 办公主题的原创征文活动，要保持每周两三篇的节奏输出完整案例。每篇文章的流程其实高度固定：从选题库取题、写稿配图、转格式、打开网页编辑器填进去、存草稿、登记台账。第 5 轮的时候我意识到，这个流程完全符合"值得做成技能"的画像。

先看痛点，都是真金白银的代价：

▲ 输入材料与技能目录

最离谱的是浏览器环节：命令行直接拉起的 Chrome 会在几十秒内被系统清理掉，我先后试了八种启动方案全部失败，最后靠系统任务计划接口才让窗口稳定存活。这些坑每一个都要现场排查半小时起步。

二、判断：什么流程值得做成技能

动手之前我先给自己立了三条判断标准，避免"什么都想自动化"。判断依据不是感觉，是台账——我在跑第二轮时就建了一个发布台账（一个 CSV，记日期、标题、链接、状态、字数、笔记）：

▲ 发布台账

10 天里 5 篇文章全部过审，台账同时记录了每一轮的坑。回看这份数据：重复频率（一周三轮还在涨）、步骤稳定性（每轮只换选题和素材，骨架一动不动）、出错代价（标签填错位置就得人工返工）——三条全中，值得做。

这里有个心得：先让流程有账可查，再谈技能化。台账里的 notes 字段，后来成了技能里"硬教训"清单的主要来源。

三、动手：把 SOP 翻译成 SKILL.md

WorkBuddy 的技能本体就是一个 SKILL.md 文件加一组配套脚本。写的时候有几个关键决定：

1. frontmatter 写清触发条件：name、description 里写明"什么话该触发这个技能"（比如"发一篇社区文章""查发文台账"），这样以后的会话里一句话就能召回整套流程，不用重新解释背景。

2. 把"红线"和"流程"写在一起：永不代替用户点发布、永不代替填问卷、配图必须真实、客户材料必须脱敏——这些不是备注，是和步骤同级的硬约束，每次运行都会被读到。

3. 踩坑写进正文而不是注释：比如"发布弹窗里有两个长得一样的标签输入框，必填区要用祖先文本位置判定"这类细节，写成编号的硬教训清单，AI 每次执行前都会过一遍。

4. 模式开关留一行配置：review（只写草稿等确认）/ semi_auto_v2（AI 干到草稿、人点发布）/ auto（全自动）。auto 标注"永不启用"——对外发布的内容必须本人过目。

四、工作流：AI 干到哪一步，人从哪里接手

最终定稿的工作流是 semi_auto_v2：左侧 AI 自动跑 7 步，右侧人只做 3 件事。

▲ 工作流分工

配了 17 个脚本（合计两千多行）把这些步骤固化：稳定拉起浏览器的、往编辑器里填标题正文和标签的、复核字数图片数的、markdown 转 docx 的。然后把整个技能挂上定时任务：每周一、三、五早上 9:30 自动运行一轮，跑完必须汇报选题、标题、字数和草稿路径。

中途有一次重要的调整：第 4 轮发布时标签被填进了"自定义关键词"选填区，必填区空着，点发布被拦截，只能人工补填。复盘后我把判定方法写死进脚本——从输入框向上遍历祖先文本，先出现"文章标签"的才是必填区，并且只点选官方标签库里精确匹配的词。此后三轮再没出过错。技能化的真正收益在这类细节上：人会忘，文件不会。

五、产出物：一套可以复用、还在自我修正的流程

最终沉淀下来的东西有四样：

▲ 硬教训清单

• 一个技能包：SKILL.md（325 行）+ 浏览器自动化手册（284 行）+ 17 个脚本，选题库和发布台账都在里面；

• 一份发布台账：5 篇已发布文章的完整记录，包含每篇的字数、配图数和踩坑笔记；

• 一条定时任务：每周三次自动跑，人只负责最后的确认和发布；

• 一份硬教训清单：目前积累到 10 条，每条都是真实事故换来的，比如"调试协议消息丢了会话字段导致探测全部假失败""标签页关到 0 会触发浏览器自杀"。

六、写在最后

这次沉淀给我最大的感受是：技能不是把流程"写下来"，而是把流程"跑过、踩过、修过"之后的东西固化下来。第一版 SKILL.md 只有一百来行，现在三百多行，多出来的部分几乎全是教训——每修一个 bug，就往文件里加一条，AI 下次运行就不会再栽同一个坑。

对工程师同行，我的建议是：挑一个你已经手工跑了三轮以上、步骤稳定、出错有代价的流程，从建台账开始做技能化。台账是地基，脚本是可以重写的，唯独踩过的坑记录下来才真正保值。