2. 内容整体设计与思路拆解3. 删掉的依据与判断标准3.1 我的“删除清单”这三个月里我删掉的 Skill 大概分这么几类每类背后都有一轮实际的翻车记录给大家当个参考第一类一句话就能说清楚的。比如“总结网页内容”“翻译一段文字”“提取图片表格”这种需求直接在对话里说“帮我把这个网页总结成三条要点”就够了Claude Code 自己处理得很好。装了个 Skill 之后反而多了一步你要先找到触发词然后等它加载规则再开始干活。实测下来直接对话 3 秒出结果走 Skill 流程可能 10 秒还没进入正题。这类装着纯属心理安慰。第二类规则过于复杂的。有些 Skill 写了二十多条规则什么“必须分三步输出”“必须引用来源”“必须用表格对比”看着很专业实际用起来特别累。我自己写代码的时候最烦就是工具跟我绕圈子。Claude Code 本身已经很聪明你给它一个明确的目标它能自己安排步骤。Skill 规则写得太多反而把它限制死了输出的东西变得又长又僵像我以前遇到过那种写方案先把免责声明写八百字的乙方。第三类跟我的工作流根本不匹配的。我主要用 Claude Code 写代码、查资料、做技术方案。装了一堆什么“小红书文案排版”“PPT 大纲生成”“短视频脚本”之类的内容创作型 Skill当时觉得“说不定用得上”实际上三个月一次都没开过。这类属于冲动安装它们的触发词跟我的对话习惯完全对不上每次想用都想不起来这玩意儿存在过。第四类跟我用的其他工具功能重叠的。比如网页搜索增强Claude Code 自己已经能搜了而且结果还不错。装了个所谓的“深度搜索 Skill”也没见它给我多搜出什么有价值的信息反而因为要走外部 API经常超时。代码审查也是Claude Code 本身就带代码评审能力我装了个“严格代码审查”Skill结果它的输出格式跟我日常用的完全不搭后来全删了。第五类需要频繁更新的。这其实是很多 Skill 的隐藏成本。老牌的 Claude Code Agent Skill 体系一直在迭代——从最早的.claude/skills目录到现在支持更丰富的SKILL.md前端格式规则里的字段和写法经常变。我装了一堆第三方 Skill有的作者已经不维护了配置文件用的还是旧格式运行起来要么报错要么行为异常。我哪有时间天天跟着更新这些删掉一了百了。3.2 留下来的那 20%到底做了些什么删掉 80% 之后我现在真正在用的 Skill 大概有这么几个类型也比较单一项目脚手架生成帮我初始化项目结构、生成基础代码框架。数据库模型设计把需求描述转成表结构和关系设计。代码迁移和重构带着完整的迁移规则处理跨目录的代码调整。测试用例生成按既定风格补齐单元测试。有没有发现这些全部是“高确定性 高步骤数 高复用频率”的类型。它们的共同点是单靠一句对话说不清楚需要一套稳定的思考和产出框架而且这个框架对我每次干活都有用。比如“数据库模型设计”我要是不给任何约束Claude Code 每次给的表结构风格都不太一样有的喜欢冗余字段有的喜欢拆细表。但有了 Skill 之后它会按我定义的规范来输出风格统一我 review 起来轻松很多。这其实才是 Skill 存在的意义它不是用来增强 Claude Code 的“智能”而是用来把“我的偏好和流程”固定下来。智能是模型自带的偏好才是你自己的。Skill 的价值就是让你的偏好可复用而不是让模型变得更聪明——它本来就已经够聪明了。4. 实操过程与核心环节实现4.1 手写一个你自己的 Skill附完整文件下面直接放一个我实际在用的最小可用示例这个 Skill 用来生成 Git 提交信息。它足够简单也算有代表性正好拿来练手。首先建目录路径按平台稍有不同# 在项目里建 .claude/skills 目录属于项目级 Skill跟着仓库走 mkdir -p .claude/skills/commit-msg # 如果想实现全局 Skill放在用户级配置目录下 code ~/.claude/skills/commit-msg # macOS code %USERPROFILE%\.claude\skills\commit-msg # Windows然后创建主文件SKILL.md内容如下--- name: commit-msg description: 根据 git diff 生成符合 Conventional Commits 规范的提交信息。 --- # Commit Message Generator ## 用途 当用户需要生成提交信息时使用本 Skill可触发词commit message、提交信息、生成提交。 ## 执行步骤 1. 先收集当前工作区的 git diff bash git diff --staged # 优先看暂存区 git diff # 没暂存就全看 git status # 确认改了什么文件根据 diff 内容识别变更类型feat: 新功能fix: 修复问题refactor: 重构不涉及功能变化docs: 文档变更chore: 构建、依赖等维护性变更按 72 字符以内写标题行正文按“为什么改 改了什么”两段组织。就这一个文件就够了。用的时候我只需要在对话里说“生成提交信息”Claude Code 就会读 SKILL.md自己安排命令去拿 diff——注意这个 Skill 文件根本不用写死执行脚本它是给 Claude Code 看的“指令说明书”而不是传统意义上的插件代码。 ### 4.2 Skill 配置的三个雷区 写完这个文件只是第一步真正决定体验的是下面几个细节 **雷区一description 写得像废话。** 如果你把 description 写成“这是一个用于生成提交信息的工具”Claude Code 在自动判断该不该启用它的时候几乎不会主动触发。必须把“什么时候该用”“能不能被触发”写清楚像“当用户要求生成提交信息时使用”模型才判断得准。这个字段决定了你的 Skill 是“随叫随到”还是“装聋作哑”。 **雷区二把执行步骤写成让人看不懂的抽象描述。** 比如“分析变更内容并生成合适信息”这种一句顶一万句的抽象写法等于没写。什么算“合适”格式是什么约束是什么模块的标准是“驱动输出的细节要具象”越具体输出越可控。我写过好几版才意识到SKILL.md 里的每一个字都是在给你未来的输出质量做预设定。 **雷区三非要在 Skill 里塞一大堆规则。** 我见过有些模板写了几十条约束这不能写那不能说结果就是 Claude Code 的精力全花在“遵守规则”上没人干正事了。Skill 是工具不是紧箍咒。规则只要覆盖输出的核心格式和质量标准就够了剩下的事情相信模型本身的能力。 ### 4.3 用 Claude Code 调试你的 Skill 调试 Skill 有一个很直接的思路打开 --debug 模式完整观察调用链。 bash # 自带的 debug 模式会显示出 Skill 是否被加载、加载顺序、触发路径 claude --debug在对话里触发你的 Skill观察输出的日志里面能看到类似Loaded skill: commit-msg之类的信息还会标记出你写的规则的读取顺序。如果没加载大概率是路径不对或者 frontmatter 格式有问题。是的name和description必须是 frontmatter 格式YAML 的语法错误或字段名写错都会导致 Skill 失效表面上不报错实际上不生效特别坑。另外一个更简单的办法找一句废话问它。拿我们这个 commit-msg 举例你在装好 Skill 的会话里问“你觉得这个项目应该用什么提交信息规范”如果它回答里提到了 Conventional Commits约定式提交说明 Skill 已经生效了如果它开始各种发挥说明 SKILL.md 没有被加载到上下文中你需要回去检查文件名和路径。5. 常见问题与排查技巧实录5.1 为什么我的 Skill 完全没有生效这是被问得最多的一个问题我自己的排查顺序是先检查路径。是放在项目根目录的.claude/skills下面还是放在全局配置目录注意 Claude Code 的配置目录在不同平台上路径不一样而且在不同的版本里也可能是~/.claude/skills或~/.config/claude/skills这种位置所以第一步必须导航到对应版本的文档确认。路径对了基本成功一半。然后检查文件命名。必须叫SKILL.md大小写不要写错。我见过有朋友建了skill.md或者Skill.MD系统不认又找不出原因最后发现是大小写问题那个郁闷。再来检查 frontmatter。用 YAML 解析器校验一下name字段最好没有空格description里不要有特殊符号这些都是我自己踩过的坑。顺带说一句如果你在 Windows 上开发记得确认 YAML 文件保存的编码是 UTF-8编码问题也会导致解析失败。最后就是看调试日志。开 debug 模式确认是否报加载错误错误信息会直接告诉你问题在哪。5.2 为什么用了 Skill 之后反而变笨了这个问题很有意思。很多 Skill 的问题不是没生效而是“生效得太猛”把模型带偏了。我遇到过的情况某个 Skill 里写了一条规则“回答问题前必须全面分析”结果每次我让它写个简单函数它先给我输出半页分析报告再动手写代码。这背后其实是一个通用的问题——几乎所有搞 Skill 的人都会掉进这个坑。为什么因为很多规则在作者自己的场景下没问题但一旦换了上下文就会水土不服。比如“必须用中英双语输出”这种规则在作者做文档时有意义我拿它去写代码就纯粹是噪音。Clippy。解决办法就是把 Skill 当代码来维护。每次发现问题就改一行规则跑一遍试试不对再改。Skill 不是写一次就完事了它是需要持续迭代的东西。我自己的 commit-msg 规则就是改了五六轮才到现在的样子。5.3 如何判断第三方 Skill 靠不靠谱我现在判断一个第三方 Skill 值不值得装只看三个标准一看目录结构。凡是目录结构清晰、SKILL.md 开头就写清用途和适用场景的作者通常想清楚了。那种上来就是几百行配置、各种嵌套目录的果断跳过。二看规则密度。好的 Skill 规则密度适中有明确的步骤和输出格式但没有吓死人的“约束清单”。规则太多说明作者根本没想清楚优先级。三看维护频率。去项目主页看看能不能看到近期的提交记录。三个月以上没动静的建议绕过。Claude Code 迭代快Skill 规范也跟着变长期不更新的作品大概率已经失配。完结撒花。如果你也正在被一仓库的 Skill 淹没不妨试试我这次的删除清单先删掉“一句话能说清楚”的再删掉“规则比需求还长”的最后删掉“从装上古就没打开过”的。留下的那些才是真正给你打长工的活儿。