1. 从“一句咒语”到“一套技能”为什么Skills突然成了AI圈的热词最近 GitHub 上涌现出一大批以 skills 为后缀的仓库Claude 官方上线了 Agent SkillsCodex 的社区里也全是“好用的 skills 推荐”甚至不少前端开发、论文写作、分镜脚本创作的朋友都开始把自己常用的写作流程封装成 skill。我最早看到这个词的时候也愣了一下——这不就是 Prompt 吗怎么会值得这么大动静后来自己上手写了几个才意识到这东西和 Prompt 完全不是一回事。过去我们用 AI 辅助干活通常是把一段精心打磨的提示词贴进对话框。这段提示词只要够长、够具体模型就能给出不错的结果。但问题是每次都得重贴一遍换个工具就失效想分享给同事还得复制粘贴、来回调整格式。如果只是写一封邮件、改一段文案这倒也无所谓可一旦你要让 AI 稳定地产出某种固定结构的东西——比如一份符合团队规范的前端代码审查报告、一篇带严格章节格式的论文初稿、一套可重复执行的测试用例——单靠 Prompt 就显得力不从心了。Skills 要解决的正是这个场景。你可以把它理解成一个“可复用的技能包”里面除了那段唤醒 AI 能力的指令文本通常叫 SKILL.md还可以附带脚本、模板、参考文档、校验规则、示例输出。AI 在运行这个技能时不只是“听一句指令”而是会读取整个技能包、理解目标、按步骤执行、甚至调用外部工具来完成闭环。换句话说Prompt 是一句话Skill 是一整套操作手册加工具箱。这篇文章会把我这几周折腾 Skills 的完整过程分享出来从最基础的概念拆解到自己设计一个技能包的实操全流程再到怎么在 GitHub 上筛选靠谱现成的技能、如何在 Claude 和 Codex 这类环境里跑起来最后还有我踩过的坑和排查方法。无论你只是好奇、想试试看还是准备给团队沉淀一套属于自己的技能库这篇都能给你一个可以直接照做的参考。2. 动手之前先想明白Skills 的内部结构和底层逻辑2.1 一句话 Prompt 和结构化 Skill 的本质差异我见过很多初次接触 Skills 的人第一个反应都是这不就是把 Prompt 写进一个 Markdown 文件里吗这话对了一半但只对了一半。真正的技能包至少包含三个层次触发层、执行层、校验层。触发层解决的是“什么时候启用这个技能”。Claude 的 Agent Skills 里支持通过描述文字让模型在合适的时机自动匹配技能也可以由用户手动指定。Codex 的 skills 则更多依赖命令行调用来触发。这一层本质上是在做意图识别——模型看到当前任务后判断该不该把某个技能包加载进来。执行层是核心。它可以是纯文本指令也可以是脚本。比如我做的一个“Markdown 论文格式整理”技能纯指令部分告诉模型“识别文内引用的标注格式、统一图表编号规则、生成参考文献列表”脚本部分则是一个 Python 脚本负责检查所有章节标题是否连续、图片引用是否有对应文件存在。指令负责“想”脚本负责“算”两者协同才能保证输出不是模型信口开河。校验层很多人会忽略但恰恰是技能能不能稳定复用的关键。它定义了一组验收标准比如“生成的报告必须包含三部分”“代码审查列表不得少于十条”“所有参数必须在表格中列出”。模型在执行完技能后会对照这些标准自查一遍。这个设计让技能的输出质量不再依赖于模型当时的心情和上下文长度而是有了一个相对稳定的底线。2.2 Agent 为什么必须依赖 Skill而不是临时发挥想理解这层得先想清楚 Agent 的工作方式。一个 Agent 不是简单地把用户的提问和大模型之间的对话做一遍它需要拆解任务、规划步骤、调用工具、观察结果、再调整下一步。整个链路里模型每走一步都在消耗上下文窗口。如果所有知识和规则都靠对话里临时输入上下文很快就会被占满模型会“忘记”前面的要求输出质量断崖式下跌。Skill 的存在相当于把一部分“长期记忆”搬到了模型的外部。模型需要某个领域的规范时直接从技能包里读取而不是靠对话里那几千个 token 硬撑。我还记得第一次用 Codex 跑一个需要读取仓库内多个文件、逐一做 Code Review 的任务时如果不挂 Skills它到第三四个文件就开始漏掉规则挂了技能包之后每个文件的审查都严格按照同一套模板输出差距非常明显。2.3 典型场景差异前端开发、论文写作、分镜脚本的 Skills 各自长得什么样不同领域的技能包侧重点完全不同。前端开发的 skills 通常包含大量的规则型指令和脚本。我见过一个做得不错的 Code Review 技能SKILL.md 里明确列出了 JSX 结构检查点、Hooks 依赖项审查规则、样式命名规范还内置了一个可调用的 ESLint 配置生成器。它的校验层要求“每条问题必须给出文件路径、行号和建议修改方案”这就保证了输出不是泛泛而谈。论文写作类的技能又是另一个路子。这类技能几乎不依赖脚本但对指令写作要求极高。模型需要严格遵循学术写作的章节组织方式、引用格式和论证逻辑。最好的做法是给模型一个“范文”让它照着范文的段落节奏来组织新内容而不是抽象地告诉它“要有逻辑”。分镜脚本类的技能则介于两者之间指令部分强调镜头语言和节奏控制脚本部分往往是一个模板渲染器把模型生成的镜头描述自动转换成标准的分镜表格。老实说这类技能是目前社区里数量增加最快的类型之一因为短视频行业对分镜格式的标准化需求非常旺盛。2.4 命名和目录布局的隐藏学问别小看 SKILL.md 的目录布局。Claude 官方推荐的目录结构是.claude/skills/你的技能名/SKILL.mdCodex 则习惯用~/.codex/skills/。但真正影响运行效果的是 SKILL.md 内部的 frontmatter 元信息——就是文件开头那几行 YAML 块。这里的 name、description 字段不是摆设。description 写得越具体模型在自动匹配时就越精准。我见过有人写“帮助用户写代码”这种描述等于没写因为模型根本分辨不清该在什么时候启用它。我自己会这样写name: frontend-code-review description: 用于对 React/TypeScript 项目进行代码审查。当用户要求检查代码质量、指出潜在 bug、评估组件设计时自动启用此技能。适用于 .tsx/.ts 文件不适合 Python 或后端代码评审。description 里包含了触发场景的正面示例和反面示例模型做意图匹配的准确率一下子提升了很多。这个细节我花了整整两天才调明白后面会再详细展开。3. 从零开始写一个能用的 Skill以“前端代码审查”为例3.1 选场景、定边界第一步决定成败很多新手写 Skill 的第一个错误就是想把所有东西一股脑塞进去。我一开始也是这样想做一个“全栈开发助手”技能结果模型执行时既想管前端又想管后端哪个都做得不深。正确的做法是先划定边界。以我最终做出来的“前端代码审查”技能为例我给自己定了三条硬规矩只审查 React TypeScript 项目、只处理组件层和逻辑层问题、不涉及样式美观度讨论。边界一定SKILL.md 的内容组织就简单多了。选定场景之后第二步是明确输出格式。我当时参考了团队 Code Review 时常用的模板把输出定为四段式概览段落、关键问题列表、次要建议列表、值得肯定之处。为了让模型不跑偏我在技能包里直接放了一个输出示例文件并在 SKILL.md 中指定“输出格式必须严格参照 example-output.md”。3.2 编写 SKILL.md 的指令部分语气、结构、细节密度指令部分的写作质量直接决定技能的表现上限。我写了几版之后总结出一个经验不要试图教模型它已经会的东西只提供它可能不知道的约束和流程。拿我的前端审查技能举例我绝不会在技能里写“使用 ESLint 检查代码”因为模型本身就知道该看哪些方面。我会写的是项目特定的约束比如“组件文件名必须为 PascalCase”“状态管理统一使用 zustand不要引入 redux”“所有导出的函数需要附带 JSDoc 注释”。这些信息模型不可能凭空知道只有放进技能包才能起作用。另外很重要的一个技巧是分步骤。我在 SKILL.md 里明确写了一个执行流程第一步扫描整个 src 目录结构第二步逐个读取组件文件第三步检查状态管理和数据流第四步汇总输出报告。你可能会觉得模型本来就会按顺序来但实际上如果不强制它按步骤走它经常跳过中间步骤、直接跳到结论。分步骤执行是让技能表现稳定的关键手段。3.3 添加辅助脚本什么时候需要脚本怎么写才不容易坏脚本在技能包里的作用是做模型不擅长的事情精确匹配、批量扫描、正则替换。但注意脚本越复杂技能包的维护成本就越高也越容易在不同的运行环境里出问题。所以我的原则是能不用脚本就不用必须要用的时候尽量写成无依赖的标准 Python 3 脚本。我在这个前端审查技能里加了一个脚本功能很简单扫描项目里所有 .tsx 文件找出那些导出了多个组件的文件并打印出来。这个检查靠模型一个个翻文件很费 token用脚本则几秒钟就搞定。脚本的输出会被模型读取作为后续综合分析的材料。这里的关键是要让脚本的输出格式尽量结构化最好是一行一个文件路径加一个简单标记这样模型解析起来不费劲。写脚本时还有个容易忽略的问题路径处理。不同环境下项目根目录不一定一样所以脚本必须接受一个 base_path 参数而不能硬编码。我在脚本里用argparse接收路径参数这样模型调用时可以用自己的“当前工作目录”概念来填充兼容性会好很多。3.4 校验层让模型学会“自我检查”校验层是整个技能包里最容易被忽略、但也最能拉开技能水平差距的部分。我的做法是在 SKILL.md 的最后加一个“输出前检查清单”段落用强制性的语气列出三项自查要求报告是否包含全部四段结构、每条关键问题是否标注了文件路径和行号、是否有针对具体代码的建议而非泛泛而谈。这个设计非常有效。原因很简单模型在生成回复时会有一个隐式的“收尾”动作如果你在技能包末尾显式列出检查清单相当于把这个收尾动作变成了显式的执行步骤模型会更认真地去对照检查。我测试过加不加这一段的差异不加清单时报告经常漏掉文件路径加了清单之后基本能做到每条问题都有精确位置信息。3.5 完整目录结构和安装步骤最终这个技能包的目录是这样的frontend-code-review/ ├── SKILL.md ├── scripts/ │ └── find_multi_export_components.py ├── templates/ │ └── review-report-template.md └── examples/ └── example-output.md安装时在 Claude Code 环境里放进.claude/skills/frontend-code-review/在 Codex 里放进~/.codex/skills/frontend-code-review/然后重启会话就能生效。启动后输入“帮我审查一下 src/components 下面的组件代码”模型会自动匹配到这个技能并开始工作。我现在已经把这个技能用在了几个真实项目上每周节省的机械性 Review 时间大约一两个小时而且报告里提到的问题比我肉眼扫的更全面——尤其是那些跨文件的重复逻辑和自定义 Hook 依赖问题。4. 从 GitHub 到本地现成 skills 的筛选、安装与改造4.1 哪里有高质量的 skills 仓库怎么快速判断优劣GitHub 上现在有大量 skills 合集仓库质量参差不齐。我筛选的标准有三条更新时间、示例输出、维护者活跃度。更新时间看的是技能是否仍在维护示例输出看的是技能作者自己是否真的用这个技能跑过任务并贴出了效果——没有示例输出的技能包我基本不碰维护者活跃度则是看 Issues 里有没有人反馈问题以及作者有没有回复。找仓库的时候我习惯用几个前端词组去搜awesome claude skills、codex skills collection、agent skills registry。搜出来之后先看 README 里的目录列表挑那些描述写得具体、分类清晰的。我下载过一个叫“superpowers”的技能集里面包含了一批通用能力增强型的技能虽然部分技能和官方能力重叠但它们对 prompt 的组织方式给了我不少启发。4.2 安装现成 skills 之后必须做的三件事第一件事读一遍 SKILL.md 的 frontmatter。很多技能包的描述写得太宽泛安装后模型根本不会在合适时机触发它。你需要自己改 description让它更贴合你的使用习惯。比如我从社区下载的一个“数据库 SQL 生成”技能原本的描述是“帮助用户处理数据库相关任务”我改成了“当用户描述数据查询需求、需要生成 SQL 或解释执行计划时使用”触发准确率高了很多。第二件事测试它在真实项目里的表现。我会准备一个小的测试目录里面放几个典型的输入样例逐个跑一遍看输出是否符合预期的格式和质量。测试时注意记录模型需要多少次调用才能完成、有没有调用脚本失败的情况。第三件事按团队规范做二次修改。社区技能包通常是为了通用场景设计的不一定符合你的团队标准。比如有些审查类技能默认的代码风格是 StandardJS而我们团队用的是 ESLint Prettier 的 Airbnb 配置这时候就需要改 SKILL.md 里的规则描述。改完后重新测试确保新规则真的被模型执行了。4.3 版本管理与技能灰度发布如果你是在团队里推广 skills我强烈建议做一个简单的版本管理。最轻量的方案是直接把技能仓库纳入 Git 管理每次修改都提交一次然后在 SKILL.md 里加一行version: 1.2.0的元信息配合一个 CHANGELOG 记录变化内容。灰度发布的方式也很简单先在个人环境里用一周确认稳定后再让一名同事安装试用收集反馈迭代几个版本之后再同步到全组。这个流程看起来笨拙但能避免很多“推出去又收回来”的问题。我见过最惨的情况是一个团队直接共享了技能目录结果某次改动让技能完全失效全员的工作流当天直接中断。有了版本管理和灰度步骤这种风险就能控制在最小范围。5. 核心技能实操用 Codex 跑通一个“论文写作助手”的完整过程5.1 论文写作场景为什么特别适合用 Skills 来标准化论文写作大概是所有内容创作类任务里对结构统一性要求最高、但每位作者的习惯和格式差异又最大的场景。同一篇论文如果让不同的人用 AI 帮忙构建初稿出来的往往是三种完全不同的章节编排方式审阅起来非常痛苦。Skill 在这里的价值是把一套“写作偏好”固化下来。比如我在做论文写作技能时设定了几个硬规则摘要部分不超过 250 字、必须包含四个要素背景、方法、结果、结论引言部分遵循“漏斗式写法”从宽泛背景逐渐收窄到本文研究问题每个章节末必须有一个过渡句链接到下一章。这些规则写进 SKILL.md模型在生成时就有了一个清晰的行为准则不会再自由发挥。5.2 设计一个 5 步执行的论文写作技能我做了一个名为 “paper-draft-assistant” 的技能执行流程分五步。第一步是“理解摘要与大纲”要求模型先读取用户提供的摘要和关键词并用自己的话复述一遍研究目标——这样能确保模型没有理解偏。第二步是“生成文献综述初稿”这一步我会提供一个最近几年的文献列表要求模型按照时间线组织段落并标注引用占位符。第三步是“填充方法学章节”这一步需要结合用户提供的实验数据描述。第四步是“生成结果与讨论初稿”我会在 SKILL.md 里特别强调“结果章节只陈述事实不进行解释讨论章节再展开分析”这是论文写作中很常见的分界原则但模型如果没有人提醒经常会把两者混在一起。第五步是“格式统一与参考文献整理”技能会调用一个模板文件把整个文档的标题层级、图表编号、引用格式一次性规范化。5.3 Codex 环境下的实际调试记录两类报错与解决思路第一次跑这个技能时我遇到两个典型的报错。第一类是“模型试图调用不存在的工具”。原因是我在 SKILL.md 里声称“如果用户提供了 PDF 文件调用 pdf_text_extractor 工具提取文本”但这个工具并没有在 Codex 环境中注册。模型的处理方式是假装调用然后自行推断输出结果就是文字内容大量缺失。这个问题的解决办法很简单在技能包里声明自己能做什么、不能做什么。我最后把描述改成了“仅处理 Markdown 或纯文本格式的输入不支持 PDF 解析如果遇到 PDF 文件提醒用户先转换成文本格式”。第二类问题是“上下文窗口溢出”。论文写作技能需要输入大量参考文献和示例文本很容易把上下文撑爆。我的解决方案是调整执行策略让模型分段处理——先生成文献综述写完后立即输出一个分节文档下一轮再继续生成方法学部分而不是要求模型一次性输出全文。实际用下来分段生成虽然没有“一键全文”看起来酷但稳定性和质量都要好得多。5.4 写论文时最值得加的三个微技能除了主技能之外我还额外封装了三个小技能写作时配合使用效果很好。第一个是“摘要精简器”输入一个字数超标的摘要技能会自动压缩到目标字数同时保留四个核心要素。第二个是“过渡句生成器”专门用于生成章节末尾的过渡段落这个功能的触发条件很明确——“当章节之间衔接不畅时使用”。第三个是“参考文献格式化器”内部保存了几种常见引用格式的样例输入原始文献信息后输出规范化的引用条目。这三个微技能的共同点是任务单一、输出格式明确、触发场景容易判断。它们的职责不是生成内容而是解决写作流程里某个具体环节的“格式一致性”问题。把大技能拆小之后再配合主技能使用整体效果比我一开始追求的“一个技能包打天下”可靠得多。6. 二进制视角之外的隐忧Skills 的上下文开销与安全边界6.1 一个被忽视的问题每次启用技能都会烧掉大量 token我前面说过Skill 的价值之一是节省上下文空间但这只是相对“在对话里输入同样内容”而言。实际上每次模型自动匹配并加载一个技能包时都需要把 SKILL.md 甚至部分附带文件读进上下文。如果你安装了上百个技能模型在做意图匹配时本身就会消耗大量 token而且匹配错误的风险也随之上升。我在自己机器上装了一批社区技能后明显感觉到响应速度变慢。查了下统计原来 Claude Code 每次启动时都会扫描所有技能目录并读取元信息。我的解决方法是在技能文件夹里建一个空的.disable标记文件把暂时不用的技能禁用掉只保留当前项目真正需要的五六个。启用数一下子降下来之后响应速度恢复到了正常水平。6.2 技能包可以执行代码规模化使用前必须设置安全边界技能包里可以携带脚本这意味着它能调用系统命令、读写文件。这在本地使用没问题但如果你的工作流里使用了云端环境、自动化流水线或者要分享给不了解技术细节的同事就必须考虑技能包代码的安全边界。我给自己定了几条规则下载的开源技能包在安装后会先通读一遍全部脚本代码重点关注有没有奇怪的网络请求和文件删除操作自己写的技能包不请求任何外部网络服务数据只在本机范围内流转任何人发给我要我安装的技能包如果不附源码说明一律不装。这些规则听起来像是老生常谈但我确实见过有技能包会在后台悄悄发送本地文件内容到外部服务器的案例——不是所有的技能包作者都怀有恶意但开源世界的信任链需要自己把关。6.3 给“内部技能库”建一个简单的分工框架如果你所在的团队开始大规模使用技能包我建议按“通用层-项目层-个人层”建一个分工框架。通用层放那些跨项目通用的技能比如代码规范检查、SQL 生成、文档翻译项目层放针对特定项目的技能里面包含项目目录结构、命名规范、常用依赖库等具体信息个人层则是每个人自己的偏好增强比如某人习惯在生成代码时附带测试用例、某人喜欢注释风格的差异。分工框架的好处是当项目层技能更新时不会影响通用层当个人层技能出错时可以直接让本人修改而不牵连全团队。我目前负责的团队就是按这个结构在维护技能目录每个新项目启动时只需要新增一个项目层技能包就能让 AI 快速进入状态。相比以前靠口头传递项目背景知识这个方式效率高太多也更不容易遗忘细节。7. 常见问题排查为什么技能没生效、输出不稳定、跨工具不兼容7.1 技能完全没被触发八成是描述没写好最典型的症状是你问了模型一个问题明摆着某个技能完全适用但模型完全没反应。排查思路很简单检查技能包的 frontmatter 描述是否足够具体是否包含准确的触发信号词。我之前写过一个“command-line helper”技能描述只写了“帮助使用终端命令”结果测试的时候死活不触发。后来我把描述改成“当用户询问如何在项目中使用 npm、git、docker 相关命令时启用尤其在用户提到构建、部署、测试命令时”模型一匹配一个准。这个现象背后的逻辑是模型在做意图匹配时需要描述中的关键词和用户问题之间有可识别的重叠。描述里那些泛泛的词汇反而会因为信息量太低而被模型忽略。7.2 输出格式漂移怎么让模型每次都严格按模板来另一个常见问题是技能第一次运行效果很好第二次开始输出格式逐渐偏移——本来要求的四段式报告变成了三段本该在表格里的内容变成了列表。这个问题的根源多半是样板示例没有在 SKILL.md 里被妥善引用。我的解决办法是双重强调一是在 SKILL.md 里明确写“输出必须与 examples 目录下的 example-output.md 保持一致”二是在技能包中把示例文件的完整路径重命名成REFERENCE_OUTPUT.md这个名字本身就是一种强提示。实测下来双重强调比只提一次要有效得多。如果有条件还可以在示例文件开头加一段注释说明“这是标准输出样例不允许修改结构”。7.3 同一技能在不同工具里表现不一根源在“能力边界”同一个技能包放在 Claude Code 里运行流畅放到 Codex 里就各种报错这是我经常被问到的问题。根本原因通常是两个工具的“能力边界”不同——Claude Code 支持某些内置工具而 Codex 支持另一套。技能包里如果引用了特定工具跨环境自然就会失效。我的习惯是在技能包的 SKILL.md 里按环境分写两套执行说明。如果模型在 Claude 环境走 A 路径使用 Claude 自带工具如果检测到 Codex 环境走 B 路径调用自定义脚本完成类似功能。当然这样会让技能包维护工作量变大但对于团队级共用的技能来说这一点投入是非常值得的。问题现象可能原因快速排查方法技能从未被触发frontmatter description 过于宽泛重写描述加入明确触发词和排除场景输出格式跑偏SKILL.md 中示例引用不足添加 REFERENCE_OUTPUT.md 并双重强调脚本报错路径硬编码或依赖缺失改用参数传入路径移除第三方依赖跨工具失效技能依赖了特定内置工具按环境拆分执行路径或改用通用脚本7.4 技能包越加越多怎么治理才不乱如果你和我一样也是个“收藏型玩家”技能包数量迟早会突破 50 个。这时候再靠一个个文件夹管理已经不现实了。我给自己的做法是把所有技能都放在一个 Git 仓库里管理每个技能目录下都有一个README.md记录用途、适用环境、依赖条件、最近更新时间。更新节奏上我每个月做一次清理把三个月内没被触发过的技能迁入“归档目录”。清理完之后模型加载扫描的负担会轻很多日常响应速度也会有可感知的提升。另外我会给每个技能按“核心-常用-偶尔”打上标签这个标签放在 description 的开头部分这样模型在匹配时也能更容易区分优先级。8. 从“会写”到“写得好”我沉淀下来的几条技能设计经验8.1 单一职责比大而全可靠得多这是我反复提到的一点但它值得单独拎出来说。我见过太多人做技能时想把热度最高的一堆功能全部塞进一个技能包里结果往往是模型无所适从。做技能和写函数是同一个道理一个函数只做一件事一个技能只覆盖一个已经足够清晰的场景。从社区数据来看那些被收藏、被 fork 最多的技能包几乎全是解决单一场景问题的。我之前下载过一个“icon 搜索”技能它只做一件事根据用户描述的风格和用途推荐匹配的 icon 库和具体图标名称。这个技能包不写代码、不生成组件纯粹是一个知识检索增强。但就是因为它足够简单、足够聚焦每次用都非常可靠。8.2 “少写规则多给例子”是技能写作的黄金法则给模型写技能时很多人会陷入“无限堆规则”的陷阱总觉得规则写得越多输出越稳定。但实际经验是规则属于显性知识模型在推理时并不总能严格遵循而例子属于隐性知识模型读过几个好例子之后模仿起来反而更容易。所以我现在写技能时会刻意把那些可以用“好与坏对比”表达的东西做成示例对。比如在论文写作技能里我不会抽象地说“结果部分不要做过多解读”而是直接给一个“合格的结果段落”和一个“不合格的结果段落”做对比并在不合格版本下面标注它错在哪里。模型看到这种并列对照材料后执行时的表现通常不会差。8.3 技能的可观测性从默默运行到过程可审计技能包里的脚本在跑的时候模型和用户都看不见中间过程这就出现了“黑盒效应”。为了提高技能的可观测性我喜欢在脚本里加日志输出每完成一个中间步骤就往标准输出打一行结构化日志。模型会读取这些日志并据此判断下一步动作用户也能在调试时看到脚本执行到了哪一环。这个习惯在一次调试中帮了大忙。当时我的脚本路径参数写错了导致一路扫描到系统目录日志输出显示“扫描了 4000 个文件”我一看就知道路径没有生效。如果没有这些日志这个问题可能很难定位外行人更会一头雾水。对于想长期维护技能库的团队可观测性设计从一开始就不该缺位。9. 写在最后给刚开始接触 Skills 的人几个实用建议9.1 第一周怎么安排从模仿到自研的路径如果你是刚听说 Skills 这个概念我建议第一周不要急着从零写。先花两天时间去 GitHub 上把热度最高的几个技能合集下载下来逐个安装、逐个跑一遍感受一下它们的设计思路。然后挑一个你自己日常任务里重复率最高的场景把社区技能改造成适合你的版本。改造的过程中你自然会理解 frontmatter、示例引用、校验清单这些概念。等到第四五天再尝试写一个完全属于自己的小技能。场景不要选太复杂的可以是一个“新闻摘要生成器”或者“会议纪要模板生成器”。第一周的目标是完成一次从“使用”到“修改”到“创作”的完整循环而不是写出全网最好的技能包。9.2 一些我在实际使用中摸索出来的“反直觉”经验有几个经验是我踩过不少坑之后才悟出来的。第一个是技能包的 SKILL.md 不要写太长最好控制在 150 行以内。太长的技能描述会稀释模型对重点内容的注意力反而让执行不稳定。第二个是不要过度依赖“示例文件”如果示例文件内容本身质量平庸模型会照着平庸的样子学效果还不如不给示例。第三个是给技能包写 README 文档的人技能整体的完成度通常更高这已经是我判断技能质量的一个隐性指标。还要提醒一句不要一口气安装几十个技能。技能数越多模型匹配的负担越大触发错误率和延迟都会上升。稳定运行的最优状态往往是只有十几个精心维护的技能而不是数百个来路不明的收藏品。9.3 技能这件事后续还能往哪里扩展Skills 的生态还在快速变化期。目前流行的做法是把技能包绑定到单个 Agent 环境里但我个人比较看好的方向是“跨工具的通用技能格式”——写一次技能能在不同 Agent 环境里无障碍运行。虽然目前完全无缝切换还不太现实但社区已经有了一些 converter 类的工具在尝试桥接不同环境之间的技能格式差异。另一个值得关注的方向是“技能编排”让多个技能在一个任务里按顺序联动。比如“先做代码审查再把审查结果整理成周报然后按周报格式生成邮件”就是一个典型的技能联动场景。目前实现这类联动还需要靠用户手动分步调用但下一步很可能会出现专门的编排机制让技能之间的交接变得更顺滑。如果你现在就开始用 Skills 并积累一批自己的技能到那时候你手里的资产会非常值钱。