模型人人都能用，什么才是你能带走的？我的答案是一个可进化的Skill库

你花几十小时调教出来的AI工作流，换个工具就没了？这篇文章聊聊怎么把它变成可积累、跨平台、能自我进化的资产。

故事是这样的。

前阵子我换了台电脑，新机器到手，兴冲冲打开Claude Code，准备继续干活。

然后我愣住了。

之前花了大半个月调教出来的commit规则没了，写中文文章的去AI味prompt没了，PR创建流程的那套逻辑也没了。我坐在那，盯着一个干干净净的编辑器，感觉自己像个刚入职的新人。

那一刻我突然意识到一个事儿，我之前所有「教AI」的努力，全部依附在某台机器、某个工具、某个项目的配置文件里。它们不属于我。

这个感觉太操蛋了。

说真的，AI时代有一个挺残酷的现实，谁也无法保证你明天还在这家公司。

团队在缩编，岗位在重组。你今天在A公司用Cursor写代码，明天可能在B公司用Claude Code，后天可能自己出来单干用Codex CLI。在这种不确定性下，什么是你真正能带走的？

公司的代码仓库？那是公司的。项目里的.cursor/rules？那是项目的。你在某个AI工具里积累的对话历史？换个工具就没了。你脑子里「怎么让AI高效干活」的经验？能带走，但不固化下来，它会慢慢模糊、过时。

唯一真正属于你的，是你把这些经验结构化、版本化、存在自己仓库里的那部分。

我做SumSec-Skills的出发点就是这个。不管明天在哪家公司、用什么工具、做什么项目，我的Agent技能库跟着我走。它是我的，不是任何公司的，不是任何平台的。

模型能力是公共基础设施，人人都能调用同一个Claude、同一个GPT。但你如何使用它，你的工作流、你的质量标准、你踩过的坑，这些才是别人复制不了的东西。

前提是，你得把它们存下来。

回到我自己的经历。

你有没有发现，你在重复「教」AI？

我举几个我自己踩过的场景。在Cursor里写了一套commit规则，换到Claude Code又得重新写一遍。花了半小时教AI「写中文文章不要有AI味」，下次新对话又从头来。在A项目里调教好了PR创建流程，B项目里又得重新解释。

你在做重复劳动。而且是一种特别隐蔽的重复劳动，每次「教AI」的过程感觉像在工作，但你其实在重复造轮子。

SumSec-Skills要解决的就是这个。教一次，到处用，永远不丢。

很多朋友可能会说，那我把常用的prompt存到一个文件里不就行了？

不够。

坦率的讲，一段prompt是「告诉AI做什么」。一个Skill是「定义AI在某个场景下应该怎么思考、怎么决策、怎么行动」。两者的区别，看个例子就明白了。

拿SumSec-Skills里的git-commit-pr举例。它不是一句「帮我写好commit message」，而是一整套行为规范。

先看这个仓库最近30条提交，学习它的风格，不是套模板。检查有没有.env、密钥之类的敏感文件，有就停下来问我。如果我在main分支上，先建议我新建功能分支，别直接往主干提交。生成commit message时，优先跟随仓库已有风格，其次才用通用规范。推送前检查远程状态，推送失败有降级方案。创建PR时优先用gh CLI，不行就给我一个链接。

每一条规则背后都是踩过的坑。这不是一段prompt能表达的，是一个经过实战打磨的决策流程。

SumSec-Skills里的每个Skill都长这样。

Skill = 结构化的行为规范 + 参考资料 + 辅助脚本

它有入口文件SKILL.md，有深度参考references/，有可执行工具scripts/。不是一段文字，是一个完整的能力包。

顺着上面的再聊聊，为什么要按领域分成多个Plugin。

SumSec-Skills目前有20多个技能，分成了四个独立的Plugin。但这不是终态，随着技能不断积累，分类会持续增长。分几个类、怎么分，完全取决于你自己。

当前的四个Plugin是按我的使用场景自然长出来的。

writing-zh，中文写作辅助，写文章、做内容的人用。media-tools，图片视频生成，做多媒体内容的人用。dev-tools，开发者日常工具，写代码的人用。agents-dev，Agent开发生态，开发AI插件的人用。

未来可能会有security-tools、data-analysis、infra-ops。。。只要某个领域的技能积累到3-5个，就值得独立成一个Plugin。这是一个会生长的结构，不是一个固定的四格抽屉。

关键问题是，为什么要分？为什么不把所有技能堆在一个大目录里？

我自己的感受是，原因有四个。

第一个，AI的「注意力」是有限的。

AI Agent的上下文窗口就像人的工作记忆，能同时关注的东西有上限。你挂载的每一个Skill，它的描述都会占用Agent的「注意力」。如果你把所有Skill全部加载，Agent每次收到你的指令，都要在几十个选项里判断「这次该用哪个」。这不仅浪费token，还会增加误触发的概率。你说「帮我提交代码」，Agent可能在git-commit-pr和creating-blog-web-ppt之间犹豫，因为后者也涉及「创建」这个动词。

分类Plugin的好处，你只装你当前需要的那几个。Agent只在少数高度相关的Skill里做判断，又快又准。技能库从20个增长到50个、100个时，这个优势会越来越明显。

第二个，不同领域的更新节奏不同。

写作技能可能每周都在调整，因为你对「去AI味」的标准在不断提高。但git-commit-pr可能几个月都不用动，因为Git工作流相对稳定。如果所有技能捆绑在一起，每次更新写作技能都要「发布」整个包。分开之后，writing-zh可以频繁迭代，dev-tools保持稳定，互不干扰。

第三个，按需安装 = 尊重用户。

不是每个人都需要你所有的技能。一个前端开发者不需要「Remotion视频最佳实践」，一个内容运营不需要「Agent SDK开发」。让用户选择他们需要的，而不是强塞一整包。

第四个，分类即认知。

当你在marketplace里浏览时，Plugin的名字就告诉你它是干什么的。3秒做出选择。如果几十个技能混在一起叫「SumSec-Skills」，你得逐个读描述才能判断。当技能库增长到50、100个时，没有分类就是灾难。

你想想看，这就像npm的@scope。你不会把Angular所有模块打成一个包。按职责拆分，是包管理的基本功。Agent Skills也一样。

说到这个，我必须聊一个我自己感触特别深的东西。多平台分发。

现在AI Agent工具有多少？Claude Code、Cursor、Codex CLI、OpenClaw、OpenCode、Hermes。。。还在不断冒出新的。

如果你的技能只能在一个平台上用，你就被锁定了。

今天你用Cursor很顺手，明天Claude Code出了个杀手级功能你想切过去，结果发现所有的rules和skills都得重写。这种锁定效应，在工具快速迭代的当下，是个真实的风险。

SumSec-Skills的做法是，核心内容只写一份，外面包一层平台适配。

SumSec-Skills/
├── dev-tools/skills/git-commit-pr/SKILL.md  ← 核心内容，只有一份
├── .claude-plugin/plugin.json               ← Claude Code适配
├── .cursor-plugin/plugin.json               ← Cursor适配
├── .codex-plugin/plugin.json                ← Codex CLI适配
├── .agents/plugins/marketplace.json         ← Codex marketplace
├── openclaw.plugin.json                     ← OpenClaw适配
├── opencode/plugins/sumsec-skills.mjs       ← OpenCode适配
└── hermes/skills/sumsec-skills/SKILL.md     ← Hermes适配

每个平台有自己的manifest格式，但它们指向的是同一批SKILL.md。版本号统一管理，一次bump全部对齐。

你的技能资产属于你，不属于任何平台。

这话听着有点像口号，但我是真的觉得这件事很重要。我见过太多人被工具锁定了，换个平台就像搬家一样痛苦。而我现在，不管用什么工具，打开就能用，因为我的技能库是独立的。

回到技能本身这块，怎么保证它们不过时？

AI Agent平台的规范在快速演进。技能库如果是一座孤岛，很快就会和官方脱节。

SumSec-Skills用Git Submodules解决这个问题，把官方仓库直接「嵌入」到自己的仓库里。

一条命令，拉取官方最新设计。

git submodule update --remote

Anthropic更新了Skill规范？新增了frontmatter字段？调整了加载机制？不用去翻changelog，不用猜「官方现在推荐怎么写」，直接看claude-plugins-official/目录里的最新代码。

我跟你说一个真实的例子。早期的Claude Code Skill只支持name和description两个字段。但官方后来陆续加入了一系列精细化控制。

disable-model-invocation，禁止AI自动调用，只能用户手动触发。user-invocable: false，纯背景知识，不暴露为命令。allowed-tools，预批准安全工具，减少确认弹窗。context: fork，用子Agent执行，隔离上下文。argument-hint，支持用户直接传参。

每个新字段都解决一个具体的痛点。如果你不跟踪官方，你可能还在用最原始的方式写Skill。能跑，但远没有用上平台的全部能力。

这就像1880年代电力开始在美国普及的时候，很多工厂主花大价钱买了发电机和电动机，装在自己的工厂里。但装完之后，很多人发现生产效率并没有显著提升。因为他们只是用电动机替代了蒸汽机，但整个工厂的布局、流程、管理方式都没有变。

那些真正吃到电力红利的人，是最早想明白电力到底意味着什么的那波人。

AI也是一样。现在这个阶段，其实就挺像1880年。你不跟踪上游的演进，你就永远在用蒸汽机的思路开电动机。

分层架构的设计是这样的。官方是地基，个人是建筑。

┌─────────────────────────────────────────────┐
│        个人定制层（你自己维护）                  │
│                                             │
│  git-commit-pr    humanizer-zh              │
│  skill-optimizer  multi-platform-guide      │
│  agent-chat-history ...                     │
├─────────────────────────────────────────────┤
│        官方基座层（submodule自动同步）           │
│                                             │
│  claude-plugins-official (Anthropic)        │
│  context7 (Upstash)                         │
└─────────────────────────────────────────────┘

官方更新不会覆盖你的定制，两层分离。随时对照官方diff，看看改了什么，再决定要不要跟进。

不是自己造轮子，是站在官方肩膀上加自己的理解。

说到进化这块，这套东西真的能「进化」吗？

有了集中管理，你能做一件之前做不到的事。系统性地优化你的技能。

SumSec-Skills里有一个叫skill-optimizer的技能，专门审计其他技能。它会扫描所有Skill，检查结构质量。分析历史对话记录，看哪些被触发了、哪些从来没用过。从八个维度打分。给出P0/P1/P2优先级的改进建议。

用AI优化AI。这是集中管理才能做到的事。

prompt散落各处的时候，你甚至不知道自己有多少条规则，更别说分析效果了。集中到一个仓库之后，每次优化都有记录。

git log --oneline skills/git-commit-pr/
# a1b2c3d 加入敏感文件检测
# d4e5f6g 优化commit message风格学习逻辑
# h7i8j9k 初始版本

你能清楚地看到一个Skill怎么从「能用」变成「好用」的。这种感觉太爽了，就像看着自己养的植物一点点长大。

怎么说呢，聊到这里，我想把整个设计哲学用一句话说清楚。

把Skill本身「渐进式加载、按需使用」的设计原则，复制到了仓库层面。

一个好的Skill内部是这样工作的。AI先读SKILL.md的入口描述，判断是否相关。相关了才读正文。正文里引用了references/才按需加载深度内容。不是一股脑全塞进上下文，而是层层递进、用多少加载多少。

SumSec-Skills的仓库架构，把同样的逻辑放大到了整个技能库。

层级1  Marketplace → 用户看到4个Plugin的描述，判断需要哪个
层级2  Plugin     → 安装后，Agent只看到该Plugin下2-5个Skill的description
层级3  Skill      → 匹配到了，才读SKILL.md正文
层级4  References → 正文引用了，才加载深度参考和脚本

每一层都是一道过滤器。从仓库到Plugin到Skill到Reference，信息量逐层收窄，上下文占用逐层递减。

刻意为之。

在此基础上，三条支撑原则。

按领域分Plugin，独立演进。不同领域的技能有不同的更新节奏、不同的受众。分开管理让它们各自生长，互不干扰。

开放系统，跟踪上游。通过submodule嵌入官方仓库，让个人定制永远站在最新规范之上。不是封闭造轮子，是「官方是地基，个人是建筑」。

一次编写，多处分发。核心内容只维护一份SKILL.md，外层用各平台的manifest包装。版本号统一管理，不被任何单一工具锁定。

如果你想开始，其实不需要一上来就搭建完整架构。

第一步，找到你的重复模式。回顾过去一周，哪些指令你对AI说了3次以上？哪些流程每次都要重新解释？这些就是你的第一批Skill候选。

第二步，写第一个SKILL.md。不用完美，先把你最常用的那个流程写下来，放在AI工具能识别的位置。验证它确实能省事。

第三步，分类整理。当你有了3-5个Skill，开始按领域分组。这时候建一个独立仓库就有意义了。

第四步，多平台适配。当你在多个AI工具间切换，加上对应的manifest文件。一次投入，长期受益。

说实话我也不确定这套方法适合所有人。可能有些人觉得「我就用一个工具，不需要这么折腾」。这完全合理。但如果你跟我一样，经常在不同工具间切换，经常换项目换团队，那这个投入的回报率会非常高。

我们正处在一个有趣的时间点。AI Agent的能力在快速提升，但「如何让AI按你的方式工作」这件事，还没有成熟的工程实践。

SumSec-Skills的尝试指向一个方向。

Agent Skills应该像代码库一样被管理，有版本、有发布流程、有上游依赖追踪。

当每个开发者都有自己的Skills仓库，当这些仓库通过submodule与官方保持同步、通过fork在社区间流动、通过marketplace被发现和安装，我们可能会看到一个新的生态。

不是「谁的AI模型更强」，而是「谁的AI技能库更深」。

模型能力是公共基础设施，官方规范是共享的地基。你如何在上面构建，你的工作流、你的质量标准、你的决策偏好，这些才是真正属于你的东西。

想想就觉得兴奋。

仓库地址，github.com/SummerSec/SumSec-Skills

许可证，Apache-2.0，自由使用、修改、分发。

以上，既然看到这里了，如果觉得不错，随手点个赞、在看、转发三连吧，如果想第一时间收到推送，也可以给我个星标⭐～

谢谢你看我的文章，我们，下次再见。

/ 作者：SummerSec