这周如果你关注 Agent 开发圈子，大概率被一个词刷过屏：Skill。
知乎上连着三天出现十几篇深度长文，GitHub 上相关仓库的 star 一天一个样，连看起来八竿子打不着的 Java 生态都开始原生接入，B 站也冒出「Agent Skills 从入门到实战」的教程。一个去年才由 Anthropic 提出的概念，为什么偏偏这周集中爆发？更实际的问题是：普通开发者现在跟不跟？怎么跟才不白忙？
我把这周知乎、小红书、B 站的讨论翻了一遍，给你捋清楚三件事：发生了什么、Skill 到底是个啥、以及上手前必须知道的三个坑。
这周发生了什么：Agent 的「App Store」正在拼齐
先说结论：这波热度不是某一条新闻炒起来的，而是生态在同一周里集中凑齐了几块拼图。
第一块是标准。Agent Skills 开放规范（agentskills.io）目前已经被 Claude Code、Cursor、Codex CLI、OpenCode 等约 30 款 Agent 产品读取，官方仓库 anthropics/skills 按社区本周统计已经攒下约 17 万 star。知乎社区里甚至已经有人开始给 Skills 排热榜，上榜第一的 obra/superpowers，就是一套把软件开发方法论整理成可复用技能的 Agentic Skills 框架。小红书也就是说，你写一份技能文件，不再只伺候一家工具。
第二块是内容。Google 工程师 Addy Osmani 把自己团队的工程规范做成了 24 个开源 Skill，覆盖需求、计划、构建、测试、审查、上线六个阶段，仓库已经 9 万+ star。知乎国内也有人拿这套思路做垂直场景：有研究者让 Agent 蒸馏专家报告和基金申请书，做出 NSFC Agent Skills 并开源，几个月就攒了 300 多 star。知乎
第三块是生态。Vercel 的 skills CLI 一条命令能把技能装进 70 多个 Agent。知乎Java 侧，Spring AI Alibaba 从 2 月发布的 1.1.2.0 版本开始原生支持 Agent Skills，和其他生态读的是同一份 SKILL.md，技能资产可以跨语言迁移。知乎还有全新长出来的工具：比如 open-slide，一个给 Agent 用的幻灯片框架，内置 /create-slide 技能，能自动规划结构并生成页面。小红书
第四块才是讨论本身。「Skill 和 MCP 到底什么区别」「为什么 Skill 没像 MCP 那样火」「大家都用 Skills 做出了什么」成了这周知乎的高频问题。有热度，也有真实分歧——这正是值得停下来看一眼的信号。
一句话概括：Agent 的能力，正在从「出厂焊死」变成「随时安装」。而装一个「应用」的成本，低到写一个 Markdown 文件。
先搞懂：Skill 不是 MCP，更不是长 Prompt
这周讨论里最大的误解，是把 Skill 当成「另一种 Tool」：有了 MCP，是不是就不需要 Skill 了？
不是。这两个东西看起来相似，实际上处于完全不同的抽象层。知乎记一句话就够了：MCP 解决「我能调用什么」，Skill 解决「我该怎么做」。打个比方：MCP 是 Agent 的手，Skill 是它的经验，模型是它的大脑。你让 Agent「分析这个 GitHub 项目，然后写篇技术文章」，MCP 负责让它够得着 GitHub、读得到代码；至于拿到代码以后先看什么、按什么结构分析、写成什么样——这是 Skill 管的。手再灵活，没有经验，干出来的活还是糙的。
Skill 也很容易和 Prompt 混。一段合格的 SKILL.md 是「YAML 头信息 + Markdown 正文」，正文里写的是步骤、检查点和退出条件，是一套可以反复执行的专业流程。知乎而 Prompt 往往只是一句「你是资深工程师，请帮我……」。前者是可复用资产，后者是一次性口头交代。社区有人总结得更细，把 Prompt、Tool、MCP、Skill、Agent 拆成五层，混层是新手最常见的翻车原因。知乎
如果还想再进一步，工程上有个好用的三分法：知识用 Skill，通道用 MCP，隔离用子 Agent。高危操作（比如发版）交给只挂了指定技能和最小权限工具的子 Agent，边界一下就清楚了。
为什么说它真的有用：两个具体案例
概念热不热是一回事，落不落地是另一回事。这周传播最广的两个案例，恰好回答了「Skill 能不能让 Agent 变强」。
一个是 Warp 的代码评审 Agent。首版提示词能搞定约 80% 的任务，但剩下两成低质量输出反复出现，工程师越用越烦。他们的解法不是继续加长 prompt，而是拆成两个 Skill：base skill 存执行规则，improver skill 专门观察人类反馈、汇总重复问题，然后提出一笔最小修改，以 PR 形式交给人审查，合入后下一轮自动继承。知乎每笔改动都有 diff、可质疑、可回滚，「自改进」更像普通软件维护，而不是黑箱。
这个量级也有参照：据 Anthropic 客户案例，Warp 内部累计跑过 1000 万次 Claude Code 会话，每周新增 40 万以上。知乎在这种使用强度下，「把翻车点写回技能」成了唯一可维护的改进方式。
另一个是前面提到的 24 个工程 Skill。最有意思的一个叫 anti-rationalization，专门盯着 Agent 找借口：「项目太简单不用写 spec」「测试回头再加」这类话术会被它当场拦住。知乎每个 Skill 结尾都要求拿出证据——测试过了、构建过了才算完，嘴上说「看起来对」不算数。
这两个案例指向同一件事：Skill 的价值不在「多」，而在把经验变成可版本化、可审查、能复利的资产。
上手前，先听三句泼冷水
热归热，这周的讨论里也埋着足够多的反面证据，直接抄作业之前先看这三条。
第一，技能包不是越多越强。社区共识是「少而准优于多而杂」。知乎堆几十个技能，Agent 反而不知道该听哪个，上下文也被撑爆。一个写得好的 Skill，正文只放流程主干和高频翻车点，大约 60 行以内，业内有「500 行红线」的默契；低频细节拆到 references 里，让 Agent 按需加载。知乎
第二，只写技能不写回反馈，等于只做了一半。Agent 第一次犯的可编码错误，如果只换来你一句口头抱怨，下次还会犯。真正增值的动作，是把反馈沉淀回技能文件。已经有人指出，现在大多数 Skill 要么是人拍脑袋写的，要么是拿几条成功/失败的执行轨迹硬总结的，「做过很多任务」不等于「经验被积累了」。知乎
第三，不是所有任务都值得上 Agent，更不值得为它写 Skill。麦肯锡最近一份在小红书流传的报告说得挺直白：低方差、高标准的任务用规则就行，高方差、低标准的才轮到 Agent。小红书把固定格式文案转成 JSON？正则表达式又快又准，非要上大模型就是滥用。先判断任务值不值得，再谈写不写技能。
还有一句诚实话：Skill 目前还没到 MCP 那种火爆程度，社区里相当一部分人还停在概念阶段，规范本身也在快速迭代。现在进场是早期用户，享受不到成熟期的省心——但也能在标准定型前把坑踩明白。
到底跟不跟：三个问题自测，一小时起步
要不要现在动手，问自己三个问题：
你有没有一类反复让 Agent 干、又反复要返工的活？
你是不是每次都得把同一套标准从头交代一遍？
你的工具链是不是 Claude Code、Cursor、Codex CLI 这类已支持 Skills 的产品（或者是准备接入的 Spring 技术栈）？
三个都是「是」，值得这周就开始；有两个「否」，先把这轮讨论收藏起来，不亏。
起步路径其实很轻，一小时足够：挑你返工最多的那类任务，写一个 SKILL.md——YAML 头里把 name 和 description 写好，description 里埋够触发关键词，Agent 靠它决定什么时候加载；正文只写流程主干和最容易翻车的点。知乎丢进 .claude/skills/ 目录，让 Agent 跑一次，把它翻车的地方记下来，写回文件。
第二个技能，永远等第一个被真实用过再说。有些 Agent 客户端已经做进了图形化的技能管理，一条 URL 导入、一键开启，门槛还在继续降低。小红书
接下来值得持续盯的信号：agentskills.io 规范的版本变动、你自己技术栈的框架接入进度、以及「反馈自动写回」这类工具什么时候成熟。这三件事任何一个有动静，都值得回来重估一遍。
这波爆发的本质，是 Agent 的「经验」第一次变成了可以安装、可以版本化、可以传给下一个 Agent 的资产。模型每周都在变强，那是厂商的事；你的标准和流程，只有写进 Skill，才开始变成你自己的事。
