1. 从提示词到SkillsAI 应用开发正在换玩法这段时间AI 圈子里skills这个词出现的频率高得吓人。前端开发的 skills、安卓逆向的 skills、写论文的 skills、数据分析的 skills甚至还有一套叫 superpowers 的开源技能合集讨论度一路飙升。如果你这几天刷技术社区大概率会看到类似Claude Agent Skills: A First Principles Deep Dive这种标题或者Codex 好用的 skills 推荐的经验帖。坦白讲我第一次看到这个术语的时候也有点懵这不就是提示词吗换个新词又来收割流量但当我真正花时间把官方文档啃完、把几个热门 skill 跑通、再自己动手写了几个之后我的结论变了Skills 确实是把AI 提示词工程推向工程化、产品化的一个关键载体它解决的不是怎么让模型更聪明的问题而是怎么让模型稳定地干好一类活的问题。你可以把 Skill 理解成一本岗位说明书 操作手册 工具箱三合一的手册。过去我们往对话框里贴一段长提示词告诉 AI 你是一个资深前端工程师请按照以下规范完成……然后祈祷它别发挥跑偏。这种方式最大的问题在于提示词只能指挥对话模型每开一个新对话就又得重新讲一遍要求。而 Skills 把这个岗位需要知道的知识、需要遵守的流程、需要调用的脚本、需要输出的模板全部打包在一个目录里模型在需要的时候自己去加载这份手册照着执行。这相当于你第一次给 AI 配了一个真正的同事而不是一个每次都要重新培训的实习生。这篇文章我会从原理到实战把 Skills 这个新生态彻底拆开讲清楚。包括它和普通提示词的本质区别是什么、Claude 和 Codex 两个主流生态各自怎么玩、怎么把网上的热门 skills 正确安装进来、怎么测试一个 skill 靠不靠谱以及最重要的——怎么从零开发一个能解决你自己实际问题的 Skill。内容会比较长但我尽量把每个环节的操作细节和踩坑记录都写进去读完你应该能直接上手。2. Skills 的本质逻辑为什么它不只是一套高级提示词先说一个最核心的问题Skills 的技术底座到底是什么如果你拆开一个真正的 Skill 目录拿 Claude 生态举例它里面通常就是一个名为SKILL.md的 Markdown 文件可能还配一个scripts文件夹放 Python 或 Shell 脚本以及若干参考文档和模板。这个结构看起来极其朴素以至于很多人第一反应是就这这不是我们搞了大半年的 Prompt 模板吗表面看确实像但关键在于加载机制。普通提示词是把几 K 的文本随着对话一起发给模型每次都占用上下文窗口模型只能记得你写了什么。而 Agent Skills 采用了一种被社区叫做渐进式上下文工程progressive context engineering的加载方式模型先只看到每个 Skill 的简介卡片也就是SKILL.md里的 YAML frontmatter只有它判断当前任务确实需要用到这个技能时才会主动去读取完整的 SKILL.md 正文进而再按需读取里面的脚本代码和参考文档。用生活里的例子类比就是普通提示词像你往背包里塞了一整套《装修施工规范》不管做不做装修都得背着走包又重又乱。而 Skills 是你家门口挂着一个工具箱你路过时要拧螺丝打开看里面有一张卡片写着本箱包含螺丝刀、扳手及各型号螺丝对应表于是你只拿出需要的工具剩下的还在箱子里等着下次用。这让模型在一个复杂任务里可以按需取用多种专业能力而不会因为上下文太长而思维混乱或者跑题。这套机制解决了三个非常现实的问题第一上下文长度瓶颈。现在的模型上下文窗口虽然越做越大从 128K 到 1M但塞得下不等于用得好。模型对长上下文的注意力会衰减中间的细节容易被忽略。如果你把十个岗位的技能手册全塞进去模型大概率会在关键步骤上失忆。Skill 的动态加载让模型每次只面对当前最相关的几百行指令专注度完全不一样。第二能力的标准化封装。没有 Skills 之前每个团队都在自己维护一套给 AI 的 SOP文档格式五花八门有的写困惑有的写太细。SKILL.md 用统一的 frontmatter、统一的正文结构、统一的脚本约定让教 AI 干活这件事变成了一种可以被分发、被复用、被评测的标准化产品。你在 GitHub 上拉下来一个 Skill放进约定的目录就能跑这体验和之前那种 CtrlC/CtrlV 提示词完全不同。第三Agent 的自主性。传统提示词是给定任务就立即执行而 Skill 文件里通常包含决策规则比如当遇到 X 情况时走方案 A当遇到 Y 情况时走方案 B。这让 AI 不是机械地执行一串指令而是像一个有经验的员工能自己判断情况、选择流程、调用对应工具。配合 Agent 的规划能力一个携带 5-10 个 Skill 的 Agent 可以承担相当复杂的端到端工作。顺带说一句skills这个术语在历史上也指 GitHub 的交互式学习课程GitHub Skills以及 LinkedIn 上的个人技能标签。但近期这波热度几乎全部指向LLM Agent Skills模型代理技能。大家在讨论的是 Claude Agent Skills、Codex Skills以及围绕它们形成的开源生态。看热词列表里agent skills 测试skills 开发reasonix 如何安装新 skills这类词就知道大家关注的是实实在在的怎么给我的 AI 配技能。3. 主流生态速览Claude Skills、Codex Skills 与开源技能合集3.1 Anthropic 的 Claude Agent Skills目前最完整的参考实现Claude指的是 Claude CodeAnthropic 的命令行编程助手推出 Agent Skills 后社区立刻炸了原因很简单它的设计是目前最接近标准的。一个 Claude Skill 的基本目录结构大致长这样my-skill/ ├── SKILL.md ├── scripts/ │ ├── analyze.py │ └── format.py ├── references/ │ ├── best-practices.md │ └── checklist.md └── templates/ └── report-template.mdSKILL.md是整个技能的核心开头必须有 YAML frontmatter--- name: my-skill description: 用于 X 场景下完成 Y 任务当用户需要处理 Z 类问题时使用。 ---这两行极其重要。name 是技能的身份标识description 是模型决定要不要调用这个技能的唯一依据。写法很有讲究后面我会专门说。正文部分则是岗位说明书 操作手册的结合体包括任务的背景与目标、执行步骤、调用脚本的命令、需要遵守的规范、输出格式要求、常见错误与规避方法。整份文件用自然的 Markdown 写作大部分是一步步的指引。在 Claude 里启用 Skill 只需要把它放进~/.claude/skills/目录全局或者项目的.claude/skills/目录局部然后打开 Claude Code输入/skill查看列表、/skill 技能名手动调用或者直接甩一个任务让它自己判断。实测下来放到项目目录里效果最好因为模型能结合项目代码上下文来判断何时加载。3.2 OpenAI Codex 的 SkillsAGENTS.md 里的由浅入深OpenAI 这边Codex 也支持 Skills 的概念不过它的方式稍有不同。Codex 使用的核心配置是AGENTS.md文件——这是一个放在项目根目录的指导文件告诉 Codex 这个项目怎么构建、用什么命令、有哪些注意事项。Skills 本质上是把AGENTS.md从项目根目录下沉到.codex/skills/目录旧版叫~/.codex/skills/每个技能一个子目录同样有一套规范和加载约定。Codex SDK 有skills工具接口支持列举已安装技能、检索技能详情。和 Claude 相比Codex 的 Skills 文件格式更宽松一点官方文档甚至可以用纯 Markdown 写一个浓缩版指南。不过社区普遍的反馈是Claude 的技能生态更丰富因为 Anthropic 的官方文档和模板更具体而且 SKILL.md 的 frontmatter 机制让什么时候用哪个技能这件事更可控。你要问哪个更好我的答案是你用哪个 Agent 产品就用哪个生态。工具是服务于工作流的别为了炫技硬跨平台。3.3 爆火的 superpowers一套改变我工作习惯的开源技能集热词里有两个名字特别亮眼superpower skills和superpowers 具体使用。这套东西是社区开发者 obraJesse Vincent做的开源技能合集目前热度极高GitHub 上 star 数量涨得飞快。superpowers 的核心思路和普通的功能性技能不太一样。绝大多数技能解决的是让 AI 会做某件事写论文、改代码、分析数据而 superpowers 解决的是让 AI 像一个优秀的团队成员一样思考和工作。里面包含了诸如 Brainstorming头脑风暴、Planning项目规划、Executing a Plan计划执行、Writing 等工作流技能每套技能都包含详细的分步引导AI 会和你进行多轮交互式对话而不是一次性甩出结果。我花了一整个晚上研究 superpowers 的源码一个很大的感受是它把好的项目经理如何推进工作这件事硬生生系统地教给了 AI。比如 Planning 技能它会要求模型先和你确定目标、约束条件和验收标准然后拆解任务、估算工作量、排优先级、制定里程碑最后才进入执行。这套流程如果靠普通提示词最多只能约束一次对话但做成 Skill 后AI 在整段工作过程中都会反复参考这份操作手册行为的稳定性高得多。安装 superpowers 也不难官方推荐直接把它作为 Claude Code 的技能目录克隆下来即用或者使用社区开发的一键安装工具。装完后你会看到一长串技能列表每个都是 SKILL.md 的实现。如果你是第一次接触 Skills我强烈建议你先装一套 superpowers 感受一下AI 主动和你对齐需求是什么体验这比你自己瞎写技能快得多。3.4 其他值得关注的来源GitHub Skills、reasonix、workbuddy 等热词里还有几个高频面孔简单做个来源说明GitHub Skills和这次的 LLM Agent Skills 概念是两码事它是 GitHub 官方用来教用户学 Git、学 Actions 的交互式课程。但很多人搜skills会撞到这个入口如果你本身想顺手学一下 GitHub 协作倒也是正经收获。reasonix是一个主打推理增强的 skills 包从热词reasonix 如何安装新 skills来看它的安装方式和 Claude 标准技能目录一致把包内容放进技能目录即可。它里面的技能偏向复杂推理任务比如多步逻辑推导、假设分析与验证适合做研究类工作。workbuddy skills 写论文这组热词很有意思——workbuddy 是一个新兴的 AI Agent 平台也支持类似 skills 的插件机制。它里面有很多第三方开发的论文写作技能包括从文献调研到大纲生成再到逐章撰写的工作流。这类垂直平台的 Skills 生态是今年的大趋势几乎每个 Agent 产品都在尝试搞技能市场。安卓脱壳 skills和自动挖洞 skills则说明技能生态已经在向安全研究领域渗透。这类技能通常封装了一系列逆向分析工具链的操作流程和常见特征的识别规则让 AI 能辅助完成样本分析、脱壳方案的选型等偏专业的工作。这个领域的 Skills 需要谨慎使用必须遵循授权测试与法律法规但作为辅助学习工具它确实让新人面对 APK 样本时不再一头雾水。后面我会单独聊一下安全类技能的正确打开方式。4. 实操环节怎么把现成的 Skills 装进你的 Agent 里4.1 在 Claude Code 中安装与启用 Skill这一步几乎是纯体力活但细节决定成败我直接给完整流程。第一步确认环境。你需要安装最新版的 Claude Code命令行工具并且登录了自己的账号。然后在终端里运行claude --version如果版本太老建议先升级。Skills 功能要求比较新的版本旧版可能根本不识别技能目录。第二步创建技能目录。Claude 支持两个层级的技能目录全局目录~/.claude/skills/所有项目都能用项目目录你的项目/.claude/skills/只对当前项目生效我个人的习惯是通用的技能写周报、代码审查、数据分析放全局和具体项目绑定的技能这个仓库的构建规范、测试流程放项目目录。因为放项目目录里模型能结合项目上下文更好地触发技能而全局目录容易造成技能泛滥模型有时候会挑花眼。第三步安装技能。从 GitHub 上把一个技能仓库克隆下来然后复制到目标目录git clone https://github.com/xxx/some-skill.git cp -r some-skill ~/.claude/skills/或者更精简的做法直接用curl拉取远程的 SKILL.mdcurl -L https://raw.githubusercontent.com/xxx/some-skill/main/SKILL.md -o ~/.claude/skills/xxx/SKILL.md注意必须保留技能名作为子目录名目录结构不能平铺。比如你不能把一堆 SKILL.md 全都直接扔在~/.claude/skills/根目录下正确的结构是~/.claude/skills/skill-a/SKILL.md、~/.claude/skills/skill-b/SKILL.md。这个看似无关紧要的细节搞错了技能就不会被识别。第四步验证与使用。启动 Claude Code输入/skill这时候应该能看到你安装的所有技能列表。如果列表里没有大概率是 frontmatter 格式问题或者目录层级不对。想强制让模型用某个技能时输入/skill 技能名即可。但更多时候我会直接描述任务让模型自己判断要不要加载——这更接近真实工作流。4.2 在 Codex 中安装与使用 SkillCodex 这边操作风格类似技能目录通常是~/.codex/skills/或项目下的.codex/skills/。安装时同样是克隆或复制目录进去。启用后Codex 在运行时会自动索引这些技能。Codex 的 AGENTS.md 文件和 Skills 之间的关系我多说一句项目根目录的 AGENTS.md 是必读而 Skills 是选读。你可以把 AGENTS.md 理解成一个电梯演讲——告诉 Codex我们这个项目是干嘛的、怎么跑起来而 Skills 是更深度的操作手册只有遇到对应任务时才加载。合理的分工是AGENTS.md 保持简短把专业流程全部放进 Skills。这也符合渐进式上下文工程的核心思想。从社区反馈来看Codex 对技能目录的识别比较宽容但正因为结构要求宽松不同作者的技能质量参差不齐。安装第三方技能前建议先看看 SKILL.md 有没有清晰的 frontmatter如果连 frontmatter 都没有这个技能多半是随手写的效果别抱太大期望。4.3 技能测试方法论不是装上能跑就完事了热词里有agent skills 测试说明很多人已经意识到技能不是装上就完测过才知道好不好用。我整理了一套自己的技能测试流程适用于任何生态第一步单元测试式调用。直接在会话里输入/skill 技能名强制加载然后给一个最简单的、符合技能描述的测试任务。比如测一个周报生成技能就给三条本周做的事让它按技能模板输出周报。这一步主要验证技能能不能被正确触发、流程能不能走通。第二步边界测试。给一些擦边的任务——不完全符合技能描述或者输入信息缺失的。好的技能会主动向你索取缺失的信息而不是强行编造差的技能会直接按着错误假设跑下去。这一步最考验技能的质量。第三步稳定性测试。同一个任务跑 3-5 遍看输出质量是否稳定。重点观察模型有没有在使用技能的过程中跑丢——比如前面还在按脚本执行后面就开始自由发挥了。如果多次出现跑丢说明技能文档的结构不够强约束后面开发时会讲到怎么优化。我自己踩过的一个坑是很多技能在第一次运行时好用是因为当时模型版本对指令的理解能力在线过了一两周换了新模型版本同样的技能可能就不触发了。所以每当我们用的模型大版本升级建议花十分钟把主力技能重新跑一遍测试集否则容易在关键时刻拉垮。4.4 安装时最容易踩的几个坑根据我自己的经历和社区里大量提问帖安装技能最常见的坑有这么几个坑一目录结构弄错。前面说了技能必须放在以技能名命名的子目录里。很多人把下载的 SKILL.md 直接丢进根目录列表里死活不显示折腾半天。坑二frontmatter 写错。YAML 的冒号后面必须有空格name: foo而不是name:foodescription 必须用双引号包裹或者避免冒号等特殊字符frontmatter 必须以---开头和结尾缺失任何一个都会导致解析失败。这里最诡异的是有些工具解析失败时不会报错只是静默地不显示这个技能。坑三技能之间的描述冲突。如果你装了十来个技能每个的描述都写得模棱两可模型会很难选择。比如当用户需要帮助时使用这种描述等于什么都没说。结果就是模型随机挑一个技能或者干脆都不挑直接自由发挥。这个问题在技能多了之后尤其严重后面我会专门讲怎么写好 description。坑四忽略了依赖脚本。很多技能不是纯 Markdown它可能依赖 Python 包、Node 工具链或者其他命令行工具。装技能前先看一眼 scripts 目录里有什么把依赖装好。否则模型调用脚本时抛异常它会一脸无辜地告诉你我执行失败了。5. 从零开发一个 Skill完整实操与经验教训5.1 选题什么任务值得做成一门技能在动手写 SKILL.md 之前先想清楚你要封装的这个任务是不是真的适合做成技能我的判断标准有四个第一任务出现频率够高。如果只是临时用一次的工作直接用普通提示词就好不值得做成技能。第二任务有稳定的流程。比如分析服务器日志并生成报告步骤相对固定读取日志、统计错误码、识别异常模式、输出报告。这种有章可循的任务最适合技能化。第三任务需要领域知识。比如写符合 IEEE 风格的论文里面涉及格式规范、引用规则、常见错误这些知识量很大不适合每次对话重新解释封装成技能最合适。第四任务完成标准要可检验。技能的效果要能判断——报告格式对不对、代码有没有通过测试、日志有没有分析到位。如果任务结果无法量化技能的质量就很难把控。拿我自己举例。我日常工作里有一块是处理用户反馈的文本分类之前每次都要在提示词里详细描述分类逻辑、标签体系和输出 JSON 格式很繁琐而且模型偶尔会忘掉某些标签。于是我开发了一个feedback-tagger技能把标签体系、分类规则、输出模板和几个典型例子全部写进 SKILL.md。从那之后每次处理反馈邮件模型会自动加载技能输出质量稳定多了我再也不用复制粘贴一大段提示词。5.2 动手写 SKILL.md一个可以直接照抄的骨架写技能文件我推荐遵循 Claude 官方文档里的三段式框架技能做什么的清晰定义、执行步骤的详细说明、参考材料和注意事项。先给出一个可以直接改写的通用模板--- name: skill-name description: 在 X 场景下执行 Y 任务的技能。当用户需要 Z 时使用。必须提供 W 信息后开始。 --- # 技能名称 ## 技能目标 帮助用户完成……任务。适用于……的场景。 ## 执行步骤 1. 收集必要信息 - 输入信息 A用于…… - 输入信息 B用于…… 2. 处理过程 - 调用脚本 python3 scripts/process.py 对数据进行预处理 - 根据规则表判断…… 3. 输出结果 - 按模板 templates/output.md 生成内容 - 输出前检查…… ## 常见错误与规避 - 错误 1…… - 规避方法…… ## 参考资料 - references/example.md完整示例这里有几个容易忽略的细节步骤描述要可执行而不仅仅是可理解。不要写分析数据而要写使用pandas读取data.csv按type列分组统计数量并将结果保存到analysis/result.json。模型不是人它不会想到该怎么做它只会按你写的做。要写清边界条件和验证规则。检查输出格式是否符合……如果不符合重新生成这类指令能显著降低模型跑飞的概率。提供示例永远不嫌多。frontmatter 里的 description 指向抽象的触发条件正文里的示例指向具体的输入输出。模型模仿示例的能力很强质量好的 examples 能直接拉高输出的下限。5.3 脚本、模板和参考资料的组织方式SKILL.md 是说明书但真正干活时还要靠配套文件。参考我之前的目录结构skill-name/ ├── SKILL.md ├── scripts/ │ ├── process.py # 核心处理脚本 │ └── requirements.txt # Python 依赖 ├── references/ │ ├── taxonomy.md # 领域分类体系 │ └── examples.md # 完整输入输出示例 └── templates/ └── report.md # 输出模板关于脚本有几个问题社区里讨论得很多我说一下我的做法。脚本要不要写如果任务能用纯文本规则解决比如分类、格式化、检查清单可以不用脚本纯靠说明文字。但如果涉及文件解析、批量处理、外部 API 调用写一个脚本能让工作流稳定得多。一个有用的分界线是如果这个任务用awk或 Excel 能搞定就先别上脚本如果用 Python 才能批量处理的就果断把脚本封装进去。脚本怎么写才能被模型正确使用记住你的脚本是给AI 小工用的它可不认识你的编程风格。所以每个脚本都要写得像给实习生的交接文档在脚本开头的 docstring 里写清楚输入参数、输出文件、依赖库。比如 usage: python3 scripts/process.py input.csv output.json 读取 input.csv 中的原始数据按 type 列聚合统计输出为 output.json。 依赖pandas、numpy。安装pip install pandas numpy 别觉得啰嗦。模型每次调用脚本时都会先读这些说明说明越清楚出错越少。5.4 写好 description 是一门学问这个部分我要单独拎出来讲因为太多人栽在这上面。模型在决定要不要加载这个技能时只能看到 description 那一小段文字。如果这段文字写得模糊、泛化、不具区分度你的技能就相当于不存在。社区里有个形象的比喻description 就是技能的电梯推销——只有 5 秒钟抓住对方的注意力技术细节展示得再好都没机会。怎么写好我给几个原则原则一包含具体触发词。比如一个日志分析技能description 里直接写当用户要求分析日志、查看报错、追踪异常时使用。这些是模型识别的锚点。原则二说清使用条件。比如仅当输入文本为英文且长度超过 500 词时使用。这样模型不会把它用到无关场景。原则三明确说明不适用的情况。比如本技能不适用于图片内容分析。这能拦住模型误用。原则四保持简短。description 最好控制在 2-3 句话内。写太长不等于信息多反而会让模型在快速扫描时抓不住重点。我自己测试过同一个技能description 从处理用户反馈改成当用户要求对用户反馈文本进行分类和标签提取时使用输入为 CSV 或 JSON 格式的反馈列表输出为 JSON 格式的分类结果触发率从大约 30% 提升到了 90% 以上。这个差距是决定性的。5.5 用测试驱动你的技能迭代开发完技能别急着宣布完工。我建议建立一个最小测试集每次改动都跑一遍# 测试 1技能能否正确触发 # 输入请把这份反馈数据按类型分类 # 期望模型加载了 feedback-tagger 技能 # 测试 2核心流程能否走通 # 输入给了 10 条反馈记录 # 期望输出完整 JSON标签全部正确格式符合模板 # 测试 3边界情况 # 输入只有 1 条反馈且内容极其简短 # 期望模型主动询问补充信息而不是硬着头皮分类 # 测试 4抗误导测试 # 输入一个明显不属于本技能的任务 # 期望模型明确拒绝加载技能或提示用户任务不匹配测试中发现的每一个问题回去修改 SKILL.md 后重新跑。这个过程很像训练新人一次不行就再教一次只不过你教的不是人是文档。6. 社区里的优质 Skills 推荐与场景化应用6.1 论文写作类技能从文献到成稿的流水线热词里workbuddy skills 写论文codex 写论文的 skills出现的频率很高说明学术写作是技能生态里最活跃的场景之一。这类技能通常做的事包括文献检索策略建议、论文大纲生成、章节写作模板、引用格式检查、行文风格调整等。一个理想状态的论文写作技能应该让 AI 先和你确认研究问题和目标期刊然后帮你在指定数据库检索文献、梳理相关工作、生成提纲再逐节撰写初稿最后按目标期刊格式规范排版并生成参考文献。如果要更严谨文献筛选与信息提取目前也主要是让 AI 从你提供的 PDF 或 API 返回的摘要中完成输出仍需你逐条核对。我用过的技能里表现比较突出的是基于 Claude Agent Skills 生态的academic-writer类技能它的优点是流程拆得足够细从读摘要判断相关度到生成文献矩阵再到按段落写引言每一步都有明确的输入输出约定模型不容易迷路。6.2 编程与工程效率类让 AI 真正理解你的项目前端开发的 skills、代码审计的 skills、自动重构的 skills这些都是编程类技能的热门方向。适合做成技能的编程任务有一个共同特征它们依赖项目专属知识。比如如何在这个项目里新增一个 API 接口——这个任务不是通用的编程问题它需要知道项目用的框架、目录结构、代码风格、已有组件的调用方式。把这些信息写进 SKILL.mdAI 才能对项目上手否则它只能用通用知识硬答答得漂亮但不落地。我看到有不少团队把项目的编码规范、构建流程、测试命令、部署步骤都封装成了技能。这样每次新成员加入不再需要花两周时间问东问西直接把技能丢给 Claude Code 或 Codex它就能按项目规范产出代码。这其实把团队知识管理这件事从人的脑子里搬到了机器的上下文里价值挺大的。6.3 数据分析与研究类技能从取数到出报告的自动化数据分析是另一个非常适合技能化的场景因为数据工作流天然具有步骤固定、参数多样的特点。一个标准的数据分析技能应该包含数据读取脚本支持常见格式、清洗规则说明缺失值处理、异常值识别、分析流程指引分组聚合、趋势计算、可视化命令以及最终分析报告的 Markdown 模板。开发这类技能时我的建议是把数据处理的脏活累活尽量写成脚本把分析判断的灵活部分留给模型。比如清洗数据这种任务机器做最靠谱而这份数据呈现了什么趋势、可能是什么原因这种开放性问题模型更有优势。分工明确技能才高效。6.4 安全研究领域合规前提下的逆向辅助技能热词里的安卓脱壳 skills和自动挖洞 skills其实指向了一个正在兴起的垂直方向安全研究辅助。这类技能把常用的逆向工具链抓包、静态分析、动态调试的操作流程以及常见样本特征的识别方法封装起来让 AI 能辅助分析陌生人发来的可疑样本或者在授权测试中协助审计代码。这里我必须多说一句合规问题这些技能永远是辅助分析工具使用前提是获得明确授权并遵循法律法规。无论是脱壳还是挖洞都必须局限在自己拥有或有明确测试授权的范围内。我见过有人把这类技能当成一键攻击器这是完全错误的理解。技能只是一个操作手册 知识库它让分析过程更规范但绝不能用来越权做任何事。想做安全方向的朋友先学会规则再谈技巧这条路才能走远。6.5 效率与生活类Nature Skills 和日常工作流热词里还有个nature skills我查了下现在很多讨论其实指的是自然语言交互技能或一些主打生活效率场景的技能合集。这类技能做的事比较杂写周报、做行程规划、整理会议纪要、起草邮件、整理读书笔记等。不要小看这类低技术含量的技能。我实测过一个会议纪要素材整理技能它的价值不在于记录会议内容这点模型本来就会而在于它强制模型按固定结构输出决策事项、待办事项、负责人、截止时间、风险点。这个结构输出让后续的项目管理变得异常轻松。很多技能的价值不是让 AI 能做这件事而是让 AI 每次都用同样高质量的方式做完这件事。稳定的高质量输出本身就是巨大的效率提升。7. 常见问题与排查技巧实录7.1 模型就是不调用我的技能怎么办这是最典型的问题。按照我的排查顺序来先确认技能目录结构是否正确用/skill能列出就说明结构没错确认 description 写得是否具体。把分析数据改成当用户提供 CSV 或 Excel 文件并要求统计分析、生成可视化图表时使用确认测试任务是否真的匹配技能描述。有时候不是模型笨是你给的任务描述太模糊它没识别出来试试手动调用作为临时方案但长期来看还是要优化 description我见过最离谱的一个案例是技能名里有大小写问题目录名是MySkill但 frontmatter 里 name 是myskill模型匹配时对不上号导致永远不触发。这种小细节排查起来很费时所以命名统一用「全小写加连字符」的惯例最省心。7.2 技能触发了但执行到一半跑飞技能能触发是第一步执行质量不稳定是第二步。跑飞的原因通常是 SKILL.md 正文的约束力不够。排查思路把 SKILL.md 里那些软性描述找出来——比如根据情况进行处理合理判断这类词然后替换成明确的条件分支如果 X 条件成立执行 A 步骤否则执行 B 步骤。模型的执行逻辑是概率性的它的默认偏好就是走最短路径如果你的文档留了太多自由发挥空间它一定会自由发挥。另一个常见原因是脚本调用失败后模型不知所措。这时候要在技能里写清楚错误处理方案如果脚本返回错误码请检查依赖库安装情况并用pip list输出已装包列表来分析原因。把错误恢复流程也写进技能执行稳定性会提高很多。7.3 技能装太多模型选择困难怎么办技能不是越多越好。我一开始也是什么都想装后来发现技能库膨胀到 50 时模型经常在多个相似的技能之间犹豫不决甚至选错。这个问题和工具选择问题非常类似。解决办法有两个方向一是减少技能数量保留最常用的其他的只留到需要时再临时安装二是优化 description 的区分度确保每个技能的触发场景和条件边界清晰不收窄到彼此重叠。如果非要装很多技能可以考虑按用途建立技能组合比如文档处理组数据分析组让不同组合面对不同任务。7.4 技能的版本更新与维护技能不是写完就一劳永逸的。模型在升级、依赖在变、你自己的工作流也在变技能需要定期维护。我的习惯是每两周花半小时过一遍主力技能的测试集发现输出质量下降就及时调整 SKILL.md。如果技能是来自社区的跟踪上游更新也很重要。很多开源技能更新很频繁拉了新版本后记得重新跑一遍测试。另外一个容易忽略的点是技能目录里的脚本依赖要用 requirements.txt 锁版本不然环境升级了脚本可能就崩了。这些都是血泪教训。8. 最后分享一点个人体会Skills 这套东西我研究得越深入越觉得它其实是提示词工程发展到一个阶段的必然产物。当和模型对话变成带模型工作我们就需要把工作方法论、领域知识和操作工具打包成可复用、可分发、可评测的模块。Skills 恰好提供了一套切实可行的封装规范。现在回头看我自己之前写过的几十条长篇提示词很多都能改写成更稳定的技能文件——同样的效果但维护成本低得多复用率高得多。根据我个人操作中的体会如果你刚开始接触 skills我的建议是先别急着开发自己的技能因为你对什么内容适合技能化还没有感觉。先去安装 superpowers 这类成熟技能包认认真真用几天看看它们怎么拆解任务、怎么写步骤、怎么和用户交互。接着试着改一个小技能——比如把你自己常用的某条提示词转成 SKILL.md跑通第一遍之后再逐步加脚本、加模板、加边界处理。技能的开发是一个需要反复打磨的活但你产出的每个技能都会是你之后所有 AI 协作工作的基础设施。最后再分享一个小技巧不要只把技能当成个人效率工具。你可以在团队里创建一个共享的技能目录把团队的项目规范、编码约定、交付流程都写成技能。这样每个成员在 AI 工具里都能获得一致的团队记忆。这件事的长期价值我觉得比大多数单点提效技巧都要大。