K6如何打磨自己的 Agent Skill

Skill 工坊的 29 个版本

2026 年 4 月 6 日，我往 Skill 目录里加了一个专门用来生成 Skill 的 Skill，后来它的中文名定为 Skill 工坊。它的 Changelog 从 4 月 14 日的 1.1.0 一直记到 10 月 31 日的 4.6.8，一共 29 个版本。

这些版本都是被具体问题推出来的。2.0.0 是因为我把所有 Skill 从一个大仓库拆成了独立仓库；3.0.0 开始要求每个 Skill 写明什么时候触发、什么时候不触发；4.0.0 把发布从创建里拆了出去，交给单独的 Skill 发布助手。

先把五件事写清楚

我对一套 Skill 的最低要求，是回答五个问题。拿写书 Skill 举例，翻开每张卡看它的答案。

写 Skill 时最容易只写第三件，怎样执行。让它稳定下来的，往往是第四件和第五件：不能做什么，决定它会不会闯祸；什么算完成，决定你能不能验收。

触发条件还要分清主动和自动。我的会话记录里，Git Commit 的 401 次调用有 98.8% 是我手动触发的，深度调研有 93.8% 是 AI 自动触发的。提交意味着我认了这一版，可以存档、可以发布；补证据适合让系统自己去找。

每次真实执行，留下一个 Case

五件事写完，Skill 才有了骨架。打磨从第一次真实任务开始。

我把一次真实任务的记录叫作 Case：脱敏后的输入、最小的 Prompt、真实的输出和验收证据。成功要记，失败更要记，失败的 Case 就是下一个版本的需求。2026 年 8 月 23 日，我上线了 Skill 案例馆，专门把真实的验收结果写回 Skill 和官网。

这个圈不是偶尔转一下。截至 2026 年 8 月底的统计，Skill 工坊被调用了 95 次，Skill 精修师 54 次，自动发版 165 次。

这组数字我在外滩大会上公开过。175 个本地 Skill 里，125 个在初版之后继续迭代；写了 Changelog 的有 120 个，留下 Case 的只有 55 个。改过的很多，拿得出证据说明自己变好了的还少。

反馈先分层，再写进 Skill

打磨时最容易出的错，是把只对这一次有效的意见写进 Skill，从此每次任务都被它管着。

我现在按三层处理反馈：只对这一次任务有效的，只改这一次的产物；能跨任务复用的，写进最窄的那个 Skill；跨领域都成立的原则，才去改全局规则。2026 年 8 月 24 日，我把这道反馈分类门禁加进了全部 88 个生产 Skill。

我的文风 Skill 是一个例子。它先用 19 篇文章校准出一份文风画像；之后我对稿子不满意时，比如判它“AI 味太重”，复核出来的写法就记进一份负向校准，到 10 月底记了三次。每张校准表后面都注明：右列只适用于本次材料，不得作为后续文章的固定句模。加这一句，是怕一次性的意见变成以后每篇都要套的规矩。

能用程序查的，不要只写成规则

2026 年 9 月 2 日，我让 Agent 在一个 Skill 里加了一条“禁止编造”。同一次会话里，它刚把这条规则写进 SKILL.md，下一轮就违反了。

规则写在文件里，模型能读到，也能忘掉。后来我写了一个检查程序，在 Agent 每轮结束时扫一遍：它提到的路径和提交号，只要之前没在工具输出或我的消息里出现过，就报出来。

写书 Skill 的验收也交给了脚本。10 月 31 日的 0.7.0 拿《超越之旅》第一期讲义复验：PDF 109 页、书签 138 个，与此前排出的版本一致；缺字、超宽、页面溢出、章末短页都是 0。这些数是脚本数出来的，我不用一页页去翻。

先自用，再发布

打磨到什么程度可以交给别人？我用三级来判断。

换一台电脑也能装上、跑通，说明它已经离开了你这台电脑。只能在你这台电脑上、在你盯着的时候才能跑的东西，还只是一次演示。

常见误区

• —把 Skill 当成更长的 Prompt。字数多了，触发、边界和完成标准还是空的。
• —写了规则就以为管住了 Agent。能用程序检查的，交给程序。
• —把一次性的意见写进 Skill。先分清它属于这一次任务、这个 Skill，还是全局。
• —拿版本号当证据。改了多少次说明不了好坏，Case 有没有变好才说明。
• —一上来就做一百个。先把一个 Skill 放进真实任务里磨一百次。