上个月，我对着自己的 OpenCode 配置文件发呆了十分钟。
斜杠命令列表已经长得翻不到底，每次想找个功能得在列表里滑半天。「这个 Skill 是啥来着」「装了这个干过啥」「这两个功能是不是重复了」——这几个问题我反复问自己，却一个都答不上来。
那一刻我意识到，我正在经历一种典型的工具焦虑：装技能的时候觉得是在提升战斗力，实际上只是在积累背景噪音。
回顾我过去几个月的操作路径，大概是这么个循环：
看到新 Skill → 感觉好厉害 → 装上 → 用了一两次 → 忘了这回事 → 下次看到新的继续装
这个循环的问题在于：我在用「收集」代替「建设」。技能库越来越臃肿，但真正形成战斗力的几乎没有。
直到上个月，我开始做一件早就该做的事：把自己在项目中反复使用的流水线，整理成自己的 Skill。
这个转变很关键。之前我一直在「找」Skill 装，后来我开始「造」Skill 用。
比如我在一个项目中需要频繁做 API 前后端联调，每次都要重复「查文档 → 写 Mock → 验证接口」这一套流程。意识到这一点后，我把整个流程固化成一个小 Skill，下次遇到同样场景，一键调用，模型直接按我设定的步骤走。
关键发现是：当我从使用者变成设计者之后，我才真正理解一个 Skill 应该在什么场景下被调用。 这个认知是安装别人技能永远学不到的。
在这个整理过程中，我发现一个让我重新审视「好 Skill」的标准：
社区里人气高的 Skill，不一定适合你。
omo 全家桶很强大，多模型并行、自动拆解任务、子 Agent 调度——听起来是一个完整的高效率解决方案。但如果你每天的任务是「给产品加个小功能」「改个 bug」「写个脚本」，这些能力对你来说根本用不上。omo 的调度开销反而会成为负担。
Superpowers 很专业，TDD 流程、Git 分支规范、代码审查流程——一套工程思维直接焊进 AI。但如果你现在还在探索阶段，需要快速原型验证，它的强制流程只会拖慢你的迭代速度。
这不是 Skill 本身的问题，是「方向」的问题。 别人的工作流是别人在特定场景下打磨出来的，强行拿来用，要么水土不服，要么邯郸学步。
真正有价值的 Skill，往往是你在自己的项目里，用真实的痛点喂出来的。
Skill 装完之后去全局加载区「躺平」，是大多数人默认的操作。但这个默认设置，正在以你看不见的方式消耗你的效率。
代价一：每次对话都在负重训练。 全局加载的 Skill 意味着每次启动对话，模型都要先消化一遍所有技能的上下文。10 个 Skill，可能有 8 个跟当前任务毫无关系，但模型得全部过一遍才能开始工作。这就是为什么有时候你觉得「AI 反应变慢了」——不是模型能力下降，是你给它的包袱太重。
代价二：选择成本高于执行成本。 当你有 20 个 Skill 可用，模型需要消耗认知资源判断该调用哪个。这个判断过程不是零成本的，场景越复杂，判断失误的概率越高。结果就是：你以为工具更多选择更多，实际上是让模型在每个决策点都多犹豫了一秒。
代价三：技能打架。 不同 Skill 可能对同一个任务有不同的处理逻辑，全局加载后，模型可能在多个 Skill 之间左右横跳，反而不如单一 Skill 来得稳定。
上个月我在整理自己的 Skill 时，给自己定了一个硬规则：
Skill 跟着项目走，不跟着感觉走。
具体做法是：
当我接手一个新项目时，先不装任何 Skill。用裸 OpenCode 跑几天，记录下哪些步骤是重复的、哪些流程是低效的。等这些问题暴露出来之后，再针对性地找或写 Skill 来解决。
这样做有几个好处：
第一，Skill 有明确的使用场景。你知道它是为了解决什么问题而存在的，不会装完就忘。
第二，Token 预算可控。Skill 只在对应的项目目录下加载，不会污染其他项目的上下文。
第三，容易迭代优化。因为是你自己设计的 Skill，改起来也顺手。用几次发现问题，直接调整，比改别人的 Skill 容易多了。
强烈建议： 不要一股脑全局安装 Skill。装之前问自己三个问题：这个 Skill 解决的是什么具体问题？我上次遇到这个问题是什么时候？下次遇到会在什么场景下？如果三个问题都答不上来，先放着，别装。
如果你的 Skill 数量已经超过 20 个，或者每几个月就往列表里塞新东西，强烈建议考虑按需加载方案。
opencode-plugin-preload-skills 支持按文件类型、目录、Agent 类型等维度触发技能加载，还内置了 Token 预算控制。对于大型 Skill 库，可以用 Summaries Mode 只加载摘要而不是完整内容，避免上下文被撑爆。
opencode-lazy-loader 解决的是 MCP server 的启动问题——技能自带的工具只在被调用时才启动，闲置 5 分钟后自动释放，兼顾了功能和性能。
opencode-skillful 则更适合 Skill 数量特别庞大的场景，支持自然语言技能发现，模型可以根据对话内容自动推断该调用哪个 Skill。
这几个工具的共同思路是：让 Skill 在该出现的时候出现，不该出现的时候消失。
如果你现在不确定某个 Skill 值不值得保留，可以用这三个维度自检：
使用频率 — 三天内用超过两次的 Skill，值得保留；装了两周都没激活过的，大概率不需要。
可复现性 — 这个 Skill 能不能把一次成功的经验固化成标准流程？能固化流程的 Skill，价值会随时间累积；只能解决一次性问题的 Skill，用完就可以删了。
可衡量收益 — 有没有数据支撑这个 Skill 真的有效？比如人工审查轮次从 2.3 降到 1.4，低级问题减少 82%——这种数字比「感觉更好用了」更有说服力。
本质上，最值得保留的 Skill 是「解决问题的方法论」，而不是「操作步骤的说明书」。 前者能应对一类问题，后者只能机械重复一个动作。
技能管理的本质，不是「拥有最多工具」，而是「用最少的工具稳定地解决问题」。
在 OpenCode 的生态里，Skill 是扩展能力边界的好东西，但它本质上是手段，不是目的。你不需要成为 Skill 收藏家，你需要的是一套顺手的工作流。
上个月我删掉了自己一半的 Skill，不是它们不够好，是它们不适合我现在的方向。删完之后，OpenCode 用起来反而更顺了——因为留下来的每一个，都是我真正在用的。
建议你也抽个时间停下来想想：装了一堆 Skill，有多少是你真正需要的？适合你的，才是真正有效的。
你在用 OpenCode 吗？装了多少个 Skill？有没有哪个是装了之后发现并不适合你的？评论区聊聊。
说实话我就是被这个问题逼得才开始整理 Skill 库的。装了十几二十个，每次找命令比写代码还费时间，后来发现问题不在于 Skill 少，是我没想过哪些真正值得保留
「Skill 是长出来的」这个认知对我帮助最大。之前一直在找别人的好东西装，后来改成先裸跑几天，等重复问题暴露了再针对性造 Skill，反而用得更顺手
按需加载工具我也试过，最明显的变化是 AI 响应速度快了。之前全局加载十几个 Skill，每次对话开头都要等它加载半天，现在只在需要的时候调进来，体验好很多
建议先从审计开始，每周花10分钟过一遍 Skill 列表，把装了两周都没用过的先删掉或移到按需加载，过一个月你会发现留下的才是真正在用的
💬 评论区