尧图网页设计 
1. Skills 到底是什么从“调教AI”到“沉淀技能”的一次范式转移最近几个月“skills”这个词在开发者圈子里出现的频率高得吓人。从前端开发群里有人问“有没有好用的 code review skills”到推特上有人晒“用 agent skills 十分钟写了个论文大纲”再到 GitHub 上各种 skills 合集仓库动辄几千 star——你很难忽略这个趋势。但如果你去翻官方文档会发现“skills”这个概念解释得特别抽象它通常被描述为“一种为 AI 助手提供专项能力的文件化机制”。听起来像是提示词又像是工具配置还有点像插件。很多人第一次接触时确实分不清这四者的边界这很正常。我的理解是这样的Skills 本质上是把一套完整的、可复用的“做事方法”打包成标准化的文件让 AI 助手能按这套方法高质量地执行特定任务。它和普通提示词最大的区别在于结构化和工程化——提示词是“你告诉 AI 怎么干”Skills 是“你给 AI 一套带说明书、带最佳实践、带示例参考的操作手册”。打个比方。你让一个实习生帮你整理客户资料你可以口头交代“把资料按行业分类重点客户标出来”——这是提示词。但如果你给实习生一份SOP手册里面有分类标准、标注规则、优先级判断逻辑、历史案例参考、常见异常处理方式——这就是 Skills。所以 Skills 解决的本质问题是通用大模型什么都会一点但什么都不精。你想让它稳定地产出专业水准的结果就得把专家脑子里的隐性知识显性化变成文件让它读。这正是“skills 推荐”“skills 大全”这些词这么火的原因——大家都在找别人沉淀好的高质量技能包。1.1 Agent Skills 与 MCP、Prompt 的本质区别现在市面上还有两个概念经常和 Skills 混在一起MCPModel Context Protocol和普通 Prompt。我直接说结论免得你去翻几十篇文档。Prompt 是“一次性指令”它不承载复杂逻辑也不具备状态。你每次对话都要重新交代一次AI 的表现完全取决于你这次说得清不清楚。它适合简单任务不适合稳定复现。MCP 是“工具接口标准”解决的是 AI 怎么连接外部系统。比如让 AI 能查询数据库、调用 API、读写文件系统。MCP 的重点是“连接”能力解决的是 AI 的“手脚”问题。Skills 解决的是“方法”问题——它告诉 AI 如何像一个资深从业者那样思考和执行。如果说 MCP 是给 AI 装上了手和脚Skills 就是给 AI 装上了脑子和经验。当然这三者不是互斥关系。我在实际项目中经常把它们组合使用通过 MCP 连接代码仓库和 CI 系统通过 Skills 注入代码审查规范和架构评审清单再配合一段简短的 Prompt 说明本次任务目标。这是目前我见过的最稳的组合方式。1.2 为什么 2025 年 Skills 突然火了Skills 概念的爆发有几个技术前提。首先是上下文窗口变大后AI 有能力“读完”一份完整的技能文档再执行任务——以前 8K 上下文的时候塞一份几千字的规范进去就什么都干不了了。其次是 Agent 类应用的成熟让“AI 自主调用方法”成为可能而不只是聊天框里一问一答。还有一个很实际的原因企业需要知识沉淀。很多团队发现用提示词共享经验根本不靠谱——一句话提示词根本承载不了复杂的业务逻辑。但 Skills 是文件化的可以放进 Git 仓库管理、可以做版本控制、可以 review、可以测试。这正好契合了工程团队的工作习惯。我在几家公司的技术群里看大家讨论 skills 开发聊得最多的不是“怎么写提示词”而是“怎么设计目录结构”“怎么写 SKILL.md 的 frontmatter 才不会报错”——这已经不是提示词工程的路子了这是软件开发的路子。2. 主流平台的 Skills 生态Claude、Codex 与 GitHub 上的优质仓库热词里出现了“claude agent skills: a first principles deep dive”“codex skills”“前任skills官方下载”“github skills”这些关键词看得出来大家的关注点主要在两大平台Anthropic 的 Claude 和 OpenAI 的 Codex。我两个平台都用过一段时间各自的生态差异还是相当明显的。2.1 Claude Agent Skills首推的成熟方案Claude 的 Skills 机制是目前最完整的。它基于 SKILL.md 文件组织放进项目的.claude/skills/目录下就能被 Claude 自动发现。这个目录有点像浏览器插件目录Claude 会自动扫描根据任务上下文调用合适的技能。官方对每个技能的要求是包含 YAML frontmatter声明名称和描述 Markdown 正文说明使用时机、步骤、规范、示例。名字必须全小写字母加连字符描述要写清楚“这个技能什么时候该用”。这个设计我觉得是有讲究的——描述写得好不好直接决定 AI 能不能在合适的时机触发这个技能。很多人写技能不触发八成是描述写得模糊。我用 Claude Skills 写过一套前端代码审查技能放在.claude/skills/code-review/下效果比我想象中的好。它能主动检查 props 命名规范、组件拆分合理性、性能隐患甚至能指出我代码里状态管理设计的问题。这种体验和以前“把提示词复制粘贴到对话框”完全不一样——AI 是在它的原生工作流程里主动调用技能而不是你手动“喂”给它的。2.2 Codex Skills面向编码任务的另一个流派Codex 的 Skills 机制更偏向编码场景。它的配置方式和 Claude 类似Skill 文件里除了指令外还经常包含可执行的脚本、测试用例模板、风格指南等。Codex 对“可验证性”的重视程度更高——它生成代码时会主动加载技能里的规范来约束自己的输出。我在用 Codex 跑代码审查和重构任务时发现它的 Skills 很适合“自动挖洞”——这个词在安全圈是漏洞挖掘的意思。把安全审计 Checklist 做成 SkillCodex 可以自动扫描代码中的常见漏洞点。这里提醒一句这类技能只会用于你自己的项目或明确授权的渗透测试不要拿去干不合规的事。Codex 的生态还有一个特点社区仓库非常多。GitHub 上有一堆“codex 好用的 skills”合集从写论文到生成分镜脚本都有。热词里“codex写论文的skills”和“分镜skills下载”说明很多人已经在用它做内容创作了不只限编程场景。2.3 GitHub 上的 Skills 仓库怎么筛选GitHub 上 skills 仓库虽然多但质量参差不齐。我筛选的标准有四条看是否有明确的目录规范好的仓库每个技能都独立成文件夹里面有 SKILL.md有示例文件看 frontmatter 是否规范name、description 字段是否清晰看是否有测试或示例光有描述没有示例的大概率是凑数的看更新时间AI 工具变化快半年不更新的仓库基本可以放弃了我自己常用的是 GitHub 官方出的 Skills 学习路径仓库和一些社区整理的合集整体上质量比较可靠。下载后放进自己的项目里试用一遍能跑通再留下不能跑通就删掉——这是最朴素的筛选逻辑。3. 手把手开发一个自己的 Skills从设计到落地热词里“skills开发”出现频率很高说明已经有大量的人不满足于用别人的技能开始想着自己写了。其实开发一个 Skills 没有想象中那么复杂我拿一个实际案例走一遍完整流程你跟着做一遍基本就通了。3.1 设计思路先想清楚“AI 缺什么”在写任何代码之前建议先回答一个问题你希望 AI 用这个技能后在哪个环节表现得比默认状态更好我举一个我实际做过的例子。做前端开发时我经常让 AI 帮我生成 React 组件的单元测试但默认状态下的 AI 写出来的测试有两个问题一是只测 happy path不测边界情况二是mock 方式不统一有时候 mock 组件有时候 mock 函数。所以我设计了一个“前端单测编写技能”核心目标就一个让 AI 写的测试符合我们团队约定好的规范。设计思路明确之后技能的内容大纲自然就出来了测试文件命名规范、mock 的统一策略、边界情况检查清单、常用断言风格、一段完整示例测试代码。你看这个过程其实和写团队文档很像只是最后的目标读者是 AI。3.2 目录结构与 SKILL.md 的标准写法一个最基础的技能目录长这样.skills/ ├── unit-test/ │ ├── SKILL.md │ └── examples/ │ └── button.test.tsxSKILL.md 是最核心的文件。它分成两部分第一部分是 YAML frontmatter第二部分是正文。我的模板一直是这样--- name: unit-test description: 编写符合团队规范的 React 组件单元测试。当用户要求为 React 组件编写测试、补充测试用例时使用。 ---注意几个细节。name 只允许小写字母和连字符不允许空格和驼峰。description 不能只写“用于编写测试”这种模糊表述要写清楚“什么时候该用”AI 是靠这个判断触发时机的。我在多次实验中发现描述里包含“当用户提出 XX 请求时”这种条件句式触发准确率会高很多。正文部分同样要用 Markdown 写内容结构我会固定成这几块使用时机明确说明在什么场景下调用这个技能核心规则用列表列出 AI 必须遵守的硬性规则执行步骤分步骤描述完成任务的流程示例放一个完整的、标注了说明的示例3.3 渐进式披露Skills 的核心设计哲学关于 SKILL.md 正文官方文档里有个概念叫“渐进式披露”Progressive Disclosure这是整个机制里最值得琢磨的点。大模型的上下文窗口是有限的如果技能文件写得巨长AI 读完你的技能就没心情干活了而且重要信息反而被淹没。渐进式披露的意思是SKILL.md 里只写核心信息和必要规则让 AI 能快速理解技能的目的和边界更详细的操作指南、参考示例、模板代码放在同一目录下的其他文件中AI 在需要时再加载。.skills/ ├── unit-test/ │ ├── SKILL.md │ ├── testing-guide.md # 详细规范指南 │ ├── mock-strategies.md # mock 策略说明 │ └── examples/ │ ├── button.test.tsx │ └── form.test.tsxSKILL.md 里可以这样引导当需要了解 mock 策略时阅读 mock-strategies.md 文件。 为组件编写测试时参考 examples/ 目录下对应的示例文件。这种写法的好处是AI 每次读取技能时只消耗少量上下文不会影响主任务但真正需要细节时又能找到。我见过的大部分劣质 Skills问题就出在把 SKILL.md 写成了一个几千字的巨型文档AI 根本消化不了。3.4 一个完整示例JSON 数据清洗技能光讲理论容易虚我直接把一个“JSON 数据清洗”技能的 SKILL.md 完整写出来你可以直接抄去改。--- name: json-clean description: 对 JSON 数据进行清洗和规范化。当用户提供 JSON 数据要求清理脏数据、规范格式、去除冗余字段时使用。 ---# JSON 数据清洗技能 ## 适用场景 - 用户提供的 JSON 数据包含空值、类型不一致、字段冗余 - 需要将数据转换为符合特定 schema 的结构 ## 核心规则 1. 先检查整体结构再逐字段处理不改变原有数据的语义 2. 统一空值处理null 和空字符串统一转为 null 3. 数字字段遇到字符串类型时使用 Number() 转换转换失败保留原值 4. 去除不包含任何有意义数据的字段全部为空值、全是占位符 5. 输出结果保持键的原始顺序 ## 执行步骤 1. 先递归检查 JSON 结构罗列所有层级和字段 2. 识别需要处理的问题字段空值、类型不一致、冗余字段 3. 逐项处理处理过程记录在注释中 4. 输出清洗后的 JSON同时输出一份简短的处理报告 ## 参考 - 详细信息参考> Agent Skills完全指南：从概念到开发实战与生态盘点
1. Skills 到底是什么从“调教AI”到“沉淀技能”的一次范式转移最近几个月“skills”这个词在开发者圈子里出现的频率高得吓人。从前端开发群里有人问“有没有好用的 code review skills”到推特上有人晒“用 agent skills 十分钟写了个论文大纲”再到 GitHub 上各种 skills 合集仓库动辄几千 star——你很难忽略这个趋势。但如果你去翻官方文档会发现“skills”这个概念解释得特别抽象它通常被描述为“一种为 AI 助手提供专项能力的文件化机制”。听起来像是提示词又像是工具配置还有点像插件。很多人第一次接触时确实分不清这四者的边界这很正常。我的理解是这样的Skills 本质上是把一套完整的、可复用的“做事方法”打包成标准化的文件让 AI 助手能按这套方法高质量地执行特定任务。它和普通提示词最大的区别在于结构化和工程化——提示词是“你告诉 AI 怎么干”Skills 是“你给 AI 一套带说明书、带最佳实践、带示例参考的操作手册”。打个比方。你让一个实习生帮你整理客户资料你可以口头交代“把资料按行业分类重点客户标出来”——这是提示词。但如果你给实习生一份SOP手册里面有分类标准、标注规则、优先级判断逻辑、历史案例参考、常见异常处理方式——这就是 Skills。所以 Skills 解决的本质问题是通用大模型什么都会一点但什么都不精。你想让它稳定地产出专业水准的结果就得把专家脑子里的隐性知识显性化变成文件让它读。这正是“skills 推荐”“skills 大全”这些词这么火的原因——大家都在找别人沉淀好的高质量技能包。1.1 Agent Skills 与 MCP、Prompt 的本质区别现在市面上还有两个概念经常和 Skills 混在一起MCPModel Context Protocol和普通 Prompt。我直接说结论免得你去翻几十篇文档。Prompt 是“一次性指令”它不承载复杂逻辑也不具备状态。你每次对话都要重新交代一次AI 的表现完全取决于你这次说得清不清楚。它适合简单任务不适合稳定复现。MCP 是“工具接口标准”解决的是 AI 怎么连接外部系统。比如让 AI 能查询数据库、调用 API、读写文件系统。MCP 的重点是“连接”能力解决的是 AI 的“手脚”问题。Skills 解决的是“方法”问题——它告诉 AI 如何像一个资深从业者那样思考和执行。如果说 MCP 是给 AI 装上了手和脚Skills 就是给 AI 装上了脑子和经验。当然这三者不是互斥关系。我在实际项目中经常把它们组合使用通过 MCP 连接代码仓库和 CI 系统通过 Skills 注入代码审查规范和架构评审清单再配合一段简短的 Prompt 说明本次任务目标。这是目前我见过的最稳的组合方式。1.2 为什么 2025 年 Skills 突然火了Skills 概念的爆发有几个技术前提。首先是上下文窗口变大后AI 有能力“读完”一份完整的技能文档再执行任务——以前 8K 上下文的时候塞一份几千字的规范进去就什么都干不了了。其次是 Agent 类应用的成熟让“AI 自主调用方法”成为可能而不只是聊天框里一问一答。还有一个很实际的原因企业需要知识沉淀。很多团队发现用提示词共享经验根本不靠谱——一句话提示词根本承载不了复杂的业务逻辑。但 Skills 是文件化的可以放进 Git 仓库管理、可以做版本控制、可以 review、可以测试。这正好契合了工程团队的工作习惯。我在几家公司的技术群里看大家讨论 skills 开发聊得最多的不是“怎么写提示词”而是“怎么设计目录结构”“怎么写 SKILL.md 的 frontmatter 才不会报错”——这已经不是提示词工程的路子了这是软件开发的路子。2. 主流平台的 Skills 生态Claude、Codex 与 GitHub 上的优质仓库热词里出现了“claude agent skills: a first principles deep dive”“codex skills”“前任skills官方下载”“github skills”这些关键词看得出来大家的关注点主要在两大平台Anthropic 的 Claude 和 OpenAI 的 Codex。我两个平台都用过一段时间各自的生态差异还是相当明显的。2.1 Claude Agent Skills首推的成熟方案Claude 的 Skills 机制是目前最完整的。它基于 SKILL.md 文件组织放进项目的.claude/skills/目录下就能被 Claude 自动发现。这个目录有点像浏览器插件目录Claude 会自动扫描根据任务上下文调用合适的技能。官方对每个技能的要求是包含 YAML frontmatter声明名称和描述 Markdown 正文说明使用时机、步骤、规范、示例。名字必须全小写字母加连字符描述要写清楚“这个技能什么时候该用”。这个设计我觉得是有讲究的——描述写得好不好直接决定 AI 能不能在合适的时机触发这个技能。很多人写技能不触发八成是描述写得模糊。我用 Claude Skills 写过一套前端代码审查技能放在.claude/skills/code-review/下效果比我想象中的好。它能主动检查 props 命名规范、组件拆分合理性、性能隐患甚至能指出我代码里状态管理设计的问题。这种体验和以前“把提示词复制粘贴到对话框”完全不一样——AI 是在它的原生工作流程里主动调用技能而不是你手动“喂”给它的。2.2 Codex Skills面向编码任务的另一个流派Codex 的 Skills 机制更偏向编码场景。它的配置方式和 Claude 类似Skill 文件里除了指令外还经常包含可执行的脚本、测试用例模板、风格指南等。Codex 对“可验证性”的重视程度更高——它生成代码时会主动加载技能里的规范来约束自己的输出。我在用 Codex 跑代码审查和重构任务时发现它的 Skills 很适合“自动挖洞”——这个词在安全圈是漏洞挖掘的意思。把安全审计 Checklist 做成 SkillCodex 可以自动扫描代码中的常见漏洞点。这里提醒一句这类技能只会用于你自己的项目或明确授权的渗透测试不要拿去干不合规的事。Codex 的生态还有一个特点社区仓库非常多。GitHub 上有一堆“codex 好用的 skills”合集从写论文到生成分镜脚本都有。热词里“codex写论文的skills”和“分镜skills下载”说明很多人已经在用它做内容创作了不只限编程场景。2.3 GitHub 上的 Skills 仓库怎么筛选GitHub 上 skills 仓库虽然多但质量参差不齐。我筛选的标准有四条看是否有明确的目录规范好的仓库每个技能都独立成文件夹里面有 SKILL.md有示例文件看 frontmatter 是否规范name、description 字段是否清晰看是否有测试或示例光有描述没有示例的大概率是凑数的看更新时间AI 工具变化快半年不更新的仓库基本可以放弃了我自己常用的是 GitHub 官方出的 Skills 学习路径仓库和一些社区整理的合集整体上质量比较可靠。下载后放进自己的项目里试用一遍能跑通再留下不能跑通就删掉——这是最朴素的筛选逻辑。3. 手把手开发一个自己的 Skills从设计到落地热词里“skills开发”出现频率很高说明已经有大量的人不满足于用别人的技能开始想着自己写了。其实开发一个 Skills 没有想象中那么复杂我拿一个实际案例走一遍完整流程你跟着做一遍基本就通了。3.1 设计思路先想清楚“AI 缺什么”在写任何代码之前建议先回答一个问题你希望 AI 用这个技能后在哪个环节表现得比默认状态更好我举一个我实际做过的例子。做前端开发时我经常让 AI 帮我生成 React 组件的单元测试但默认状态下的 AI 写出来的测试有两个问题一是只测 happy path不测边界情况二是mock 方式不统一有时候 mock 组件有时候 mock 函数。所以我设计了一个“前端单测编写技能”核心目标就一个让 AI 写的测试符合我们团队约定好的规范。设计思路明确之后技能的内容大纲自然就出来了测试文件命名规范、mock 的统一策略、边界情况检查清单、常用断言风格、一段完整示例测试代码。你看这个过程其实和写团队文档很像只是最后的目标读者是 AI。3.2 目录结构与 SKILL.md 的标准写法一个最基础的技能目录长这样.skills/ ├── unit-test/ │ ├── SKILL.md │ └── examples/ │ └── button.test.tsxSKILL.md 是最核心的文件。它分成两部分第一部分是 YAML frontmatter第二部分是正文。我的模板一直是这样--- name: unit-test description: 编写符合团队规范的 React 组件单元测试。当用户要求为 React 组件编写测试、补充测试用例时使用。 ---注意几个细节。name 只允许小写字母和连字符不允许空格和驼峰。description 不能只写“用于编写测试”这种模糊表述要写清楚“什么时候该用”AI 是靠这个判断触发时机的。我在多次实验中发现描述里包含“当用户提出 XX 请求时”这种条件句式触发准确率会高很多。正文部分同样要用 Markdown 写内容结构我会固定成这几块使用时机明确说明在什么场景下调用这个技能核心规则用列表列出 AI 必须遵守的硬性规则执行步骤分步骤描述完成任务的流程示例放一个完整的、标注了说明的示例3.3 渐进式披露Skills 的核心设计哲学关于 SKILL.md 正文官方文档里有个概念叫“渐进式披露”Progressive Disclosure这是整个机制里最值得琢磨的点。大模型的上下文窗口是有限的如果技能文件写得巨长AI 读完你的技能就没心情干活了而且重要信息反而被淹没。渐进式披露的意思是SKILL.md 里只写核心信息和必要规则让 AI 能快速理解技能的目的和边界更详细的操作指南、参考示例、模板代码放在同一目录下的其他文件中AI 在需要时再加载。.skills/ ├── unit-test/ │ ├── SKILL.md │ ├── testing-guide.md # 详细规范指南 │ ├── mock-strategies.md # mock 策略说明 │ └── examples/ │ ├── button.test.tsx │ └── form.test.tsxSKILL.md 里可以这样引导当需要了解 mock 策略时阅读 mock-strategies.md 文件。 为组件编写测试时参考 examples/ 目录下对应的示例文件。这种写法的好处是AI 每次读取技能时只消耗少量上下文不会影响主任务但真正需要细节时又能找到。我见过的大部分劣质 Skills问题就出在把 SKILL.md 写成了一个几千字的巨型文档AI 根本消化不了。3.4 一个完整示例JSON 数据清洗技能光讲理论容易虚我直接把一个“JSON 数据清洗”技能的 SKILL.md 完整写出来你可以直接抄去改。--- name: json-clean description: 对 JSON 数据进行清洗和规范化。当用户提供 JSON 数据要求清理脏数据、规范格式、去除冗余字段时使用。 ---# JSON 数据清洗技能 ## 适用场景 - 用户提供的 JSON 数据包含空值、类型不一致、字段冗余 - 需要将数据转换为符合特定 schema 的结构 ## 核心规则 1. 先检查整体结构再逐字段处理不改变原有数据的语义 2. 统一空值处理null 和空字符串统一转为 null 3. 数字字段遇到字符串类型时使用 Number() 转换转换失败保留原值 4. 去除不包含任何有意义数据的字段全部为空值、全是占位符 5. 输出结果保持键的原始顺序 ## 执行步骤 1. 先递归检查 JSON 结构罗列所有层级和字段 2. 识别需要处理的问题字段空值、类型不一致、冗余字段 3. 逐项处理处理过程记录在注释中 4. 输出清洗后的 JSON同时输出一份简短的处理报告 ## 参考 - 详细信息参考>