很多人用 Claude Code 一段时间后，会发现自己反复在说同样的话：先读项目规则、改完跑测试、检查风险、写交接记录、不要碰某些文件。提示词越写越长，真正的问题却没有解决：这些流程没有沉淀下来。
Claude Code Skills 的价值，就是把这些重复提示词和多步骤流程变成可复用能力。你写一个 SKILL.md，Claude Code 在合适的时候加载它，或者你直接用命令调用它。对个人项目、站长工作流和小团队协作来说，这比每次复制一大段提示词更稳定。
如果你已经看过 AI编程任务说明模板 和 AI编程上下文管理，这篇可以看作下一步：把临时说明变成长期可维护的工具。
Claude Code Skills 是什么
按照官方文档，Skill 是一个带有 SKILL.md 的目录。这个文件包含技能描述、调用规则和执行说明。Claude 可以在相关场景自动使用，也可以由你通过斜杠命令直接调用。
它和普通 CLAUDE.md 的区别在于：CLAUDE.md 更适合写长期事实和项目规则，Skill 更适合写可执行流程。比如“本项目使用 pnpm”适合放在 CLAUDE.md；“发布前按 8 个步骤检查文章质量”更适合做成 Skill。
Skills 还有一个重要好处：长参考材料不需要一开始全部塞进上下文。只有相关技能被调用时，Claude 才读取对应内容。这对复杂项目很有价值。
什么时候该创建 Skill
不是所有提示词都值得做成 Skill。我的判断标准很简单：只要同一类任务已经重复出现三次，就可以考虑沉淀。
- 代码审查流程：固定检查安全、性能、测试、回滚点和边界条件。
- 发版流程：固定执行构建、测试、变更说明和部署检查。
- 内容发布流程：固定检查标题、摘要、SEO meta、特色图、内链和正文结构。
- Bug 复现模板：固定整理环境、步骤、期望结果、实际结果和日志。
- 项目交接记录：固定输出改动范围、验证结果、风险和下一步。
这些流程如果每次都靠手写提示词，迟早会漏。做成 Skill 后，真正变化的是本次任务内容，流程本身保持稳定。
一个最小 SKILL.md 长什么样
Skill 的核心是一个 Markdown 文件，前面可以有 YAML frontmatter，用来描述技能什么时候适用。
---
description: Review the current code changes and flag risky issues before commit.
---
## Instructions
Read the current diff, summarize what changed, then check:
- missing tests
- risky file changes
- hardcoded secrets
- unclear rollback path
End with a concise recommendation: ready to commit, needs fixes, or needs human decision.
这个例子很短，但已经足够表达一个稳定流程。实际项目里，你还可以在技能目录里放模板、示例、脚本和参考文档。关键是让 SKILL.md 保持清晰，不要把所有资料都塞进去。
个人技能和项目技能怎么选
官方文档里提到，Skills 可以放在个人目录，也可以放在项目目录。怎么选，取决于它是不是跨项目复用。
- 个人技能：适合你的通用习惯，比如总结改动、写 commit message、做读书笔记、整理会议纪要。
- 项目技能：适合某个仓库独有流程，比如 WordPress 发布检查、主题构建、专题页内链规范。
- 嵌套技能：适合 monorepo 里某个子项目独有规则，比如前端包和后端包各有不同测试命令。
对个人站长来说，我更建议先做项目技能。因为网站发布、SEO 检查、图片 alt、内链规则这些东西都和具体站点强相关，放在项目里更容易长期维护。
站长可以先做哪 3 个 Skill
如果把它用在老达AI博客这种内容站，我会优先做三个技能。
第一个是文章发布检查 Skill。要求 Claude 检查正文不能有 h1、摘要 80-150 字、SEO title 和 description 完整、特色图 alt 不为空、至少有专题页和旧文内链。这类规则每天都要用，最适合技能化。
第二个是旧文更新 Skill。要求先判断搜索意图，再检查旧文是否过时，最后补充新信息、内链和 FAQ，而不是粗暴改标题。这样可以减少自相竞争。
第三个是代码维护 Skill。要求先读项目规则，再定位文件，改完跑检查，并输出风险说明。它可以和 AI编程测试自动化、WordPress发布后检查自动化 配合使用。
Skills 和斜杠命令有什么关系
Claude Code 新文档里一个重要变化是：自定义命令已经并入 Skills。以前你可能会在 .claude/commands/ 里放一个命令文件，现在更推荐用 .claude/skills/ 组织。
这样做的好处是 Skill 不只是一个命令文本，还可以拥有自己的目录、支持文件、示例和脚本。比如一个发布检查 Skill 可以包含：
SKILL.md：说明什么时候用、怎么检查；template.md：发布后报告模板；scripts/check_post.js：实际检查页面的脚本；examples/：合格和不合格报告示例。
这比单个命令文件更适合长期维护，也更符合真实项目的复杂度。
不要把 Skill 写成万能助手
Skill 最常见的坑，是写得太大。比如一个“网站运营 Skill”同时要求选题、写作、配图、发布、查数据、改主题、发邮件。这样的技能看起来全面，实际很难稳定执行。
更好的做法是拆小：选题是一个技能，发布检查是一个技能，旧文更新是一个技能，主题代码审查是另一个技能。每个 Skill 只负责一个清晰流程，Claude 才容易判断什么时候该用。
这和 AI智能体与自动化专题 里反复讲的原则一致：自动化不是把所有动作塞进一个入口，而是把可控的小工具组合起来。
安全和维护建议
第一，Skill 里不要写真实密钥、服务器密码、API token。需要凭据时，只写“从环境变量读取”，不要把值写进 Markdown。
第二，Skill 变更要像代码一样管理。尤其是项目技能，最好放进版本管理，方便回看规则为什么变化。
第三，技能描述要具体。描述写得越清楚，Claude 越容易在正确场景自动调用。不要只写“帮助我工作”，要写“当用户要求发布 WordPress 文章并做 SEO 检查时使用”。
第四，复杂技能要配示例。Claude 看到合格输出样例，比只看抽象要求更容易稳定复现格式。
更多 Claude Code 相关实践，可以继续看 Claude专题 和 AI编程工具专题。
老达点评
Claude Code Skills 的本质，不是多了一个新功能，而是把个人经验从聊天窗口里拿出来，变成项目资产。你反复提醒 AI 的那些话，如果长期有用，就不应该只停留在一次对话里。
我建议从最痛的重复流程开始做 Skill：每天都要做、经常漏项、出错后代价高。对站长来说，发布检查和旧文更新最值得先做；对开发者来说，代码审查、测试验证和交接记录最值得先做。
参考资料：Claude Code Skills 官方文档。
