【征文】#WorkBuddy# 我把 9 个重复工作流封装成了可复用技能，从此不再重复提需求

一、先说我遇到的麻烦

用 AI 干活，最累的不是活儿本身，是重复描述同一件事。

比如我每周要出一版数据复盘，每次都得从头说一遍：数据在哪、口径怎么定、表格怎么分列、结论要几段。第一次说清楚了，第二周还得再说一遍——因为对话历史不认人，换个新会话它就全忘了。

我统计了一下自己重复做过的事：视频脚本→分镜→配音的流程、表格批量清洗、文档结构整理、定时生成日报……一共 9 件，每件平均每次要花 3–5 分钟写需求。一个礼拜光"提需求"就要耗掉小半天。

后来我把这 9 件事全部封装成了 Skill（技能包）。现在的效果是：一句话触发，剩下的它自己跑。

这篇文章把封装方法、判断"该不该封装"的标准、以及我踩的坑，一次说清。

二、结论先行

不是所有重复的事都值得封装。我自己的判断标准只有一条：

同一件事，一个月内会做 3 次以上，且输入输出的格式固定 —— 才封装。

低于这个频率，封装成本高于收益；格式不固定，封装出来的技能会反复跑偏，比不封装更烦。

三、第一步：判断该不该封装（我踩的第一个坑）

我最早的做法是"觉得会重复就封装"，结果 36 个技能里，真正高频用的不到 10 个，剩下的是伪需求——做的时候很爽，做完一次没再用过。

后来我给自己列了三道判断：

四、第二步：一个 Skill 的标准结构

我现在的封装模板就四块，缺一块就会出问题：

skills/技能名/
├── SKILL.md          # 核心：做什么、什么时候用、什么时候别用
├── references/       # 该领域的规范、术语表、示例
├── scripts/          # 需要确定性执行的脚本（Python/Shell）
└── assets/           # 模板文件（输出骨架、样式）

SKILL.md 是唯一必须有的文件，开头写元信息：

---
name: 技能名
description: 一句话说清这个技能干什么，以及什么时候该用它
---

description 是整个封装里最值钱的一行。 它被模型用来判断"该不该加载这个技能"。我最初的写法是"用于处理数据"，结果它什么任务都想插一脚；改成"当用户需要清洗带合并单元格的 Excel 报表并输出为标准一维表时使用"，误触发立刻少了。

五、第三步：写"什么时候不用"（第二个坑）

这一步是我后加的，加完质量提升最明显。

在 SKILL.md 里明确写一段「不适用场景」，例如：

## 什么时候不要用
- 数据行数 < 50 行时，直接让 AI 处理即可，不必走清洗流程
- 源文件为图片扫描件时，本技能不适用（需先做 OCR）
- 涉及金额、合同、人员信息的最终确认，本技能只出初稿，必须人工复核

作用有两个：减少误触发；更重要的是把人工复核的位置固定下来——哪些环节不能交给它，写清楚比事后记住靠谱。

六、第四步：区分"提示词型"和"工程型"

我那 9 个技能里，8 个是提示词型，1 个是工程型。这两类的封装思路完全不同：

工程型技能安装前必须过一遍安全审查：看它读写哪些路径、有没有网络请求、有没有删除操作。提示词型可以放心装，工程型不行。

七、实测数据

【待本人实测补充，发布前填，不要编造】

八、踩坑与边界

1. 技能不是越多越好。 技能多了，模型选择成本上升，反而容易选错。我现在的原则是控制在 15 个以内，重复的合并。
2. description 写得太宽会误触发。 宁可窄一点，窄了可以手动召唤，宽了会到处乱插。
3. 别把"需要你判断"的活封装进去。 需要临场判断的环节，封装后会变成固定动作，遇到新情况就翻车。
4. 工程型技能要留日志。 没有执行日志，出错时无法回溯，等于盲跑。
5. 定期清库存。 我每季度清一次，三个月没触发过的直接归档，不做情感留念。

九、小结

封装 Skill 的本质，是把"每次都要重新说的需求"变成"一次说清、以后一句话调用"。判断标准很简单：一个月 3 次以上、格式固定、产出可验收。满足就封装，不满足就别折腾。

省下来的不是时间，是注意力——不用再每周重复解释同一件事，这个收益比省几分钟大得多。