夜雨聆风Skill 越来越多，不代表你的 Agent 越来越强。
很多人装着装着，系统里堆了一堆名字很猛的能力，真正每天会用的没几个。
问题不在于 Skill 不够多，恰恰在于太多了。
你以为自己在升级，结果只是把系统越装越重，把决策越装越乱。
我最近重新过了一遍一份 80 个 OpenClaw Skills 清单。
看完最大的感受不是兴奋，而是冷静。
这里面当然有好东西。
但也有不少条目，一眼看过去就知道：
- 名字比能力大
- 包装比价值重
- 看着很强，真进工作流却很少用
- 还有一些，已经该合并、降级，甚至直接替换了
所以这篇文章我不想做“大全”。
我只想做一件更有用的事：
帮你把这 80 个 Skills 重新筛一遍，挑出真正值得长期留下的，顺手把那些虚胖的、过时的、重复的，清出去。
先说结论：真正值得长期保留的，不会超过 20 个
这不是说剩下的都没用。
而是一个 Skill 值不值得留，判断标准从来不是“它能不能做事”，而是：
它能不能稳定进入你的真实工作流。
如果一个 Skill 只是偶尔演示时看起来很强，平时却几乎不会点开，那它就不是核心能力。
顶多算库存。
我更愿意把 Skill 分成三层。
第一层：应该长期保留的
这些是你真的会反复用到的。
第二层：有用，但别高估
这些能帮忙，但不是核心。
第三层：该合并、改名，甚至淘汰的
这些问题最多，不处理反而会拖累整个系统。
第一层：我认为真正值得长期保留的 Skills
1. 搜索与研究类，真正该留下的是这 5 个
如果一个 Agent 连信息入口都不稳，后面的总结、判断、写作都会跟着跑偏。
所以搜索研究类一定要留，但不用留一大把。
我更推荐下面这几个：
tavily-searchbrave-searchsummarizefact-checkerarxiv-search
为什么是它们？
因为这几类能力边界清楚，也真的能补到工作流的缺口。
比如：
tavily-search适合做 AI 优化搜索brave-search适合做干净一点的网页检索summarize能把 URL、PDF、视频、长内容压成可读摘要fact-checker能给信息真伪多一层交叉验证arxiv-search对论文和技术研究确实有用
这几个留下，已经够撑起“查资料—提取—校验”这一条主链路。
至于那种一口气堆很多搜索引擎的写法，看起来丰富，实际很容易变成重复建设。
2. 文案与营销类，不要贪多，留这 4 个就够了
这一类最容易虚胖。
因为很多名字拆开看像独立技能，合起来看其实只是同一件事的不同包装。
我更建议留下这几个：
copywritingsocial-contentseo-writerscript-writer
理由很简单。
它们对应的是四种真实产出：
- 普通文案优化
- 社媒平台内容生成
- 搜索场景优化
- 视频/播客脚本生成
这已经够覆盖大多数内容生产需求。
反过来，有些条目就没必要单独存在。
比如：
hashtag-generatortone-adjusterbrand-story
这些不是完全没价值。
而是更适合并进主技能里，做成子能力，而不是单独挂一个 Skill 名字。
不然你表面上看是工具变多了，实际只是菜单变得更乱。
3. 设计与体验类，最值得留的是“真能出图和真能补结构”的
这类 Skill 也很容易被花名字带偏。
真正值得留的，不是“听起来很设计总监”的，而是你能马上拿去生产内容的。
我会留：
nano-banana-prodiagram-generatoraccessibility-auditor
其中最能打的，是 nano-banana-pro。
它直接对应封面、插图、海报这些高频需求，价值非常直接。
diagram-generator 也值得留，因为流程图、架构图、思维导图，本来就是很多知识类内容的刚需。
accessibility-auditor 看起来没那么“炸”，但它属于那种平时不炫、真做产品和页面时却很有用的技能。
反而像 ui-ux-pro-max 这种名字，我会很警惕。
不是说它一定没用，而是这种命名本身就暴露了一个问题：
它更像包装词，不像稳定能力。
如果真要留，最好改成更克制一点的名字，比如：
ui-auditorux-reviewprototype-assistant
这样别人一看就知道它到底干什么。
4. 文档与办公类，是最不该删的一类
这一类通常不花哨，但非常实用。
我建议稳稳保留：
pdfdocxxlsxpptx
原因不复杂。
只要你在真实工作里处理文档、表格、汇报、材料整理，这四个入口就很难绕开。
它们不一定最性感。
但属于你每周都可能碰到的能力。
这种 Skill 才是真核心。
5. 多媒体类，真正该留的是“能把非文字内容转成文字资产”的
我会优先保留：
openai-whispervideo-summarizersubtitle-generatorimage-to-text
这些能力有一个共同点：
它们不是在“装饰”工作流，而是在把音频、视频、图片里的信息，重新变回可以检索、可以总结、可以二次加工的文字。
这一步非常值钱。
因为 Agent 最擅长处理的，还是文本。
谁能把非文本内容更顺手地转回文本，谁就更容易把整条链路打通。
6. 通讯与协作类，不用全留，但要留真正能形成入口的
我倾向保留：
Slackdiscord-botcalendar-syncchat-summarytranslation-bot
这几类能力的价值在于：
它们不是内容花活，而是工作入口。
消息、日程、总结、跨语言协作，这些都属于高频真实场景。
但像有些更泛的协作名字，比如：
team-taskdocument-collab
我就会打个问号。
因为它们描述得太大了，大到读完名字，你还是不知道它到底解决了什么具体问题。
名字一虚，能力边界往往也跟着虚。
7. 知识管理类，真正值得留的是“能形成长期积累”的
这一组我会保留：
obsidianNotionself-improving-agentweb-clipper
其中我最看重的，其实是 self-improving-agent。
因为很多 Skill 解决的是“多做一件事”，而这个 Skill 解决的是“下次别再犯同样的错”。
这类能力平时不显山露水，但越用越值钱。
它更像一个系统会不会越用越聪明的分水岭。
第二层：有用，但别高估
这一层最容易让人误判。
因为它们通常不是没用，而是没你想的那么核心。
1. baoyu-article-illustrator
这个 Skill 方向是对的。
它不是写文章，而是给文章系统性配图。
所以它适合做“长文升级模块”，不适合被写成“人人都该先装的主技能”。
如果你文章已经成型，它很有价值。
如果你还在解决起稿、改稿、发布这些更前面的环节，它就不是最先该上的东西。
2. template-library
模板库当然方便。
但模板更像素材，不太像真正的能力。
你可以保留它，但别把它当核心 Skill 去宣传。
3. skill-creator
这个很有价值，但它更像“造工具的工具”。
适合进阶用户，不适合拿来当大多数人的主入口。
4. skill-vetter
这个也很重要。
尤其是社区 Skill 越来越多以后，安全审查会越来越关键。
但它属于“守门员”，不是日常高频产出型 Skill。
所以它很重要，却不一定很高频。
第三层：这批 Skill，我会建议改名、合并，甚至直接替换
这部分是最值得动刀的。
因为真正拖累系统的，往往不是能力不够，而是菜单里虚胖的东西太多。
1. free-ride
这个名字问题最大。
它会让整个 Skill 显得很不稳，也很像临时绕路方案。
如果它本质上做的是模型路由和低成本 fallback，那就老老实实改成：
budget-model-routerfallback-model-routeropenrouter-lite
一改名，可信度立刻就上来了。
2. Humanizer
这个名字也不太好。
因为它很容易让人联想到“把 AI 文本伪装成人写的”。
这类表达现在越来越敏感。
如果它真正做的是润色、降模板感、调自然度，那更适合换成：
style-naturalizerrewrite-naturaltone-refiner
3. ui-ux-pro-max
这个名字太像噱头。
能力再强，也不该叫成这样。
建议直接换。
4. hashtag-generator
建议并入 social-content。
单独拿出来，价值太薄。
5. tone-adjuster
建议并入 copywriting。
不必再单开一个入口。
6. brand-story
建议并入 copywriting 或 product-marketing。
因为它本质上还是品牌叙事，不值得长期独立占一个 Skill 位。
7. spotify
如果这是一个娱乐控制类接入，那就别在核心清单里占位置了。
它不是不能留，而是不该出现在“最值得推荐的 OpenClaw Skills”这一层。
一份 Skill 清单值不值钱，不看数量，看有没有“工作流意识”
这是我看完这份 80 条清单之后最大的感受。
很多人整理 Skill，习惯用“越全越好”的思路。
但系统不是超市。
Skill 也不是货架。
真正值钱的，不是你列出 80 个名字，而是你知不知道：
- 哪些是入口能力
- 哪些是生产能力
- 哪些是增强模块
- 哪些只是包装出来的幻觉
如果这层判断没有建立起来，Skill 越多，系统越重。
表面上看是能力在增长，实际是决策成本在上升。
如果让我重新给这份清单瘦身
我会把它压成三组。
第一组：必留核心能力
搜索、摘要、文档处理、出图、多媒体转文字、知识管理、通讯入口。
第二组：按需增强模块
配图系统、模板库、技能创建器、安全审查器。
第三组：合并或替换项
那些名字太虚、边界太糊、功能太薄、和别的 Skill 高度重叠的。
这样一来，整个 Skill 体系会立刻清爽很多。
而且更像一个能真的拿来干活的系统。
最后
我越来越觉得，判断一个 Agent 系统成不成熟，不是看它能挂多少 Skill。
而是看它有没有能力把“看起来很强”的东西清掉，只留下“真的会被反复使用”的那部分。
因为真正拉开差距的，从来不是菜单里有多少项。
而是你有没有把少数几个高价值能力，接进自己的真实工作流。
Skill 不是越多越强。
真正强的，是你知道哪些该留，哪些该删，哪些该重新命名。
