最近社区里“skills”这个词出现频率高得离谱从“前端开发skills”到“安卓脱壳skills”再到各类“agent skills测试”“skills下载平台”几乎每隔几天就能看到新的热词冒出来。我自己的第一反应是这不就是给大模型塞一堆提示词规则吗有什么好稀奇的。但真正动手用了一段时间之后我得承认这个理解太浅了。skills 本质上是在重新定义大模型的能力边界让一个通用聊天助手变成能按固定套路干活的“岗位专家”。这篇文章我想从个人实践的角度把 skills 这件事拆开讲透它到底是什么、为什么值得折腾、怎么从零写一个能用的 skill、安装调试有哪些坑以及我在实际项目里踩过的各种雷。不吹概念只说怎么落地适合那些已经用过 ChatGPT、Claude、Codex 这类工具但还没搞明白“技能文件”该怎么组织的人也适合想把手头重复工作沉淀成可复用技能的开发者。哪怕你完全没写过代码照着后面论文润色那个例子走一遍也能体会到这套逻辑的爽点。1. skills到底是什么1.1 一个 skill 不只是“一段提示词”很多人第一次接触 skills看到 README 里那个SKILL.md文件会觉得这不就是 Markdown 写的 prompt 吗。表面看确实如此但实际区别很大。普通 prompt 是一次性的你打一段话模型按这段话执行一次。而 skill 是结构化的能力封装它包含说明文件、参考示例、可执行脚本、校验规则甚至还有自己的工具调用逻辑。模型读到SKILL.md之后不是“听你指挥一次”而是“学会了你这套做事方法下次遇到同类任务能自己按流程走”。我打个比方普通 prompt 像你给实习生口头交代“帮我把这份报告润色一下”实习生这次干得怎么样全看心情和悟性。而 skill 等于你给实习生一份岗位手册里面写着“润色分三步第一步检查逻辑第二步调整句式第三步统一术语每步做完都要输出中间结果”手册旁边还配了工具、模板和反例。你说哪种方式更可靠。这也是为什么社区里很多人讨论“skills 推荐”“find skills”的时候关注点都在技能库的完整度上。一个成熟的 skill 文件通常包含几个固定部件SKILL.md主说明文件告诉模型这个技能什么时候用、怎么用、输出格式是什么。scripts/目录可选存放辅助脚本比如格式化、抓取数据、批量处理文件。references/目录可选放样例、参考资料、术语表。配置文件比如skill.json声明元数据、版本、依赖。这个结构意味着 skills 已经不只是提示词技巧而是一套轻量级的“模型编程框架”。你定义流程模型负责执行脚本负责处理模型做不了的计算和 IO 操作。1.2 为什么叫“技能”而不是“插件”和插件plugin相比skills 更强调“内化”。插件是外部工具模型需要专门调 API 才能用。技能则更像是模型的“动作记忆”它不需要外部系统介入模型读取说明文件后就能直接表现出对应的能力。Claude 官方文档里有一篇非常出名的分析文章标题就叫《Claude Agent Skills: A First Principles Deep Dive》里面反复强调一个观点skills 的目标是让 agent 在复杂任务中“知道什么时候用什么方法”而不是把所有逻辑前置到系统提示里。从这个角度看安卓脱壳 skills、自动挖洞 skills 这类安全研究方向的热词其实一点也不奇怪。逆向工程和漏洞挖掘是高度依赖流程的领域一个经验丰富的安全研究员可以把“脱壳步骤”“动态调试路径”“特征定位方法”固化成 skill让 agent 按部就班地辅助分析。这也是 skills 被叫做 superpower skills 的原因它确实像是给模型装上了某种超能力只是这个能力完全由你自己定义。我自己测试过一个小实验让同一个模型分别用“普通 prompt 提示词描述”和“完整 skill 文件”去处理同一批客服工单分类任务。结果很直观用 skill 的那次输出格式稳定、分类标准一致、每单耗时少三分之一。原因不复杂prompt 模式下模型每次都在重新理解规则而 skill 模式下规则是固定的模型只需要对照执行。2. 主流实现和生态现状2.1 Claude 系 skills 和 Codex skills 的各自风格目前最常被提到的两个实现一个是 Claude 官方市场里的 Agent Skills另一个是 OpenAI Codex 里支持的 skills 集合。两者目标一致但设计思路差别挺大。Claude Agent Skills 走的是“文档驱动”路线。一个技能本质上就是一个文件夹主入口是SKILL.md模型通过读取这份文档来决定是否调用、如何调用。因为说明文件是自然语言写的所以技能的创建门槛很低会写 Markdown 的人就能贡献技能。官方市场里的技能库覆盖了邮件处理、代码审查、视频脚本、论文润色这些高频场景直接下载就能用。Codex Skills 则更偏向“工程化”。它经常和自动化流水线绑定一个 skill 可能包含多个脚本、配置模板、甚至 CI 校验逻辑。Codex 社区里流行的“codex 好用的 skills”基本都是配合代码仓库用的比如自动生成 commit message、自动补单元测试、自动修 lint 错误。这类技能对执行环境的要求更高通常需要把仓库 clone 到本地再通过命令行调用。我整理过一张对比表可以帮你快速判断自己更适合哪套体系维度Claude Agent SkillsCodex Skills技能形态文件夹 SKILL.md脚本集 配置 文档门槛低会写说明就行中高需要理解执行流程典型场景内容处理、分析、写作辅助代码生成、仓库操作、自动化调用方式自然语言触发模型自主判断明确命令触发流程感更强社区供给官方市场 GitHubGitHub 命令行工具集适合人群普通用户、内容创作者开发者、DevOps、技术团队当然这个对比不是绝对的现在两边都在互相学习。Claude 的技能也开始支持引用脚本Codex 也在加强文档说明的作用。你如果刚入门我建议先玩 Claude 系因为从安装到见效的时间最短“skills 安装包下载”之后一般放对文件夹就能跑起来。2.2 “skills 大全”和“下载平台”到底在找什么热词里有一类特别有意思“skills大全”“skills下载平台有哪些”“skills安装包下载”。表面看是在找资源本质上是大家发现了一个新生产力市场但不知道去哪里找高质量货。这和早期找“prompt 大全”的心理一模一样只是 skills 的筛选门槛更高一个 prompt 写得不好顶多没效果一个 skill 写得不好可能把流程带偏。我常用的资源渠道有三类。第一类是官方市场比如 Claude 的 skills 市场质量有基础保障但数量有限。第二类是 GitHub 搜索关键词用claude skills或agent skills按 stars 排序能挖到不少宝藏仓库比如有人专门整理了几十个文案写作类技能还有合作团队开源的内部工种技能库。第三类是社区博客和评测文章很多作者会把技能文件直接贴在文章里看到合适的复制下来就能用。但这里要提醒一句别见到 skill 就随手装。技能文件本质是一段可执行逻辑里面如果引用了脚本就相当于在你机器上跑外部代码。我的原则是先看 SKILL.md、再看 scripts 里的代码、最后才安装。尤其是命令行工具类的技能最好先在一个没有重要数据的目录里试跑一遍。2.3 为什么“agent skills 测试”突然成了刚需热词里有“agent skills测试”“skills开发”这两个我特别有共鸣。最初我写 skill 的时候觉得写完就完事了结果经常出现“文档写得很完美但模型根本不调用”的尴尬情况。后来才意识到技能和人一样需要验收。你至少要测四件事触发准确性输入什么内容时模型会主动调用这个技能执行稳定性同一输入跑五次输出差异大不大脚本健壮性脚本遇到缺文件、空数据、异常符号时会不会崩溃上下文占用技能文档太长会不会把对话窗口撑爆现在社区里已经有人开始写“skills 测试框架”了基本原理是准备一组典型输入自动调用技能跑一遍检查输出结构是否符合预期。我自己的土办法更简单在 Claude 里建一个测试会话把技能装好后连发五条不同难度的请求看它是否按说明文档执行。比如测试论文润色技能我会分别丢“摘要只有三行”“全文两万字”“带图表标注的论文片段”三种输入观察处理方式的差异。3. 手把手写一个能用的 skill论文润色3.1 为什么拿“论文润色”当例子因为热词里“codex写论文的skills”“workbuddy skills 写论文”“claude skills”出现的频率非常高说明这是大多数人最需要的场景。而且论文润色任务的流程相对固定读原文、找逻辑断点、改句式、统一术语、输出修改说明每一步都可以文档化。哪怕你完全没写过代码只要理解这套流程就能跟着做出来一个能用的 skill。顺便说一句官方市场里已经有很多论文润色技能了但自己写一遍的价值在于你更清楚模型的处理边界更知道哪里该给规则、哪里该留自由度。直接用现成的出了问题你很难判断是文档问题还是模型问题。3.2 技能文件的目录结构规划论文润色技能时我的目录结构是这样paper-polish/ ├── SKILL.md # 主说明文件 ├── references/ │ ├── academic-terms.md # 学术术语对照表 │ └── before-after.md # 修改前后对比示例 └── scripts/ └── extract_refs.py # 从论文中提取参考文献列表可选这个结构的好处是说明、参考、代码完全分层。模型先读SKILL.md形成全局认知遇到术语问题去查references需要批量处理时就跑scripts。你在写自己的技能时也可以参照这个模板不一定非要写脚本但references目录强烈建议保留它能显著提升输出质量。3.3 SKILL.md 怎么写才算清楚SKILL.md是整个技能的核心模型能不能正确执行全看这份文档写得是否清晰。我见过很多人的技能文档写得像散文洋洋洒洒几百字但模型读了还是不知道第一步干什么。这里分享一个我摸索出的结构模板--- name: paper-polish description: 用于学术论文的润色与逻辑优化特别适合英文摘要、引言和结论部分。 --- # 论文润色 ## 使用场景 仅当用户提供论文段落、摘要或完整稿件并要求润色时使用。 不要用于普通文案、朋友圈文案或非学术语境。 ## 处理流程 1. 通读原文标记逻辑断点。 2. 逐句优化优先修改被动语态、冗余表达和模糊指代。 3. 术语一致性检查对照 references/academic-terms.md。 4. 输出修改后文本并在末尾列出 3-5 条修改要点。 ## 输出格式 必须按以下结构返回 - 修改后版本 - 修改要点列表 - 术语对照表如有注意到几个关键点没有。首先是description字段模型会读这个字段来决定是否触发技能所以里面要写清楚“什么时候用、什么时候不用”。其次是“处理流程”一定要拆到模型能直接执行的粒度“逐句优化”比“提升语言质量”好用一百倍。然后是“输出格式”固定了格式你后续做批量处理或者集成到工作流里都会容易很多。另外SKILL.md里可以加一小节“禁忌事项”。比如论文润色技能里我会写不改动作者的原意、不新增实验数据、不修改参考文献编号。这些约束能有效防止模型自由发挥过度。3.4 脚本在技能里的作用论文润色这个场景里脚本不是必需品但有两个地方脚本特别好用。一是参考文献提取论文里参考文献格式五花八门让模型靠阅读去解析容易出错写个正则脚本提取就稳得多。二是批量处理比如你有二十篇摘要要润色模型每次只能处理一段脚本可以先按段落拆分文本润色完成后自动拼回去。我给extract_refs.py写过一个简化版本大概长这样import re import sys def extract_references(text): # 简单匹配 [1]、[1,2]、[1-3] 这类引用标记 pattern r\[(\d(?:[,\-]\d)*)\] return re.findall(pattern, text) if __name__ __main__: content sys.stdin.read() refs extract_references(content) for ref in refs: print(ref)注意这个脚本只是为了说明“技能里的脚本可以承担什么角色”实际使用时要根据自己的论文格式调整正则。更重要的是你要在SKILL.md里写清楚“什么时候调用脚本、什么时候不调用”。比如我规定当用户要求“提取参考文献列表”时才运行脚本只是润色正文时不要额外跑脚本打断节奏。4. 安装引入与管理从官方市场到本地目录4.1 几种安装路径先说最简单的情况如果你用的是 Claude 这种带有官方市场的产品直接搜索 skill 名称点安装即可。热词里“claude 国内安装 skills 官方市场”说明很多人第一步就卡在这里其实口碑比较好的办法是先用官方客户端或网页版进入 settings 里的 skills 板块找到市场并搜索。这个过程的本质是把远程仓库克隆到本地指定目录所以你也可以绕过市场直接把 GitHub 上的技能文件夹下载下来放到对应目录里。具体路径因工具而异但逻辑一致。以 Claude 桌面版为例技能通常放在~/.claude/skills/每个技能一个文件夹里面要有SKILL.md否则不会被识别。Codex 的安装方式更偏命令行一般通过codex skills install 仓库地址这类命令完成安装后会自动配置执行环境。热词里“idea使用skills”“reasonix如何安装新skills”也属于这一类本质都是“把技能文件放到工具能扫描到的目录”。4.2 安装之后的“冒烟测试”技能装好不代表能用我强烈建议每次安装完都做一次不超过五分钟的冒烟测试。测试步骤很简单新建一个空会话不写任何额外提示词。输入一个该技能覆盖范围内的典型请求。观察模型是否主动提到找到了对应技能。看输出格式是否和SKILL.md里定义的一致。如果没触发检查技能目录名是否包含空格或非法字符检查description是否包含用户可能说的关键词。我自己曾经装了一个“代码审查 skills”结果发了五次请求模型都当成普通问答处理。排查半天发现是SKILL.md的description写的是“Review code”而我在提问时用的是“帮我看看这段代码”关键词完全没接上。后来把 description 改成“审查代码、检查代码质量问题、Code Review”之后第二次就触发了。这个细节很值得记下来。4.3 多个技能之间的优先级管理技能装多了就会出现另一个问题冲突。比如你同时装了“论文润色”和“学术写作助手”模型面对一段论文摘要到底该调哪个很多新手对这个感到头疼。解决办法是在每个技能的description里明确“适用边界”并且可以在SKILL.md的开头加一行“只有在用户明确要求润色时使用不要进行学术写作指导”。我实测下来这句话能明显减少技能之间“抢活”的概率。如果冲突还是严重还有一个土办法把不常用的技能暂时移出 skills 目录放到一个_disabled文件夹里。需要用时再移回来。这比在配置里反复开关快得多而且不会误删文件。5. 使用中的高频问题与排查思路5.1 常见问题速查表我用表格把这段时间遇到最多的问题整理了一下基本覆盖了新手阶段的全部痛点了现象可能原因排查与解决模型完全无视技能description 写得太泛或没包含触发词把触发说法写进 description至少包含三种同义表达技能被调用但输出跑偏SKILL.md 流程不够具体拆步骤每个动作细化到可执行指令脚本执行时报错缺依赖或路径不对确认脚本在 skill 目录下可独立运行不要依赖全局变量会话上下文快速耗尽SKILL.md 或 references 内容过长把长样例移到 references只在主文档保留核心规则两个技能互相冲突description 边界不清加“仅当…时使用”的限制语句排版输出不稳定输出格式描述不够硬用“必须”“不得”等强约束词并用列表固定结构这张表我建议保存下来遇到问题先对号入座大部分情况不需要去翻文档。5.2 一次真实的排查经历有段时间我写了一个“分镜脚本 skills”灵感来自热词里的“分镜skills下载”。这个技能的目标是根据小说章节生成分镜脚本包含景别、运镜、时长、台词。第一次测试就翻车了模型确实调用了技能但输出只有三行字和文档里要求的表格结构完全不符。我翻看生成的日志发现模型只读了SKILL.md里“使用场景”那一段后面的“输出格式”部分完全没执行。原因是我的SKILL.md结构太靠近纯自然语言了细节全埋在段落里模型没抓住重点。后来我重写了文档把所有关键规则全部列表化并在文件最开头用加粗写了一句“输出必须是完整分镜表格不得以段落形式返回”。再测输出质量立刻提升了。这件事给我的教训是技能文档不是文章而是“操作手册”模型阅读效率最高的结构永远是短句、列表、固定格式。5.3 关于“上下文占用”的提醒很多人忽略了一个问题技能文档本身会占用模型的上下文窗口。一个写了两千字的SKILL.md相当于每一次对话都先塞两千字进去。如果同时装了十几个技能光技能内容就可能占掉上下文的一小半留给实际任务的容量就少了。这和你电脑开了太多后台程序导致内存不足是一个道理。解决办法其实很朴素给技能做“瘦身”。主文档只保留流程骨架参考资料全部放到references/目录里让模型按需读取。另外在SKILL.md里明确写出“首次响应只输出关键结论不接受额外解释”也能节省大量 token。我试过把同一套技能从三千字压缩到一千字输出质量没有明显下降但响应速度快了不少。6. 安全边界与我的几点经验6.1 技能里的脚本要慎之又慎因为 skills 可以携带脚本所以安全问题必须正视。一个技能文件夹放到本地后脚本通常以当前用户权限运行。如果脚本来自陌生人仓库里面写了删除文件、上传数据、修改系统配置的操作后果可能很严重。这不是危言耸听社区里已经出现过恶意技能的预警案例。我的建议是三条只安装可信来源的技能官方市场优先。安装后打开脚本看一眼重点关注os.system、shutil.rmtree、requests.post这类敏感调用。给技能运行设置一个独立的临时目录不要让它直接操作主项目文件。这和“自动挖洞 skills”这种安全研究场景其实并不冲突。研究者在隔离环境里把攻击性技能用于实验属于正常测试但对普通用户来说保持谨慎是底线。6.2 skill 不是越复杂越好我见过一些人开发技能时恨不得把所有逻辑都塞进去写了几十页文档、挂了七八个脚本。结果呢模型在第一步就看不懂了脚本互相依赖调试成本极高。我的经验是一个技能只解决一个核心问题。拿论文润色举例你完全可以把“润色”“查重”“生成参考文献”分别做成三个技能。它们可以放在同一个技能目录下但各自独立。这样做的好处是模型触发任何一个技能都不需要加载另外两个的配置上下文更省出错时也更容易定位。热词里“superpower skills”听起来很玄但真正好用的 superpowers往往是那些专注、克制、流程清晰的技能。“superpowers 具体使用”这个问题我自己的答案是别贪多把一个技能打磨到十倍好用比收藏一百个技能有价值得多。6.3 写技能文档的三个反直觉技巧最后分享三个我写作时总结出来的小技巧可能和直觉不太一样。第一个技巧是“先写禁忌再写流程”。因为模型对否定指令的敏感度往往高于肯定指令。你说“不要改变作者原意”比“保持作者意图”更能约束行为。所以我在每个技能文档的开头部分都会先列三到五条“不得做”的事项。第二个技巧是“引用具体的实例”。空泛的规则很难被执行但一个“before-after 示例”能让模型立刻理解你要的风格。我在论文润色技能里放了一个改前改后的对照表模型看到之后输出的风格明显更接近我的期望。第三个技巧是“给技能一个内部代号”。比如把论文润色技能命名为“学术文本清洁工”然后在 description 里同时写“论文润色”“学术文本清洁工”两个说法。模型在处理相关请求时会更容易联想到这个技能。这个方法没有论文级别的原理支撑但在我实测里效果不错。写在最后从一个小技能开始如果你看完这篇文章还是觉得有点抽象我的建议特别简单今天就写一个文档描述你手头最重复的一件事比如周报怎么写、会议纪要怎么整理、代码注释怎么补。然后用三十分钟把它变成一个最简版技能装进你的 AI 工具里试一次。这个动作本身比任何教程都有用因为它会逼你去想“流程到底是什么”“边界在哪里”“怎么让另一个智能体理解我的标准”。等你跑通第一个技能再看那些“skills大全”“skills推荐”你的视角会完全不一样你不再是一个下载者而是一个能判断、能修改、能创造的人。这大概就是 skills 这件事最有魅力的地方。 
长河君 · 2026/10/8 21:47:16 · 阅读 1.2k 从提示词到岗位专家：Skills如何重塑大模型能力边界与实战指南
最近社区里“skills”这个词出现频率高得离谱从“前端开发skills”到“安卓脱壳skills”再到各类“agent skills测试”“skills下载平台”几乎每隔几天就能看到新的热词冒出来。我自己的第一反应是这不就是给大模型塞一堆提示词规则吗有什么好稀奇的。但真正动手用了一段时间之后我得承认这个理解太浅了。skills 本质上是在重新定义大模型的能力边界让一个通用聊天助手变成能按固定套路干活的“岗位专家”。这篇文章我想从个人实践的角度把 skills 这件事拆开讲透它到底是什么、为什么值得折腾、怎么从零写一个能用的 skill、安装调试有哪些坑以及我在实际项目里踩过的各种雷。不吹概念只说怎么落地适合那些已经用过 ChatGPT、Claude、Codex 这类工具但还没搞明白“技能文件”该怎么组织的人也适合想把手头重复工作沉淀成可复用技能的开发者。哪怕你完全没写过代码照着后面论文润色那个例子走一遍也能体会到这套逻辑的爽点。1. skills到底是什么1.1 一个 skill 不只是“一段提示词”很多人第一次接触 skills看到 README 里那个SKILL.md文件会觉得这不就是 Markdown 写的 prompt 吗。表面看确实如此但实际区别很大。普通 prompt 是一次性的你打一段话模型按这段话执行一次。而 skill 是结构化的能力封装它包含说明文件、参考示例、可执行脚本、校验规则甚至还有自己的工具调用逻辑。模型读到SKILL.md之后不是“听你指挥一次”而是“学会了你这套做事方法下次遇到同类任务能自己按流程走”。我打个比方普通 prompt 像你给实习生口头交代“帮我把这份报告润色一下”实习生这次干得怎么样全看心情和悟性。而 skill 等于你给实习生一份岗位手册里面写着“润色分三步第一步检查逻辑第二步调整句式第三步统一术语每步做完都要输出中间结果”手册旁边还配了工具、模板和反例。你说哪种方式更可靠。这也是为什么社区里很多人讨论“skills 推荐”“find skills”的时候关注点都在技能库的完整度上。一个成熟的 skill 文件通常包含几个固定部件SKILL.md主说明文件告诉模型这个技能什么时候用、怎么用、输出格式是什么。scripts/目录可选存放辅助脚本比如格式化、抓取数据、批量处理文件。references/目录可选放样例、参考资料、术语表。配置文件比如skill.json声明元数据、版本、依赖。这个结构意味着 skills 已经不只是提示词技巧而是一套轻量级的“模型编程框架”。你定义流程模型负责执行脚本负责处理模型做不了的计算和 IO 操作。1.2 为什么叫“技能”而不是“插件”和插件plugin相比skills 更强调“内化”。插件是外部工具模型需要专门调 API 才能用。技能则更像是模型的“动作记忆”它不需要外部系统介入模型读取说明文件后就能直接表现出对应的能力。Claude 官方文档里有一篇非常出名的分析文章标题就叫《Claude Agent Skills: A First Principles Deep Dive》里面反复强调一个观点skills 的目标是让 agent 在复杂任务中“知道什么时候用什么方法”而不是把所有逻辑前置到系统提示里。从这个角度看安卓脱壳 skills、自动挖洞 skills 这类安全研究方向的热词其实一点也不奇怪。逆向工程和漏洞挖掘是高度依赖流程的领域一个经验丰富的安全研究员可以把“脱壳步骤”“动态调试路径”“特征定位方法”固化成 skill让 agent 按部就班地辅助分析。这也是 skills 被叫做 superpower skills 的原因它确实像是给模型装上了某种超能力只是这个能力完全由你自己定义。我自己测试过一个小实验让同一个模型分别用“普通 prompt 提示词描述”和“完整 skill 文件”去处理同一批客服工单分类任务。结果很直观用 skill 的那次输出格式稳定、分类标准一致、每单耗时少三分之一。原因不复杂prompt 模式下模型每次都在重新理解规则而 skill 模式下规则是固定的模型只需要对照执行。2. 主流实现和生态现状2.1 Claude 系 skills 和 Codex skills 的各自风格目前最常被提到的两个实现一个是 Claude 官方市场里的 Agent Skills另一个是 OpenAI Codex 里支持的 skills 集合。两者目标一致但设计思路差别挺大。Claude Agent Skills 走的是“文档驱动”路线。一个技能本质上就是一个文件夹主入口是SKILL.md模型通过读取这份文档来决定是否调用、如何调用。因为说明文件是自然语言写的所以技能的创建门槛很低会写 Markdown 的人就能贡献技能。官方市场里的技能库覆盖了邮件处理、代码审查、视频脚本、论文润色这些高频场景直接下载就能用。Codex Skills 则更偏向“工程化”。它经常和自动化流水线绑定一个 skill 可能包含多个脚本、配置模板、甚至 CI 校验逻辑。Codex 社区里流行的“codex 好用的 skills”基本都是配合代码仓库用的比如自动生成 commit message、自动补单元测试、自动修 lint 错误。这类技能对执行环境的要求更高通常需要把仓库 clone 到本地再通过命令行调用。我整理过一张对比表可以帮你快速判断自己更适合哪套体系维度Claude Agent SkillsCodex Skills技能形态文件夹 SKILL.md脚本集 配置 文档门槛低会写说明就行中高需要理解执行流程典型场景内容处理、分析、写作辅助代码生成、仓库操作、自动化调用方式自然语言触发模型自主判断明确命令触发流程感更强社区供给官方市场 GitHubGitHub 命令行工具集适合人群普通用户、内容创作者开发者、DevOps、技术团队当然这个对比不是绝对的现在两边都在互相学习。Claude 的技能也开始支持引用脚本Codex 也在加强文档说明的作用。你如果刚入门我建议先玩 Claude 系因为从安装到见效的时间最短“skills 安装包下载”之后一般放对文件夹就能跑起来。2.2 “skills 大全”和“下载平台”到底在找什么热词里有一类特别有意思“skills大全”“skills下载平台有哪些”“skills安装包下载”。表面看是在找资源本质上是大家发现了一个新生产力市场但不知道去哪里找高质量货。这和早期找“prompt 大全”的心理一模一样只是 skills 的筛选门槛更高一个 prompt 写得不好顶多没效果一个 skill 写得不好可能把流程带偏。我常用的资源渠道有三类。第一类是官方市场比如 Claude 的 skills 市场质量有基础保障但数量有限。第二类是 GitHub 搜索关键词用claude skills或agent skills按 stars 排序能挖到不少宝藏仓库比如有人专门整理了几十个文案写作类技能还有合作团队开源的内部工种技能库。第三类是社区博客和评测文章很多作者会把技能文件直接贴在文章里看到合适的复制下来就能用。但这里要提醒一句别见到 skill 就随手装。技能文件本质是一段可执行逻辑里面如果引用了脚本就相当于在你机器上跑外部代码。我的原则是先看 SKILL.md、再看 scripts 里的代码、最后才安装。尤其是命令行工具类的技能最好先在一个没有重要数据的目录里试跑一遍。2.3 为什么“agent skills 测试”突然成了刚需热词里有“agent skills测试”“skills开发”这两个我特别有共鸣。最初我写 skill 的时候觉得写完就完事了结果经常出现“文档写得很完美但模型根本不调用”的尴尬情况。后来才意识到技能和人一样需要验收。你至少要测四件事触发准确性输入什么内容时模型会主动调用这个技能执行稳定性同一输入跑五次输出差异大不大脚本健壮性脚本遇到缺文件、空数据、异常符号时会不会崩溃上下文占用技能文档太长会不会把对话窗口撑爆现在社区里已经有人开始写“skills 测试框架”了基本原理是准备一组典型输入自动调用技能跑一遍检查输出结构是否符合预期。我自己的土办法更简单在 Claude 里建一个测试会话把技能装好后连发五条不同难度的请求看它是否按说明文档执行。比如测试论文润色技能我会分别丢“摘要只有三行”“全文两万字”“带图表标注的论文片段”三种输入观察处理方式的差异。3. 手把手写一个能用的 skill论文润色3.1 为什么拿“论文润色”当例子因为热词里“codex写论文的skills”“workbuddy skills 写论文”“claude skills”出现的频率非常高说明这是大多数人最需要的场景。而且论文润色任务的流程相对固定读原文、找逻辑断点、改句式、统一术语、输出修改说明每一步都可以文档化。哪怕你完全没写过代码只要理解这套流程就能跟着做出来一个能用的 skill。顺便说一句官方市场里已经有很多论文润色技能了但自己写一遍的价值在于你更清楚模型的处理边界更知道哪里该给规则、哪里该留自由度。直接用现成的出了问题你很难判断是文档问题还是模型问题。3.2 技能文件的目录结构规划论文润色技能时我的目录结构是这样paper-polish/ ├── SKILL.md # 主说明文件 ├── references/ │ ├── academic-terms.md # 学术术语对照表 │ └── before-after.md # 修改前后对比示例 └── scripts/ └── extract_refs.py # 从论文中提取参考文献列表可选这个结构的好处是说明、参考、代码完全分层。模型先读SKILL.md形成全局认知遇到术语问题去查references需要批量处理时就跑scripts。你在写自己的技能时也可以参照这个模板不一定非要写脚本但references目录强烈建议保留它能显著提升输出质量。3.3 SKILL.md 怎么写才算清楚SKILL.md是整个技能的核心模型能不能正确执行全看这份文档写得是否清晰。我见过很多人的技能文档写得像散文洋洋洒洒几百字但模型读了还是不知道第一步干什么。这里分享一个我摸索出的结构模板--- name: paper-polish description: 用于学术论文的润色与逻辑优化特别适合英文摘要、引言和结论部分。 --- # 论文润色 ## 使用场景 仅当用户提供论文段落、摘要或完整稿件并要求润色时使用。 不要用于普通文案、朋友圈文案或非学术语境。 ## 处理流程 1. 通读原文标记逻辑断点。 2. 逐句优化优先修改被动语态、冗余表达和模糊指代。 3. 术语一致性检查对照 references/academic-terms.md。 4. 输出修改后文本并在末尾列出 3-5 条修改要点。 ## 输出格式 必须按以下结构返回 - 修改后版本 - 修改要点列表 - 术语对照表如有注意到几个关键点没有。首先是description字段模型会读这个字段来决定是否触发技能所以里面要写清楚“什么时候用、什么时候不用”。其次是“处理流程”一定要拆到模型能直接执行的粒度“逐句优化”比“提升语言质量”好用一百倍。然后是“输出格式”固定了格式你后续做批量处理或者集成到工作流里都会容易很多。另外SKILL.md里可以加一小节“禁忌事项”。比如论文润色技能里我会写不改动作者的原意、不新增实验数据、不修改参考文献编号。这些约束能有效防止模型自由发挥过度。3.4 脚本在技能里的作用论文润色这个场景里脚本不是必需品但有两个地方脚本特别好用。一是参考文献提取论文里参考文献格式五花八门让模型靠阅读去解析容易出错写个正则脚本提取就稳得多。二是批量处理比如你有二十篇摘要要润色模型每次只能处理一段脚本可以先按段落拆分文本润色完成后自动拼回去。我给extract_refs.py写过一个简化版本大概长这样import re import sys def extract_references(text): # 简单匹配 [1]、[1,2]、[1-3] 这类引用标记 pattern r\[(\d(?:[,\-]\d)*)\] return re.findall(pattern, text) if __name__ __main__: content sys.stdin.read() refs extract_references(content) for ref in refs: print(ref)注意这个脚本只是为了说明“技能里的脚本可以承担什么角色”实际使用时要根据自己的论文格式调整正则。更重要的是你要在SKILL.md里写清楚“什么时候调用脚本、什么时候不调用”。比如我规定当用户要求“提取参考文献列表”时才运行脚本只是润色正文时不要额外跑脚本打断节奏。4. 安装引入与管理从官方市场到本地目录4.1 几种安装路径先说最简单的情况如果你用的是 Claude 这种带有官方市场的产品直接搜索 skill 名称点安装即可。热词里“claude 国内安装 skills 官方市场”说明很多人第一步就卡在这里其实口碑比较好的办法是先用官方客户端或网页版进入 settings 里的 skills 板块找到市场并搜索。这个过程的本质是把远程仓库克隆到本地指定目录所以你也可以绕过市场直接把 GitHub 上的技能文件夹下载下来放到对应目录里。具体路径因工具而异但逻辑一致。以 Claude 桌面版为例技能通常放在~/.claude/skills/每个技能一个文件夹里面要有SKILL.md否则不会被识别。Codex 的安装方式更偏命令行一般通过codex skills install 仓库地址这类命令完成安装后会自动配置执行环境。热词里“idea使用skills”“reasonix如何安装新skills”也属于这一类本质都是“把技能文件放到工具能扫描到的目录”。4.2 安装之后的“冒烟测试”技能装好不代表能用我强烈建议每次安装完都做一次不超过五分钟的冒烟测试。测试步骤很简单新建一个空会话不写任何额外提示词。输入一个该技能覆盖范围内的典型请求。观察模型是否主动提到找到了对应技能。看输出格式是否和SKILL.md里定义的一致。如果没触发检查技能目录名是否包含空格或非法字符检查description是否包含用户可能说的关键词。我自己曾经装了一个“代码审查 skills”结果发了五次请求模型都当成普通问答处理。排查半天发现是SKILL.md的description写的是“Review code”而我在提问时用的是“帮我看看这段代码”关键词完全没接上。后来把 description 改成“审查代码、检查代码质量问题、Code Review”之后第二次就触发了。这个细节很值得记下来。4.3 多个技能之间的优先级管理技能装多了就会出现另一个问题冲突。比如你同时装了“论文润色”和“学术写作助手”模型面对一段论文摘要到底该调哪个很多新手对这个感到头疼。解决办法是在每个技能的description里明确“适用边界”并且可以在SKILL.md的开头加一行“只有在用户明确要求润色时使用不要进行学术写作指导”。我实测下来这句话能明显减少技能之间“抢活”的概率。如果冲突还是严重还有一个土办法把不常用的技能暂时移出 skills 目录放到一个_disabled文件夹里。需要用时再移回来。这比在配置里反复开关快得多而且不会误删文件。5. 使用中的高频问题与排查思路5.1 常见问题速查表我用表格把这段时间遇到最多的问题整理了一下基本覆盖了新手阶段的全部痛点了现象可能原因排查与解决模型完全无视技能description 写得太泛或没包含触发词把触发说法写进 description至少包含三种同义表达技能被调用但输出跑偏SKILL.md 流程不够具体拆步骤每个动作细化到可执行指令脚本执行时报错缺依赖或路径不对确认脚本在 skill 目录下可独立运行不要依赖全局变量会话上下文快速耗尽SKILL.md 或 references 内容过长把长样例移到 references只在主文档保留核心规则两个技能互相冲突description 边界不清加“仅当…时使用”的限制语句排版输出不稳定输出格式描述不够硬用“必须”“不得”等强约束词并用列表固定结构这张表我建议保存下来遇到问题先对号入座大部分情况不需要去翻文档。5.2 一次真实的排查经历有段时间我写了一个“分镜脚本 skills”灵感来自热词里的“分镜skills下载”。这个技能的目标是根据小说章节生成分镜脚本包含景别、运镜、时长、台词。第一次测试就翻车了模型确实调用了技能但输出只有三行字和文档里要求的表格结构完全不符。我翻看生成的日志发现模型只读了SKILL.md里“使用场景”那一段后面的“输出格式”部分完全没执行。原因是我的SKILL.md结构太靠近纯自然语言了细节全埋在段落里模型没抓住重点。后来我重写了文档把所有关键规则全部列表化并在文件最开头用加粗写了一句“输出必须是完整分镜表格不得以段落形式返回”。再测输出质量立刻提升了。这件事给我的教训是技能文档不是文章而是“操作手册”模型阅读效率最高的结构永远是短句、列表、固定格式。5.3 关于“上下文占用”的提醒很多人忽略了一个问题技能文档本身会占用模型的上下文窗口。一个写了两千字的SKILL.md相当于每一次对话都先塞两千字进去。如果同时装了十几个技能光技能内容就可能占掉上下文的一小半留给实际任务的容量就少了。这和你电脑开了太多后台程序导致内存不足是一个道理。解决办法其实很朴素给技能做“瘦身”。主文档只保留流程骨架参考资料全部放到references/目录里让模型按需读取。另外在SKILL.md里明确写出“首次响应只输出关键结论不接受额外解释”也能节省大量 token。我试过把同一套技能从三千字压缩到一千字输出质量没有明显下降但响应速度快了不少。6. 安全边界与我的几点经验6.1 技能里的脚本要慎之又慎因为 skills 可以携带脚本所以安全问题必须正视。一个技能文件夹放到本地后脚本通常以当前用户权限运行。如果脚本来自陌生人仓库里面写了删除文件、上传数据、修改系统配置的操作后果可能很严重。这不是危言耸听社区里已经出现过恶意技能的预警案例。我的建议是三条只安装可信来源的技能官方市场优先。安装后打开脚本看一眼重点关注os.system、shutil.rmtree、requests.post这类敏感调用。给技能运行设置一个独立的临时目录不要让它直接操作主项目文件。这和“自动挖洞 skills”这种安全研究场景其实并不冲突。研究者在隔离环境里把攻击性技能用于实验属于正常测试但对普通用户来说保持谨慎是底线。6.2 skill 不是越复杂越好我见过一些人开发技能时恨不得把所有逻辑都塞进去写了几十页文档、挂了七八个脚本。结果呢模型在第一步就看不懂了脚本互相依赖调试成本极高。我的经验是一个技能只解决一个核心问题。拿论文润色举例你完全可以把“润色”“查重”“生成参考文献”分别做成三个技能。它们可以放在同一个技能目录下但各自独立。这样做的好处是模型触发任何一个技能都不需要加载另外两个的配置上下文更省出错时也更容易定位。热词里“superpower skills”听起来很玄但真正好用的 superpowers往往是那些专注、克制、流程清晰的技能。“superpowers 具体使用”这个问题我自己的答案是别贪多把一个技能打磨到十倍好用比收藏一百个技能有价值得多。6.3 写技能文档的三个反直觉技巧最后分享三个我写作时总结出来的小技巧可能和直觉不太一样。第一个技巧是“先写禁忌再写流程”。因为模型对否定指令的敏感度往往高于肯定指令。你说“不要改变作者原意”比“保持作者意图”更能约束行为。所以我在每个技能文档的开头部分都会先列三到五条“不得做”的事项。第二个技巧是“引用具体的实例”。空泛的规则很难被执行但一个“before-after 示例”能让模型立刻理解你要的风格。我在论文润色技能里放了一个改前改后的对照表模型看到之后输出的风格明显更接近我的期望。第三个技巧是“给技能一个内部代号”。比如把论文润色技能命名为“学术文本清洁工”然后在 description 里同时写“论文润色”“学术文本清洁工”两个说法。模型在处理相关请求时会更容易联想到这个技能。这个方法没有论文级别的原理支撑但在我实测里效果不错。写在最后从一个小技能开始如果你看完这篇文章还是觉得有点抽象我的建议特别简单今天就写一个文档描述你手头最重复的一件事比如周报怎么写、会议纪要怎么整理、代码注释怎么补。然后用三十分钟把它变成一个最简版技能装进你的 AI 工具里试一次。这个动作本身比任何教程都有用因为它会逼你去想“流程到底是什么”“边界在哪里”“怎么让另一个智能体理解我的标准”。等你跑通第一个技能再看那些“skills大全”“skills推荐”你的视角会完全不一样你不再是一个下载者而是一个能判断、能修改、能创造的人。这大概就是 skills 这件事最有魅力的地方。