最近在GitHub上翻到一个很有意思的项目awesome-claude-skills一个专门收集Claude技能资源的长清单。我花了一个周末把里面列出的仓库挨个看了一遍也在Claude Code里实际装了七八个Skill跑了跑整个过程踩的坑不少但收获更大。这篇文章就当作我的折腾记录把claude-skills这个很多人听说过但没系统玩过的概念彻底讲清楚它到底是什么、和插件有什么区别、怎么选择怎么安装以及如何从零手写一个自己的Skill。如果你正在研究怎么让Claude在真实工作流里发挥更大作用这篇应该能帮上忙。1. 先搞清楚Claude Skills是什么一个按需加载的“技能包”而不是插件1.1 从一份SKILL.md说起我最初看Awesome清单里那些项目时也是一头雾水直到我打开其中一个仓库发现核心就是一个特殊格式的Markdown文件。这个文件的命名有讲究官方要求叫SKILL.md它和普通的说明文档完全不同头部有一段YAML格式的元信息包含技能名称和一个极其关键的description字段。--- name: weekly-report description: 根据git提交历史生成结构化周报。当用户说“生成周报”“这周干了什么”时使用。 --- # Weekly Report 当用户请求生成周报时按下面步骤执行 1. 运行 python3 scripts/generate_report.py 2. 如果脚本执行失败回退用 git log --since7 days ago --prettyformat:%h|%an|%s --no-merges 获取提交记录 3. 将提交信息分为功能开发、Bug修复、文档维护三类按表格输出就这么一个文件加上同目录下若干脚本和参考文件就构成了一个完整的Skill。它本质上不是给Claude装了一个“新大脑”而是给Claude提供了一组高度结构化的指令和工具脚本让它遇到相关任务时能立刻进入一套标准作业流程。1.2 Skills和传统插件的本质区别渐进式披露很多人第一次接触Claude Skills都会先入为主觉得它就是插件。我当时也这么想直到把官方设计思路翻了一遍才意识到这俩在机制上是两码事。传统插件比如老式浏览器扩展、IDE插件的加载方式是启动时就把所有功能注册进系统全部可用。而Claude Skills走的是“渐进式披露”路线——每一个Skill在初始状态下只暴露它的name和description给Claude完整指令和脚本全部藏在文件夹里。只有当模型判断当前任务跟某个description匹配时才会去读取完整的SKILL.md和脚本内容。我打一个比方插件像你办公桌上摊开的二十本手册随时都能翻占满了桌面Skill像一排文件夹只露着标签贴在墙边你要做财务工作才抽出财务手册要做设计才抽出设计手册。桌面上下文窗口始终干净。1.3 为什么要这么设计上下文就是真金白银理解渐进式披露一定要回到上下文窗口这个现实约束。Claude的上下文窗口虽然已经很大但每多塞一万个token就多一分注意力稀释响应速度也会变慢成本更是肉眼可见地涨。处理复杂任务时浪费在无关工具说明上的token越少留给真正推理的token就越多。如果像传统插件那样把所有Skill的完整指令一次性灌进上下文二十个Skill光说明书就能吃掉几万字Claude的中枢工作内存几乎被榨干。渐进式披露保证了每个Skill平时只作为“一行描述”存在用到了才展开。这是Claude Skills最聪明的设计也是我觉得它必然成为未来AI扩展主流形态的原因。提示判断一个Skill文件写得是否专业先看它的description写得好不好。真正合格的做法是写什么时候触发解决什么问题而不是“帮助用户提高效率”这种毫无信息量的话。2. 从awesome-claude-skills清单里我筛出了这五类最值得收藏的Skill2.1 一堆Skill扑面而来时怎么挑awesome-claude-skills这类聚合清单有个通病什么都收质量参差。我刷完列表的第一反应是“选择困难”。后来定了一套筛选流程先看目录分类再看SKILL.md的description写得是否克制最后看脚本的编程语言和依赖是否轻量。我的筛选标准就三条一是Skill解决的问题我每周都会遇到二是它的description能在三十个字内让我看懂触发场景三是脚本尽量用Python或Shell别一上来就要求装一堆重型依赖。按这三条标准过滤我留下了大概五类。2.2 五类实际体验下来最有感的Skill第一类浏览器与网页自动化。这类Skill能让Claude通过脚本驱动浏览器做信息抓取、表单填写、页面截图比对。实测下来比让我手动给Claude贴链接再让它分析要顺滑得多适用于做竞品信息收集、网页内容归档这类重复操作。第二类办公文档处理。包括PDF转Markdown、Word文档批量格式化、Excel表格清洗。社区里的实现思路大多是用Python库解析文件把提取到的内容交给Claude做结构化和润色。我拿“从PDF里提取合同关键字段”这个场景跑过输出准确率比我预想的高。第三类数据处理与可视化。这类Skill通常提供一套固定的数据探查流水线比如读CSV、跑基础统计、自动生成图表。它的价值在于把“Claude随手写一段分析代码”变成“固定可靠的代码模板”输出风格更统一。第四类开发流程辅助。这是我认为最有潜力的方向。比如代码审查Skill它会自动分析git diff、检查常见安全隐患、生成审查意见清单提交信息生成Skill根据改动内容产出Angular规范的Commit Message。这类Skill把Claude Code从“你问我答”变成了“自动化流水线里的一个执行节点”。第五类内容与创意工作流。包括长文改写、翻译校对、SEO标题生成。实用性不复杂但胜在把提示词工程沉淀成了可复用的配置文件一个人写完团队都能直接调用。2.3 怎么快速判断一个Skill是不是“金玉其外”我在清单里点开过不少漂亮的仓库SKILL.md写得花团锦簇结果跑起来寸步难行。我的经验是看两个地方第一看SKILL.md里是否写了fallback降级方案指令。如果脚本失败了怎么办好的Skill一定会交代清楚而不是假设脚本永远能跑通。第二看脚本依赖声明。只依赖Python标准库或者两三个常见库的出问题的概率远低于动不动就引入Pandas全家桶的。3. 实战接入Claude Code和Claude App里启用Skills的正确姿势3.1 在Claude Code里装Skill搞清楚两个层级Claude Code是开发者接触Skills最主力的阵地安装方式分两种场景用户级和项目级。用户级Skill放在~/.claude/skills/目录下对所有项目生效。适合放你个人沉淀下来的通用技能比如信息整理、文档格式化、邮件撰写。项目级Skill放在当前工程目录下的.claude/skills/里只在当前项目生效。适合放和项目强相关的技能比如“读取本项目数据库表结构生成ORM映射”这种换项目就没意义的技能。# 用户级 mkdir -p ~/.claude/skills/pdf-extract cp -r my-skill/* ~/.claude/skills/pdf-extract/ # 项目级 mkdir -p .claude/skills/code-review cp -r my-code-review-skill/* .claude/skills/code-review/安装完不需要重启Claude Code在会话里输入/skills就能看到当前可用的技能列表。我在实际操作中有一个体会如果Skill没有被识别九成问题出在文件名上。Claude Code要求技能文件夹的目录名和SKILL.md里frontmatter的name保持完全一致大小写、中划线都不能差。我之前一个技能目录叫PDF_to_MDfrontmatter里写的是pdf-to-md调了半天愣是不加载改成一致后立刻就好了。3.2 Claude App里的Skills普通用户也能玩的轻量入口移动端和桌面的Claude App里也内置了Skills功能入口藏在设置模块中可以创建新技能。创建界面比Claude Code友好得多不需要写脚本只需要填名称、描述和指令正文。这就非常像一个“自定义指令模板”适合非程序员使用。比如我媳妇就在Claude App里给自己写了一个“小古文风格游记”技能让她写旅行记录时统一用轻文言文风格输出。不过我提醒一句App里的Skills功能相对初级本质上就是把一段高质量提示词包装成了固定技能没有脚本执行能力。如果你想做真正调用外部工具的Skill还是得回到Claude Code或API层面。这也解释了为什么awesome-claude-skills清单里的项目绝大多数都是面向开发者场景的——脚本执行才是Skills的灵魂。3.3 权限边界Skill不是免死金牌装第三方Skill时要特别警惕因为Skill自带的脚本会在你的机器上以你的用户权限执行命令。社区里绝大多是善意的但不代表没有风险。我的原则是二手Skill先通读SKILL.md和全部脚本再运行脚本里出现rm -rf、curl管道执行、关闭系统安全机制这类高危操作的直接PASS从可信作者或高star仓库里选陌生仓库先放到隔离目录跑一次看看行为。注意我见过一个号称“一键优化系统”的Skill脚本里悄悄混了一段把环境变量导出到外部服务器的代码。装第三方Skill前养成先读代码的习惯跟吃饭前先洗手一样麻烦一次安全一百次。4. 从零手写一个Skill周报生成技能从SKILL.md到落地验证4.1 场景选择为什么选周报概念理解得再多不亲手写一个都是纸上谈兵。我建议你第一个Skill从周报生成开始练手因为它足够简单又足够典型有明确输入git提交记录有明确输出结构化Markdown而且几乎所有开发者都痛恨手工写周报。这个例子的完整代码不值得粘贴我更想拆解整个设计决策过程这些思路才能复用到复杂技能上。4.2 目录结构与SKILL.md写作要点一个最小可用的Skill目录长这样weekly-report/ ├── SKILL.md └── scripts/ └── generate_report.pySKILL.md的frontmatter里最关键的是description字段。我前面强调过description是“广告位”决定了Claude什么时候会想起这个技能。我在第一版里写的是“根据git历史生成周报”结果有个明显问题触发条件不够具体。改成“当用户请求生成周报、周总结、或询问本周开发内容时使用该技能从git提交历史中统计并组织报告”之后触发准确率直线上升。正文部分有个很容易被忽略的细节要给Claude留决策余地。不要把所有步骤写得死死板板而要让它在不同情况下有路可走。比如我的SKILL.md正文里写了先尝试用脚本如果脚本因为环境原因失败就退回到git原始命令手工整理。这个fallback设计让整个Skill在碰到新环境时不至于直接废掉。4.3 脚本设计的“少即是多”原则写Skill配套脚本时我强烈建议遵循“脚本只做机械工作智能判断全交给Claude”的原则。generate_report.py不要试图自动判断某个提交是功能还是修复那是Claude的活脚本只需要把原始提交信息干净地拉出来按时间排好序输出成易读的文本源料。#!/usr/bin/env python3 import subprocess import sys from datetime import datetime, timedelta days int(sys.argv[1]) if len(sys.argv) 1 else 7 since (datetime.now() - timedelta(daysdays)).strftime(%Y-%m-%d) result subprocess.run( [git, log, f--since{since}, --prettyformat:%ad|%an|%s, --dateshort, --no-merges], capture_outputTrue, textTrue ) if result.returncode ! 0 or not result.stdout.strip(): print(NO_COMMITS_FOUND) else: print(result.stdout)脚本输出一行一个提交用竖线分隔日期、作者、标题。结构简单、解析方便Claude拿到的是一份干净的数据剩下的分类判断交给大模型处理。很多新手犯的错是把分类逻辑硬编码进Python用一堆正则去猜“这个提交是feature还是fix”结果猜错的概率比Claude自己判断高出一大截。4.4 测试与迭代没有一次写对的SkillSkill写完要测试测试方法直接反映你对该Skill的信心。我的测试步骤是先进会话输入/skills确认被加载再直接说“帮我生成这周的周报”看Claude是否自动调用了这个技能。如果它答非所问或开始写一堆客套话说明description触发词没写好。第一版跑出来的输出让我有点失望脚本返回了提交记录但Claude生成的分类有些生硬。我把周报模板从SKILL.md里拆出来单独放了一份示例文件指令里写明“参考examples/weekly-report-sample.md严格按照此结构输出”格式瞬间稳定。这就是迭代的价值Skill不是代码写完就结束它是提示词工程和代码工程的结合体必须反复调。4.5 进阶方向从单文件到多脚本协作当你掌握基础写法后可以尝试更复杂的技能编排。社区里有些优秀Skill已经用上了目录分区skills/下放可复用脚本assets/放参考文档instruction/放覆盖不同场景的指令片段。这种结构能让一个Skill面对复杂任务时分步决策先读取主指令再根据任务细节加载对应子指令。它的代价是复杂度上升如果只是做周报这种小任务完全没必要搞这么重。5. 用Skill踩过的坑和几条判断准则5.1 装了很多Skill之后我遇到的典型问题用了一段时间之后我最想吐槽的是上下文膨胀问题。很多人以为渐进式披露就万事大吉其实description也会占上下文每多一个Skill就多几十个token。我装了十几个Skill后明显感觉基础对话的token消耗涨了。解决方法是定期清理三个月没触发过一次的Skill直接删掉同类功能只留一个最好的。第二个坑是Skill之间的“触发打架”。我装了一个“长文润色”Skill又装了一个“学术论文改写”Skill结果发一段学术摘要的时候两个争先恐后想接管输出风格互相冲突。后来我把学术论Skill并入长文润色作为子指令才根治。所以装Skill之前先看一眼自己库里有没有重叠能力与其装一堆互为替代品的不如集中力量维护一个全能选手。第三个坑是环境漂移。一个Skill上个月还跑得好好的这个月因为系统Python版本升级突然报错。我的应对是把Skill脚本里的核心依赖都固定版本在SKILL.md里写明最低环境要求省得每次升级都要排查一轮。5.2 “什么时候不该用Skill”越用Skill越要明白的边界我在清单翻了一段时间后得出一个反直觉的结论很多任务根本不该做成Skill。任务是一次性、没有固定流程、没有重复价值的做成Skill纯属浪费维护精力。Skill适合的是“固定流程重复执行可沉淀经验”的场景比如周报、发版说明、代码审查。那些每次都需要大量上下文来回沟通的探索型任务老老实实开普通对话就好。另一个不该用Skill的场景是你还没摸清稳定工作流之前。我见过有人把一段效果都还没验证过的提示词封装成Skill结果团队一起跟着踩坑。正确顺序是先在普通对话里和Claude磨合出一套可靠的流程确认步骤稳定、输出达标再固化成Skill。5.3 几条实操心得写在最后第一一个优质Skill的description应该像一条精准的搜索索引宁可长一点把边界说清楚也不要短到让Claude胡乱触发。第二Skill内部推荐尽量使用标准库或常见库降低未来环境漂移的风险。第三更新Skill时要保留上一版很多调整是倒退的有回滚能力会让你大胆尝试。第四团队内部用Skill时建议做Code ReviewSkill也是代码也需要review流程。我的习惯是每次Skill大版本变更后在群里发一段变更说明让团队的每个人都清楚技能行为发生了什么变化。Skill这个功能出来已经有一段时间了awesome-claude-skills这类清单还在快速增长但生态依然处在早期。我判断未来一段时间会出现大量垂直领域的优质技能沉淀特别是那些能把工具调用、代码执行和领域知识结合得很好的技能。你现在花时间把基础概念和实践路径搞通等于提前占领了这片蓝海。回头看看我装的那一堆Skill真正每天在用的不超过三个但就是这三个让我每周至少省出半天时间。这大概就是Skills最朴素的价值。 
长河君 · 2026/10/31 14:06:59 · 阅读 1.2k Claude Skills入门：从SKILL.md到渐进式披露，手把手教你写自己的AI技能包
最近在GitHub上翻到一个很有意思的项目awesome-claude-skills一个专门收集Claude技能资源的长清单。我花了一个周末把里面列出的仓库挨个看了一遍也在Claude Code里实际装了七八个Skill跑了跑整个过程踩的坑不少但收获更大。这篇文章就当作我的折腾记录把claude-skills这个很多人听说过但没系统玩过的概念彻底讲清楚它到底是什么、和插件有什么区别、怎么选择怎么安装以及如何从零手写一个自己的Skill。如果你正在研究怎么让Claude在真实工作流里发挥更大作用这篇应该能帮上忙。1. 先搞清楚Claude Skills是什么一个按需加载的“技能包”而不是插件1.1 从一份SKILL.md说起我最初看Awesome清单里那些项目时也是一头雾水直到我打开其中一个仓库发现核心就是一个特殊格式的Markdown文件。这个文件的命名有讲究官方要求叫SKILL.md它和普通的说明文档完全不同头部有一段YAML格式的元信息包含技能名称和一个极其关键的description字段。--- name: weekly-report description: 根据git提交历史生成结构化周报。当用户说“生成周报”“这周干了什么”时使用。 --- # Weekly Report 当用户请求生成周报时按下面步骤执行 1. 运行 python3 scripts/generate_report.py 2. 如果脚本执行失败回退用 git log --since7 days ago --prettyformat:%h|%an|%s --no-merges 获取提交记录 3. 将提交信息分为功能开发、Bug修复、文档维护三类按表格输出就这么一个文件加上同目录下若干脚本和参考文件就构成了一个完整的Skill。它本质上不是给Claude装了一个“新大脑”而是给Claude提供了一组高度结构化的指令和工具脚本让它遇到相关任务时能立刻进入一套标准作业流程。1.2 Skills和传统插件的本质区别渐进式披露很多人第一次接触Claude Skills都会先入为主觉得它就是插件。我当时也这么想直到把官方设计思路翻了一遍才意识到这俩在机制上是两码事。传统插件比如老式浏览器扩展、IDE插件的加载方式是启动时就把所有功能注册进系统全部可用。而Claude Skills走的是“渐进式披露”路线——每一个Skill在初始状态下只暴露它的name和description给Claude完整指令和脚本全部藏在文件夹里。只有当模型判断当前任务跟某个description匹配时才会去读取完整的SKILL.md和脚本内容。我打一个比方插件像你办公桌上摊开的二十本手册随时都能翻占满了桌面Skill像一排文件夹只露着标签贴在墙边你要做财务工作才抽出财务手册要做设计才抽出设计手册。桌面上下文窗口始终干净。1.3 为什么要这么设计上下文就是真金白银理解渐进式披露一定要回到上下文窗口这个现实约束。Claude的上下文窗口虽然已经很大但每多塞一万个token就多一分注意力稀释响应速度也会变慢成本更是肉眼可见地涨。处理复杂任务时浪费在无关工具说明上的token越少留给真正推理的token就越多。如果像传统插件那样把所有Skill的完整指令一次性灌进上下文二十个Skill光说明书就能吃掉几万字Claude的中枢工作内存几乎被榨干。渐进式披露保证了每个Skill平时只作为“一行描述”存在用到了才展开。这是Claude Skills最聪明的设计也是我觉得它必然成为未来AI扩展主流形态的原因。提示判断一个Skill文件写得是否专业先看它的description写得好不好。真正合格的做法是写什么时候触发解决什么问题而不是“帮助用户提高效率”这种毫无信息量的话。2. 从awesome-claude-skills清单里我筛出了这五类最值得收藏的Skill2.1 一堆Skill扑面而来时怎么挑awesome-claude-skills这类聚合清单有个通病什么都收质量参差。我刷完列表的第一反应是“选择困难”。后来定了一套筛选流程先看目录分类再看SKILL.md的description写得是否克制最后看脚本的编程语言和依赖是否轻量。我的筛选标准就三条一是Skill解决的问题我每周都会遇到二是它的description能在三十个字内让我看懂触发场景三是脚本尽量用Python或Shell别一上来就要求装一堆重型依赖。按这三条标准过滤我留下了大概五类。2.2 五类实际体验下来最有感的Skill第一类浏览器与网页自动化。这类Skill能让Claude通过脚本驱动浏览器做信息抓取、表单填写、页面截图比对。实测下来比让我手动给Claude贴链接再让它分析要顺滑得多适用于做竞品信息收集、网页内容归档这类重复操作。第二类办公文档处理。包括PDF转Markdown、Word文档批量格式化、Excel表格清洗。社区里的实现思路大多是用Python库解析文件把提取到的内容交给Claude做结构化和润色。我拿“从PDF里提取合同关键字段”这个场景跑过输出准确率比我预想的高。第三类数据处理与可视化。这类Skill通常提供一套固定的数据探查流水线比如读CSV、跑基础统计、自动生成图表。它的价值在于把“Claude随手写一段分析代码”变成“固定可靠的代码模板”输出风格更统一。第四类开发流程辅助。这是我认为最有潜力的方向。比如代码审查Skill它会自动分析git diff、检查常见安全隐患、生成审查意见清单提交信息生成Skill根据改动内容产出Angular规范的Commit Message。这类Skill把Claude Code从“你问我答”变成了“自动化流水线里的一个执行节点”。第五类内容与创意工作流。包括长文改写、翻译校对、SEO标题生成。实用性不复杂但胜在把提示词工程沉淀成了可复用的配置文件一个人写完团队都能直接调用。2.3 怎么快速判断一个Skill是不是“金玉其外”我在清单里点开过不少漂亮的仓库SKILL.md写得花团锦簇结果跑起来寸步难行。我的经验是看两个地方第一看SKILL.md里是否写了fallback降级方案指令。如果脚本失败了怎么办好的Skill一定会交代清楚而不是假设脚本永远能跑通。第二看脚本依赖声明。只依赖Python标准库或者两三个常见库的出问题的概率远低于动不动就引入Pandas全家桶的。3. 实战接入Claude Code和Claude App里启用Skills的正确姿势3.1 在Claude Code里装Skill搞清楚两个层级Claude Code是开发者接触Skills最主力的阵地安装方式分两种场景用户级和项目级。用户级Skill放在~/.claude/skills/目录下对所有项目生效。适合放你个人沉淀下来的通用技能比如信息整理、文档格式化、邮件撰写。项目级Skill放在当前工程目录下的.claude/skills/里只在当前项目生效。适合放和项目强相关的技能比如“读取本项目数据库表结构生成ORM映射”这种换项目就没意义的技能。# 用户级 mkdir -p ~/.claude/skills/pdf-extract cp -r my-skill/* ~/.claude/skills/pdf-extract/ # 项目级 mkdir -p .claude/skills/code-review cp -r my-code-review-skill/* .claude/skills/code-review/安装完不需要重启Claude Code在会话里输入/skills就能看到当前可用的技能列表。我在实际操作中有一个体会如果Skill没有被识别九成问题出在文件名上。Claude Code要求技能文件夹的目录名和SKILL.md里frontmatter的name保持完全一致大小写、中划线都不能差。我之前一个技能目录叫PDF_to_MDfrontmatter里写的是pdf-to-md调了半天愣是不加载改成一致后立刻就好了。3.2 Claude App里的Skills普通用户也能玩的轻量入口移动端和桌面的Claude App里也内置了Skills功能入口藏在设置模块中可以创建新技能。创建界面比Claude Code友好得多不需要写脚本只需要填名称、描述和指令正文。这就非常像一个“自定义指令模板”适合非程序员使用。比如我媳妇就在Claude App里给自己写了一个“小古文风格游记”技能让她写旅行记录时统一用轻文言文风格输出。不过我提醒一句App里的Skills功能相对初级本质上就是把一段高质量提示词包装成了固定技能没有脚本执行能力。如果你想做真正调用外部工具的Skill还是得回到Claude Code或API层面。这也解释了为什么awesome-claude-skills清单里的项目绝大多数都是面向开发者场景的——脚本执行才是Skills的灵魂。3.3 权限边界Skill不是免死金牌装第三方Skill时要特别警惕因为Skill自带的脚本会在你的机器上以你的用户权限执行命令。社区里绝大多是善意的但不代表没有风险。我的原则是二手Skill先通读SKILL.md和全部脚本再运行脚本里出现rm -rf、curl管道执行、关闭系统安全机制这类高危操作的直接PASS从可信作者或高star仓库里选陌生仓库先放到隔离目录跑一次看看行为。注意我见过一个号称“一键优化系统”的Skill脚本里悄悄混了一段把环境变量导出到外部服务器的代码。装第三方Skill前养成先读代码的习惯跟吃饭前先洗手一样麻烦一次安全一百次。4. 从零手写一个Skill周报生成技能从SKILL.md到落地验证4.1 场景选择为什么选周报概念理解得再多不亲手写一个都是纸上谈兵。我建议你第一个Skill从周报生成开始练手因为它足够简单又足够典型有明确输入git提交记录有明确输出结构化Markdown而且几乎所有开发者都痛恨手工写周报。这个例子的完整代码不值得粘贴我更想拆解整个设计决策过程这些思路才能复用到复杂技能上。4.2 目录结构与SKILL.md写作要点一个最小可用的Skill目录长这样weekly-report/ ├── SKILL.md └── scripts/ └── generate_report.pySKILL.md的frontmatter里最关键的是description字段。我前面强调过description是“广告位”决定了Claude什么时候会想起这个技能。我在第一版里写的是“根据git历史生成周报”结果有个明显问题触发条件不够具体。改成“当用户请求生成周报、周总结、或询问本周开发内容时使用该技能从git提交历史中统计并组织报告”之后触发准确率直线上升。正文部分有个很容易被忽略的细节要给Claude留决策余地。不要把所有步骤写得死死板板而要让它在不同情况下有路可走。比如我的SKILL.md正文里写了先尝试用脚本如果脚本因为环境原因失败就退回到git原始命令手工整理。这个fallback设计让整个Skill在碰到新环境时不至于直接废掉。4.3 脚本设计的“少即是多”原则写Skill配套脚本时我强烈建议遵循“脚本只做机械工作智能判断全交给Claude”的原则。generate_report.py不要试图自动判断某个提交是功能还是修复那是Claude的活脚本只需要把原始提交信息干净地拉出来按时间排好序输出成易读的文本源料。#!/usr/bin/env python3 import subprocess import sys from datetime import datetime, timedelta days int(sys.argv[1]) if len(sys.argv) 1 else 7 since (datetime.now() - timedelta(daysdays)).strftime(%Y-%m-%d) result subprocess.run( [git, log, f--since{since}, --prettyformat:%ad|%an|%s, --dateshort, --no-merges], capture_outputTrue, textTrue ) if result.returncode ! 0 or not result.stdout.strip(): print(NO_COMMITS_FOUND) else: print(result.stdout)脚本输出一行一个提交用竖线分隔日期、作者、标题。结构简单、解析方便Claude拿到的是一份干净的数据剩下的分类判断交给大模型处理。很多新手犯的错是把分类逻辑硬编码进Python用一堆正则去猜“这个提交是feature还是fix”结果猜错的概率比Claude自己判断高出一大截。4.4 测试与迭代没有一次写对的SkillSkill写完要测试测试方法直接反映你对该Skill的信心。我的测试步骤是先进会话输入/skills确认被加载再直接说“帮我生成这周的周报”看Claude是否自动调用了这个技能。如果它答非所问或开始写一堆客套话说明description触发词没写好。第一版跑出来的输出让我有点失望脚本返回了提交记录但Claude生成的分类有些生硬。我把周报模板从SKILL.md里拆出来单独放了一份示例文件指令里写明“参考examples/weekly-report-sample.md严格按照此结构输出”格式瞬间稳定。这就是迭代的价值Skill不是代码写完就结束它是提示词工程和代码工程的结合体必须反复调。4.5 进阶方向从单文件到多脚本协作当你掌握基础写法后可以尝试更复杂的技能编排。社区里有些优秀Skill已经用上了目录分区skills/下放可复用脚本assets/放参考文档instruction/放覆盖不同场景的指令片段。这种结构能让一个Skill面对复杂任务时分步决策先读取主指令再根据任务细节加载对应子指令。它的代价是复杂度上升如果只是做周报这种小任务完全没必要搞这么重。5. 用Skill踩过的坑和几条判断准则5.1 装了很多Skill之后我遇到的典型问题用了一段时间之后我最想吐槽的是上下文膨胀问题。很多人以为渐进式披露就万事大吉其实description也会占上下文每多一个Skill就多几十个token。我装了十几个Skill后明显感觉基础对话的token消耗涨了。解决方法是定期清理三个月没触发过一次的Skill直接删掉同类功能只留一个最好的。第二个坑是Skill之间的“触发打架”。我装了一个“长文润色”Skill又装了一个“学术论文改写”Skill结果发一段学术摘要的时候两个争先恐后想接管输出风格互相冲突。后来我把学术论Skill并入长文润色作为子指令才根治。所以装Skill之前先看一眼自己库里有没有重叠能力与其装一堆互为替代品的不如集中力量维护一个全能选手。第三个坑是环境漂移。一个Skill上个月还跑得好好的这个月因为系统Python版本升级突然报错。我的应对是把Skill脚本里的核心依赖都固定版本在SKILL.md里写明最低环境要求省得每次升级都要排查一轮。5.2 “什么时候不该用Skill”越用Skill越要明白的边界我在清单翻了一段时间后得出一个反直觉的结论很多任务根本不该做成Skill。任务是一次性、没有固定流程、没有重复价值的做成Skill纯属浪费维护精力。Skill适合的是“固定流程重复执行可沉淀经验”的场景比如周报、发版说明、代码审查。那些每次都需要大量上下文来回沟通的探索型任务老老实实开普通对话就好。另一个不该用Skill的场景是你还没摸清稳定工作流之前。我见过有人把一段效果都还没验证过的提示词封装成Skill结果团队一起跟着踩坑。正确顺序是先在普通对话里和Claude磨合出一套可靠的流程确认步骤稳定、输出达标再固化成Skill。5.3 几条实操心得写在最后第一一个优质Skill的description应该像一条精准的搜索索引宁可长一点把边界说清楚也不要短到让Claude胡乱触发。第二Skill内部推荐尽量使用标准库或常见库降低未来环境漂移的风险。第三更新Skill时要保留上一版很多调整是倒退的有回滚能力会让你大胆尝试。第四团队内部用Skill时建议做Code ReviewSkill也是代码也需要review流程。我的习惯是每次Skill大版本变更后在群里发一段变更说明让团队的每个人都清楚技能行为发生了什么变化。Skill这个功能出来已经有一段时间了awesome-claude-skills这类清单还在快速增长但生态依然处在早期。我判断未来一段时间会出现大量垂直领域的优质技能沉淀特别是那些能把工具调用、代码执行和领域知识结合得很好的技能。你现在花时间把基础概念和实践路径搞通等于提前占领了这片蓝海。回头看看我装的那一堆Skill真正每天在用的不超过三个但就是这三个让我每周至少省出半天时间。这大概就是Skills最朴素的价值。