AI惊叹号 - Agent Skills 全知道：一周涨星 1.2 万
11 月 2 日的 GitHub 周榜，前三名不是模型，是三个装满了“怎么干活”的文件夹。
引言：涨星的不是模型，是作业手册
11 月 2 日读到的 GitHub 周榜，16 个项目里有 13 个服务编码 Agent。前三名全是 Skill：pbakaus/impeccable 一周 +12,017 星，nutlope/hallmark +11,566 星，cloudflare/security-audit-skill +10,069 星。
这三个项目没有训模型，也没有发 API。它们只做了一件事：把一个文件夹写清楚，告诉 Agent 遇到某类任务时先做什么、后做什么、什么算做完。
一年前，大家比的是谁的跑分高。现在，同一个模型，装不装一套 Skill，产出的东西能差一个档次。这篇文章只回答一个问题：这套“作业手册”到底怎么起作用，以及它为什么会在一周里被这么多人抢着装。
一个 SKILL.md，凭什么改变 Agent 的行为？
先把结构说清楚。一个 Skill 就是一个目录，里面必须有一个 SKILL.md。文件开头是 YAML frontmatter，至少两项：name 和 description。
Agent 启动时，只会把每个 Skill 的 name 和 description 预加载进系统提示。这是第一层。它足够让模型判断“这个任务要不要用这个 Skill”，但还不足以让模型照着做。
当模型觉得相关，它会去读 SKILL.md 的正文。这是第二层，讲步骤、讲约束、讲什么情况该停下来。
正文里如果还有细节，就拆到同目录的 references/、scripts/、assets/ 里。模型按需打开。这是第三层，也是 Skill 能和“超长提示词”拉开差距的地方。
这套设计叫渐进披露。Anthropic 在 2025 年 10 月给出这套结构，12 月把它发布成开放标准，Claude Code、Claude.ai、Agent SDK 都按同一套目录约定读。
更关键的是第三层里的 scripts/。一个脚本可以被 Agent 直接执行，而不必先读进上下文。Anthropic 举的 PDF 例子很典型：填表这件事，模型自己生成 token 去填，又贵又容易错；写一个 Python 脚本读表单字段，模型只负责决定“什么时候调用”，剩下的交给确定性代码。
这就是 Skill 和“知识文档”的区别。文档告诉模型“有这么回事”，Skill 把“怎么做”连同可执行的检查一起交出去。
本周榜上还有一个极端案例：andrej-karpathy-skills 只有一个 CLAUDE.md 文件，总星数 228,000。一份写得足够具体的行为规范，本身就是稀缺品。
答案：Skill 改的不是模型权重，是模型在这个任务上的操作规程。它把“经验”从某个人的脑子里，变成模型每次都能读到、而且能执行的文件夹。
写进提示词和写进 Skill，差在哪？
最常见的误解是：Skill 就是一段更长的提示词。真是这样，它不会在一周里涨一万多星。
差别在加载时机。系统提示词是常驻的，每一轮对话都要占上下文。Skill 的正文是按需的，没触发就不进上下文。装 30 个 Skill，平时占的只是 30 条描述。
打个比方。假设每个 Skill 的描述平均 50 token，30 个就是 1,500 token。如果把 30 份正文（每份按 2,000 token 算）全塞进系统提示，常驻开销就是 60,000 token。差了 40 倍。这个数字是估算，但量级关系成立：常驻的规则越厚，留给任务本身的窗口越薄。
第二层差别是“可执行”。提示词只能请求模型“记得检查对比度”，Skill 可以直接带一个检查脚本，跑完把结果摔在模型面前。前者靠自觉，后者有返回值。
第三层差别是“可维护”。提示词改起来没有版本，谁在什么时候加了一句“别用紫色”，没人知道。Skill 是文件，能进 git，能 review，能回滚。
但 Skill 也有它自己的脆弱点：description 写不好，它就不会被触发；写得太宽，它会在所有任务里被触发。模型判断“要不要用”的依据，就是那几十个 token 的描述。
答案：提示词买的是“一直记得”，Skill 买的是“需要时查得到”。前者花的是每轮上下文，后者花的是触发准确率。
MCP 接过工具了，Skill 还管什么？
很多人把 Skill 和 MCP 当成竞品。其实它们管的是两件事。
MCP 管“能连到什么”。数据库、浏览器、工单系统、代码仓库，通过 MCP 暴露成工具，Agent 知道有哪些动作可以调。它解决的是接口和权限。
Skill 管“先做什么、后做什么、什么算做完”。它不提供新工具，它安排工具的使用顺序，定义中间产物，规定失败时怎么退。
Cloudflare 的 security-audit-skill 把这条界线画得很清楚。它只有六个阶段，但每个阶段都有交付物：
侦察阶段先画架构、标信任边界、列输入面，产出 architecture.md 和一份覆盖清单。狩猎阶段按清单派互相隔离的 Agent，再让一个“覆盖复核”去找漏掉的地方。候选验证阶段，每个疑似漏洞交给一个全新的 Agent，任务不是“再看看”，而是“证明它不存在”。之后才是结构化输出、记录复核、出报告。
这里没有一个是“新工具”。全是流程。发现者不能自己宣布“这是漏洞”，必须由没见过这段推理的另一个 Agent 来推翻。这套分工，和人类安全团队的双人复核是一个逻辑。
也正因为它是流程，才能累积。第二次运行会接着上一次的覆盖清单，补没查过的地方。工具不会记得上次查到哪，Skill 会。
答案：MCP 让 Agent 能敲门，Skill 决定它进门先看哪里、什么时候停、什么算查完。一个扩能力，一个管纪律。
三个霸榜项目，各自把什么装进文件夹？
本周前三名恰好代表三种完全不同的写法。把它们放在一张表里，比单独看 README 清楚得多。
| 项目 | 许可证 / 体量 | 核心资产 | 它拒绝什么 |
|---|---|---|---|
| impeccable | Apache-2.0 / 99,417 星 | 24 个设计命令 + 62 条不调用模型的确定性规则 | “再高级一点”这种没法验收的要求 |
| Hallmark | MIT / 44,950 星 | 50 套主题素材 + 755 张开放图片 + 8 个宽度检查 | 对比度不足、焦点态缺失、移动端错位、编造事实 |
| security-audit-skill | 56,442 星 | 6 阶段审计 + 11 个按攻击面分类的狩猎 prompt | 由发现者自己宣布“这是漏洞” |
impeccable 走的是“词表”路线。它给你 24 个词：bolder、quieter、polish、critique、audit。一个词对应一类改动。它真正值钱的是那 62 条规则——不调用模型，不需要 API key，跑起来就是确定性的。这意味着“AI 味”可以被复现地检测，而不是再请一个模型来主观评价。它更擅长改已有页面，最新版本 cli-v4.8.0 在 10 月 26 日发布。
Hallmark 走的是“生成器 + 硬底线”。它由 Together AI 开源，带 50 套主题和 755 张开放授权图片。页面生成完，要在 8 个宽度上跑一遍检查。对比度、焦点态、移动布局、有没有编造事实，都是底线。不过线，就不交付。
Cloudflare 走的是“流程 + 复核”。它不追求一次审完，而是把“找”和“证伪”拆给不同的 Agent。仓库说明里写得很直白：这个单仓库 Skill 后来演变成了覆盖全公司的多阶段漏洞发现系统，这里只是起点。
榜上还有两个信号。taste-skill 先研究 247 个精选网站，再定方向，最后自己截图、只修最前面的三个问题，最多三轮。README 直接写明：一次构建 30 到 45 分钟，烧几十万 token。claude-mem 则把每次工具调用压成一条观察记录，下次会话按索引注入，总星数已经超过 109,000。
答案：三种范式：用词表和规则管审美，用生成器和底线管交付，用阶段和复核管风险。共同点不是模型更强，而是都不允许模型自己说“我觉得可以了”。
几十万 token，钱花在文件还是调用上？
先把账算清楚：SKILL.md 本身是纯文本，几 KB，安装不要钱。贵的是它触发的模型调用。
不同 Skill 的烧钱方式完全不一样。
impeccable 的 62 条规则不调用模型，这部分几乎零成本。它贵在“改”的时候：模型要读页面、理解结构、生成改动。
Hallmark 贵在“看”。8 个宽度，每个宽度都要真实渲染、截图、检查。图进了上下文，就是视觉 token。宽度越多，账单越厚。
Cloudflare 贵在“人多”。6 个阶段，每个阶段可能派多个 Agent，而且验证阶段坚持用全新 Agent，不继承发现者的上下文。上下文是干净了，token 也得重新付一遍。它还有累积机制，第二次跑要接着上次的清单，长任务的成本是叠加的。
taste-skill 的 README 把话说得最明白：一次构建 30 到 45 分钟，几十万 token。它还要截图、自查、最多改三轮。
所以“装个 Skill”这件事，成本不在安装，在运行。Skill 更像一张可以把模型用量放大的乘法表：流程越完整、检查越多、复核越独立，乘数越大。
算账时看三个数：一次任务跑几轮、每轮读多少上下文、有没有开子 Agent。三个数里任意一个翻倍，账单就翻倍。Skill 文件本身不在账单上。
答案：便宜的是规则，贵的是“看一眼再改”。确定性检查越多越省，视觉复核和独立复核越多越贵。
什么流程值得写成 Skill？
不是所有经验都值得固化成文件。写之前先过一张表。
| 判断维度 | 写提示词 | 接 MCP | 写成 Skill |
|---|---|---|---|
| 会用几次 | 一次性的活 | 每次都要连外部系统 | 同一流程反复三次以上 |
| 有没有“做完”的标准 | 说不清 | 不负责 | 有明确验收项 |
| 需不需要确定性脚本 | 不需要 | 可能 | 需要，且脚本可复用 |
| 有没有已知失败模式 | 没有 | 不负责 | 有，且能写成检查项 |
| 维护成本 | 零 | 中 | 高，要版本化 |
三个问题就能做判断：这件事会不会重复三次以上？有没有一个别人能照着验的“做完”标准？有没有至少一个已知的坑需要防？三个都是“是”，才值得写。
反过来，只写“要仔细”“要专业”“要符合品牌调性”的 Skill，价值接近于零。模型本来就会说这些。Skill 的价值在于具体：先读哪个文件、跑哪个脚本、输出成什么结构、哪三种情况必须停下来问人。
claude-seo 是个好例子。它拆成 26 个子 Skill、19 个专用 Agent，一次完整审计 10 到 15 分钟。它甚至有一个检查项，专门评估页面被 Google AI Overviews、ChatGPT、Perplexity 引用的概率。这种颗粒度，靠一句提示词写不出来。
也别把 Skill 当子 Agent 用。Skill 不需要独立进程，核心就是一个 SKILL.md，轻；子 Agent 适合必须独立连外部系统、独立跑很久的任务，重。能用文件解决的，先别起进程。
答案：有检查表、有失败模式、会重复三次以上，才写成 Skill。只表达态度的，留在提示词里就够了。
Skill 装得越多，Agent 会更强还是更乱？
会先变乱。
第一层乱在触发。每个 Skill 的 description 都在争同一个注意力位。两个 Skill 都说自己管“前端设计”，模型只能猜。装得越多，误触发的概率越高，上下文里塞进来的无关正文也越多。
第二层乱在规则打架。本周榜上的三个设计 Skill，impeccable、Hallmark、taste-skill，各自有一套审美和底线。同时开，模型会在一堆互相矛盾的指令里摇摆。原文的建议很直接：同类只留一个，先在几个页面上跑，比较效果，再决定。
第三层乱在权限。Skill 里的脚本是用你的权限跑的。impeccable 的 live 模式会执行 package.json 里指定的校验脚本；Hallmark 的浏览器检查依赖 puppeteer-core 和本机 Chrome。来源不明的 Skill，安装前至少读一遍 SKILL.md 和 scripts/ 目录。
Anthropic 在文档里也提醒过：恶意 Skill 可以引导 Agent 泄露数据、执行非预期动作。这不是理论风险，Skill 的执行模型就是“模型决定什么时候跑你的代码”。
所以正确的姿势不是“多装”，是“少而准”。一个类别一个，装完先跑真实任务，看它有没有在该触发的时候触发、有没有在不该动的时候乱动。版本要 pin，来源要记，升级前看 diff。
答案：Skill 的收益来自“流程被固定”，成本来自“注意力被分割”。装十个不如把一个跑到稳定。
结语：先写那件最常返工的事
这一周 Skills 霸榜，不是因为模型突然不行了。恰恰相反，模型已经够强，强到“怎么做”比“会不会”更决定产出。
Skill 把这件事说穿了：把流程写成文件，把验收写成检查，把失败写成提醒。模型换一代，文件还在。
如果你今晚只想做一件事，别急着装榜上的十个。挑出团队这周返工最多的那件事，把步骤、检查项、失败案例写成一个 SKILL.md。先别追求 62 条规则，先写清楚一句话：什么算做完。