如果你最近刷技术社区可能会发现一个现象讨论的焦点正在从“如何写更好的 Prompt”悄悄转向“如何给 Agent 安装技能”。这其实是 Agent 使用方式的一个重要分水岭。先说结论Agent Skills 最容易被低估的地方是它把“对话能力”变成了“文件系统”。从此以后你使用 AI 的方式不再是一个“聊天窗口 一段提示词”而是一套可以安装、复用、分享、版本管理的能力包。你可以把 Skills 理解为给 AI 配的“职业资格证”——装上财务分析技能它就能按财务分析师的思路工作装上网页抓取技能它就能按标准流程采集和清洗数据。同一个模型装上不同的 Skill干不同岗位的活。这个变化对开发者的影响是非常直接的以前你要为每个项目写一大段系统提示词让模型记住“输出格式是什么”“处理步骤是什么”“遇到异常怎么兜底”现在这些规则可以被打包成 Skill 文件按需加载、随时卸载。更重要的是Skill 不是只能靠别人发布你可以自己造。网上已经有很多讨论“Agent Skills 和 AI Skills 到底有什么区别”“有什么好用的 Claude Code Skills 值得装”也有越来越多非程序员用户在研究怎么用 Agent Skills 辅助论文写作和文本分析。这篇文章就围绕“从会用到会造”这条主线展开。我会先讲清楚 Agent Skills 的核心概念和它与普通提示词的本质差异然后带你从零搭建一个可用的 Skill再通过代码审查、文档生成、研究分析这三个真实场景讲透 Skill 的设计、安装、验证和排错。整篇文章读完你应该能独立完成“自己设计一个 Skill → 安装进 Agent → 在真实项目中使用”的完整闭环。1. Agent Skills 究竟解决了什么问题要理解 Agent Skills 的价值先回到一个最朴素的场景。假设你是一名 Java 后端工程师每天都要让 AI 帮忙写单元测试。过去的做法是打开聊天窗口输入一段非常详细的指令“请为 UserService 类生成单元测试使用 JUnit5 Mockito覆盖正常流程、异常分支、边界条件测试类放在 src/test/java 目录下。”这段指令确实能让模型输出不错的结果但下一次换一个 Service 类你还要重新输入几乎一样的指令。更麻烦的是如果团队里有五个人都在用 AI 辅助写测试五个人可能各自写了一套要求有人要求 Mockito 写法有人要求用 AssertJ有人干脆不提框架让模型自由发挥。结果就是AI 生成的测试代码风格五花八门维护成本很高。Agent Skills 解决的就是这个问题。它把“写单元测试”这件事从“一段临时 Prompt”升级成了“一个标准技能包”。技能包里写清楚了目标、步骤、输出格式、边界条件、甚至附加了一个检查脚本。当 Agent 检测到用户请求命中这个技能时它不再是自由发挥而是按照技能包里的流程执行。技能包可以被团队共享放进 Git 仓库任何成员拉到项目后都能使用同一套标准。用一句话总结Prompt 是临场发挥的提示Skill 是沉淀下来的操作规程。这也解释了为什么 Anthropic 在 Claude Code 中引入 Skills 之后社区的反应会那么强烈。Skill 本质上改变了 AI 应用的分发方式。以前我们分发的是“模型权重”或“API 接口”现在我们可以分发“AI 的职业能力”。一个研究者可以分享一个“人文社科混合方法论文分析 Skill”一个前端开发者可以分享一个“React 组件代码审查 Skill”。别人拿到这个 Skill不需要理解背后的逻辑直接就能让 Agent 具备同样的能力。从工程视角看它还有一个隐蔽的优势Skill 让 AI 项目更可控。因为技能的行为是定义在文件里的你可以 review、测试、回滚。这比在系统提示词里维护一堆隐性规则要可靠得多。2. AI Skills 与 Agent Skills一次讲清楚在继续往下之前有必要先厘清一个常见困惑AI Skills 和 Agent Skills 到底是不是一个东西网上搜索热词里同时出现了“ai agent skills”“ai skills和agent的区别”说明确实有不少人在这个概念上纠结。我的理解是这样的AI Skills 是更宽泛的概念指的是 AI 系统具备的某种能力。它可以是一个微调过的模型、一个精心设计的提示词模板、一个工具调用策略甚至是一个 RAG 检索管道。只要它让 AI 在某些任务上表现得更好都可以叫 AI Skill。这个词更偏向“能力”本身。Agent Skills 则更具体它通常指以文件/目录为载体的、可被 Agent 动态加载的技能包。一个 Agent Skill 包含 SKILL.md 描述文件和可选的参考脚本、资源文件。Agent 在运行时会扫描可用的 Skills 目录根据用户请求匹配 description然后加载对应技能并执行。可以这样对比维度AI SkillsAgent Skills概念范围泛指 AI 的任何专项能力特指 Agent 可加载的技能包载体模型、提示词、工具、流程都可能通常是一个目录 SKILL.md 脚本分发方式不固定可能集成在模型里可复制、可安装、可放进 Git 仓库是否必须依赖 Agent不一定普通聊天也能体现通常需要 Agent 框架配合典型例子模型的代码能力、翻译能力Claude Code 中的 code-review Skill有一个更形象的类比AI Skills 像是“人会弹钢琴”这种能力描述Agent Skills 则像“一本乐谱加上练琴步骤”。乐谱可以被复制、被分发、被教学任何一个会弹琴的人拿到乐谱都能演奏同一首曲子。不过在实际使用中这两个词经常被混用。社区里说“安装一个 Skill”时通常指的就是 Agent Skills而且大多数时候说的是 Claude Code Skills。这是因为 Anthropic 的 Agent Skills 规范在社区里传播最广也有官方的技能仓库可以直接装。理解到这一层阅读各类资料时就不会被名词绕晕凡是提到“skills 目录”“SKILL.md”“add-skill”的都是在说 Agent Skills凡是空泛地讲“AI 应该具备某种能力”的多半是在说 AI Skills。3. Agent Skills 的适用场景与使用边界什么样的任务适合做成 Skill我的判断是凡是“流程稳定、输出格式明确、重复出现”的任务都值得考虑 Skill 化。反过来如果一项任务每次都不一样没有固定套路做成 Skill 反而会限制模型的灵活性。几个典型场景第一类是代码工程类任务。例如单元测试生成、代码审查、依赖升级检查、README 生成、API 文档生成。这类任务的最大特点是规则明确团队可以约定统一的规范让 Agent 按规范执行。搜索热词里经常出现的“好用的 Claude Code Skills 安装”“claude code skills 推荐”大多集中在这个方向。第二类是数据与文本处理任务。例如从非结构化文本中提取结构化字段、清洗 CSV 数据、按指定模板生成周报、转换文档格式。这类任务适合做成 Skill是因为输入输出边界清晰而且每个步骤都可以写清楚。第三类是研究分析任务。这可能是最容易被忽视的方向。热搜词里有一条很有意思“agent skills 赋能人文社科混合研究方法论文写作”。很多人以为 Skill 只服务程序员其实一个“文献编码分析 Skill”完全可以辅助研究者做定性数据编码、主题归纳、文献综述框架搭建。Skill 里写清楚分析步骤和输出表格结构研究者只需要把文本材料交给 AgentAgent 就能按 Socra 或主题分析法的框架去处理。再说说不适合的场景。需要强实时交互的任务比如多轮商业谈判模拟需要非结构化创意的任务比如头脑风暴写小说需要访问高度敏感数据的任务比如处理包含大量个人隐私的医疗记录。这些场景里Skill 反而会成为负担或者引入不必要的安全风险。Agent 的自主执行能力越强越要限制它的行动边界而不是把更多权限交给它。4. 环境准备与前置条件在开始创建 Skill 之前我们需要确认环境满足要求。这里提醒一句AI 工具链迭代很快下面的版本描述是一般性说明具体版本请以你安装时的官方文档为准。重点是理解流程而不是背参数。首先你需要一个支持 Agent Skills 的 Agent 客户端。目前社区讨论最集中的是 Claude Code包括命令行版本和桌面版本。Claude Code 在较新的版本中加入了 Skills 机制能够扫描项目目录下的.claude/skills目录也可以安装官方仓库或其他来源的 Skill。其次需要确保你的机器上有基础的命令行工具例如bash、curl以及你希望在 Skill 脚本中使用的语言环境。如果你要写 Python 辅助脚本就需要安装 Python如果要写 Node 脚本就需要 Node.js 等。这些不是 Agent 本身的依赖而是你创建的 Skill 的运行时依赖。我们用一个最小环境清单来说明操作系统macOS / Linux / WindowsWindows 建议使用 WSL 或 Git Bash Agent 客户端Claude Code 或同类支持 Skills 的客户端 命令行工具bash、git 脚本语言Python 3.x 或 Node.js 18如果你想先跑通官方示例可以查看 Anthropic 官方发布的 skills 仓库按 README 说明进行下载和安装。最好先确认一下你的 Claude Code 版本是否支持 Skills可以运行claude --version如果版本过于老旧Skills 可能无法识别建议先更新到最新版本。注意不要在生产依赖中盲目使用最新版先在测试项目里验证兼容性。5. 从会用到会造手把手创建第一个 Skill现在进入核心部分我们从一个空目录开始创建一个真实的 Skill。为了贴近大多数读者的需求我用“Python 代码审查”作为示例。这个 Skill 的实际价值很直观团队可以约定统一代码规范Agent 按这套规范审查代码而不是每次临时描述想要什么。5.1 创建目录结构Agent Skills 的规范通常要求一个 Skill 对应一个目录目录内包含SKILL.md文件文件名必须是这个大写的SKILL.md。除此之外可以按需创建scripts目录存放辅助脚本assets目录存放参考文件。我们创建如下结构. └── .claude └── skills └── python-code-review ├── SKILL.md └── scripts └── check_conflict_markers.sh这里我把 Skill 放在项目的.claude/skills目录下这是 Claude Code 扫描的默认路径之一。如果你的客户端支持用户级 Skills 目录也可以放进去这样所有项目都能用。5.2 编写 SKILL.mdSKILL.md是 Skill 的灵魂。它的格式很接近 Markdown 文档但顶部有一段 YAML frontmatter用来写元信息。核心字段是name和description。--- name: python-code-review description: 对 Python 代码进行规范性审查。当用户要求“审查代码”“检查提交”“code review”或提供 Python 文件路径时使用。 --- # Python 代码审查技能 本技能用于对 Python 代码进行系统性检查并在代码可能存在问题的地方给出修改建议。 ## 审查范围 1. 正确性空指针、异常处理缺失、边界条件处理不当、条件判断写反。 2. 安全性硬编码密钥、动态执行用户输入、不安全的反序列化。 3. 可维护性命名不清晰、函数过长、重复代码、模块职责混乱。 4. 性能循环内执行数据库查询、不必要的重复计算、资源未释放。 ## 执行步骤 1. 获取用户提供的文件路径或代码内容。 2. 使用工具读取文件内容或直接接收用户粘贴的代码。 3. 按上述四个维度逐项检查。 4. 如果有 scripts/check_conflict_markers.sh先运行它检查合并冲突标记。 5. 输出报告格式见下。 ## 输出格式 每个问题按以下 Markdown 模板输出 markdown ### 问题 1一句话概括问题 - 文件file_path - 行号line_number - 级别严重 / 建议 - 说明为什么这是一个问题 - 修改建议具体修改建议必要时给代码示例最后给出总结## 审查总结 共发现 X 个严重问题Y 个建议。 推荐下一步最优先处理哪一类问题注意事项不要修改用户代码只输出审查意见。如果无法确定某处是否有问题标记为“建议”不要武断。不要输出超出代码审查范围的内容。这个 SKILL.md 的核心作用是告诉 Agent什么时候触发、按什么顺序执行、输出什么格式、有哪些边界。模型看到这份文档后会把它当成操作手册来执行。 ### 5.3 添加辅助脚本 辅助脚本不是必需的但如果你的 Skill 需要执行确定性检查脚本非常有用。比如检查文件中是否残留 Git 合并冲突标记这种任务靠模型肉眼找不一定稳定用一个正则脚本更可靠。 bash #!/usr/bin/env bash # 文件路径scripts/check_conflict_markers.sh # 用法bash check_conflict_markers.sh 文件路径 # 功能检测文件中是否残留 Git 合并冲突标记 file$1 if [ ! -f $file ]; then echo 文件不存在: $file exit 1 fi grep -nE ^(||) $file { echo 发现 Git 合并冲突标记请先解决冲突后再审查。 exit 2 } echo 未发现合并冲突标记。脚本逻辑不复杂接收一个文件路径用正则查找冲突标记。如果发现冲突标记退出码为 2Agent 可以据此停止审查先让用户解决冲突。5.4 安装并验证 Skill目录创建好之后你需要让 Agent 能识别这个 Skill。不同客户端的具体命令会有差异下面的写法是最常见的安装方式# 在项目根目录执行 claude --add-skill .claude/skills/python-code-review如果客户端已经自动扫描.claude/skills目录那么重启客户端后Skill 应该就能被识别。你可以输入下面这句话来测试请用 python-code-review 技能审查 src/main.py 文件如果 Agent 正确加载了 Skill它应该会按照 SKILL.md 里的执行步骤来响应并在审查前先运行合并冲突检查脚本。6. 完整示例一个真正可用的“文档生成” Skill光有代码审查一个示例还不够。为了展示 Skill 的设计弹性我们再做一个完全不同风格的 Skill针对 API 接口的文档生成。这个 Skill 不依赖脚本纯粹靠规则驱动适用于团队需要统一接口文档格式的场景。6.1 创建目录结构. └── .claude └── skills └── api-doc-generator ├── SKILL.md └── templates └── endpoint-doc.md6.2 编写 SKILL.md--- name: api-doc-generator description: 根据后端接口代码生成 API 接口文档。当用户提供 Controller 文件、路由文件、接口定义时使用适合需要编写 REST API 文档的场景。 --- # API 文档生成技能 本技能用于从接口源码中提取信息生成结构化的 Markdown API 文档。 ## 触发条件 - 用户要求“生成接口文档”“写 API 文档”“generate API doc” - 用户提供包含路由定义的源代码文件 - 用户要求把某个 Controller 转换为文档 ## 执行步骤 1. 读取用户指定的接口源码文件。 2. 解析出 - 接口路径Path - HTTP 方法GET / POST / PUT / DELETE / PATCH - 请求参数Query、Path、Body - 请求头Header - 响应结构Response 3. 按标准模板输出文档。 ## 输出模板 每个接口输出一节参考 templates/endpoint-doc.md。 ## 注意 - 参数必须标注是否必填。 - 响应示例应从代码中提取真实字段不要编造。 - 如果源码中缺少某个字段标注“未定义”不要自行推断。6.3 编写文档模板# 接口文档 ## POST /api/v1/users 创建新用户。 ### 请求参数 | 参数名 | 位置 | 类型 | 必填 | 说明 | | --- | --- | --- | --- | --- | | name | body | string | 是 | 用户姓名 | | email | body | string | 是 | 邮箱地址 | | age | body | int | 否 | 年龄 | ### 请求示例 json { name: 张三, email: zhangsanexample.com, age: 28 }响应示例{ id: 123, name: 张三, email: zhangsanexample.com }错误码状态码说明400参数校验失败409邮箱已存在500服务器内部错误### 6.4 运行与验证 把这段 SKILL.md 和模板文件放进 .claude/skills/api-doc-generator 目录然后在 Claude Code 中请求用 api-doc-generator 为 UserController.java 生成接口文档预期结果是Agent 读取 Java 文件提取 /api/v1/users 相关的路由和注解信息按照模板输出一份 Markdown 文档。这里的重点不是文档内容多完整而是 Agent 能稳定地使用同一个模板不跑偏。 ## 7. 进阶实践用 Skill 串联人文社科研究任务 前面两个例子都是围绕软件开发的但如果 Agent Skills 只服务程序员那它就配不上“改变 AI 使用方式”这个评价。事实上在人文社科研究、市场分析、内容创作这些领域Skill 同样能发挥巨大作用。 我们来看一个研究场景。搜索热词里提到了“agent skills 赋能人文社科混合研究方法论文写作”这是一个很值得展开的方向。混合研究方法Mixed Methods Research通常同时涉及定量数据和定性数据研究者需要先对访谈记录做编码分析再结合问卷统计结果做交叉解释。整个流程方法成熟、步骤固定非常适合做成 Skill。 例如我们可以设计一个 qualitative-coding-skill专门辅助访谈文本的编码分析 markdown --- name: qualitative-coding-skill description: 对访谈记录等定性文本进行主题编码分析辅助社会科学研究者完成材料分析。当用户要求“编码分析”“主题分析”“处理访谈记录”时使用。 --- # 定性文本编码分析技能 本技能基于主题分析法Thematic Analysis框架对定性文本进行系统性编码。 ## 执行步骤 1. 读取用户提供的文本材料。 2. 进行初始编码Open Coding逐段标记出现的概念、事件、情绪。 3. 归纳主题Axial Coding将近似编码聚合成候选主题。 4. 提炼核心主题Selective Coding筛选与研究对象最相关的主题。 5. 输出编码表。 ## 输出格式 | 编码号 | 原文摘录 | 初始编码 | 候选主题 | 核心主题 | | --- | --- | --- | --- | --- | | C01 | (原文片段) | (概念) | (主题) | (核心主题) | ## 注意事项 - 编码必须忠实于原文不要自行补充事实。 - 摘录原文片段时保留说话者标记如「受访者A」。 - 如果文本量较大先按段落切分再逐段编码。这种 Skill 的价值在于研究者不需要反复向 AI 解释“请按主题分析法帮我处理”“编码表要包含哪些列”只需要提供文本材料Agent 就会按方法论的规范走完流程。输出结果可以直接导入 Excel 或 NVivo 继续处理。同样的思路还可以延伸到竞品分析、访谈问卷设计、文献综述结构搭建等领域。从这些例子里能看出Agent Skills 本质上是一套“方法论的封装格式”它能把某个领域的隐性经验转成显性文件让模型按部就班地执行。这也是为什么这个方向对非程序员也有很强的吸引力。8. 运行结果验证与正确性检查Skill 写完不能直接扔进生产环境先验证它真的按预期工作。我建议按下面的检查顺序来。第一验证 Skill 是否被识别。启动 Agent 客户端后先查看当前已加载的 Skills 列表。许多客户端提供类似skills list的命令claude skills list如果列表里能看到你创建的python-code-review说明目录扫描和元信息解析都没问题。如果看不到检查目录路径是否正确SKILL.md 文件名是否准确YAML frontmatter 是否缺少字段。第二验证触发词是否有效。在对话中故意使用description里的关键词发起请求看 Agent 是否加载技能。如果 Agent 只是普通回答而没有进入技能流程说明description写得不够明确或者触发条件设置不合适。你需要调整description使它更贴近用户的自然表达。第三验证脚本是否可执行。如果 Skill 中有辅助脚本先手动运行一遍。以我们的冲突检查脚本为例bash .claude/skills/python-code-review/scripts/check_conflict_markers.sh src/main.py如果脚本返回预期输出再让 Agent 调用它。这里真正容易踩坑的地方是Agent 在调用脚本时可能使用不同的工作目录脚本里的相对路径会失效。稳妥的做法是在脚本开头用绝对路径定位项目根目录或者让 SKILL.md 明确说明脚本的调用方式。第四验证输出格式是否稳定。同一个输入多生成几次观察 Agent 是否每次都按照 SKILL.md 里的模板输出。如果输出格式时好时坏通常是因为 SKILL.md 里的指令不够具体。你可以把“输出格式”部分写得更细致甚至给一段完整示例让模型有样板可循。9. 常见问题与排查方法下面整理了几个高概率遇到的问题按“现象 → 原因 → 排查 → 解决”的思路列成表格方便排查时快速定位。问题现象可能原因排查方式解决方案Skill 完全没被触发SKILL.md 目录或文件名错误检查目录路径和文件名是否为SKILL.md修正文件名确认目录在.claude/skills下Agent 不按 SKILL.md 执行description与用户请求不匹配在对话中尝试多个触发词重写 description包含更多自然表达辅助脚本执行失败工作目录不对或权限不足手动执行脚本复现在脚本中加入项目根目录定位逻辑Skill 之间互相干扰多个 Skill 的 description 相似查看 skills list分析触发冲突收敛 description让每个 Skill 覆盖不同场景输出格式不稳定SKILL.md 中的格式说明不够具体检查输出与模板差异在 SKILL.md 中增加完整输出示例更换设备后 Skill 失效Skill 未纳入版本管理检查项目是否包含 .claude/skills将 .claude/skills 目录加入 Git 仓库第一条“Skill 完全没被触发”是新手最常遇到的问题。常见原因是创建目录时把SKILL.md写成了skill.md或者SKILL.md.txt大小写错误会导致扫描器找不到。还有一个隐蔽问题是 frontmatter 中缺少description字段导致 Agent 无法判断何时启用该技能。第二条需要特别说明Skill 的触发机制通常不是“用户说出技能名”而是 Agent 根据用户请求和description做语义匹配。如果你把 description 写得太窄比如只写了“代码审查”用户说“帮我看看这段代码有什么问题”Agent 未必能联想到使用这个 Skill。更好的写法是列出多种触发表达例如“审查代码”“检查这段代码”“code review”“帮我找找 Bug”。10. 最佳实践与工程建议当你能稳定地创建和安装 Skill 之后下一步要考虑的是工程化。以下是几条经过社区验证的建议。10.1 保持职责单一一个 Skill 只做一件事。不要试图做一个“万能技能包”里面既管代码审查又管接口文档生成还管测试用例生成。职责单一的好处有三个description 容易写准、触发不会互相干扰、维护成本低。如果一个 Skill 的功能边界模糊Agent 常常会选错技能。10.2 把“规则”和“脚本”分开SKILL.md 放规则scripts 放脚本。规则是给模型读的用来指导它按步骤执行脚本是用来做确定性计算的比如正则校验、数据转换、文件检查。不要指望模型靠“思考”完成所有事能交给脚本的确定性操作就交给脚本。这能显著提升 Skill 的可靠性。10.3 description 是命中率的生命线很多人在写 SKILL.md 时把精力全放在正文忽略了对 description 的打磨。但 description 才是 Agent 选择技能的开关。写好 description 的核心方法是站在用户角度列出最自然的表达把同义词和变体都考虑进去。比如“文档生成”这个技能可以写“生成接口文档”“写 API 文档”“根据 Controller 输出文档”等。10.4 Skill 应该纳入版本管理把.claude/skills目录纳入 Git 仓库和代码一起提交。这样团队成员拉到代码时自动拥有相同的技能集避免“在我机器上能触发在你的机器上不行”的问题。同时代码评审时也能 review Skill 的变更防止某个技能被悄悄改成高风险行为。10.5 安全边界与最小权限如果你的 Skill 会调用外部命令或访问网络一定要遵循最小权限原则。不要在一个 Skill 里写“可以读写任意路径”的指令。例如代码审查 Skill 只需要读文件就不要在描述中暗示“可以修改文件”。如果 Skill 要执行 bash 脚本先审查脚本内容避免使用会出现风险的操作比如删除生产目录、修改权限、直接连接数据库执行 DDL。在涉及生产环境的变更时务必先在测试环境验证确认无误后再应用。这个原则对 AI 工具链同样适用。10.6 从“用 Skill”走向“编排 Skill”单个 Skill 威力有限但多个 Skill 组合起来就能形成一条完整的自动化流水线。例如API 文档生成 Skill 代码审查 Skill 单元测试生成 Skill三者按顺序执行就是一个简单的“新接口开发完成后的质量保障流程”。当你开始考虑 Skill 之间的依赖关系和执行顺序时你其实就已经在走向“Agent 工作流编排”了。这也是从“会造 Skill”到“会用 Agent”的必经之路。11. 总结从 Skill 到 Agent 的进阶路径Agent Skills 是 AI 应用层一个不大但很关键的转折。它让能力的复用从“复制粘贴提示词”升级为“安装技能包”让团队协作和知识沉淀有了更标准的载体。从本文的示例可以看到学会创建 Skill 并不难搭一个目录、写一个 SKILL.md、加几个辅助脚本就完成了一个最小可用技能。难点在于把好用的结构沉淀成你自己的方法论。如果你想继续深入我建议按这几步走第一步把你日常工作里重复出现三次以上的 AI 任务记录下来看看它们能不能拆成固定的步骤。第二步挑一个最简单的任务按本文的格式做一个 Skill不用追求大而全先跑通。第三步把 Skill 放进团队的 Git 仓库收集同事的使用反馈迭代 description 和输出格式。第四步研究多个 Skill 之间的编排顺序思考哪些任务可以组合成一条自动流程。这里还有一个实用提醒不要迷信“装了某个 Skill 就能让 AI 一夜变强”。Skill 的上限取决于你封装的方法论是否可靠。如果你自己都说不清这个任务的执行步骤那就先别急着做 Skill。先把流程梳理清楚再考虑把它教给 Agent。最后想强调一点AI 工具会持续更新今天讲的目录规范、安装命令明天可能就有更优雅的写法。但 Skill 的底层思想不会过时——把经验封装成文件让 AI 按标准流程工作再通过版本管理和团队协作持续迭代。掌握了这个思想无论未来工具怎么变你都能快速适应。如果你正在探索 Agent、Claude Code 或 AI 自动化的新用法不妨从今天开始把第一个 Skill 建起来。它会让你重新认识到使用 AI 的最高效方式不是每次重新描述需求而是把需求固化成能力让 AI 随取随用。 Agent Skills 实战：从提示词到可复用技能包，安装与自建指南
如果你最近刷技术社区可能会发现一个现象讨论的焦点正在从“如何写更好的 Prompt”悄悄转向“如何给 Agent 安装技能”。这其实是 Agent 使用方式的一个重要分水岭。先说结论Agent Skills 最容易被低估的地方是它把“对话能力”变成了“文件系统”。从此以后你使用 AI 的方式不再是一个“聊天窗口 一段提示词”而是一套可以安装、复用、分享、版本管理的能力包。你可以把 Skills 理解为给 AI 配的“职业资格证”——装上财务分析技能它就能按财务分析师的思路工作装上网页抓取技能它就能按标准流程采集和清洗数据。同一个模型装上不同的 Skill干不同岗位的活。这个变化对开发者的影响是非常直接的以前你要为每个项目写一大段系统提示词让模型记住“输出格式是什么”“处理步骤是什么”“遇到异常怎么兜底”现在这些规则可以被打包成 Skill 文件按需加载、随时卸载。更重要的是Skill 不是只能靠别人发布你可以自己造。网上已经有很多讨论“Agent Skills 和 AI Skills 到底有什么区别”“有什么好用的 Claude Code Skills 值得装”也有越来越多非程序员用户在研究怎么用 Agent Skills 辅助论文写作和文本分析。这篇文章就围绕“从会用到会造”这条主线展开。我会先讲清楚 Agent Skills 的核心概念和它与普通提示词的本质差异然后带你从零搭建一个可用的 Skill再通过代码审查、文档生成、研究分析这三个真实场景讲透 Skill 的设计、安装、验证和排错。整篇文章读完你应该能独立完成“自己设计一个 Skill → 安装进 Agent → 在真实项目中使用”的完整闭环。1. Agent Skills 究竟解决了什么问题要理解 Agent Skills 的价值先回到一个最朴素的场景。假设你是一名 Java 后端工程师每天都要让 AI 帮忙写单元测试。过去的做法是打开聊天窗口输入一段非常详细的指令“请为 UserService 类生成单元测试使用 JUnit5 Mockito覆盖正常流程、异常分支、边界条件测试类放在 src/test/java 目录下。”这段指令确实能让模型输出不错的结果但下一次换一个 Service 类你还要重新输入几乎一样的指令。更麻烦的是如果团队里有五个人都在用 AI 辅助写测试五个人可能各自写了一套要求有人要求 Mockito 写法有人要求用 AssertJ有人干脆不提框架让模型自由发挥。结果就是AI 生成的测试代码风格五花八门维护成本很高。Agent Skills 解决的就是这个问题。它把“写单元测试”这件事从“一段临时 Prompt”升级成了“一个标准技能包”。技能包里写清楚了目标、步骤、输出格式、边界条件、甚至附加了一个检查脚本。当 Agent 检测到用户请求命中这个技能时它不再是自由发挥而是按照技能包里的流程执行。技能包可以被团队共享放进 Git 仓库任何成员拉到项目后都能使用同一套标准。用一句话总结Prompt 是临场发挥的提示Skill 是沉淀下来的操作规程。这也解释了为什么 Anthropic 在 Claude Code 中引入 Skills 之后社区的反应会那么强烈。Skill 本质上改变了 AI 应用的分发方式。以前我们分发的是“模型权重”或“API 接口”现在我们可以分发“AI 的职业能力”。一个研究者可以分享一个“人文社科混合方法论文分析 Skill”一个前端开发者可以分享一个“React 组件代码审查 Skill”。别人拿到这个 Skill不需要理解背后的逻辑直接就能让 Agent 具备同样的能力。从工程视角看它还有一个隐蔽的优势Skill 让 AI 项目更可控。因为技能的行为是定义在文件里的你可以 review、测试、回滚。这比在系统提示词里维护一堆隐性规则要可靠得多。2. AI Skills 与 Agent Skills一次讲清楚在继续往下之前有必要先厘清一个常见困惑AI Skills 和 Agent Skills 到底是不是一个东西网上搜索热词里同时出现了“ai agent skills”“ai skills和agent的区别”说明确实有不少人在这个概念上纠结。我的理解是这样的AI Skills 是更宽泛的概念指的是 AI 系统具备的某种能力。它可以是一个微调过的模型、一个精心设计的提示词模板、一个工具调用策略甚至是一个 RAG 检索管道。只要它让 AI 在某些任务上表现得更好都可以叫 AI Skill。这个词更偏向“能力”本身。Agent Skills 则更具体它通常指以文件/目录为载体的、可被 Agent 动态加载的技能包。一个 Agent Skill 包含 SKILL.md 描述文件和可选的参考脚本、资源文件。Agent 在运行时会扫描可用的 Skills 目录根据用户请求匹配 description然后加载对应技能并执行。可以这样对比维度AI SkillsAgent Skills概念范围泛指 AI 的任何专项能力特指 Agent 可加载的技能包载体模型、提示词、工具、流程都可能通常是一个目录 SKILL.md 脚本分发方式不固定可能集成在模型里可复制、可安装、可放进 Git 仓库是否必须依赖 Agent不一定普通聊天也能体现通常需要 Agent 框架配合典型例子模型的代码能力、翻译能力Claude Code 中的 code-review Skill有一个更形象的类比AI Skills 像是“人会弹钢琴”这种能力描述Agent Skills 则像“一本乐谱加上练琴步骤”。乐谱可以被复制、被分发、被教学任何一个会弹琴的人拿到乐谱都能演奏同一首曲子。不过在实际使用中这两个词经常被混用。社区里说“安装一个 Skill”时通常指的就是 Agent Skills而且大多数时候说的是 Claude Code Skills。这是因为 Anthropic 的 Agent Skills 规范在社区里传播最广也有官方的技能仓库可以直接装。理解到这一层阅读各类资料时就不会被名词绕晕凡是提到“skills 目录”“SKILL.md”“add-skill”的都是在说 Agent Skills凡是空泛地讲“AI 应该具备某种能力”的多半是在说 AI Skills。3. Agent Skills 的适用场景与使用边界什么样的任务适合做成 Skill我的判断是凡是“流程稳定、输出格式明确、重复出现”的任务都值得考虑 Skill 化。反过来如果一项任务每次都不一样没有固定套路做成 Skill 反而会限制模型的灵活性。几个典型场景第一类是代码工程类任务。例如单元测试生成、代码审查、依赖升级检查、README 生成、API 文档生成。这类任务的最大特点是规则明确团队可以约定统一的规范让 Agent 按规范执行。搜索热词里经常出现的“好用的 Claude Code Skills 安装”“claude code skills 推荐”大多集中在这个方向。第二类是数据与文本处理任务。例如从非结构化文本中提取结构化字段、清洗 CSV 数据、按指定模板生成周报、转换文档格式。这类任务适合做成 Skill是因为输入输出边界清晰而且每个步骤都可以写清楚。第三类是研究分析任务。这可能是最容易被忽视的方向。热搜词里有一条很有意思“agent skills 赋能人文社科混合研究方法论文写作”。很多人以为 Skill 只服务程序员其实一个“文献编码分析 Skill”完全可以辅助研究者做定性数据编码、主题归纳、文献综述框架搭建。Skill 里写清楚分析步骤和输出表格结构研究者只需要把文本材料交给 AgentAgent 就能按 Socra 或主题分析法的框架去处理。再说说不适合的场景。需要强实时交互的任务比如多轮商业谈判模拟需要非结构化创意的任务比如头脑风暴写小说需要访问高度敏感数据的任务比如处理包含大量个人隐私的医疗记录。这些场景里Skill 反而会成为负担或者引入不必要的安全风险。Agent 的自主执行能力越强越要限制它的行动边界而不是把更多权限交给它。4. 环境准备与前置条件在开始创建 Skill 之前我们需要确认环境满足要求。这里提醒一句AI 工具链迭代很快下面的版本描述是一般性说明具体版本请以你安装时的官方文档为准。重点是理解流程而不是背参数。首先你需要一个支持 Agent Skills 的 Agent 客户端。目前社区讨论最集中的是 Claude Code包括命令行版本和桌面版本。Claude Code 在较新的版本中加入了 Skills 机制能够扫描项目目录下的.claude/skills目录也可以安装官方仓库或其他来源的 Skill。其次需要确保你的机器上有基础的命令行工具例如bash、curl以及你希望在 Skill 脚本中使用的语言环境。如果你要写 Python 辅助脚本就需要安装 Python如果要写 Node 脚本就需要 Node.js 等。这些不是 Agent 本身的依赖而是你创建的 Skill 的运行时依赖。我们用一个最小环境清单来说明操作系统macOS / Linux / WindowsWindows 建议使用 WSL 或 Git Bash Agent 客户端Claude Code 或同类支持 Skills 的客户端 命令行工具bash、git 脚本语言Python 3.x 或 Node.js 18如果你想先跑通官方示例可以查看 Anthropic 官方发布的 skills 仓库按 README 说明进行下载和安装。最好先确认一下你的 Claude Code 版本是否支持 Skills可以运行claude --version如果版本过于老旧Skills 可能无法识别建议先更新到最新版本。注意不要在生产依赖中盲目使用最新版先在测试项目里验证兼容性。5. 从会用到会造手把手创建第一个 Skill现在进入核心部分我们从一个空目录开始创建一个真实的 Skill。为了贴近大多数读者的需求我用“Python 代码审查”作为示例。这个 Skill 的实际价值很直观团队可以约定统一代码规范Agent 按这套规范审查代码而不是每次临时描述想要什么。5.1 创建目录结构Agent Skills 的规范通常要求一个 Skill 对应一个目录目录内包含SKILL.md文件文件名必须是这个大写的SKILL.md。除此之外可以按需创建scripts目录存放辅助脚本assets目录存放参考文件。我们创建如下结构. └── .claude └── skills └── python-code-review ├── SKILL.md └── scripts └── check_conflict_markers.sh这里我把 Skill 放在项目的.claude/skills目录下这是 Claude Code 扫描的默认路径之一。如果你的客户端支持用户级 Skills 目录也可以放进去这样所有项目都能用。5.2 编写 SKILL.mdSKILL.md是 Skill 的灵魂。它的格式很接近 Markdown 文档但顶部有一段 YAML frontmatter用来写元信息。核心字段是name和description。--- name: python-code-review description: 对 Python 代码进行规范性审查。当用户要求“审查代码”“检查提交”“code review”或提供 Python 文件路径时使用。 --- # Python 代码审查技能 本技能用于对 Python 代码进行系统性检查并在代码可能存在问题的地方给出修改建议。 ## 审查范围 1. 正确性空指针、异常处理缺失、边界条件处理不当、条件判断写反。 2. 安全性硬编码密钥、动态执行用户输入、不安全的反序列化。 3. 可维护性命名不清晰、函数过长、重复代码、模块职责混乱。 4. 性能循环内执行数据库查询、不必要的重复计算、资源未释放。 ## 执行步骤 1. 获取用户提供的文件路径或代码内容。 2. 使用工具读取文件内容或直接接收用户粘贴的代码。 3. 按上述四个维度逐项检查。 4. 如果有 scripts/check_conflict_markers.sh先运行它检查合并冲突标记。 5. 输出报告格式见下。 ## 输出格式 每个问题按以下 Markdown 模板输出 markdown ### 问题 1一句话概括问题 - 文件file_path - 行号line_number - 级别严重 / 建议 - 说明为什么这是一个问题 - 修改建议具体修改建议必要时给代码示例最后给出总结## 审查总结 共发现 X 个严重问题Y 个建议。 推荐下一步最优先处理哪一类问题注意事项不要修改用户代码只输出审查意见。如果无法确定某处是否有问题标记为“建议”不要武断。不要输出超出代码审查范围的内容。这个 SKILL.md 的核心作用是告诉 Agent什么时候触发、按什么顺序执行、输出什么格式、有哪些边界。模型看到这份文档后会把它当成操作手册来执行。 ### 5.3 添加辅助脚本 辅助脚本不是必需的但如果你的 Skill 需要执行确定性检查脚本非常有用。比如检查文件中是否残留 Git 合并冲突标记这种任务靠模型肉眼找不一定稳定用一个正则脚本更可靠。 bash #!/usr/bin/env bash # 文件路径scripts/check_conflict_markers.sh # 用法bash check_conflict_markers.sh 文件路径 # 功能检测文件中是否残留 Git 合并冲突标记 file$1 if [ ! -f $file ]; then echo 文件不存在: $file exit 1 fi grep -nE ^(||) $file { echo 发现 Git 合并冲突标记请先解决冲突后再审查。 exit 2 } echo 未发现合并冲突标记。脚本逻辑不复杂接收一个文件路径用正则查找冲突标记。如果发现冲突标记退出码为 2Agent 可以据此停止审查先让用户解决冲突。5.4 安装并验证 Skill目录创建好之后你需要让 Agent 能识别这个 Skill。不同客户端的具体命令会有差异下面的写法是最常见的安装方式# 在项目根目录执行 claude --add-skill .claude/skills/python-code-review如果客户端已经自动扫描.claude/skills目录那么重启客户端后Skill 应该就能被识别。你可以输入下面这句话来测试请用 python-code-review 技能审查 src/main.py 文件如果 Agent 正确加载了 Skill它应该会按照 SKILL.md 里的执行步骤来响应并在审查前先运行合并冲突检查脚本。6. 完整示例一个真正可用的“文档生成” Skill光有代码审查一个示例还不够。为了展示 Skill 的设计弹性我们再做一个完全不同风格的 Skill针对 API 接口的文档生成。这个 Skill 不依赖脚本纯粹靠规则驱动适用于团队需要统一接口文档格式的场景。6.1 创建目录结构. └── .claude └── skills └── api-doc-generator ├── SKILL.md └── templates └── endpoint-doc.md6.2 编写 SKILL.md--- name: api-doc-generator description: 根据后端接口代码生成 API 接口文档。当用户提供 Controller 文件、路由文件、接口定义时使用适合需要编写 REST API 文档的场景。 --- # API 文档生成技能 本技能用于从接口源码中提取信息生成结构化的 Markdown API 文档。 ## 触发条件 - 用户要求“生成接口文档”“写 API 文档”“generate API doc” - 用户提供包含路由定义的源代码文件 - 用户要求把某个 Controller 转换为文档 ## 执行步骤 1. 读取用户指定的接口源码文件。 2. 解析出 - 接口路径Path - HTTP 方法GET / POST / PUT / DELETE / PATCH - 请求参数Query、Path、Body - 请求头Header - 响应结构Response 3. 按标准模板输出文档。 ## 输出模板 每个接口输出一节参考 templates/endpoint-doc.md。 ## 注意 - 参数必须标注是否必填。 - 响应示例应从代码中提取真实字段不要编造。 - 如果源码中缺少某个字段标注“未定义”不要自行推断。6.3 编写文档模板# 接口文档 ## POST /api/v1/users 创建新用户。 ### 请求参数 | 参数名 | 位置 | 类型 | 必填 | 说明 | | --- | --- | --- | --- | --- | | name | body | string | 是 | 用户姓名 | | email | body | string | 是 | 邮箱地址 | | age | body | int | 否 | 年龄 | ### 请求示例 json { name: 张三, email: zhangsanexample.com, age: 28 }响应示例{ id: 123, name: 张三, email: zhangsanexample.com }错误码状态码说明400参数校验失败409邮箱已存在500服务器内部错误### 6.4 运行与验证 把这段 SKILL.md 和模板文件放进 .claude/skills/api-doc-generator 目录然后在 Claude Code 中请求用 api-doc-generator 为 UserController.java 生成接口文档预期结果是Agent 读取 Java 文件提取 /api/v1/users 相关的路由和注解信息按照模板输出一份 Markdown 文档。这里的重点不是文档内容多完整而是 Agent 能稳定地使用同一个模板不跑偏。 ## 7. 进阶实践用 Skill 串联人文社科研究任务 前面两个例子都是围绕软件开发的但如果 Agent Skills 只服务程序员那它就配不上“改变 AI 使用方式”这个评价。事实上在人文社科研究、市场分析、内容创作这些领域Skill 同样能发挥巨大作用。 我们来看一个研究场景。搜索热词里提到了“agent skills 赋能人文社科混合研究方法论文写作”这是一个很值得展开的方向。混合研究方法Mixed Methods Research通常同时涉及定量数据和定性数据研究者需要先对访谈记录做编码分析再结合问卷统计结果做交叉解释。整个流程方法成熟、步骤固定非常适合做成 Skill。 例如我们可以设计一个 qualitative-coding-skill专门辅助访谈文本的编码分析 markdown --- name: qualitative-coding-skill description: 对访谈记录等定性文本进行主题编码分析辅助社会科学研究者完成材料分析。当用户要求“编码分析”“主题分析”“处理访谈记录”时使用。 --- # 定性文本编码分析技能 本技能基于主题分析法Thematic Analysis框架对定性文本进行系统性编码。 ## 执行步骤 1. 读取用户提供的文本材料。 2. 进行初始编码Open Coding逐段标记出现的概念、事件、情绪。 3. 归纳主题Axial Coding将近似编码聚合成候选主题。 4. 提炼核心主题Selective Coding筛选与研究对象最相关的主题。 5. 输出编码表。 ## 输出格式 | 编码号 | 原文摘录 | 初始编码 | 候选主题 | 核心主题 | | --- | --- | --- | --- | --- | | C01 | (原文片段) | (概念) | (主题) | (核心主题) | ## 注意事项 - 编码必须忠实于原文不要自行补充事实。 - 摘录原文片段时保留说话者标记如「受访者A」。 - 如果文本量较大先按段落切分再逐段编码。这种 Skill 的价值在于研究者不需要反复向 AI 解释“请按主题分析法帮我处理”“编码表要包含哪些列”只需要提供文本材料Agent 就会按方法论的规范走完流程。输出结果可以直接导入 Excel 或 NVivo 继续处理。同样的思路还可以延伸到竞品分析、访谈问卷设计、文献综述结构搭建等领域。从这些例子里能看出Agent Skills 本质上是一套“方法论的封装格式”它能把某个领域的隐性经验转成显性文件让模型按部就班地执行。这也是为什么这个方向对非程序员也有很强的吸引力。8. 运行结果验证与正确性检查Skill 写完不能直接扔进生产环境先验证它真的按预期工作。我建议按下面的检查顺序来。第一验证 Skill 是否被识别。启动 Agent 客户端后先查看当前已加载的 Skills 列表。许多客户端提供类似skills list的命令claude skills list如果列表里能看到你创建的python-code-review说明目录扫描和元信息解析都没问题。如果看不到检查目录路径是否正确SKILL.md 文件名是否准确YAML frontmatter 是否缺少字段。第二验证触发词是否有效。在对话中故意使用description里的关键词发起请求看 Agent 是否加载技能。如果 Agent 只是普通回答而没有进入技能流程说明description写得不够明确或者触发条件设置不合适。你需要调整description使它更贴近用户的自然表达。第三验证脚本是否可执行。如果 Skill 中有辅助脚本先手动运行一遍。以我们的冲突检查脚本为例bash .claude/skills/python-code-review/scripts/check_conflict_markers.sh src/main.py如果脚本返回预期输出再让 Agent 调用它。这里真正容易踩坑的地方是Agent 在调用脚本时可能使用不同的工作目录脚本里的相对路径会失效。稳妥的做法是在脚本开头用绝对路径定位项目根目录或者让 SKILL.md 明确说明脚本的调用方式。第四验证输出格式是否稳定。同一个输入多生成几次观察 Agent 是否每次都按照 SKILL.md 里的模板输出。如果输出格式时好时坏通常是因为 SKILL.md 里的指令不够具体。你可以把“输出格式”部分写得更细致甚至给一段完整示例让模型有样板可循。9. 常见问题与排查方法下面整理了几个高概率遇到的问题按“现象 → 原因 → 排查 → 解决”的思路列成表格方便排查时快速定位。问题现象可能原因排查方式解决方案Skill 完全没被触发SKILL.md 目录或文件名错误检查目录路径和文件名是否为SKILL.md修正文件名确认目录在.claude/skills下Agent 不按 SKILL.md 执行description与用户请求不匹配在对话中尝试多个触发词重写 description包含更多自然表达辅助脚本执行失败工作目录不对或权限不足手动执行脚本复现在脚本中加入项目根目录定位逻辑Skill 之间互相干扰多个 Skill 的 description 相似查看 skills list分析触发冲突收敛 description让每个 Skill 覆盖不同场景输出格式不稳定SKILL.md 中的格式说明不够具体检查输出与模板差异在 SKILL.md 中增加完整输出示例更换设备后 Skill 失效Skill 未纳入版本管理检查项目是否包含 .claude/skills将 .claude/skills 目录加入 Git 仓库第一条“Skill 完全没被触发”是新手最常遇到的问题。常见原因是创建目录时把SKILL.md写成了skill.md或者SKILL.md.txt大小写错误会导致扫描器找不到。还有一个隐蔽问题是 frontmatter 中缺少description字段导致 Agent 无法判断何时启用该技能。第二条需要特别说明Skill 的触发机制通常不是“用户说出技能名”而是 Agent 根据用户请求和description做语义匹配。如果你把 description 写得太窄比如只写了“代码审查”用户说“帮我看看这段代码有什么问题”Agent 未必能联想到使用这个 Skill。更好的写法是列出多种触发表达例如“审查代码”“检查这段代码”“code review”“帮我找找 Bug”。10. 最佳实践与工程建议当你能稳定地创建和安装 Skill 之后下一步要考虑的是工程化。以下是几条经过社区验证的建议。10.1 保持职责单一一个 Skill 只做一件事。不要试图做一个“万能技能包”里面既管代码审查又管接口文档生成还管测试用例生成。职责单一的好处有三个description 容易写准、触发不会互相干扰、维护成本低。如果一个 Skill 的功能边界模糊Agent 常常会选错技能。10.2 把“规则”和“脚本”分开SKILL.md 放规则scripts 放脚本。规则是给模型读的用来指导它按步骤执行脚本是用来做确定性计算的比如正则校验、数据转换、文件检查。不要指望模型靠“思考”完成所有事能交给脚本的确定性操作就交给脚本。这能显著提升 Skill 的可靠性。10.3 description 是命中率的生命线很多人在写 SKILL.md 时把精力全放在正文忽略了对 description 的打磨。但 description 才是 Agent 选择技能的开关。写好 description 的核心方法是站在用户角度列出最自然的表达把同义词和变体都考虑进去。比如“文档生成”这个技能可以写“生成接口文档”“写 API 文档”“根据 Controller 输出文档”等。10.4 Skill 应该纳入版本管理把.claude/skills目录纳入 Git 仓库和代码一起提交。这样团队成员拉到代码时自动拥有相同的技能集避免“在我机器上能触发在你的机器上不行”的问题。同时代码评审时也能 review Skill 的变更防止某个技能被悄悄改成高风险行为。10.5 安全边界与最小权限如果你的 Skill 会调用外部命令或访问网络一定要遵循最小权限原则。不要在一个 Skill 里写“可以读写任意路径”的指令。例如代码审查 Skill 只需要读文件就不要在描述中暗示“可以修改文件”。如果 Skill 要执行 bash 脚本先审查脚本内容避免使用会出现风险的操作比如删除生产目录、修改权限、直接连接数据库执行 DDL。在涉及生产环境的变更时务必先在测试环境验证确认无误后再应用。这个原则对 AI 工具链同样适用。10.6 从“用 Skill”走向“编排 Skill”单个 Skill 威力有限但多个 Skill 组合起来就能形成一条完整的自动化流水线。例如API 文档生成 Skill 代码审查 Skill 单元测试生成 Skill三者按顺序执行就是一个简单的“新接口开发完成后的质量保障流程”。当你开始考虑 Skill 之间的依赖关系和执行顺序时你其实就已经在走向“Agent 工作流编排”了。这也是从“会造 Skill”到“会用 Agent”的必经之路。11. 总结从 Skill 到 Agent 的进阶路径Agent Skills 是 AI 应用层一个不大但很关键的转折。它让能力的复用从“复制粘贴提示词”升级为“安装技能包”让团队协作和知识沉淀有了更标准的载体。从本文的示例可以看到学会创建 Skill 并不难搭一个目录、写一个 SKILL.md、加几个辅助脚本就完成了一个最小可用技能。难点在于把好用的结构沉淀成你自己的方法论。如果你想继续深入我建议按这几步走第一步把你日常工作里重复出现三次以上的 AI 任务记录下来看看它们能不能拆成固定的步骤。第二步挑一个最简单的任务按本文的格式做一个 Skill不用追求大而全先跑通。第三步把 Skill 放进团队的 Git 仓库收集同事的使用反馈迭代 description 和输出格式。第四步研究多个 Skill 之间的编排顺序思考哪些任务可以组合成一条自动流程。这里还有一个实用提醒不要迷信“装了某个 Skill 就能让 AI 一夜变强”。Skill 的上限取决于你封装的方法论是否可靠。如果你自己都说不清这个任务的执行步骤那就先别急着做 Skill。先把流程梳理清楚再考虑把它教给 Agent。最后想强调一点AI 工具会持续更新今天讲的目录规范、安装命令明天可能就有更优雅的写法。但 Skill 的底层思想不会过时——把经验封装成文件让 AI 按标准流程工作再通过版本管理和团队协作持续迭代。掌握了这个思想无论未来工具怎么变你都能快速适应。如果你正在探索 Agent、Claude Code 或 AI 自动化的新用法不妨从今天开始把第一个 Skill 建起来。它会让你重新认识到使用 AI 的最高效方式不是每次重新描述需求而是把需求固化成能力让 AI 随取随用。