尧图网站建设 
1. 从skills这个模糊词说起它到底指什么第一次看到skills这个词作为项目标题大部分人脑子里蹦出来的可能是技能这个泛泛的翻译然后就没有然后了。但如果你最近在折腾 Claude Code、Codex 这类 AI 编程助手或者关注过 Agent 生态的动向就会知道这里的 skills 指的是一套非常具体的东西——Agent Skills也就是给 AI 智能体挂载的技能包。说白了skills 就是一组结构化的指令文件通常以SKILL.md为核心配合若干辅助脚本、模板、参考资料告诉 AI 在遇到某类任务时应该怎么做、按什么流程做、注意哪些坑。它跟传统的 prompt 有本质区别prompt 是你每次对话临时写的skills 是提前沉淀好、可以反复调用、可以版本管理的能力模块。我最初接触这个概念的时候也觉得不就是把提示词存成文件嘛有什么大不了的。但真正用起来才发现skills 解决的是一个非常现实的问题AI 每次对话都是失忆的你不告诉它你的项目规范、你的代码风格、你的业务逻辑它就按通用套路给你输出结果就是能用但不好用。skills 相当于给 AI 装了一本上岗手册让它在你这个特定场景下表现得像个熟手。这个内容适合谁看三类人一是刚上手 Claude Code 或类似工具、还在摸索怎么让 AI 更听话的新手二是已经会用但每次都要重复交代背景、想提升效率的中级用户三是想自己写 skills、把团队经验沉淀下来的开发者。不管你属于哪一类下面这些内容都能让你少走弯路。2. Agent Skills 的运行机制为什么一个 Markdown 文件能改变 AI 的行为2.1 SKILL.md 的加载逻辑与触发条件要理解 skills 为什么有效得先搞清楚它是怎么被 AI 读取和使用的。以 Claude Code 为例skills 通常放在项目的特定目录下比如.claude/skills/或者用户级的配置目录每个 skill 是一个独立的文件夹里面至少有一个SKILL.md文件。这个SKILL.md的结构一般包含几个部分name技能名称、description技能描述、以及正文的指令内容。关键在于 description 这一栏——它不是写给人看的是写给 AI 看的。AI 在接到任务时会先扫描所有可用 skills 的 description判断当前任务跟哪个 skill 匹配匹配上了才会去读完整的SKILL.md正文。这个机制叫渐进式披露progressive disclosure。为什么要这样设计因为如果把所有 skills 的完整内容都塞进上下文token 消耗会爆炸而且 AI 容易被无关信息干扰。只加载 description 做路由命中后再读全文既省 token 又精准。我实测下来的经验是description 写得好不好直接决定 skill 会不会被触发。很多人写完SKILL.md发现 AI 根本不用八成是 description 太笼统。比如你写帮助处理数据AI 不知道什么时候该用你写当用户需要清洗 CSV 文件中的缺失值、去重、格式转换时使用命中率立刻上去了。2.2 skills 与 prompt、MCP、子代理的区别这里容易混淆的几个概念得掰扯清楚不然选型的时候会纠结。机制本质适用场景加载方式Prompt临时指令一次性、简单任务每次手动输入Skills结构化指令包可复用、有固定流程的任务按 description 自动匹配MCP外部工具协议需要调用外部服务/数据配置后常驻可用子代理独立 AI 实例复杂任务拆分并行主代理调度简单说prompt 是随口交代skills 是写成 SOPMCP 是给 AI 接上外部的手子代理是再雇一个人。它们不是互斥的实际项目里经常组合使用。比如一个数据处理流程可以用 skill 定义步骤用 MCP 连接数据库用子代理并行处理多个文件。我个人的判断标准是如果一件事你需要跟 AI 交代超过三次就该写成 skill 了。这个阈值很实用能帮你判断哪些经验值得沉淀。2.3 一个 skill 从被调用到执行的完整链路很多人以为 AI 读了SKILL.md就完事了其实后面还有一段路。完整的链路大致是这样用户发出任务请求AI 扫描可用 skills 的 description 列表匹配到相关 skill读取完整SKILL.md按照SKILL.md中的指令规划执行步骤如果 skill 引用了辅助文件脚本、模板按需读取执行任务过程中可能调用其他工具或 MCP输出结果这里面第 5 步是很多人忽略的。skills 文件夹里除了SKILL.md还可以放脚本、示例文件、参考文档AI 会在需要时去读。这就意味着你可以把复杂的逻辑拆分成多个文件SKILL.md只做导航具体细节放在子文件里。这样既保持了主文件的简洁又能承载大量细节。3. 手把手写第一个 skill从目录结构到调试通过3.1 目录结构怎么设计才合理先看一个我常用的目录结构模板.claude/skills/ └── my-data-cleaner/ ├── SKILL.md ├── scripts/ │ └── clean.py ├── templates/ │ └── report-template.md └── references/ └── field-mapping.md这个结构不是随便定的。SKILL.md是入口必须放在根目录scripts/放可执行脚本AI 可以直接调用templates/放输出模板保证格式统一references/放参考资料比如字段映射表、业务规则说明。为什么要分这么细因为 AI 读取文件是有成本的你把所有内容堆在SKILL.md里每次触发都要读一大堆既慢又费 token。拆开之后SKILL.md只写什么时候用什么具体内容按需加载。提示目录名和文件名尽量用英文小写加连字符避免空格和特殊字符。我踩过一次坑目录名带了中文在某些环境下路径解析出问题排查了半天。3.2 SKILL.md 的字段写法与常见错误一个能正常工作的SKILL.md长这样--- name:>## 执行流程 1. 收集本周的 git commit 记录 2. 按项目分类整理 3. 生成周报草稿格式参考 templates/weekly-report.md 4. 如果用户有特殊要求参考 references/custom-rules.md具体模板和规则放在子文件里AI 只在需要时读取。这样主文件保持清爽维护起来也方便。4.3 用脚本处理确定性任务用指令处理判断性任务这是我从实践中总结的一条原则。凡是能用脚本确定性完成的就不要让 AI 去想。比如日期格式转换、文件重命名、数据统计写个 Python 脚本放scripts/里AI 直接调用又快又准。AI 擅长的是判断和决策比如这个缺失值该填还是该删、这段描述该归到哪个类别。把这些交给 AI把机械操作交给脚本分工明确效率最高。我见过有人把所有逻辑都写成自然语言指令结果 AI 每次执行结果都不太一样稳定性很差。后来把确定性部分抽成脚本问题立刻解决了。5. 实战中踩过的坑与排查思路5.1 skill 不触发从 description 到文件位置的排查链路这是最常见的问题。我的排查顺序是第一步确认文件位置。不同工具对 skills 的存放路径要求不同。Claude Code 一般是项目根目录的.claude/skills/用户级的在~/.claude/skills/。放错地方 AI 根本扫不到。第二步确认文件格式。打开SKILL.md检查 frontmatter 的---是否成对name和description是否存在冒号后是否有空格。这些细节错了文件会被静默忽略。第三步确认 description 是否匹配。把你实际提的任务和 description 对比看语义是否接近。如果差太远改 description。第四步确认是否有命名冲突。如果两个 skill 的 name 相同可能只有一个生效。检查一下有没有重名。这四步走下来90% 的不触发问题都能解决。5.2 触发后行为不对指令歧义与上下文干扰有时候 skill 触发了但 AI 执行的结果跟预期不符。常见原因有两个一是指令有歧义。比如你写处理异常值AI 不知道是删除还是替换。改成删除超过 3 倍标准差的异常值就明确了。二是上下文干扰。如果对话历史里有跟当前 skill 冲突的信息AI 可能会混淆。解决办法是在 skill 里明确写忽略之前的 XX 指令按以下步骤执行。我遇到过一次skill 里写用中位数填充缺失值但对话前面用户提过尽量保留原始数据结果 AI 纠结了半天。后来在 skill 里加了优先级说明问题解决。5.3 多 skill 冲突时的优先级处理项目大了skills 多了难免有功能重叠。比如一个数据清洗skill 和一个数据预处理skill都可能处理缺失值。处理原则是能合并的合并不能合并的明确边界。如果两个 skill 确实做不同的事就在 description 里写清楚各自的适用场景避免重叠。如果只是叫法不同合并成一个。另外有些工具支持在 skill 里设置优先级字段高优先级的先匹配。这个因工具而异用之前查一下文档。6. 不同场景下的 skills 设计思路6.1 数学建模场景把建模流程标准化数学建模比赛里时间紧、任务重skills 能帮上大忙。我见过有人把数据探索→模型选择→参数调优→结果可视化整个流程写成一个 skill比赛时直接调用省去大量重复沟通。这类 skill 的设计要点是把常用的模型和对应的适用场景列出来让 AI 根据数据特征推荐模型。比如## 模型选择规则 - 数据量小、特征少优先线性回归或决策树 - 数据量大、特征多考虑随机森林或梯度提升 - 时间序列ARIMA 或 LSTM - 分类问题先试逻辑回归效果不好再上集成模型这样 AI 就不会盲目推荐复杂模型而是根据实际情况选择。6.2 前端开发场景统一代码风格与组件规范前端项目最怕风格不统一。一个组件开发skill 可以规定用什么框架、目录怎么组织、命名用什么规范、样式怎么写、测试怎么覆盖。我帮一个团队写过这样的 skill核心内容是组件文件放在src/components/组件名/index.tsx样式用 CSS Modules文件名index.module.cssProps 必须定义 TypeScript 类型每个组件至少有一个测试文件写完之后AI 生成的代码直接符合团队规范省去了大量 review 修改的时间。6.3 内容创作场景固定输出格式与语气做内容的人可以用 skill 固定输出格式。比如一个公众号文章skill规定标题风格、开头方式、段落长度、结尾形式。这样 AI 每次生成的内容都符合你的账号调性不用反复调整。这类 skill 的关键是给出正例和反例。光说语气要轻松没用给一段符合要求的文字和一段不符合的AI 立刻就懂了。7. skills 的维护与迭代别写完就不管了skills 不是写完就一劳永逸的。项目在变需求在变skill 也得跟着更新。我的习惯是每次发现 AI 执行结果不对先想是不是 skill 该改了。如果同一个问题出现两次以上就动手改 skill而不是每次在对话里纠正。定期清理不再用的 skill。项目里堆太多废弃 skill会影响匹配准确率。我一般一个月清理一次把过时的删掉或归档。给 skill 加版本号。在SKILL.md里加个version字段改动大的时候更新一下方便追溯。还有一点skill 要写给人看也要写给 AI 看。团队协作时新人通过读 skill 能快速了解项目规范AI 通过读 skill 能按规范执行。一份好的 skill 是双重价值的。8. 关于 skills 生态的一些观察现在 skills 的生态还在早期但已经能看到一些趋势。GitHub 上有人分享自己写的 skills覆盖了从代码审查到文档生成的各类场景。社区里也有讨论怎么组织大型 skill 库、怎么处理依赖关系。我的判断是skills 会成为 AI 工具使用的一个基础能力就像当年大家学 Git、学 Docker 一样。早一点掌握早一点受益。但也不用焦虑核心逻辑不复杂写几个练手就熟了。如果你刚开始建议从最小的场景入手——比如把你最常跟 AI 交代的一件事写成 skill用起来再迭代。别一上来就想搞个大而全的技能库那样容易半途而废。我在实际使用中最大的体会是skills 的价值不在于技术多高深而在于它强迫你把隐性经验显性化。写 skill 的过程其实就是梳理自己工作流程的过程。很多时候写着写着自己都想明白了一些之前没注意到的细节。这个附加价值可能比 skill 本身还重要。 Agent Skills 实战指南：从 SKILL.md 到 AI 编程助手技能包
1. 从skills这个模糊词说起它到底指什么第一次看到skills这个词作为项目标题大部分人脑子里蹦出来的可能是技能这个泛泛的翻译然后就没有然后了。但如果你最近在折腾 Claude Code、Codex 这类 AI 编程助手或者关注过 Agent 生态的动向就会知道这里的 skills 指的是一套非常具体的东西——Agent Skills也就是给 AI 智能体挂载的技能包。说白了skills 就是一组结构化的指令文件通常以SKILL.md为核心配合若干辅助脚本、模板、参考资料告诉 AI 在遇到某类任务时应该怎么做、按什么流程做、注意哪些坑。它跟传统的 prompt 有本质区别prompt 是你每次对话临时写的skills 是提前沉淀好、可以反复调用、可以版本管理的能力模块。我最初接触这个概念的时候也觉得不就是把提示词存成文件嘛有什么大不了的。但真正用起来才发现skills 解决的是一个非常现实的问题AI 每次对话都是失忆的你不告诉它你的项目规范、你的代码风格、你的业务逻辑它就按通用套路给你输出结果就是能用但不好用。skills 相当于给 AI 装了一本上岗手册让它在你这个特定场景下表现得像个熟手。这个内容适合谁看三类人一是刚上手 Claude Code 或类似工具、还在摸索怎么让 AI 更听话的新手二是已经会用但每次都要重复交代背景、想提升效率的中级用户三是想自己写 skills、把团队经验沉淀下来的开发者。不管你属于哪一类下面这些内容都能让你少走弯路。2. Agent Skills 的运行机制为什么一个 Markdown 文件能改变 AI 的行为2.1 SKILL.md 的加载逻辑与触发条件要理解 skills 为什么有效得先搞清楚它是怎么被 AI 读取和使用的。以 Claude Code 为例skills 通常放在项目的特定目录下比如.claude/skills/或者用户级的配置目录每个 skill 是一个独立的文件夹里面至少有一个SKILL.md文件。这个SKILL.md的结构一般包含几个部分name技能名称、description技能描述、以及正文的指令内容。关键在于 description 这一栏——它不是写给人看的是写给 AI 看的。AI 在接到任务时会先扫描所有可用 skills 的 description判断当前任务跟哪个 skill 匹配匹配上了才会去读完整的SKILL.md正文。这个机制叫渐进式披露progressive disclosure。为什么要这样设计因为如果把所有 skills 的完整内容都塞进上下文token 消耗会爆炸而且 AI 容易被无关信息干扰。只加载 description 做路由命中后再读全文既省 token 又精准。我实测下来的经验是description 写得好不好直接决定 skill 会不会被触发。很多人写完SKILL.md发现 AI 根本不用八成是 description 太笼统。比如你写帮助处理数据AI 不知道什么时候该用你写当用户需要清洗 CSV 文件中的缺失值、去重、格式转换时使用命中率立刻上去了。2.2 skills 与 prompt、MCP、子代理的区别这里容易混淆的几个概念得掰扯清楚不然选型的时候会纠结。机制本质适用场景加载方式Prompt临时指令一次性、简单任务每次手动输入Skills结构化指令包可复用、有固定流程的任务按 description 自动匹配MCP外部工具协议需要调用外部服务/数据配置后常驻可用子代理独立 AI 实例复杂任务拆分并行主代理调度简单说prompt 是随口交代skills 是写成 SOPMCP 是给 AI 接上外部的手子代理是再雇一个人。它们不是互斥的实际项目里经常组合使用。比如一个数据处理流程可以用 skill 定义步骤用 MCP 连接数据库用子代理并行处理多个文件。我个人的判断标准是如果一件事你需要跟 AI 交代超过三次就该写成 skill 了。这个阈值很实用能帮你判断哪些经验值得沉淀。2.3 一个 skill 从被调用到执行的完整链路很多人以为 AI 读了SKILL.md就完事了其实后面还有一段路。完整的链路大致是这样用户发出任务请求AI 扫描可用 skills 的 description 列表匹配到相关 skill读取完整SKILL.md按照SKILL.md中的指令规划执行步骤如果 skill 引用了辅助文件脚本、模板按需读取执行任务过程中可能调用其他工具或 MCP输出结果这里面第 5 步是很多人忽略的。skills 文件夹里除了SKILL.md还可以放脚本、示例文件、参考文档AI 会在需要时去读。这就意味着你可以把复杂的逻辑拆分成多个文件SKILL.md只做导航具体细节放在子文件里。这样既保持了主文件的简洁又能承载大量细节。3. 手把手写第一个 skill从目录结构到调试通过3.1 目录结构怎么设计才合理先看一个我常用的目录结构模板.claude/skills/ └── my-data-cleaner/ ├── SKILL.md ├── scripts/ │ └── clean.py ├── templates/ │ └── report-template.md └── references/ └── field-mapping.md这个结构不是随便定的。SKILL.md是入口必须放在根目录scripts/放可执行脚本AI 可以直接调用templates/放输出模板保证格式统一references/放参考资料比如字段映射表、业务规则说明。为什么要分这么细因为 AI 读取文件是有成本的你把所有内容堆在SKILL.md里每次触发都要读一大堆既慢又费 token。拆开之后SKILL.md只写什么时候用什么具体内容按需加载。提示目录名和文件名尽量用英文小写加连字符避免空格和特殊字符。我踩过一次坑目录名带了中文在某些环境下路径解析出问题排查了半天。3.2 SKILL.md 的字段写法与常见错误一个能正常工作的SKILL.md长这样--- name:>## 执行流程 1. 收集本周的 git commit 记录 2. 按项目分类整理 3. 生成周报草稿格式参考 templates/weekly-report.md 4. 如果用户有特殊要求参考 references/custom-rules.md具体模板和规则放在子文件里AI 只在需要时读取。这样主文件保持清爽维护起来也方便。4.3 用脚本处理确定性任务用指令处理判断性任务这是我从实践中总结的一条原则。凡是能用脚本确定性完成的就不要让 AI 去想。比如日期格式转换、文件重命名、数据统计写个 Python 脚本放scripts/里AI 直接调用又快又准。AI 擅长的是判断和决策比如这个缺失值该填还是该删、这段描述该归到哪个类别。把这些交给 AI把机械操作交给脚本分工明确效率最高。我见过有人把所有逻辑都写成自然语言指令结果 AI 每次执行结果都不太一样稳定性很差。后来把确定性部分抽成脚本问题立刻解决了。5. 实战中踩过的坑与排查思路5.1 skill 不触发从 description 到文件位置的排查链路这是最常见的问题。我的排查顺序是第一步确认文件位置。不同工具对 skills 的存放路径要求不同。Claude Code 一般是项目根目录的.claude/skills/用户级的在~/.claude/skills/。放错地方 AI 根本扫不到。第二步确认文件格式。打开SKILL.md检查 frontmatter 的---是否成对name和description是否存在冒号后是否有空格。这些细节错了文件会被静默忽略。第三步确认 description 是否匹配。把你实际提的任务和 description 对比看语义是否接近。如果差太远改 description。第四步确认是否有命名冲突。如果两个 skill 的 name 相同可能只有一个生效。检查一下有没有重名。这四步走下来90% 的不触发问题都能解决。5.2 触发后行为不对指令歧义与上下文干扰有时候 skill 触发了但 AI 执行的结果跟预期不符。常见原因有两个一是指令有歧义。比如你写处理异常值AI 不知道是删除还是替换。改成删除超过 3 倍标准差的异常值就明确了。二是上下文干扰。如果对话历史里有跟当前 skill 冲突的信息AI 可能会混淆。解决办法是在 skill 里明确写忽略之前的 XX 指令按以下步骤执行。我遇到过一次skill 里写用中位数填充缺失值但对话前面用户提过尽量保留原始数据结果 AI 纠结了半天。后来在 skill 里加了优先级说明问题解决。5.3 多 skill 冲突时的优先级处理项目大了skills 多了难免有功能重叠。比如一个数据清洗skill 和一个数据预处理skill都可能处理缺失值。处理原则是能合并的合并不能合并的明确边界。如果两个 skill 确实做不同的事就在 description 里写清楚各自的适用场景避免重叠。如果只是叫法不同合并成一个。另外有些工具支持在 skill 里设置优先级字段高优先级的先匹配。这个因工具而异用之前查一下文档。6. 不同场景下的 skills 设计思路6.1 数学建模场景把建模流程标准化数学建模比赛里时间紧、任务重skills 能帮上大忙。我见过有人把数据探索→模型选择→参数调优→结果可视化整个流程写成一个 skill比赛时直接调用省去大量重复沟通。这类 skill 的设计要点是把常用的模型和对应的适用场景列出来让 AI 根据数据特征推荐模型。比如## 模型选择规则 - 数据量小、特征少优先线性回归或决策树 - 数据量大、特征多考虑随机森林或梯度提升 - 时间序列ARIMA 或 LSTM - 分类问题先试逻辑回归效果不好再上集成模型这样 AI 就不会盲目推荐复杂模型而是根据实际情况选择。6.2 前端开发场景统一代码风格与组件规范前端项目最怕风格不统一。一个组件开发skill 可以规定用什么框架、目录怎么组织、命名用什么规范、样式怎么写、测试怎么覆盖。我帮一个团队写过这样的 skill核心内容是组件文件放在src/components/组件名/index.tsx样式用 CSS Modules文件名index.module.cssProps 必须定义 TypeScript 类型每个组件至少有一个测试文件写完之后AI 生成的代码直接符合团队规范省去了大量 review 修改的时间。6.3 内容创作场景固定输出格式与语气做内容的人可以用 skill 固定输出格式。比如一个公众号文章skill规定标题风格、开头方式、段落长度、结尾形式。这样 AI 每次生成的内容都符合你的账号调性不用反复调整。这类 skill 的关键是给出正例和反例。光说语气要轻松没用给一段符合要求的文字和一段不符合的AI 立刻就懂了。7. skills 的维护与迭代别写完就不管了skills 不是写完就一劳永逸的。项目在变需求在变skill 也得跟着更新。我的习惯是每次发现 AI 执行结果不对先想是不是 skill 该改了。如果同一个问题出现两次以上就动手改 skill而不是每次在对话里纠正。定期清理不再用的 skill。项目里堆太多废弃 skill会影响匹配准确率。我一般一个月清理一次把过时的删掉或归档。给 skill 加版本号。在SKILL.md里加个version字段改动大的时候更新一下方便追溯。还有一点skill 要写给人看也要写给 AI 看。团队协作时新人通过读 skill 能快速了解项目规范AI 通过读 skill 能按规范执行。一份好的 skill 是双重价值的。8. 关于 skills 生态的一些观察现在 skills 的生态还在早期但已经能看到一些趋势。GitHub 上有人分享自己写的 skills覆盖了从代码审查到文档生成的各类场景。社区里也有讨论怎么组织大型 skill 库、怎么处理依赖关系。我的判断是skills 会成为 AI 工具使用的一个基础能力就像当年大家学 Git、学 Docker 一样。早一点掌握早一点受益。但也不用焦虑核心逻辑不复杂写几个练手就熟了。如果你刚开始建议从最小的场景入手——比如把你最常跟 AI 交代的一件事写成 skill用起来再迭代。别一上来就想搞个大而全的技能库那样容易半途而废。我在实际使用中最大的体会是skills 的价值不在于技术多高深而在于它强迫你把隐性经验显性化。写 skill 的过程其实就是梳理自己工作流程的过程。很多时候写着写着自己都想明白了一些之前没注意到的细节。这个附加价值可能比 skill 本身还重要。