做了两个 Skill 之后，我对“怎么写好 Skill”有了一些新理解

Tue, 23 Jun 2026 15:50:00 +0800

最近一方面是想让自己平时工作更顺手一点，另一方面工作上又正好有 Skill 比赛，我就连续做了两个自己的 Skill。做完以后回头看，技术细节当然有不少，但我现在最想先记下来的，其实是一些更偏方法论的感受。

因为我感觉，这两次折腾下来，自己对“Skill 应该怎么做”这件事，确实比之前想明白了一点。

第一个 Skill：做得太重了

我做的第一个 Skill，是一个辅助自己在同一个 workspace 里做前后端全栈开发的 Skill。

一开始的思路其实很自然：既然都做了，那不如尽量完整一点。于是除了前后端同步开发本身，我还往前扩了一层需求分析、影响范围分析，往后又补了一层四角色 code review，再加上一些我自己的开发习惯和细节偏好，慢慢全塞了进去。

从个人使用体验来说，体感其实还可以。但后面拿去参加比赛，先上传到 SkillHub 做自动化评测，我才比较明确地意识到问题在哪。

评测里有触发准确率、功能执行质量和 token 消耗量。前两项我的得分还行，第三项就比较难看。看到结果的时候我几乎立刻反应过来了：这个 Skill 确实还是包装得太重了。

很多时候我们会本能地觉得，功能更全一点总是好的。但 Skill 这种东西，可能恰恰不是这样。你塞进去的目标越多、流程越长、依赖越复杂，它就越容易变成一个看起来很强、但实际代价也很高的东西。

所以第一个 Skill 做完以后，我最大的反思不是“还不够强”，而是：我是不是一开始就想做得太大了。

比赛展示时，我又暴露了另一个问题

后面到了复赛 presentation 环节，我是第一个讲。现在回头想，那个过程也挺说明问题的。

我讲的时候就已经隐隐感觉到不太对。不是完全没内容，而是讲得有点太宏观了，不够落地，也没有把重点放在一个更关键的问题上：

评委到底想听什么，想了解什么。

我当时更像是在讲理念、讲覆盖面、讲整体设计，但评委显然更关心两件事：

有没有足够具体的示例和效果展示
这个东西是不是有较强的推广性

这两点，我觉得自己都做得不太好。展示不够具体，推广性也讲得不够扎实。现在看，估计得奖大概率是没戏了。

不过这件事对我也不是坏事。它至少让我意识到，做一个 Skill，不只是把东西做出来，还得想清楚：它到底解决了一个什么问题，这个问题是不是足够真实、足够具体，也足够容易被别人理解和复用。

第二个 Skill：开始收了

后来又有一个类似的比赛，我就不太想再闭门造车了。

有了上一次的经验之后，我这次最直接的想法就是：不要再试图一下子包太多东西，而是先专注地把一个问题解决好。

所以这次我的选题换成了自然语言转 SQL。

这个需求不是我拍脑袋想出来的，而是领导之前确实提到过，是一个真实存在的痛点。而且这种题目也天然比一个高度绑定我个人工作流的全栈开发 Skill，更容易讲清楚价值和推广性。

现在我已经先做了一个版本方案，准备后面继续往下做。

这次我也没有再完全闷头想，而是顺手研究了一下类似的产品，比如 vanna.ai。它整个盘子铺得比较大，功能也很多，但我还是找到了一点我觉得很值得拿来用的思路：在自然语言输入之后，先增加一层语义理解、抽取和标准化。

我觉得这一层挺重要的。很多时候，自然语言转 SQL 真正难的，不是最后那句 SQL 怎么拼，而是用户输入本身就很模糊。如果中间没有一层先把表达整理干净，后面直接硬转，其实很容易漂。

这段时间我总结下来的几点心得

除了看竞品，我也顺手看了一些关于怎么写好 Skill 的文章。边看边结合这两次实践，我现在大概有这么几个心得。

1. 做渐进式披露，`skill.md` 不要太胖

这是我感触最深的一点。

skill.md 如果一上来就什么都写，背景、流程、分支、细则全堆进去，最后往往就是又重又难读。对模型来说不一定稳定，对 token 来说也很浪费。

我现在越来越认同一种结构：中心短，辐射厚。

也就是 skill.md 本身只放最核心、最高信号的流程和判断，其他细节按需拆到别的文件里，需要的时候再读、再执行。这样既更省 token，也更不容易让主干被细节淹没。

2. 写完之后一定要测试

我现在会觉得，写 Skill 不能写完就算完，最好还是把它当成一种“程序”来看。

至少要验证几个问题：

能不能正常跑
能不能被正确触发
跑出来的结果稳不稳定
它到底是不是真的比不用 Skill 更好

前面几个都比较容易想到，但最后一个问题其实很关键。有时候你做了一套看起来很完整的 Skill，实际一用，却不一定真的带来了明显收益。它可能只是把原本就能做的事，换了一种更正式、但不一定更高效的方式重做了一遍。

所以测试不能只测“能不能跑”，还得测“值不值得用”。

3. 复杂逻辑一定要下沉到 `/scripts`

这一点我现在也基本确定了。

如果 Skill 里有复杂逻辑，尤其是固定判断、重复处理、半结构化数据加工之类的内容，最好还是写成脚本放到 /scripts 下面，不要硬塞在 skill.md 里。

原因也很直接：脚本更稳定、更容易复用、更容易测试，也更省上下文。很多本来可以交给程序去做的事情，如果非要用自然语言写得特别细，最后只会又长又重，还不一定稳。

4. 最后，真的要用 `skill creator`

这个结论我现在也挺明确。

以前可能会觉得，自己手写也不是不行，为什么非要用 creator。但真做了两次以后，我会觉得，skill creator 的价值不只是帮你生成一个壳子，而是能把结构、规范、拆分方式这些基础东西先拉到一个比较合理的起点。

很多时候，人自己写的时候，很容易想到什么塞什么，最后越写越散。用 skill creator，至少能让整个 Skill 的骨架一开始就更规整一点。

最后

如果现在让我总结，这两次做 Skill 最大的收获是什么，我大概会说，不是我学会了多少“高级技巧”，而是我慢慢开始意识到：

Skill 最怕的，可能不是做不大，而是收不住。

第一个 Skill，我更像是在证明“我能把很多东西包进去”；第二个 Skill，我开始尝试去证明“我能不能先把一个问题解决好”。这两种思路看起来只是收和放的区别，但最后做出来的东西，味道其实完全不一样。

至于这次新的比赛最后能不能拿到一个好成绩，我现在也不好说。能拿当然最好，但如果最后还是没拿到，我觉得也没什么关系。因为至少上一次比赛已经让我学到了不少东西，而这一次，我又比上一次更清楚了一点：以后再写 Skill，到底应该把力气花在哪。

SkillHub on CHEN 的博客