Free Preview
先试读：Claude Code Skill 到底是什么
很多人第一次听到 Skill，会把它理解成“给 Claude 多塞一点背景资料”。这个理解只说对了一小半。
Claude Code Skill 的核心不是让模型“记住你是谁”，而是把一类任务的判断标准、操作流程、文件资源和工具使用方式封装起来。下一次遇到同类任务时，Claude Code 不需要从零猜，也不需要你再写一大段提示词，它可以加载这份 Skill，然后按里面的步骤工作。
这篇能解决什么问题
- 把一句模糊需求改成 AI 能执行、你能验收的任务卡。
- 知道执行前要先检查哪些文件、风险点和验证命令。
- 避免 AI 顺手改无关内容，最后只交付可审、可回退的改动。
付费后能看到哪些内容
- Skill 解决的不是“记忆”，而是“可复用流程”
- Skill 最适合沉淀什么
- 它和 CLAUDE.md、提示词、命令、MCP 有什么区别
- Skill 不是越多越好
可以先照着试的一句话
这是我要改的功能：___。请先阅读项目结构，列出会动哪些文件、风险点和验证命令；等我确认范围后，再开始做最小改动。
试读到这里先判断是否对你的任务有用；完整文章会继续展开步骤、案例、模板和避坑细节。
Skill 解决的不是“记忆”，而是“可复用流程”
很多人第一次听到 Skill，会把它理解成“给 Claude 多塞一点背景资料”。这个理解只说对了一小半。
Claude Code Skill 的核心不是让模型“记住你是谁”，而是把一类任务的判断标准、操作流程、文件资源和工具使用方式封装起来。下一次遇到同类任务时，Claude Code 不需要从零猜，也不需要你再写一大段提示词，它可以加载这份 Skill，然后按里面的步骤工作。
一个 Skill 通常是一个文件夹，里面必须有 SKILL.md。更复杂的 Skill 还可以带 scripts/、references/、assets/ 等资源。官方文档把 Skill 描述为用于扩展 Claude Code 能力的模块化说明，Claude 会在相关时自动使用，也可以由用户用斜杠方式直接调用。
假设有一个模拟电商团队，每周都要让 Claude Code 检查活动页：确认移动端不溢出、CTA 链接正确、价格文案没有矛盾、埋点没有遗漏。
如果每次都手写提示词，就会漏条件。更好的做法是写一个 landing-page-review Skill，把检查步骤、验收标准、常见坑和截图验证方式写进去。以后只要说“帮我 review 这个活动页”，Claude Code 就可以按这套流程做。
所以 Skill 不是一个“万能增强包”。它更像给某类重复任务配了一份 SOP。任务越重复、流程越稳定、验收标准越明确，越适合做成 Skill。
Skill 最适合沉淀什么
适合沉淀的不是泛泛知识，而是“下次还会重复用”的东西：
• 某类文件怎么处理，比如 PDF、Excel、PPT、前端页面。
• 某个团队的固定规范，比如提交信息、代码审查、文案风格。
• 某种工具的固定流程，比如部署、截图验证、表格生成。
• 某类输出的固定结构，比如周报、客户摘要、PRD、合同审阅清单。
Skill 不会修改模型权重，也不会让 Claude 永久学会某个能力。它是在合适时把一组说明和资源加载进当前任务，让 Claude Code 按这组说明工作。
如果资料会频繁变化，Skill 里应该写“去哪里读取最新资料”，而不是把一堆过时内容硬塞进 SKILL.md。
它和 CLAUDE.md、提示词、命令、MCP 有什么区别
如果边界没分清，最后会把所有东西都塞进 Skill，反而越用越乱。
| 机制 | 主要解决什么 | 适合放什么 | 不适合放什么 |
|---|---|---|---|
| 普通提示词 | 一次性任务表达 | 这次任务的目标、输入、限制、输出格式 | 下次也会重复用的大段流程 |
| CLAUDE.md | 项目级长期背景 | 项目结构、技术栈、编码规范、禁止事项、部署规则 | 某个细分任务的完整操作手册 |
| Slash Command | 手动触发一个固定命令 | 明确的快捷入口，比如“生成 changelog” | 需要自动判断是否使用的一整套专业流程 |
| MCP | 连接外部工具和数据源 | 数据库、SaaS、浏览器、文件系统、API 工具能力 | 告诉 Claude “该怎么做”的业务流程 |
| Hook | 在特定事件自动执行脚本 | 提交前检查、命令前后审计、自动格式化 | 需要模型判断和写作的任务流程 |
| Skill | 可复用的专业工作流 | 触发条件、操作步骤、判断标准、参考资料、脚本和模板 | 密钥、隐私数据、实时数据库副本、无边界的大杂烩知识库 |
最实用的判断方式是：如果这件事只是“这次要告诉 Claude 的信息”，写在提示词里；如果是“这个项目长期都要遵守的事实”，写进 CLAUDE.md；如果是“一类任务的可复用做法”，做成 Skill。
Skill 不是越多越好
Skill 太多、描述太宽，会带来两个问题：第一，Claude Code 更难判断该用哪个；第二，多个 Skill 的指令可能互相冲突。比如同时有“前端代码规范”“落地页审查”“移动端视觉 QA”三个 Skill，如果它们都写得很宽，Claude 可能不知道该加载哪个，或者加载后发现标准不一致。
不要写一个叫 frontend 的大 Skill。可以拆成：
responsive-qa：专门检查移动端布局、溢出、字号和点击区域。
landing-copy-review：专门检查落地页文案、CTA、价值表达和转化路径。
react-component-review：专门检查 React 组件拆分、状态管理和可维护性。
拆细之后，每个 Skill 的触发更准，内容也更短。
Claude Code 怎么发现和调用 Skill
理解触发机制，才能写出真正会被调用的 Skill。
一个 Skill 的入口是 SKILL.md。这个文件开头有 YAML frontmatter，最关键的是 name 和 description。其中 description 很重要，因为 Claude Code 会用它判断这个 Skill 什么时候相关。
---
name: landing-page-review
description: Review static landing pages for responsive layout, CTA clarity, copy consistency, analytics hooks, and launch readiness. Use when checking HTML/CSS/JS landing pages before publishing.
---
# Landing Page Review
Follow this workflow when reviewing a landing page...自动触发
用户提出的任务和 description 匹配时，Claude Code 会判断是否加载对应 Skill。
显式调用
官方文档说明，也可以用 /skill-name 直接调用一个 Skill。适合你很确定要用哪一个的时候。
组合使用
复杂任务可能同时涉及多个 Skill。关键是每个 Skill 要足够聚焦，不要互相覆盖。
description 要写“触发场景”，不是写广告语
一个差的描述通常是：“帮助处理网页”。这太宽，Claude Code 很难判断什么时候该用。一个好的描述会写清楚任务、对象和触发词：处理什么文件、做什么检查、什么时候使用。
| 写法 | 示例 | 问题或优点 |
|---|---|---|
| 太宽 | description: For frontend work. |
几乎所有前端任务都可能匹配，触发不准。 |
| 太窄 | description: Use only when reviewing the file index.html. |
换一个页面就触发不了，复用价值低。 |
| 合适 | description: Review static HTML/CSS landing pages for responsive layout, CTA clarity, broken links, paywall visibility, and launch readiness. |
对象、任务和验收点都清楚，触发更稳定。 |
Claude Code 官方文档说明：Skills 会从个人、项目和插件来源自动发现；用户可以询问 Claude 当前有哪些可用 Skills；创建 Skill 时，目录中需要包含 SKILL.md；测试时可以用匹配 description 的问题触发。
官方文档入口：Claude Code Skills 文档。
个人、项目、插件三个作用域怎么选
同一个 Skill 放在不同位置，代表不同的共享范围和维护责任。
个人 Skill
路径通常是 ~/.claude/skills/skill-name/SKILL.md。
适合个人写作风格、个人审稿习惯、自己的自动化流程。
项目 Skill
路径通常是 .claude/skills/skill-name/SKILL.md。
适合和项目一起提交到 git，让团队成员拉代码后自动获得同一套规范。
插件 Skill
插件可以把 Skills 打包在 skills/ 目录中。
适合跨团队、跨项目分发，或者做成一组可安装的能力包。
最保守的选择：自己用的放个人，团队项目规范放项目，要分发给多人安装的做插件。
为什么不要把所有 Skill 都放个人目录
个人目录方便，但它有一个问题：项目换人、换电脑、换环境后，别人拿不到你的 Skill。比如一个模拟 SaaS 项目里有专门的“计费逻辑审查 Skill”，如果它只放在某个员工的个人目录，其他人不会自动使用这套检查流程。
这类 Skill 更应该放进项目的 .claude/skills/，跟代码一起走。这样团队成员拉取最新代码后，Claude Code 才能在同一个项目里使用同一套工作规范。
项目 Skill 很可能会提交到 git。不要把客户名单、真实合同、密钥、内部账号、个人身份信息写进 Skill。需要举例时，用模拟数据；需要读取真实资料时，让 Skill 指示 Claude Code 去读取受控路径，并遵守权限规则。
什么时候应该写 Skill，什么时候不该写
Skill 的价值来自复用。没有复用，就只是把提示词复杂化。
应该写 Skill 的情况
• 这个任务你已经重复做过三次以上。
• 每次都要提醒 Claude Code 同一批规则。
• 任务有明确的检查清单或验收标准。
• 需要固定使用某些脚本、模板、参考文档。
• 团队希望每个人都按同一套流程交付。
不该写 Skill 的情况
• 只是一次性任务，写完不会再用。
• 你自己还没想清楚流程，只是想让 Skill “变聪明”。
• 任务需要大量实时数据，而不是固定流程。
• 你想把所有公司知识都塞进去，结果变成一个巨大的资料堆。
• 你没有能力验证输出，却希望 Skill 自动处理高风险事项。
Skill = 触发条件 + 工作流程 + 判断标准 + 可选资源。
如果你只能写出“帮我做得更好”，那还不是 Skill；如果你能写出“遇到这类文件，先检查 A，再运行 B，再按 C 标准判断，最后输出 D 格式”，这就适合做成 Skill。
- Skill 不是模型训练，也不是普通长提示词，而是一类任务的可复用工作手册。
SKILL.md是入口，description决定它是否容易被 Claude Code 触发。- 个人 Skill 适合自己用，项目 Skill 适合团队共享，插件 Skill 适合跨项目分发。
- Skill 应该聚焦，一个 Skill 解决一个稳定问题，不要写成包罗万象的大杂烩。
- 所有示例、资料和脚本都要注意隐私，不要把密钥、真实客户资料或敏感项目内容写进 Skill。