今天 GitHub Trending 翻车了，但翻的不是 AI，是 Skills 赛道

打开 9 月 1 号的 GitHub Trending，整页 AI 项目我数了一遍，11 条里 6 条围绕同一个东西：Agent Skills。

archify 是给 AI 加画图技能，OpenMAIC 是清华系的多 Agent 虚拟教室，scientific-agent-skills 喊"165 个科研技能 + 100 个数据库"，reverse-skill 是逆向工程的 AI 调度，patent-disclosure-skill 写中国专利交底书，ECC 把 Skills、Instincts、Memory、Security 做成 Agent 操作系统。

6 个项目，6 个角度，6 种 Skills。这不是巧合，是生态外溢。

但你要以为这是技术突破，那就错了。这是模式外溢。Claude Code 圈玩了大半年的 Skills 模式，被全 AI 圈集体抄走了。问题在于，所有人都在抄，没有人真正赚到钱。HN 上 Skills 相关 337 分的爆款是 3 月份一个写 Godot 游戏的小工具，OpenAI 和四家大厂 8 月份签了 agent 互通标准，agentskills.io 标准站 2025 年 12 月就开张了。标准在卷，钱包没卷。

这一篇我想掰开说说：Skills 赛道今天为什么集体爆，又为什么注定是个商业化真空。你不需要会写 Claude Code，只需要理解一个概念：渐进式披露。

一、不是技术突破，是模式外溢：今天这 6 个项目到底在卖什么

先把这 6 个项目一个个拆开看，你会发现它们卖的不是同一个东西，但是套着同一层皮。

archify，JavaScript，3.7 万 stars。给 AI Agent 加画架构图的技能，输出自包含 HTML 带动效，工程师写一句"帮我画个支付系统的时序图"直接出图。痛点是 mermaid 丑、PlantUML 难装、draw.io 要手点，archify 让 AI 把这件事干了。这是典型的"垂直场景包装技能"，一个 Skill 就解决一类问题。

archify 的核心不是它的图引擎，而是它的 Skill 描述写得好。"输入一段系统设计描述，输出带交互的架构图 HTML"这句话在 frontmatter 里非常精准，AI 一看就懂该加载这个 Skill。我自己的项目里见过太多 Skill 写得一塌糊涂的，描述长到 AI 读不完也记不住，最后等于不存在。archify 把这件事做对了，所以能火。

OpenMAIC，清华大学 THU-MAIC 团队出品，TypeScript，2.6 万 stars。多 Agent 虚拟教室，老师 Agent、学生 Agent、答题 Agent 同时跑，本质是把 Skills 模式套到教学场景。卖的是"沉浸式 AI 教育"，背后是清华背书。

OpenMAIC 跟其他多 Agent 框架不一样的地方是：它把 Skill 颗粒度做得非常细，一个教学环节就是一个 Skill。"提问"、"反驳"、"总结"、"追问"是四个不同的 Skill，AI 根据学生当前状态选哪个加载。这种颗粒度设计比 Cursor、Claude Code 的默认 Skill 都细。

scientific-agent-skills，Python，4 万 stars。号称"把任意 Agent 变成 AI 科学家"，165 个验证过的科研技能加 100 多个数据库，生信、化学、材料全覆盖。卖的是科研 Agent 模板库。

这个项目的真正卖点是"验证过"三个字。HF 上你搜 scientific skill 能搜出几百个，没验证过的跑出来结果随机。scientific-agent-skills 把每个 Skill 都跑过测试，附了 benchmark 数据，科研团队拿来就能用，不用自己调。这是 Skills 模式真正成熟才有的产品形态。早期 Skills 都是个人开发者凭经验写，今天 scientific-agent-skills 把它做成了有 QA 的工程化产物。

reverse-skill，PowerShell，3.3 万 stars。Claude Code/Kiro 上做逆向工程和渗透测试，AI 驱动调度工具链。这个 Skill 争议大，因为给安全研究员用了等于给黑产开了个口子。

但 reverse-skill 在技术上有意思的地方是：它演示了 Skill 怎么调度"危险工具"。逆向工程涉及一堆本地二进制（gdb、radare2、ghidra headless），普通 AI Agent 不会主动调这些工具。reverse-skill 的 Skill 描述里写清楚"在用户授权后调 gdb 二进制分析 ELF 文件"，AI 看了知道这是被允许的操作。这是 Skills 协议里"工具权限描述"第一次有清晰的工程实现。

patent-disclosure-skill，Python，6 千 stars，今天涨 573。中国专利场景的 Skill，自动挖专利点、写交底书、解读审查意见。这是中文圈第一个有规模的"垂直中文 Skills"。

中文 Skills 的痛点不只是语言，是术语体系。中国专利的"交底书"、"审查意见"、"权利要求书"这些词在国外 Skill 库不存在，patent-disclosure-skill 把这套术语体系打包成 Skill，让 Claude Code 在中国专利场景下能写出像样的交底书。这是 Skills 生态在中国本土化的第一步。

ECC，JavaScript，24.5 万 stars，最猛的一个。把 Skills、Instincts、Memory、Security、Research-Driven Development 五个层次做成"Agent 操作系统"，覆盖 Claude Code、Codex、Cursor。ECC 本质是把 Skills 从"插件"升级到"Agent 框架"。

ECC 的野心最大但争议也最大。它声称要做 Agent OS，但 Skills 协议不是它定义的，加载机制是 Claude Code 提供的。ECC 实际上是在 Skills 之上加了一层自己的抽象。Instincts 是 ECC 提的新概念，指 Agent 不依赖显式 prompt 就该有的行为模式，比如"不要在生产库 DROP TABLE"。Memory 是会话间持久化的记忆层。Security 是 Skills 调外部工具的权限沙箱。Research-Driven Development 是 ECC 自创的工作流，让 Agent 先做调研再写代码。

这套抽象层级比 Skills 协议复杂得多。我的判断是：ECC 想做的事 Anthropic 早晚自己做（事实上 Claude Code 已经在做 Memory），ECC 最大的风险是它的抽象层被官方收编，然后变成 Claude Code 的子集。24.5 万 stars 给了 ECC 足够大的势能，但能不能撑过 12 个月的标准化浪潮，要看它能不能在 Skills 协议 v2 里争到一席之地。

你看完会发现一件事：6 个项目里，5 个是"垂直场景包装"，1 个是"操作系统"。前者占多数，后者野心最大。但它们都挂在同一个钩子上，那就是 Claude Code 提出来的 Skills 模式。

这就是我说的"模式外溢"。一个原本属于 Claude Code 圈子的玩法，被全 AI 圈认出来这是个好模式，然后每个赛道都来抄一遍。

二、Skills 到底是什么：渐进式披露，工程师最容易踩的 3 个坑

很多人以为 Skills 是"prompt 模板集合"，这是错的。Skills 的本质是渐进式披露（progressive disclosure）。Simon Willison 2025 年 12 月在 HN 上一句话讲清楚了：Agent Skills 不是什么神秘概念，就是渐进式披露模式的一个包装。

什么叫渐进式披露？我拿一个真实场景给你讲。

我去年写 Claude Code 项目的时候，第一个痛点是：每次开新会话，Claude 都问我"这个项目用什么框架、什么测试命令、什么部署流程"。每次都要重新讲一遍。我最早的做法是把所有项目背景塞到 CLAUDE.md 里，结果发现一个问题，上下文 token 撑爆了。一个 200K token 的会话窗口，光项目背景就吃掉 80K，剩下的对话空间只剩 60K。

第二个痛点是：有些工具（比如 git rebase、docker exec）我 90% 的场景下不需要，10% 的场景下必须用。我没法把所有工具的详细用法都塞 prompt 里，会话一开始就跑了一半预算。

第三个痛点是：团队成员写 prompt 水平参差不齐，有人写得巨长，有人只写一句"帮我修 bug"，AI 表现天差地别。

这三个痛点 Claude Code 用一个东西解决了：Skills。

一个 Skill 是一个文件夹，里面有 SKILL.md（一段自然语言指令）加可选的资源文件（脚本、模板、参考资料）。Skill 的特点是你写完之后，AI 不是一上来就读全，而是按需加载。Claude Code 的 Skills 协议规定了一个 frontmatter，AI 根据任务描述判断要不要加载这个 Skill，加载之后才把 SKILL.md 内容塞进 prompt。

这就是渐进式披露：90% 的会话里，大部分 Skill 不进 prompt；10% 的会话里，相关 Skill 按需加载。

听起来很美好对吧？真用起来有三个坑，踩过的人都知道。

坑 1：Skill 数量爆炸导致 token 预算失控。我自己的项目里塞了 30 多个 Skill，结果发现 AI 在每个会话开始时，会扫描所有 Skill 的 frontmatter（名字加描述），这本身就是 token 开销。30 个 Skill 扫描一遍大概吃 3K 到 5K token。如果不节制，Skills 系统本身就会撑爆你的上下文窗口。

更糟的是，frontmatter 里 description 写得越长，扫描开销越大。我见过有人写 200 字的 Skill description，比 SKILL.md 主体内容还长。结果是：Skill 加载判断还没做完，token 已经花掉一半。这种 Skill 实际是负资产。

坑 2：Skill 加载顺序打架。这是真踩过的。我有两个 Skill 都跟 git 操作相关，一个叫 git-workflow，一个叫 git-advanced，结果 AI 在某些场景下同时加载了两个，prompt 里出现两套互相矛盾的 git 指令，AI 直接懵了。Skills 协议目前没有"优先级"和"互斥"机制，全靠你自己写描述区分。

我的解决办法是：把所有 git 相关 Skill 合并成一个，叫 git-master，里面分章节"基础工作流"、"高级回退"、"冲突解决"。但这违反了 Skills 设计的颗粒度原则（一个 Skill 一个职责）。这是 Skills 协议的真实张力：颗粒度细了会冲突，颗粒度粗了又失去渐进式披露的意义。

坑 3：Skill 跟系统 prompt 抢位置。Claude Code 的 Skills 加载位置在系统 prompt 之后、用户消息之前。如果你的 Skill 写得太啰嗦，会把用户的实际请求挤下去，AI 开始"过度执行 Skill 描述"。比如你的 Skill 说"先做 A 再做 B"，结果用户问的是 D，AI 也要把 A、B 跑一遍才肯回答 D。

这个问题没有好的工程解，只能靠写 Skill 时自律：每个 Skill 开头写一句"如果不相关，跳过本 Skill"，AI 会更倾向于忽略不相关的 Skill。但这违反了 Claude Code 官方推荐的最佳实践（开头写明 Skill 是什么、什么时候用）。

这三个坑今天 Trending 上的 6 个项目都没解。archify 解决画图但没解决 token，OpenMAIC 解决多 Agent 但没解决冲突，ECC 解决操作系统但没解决加载顺序。本质上大家都还在用同一套 Skills 协议，而这个协议的下一个版本还没出来。

三、Skills vs MCP vs Sub-agent：三个概念为什么打不起来又离不开

知乎和 HN 上经常有人问：Skills 和 MCP 到底什么关系？是不是同一个东西？到底应该用哪个？

我从工程视角给你一个干净的拆解。

Skills 解决的是"AI 知道怎么干活"的问题。比如怎么写 git commit message、怎么写单元测试、怎么画时序图，本质是工作流知识。

Skills 是声明式的，你写一个 Skill，AI 知道"哦，这种情况下该这么做"。Skills 不直接调外部工具，它教 AI 怎么调用工具。Skills 是"知识层"。

MCP（Model Context Protocol）解决的是"AI 能调什么外部工具"的问题。比如能不能调你的数据库、能不能调 GitHub API、能不能调本地文件系统，本质是数据/工具接入。

MCP 是命令式的，你写一个 MCP server，AI 调用时拿到的是结构化数据。MCP 不教 AI 怎么思考，它给 AI 提供"原材料"。MCP 是"数据层"。

Sub-agent 解决的是"AI 怎么分工"的问题。把一个复杂任务拆给多个子 Agent，每个子 Agent 跑独立的上下文窗口，最后把结果汇总，本质是上下文隔离和并行执行。

Sub-agent 是结构式的，主 Agent 不直接干活，它把任务派给子 Agent。子 Agent 跑完把结果返回。Sub-agent 是"执行层"。

这三个东西不是替代关系，是组合关系。典型的工作流是这样的：

1. 一个主 Agent 接到任务"给我写一个 PR"
2. 主 Agent 加载 git-workflow Skill（知道怎么写 commit message）
3. 主 Agent 通过 MCP 调 GitHub API 拉 PR 模板
4. 主 Agent 起一个 sub-agent 去跑测试，另一个 sub-agent 去 lint 代码
5. 测试结果汇总，主 Agent 按 Skill 指导写 PR description

Skills、MCP、Sub-agent 三个加起来，才是"能干活的 AI"。

问题在于，今天 GitHub 上的 6 个 Skill 项目里，没有一个真正解决了"组合"问题。archify 只做 Skills（画图），ECC 声称做"Agent 操作系统"但只解决 Skills 这一层，MCP 那一层用的是别人的协议。OpenMAIC 看起来在做组合（多 Agent），但它的多 Agent 是"虚拟教室"语境下的，不是工程语境下的，组合方式不一样。

这是个真问题。如果你今天想做一个生产级的 AI Agent 系统，你必须自己组装 Skills 加 MCP 加 Sub-agent 三件套，没有一个现成的开源方案给你。这恰好是 8 月份 OpenAI 和四家大厂签 agent 互通标准的真正动机：大家发现，单做 Skills 不够，单做 MCP 不够，必须打通。

我自己的项目里，组装三件套花了大概两个月。每个组件单独跑都没问题，组合起来互相打架。Skills 加载顺序跟 MCP 工具列表有冲突，Sub-agent 之间的 Skills 继承关系搞不清楚。这两个月踩的坑比 Skills 本身还多。

具体一个例子：我让 Sub-agent 跑测试，Sub-agent 自己加载了 testing-skill，这个 Skill 教 AI 怎么写测试报告。测试跑完后 Sub-agent 把报告交给主 Agent，主 Agent 加载 git-workflow Skill 生成 commit message。结果 commit message 引用了 Sub-agent 的测试报告，但 git-workflow Skill 不知道测试报告在哪，要 AI 自己找文件。AI 来回找了 3 轮才找到，token 烧了一堆。这种"Skill 上下文不传递"的问题，在三件套组合的场景下非常常见。

更糟的是 MCP。Sub-agent 通过 MCP 调 GitHub API 拿 PR 列表，主 Agent 通过 MCP 调 GitHub API 拿 PR 详情。两次 MCP 调用各自建立了连接，token 各自计费。如果合并成一个 MCP 调用，token 成本能省 40%。但 Skills 协议没规定"调用复用"机制，每个 Agent 各自调各自。

四、标准化暗战：从 agentskills.io 到 OpenAI + 4 巨头协议

2025 年 12 月，Simon Willison 在 HN 上转了一个链接：agentskills.io。

这个站点的核心是把 Skills 这个概念抽象成"开放标准"。SKILL.md 的格式、frontmatter 的字段、加载机制的协议，全部公开。站点的意图很明显：抢标准话语权。

agentskills.io 的关键设计是把 Skills 跟 AI Agent 框架解耦。一个 Skills 仓库应该能在 Claude Code、Codex、Cursor 上都能跑。SKILL.md 的 frontmatter 字段定义清晰（name、description、when_to_use、allowed_tools），AI 框架读到 frontmatter 决定怎么加载。

这个抽象层级跟 HTTP 协议很像：HTTP 不关心你是用 Apache 还是 Nginx，Skills 标准不关心你是用 Claude Code 还是 Cursor。

3 个月后，2026 年 3 月，agentskills.io 推出了"Cybersecurity Skills for AI Agents"标准。安全这个垂直场景的 Skills 开始有自己的规范。这个标准跟通用 Skills 标准的区别是增加了"permission_scope"字段，明确每个 Skill 能调哪些工具、访问哪些目录。这是 reverse-skill 那类危险 Skills 真正需要的。

2026 年 8 月 6 日，HN 上 24 分的爆料："OpenAI and four rivals just agreed on one standard for AI agents"。这条新闻在中文圈几乎没人讨论，但它比 Skills 赛道本身更重要。

四家大厂愿意坐下来签标准，说明三件事：

第一，Skills 赛道已经大到不能各自为战。今天 GitHub Trending 上 6 个 Skill 项目只是冰山一角，HF（抱抱脸）上还有几百个垂直 Skill 仓库，没人愿意看到 Anthropic 一家把 Skills 协议垄断。

第二，大厂想把"开放标准"做出来，反制模型厂的锁定。如果 Skills 协议开放，所有 Agent 框架（Claude Code、Codex、Cursor、Kiro、Gemini CLI）都能跑同一套 Skills，模型层就不那么重要了。你用 Claude 也好 GPT 也好，只要 Skill 通用，模型可以随时换。

第三，也是最微妙的。大厂对"Skills marketplace"的态度暧昧。标准签了，市场却没做。这是有意为之。一旦 marketplace 跑出来，赢家会拿走大部分利润；不跑 marketplace，大家都只贡献规范，谁也不亏。

这跟云计算早期的 IaaS 标准化战争是同一个剧本。Google 当年想做 A2A（Agent-to-Agent）协议，Apple 和 Microsoft 私下也在做类似的协议框架。8 月 6 号的协议签下来，等于把"Agent 互通"这件事从暗战变成明牌。下一步就看大厂愿不愿意把这套协议跟 Skills 标准合并。如果合并了，今天 GitHub 上 6 个 Skills 项目里 5 个都得重写 frontmatter。这是 Skills 赛道最大的不确定性。

五、商业化真空：为什么 Skills marketplace 全军覆没

标准化在卷，钱包没卷。这是 Skills 赛道最诡异的地方。

HN 上能搜到的 Skills marketplace 项目不少，我数了数，至少 5 个：

• Skly.ai：Skills marketplace，2026 年 3 月，1 分，几乎没人讨论。
• ClawHQ：Fleet management 加 skill marketplace，2026 年 2 月，1 分。
• SkillSandbox：Rust 写的 capability-based sandbox for skills，2026 年 2 月，1 分。
• Building an AI skill marketplace for GTM teams：2026 年 6 月，3 分。
• **AI Skills Marketplace: A New Digital Economy?**：2026 年 1 月，1 分。

5 个 marketplace，HN 总分加起来不到 10 分。

为什么 Skills marketplace 跑不出来？我从工程和商业两个视角分析。

工程视角：Skills 的交付比想象复杂。一个 Skill 不是一个 zip 包，它依赖 AI Agent 框架的具体实现。Claude Code 的 Skill 在 Codex 上不一定能跑，Codex 的 Skill 在 Cursor 上不一定能跑。今天没有任何一个 Skills marketplace 解决了"跨框架兼容"问题。每个 marketplace 都在赌单一框架（基本都是 Claude Code），赌输了就死。

更糟的是，Skills 的版本管理是个无解的难题。一个 Skill v1 在 Claude Code 上跑得好，升到 v2 改了 frontmatter 描述，AI 加载行为就变了。marketplace 上一个 Skill 可能有 10 个版本，哪个版本跟哪个 Agent 框架兼容，没人说清楚。装错版本就是车祸现场。

商业视角：Skills 的供给端过剩，需求端模糊。今天 GitHub 上你搜"claude-code skill"，能找到几百个 Skill 仓库，全是免费的。免费的供给端把付费的 marketplace 全部打死。需求端呢？企业用户想用 Skills 提效，但他们最关心的不是"哪个 Skill 好"，是"我的数据安不安全"、"Skill 出错谁负责"、"怎么审计"。这三件事 marketplace 都没解。

更关键的是，Skills 的边际成本极低。一个 Skill 写完之后，可以无限复制。这跟 SaaS 不同，SaaS 有服务器成本、运维成本；Skills 没有。供给端天然零成本，付费意愿天然为零。

这个死结在 npm、pip、VS Code 扩展市场都出现过，VS Code 扩展最后是微软自己下场做才跑出来的。Skills marketplace 要跑出来，必须有模型厂下场，Anthropic 或者 OpenAI 自己做 marketplace 才有可能活。

目前 Anthropic 在 Claude Code 里塞了 Skills 功能，没做 marketplace；OpenAI 在 Codex 里做了 plugin system，没做 marketplace。大厂都在观望。

谁先打破观望，谁拿走下一个 AI 时代的基础设施。这跟当年 AWS 做 S3、Stripe 做支付是一个量级的机会。问题是，没人愿意第一个开枪。

六、反常识洞察：Skills 赛道真正的护城河不是技能数量，是加载顺序策略

现在说今天的反常识。

很多人以为 Skills 赛道拼的是"谁的 Skill 多"，谁就是赢家。今天 Trending 上的 scientific-agent-skills 喊 165 个 Skill，ECC 喊 Skills 加 Instincts 加 Memory 加 Security 五件套，看上去数量就是竞争力。

错了。

Skills 赛道真正的护城河是加载顺序策略。

为什么这么说？因为 AI 的上下文窗口是有限的，token 是按输入计费的，Skill 加载是有顺序的。一个 Agent 系统里塞 100 个 Skill 没用。AI 不会每次会话都加载 100 个，它会根据任务描述选 3 到 5 个加载。谁控制加载顺序，谁就控制 AI 的行为。

这是 Skills 协议当前最大的空白：没有任何机制告诉你"该先加载哪个 Skill"。AI 自己猜。猜错了，要么加载了一堆无关 Skill 浪费 token，要么漏掉了关键 Skill 行为错乱。

我自己的项目里试过几种加载策略：

策略 1：所有 Skill 平等加载。最差。每个会话都吃满 token 预算，AI 表现稳定但成本爆炸。一个会话平均多花 2-3 倍 token 钱。

策略 2：按任务分类预加载。把 Skill 分成 frontend、backend、devops、testing 几组，根据用户任务关键词选组加载。中等。分类对了效率高，分错了 AI 表现崩盘。我自己的数据看下来，准确率大概 70%，剩下 30% 的任务加载错了 Skill。

策略 3：动态描述匹配。每个 Skill 写一段精确的"触发场景"描述，AI 根据用户消息匹配触发条件。最优。问题是"触发场景"描述怎么写、写多长，太短匹配不到，太长又占 token。这是个 fine-tuning 任务，没有银弹。

策略 4（实验）：Skill 优先级加互斥。给每个 Skill 打优先级，加载时按优先级排，冲突时互斥。理论上最优，工程上最难。优先级怎么定？互斥怎么判？没有标准答案。

我自己的项目最后用的是策略 2 加策略 3 的混合：先用任务分类做粗筛，再用动态描述做精排。准确率从 70% 提到 88%，token 成本降了 30%。这是个不小的优化，但写起来不优雅，每加一个 Skill 都要手动调一遍触发描述。

策略 5（实验）：工具驱动加载。这是最近半年才有人开始探索的方向。逻辑是反过来的：不靠 AI 根据用户消息猜该加载哪个 Skill，而是看 AI 这一轮准备调用什么工具，根据工具反推需要的 Skill。比如 AI 准备调 gh pr create，那必然要加载 git-workflow 和 pr-template 两个 Skill。这种方式避开了"AI 自己猜"的不确定性，但需要 MCP 工具和 Skills 之间建立映射关系，工程复杂度更高。

策略 5 现在还没有成熟的开源实现，但 Anthropic 内部已经在用类似机制（从官方仓库的 commit 记录能看出来）。等它正式发布，估计又是一波刷榜。

今天 Trending 上的项目几乎没有一个真正在解决加载顺序。ECC 在描述里提了"Skills、Instincts、Memory"，但没说加载顺序；scientific-agent-skills 列了 165 个 Skill 但没说怎么选；archify 专注画图，连加载顺序问题都不涉及。

这是 Skills 赛道下一个 12 个月的真正战场。谁先把"智能加载"做出来，谁就是下一个 Agent 框架的霸主。Anthropic、OpenAI、Google 三家都在偷偷做这件事，没人说。

这也是为什么我说"Skills 赛道拼的是工程细节"。一个 Skill 的加载策略好不好，比 100 个 Skill 多不多重要得多。

七、给普通读者的判断：你今天要不要学 Skills

写到这里，估计有读者想问：那我现在要不要学 Skills？

我的判断：要，但别学太多。

学一个 Claude Code 的 Skill 写法，半小时够了。SKILL.md 的格式、frontmatter 的字段、加载机制，这些是基础功，今天所有的 Skills 项目都跑这套协议。不学等于错过一个赛道。

但别陷进去。Skills 的工程复杂度没有外面传的那么高，本质就是会写 prompt 加会写 Markdown 加会用 Claude Code。网上那些 5000 一课的"AI Agent 工程师"培训，99% 是在卖焦虑。

真正值钱的不是会写 Skill，是会判断"什么任务该用 Skill，什么任务该用 MCP，什么任务该用 Sub-agent"。这个判断力靠踩坑，不靠上课。

另外一个判断：别押注 marketplace。今天 Skills marketplace 全部跑不出来，未来 12 个月大概率还是跑不出来。要做商业化，去做"Skills 加载顺序策略"或者"Skills 安全审计"，比做 marketplace 有戏。

最后一句话留给你：今天 GitHub Trending 6 个 Skill 项目集体爆，但你看到的不是 Skills 赛道的春天，是冬天前的最后一次集体刷榜。下一个 12 个月，这个赛道会死掉 90% 的项目，活下来的不是 Skill 多，是加载策略好的人。

这不是技术问题，是工程问题。工程问题，从来都是细节决定生死。

八、附：30 分钟写出你的第一个 Skill

我知道有人看完就想动手。我把最快路径写一遍，照着做能跑通。

第一步：装 Claude Code。需要 Claude Pro 或 Max 订阅，国内用 Max 性价比更高。装完之后 claude 命令行工具可用。

第二步：建 Skill 目录。在你的项目根目录新建 .claude/skills/my-first-skill/，然后建 SKILL.md 文件。Claude Code 默认从 .claude/skills/ 读所有 Skill。

第三步：写 frontmatter。SKILL.md 顶部写：

---
name: my-first-skill
description: 当用户询问 git 工作流相关问题时加载。教 AI 怎么写规范的 commit message 和分支命名。
---

description 字段是 Skills 加载的唯一依据，AI 根据它的字面意思判断要不要加载这个 Skill。写得越精准，加载准确率越高。我自己反复试出来的经验是：description 第一句话写明触发场景，第二句话写明能解决什么问题。控制在 60 字以内。

第四步：写主体。frontmatter 下面开始 SKILL.md 主体内容，告诉 AI 在加载这个 Skill 后该怎么做。比如：

## 触发场景
- 用户说"commit"、"提交代码"、"git commit"
- 用户说"创建分支"、"切分支"
- 用户说"merge"、"合并"

## 工作流
1. 检查当前分支是否符合命名规范（feat/fix/chore/docs/refactor 前缀）
2. 检查 commit message 格式（type(scope): subject 格式，subject 不超过 50 字）
3. 如果不规范，告诉用户怎么改

第五步：测试。重启 Claude Code 会话（Skills 加载是会话开始时一次性扫描）。输入"帮我提交一下当前的改动"。如果 AI 没加载你的 Skill，检查 description 是不是写得太抽象。如果加载了但表现不对，检查主体内容是不是写得不够具体。

第六步：调优。跑 10 个真实任务，记录 AI 的加载行为。加载错的任务把 description 改得更精准，加载漏的任务把 description 改得更宽泛。10 轮下来准确率能到 80% 以上。

踩坑提醒：description 不要超过 100 字。我见过有人写 300 字的 description，结果单是扫描这个 Skill 就吃 2K token。Claude Code 默认每个会话扫描所有 Skill 的 description 加起来不能超过某个阈值（具体数值没公布），写长了等于这个 Skill 永远被 AI 跳过。

写第一个 Skill 半小时够了。写完你会发现，Skills 没什么神秘的，就是把"我希望你这样做"用 AI 能读懂的方式写一遍。真正难的是怎么让 AI 在 100 个 Skill 里挑出对的几个，这部分就是加载顺序策略。

这也是今天我写这一篇的真正原因。