1. 从“skills”这个热词说起它到底是什么为什么突然火了最近几个月不管是在技术社区还是各种开发者群聊里“skills”这个词出现的频率高得离谱。很多人第一次看到它的时候会以为是某种新出的编程语言或者框架其实不是。这里的 skills指的是围绕 Claude 生态尤其是 Claude Code 和 Claude Desktop构建的一套可复用的能力模块。你可以把它理解成给 AI 助手装的“插件包”或者“技能卡”——每一张技能卡都定义了一类特定任务的执行方式、上下文规则和输出格式。我最早接触这个概念是在折腾 Claude Code 的时候。当时我想让它帮我处理一些重复性的代码审查工作每次都要把同样的规则、同样的格式要求重新粘贴一遍非常烦。后来发现社区里已经有人把这类需求封装成了 SKILL.md 文件放到项目目录里Claude Code 启动时会自动加载之后所有对话都默认遵循这些规则。这就是 skills 最朴素也最核心的用法。那为什么现在突然火起来了我的判断是三个因素叠加。第一Claude Code 这个命令行工具本身在开发者群体里口碑起来了大家愿意花时间研究它的扩展能力。第二SKILL.md 这种纯文本定义方式门槛极低不需要写代码不需要编译会写 Markdown 就能做。第三社区里涌现了一批高质量的 skills 仓库比如 superpower skills、typesafe ai skills 这些直接拉下来就能用效果立竿见影。这篇文章我想做的事情很明确把 skills 从概念到实操到避坑完整地讲一遍。不管你是刚听说这个词的新手还是已经用过几个 skills 但想自己动手写的进阶用户都能从里面找到能直接抄作业的内容。我会重点讲 SKILL.md 的结构设计、Claude Code 里怎么加载和管理 skills、常见问题的排查思路以及我自己在写 skills 过程中踩过的坑。2. Skills 的核心机制与 SKILL.md 文件结构拆解2.1 Skills 在 Claude 生态里扮演什么角色要理解 skills先得理解 Claude Code 的工作方式。Claude Code 本质上是一个跑在终端里的 AI 编程助手它能读你项目里的文件、执行命令、修改代码。但它默认的行为是“通用”的——你问什么它答什么没有特定的领域偏好。Skills 的作用就是给这个通用助手注入“领域知识”和“行为约束”。举个例子你是一个前端团队代码规范要求所有组件必须用函数式写法、必须写 PropTypes、必须遵循特定的目录结构。这些规则如果每次对话都手动输入效率极低。但如果你在项目根目录放一个.claude/skills/文件夹里面写好对应的 SKILL.mdClaude Code 每次启动就会自动读取之后它生成的所有代码都会遵循这些规则。从技术实现角度看skills 就是一组 Markdown 文件的集合每个文件描述一个技能。Claude Code 在启动时会扫描指定目录把这些文件内容加载进上下文。当你的对话内容匹配到某个技能的定义范围时它就会按照那个技能里写的规则来执行。这里有一个关键点很多人会忽略skills 不是函数调用而是上下文注入。它不会像传统插件那样“执行”某个操作而是通过改变 AI 的上下文来影响它的行为。这意味着 skills 的效果取决于你写的内容质量写得越具体、越结构化效果越好。2.2 SKILL.md 的标准结构长什么样一个规范的 SKILL.md 文件通常包含以下几个部分。我拿一个实际在用的代码审查 skill 来举例说明。文件开头是元信息区域用 YAML frontmatter 的格式写--- name: code-review description: 对指定文件或目录进行代码审查输出结构化报告 version: 1.0.0 tags: [review, quality, frontend] ---这部分的作用是让 Claude Code 知道这个技能叫什么、干什么用的、什么时候该触发。description写得越准确触发时机就越精准。我见过有人把 description 写成“一个很有用的技能”结果 Claude 根本不知道什么时候该用它。接下来是技能的主体内容通常分为几个区块。第一个区块是“角色定义”告诉 Claude 在这个技能激活时应该扮演什么角色## 角色 你是一名资深前端代码审查员有 8 年以上 React 项目经验。 你的审查风格是严格但建设性每个问题都要给出具体的修改建议。第二个区块是“执行规则”这是最核心的部分列出具体的检查项和输出要求## 审查规则 1. 检查所有组件的命名是否符合 PascalCase 规范 2. 检查是否使用了 any 类型如有则标记为高优先级问题 3. 检查 useEffect 的依赖数组是否完整 4. 检查是否有未处理的 Promise rejection 5. 每个问题必须标注文件路径、行号、问题等级、修改建议第三个区块是“输出格式”定义最终报告的结构## 输出格式 按以下结构输出审查报告 ### 问题汇总 | 等级 | 数量 | |------|------| | 高 | X | | 中 | X | | 低 | X | ### 详细问题列表 每个问题按以下格式 - **文件**: path/to/file.tsx:42 - **等级**: 高 - **问题**: 具体描述 - **建议**: 具体修改方案这三个区块构成了一个完整 skill 的骨架。当然实际使用中还可以加入“示例”、“边界情况处理”、“禁止事项”等区块但核心就是这三块。2.3 为什么选择 Markdown 而不是代码来定义技能这个问题我被问过很多次。用 Markdown 定义技能看起来“不够工程化”为什么不用 JSON 或者 YAML 来写配置我的理解是这样的skills 的本质是给 AI 看的不是给程序解析的。AI 对自然语言的理解能力远强于对结构化配置的解析能力。你用 Markdown 写“检查所有组件的命名是否符合 PascalCase 规范”Claude 能理解这句话的语义甚至能处理边界情况比如它知道 index.tsx 这种文件名不算组件命名。但如果你用 JSON 写{check: naming, rule: pascal_case}Claude 反而需要额外推理才能理解你的意图。另一个原因是 Markdown 的表达能力强。你可以在 skill 里写示例、写反例、写注意事项、写条件分支这些用配置文件格式写起来非常别扭。而且 Markdown 对人类也友好团队协作时谁都能看懂、能改。当然 Markdown 也有缺点最大的问题是“不够精确”。同样的规则不同人写出来的 skill 效果可能差很多。这就需要一些写作技巧后面我会专门讲。3. Claude Code 中 Skills 的安装、加载与管理实操3.1 环境准备与 Claude Code 安装要点在折腾 skills 之前得先把 Claude Code 跑起来。这部分我尽量讲得细一点因为安装环节踩坑的人最多。Claude Code 目前主要通过 npm 分发安装命令是npm install -g anthropic-ai/claude-code装完之后在终端输入claude就能启动。但这里有几个常见的坑。第一个坑是 Node 版本。Claude Code 要求 Node 18 以上我建议直接用 20 LTS。如果你用 nvm 管理 Node 版本切换之后记得重新全局安装因为全局包是按 Node 版本隔离的。第二个坑是权限问题。在 macOS 和 Linux 上如果 npm 的全局目录需要 sudo 权限安装会失败或者装完之后命令找不到。解决办法是配置 npm 的 prefix 到用户目录npm config set prefix ~/.npm-global export PATH~/.npm-global/bin:$PATHWindows 用户遇到的典型问题是提示“无法将 claude 项识别为 cmdlet、函数、脚本文件或可运行程序的名称”。这通常是 PATH 没配好。npm 全局包的路径一般在%APPDATA%\npm确认这个路径在系统环境变量 PATH 里就行。还有一个 Windows 特有的问题Claude Code 的某些功能依赖虚拟化平台会提示需要启用虚拟机平台。这个在“启用或关闭 Windows 功能”里勾选“虚拟机平台”和“Windows Subsystem for Linux”就行重启后生效。安装完成后第一次运行claude会引导你做认证。认证方式这里不展开按提示操作即可。3.2 Skills 的目录结构与加载优先级Claude Code 加载 skills 的路径有几个层级优先级从高到低大致是这样的层级路径适用场景项目级project/.claude/skills/当前项目专用技能用户级~/.claude/skills/个人通用技能所有项目共享内置Claude Code 自带官方预置技能项目级的优先级最高意味着如果同一个技能名在项目级和用户级都存在项目级的会覆盖用户级的。这个设计很合理你可以在用户级放一些通用的代码规范 skill然后在具体项目里用项目级 skill 覆盖掉特殊规则。每个 skill 是一个独立的子目录目录名就是技能名里面至少包含一个 SKILL.md 文件。结构大概是这样.claude/ └── skills/ ├── code-review/ │ └── SKILL.md ├── commit-message/ │ └── SKILL.md └── api-design/ ├── SKILL.md └── examples/ └── sample.md注意 skill 目录里可以放其他辅助文件比如示例、模板、参考文档。Claude Code 加载时会把这些文件也纳入上下文所以你可以把一些长文档拆到单独文件里避免 SKILL.md 本身过于臃肿。3.3 从 GitHub 手动安装社区 Skills 的完整流程社区里有很多现成的 skills 仓库可以直接用比如 superpower skills、typesafe ai skills 这些。手动安装的流程其实很简单但有几个细节要注意。第一步是找到你想要的 skill。GitHub 上搜索 “claude skills” 或者 “SKILL.md” 能找到不少。挑选的时候重点看几个东西star 数量、最近更新时间、SKILL.md 的内容质量。一个半年没更新的 skill 可能已经不适配最新版 Claude Code 了。第二步是克隆或者下载。如果整个仓库都是 skills 集合直接 clone 下来git clone https://github.com/xxx/xxx-skills.git /tmp/xxx-skills第三步是复制到目标目录。假设你要把某个 skill 装到用户级mkdir -p ~/.claude/skills cp -r /tmp/xxx-skills/skills/code-review ~/.claude/skills/第四步是验证。启动 Claude Code输入/skills命令如果版本支持或者直接问它“你现在有哪些可用的 skills”看它能不能列出来。这里有一个容易忽略的点复制的时候要确保 SKILL.md 在正确的位置。有些仓库的目录结构是skills/code-review/SKILL.md有些是code-review.md直接放在根目录。前者可以直接复制整个目录后者需要你手动创建目录再放进去。另外如果你是从 GitHub 上单独下载某个 SKILL.md 文件注意检查它的 frontmatter 里有没有name字段。有些作者写 skill 时忘了加导致 Claude Code 加载后无法正确识别技能名。3.4 验证 Skills 是否生效的三种方法装完 skill 之后怎么确认它真的生效了我常用三种方法。第一种是直接询问。启动 Claude Code 后问它“列出当前加载的所有 skills 及其描述。”如果 skill 加载成功它应该能准确说出你刚装的技能名和描述。如果它说“我没有加载任何 skills”那说明路径不对或者文件格式有问题。第二种是触发测试。找一个该 skill 应该处理的场景看 Claude 的行为是否符合 skill 里定义的规则。比如你装了一个代码审查 skill就让它审查一段有明显问题的代码看它输出的格式是否和 skill 里定义的一致。第三种是看启动日志。Claude Code 启动时如果加了--verbose参数会输出加载了哪些 skill 文件。这个方法最直接但需要你注意看终端输出。如果验证不通过排查顺序是先确认文件路径对不对再确认 SKILL.md 的 frontmatter 格式对不对最后确认文件编码是不是 UTF-8有些 Windows 编辑器默认用 GBK会导致解析失败。4. 自己动手写一个高质量 Skill 的完整过程4.1 从需求到技能定义的转化思路写 skill 最难的不是技术而是“把模糊的需求转化成精确的规则”。我见过太多人写出来的 skill 是这样的“帮我写好代码”——这种 skill 等于没写因为 Claude 本来就会尽量写好代码。一个好的 skill 应该解决的是“通用助手做不好或者做得不一致”的问题。比如团队有特定的代码规范通用助手不知道某类任务有固定的输出格式每次手动指定很烦某个领域有特殊的边界情况通用助手容易忽略拿我自己写的一个“API 设计审查”skill 举例。起因是我们团队在 review API 设计时总是漏掉一些检查项比如分页参数命名不统一、错误码没有文档、缺少幂等性说明。这些问题每次都要靠人肉记忆去查效率很低。我把这个需求转化成了 skill 里的三条核心规则第一所有列表接口必须明确分页参数名和默认值第二所有错误响应必须包含业务错误码和用户可读消息第三所有写操作必须说明幂等性策略。每条规则下面再补充具体的检查方法和示例。这个转化过程的关键是把“我们希望你做得好”变成“你必须检查以下具体项”。前者是愿望后者是可执行的指令。4.2 SKILL.md 撰写的五个关键技巧写了十几个 skill 之后我总结了五个让 skill 效果翻倍的技巧。技巧一用“必须”和“禁止”代替“建议”和“尽量”。Claude 对指令性语言的遵循度远高于建议性语言。你写“建议使用函数式组件”它可能在某些情况下用类组件。你写“必须使用函数式组件禁止使用 class 组件”它就会严格遵守。技巧二给出正例和反例。人对例子的理解比对规则的理解更直观AI 也一样。在 skill 里放一段“正确示例”和一段“错误示例”Claude 的输出会明显更贴近你的预期。技巧三定义输出格式时用模板。不要只说“输出一个表格”而是直接把表格的 Markdown 模板写出来让它填空。这样格式一致性最高。技巧四把长规则拆成编号列表。一大段文字描述规则Claude 可能会漏掉其中几条。拆成 1、2、3、4 的编号列表每条独立成行遵循率会高很多。技巧五在 skill 末尾加一个“自检清单”。让 Claude 在完成任务后逐条核对是否满足要求。这个技巧我是从 prompt engineering 里学来的效果非常好。比如## 自检清单 完成任务后请逐条确认 - [ ] 所有问题都标注了文件路径和行号 - [ ] 每个问题都给出了具体的修改建议 - [ ] 输出格式符合上述模板 - [ ] 没有遗漏任何一条审查规则4.3 一个完整 Skill 的实战案例数学建模代码规范数学建模比赛里用 Claude Code 辅助写代码的人越来越多但通用助手生成的代码往往不符合建模场景的特殊需求。我写了一个专门针对数学建模的 skill这里把核心内容分享出来。--- name: math-modeling description: 数学建模竞赛代码规范适用于 Python 数据处理和求解脚本 version: 1.0.0 tags: [math, modeling, python] --- ## 角色 你是一名数学建模竞赛的代码助手熟悉 Python 科学计算栈 numpy, scipy, pandas, matplotlib, sklearn。 你的代码风格是可读性优先、注释充分、结果可复现。 ## 必须遵守的规则 1. 所有随机过程必须设置随机种子种子值统一用 42 2. 所有数据读取必须包含异常处理文件不存在时给出明确提示 3. 所有图表必须包含标题、轴标签、图例中文字体设置为 SimHei 4. 所有求解过程必须打印中间结果便于调试 5. 禁止使用全局变量所有参数通过函数参数传递 6. 每个函数必须有 docstring说明输入输出和算法思路 ## 输出格式 代码文件按以下结构组织 python # -*- coding: utf-8 -*- 模块说明本文件实现 XXX 模型 作者XXX 日期XXXX-XX-XX import numpy as np import pandas as pd # 全局配置 RANDOM_SEED 42 np.random.seed(RANDOM_SEED) def load_data(path: str) - pd.DataFrame: 读取数据文件 Args: path: 数据文件路径 Returns: 读取后的 DataFrame Raises: FileNotFoundError: 文件不存在时抛出 # 实现...自检清单[ ] 随机种子已设置[ ] 所有函数有 docstring[ ] 图表有完整标签[ ] 无全局变量[ ] 数据读取有异常处理这个 skill 在实际比赛中帮我们省了大量时间。以前每次让 Claude 写代码都要反复强调“记得设种子”“记得加中文标签”现在这些规则固化在 skill 里生成出来的代码直接就能用。 ### 4.4 调试和迭代 Skill 的方法论 Skill 不是一次写完就完事的需要反复调试。我的做法是建一个测试用例集每次修改 skill 后跑一遍看输出是否符合预期。 具体来说我会准备 3 到 5 个典型的输入场景覆盖正常情况、边界情况、异常情况。比如代码审查 skill我会准备一段有明显问题的代码、一段基本没问题的代码、一段格式很乱的代码。每次改完 skill分别用这三个输入测试对比输出。 迭代的方向通常是两个一是“漏检”就是本该被检查出来的问题没被检查出来说明规则写得太模糊需要加具体描述或示例二是“误报”就是没问题的地方被标记为问题说明规则太严格或者边界没定义清楚需要加例外说明。 我一般会维护一个 skill 的版本记录每次修改都记下改了什么、为什么改、测试结果如何。这个习惯在 skill 变复杂之后特别有用因为你会忘记当初为什么加某条规则。 ## 5. 常见问题排查与避坑经验实录 ### 5.1 Skills 不生效的排查清单 Skills 装了但没反应这是最高频的问题。我整理了一个排查清单按顺序检查基本能定位到原因。 | 排查项 | 检查方法 | 常见问题 | |--------|----------|----------| | 文件路径 | 确认 SKILL.md 在 .claude/skills/name/ 下 | 路径层级多了一层或少了一层 | | 文件编码 | 用 file 命令查看编码 | Windows 下保存成了 GBK | | frontmatter | 检查开头是否有 --- 包裹的 YAML | 缺少 name 或 description | | 目录权限 | ls -la 确认可读 | 权限不足导致读取失败 | | 版本兼容 | 确认 Claude Code 版本支持 skills | 旧版本不支持该功能 | | 技能冲突 | 检查是否有同名 skill 覆盖 | 项目级覆盖了用户级 | 我遇到最多的是路径问题。很多人把 SKILL.md 直接放在 .claude/skills/ 下面而不是放在子目录里。Claude Code 要求每个 skill 是一个独立的子目录目录名就是技能名。这个设计是为了支持一个 skill 包含多个文件的情况。 另一个高频问题是 frontmatter 格式错误。YAML 对缩进和符号很敏感比如 name: code-review 和 name:code-review 是不同的后者会被解析成一个键值对但值前面带空格。建议用编辑器的高亮功能确认 YAML 语法正确。 ### 5.2 Skill 触发时机不对怎么办 有时候 skill 加载成功了但 Claude 在该用它的时候不用或者不该用的时候乱用。这是触发时机的问题。 触发时机的核心在 frontmatter 的 description 字段。Claude Code 会根据这个描述来判断当前对话是否匹配该技能。如果 description 写得太宽泛比如“处理代码相关任务”那几乎每次对话都会触发。如果写得太窄比如“审查 React 函数式组件的 useEffect 依赖数组”那可能永远不触发。 我的经验是 description 要包含三个要素**动作、对象、场景**。比如“对 Python 脚本进行代码审查适用于数据处理和科学计算场景”。动作是“代码审查”对象是“Python 脚本”场景是“数据处理和科学计算”。这样 Claude 就能准确判断什么时候该用。 如果还是触发不准可以在 skill 正文里加一个“触发条件”区块明确写出什么时候应该激活这个技能 markdown ## 触发条件 当用户提出以下类型的请求时激活本技能 - 要求审查 Python 代码 - 要求检查数据处理脚本的规范性 - 要求对科学计算代码提出改进建议 当用户只是询问 Python 语法问题时不要激活本技能。5.3 多个 Skills 冲突的处理策略当你装了很多 skill 之后可能会遇到冲突。比如一个 skill 要求“所有函数必须写类型注解”另一个 skill 要求“保持代码简洁避免冗余”。这两个规则在某些情况下会打架。处理冲突的原则是明确优先级定义覆盖关系。在 skill 的 frontmatter 里可以用priority字段指定优先级数字越大优先级越高。当两个 skill 的规则冲突时高优先级的规则生效。但更好的做法是从源头避免冲突。写 skill 的时候就要考虑它和其他 skill 的边界。比如代码审查 skill 只负责“发现问题”不负责“修改代码”那它和代码生成 skill 就不会冲突。如果冲突已经发生了我的处理方式是先确认哪个 skill 的规则更符合当前项目的实际需求然后把另一个 skill 里冲突的部分改成“在 XX 情况下例外”。比如把“所有函数必须写类型注解”改成“所有公开函数必须写类型注解内部辅助函数可省略”。5.4 性能与上下文占用的平衡每个加载的 skill 都会占用 Claude 的上下文窗口。上下文窗口是有限的如果 skill 太多或者单个 skill 太长会导致 Claude 处理你的实际请求时“注意力”被分散效果反而下降。我的经验值是同时加载的 skill 不超过 5 个单个 SKILL.md 不超过 500 行。超过这个量级就要考虑拆分或者按需加载。按需加载的思路是把不常用的 skill 放在一个“备用”目录里需要的时候再复制到.claude/skills/下。或者用 Claude Code 的配置功能指定只在特定项目里加载特定 skill。另一个优化技巧是把 skill 里的长文档拆到单独文件。比如一个 skill 有大量的示例代码可以把示例放到examples/子目录里SKILL.md 里只保留规则和引用。Claude Code 加载时会按需读取这些文件不会一次性全部塞进上下文。5.5 社区 Skills 的筛选与安全注意事项从社区下载 skill 直接用有几个风险要注意。第一是内容质量参差不齐。有些 skill 是随手写的规则模糊、格式混乱用了反而添乱。下载前一定要读一遍 SKILL.md 的内容确认它的规则清晰、格式规范。第二是潜在的安全风险。虽然 SKILL.md 本身只是文本但如果 skill 里包含让 Claude 执行某些命令的指令可能会带来风险。比如一个 skill 里写“自动执行 npm install 安装依赖”如果这个依赖有问题就麻烦了。我的做法是任何涉及执行命令、修改系统配置的 skill都要先审查再使用。第三是版本兼容性。Claude Code 更新比较频繁旧版 skill 可能用了已经废弃的语法。下载时看一下仓库的最后更新时间超过三个月没更新的要谨慎。第四是许可证问题。有些 skill 仓库有特定的开源许可证商用前要确认是否符合你的使用场景。6. Skills 的进阶玩法与生态观察6.1 组合多个 Skills 构建工作流单个 skill 解决单点问题组合起来能构建完整的工作流。我目前的工作流是这样的code-review负责审查commit-message负责生成提交信息api-design负责接口设计审查。三个 skill 各司其职在提交代码前依次触发。组合的关键是让 skill 之间有清晰的输入输出关系。比如code-review的输出是一份问题列表commit-message可以读取这份列表来生成更有信息量的提交信息。虽然 Claude Code 不直接支持 skill 之间的数据传递但你可以通过对话上下文来实现——先让 Claude 执行审查再让它基于审查结果生成提交信息。更进阶的玩法是写一个“元 skill”它的作用是协调其他 skill 的执行顺序。比如一个pre-commitskill里面定义了“先执行代码审查再执行格式检查最后生成提交信息”的流程。这样你只需要触发一个 skill就能完成整个提交流程。6.2 针对特定领域的 Skills 设计思路不同领域写 skill 的思路差异很大。我举几个典型场景。前端开发场景重点在组件规范、状态管理约定、样式方案统一。skill 里要明确指定用函数式组件还是类组件、用 CSS Modules 还是 styled-components、状态管理用 Redux 还是 Zustand。这些选择一旦定下来skill 就能保证生成的代码风格一致。数学建模场景重点在可复现性和结果展示。skill 里要强制设置随机种子、统一图表风格、规范中间结果的打印格式。建模比赛时间紧代码可读性和可复现性比性能更重要。AI 漫剧场景这个比较新主要是用 AI 生成漫画和短剧脚本。skill 里要定义角色设定的一致性规则、分镜描述的格式、对话风格。核心是保证多轮生成的内容在角色形象和叙事风格上保持一致。STM32 嵌入式场景重点在寄存器操作规范、中断处理约定、外设初始化顺序。skill 里要明确 HAL 库的使用方式、中断优先级分组规则、时钟配置流程。嵌入式开发对细节要求极高skill 能有效减少低级错误。6.3 Skills 生态的现状与未来可能目前 skills 生态还处于早期阶段。社区里的 skill 数量在快速增长但质量分化严重。高质量 skill 主要集中在几个方向代码审查、提交信息生成、特定框架的代码规范。这些方向的共同点是规则明确、输出格式固定适合用 skill 来固化。从趋势上看我觉得接下来会有几个变化。一是官方会推出更多内置 skill覆盖常见的开发场景降低新用户的上手门槛。二是skill 市场或注册中心会出现让分享和发现 skill 更容易。三是skill 的组合和编排能力会增强支持更复杂的工作流定义。对于个人开发者来说现在投入时间学习 skill 的编写是划算的。这个技能的门槛不高但能显著提升日常开发效率。而且随着生态成熟会写高质量 skill 的人会越来越有优势。6.4 我个人的 Skill 管理习惯最后分享几个我日常管理 skill 的习惯都是踩坑之后总结出来的。第一用 Git 管理用户级 skills 目录。~/.claude/skills/本身就是一个 Git 仓库每次修改都提交。这样换电脑或者重装系统时直接 clone 下来就能恢复所有 skill。而且能看到每个 skill 的修改历史方便回溯。第二给每个 skill 写一个 README。SKILL.md 是给 Claude 看的README.md 是给自己看的。README 里记录这个 skill 解决什么问题、什么时候该用、有什么已知限制。skill 多了之后没有 README 根本记不住每个是干什么的。第三定期清理不用的 skill。我每两个月会 review 一次 skills 目录把三个月没用过的 skill 移到archive/子目录。保持活跃 skill 数量在 5 个以内避免上下文被稀释。第四建立个人 skill 模板。我把自己常用的 skill 结构固化成了一个模板文件新建 skill 时直接复制模板再改内容。模板里包含了 frontmatter、角色定义、规则列表、输出格式、自检清单这些标准区块省去了每次从头搭结构的时间。第五关注社区但保持克制。社区里每天都有新 skill 出现但没必要每个都装。我的原则是只有当某个重复性任务让我感到烦躁时才去找或写对应的 skill。需求驱动而不是收藏驱动。这些习惯看起来琐碎但实际用下来能省很多时间。尤其是 Git 管理和定期清理这两条建议从第一天就开始做。