最近刷 Skill 相关的内容，体感挺分裂的。
一边是生态火得不像话。小红书上一条 Skill 合集帖，七千多赞、一万多收藏。小红书 B站上，手把手教用 Skill 的教程视频播放量冲到几十万。哔哩哔哩 公开时间线上，Agent Skills 由 Anthropic 在 2025 年 10 月 16 日首次发布。知乎 短短半年，「装 skill」已经成了流量密码。
另一边，深度用户社区的风向明显变了。五月有人问「Skill 不就是 prompt 吗，为啥被吹成这样」，七月出现了「Codex 用户集体弃用 Skills 是明智还是短视」，高赞反驳说，Skill 就是提前封装好的标准化操作流程，不封装就得每次全量复述一遍。知乎 就在两天前，「skill 对于未来的 agent 还需要吗」下面有个回答直接捅破了窗户纸：作者在新模型上线后删掉了 Superpowers、GSD 这类通用编排框架，而 OpenAI Codex、DeepSeek Harness 这些顶级项目的官方仓库，反而塞进了大量项目级 skill。知乎 所以「Skills 有没有用」已经是个伪问题，真正的问题是：哪些 skill 会被模型淘汰，哪些 skill 模型越强越值钱。想明白这一点，你要做的就不是继续囤，而是开始自己设计。这篇写给已经装过一些 skill、尝到过甜头、想自己动手写的人，Skill 是什么的科普就跳过了。
一、先搞懂游戏规则：Skill 是怎么被加载的
很多「不触发、没用、吃上下文」的问题，不是写得不好，而是设计没顺着加载机制来。物理上，一个 Skill 就是一个文件夹：一个必需的 SKILL.md，加上可选的 scripts/、references/ 目录，agent 启动时只会把它的元数据预加载进系统提示。Anthropic 这份元数据只有 name 和一条 description，一个 skill 大约只占 100 个 token；SKILL.md 正文要等任务命中才会被读进来，官方建议控制在 5000 token 以内；至于脚本和参考资料，用到哪个读哪个，用不到就是零开销。知乎 这笔经济账，直接决定了设计的三条常识。
description 不是简介，是路由条件，模型先看元数据决定要不要触发，命中之后才读正文。知乎写成「帮助处理文档」这种，基本永远不会被触发，得写清楚能做什么、对什么对象、在什么场景用、什么时候别用。
正文是昂贵的地皮。装的 skill 越多，命中时加载的正文越多，直接挤占任务本身的上下文，所以正文建议控制在 500 行以内，细节挪进 references/，每个引用文件写清楚「何时读取」。知乎
封装的不是知识，是执行策略。好 skill 不是把所有知识塞进一个长文档，而是把路由规则、边界条件、验证标准放在 agent 能及时拿到的位置。
二、生死线：通用 skill 和项目级 skill
回到两天前那个回答。作者起初始终觉得开发类 skill 大概都会慢慢消失，因为新模型自己的工程实践已经够完备，再跑一遍别人预设的流程反而碍事；但看完 OpenAI Codex 和 DeepSeek Harness 的仓库之后，他意识到 skill 要分两种：一种通用型，越通用越容易被下一代模型的原生能力覆盖；另一种项目型，模型再强也不可能凭空知道。知乎这个分野，直接决定了手里的存量 skill 哪些该删、哪些值得新写。
看两个样本。Codex 官方仓库的项目级 skill 基本围绕 PR 展开：codex-pr-body 负责把 PR 描述写清楚，babysit-pr 在 PR 创建后持续盯评审、CI 和合并状态，code-review 做总调度再拆出兼容性、变更规模等审查线；DeepSeek Harness 的仓库在类似的代码流程之外，还加了 dsh-doc-standards、dsh-find-simplifications 这类文档治理线，前者管文档规范，后者专门删 AI 写作里事无巨细的啰嗦内容。知乎 这些 skill 的共同点是：它们不再规定 agent 怎么工作，而是补充 agent 不可能知道的上下文，也就是你的项目验收标准、团队的评审习惯、仓库里的隐性规则。所以写 skill 之前，先回答三个问题：
这件事你是不是已经做过 3 次以上，而且每次流程基本一致？没做过 3 次先手动跑，别急着封装。
把你的项目、业务、个人偏好这些上下文拿掉，模型还能把它做好吗？能，就别写，模型原生能力够用；不能，才值得封装。
你能不能写清楚「做完」的判定标准？写不出来，封装出来的不是 skill，是模糊的愿望。
三个都通过，再谈怎么写。
三、最容易犯的错：把 Skill 写成大 Prompt
很多人的第一个 skill 是这么诞生的：打开空白的 SKILL.md，往里塞规则、流程、模板、注意事项、风格要求、异常处理，最后写成一个巨大的系统提示词。能跑，但跑不了多久。社区已经给这个问题做了归纳，今年 3 月谷歌 ADK 开发者一侧总结了五种最常用的 Skill 设计模式，核心观点值得背下来：别从目录结构出发，要从你想控制的失控出发。知乎
模式 | 解决哪种失控 | 典型场景 |
|---|---|---|
Tool Wrapper | 知识失控：处理某个技术栈时不守规范 | 团队 FastAPI / Terraform 规范，命中相关任务时加载对应规则 |
Generator | 输出失控：每次写出来的结构都不一样 | 周报、技术方案、API 文档，先固定模板再填充内容 |
Reviewer | 评估失控：审查意见含糊 | 代码评审、内容质检，给它检查清单和严重级别 |
Inversion | 输入失控：不问清楚就开工 | 设计方案、需求分析，先结构化访谈再动手 |
Pipeline | 顺序失控：跳步骤交付 | 绝对不能跳步的多步流程，每步带通过条件 |
几条实操的选型经验。团队有明确规范文档的，写成 Tool Wrapper：规范放 references/，SKILL.md 只负责「何时加载、按什么执行」，别把两百条规则全塞进主文件。受不了 AI 输出格式每次都变的，写成 Generator：模板放 assets/，风格指南放 references/，改格式换模板、改文风换指南，不用动主流程。
Reviewer 有个很实用的判据：如果一个任务能由人拿着检查清单完成，那它大概率能写成 Reviewer Skill，但记得强制输出行号、影响范围和修复建议，不然得到的都是「整体感觉不错，建议优化」。知乎 Inversion 容易用力过猛，一上来抛 12 个问题用户直接想关掉，正确做法是分阶段访谈，轻任务一次问 3 个，复杂任务逐题推进，底线是关键信息没问全之前不给最终方案。Pipeline 最重也最容易写假：只有 Step 1、2、3，没有阻塞条件和验收门槛，那不叫 Pipeline，叫编号列表。
还有一个「约束比教导好用」的底层原因：让大模型用 token 生成去做排序、格式化这类确定性计算，既贵又不稳定，脚本则是确定的。官方工程博客里的原话很直接：靠生成 token 给列表排序，比直接跑一个排序算法贵得多，而代码是确定性的，流程才能稳定、可复现。知乎 确定性环节能脚本化就放进 scripts/，比多写十条规则都稳。
四、四条红线，踩了白写
description 按黄金结构写：一句话核心功能 + 具体执行动作 + 触发关键词，模拟用户会怎么提需求，就把那些关键词写进去。知乎
资源路由写成强指令，别写弱建议。「可以参考 xxx」和「必须先读 xxx」，效果差的不是一点半点，大的引用文件还要在开头加一句摘要，帮模型判断要不要读。
验证是完成条件，不是附加项。会生成文件、改代码、查数据的 skill，不写验证步骤，agent 就会过早宣布完成；开发阶段最好维护一份 golden checklist，拿覆盖成功、失败、信息不足的真实案例跑一遍再上岗。
引入第三方 Skill 先看一遍再装。SKILL.md、脚本、资源文件都要过目，多余的权限、数据外传、prompt injection 风险都可能藏在里面，你交出去的是执行权限，不只是读一篇文档。知乎
五、接下来值得盯什么
Skill 规范在 2025 年 12 月 18 日开放为统一标准之后，生态只用了半年就走完了「安装期」。知乎 现在的状态可以用一句话概括：安装期的红利快吃完了，设计期的红利刚开始。合集帖依然几万收藏，说明大众还在进场；但深度用户的讨论重心，已经转向项目级 skill、设计模式和评测方法。三个信号值得持续盯：
顶级团队的项目级 skill 实践会不会被复制。Codex 和 DeepSeek Harness 是两个样本，看接下来有没有更多开源项目跟进自带项目级 skills。
模型原生工程能力的进化速度。它决定通用型 skill 的保质期，也决定你手里的存量 skill 什么时候该删。
Skill 评测和安全的工具化。现在评测基本靠手写 golden checklist，安全靠自觉，这两块迟早会被标准化。
最后一句话收尾：囤一百个 skill，像雇一百个临时工；写好一个 skill，像培养一个正式员工。2026 下半年拼的不是谁的 skill 库大，是谁先把自己的上下文封装起来。
