别再到处装 Skill了！自己做的可能更好用

现在打开 GitHub，大家可能会发现以前都是放开源软件项目代码的，现在很多人都在上面放自己的 Skill，甚至各个自媒体博主都人手一个。

现在我们再逛 GitHub 上的 Skill，就像逛一个应用商店那样。但是，这也不代表啥好东西我都要安装一下。不是说那些大佬的 Skill 不好，而是你可能弄错了一些事情。

装得越多，Agent 效果反而会越差

先说一个很现实的问题。

Agent 想要用某个 Skill，它首先得知道有这个东西，其次还得知道这个 Skill 能干嘛。

每次启动一次新会话时，所有能被 Agent 看到的 Skill 的 Name（名字）和 Description（介绍），都会被载入到 Agent 的上下文里边。

你要是还装了几百个 Skill，那必然会分散模型的注意力。

换句话说，你装得越多，Agent 它越懵。最后的生成效果也会一定程度受到影响。

所以，不是装得越多越好。

Agent 不缺通用知识，缺的是你的上下文

这是我本文最想说的一点。

Agent 其实是不缺通用知识的。它真正缺的，是只有你知道的那部分上下文。

举个例子，大家前段时间都在用的 Superpowers，里面确实装了不少软件工程的最佳实践、一些工业化的流程。但我觉得这种能力，等下一代模型训练的时候，就是会作为训练语料烧录到模型里的。到时候你都不用调这个 Skill，它自然就懂。

即使是早期的大模型，你问它"国庆节是哪天？"，它也能回你"10 月 1 日"。

而真正值钱的、能切切实实渗透进你的工作的，是只有你知道、你偏好的东西。

举几个例子。

我最近的视频封面很多都是黑色底，因为我认为这相对会更有科技感和 YouTube 画风感，这是我个人的封面偏好。

我写代码喜欢用驼峰式，而且 ID 里的那个 D，我要小写 d 不要大写（比如：ClientId）。

这些，都是我的上下文，和别人是不一样的。

当然，我举的这些例子比较简单。我想表达的是：这些个人、组织内部的原则、偏好、底线、经验知识，这些“私有的”上下文才是有价值的、需要 Agent 去知道的。

别在 Skill 里写"正确的废话"

我们在写 Skill 的时候，会倾向于把它写成通用的、甚至是保留一定灵活性的。但这样最后往往会写出一堆正确的废话。

什么叫正确的废话？

比如你在 Skill 里写"遵循最佳实践"——那什么是最佳？写"妥善处理异常"——具体是什么异常？写"确保工程安全、高质量"——那怎样算高质量？安全要到什么程度？

这些话都对，但也都没什么用。

关键是你得把自己真实踩过的坑、真实的经验写进去，而且要足够的具体。只有这样，Agent 才可能真的结合你的经验去做。

打个几个比方。

我字幕转录用的模型不是特别新，有时候会出错，所以我就需要维护一套我自己的词库去做纠偏。

我有时候用做 PPT 的 Skill，会要求它输出 PPT 而不是 HTML 的演示文稿，是因为领导就是这么要求的。

我写 code review 的 Skill，就结合我们团队自己的编程原则和规范，给定验收标准 —— 有些代码看着也没啥问题，但跟我们的标准不符，那就是不符合要求的。

真正该写进 Skill 的，是你真正想要的东西，是你平时怎么做这件事的要点。

自制 Skill 的过程，本质上就是在反复纠偏

一个通用的 Skill，通常只能代表"通常怎么做"。但你自己的 Skill，代表的是"在我这里，这件事应该怎么做"。这两者有本质区别。

你不带任何上下文地问 AI 一个问题，它一定给你一个最大众化的解法，而不是最适合你的。（问人也同理）

而你自制 Skill 的过程，就是不断地把 AI 往你的解空间里拉。

「这个不要」「这样写不对，换个写法」「别这么开头，我这视频要真实问题切入」「这个必须先检查再执行」「这个必须校验」……

虽然但是，现在的我们其实有点像甲方了。有时候我们不具体看到一些东西，可能确实也想不到，那就先让它做，做出来至少你能知道什么是错的、什么是你不想要的，再一点一点把它往对的路子上拉。

质疑甲方，理解甲方，成为甲方，超越甲方。

包括你拿到一个别人的通用 Skill，觉得没那么好用，你也能通过反复纠偏，让它回到你的上下文、你的要求上。

自制 Skill，本质就是把一个大众化的解法，反复纠偏成你自己的工作方式。

哪些可以照搬

那难道所有 Skill 都自己做吗？倒也不至于。像下面这几类，直接拿来用就行。

第一，偏通用、跟客观规则强绑定的。

PDF、PPT、表格处理这种。Anthropic 官方，国内的像张Zara、花叔，他们做的那些 PPT Skill 就挺好用的。里面可能带他们的偏好，但整体就是通用能力，用他们的就行。

第二，标准化、厂商或基建团队已经提供的。

比如程序相关的 API、部署、测试。厂商自己提供了，或者基建团队（IT、运维）那边有，你就直接拿来用。

第三，客观规则非常明确的。

这种是"死的"，跟你主观经验没关系，拿来用是没问题的。比如我之前分享的封面尺寸转换的 Skill 就是。

我会先做一个母版，以 B 站推荐流封面要做的 4:3 为主，然后我想在全平台都能用，就要拓展、“裁剪”生成 —— B 站个人主页列表是 16:9，YouTube 也是 16:9，公众号要 2.35:1 和 1:1，小红书要 3:4。

这种很死的规则，你直接用我的 Skill 就行，因为平台要求就是要那样。只是里面可能包含了一些我对平台的理解以及踩过的坑，比方说转的时候要注意不影响主体内容、文本内容要能保留，公众号那种长图就不用包含真人了这种。

哪些应该自己做

那什么更适合自己做？

内容创作本身，你自己那套东西。

你要用 AI 生成文字，首先得有自己的语料库吧，得有自己的一套行文逻辑、口癖、行文节奏、标点习惯，AI 都得知道。

内容工作流，你自己的审美。

你喜欢什么样的封面、什么风格的标题、怎么生成视频简介、标签、章节、字幕、粉丝动态，这些都是“你的”。

你的视频拍完了怎么预处理、怎么做粗剪甚至直出，也是你的。

这些别人没办法替你写出来，就像我之前给你们分享过的内容工作流，你们拿去用大概率会发现没那么好用，很可能会踩点坑 —— 因为那是我的。

项目规范，团队自己的约定。

比如我们在公司上班，团队都有自己的标准。Git 每个公司都有自己的标准，工作流也各有各的，写 Java、写 Go、写 TS 的团队规范都不一样，哪怕是设计也各有各的 DESIGN.md 规范。

强依赖品味和经验的。

我举个很经典的例子 —— 视频封面生成。

这个很多博主都做，但你拿来生成的话就会发现，那是他的味道、他的 IP 味，甚至带着他的品牌；而这些都不是你。

包括你用别人的建站 Skill 做出海站，也是别人的经验，做出来一股别人的味道，经验也都是别人的，最后出了问题你可能都不知道是哪个环节。

最好的组合，不是二选一

事实上，一部分拿通用 Skill 来直接用，一部分自己做，才是大家的常态。

比方说本文的插图用的是 Zara 的 frontend-slides（本来是用于 B/红/油的视频演示）；而这个文章和视频的封面，都是我自己的 Skill 做的，发布流程、怎么同步到 B/红/油、封面怎么转尺寸、简介和标签怎么生成，都是我自己磨出来的 Skill；包括我怎么从视频粗转成当前的这篇文章，做一鱼多吃。

此外，我剪辑视频，用的 ChatCut 插件，就是比较底层、通用的 Skill 了；而剪映、Screen Studio 的剪辑，我又会自己去写一些 skill 来做。