★ FEATURED ARTICLE 1. 从“什么都能干”到“干得漂亮”Skills机制的前世今生1.1 大模型“会说话”不等于“会做事”如果你最近玩过Claude Agent、Codex这类编程智能体大概会有一种奇妙的感觉同一个模型在A手里是“神队友”写代码条理清晰、改Bug一针见血换到B手里就变成“新手实习生”问一句答一句你不催它就不动甚至会在同一个错误上反复打转。模型还是那个模型差距出在哪儿我的答案是差距不在模型在人。更准确地说在“人有没有给Agent准备好一套趁手的Skills”。这里说的Skills不是简历上写的“熟练掌握某某技术”那种个人能力而是近半年在AI Agent圈子里快速火起来的一个特定概念——给Claude Agent、Codex这类编程智能体准备的“技能包”。它本质上是把一套可复用的方法论、操作流程、脚本模板打包成结构化文件放进项目的skills目录里。Agent在执行任务时会像翻参考手册一样读取这些文件照着你定好的流程去思考、去调用、去输出。社区里有篇很火的文章叫《Claude Agent Skills: A First Principles Deep Dive》标题起得挺学术读完你会发现核心就一句话Skills是对“模型能力”和“任务结果”之间那道鸿沟的工程化填补。我自己最初看到这个词组时第一反应是“这不就是预设Prompt吗”但真正用了一段时间、自己也动手写过几个Skills之后才意识到这里面的设计思路比单纯写Prompt深得多。我们得承认一个现实大模型本质上是一个“会说话”的系统它擅长的是生成看起来合理的文本而不是稳定地执行一套流程。哪怕你告诉它“先分析需求再写代码最后跑测试”它也可能因为上下文太长而把中间某一步漏掉或者因为某句话说得不够明确就自己发挥发挥走偏了。Skills要解决的正是这种“漫谈式执行”的不稳定性——它把一套过程固化下来让模型每次启动任务时都能回到同一条轨道上。1.2 与Prompt、MCP的分工边界聊Skills之前得先把几个容易混的概念捋清楚。这段时间社区里讨论Agent的人很多但很多朋友把Prompt、MCPModel Context Protocol模型上下文协议、Skills混在一锅粥里煮聊着聊着就乱了。我自己的理解是这样的Prompt是“对话策略”你告诉模型“你是一个资深前端工程师请帮我写一个React组件”这是在当下这一次对话中调整模型的姿态。它的作用是临时的、上下文相关的换一个会话就得重新说。MCP是“能力接口”它解决的是模型“能不能调用外部工具”的问题比如读文件、查数据库、调API。MCP定义了工具长什么样、参数怎么传但没规定“先调哪个后调哪个”也没规定“调用完怎么决定下一步”。Skills是“业务方法论”它解决的是模型“知道该怎么做才靠谱”的问题。Skills里既包含流程指引也可以捆绑相关的脚本和模板让模型在需要时能按步骤执行。打个不那么严谨但很好懂的比方Prompt像是给一个刚入职的顾问做briefing告诉他客户是谁、目标是什么MCP像是给他配齐了电脑、电话、打印机这些办公设备Skills则是把公司沉淀下来的“项目交付SOP”递到他手里告诉他“按照这个流程走你能少踩很多坑”。三者各管一段谁也替代不了谁。明白了这层边界再去看Skills的设计很多困惑就迎刃而解了——为什么Skills要放在项目目录里而不是写进系统提示词因为它要跟着项目走换一个项目就是换一套SOP而不是靠人肉复制粘贴。为什么Skills里要允许捆绑脚本因为有些流程本来就该用代码固化比如解析一个JSON、调用一个API让模型现场写太不稳定不如直接给它一个写好的工具。2. 拆开Skills的“黑盒”目录结构与核心文件解析2.1 一份典型Skills的目录长什么样要说清楚Skills怎么用最直接的办法就是拆一个真实的包看看。我这边有一份自己常用的Skill名字叫analyze-doc功能是帮我对项目里的技术文档做结构化审读。它的目录结构长这样analyze-doc/ ├── SKILL.md └── scripts/ └── extract_sections.py就这么简单对就这么简单。一个Skills包的核心只有一个SKILL.md文件剩下的都属于可选增强项。SKILL.md是技能的主控文件Agent会优先读取它scripts/目录用来放一些配套的脚本模型在需要时可以调用这些脚本来辅助完成任务。SKILL.md本身由两部分组成开头是YAML格式的frontmatter元信息正文是给Agent看的操作指引。我见过不少朋友第一次接触Skills时拿过来一个包会习惯性地去翻里面的代码这其实搞反了——对Agent来说SKILL.md里的自然语言描述才是最重要的脚本只是执行细节的补充。2.2 SKILL.md的frontmatter与正文怎么写SKILL.md的frontmatter不像写Jekyll博客那么简单它里面的字段都有明确的语义。我对照官方文档和自己踩过的坑把常用字段整理成了一张表字段作用推荐写法name技能名称Agent识别用用短横线连接的英文如frontend-reviewdescription一句话说明技能的适用场景和触发条件写清楚“什么情况下用”不要太泛allowed-tools允许该技能调用的工具白名单如bash、read_file、write_filetemperature输出随机性控制更准确地说是传给底层模型的采样参数之一值越大越发散适合创意类越小越收敛适合代码类model限定使用的底层模型族部分平台支持用来强制走某个模型比如代码任务走更稳的型号正文怎么写其实没有统一模板但有两条经验我觉得放之四海而皆准。第一用“步骤化”的语言描述流程别用散文第二多用“验收标准”约束输出别只说“分析一下”就完事。拿我自己写的analyze-doc的正文举例核心段落大概是这样的# 分析目标 - 提取文档中的核心观点按优先级排序 - 标出至少3个可用数据支撑的论点 # 参考实现 1. 使用 scripts/extract_sections.py 解析文档结构 2. 对每个章节执行以下检查 - 是否有明确的小标题 - 论点与论据是否对应 3. 输出一份Markdown报告包含章节树、问题清单、优化建议你会发现正文里有一个很关键的小设计——# 参考实现。这个叫reference implementation的段落在Skills机制里承担着“两段式控制”的作用它告诉Agent“这个流程是参考路径你可以按它执行”而不是“你必须一字不差地照做”。这样做的好处是既给了模型足够的引导又保留了它在实际执行时做局部调整的灵活性避免流程僵化到没法用。2.3 为什么用“参考实现”而不是“必须执行”这里头有个挺值得琢磨的设计哲学。如果Skills把每一步都写死一旦实际场景和设计时的假设稍有出入Agent就被卡住了但如果不给流程Skills又退化成普通Prompt失去了约束力。“参考实现”这个定位本质上是把人机协作的分寸感做进了规范里。我在写第一个Skills的时候吃过亏。当时我写了一个“代码安全扫描”技能把每一步检查点列得特别细比如“第1步检查SQL拼接第2步检查文件上传第3步检查越权接口……”结果实际跑起来Agent到了第2步就开始机械地往报告里堆东西完全不会根据代码库的情况做取舍。后来我改成“参考实现”的写法把步骤作为推荐路径而不是死命令同时在末尾加了一句“如果检查中发现与上述步骤无关但明显异常的内容请补充记录”执行效果一下子就好起来了。这个细节也让我更认同社区里的那句总结Skills的定位不是“让模型变成自动化流水线”而是“让模型在挂载了方法论之后变成更有经验的操作员”。你要给模型一个框架而不是一条铁轨。3. 手把手开发一个“分镜写作文”Skills3.1 为什么选择“分镜写作文”这个案例前面讲了不少概念光说不练容易让人心里发虚。这一节我拿一个真实场景走一遍全流程——开发一个叫storyboard-essay的Skills专门用来写“分镜式作文”。我选的这个案例有三个考量第一它不需要依赖任何外部服务只要一个文本模型就能跑适合新手完整跟下来第二分镜这个概念不只在写作里用拍短视频、做PPT、写营销文案都用得上推理路径可以移植第三它相对容易出效果写完你能比较直观地感觉到“挂技能”和“不挂技能”的差异。什么叫分镜式作文简单说就是先建立“分镜表”——每个镜头里有画面、有动作、有情绪再把分镜转写成文字段落。它的好处是让文章天然有画面感告别“流水账”。传统写法和分镜式写法的差异本质上是从“线性叙述”变成“视觉化构建”文章的层次感和节奏感会明显不一样。我这个Skills的设计目标是给定一个作文题目Agent能先输出分镜表再输出完整的成文。分镜表最少8个镜头每个镜头要包含场景、动作、细节。更重要的是我要让它避免“套用万能作文模板”的油腻感所以在流程里专门加了一步“针对题目关键词做意象联想”。3.2 搭建目录与编写SKILL.md我先把目录建出来mkdir -p storyboard-essay/scripts cd storyboard-essay然后编辑SKILL.md。先说frontmatter我实际用的是--- name: storyboard-essay description: 根据给定命题先规划分镜再撰写带画面感的叙事作文。适用于语文作文、创意写作、故事创作等场景。 ---注意我的description里没有写“写作文”这种笼统的词而是写了“分镜”“画面感”“叙事”这些可以匹配任务场景的关键词。经验告诉我Agent对“什么时候该用这个技能”的判断主要靠description做语义匹配——你要是写得太泛模型容易在不需要的时候也去调它写得太窄该用的时候又不会触发。正文部分我完整贴出来供参考# 目标 针对给定的作文题目生成一篇不少于800字的叙事作文核心特征是“有画面感”。 # 参考流程 1. 提取题目关键词列出3个可用的核心意象。 2. 设计分镜表不少于8个镜头每个镜头包含 - 场景设定时间、地点、环境气氛 - 主体动作画面中的核心动态 - 细节点缀一个可被“看见”的小细节 3. 检查分镜的逻辑连贯性镜头之间是否有转折或递进如果没有调整顺序。 4. 根据分镜表逐镜头撰写正文禁止直接罗列分镜内容。 5. 输出后检查是否每个镜头都对应到了正文中的一段未对应的在定稿前补充。 # 验收标准 - 全文没有“首先”“然后”“最后”式流水账连接词。 - 至少有2处用五感描写视觉之外的听觉、嗅觉、触觉等。 - 结尾要有意象回扣而非空泛抒情。写完SKILL.md我顺手加了一个scripts/generate_outline.py作用是帮你把分镜表转成初步的内容提纲。这个脚本并不复杂几十行就能完成——主要是为了演示“Skills可以带脚本”这件事。虽然这段脚本会让Skill包体积变大但对于需要固定格式输出的场景这种提取细节的思路真的能让输出稳定很多。3.3 安装、注册与验证目前主流的安装方式是把Skills目录放进项目的.claude/skills/目录下比如my-project/ ├── .claude/ │ └── skills/ │ └── storyboard-essay/ │ ├── SKILL.md │ └── scripts/ │ └── generate_outline.py └── ...装完之后怎么验证我习惯的做法是开一个干净的新会话只给出一句话“请用storyboard-essay技能以‘雨天的站台’为题写一篇作文。”然后观察两个东西第一模型有没有主动引用SKILL.md里的内容第二生成的文章是不是按分镜结构展开的。如果模型无视技能直接开写那多半是description写得不够清晰或者目录放错了位置。如果模型确实读了技能但效果不理想——比如分镜表只列了5个镜头或者正文段落和分镜对不上——那八成是“验收标准”写得不够细需要再补几条更明确的硬约束。这个“写技能、跑一次、改描述”的循环我每个技能至少会调三轮以上急不来。3.4 调试Skills时最容易忽略的三件事第一SKILL.md的排版一定要干净。模型解析Markdown的能力很强但你如果把它写得层层嵌套、标题乱跳模型提取要点时也会“读晕”。标题层级清晰、每段落短小精悍是让模型快速吃透流程的关键。第二别把大段示例文本堆在步骤里。有些朋友写Skills时特别“大方”每个步骤下面都贴一大段示例代码结果是技能文件动辄几百行模型读起来费劲还会干扰它对本项目上下文的注意力。示例是用来定向的一个步骤最多一个点到为止就够了。第三脚本的报错信息要友好。Skills里捆绑的脚本可能被模型在“非预期场景”下调用如果脚本报了看不懂的错模型会卡在那个错误上反复兜圈子。我现在的习惯是脚本被不满足前置条件时直接给提示“请检查输入格式后再调用”让模型能自己纠错往下走。4. Skills从哪里找官方市场与第三方下载平台4.1 官方渠道与正规安装聊完自己开发再说说怎么“借力”。现在Skills的生态已经比半年前热闹多了各类下载平台和合集像雨后春笋一样冒出来。我这里只谈正规渠道避免水货和隐私风险。官方层面Claude现在做了Skills的官方市场等分发渠道你可以在受支持的环境里直接浏览、安装社区提交的Skills也可以把别人分享的Skills包下载后放进项目目录使用。官方渠道的好处是有人审核、规范统一踩雷概率低。GitHub上也有几个组织在维护Skills合集比如Anthropic官方组织下就有不少参考实现另外editors和社区维护的awesome-claude-skills这类列表也值得关注。我找新技能的固定动作是先逛官方市场再刷GitHub的awesome类列表最后才去看个人博客或社交平台上的零散分享。4.2 第三方平台与社区合集除了官方渠道这几年也冒出了不少第三方的Skills下载站和导航站。有的是把GitHub上的Skills包做了索引和分类有的直接提供“一键安装”的功能。这类平台的价值在于聚合搜索方便——你用关键词“分镜”“论文”“代码审查”一搜就能找到好几个待选项。得提醒一句第三方平台鱼龙混杂下载之前务必做几个检查。第一优先选有源码链接、可以直接看内容的包第二警惕那些声称“效果神奇”但SKILL.md写得稀烂的包原理上讲效率不会好到哪里去第三凡是要求你填入私密token、API Key的Skills建议直接拉黑。我用第三方平台下载的一致性准则是不管发布者吹得多猛拿到手先看SKILL.md的质量再决定要不要用。4.3 试技能的“三无原则”我自己的习惯是不管从哪个渠道拿到一个新技能第一轮试用都按“三无原则”来无隐私、无脏数据、无长链调用。“无隐私”很好理解——不要在真实项目里试建一个临时目录放点脱敏数据再测。“无脏数据”是说输入数据用干净的样例免得测试失败时说不清是技能的问题还是数据的问题。“无长链调用”是我后补的一条先给一个尽量简单、不需要调用外部服务的任务验证主流程能跑通然后再叠加脚本、API之类的外部依赖。如果一个技能在主流程跑通之前就搞出一堆外部调用出问题时排查成本会比较大划不来。我还遇到过一种情况同一个技能在A环境跑得好好的换到B环境就“失灵”。后来排查发现是环境变量和依赖没对齐——比如脚本里用了某个Python库在A环境装了在B环境没装。所以拿到带脚本的Skills检测一下依赖是否齐全再谈“好不好用”这个命题。5. Skills常见问题与排查实录5.1 技能加载了但“没生效”怎么办这个问题我在各种群里见过的频率最高用户明明把Skills放进了目录但模型跑起来完全不理会文章还是按老套路写。遇到这种情况别急着怀疑人生按顺序排查这三件事。第一检查路径。Claude Agent读取的是.claude/skills/目录Codex则有自己的约定目录——不同工具读的路径不一样放错位置等于白放。确认一下你的工具到底认哪个目录别把Skills放在外层让它找不到。第二检查description。我刚说过模型是用description做语义匹配来决定是否使用技能的如果你的description写的是“关于写作文的方法论”模型在半路可能根本意识不到“现在该用这个技能”。改成“当用户要求撰写带有画面感的作文时使用本技能”这类带触发场景的描述效果会好很多。第三检查“亲和力”问题。当前主流方案会根据描述与用户请求的相关度来决定是否触发某个技能有些框架还允许在对话里指定强制启用。实在不行在对话里直接说“请使用storyboard-essay技能”是最稳妥的触发方式。5.2 技能包太大会拖慢响应吗会而且影响不小。每次Agent启动时都会把相关技能的内容读入上下文你的技能包越大、SKILL.md越长占用的上下文token就越多留给实际任务的空间就越小。这就像在对话窗口里塞了一大段说明书模型要一边读说明书一边干活响应速度和输出质量都会受影响。我的建议是单个SKILL.md控制在几十行以内能表达清楚流程就行。长内容应该拆到脚本或参考文件里让模型按需去查而不是一股脑全塞进去。用这个方法我能让技能的上下文开销降到很小同时保持完整的方法论结构。另一个容易被忽略的点是不是每个会话都需要加载全部Skills。尽量只保留当前项目真正需要的技能把不常用的移到仓库根目录外的存档区需要时再挂回来。这样能显著改善长对话场景下的体验。5.3 真实场景中的“自动挖洞”与权限边界搜索热词里有个“自动挖洞skills”这里必须把边界说明白。安全测试类的Skills比如自动探测漏洞、检查注入风险等确实存在而且效果不俗但它的适用范围有严格前提——只能在你自己拥有授权的系统、测试靶场、CTF竞赛环境中使用。未经授权的探测行为在任何地区都属于违规操作这不能被当成“炫技”的理由。如果你对这类技能感兴趣建议从CTF靶场或自己搭的测试环境练起。很多平台提供合法的漏洞靶场镜像在里面跑技能既安全又能学到东西。用这种“合法靶场”的方式去接触技术比任何“快捷方法”都稳妥得多。5.4 技能使用频率不高、效果不稳定怎么办有些Skills你写的时候脑子里是“星辰大海”实际用起来却发现触发率低、输出质量飘忽。我的经验是不是技能机制不行是你选的场景不适合固化。适合做成Skills的任务需要满足两个条件第一流程相对固定有明确的“怎么做”路径第二会重复发生值得为此沉淀。反之那些高度依赖当下对话情境、每次变化都很大的任务靠Prompt临场发挥反而更好。所以我现在对Skills的态度是“宁缺毋滥”。与其收藏一堆技能包不如针对自己最高频的3到5个任务场景认真打磨出几个真正好用的Skills。收藏夹吃灰的技能和不存在没什么区别。6. 写给想入坑Skills的你一点个人心得6.1 开发Skills的技术门槛不高难点全在“定义问题”我见过不少开发朋友问“Skills的开发是不是需要精通底层Agent框架”我的回答是不需要但需要你能把一个问题场景拆得很清楚。Skills的技术骨架无非是Markdown加几个YAML字段加一点脚本辅助本质上是个“结构化文档”工程。真正考验人的是第一个环节——定义问题。你得想明白你希望模型在什么场景下、按照什么流程、产出什么格式的结果这个流程里哪些步骤必须约束、哪些步骤可以留白想清楚了再动手写技能文件可以在半小时内搞定想不清楚写出来的就是一个披着Skills外衣的普通Prompt。跟做产品一样——先把需求搞清楚再谈技术实现。6.2 最后一招如何持续保持Skills的“新鲜度”Skills不是一次写完就完事的。模型在变你的使用场景在变技能也需要跟着迭代。我自己每过一两周都会把项目里的Skills翻出来审视一遍“最近有没有在某个场景下反复给模型追加类似的指令如果有是不是该把这条经验固化进某个技能里”慢慢你会发现当“给Agent追加临时指令”变成“打开以前的Skills改两行”时你对Agent的“驾御感”就完全不一样了。这时候你再回头看那些躺在收藏夹里的所谓“万能技能”反而会用一种更冷静的眼光去评判它们——真正好用的技能不是越多越好而是越贴合自己的工作流越好。Skills这个机制本质上是在提醒我们一件事AI时代的能力不完全取决于模型的进步更取决于你有没有把自己的专业经验翻译成模型能够理解和执行的“语言”。这件事你可以从现在开始自己动手做起来。
阅读完成 · 觉得有帮助？
