1. 为什么skills突然成了 AI 开发圈的热词先说个我自己的场景。去年我在一个前端项目里做代码审查每天都要给 Claude Code 粘贴同一套编码规范、组件评审清单、可访问性检查项。这些重复说明占掉的上下文比实际要审查的代码还多。最离谱的一次审查一个十几行的改动光背景说明就消耗了大半上下文窗口模型反而该查的没查该提醒的没提醒。后来 Anthropic 把 skills 概念带入 Claude Code我才意识到问题不在模型而在我们用了错误的方式传递知识。把整段操作说明塞进对话和给模型一个可检索、可复用的技能包这是两件完全不同的事。再往后Codex 跟进、社区出现 superpower skills、吴恩达专门出了 agent skills 教程连数学建模、专利写作、内容创作这些非编程领域都开始讨论skills 推荐这个热度不是营销能炒出来的是真实的效率差逼出来的。这篇东西我想认真聊透一件事skills 到底是什么、它和 prompt 的本质区别在哪、你自己怎么从零写一个、以及在 Claude Code / Codex 这些工具里到底怎么落地。你不用是 AI 研究员只要平时用 AI 辅助写代码、写方案、做分析这篇文章里的东西就能直接拿去用。2. 从 prompt 到 skill底层机制到底改了什么2.1 上下文不再是草稿纸而是分层书架我们过去用 prompt 的方式本质上是把所有信息一次性塞进上下文。问题是上下文窗口再大也是有限的塞进去的重复信息越多模型真正用于推理的空间就越少。我做个不太严谨但好懂的类比prompt 像是你每次进图书馆都背着一整箱资料skill 则是给你一张借书卡——你需要什么再去哪一层、哪个书架、抽哪本书。skills 的核心机制叫progressive disclosure渐进式披露。一个 skill 的表现形式通常是这样的my-skill/ ├── SKILL.md # 技能说明书模型先读这个 ├── scripts/ # 可执行的本地脚本可选 └── references/ # 参考资料按需读取可选模型不是一上来就把 references 里所有内容都读进上下文而是先读 SKILL.md 的开头索引遇到具体环节再展开对应章节。这个设计看着简单但它解决的是 Agent 类工具最要命的问题上下文污染。2.2 description 是开关不是装饰SKILL.md 的头部是一段 YAML frontmatter最关键的两个字段是name和description。很多第一次写 skill 的人不重视 description随便写一句This skill helps with coding结果模型永远不触发它写得太泛又会在无关任务上乱触发。description 承担的任务是路由。当你在对话里提出帮我审查一下这段代码有没有安全问题模型会扫描所有可用 skill 的 description做一次语义匹配再决定调不调用。所以好的 description 应该包含三类信息动词开头明确触发动作比如审查生成分析优化场景列举什么情况下用写清楚具体场景负向条件什么情况下不要用避免误触发我用一个前后对比的例子说明# 错误写法 name: code-review description: Code review best practices. # 正确写法 name: code-review description: 当用户要求审查代码、检查 PR、评估变更质量或发现潜在 bug 时使用。 不适用于纯粹的代码生成、重构或格式化任务。那个错误写法我一开始就踩过写了best practices这种抽象词模型根本不知道什么时候该用。改成场景化描述之后基本每次提出审查需求都会触发效果立刻不一样。2.3 脚本让 skill 从文本建议变成可执行工具纯文字的 skill 再详细本质上还是建议。而带scripts/目录的 skill 等于有了手和脚——它可以调用本地命令、解析文件、跑测试、统计结果。这是 skill 和 prompt 之间最实质的分界线。一个带脚本的 skill 在 SKILL.md 里会这样指示模型## Execution 1. 分析用户提供的代码文件列表 2. 运行 python scripts/check_security.py target_file 3. 将脚本输出与下方常见问题清单交叉比对 4. 输出审查报告标记严重程度模型本身不擅长精确的算法计算和规则匹配但它擅长理解意图、编排流程、解释结果。脚本负责算得准模型负责决定算什么和怎么解读这个分工比让模型硬记规则高效得多。3. 手写第一个自己的 skill从目录结构到调试验收3.1 目录与 SKILL.md 骨架技能不是越复杂越好。我强烈建议第一个 skill 选一个你每周都会做、但每次都要费口舌解释的任务。我拿一个很常见的场景举例前端组件代码审查。先建目录frontend-review/ ├── SKILL.md ├── scripts/ │ └── check_a11y.py └── references/ └── checklist.mdSKILL.md 的完整骨架--- name: frontend-review description: 当用户要求审查前端组件、React/Vue 代码、检查可访问性或评估 UI 实现质量时使用。 不适用于后端逻辑审查或数据库设计评审。 --- # Frontend Code Review Skill 对用户提供的前端代码进行结构化审查输出包含严重程度分级的问题清单。 ## 审查流程 1. 理解组件职责读取 references/checklist.md 中的审查清单 2. 逐条检查可访问性、响应式、命名、状态管理、性能隐患 3. 涉及 ARIA 属性和焦点管理时运行 scripts/check_a11y.py 辅助判断 4. 按 P0/P1/P2 输出问题清单 ## 关键规则 - 每个问题必须给出具体代码位置 - P0 只用于影响用户核心操作或造成数据丢失的问题 - 拿不准的问题标为 P2 并在备注中说明原因 ## Verification - 问题清单中每条是否都有文件与行号 - 是否遗漏了可访问性检查项 - 结论是否区分了事实与推测这个例子看起来简单但每个段落都有目的。checklist.md是详细规则不要写进主文件脚本帮模型做它不擅长的静态检查Verification 段落让模型在输出前自检这是后面要重点讲的防烂技巧。3.2 安装方式与触发测试skill 装在哪里取决于你用的工具。以 Claude Code 为例把frontend-review文件夹放进项目的.claude/skills/目录或者用户级目录~/.claude/skills/重启会话就会自动被发现。用 Codex 的话对应目录是~/.codex/skills/或项目内的.codex/skills/。社区里的 skill 大多通过命令安装比如这类形式的指令npx skills add 作者/技能名 --agent claude-code -g -y-g表示安装到全局用户目录-y是跳过交互确认。如果你拿到的是源码包也可以手动把整个目录拷到对应 skills 文件夹本质是一样的——skill 就是文件夹文件到位就等于安装完成。装完之后立刻做一次触发测试开一个全新会话避免旧上下文干扰用接近你 description 写法的一句话提需求帮我审查一下这个 Button 组件的可访问性观察模型是否加载了 skill——通常在日志里能看到 Using skill: frontend-review再用一个不应该触发的需求测试边界帮我写一个上传组件——如果也触发了说明 description 的负向条件没写够3.3 迭代skill 是活的文档不是一次性交付写 skill 最忌讳的是一口气写完就再也不动。我第一次写的 review skill 实际用了两周改了四个版本刚开始漏掉了对useEffect依赖项的分析后来在常见遗漏里补了一条一开始 P0 定义太松模型动不动把样式问题标成 P0我加了具体说明才收敛住。我的经验是把每一轮使用中模型做得明显不对的地方记下来回到 SKILL.md 里补规则。skill 本质上是你和模型之间不断演进的操作协议它跟代码一样需要维护。一个月没更新的 skill基本就退化成了普通 prompt。4. 生态盘点Claude Code、Codex、superpower skills 到底怎么选现在社区里讨论 skills绕不开几个名字。我花了些时间把主流方案都过了一遍直接给一张对比表方案适用工具特点适合谁Claude Code skillsClaude Code / Claude 系官方原生支持生态最成熟npx skills add安装主力用 Claude Code 的开发者Codex skillsOpenAI Codex强调 Agent 自主执行与 ChatGPT 系工具集成用 Codex CLI 做自动化任务的人superpower skills多工具社区项目包含上百个现成技能包覆盖开发、写作、分析想快速拿来主义、丰富技能库的人agent skills概念/框架层吴恩达等团队提出的技能设计方法论教你如何结构化想自己设计复杂技能体系的人opencode skillsopencode CLI开源 CLI 方案格式相对自由喜欢开源工具链的玩家4.1 怎么选看你的主力工具而不是看热门选型逻辑其实很简单你的主力 Agent 工具是什么就用它支持的原生 skills 方案。我是 Claude Code 的重度用户所以主要维护.claude/skills/下的技能。虽然社区里也有一套技能全工具通用的说法但实际操作中不同工具的技能加载机制、上下文策略、脚本权限都不一样强行通用只会两头不讨好。如果你刚入门我的建议是先装一个社区现成的技能包观察结构——superpower skills 就很适合当学习材料它的技能覆盖广、写法规范你可以直接翻它某个技能的 SKILL.md比自己从零摸索快得多。但要提醒一句别一次装一百个技能。技能越多模型每次扫描 description 的负担越重反而可能拖慢响应、增加误触发。我见过有人装了几十个 skills结果模型在无关任务上频繁乱调用。质量永远大于数量。4.2 skills 会取代 prompt 吗热搜词里有一条rethinking skills and prompts这个话题圈内讨论很热。我的判断是不会取代但分工会更明确。prompt 依然适合一次性的、极强的上下文关联任务——比如你要针对一个具体文件做深度分析所有背景都在这个文件里直接对话反而最高效。skill 适合的是反复出现的、流程固定的、知识可沉淀的任务。它俩解决的是不同问题一个靠临场发挥一个靠平时积累。5. 实战中踩过的坑skill 不是 prompt 的换皮这三处最致命5.1 description 写不好skill 永远不触发前面提过我的 review 技能一开始用了Code review best practices这种描述。那段时间我反复测试发现模型经常不调用它。起初我还以为是工具 bug后来把日志打开一看模型确实扫描了所有 skill但判断用户的请求和这个 description 匹配度不够高。排查链路是这样的检查日志确认 skill 有没有进入候选列表——进了说明文件加载没问题检查 description发现太抽象缺少触发场景——这是根因改成场景化描述加入审查代码检查 PR评估变更质量等具体表达再测试触发率明显提升这个坑的原理是模型的 skill 路由本质上是一次语义匹配。你写best practices它无法从中推断出用户说帮我看看这段代码有没有问题时就该用这个。description 是写给路由系统看的不是写给人类看的——要用具体场景喂它。5.2 过度堆细节把 skill 变成了第二个 prompt和 description 写太少相反的坑是把 SKILL.md 当成大杂烩什么规则都往里塞。我见过有人写了一个 3000 行的 skill把团队所有编码规范都复制进去了。后果是模型加载慢、执行时反而遗漏关键步骤——信息太多和太少同样致命。正确做法是分层存放。主文件只保留流程骨架和决策要点细枝末节的规则放进 references/ 按需读取。还有一个技巧与其写必须检查 XSS、CSRF、注入……不如写运行 scripts/security_check.py 并分析输出。规则会过时代码会维护但僵化的长文本只会让模型越用越迟钝。5.3 没有验证回路skill 越用越烂skill 是给模型用的操作手册但它本身也是代码需要测试。我最开始写 skill 时没加 Verification 段落结果模型经常输出一份看似完整、实则漏掉关键检查项的审查报告。问题不在模型偷懒而在于我的 skill 没有给它一个自检清单。加了这样一段之后效果立竿见影## Verification - 每个结论是否都有具体的文件与行号引用 - 可访问性检查ARIA、键盘导航、对比度是否已覆盖 - 是否明确区分了确定的问题与推测的问题模型是很好的执行者但它需要明确的质量标准。Verification 段落就是质量标准。没有这个回路skill 的输出质量全靠模型临场发挥有了它每次执行都带一层质量过滤。我甚至会把上一轮发现的失败案例摘要写进 SKILL.md 的常见错误小节让模型避开自己之前踩过的坑。6. 把 skills 用到具体领域数学建模、前端、内容创作怎么落地skills 的价值不止在写代码。热搜词里数学建模 skills前端开发 skills微信公众号文章 skills这些说明各个领域的人都在做自己的技能包。我挑几个典型领域说说怎么设计。6.1 数学建模 skills把解题流程固化成四个子技能数模竞赛时间紧、流程固定、每个环节都有方法论特别适合 skills。我推荐的拆法是四个技能包problem-analysis读题、提取约束条件、识别模型类型优化/预测/评价model-selection根据问题特征推荐算法并给出适用性和局限性说明sensitivity-analysis参数扰动分析、边界条件检验、结果稳健性评估paper-writing论文结构、图表规范、公式排版、摘要提炼每个子技能负责一个阶段比一个大而全的数学建模技能更容易被精准触发。写这类 skill 的关键是把你在训练和比赛中积累的判断直觉转成显式规则。比如 model-selection 的 description 可以写当用户面对一个预测类问题且数据量小于 500 条时优先考虑树模型而非深度学习。6.2 前端开发 skills把审查和规范沉淀成团队资产前端技能的落地场景很丰富。除了前面写的组件审查还可以做样式规范检查设计令牌、命名规范、响应式断点性能审查包体积分析、渲染性能、懒加载策略迁移辅助从类组件迁移到函数组件时的检查清单团队场景下skills 有一个额外价值它是可版本管理、可评审的知识库。以前新同事问我们项目的代码规范是什么你只能甩一个几十页的文档现在可以直接让他装上团队技能模型会自动按规范审查他的代码。这比任何培训文档都管用。6.3 内容创作 skills把自媒体工作流变成半自动流水线微信公众号写作看起来和技能不搭其实流程化程度很高。选题→收集素材→搭框架→写初稿→打磨标题→配图→发布检查每一步都有固定套路。一个完整的自媒体创作 skill 可以包含选题库记录你的领域关键词和爆款特征自动生成选题清单结构模板开头抓注意力、正文递进、结尾行动号召标题打磨提供多种标题风格的改写发布自检错别字、敏感词、格式、引流话术合规性我认识的内容创作者用这种方式把一篇公众号文章的初稿时间从三小时压缩到了四十分钟。这里要提醒一句内容创作 skill 产出的是素材和初稿最终发布前的判断和修改还是得靠人——技能替代的是重复劳动不是创造力和判断力。6.4 专利写作与安全测试高门槛领域的技能设计思路专利写作是另一个我见过比较成功的 skill 应用。它的难点在于权利要求书的撰写——结构严谨、术语精确、层级分明。一个专利写作 skill 可以内置权利要求结构模板独立权利要求从属权利要求、技术特征拆解方法、说明书各部分写作要点、常见审查意见的应对策略。核心价值是让模型在正确框架下输出而不是天马行空自由发挥。安全测试领域的技能设计我特别想多说一句合规边界。技能包可以涵盖资产盘点、测试范围界定、漏洞报告模板、复测记录管理这些流程性内容但我强烈不建议去收集任何漏洞利用速查表类的技能——那不是提升效率是在制造风险。正规的授权安全测试核心价值在于流程规范和报告质量不是攻击技巧的堆砌。合规是底线这个底线不因为用了新工具就松动。写在最后我的四个经验讲到这里核心内容基本说完了。最后分享几条我实际用下来的体会第一从一个高频痛点的 skill 开始。我见过太多人一上来就想建一个全能技能体系结果维护了三天就放弃了。挑一个你每周都在做、每次都嫌烦的任务先做出一个能用的比规划十个完美的要强。第二skill 的维护成本是真实存在的。它不是写完就完的东西工具升级、场景变化、模型行为变化都会让旧技能失效。我现在的习惯是每个月抽半天把所有 skill 过一遍删掉没用的更新过时的。第三观察模型的日志。Claude Code 这类工具都支持查看模型每一步的调用记录你会清楚地看到它什么时候调用了哪个 skill、为什么调用。这是调 description 第一手资料比瞎试有效得多。第四skills 最大的价值不是省时间是沉淀方法论。一个写得很好的 skill是你个人或团队经验的结构化表达。它让你每次做同类任务时都能站在自己最好的水平上出发而不是凭当天的心情和状态。技能的边界会随工具演进不断变化但把经验结构化、把流程自动化这个方向短期之内不会变。希望这篇东西能给你一个清晰的起点。