终于有人聊awesome-claude-skills这个方向了。我第一次看到“给 Claude 装技能”这种说法时，第一反应是不信——Claude 本身已经能写代码、能读文档，为什么还需要额外装东西？直到有一天，我用一个社区里的前端代码审查 skill 跑了一遍自己的项目，它不光把我之前所有代码评审规则全部执行了，还顺手指出了我忽略的两个可访问性问题，我才意识到：Skills 不是给 Claude 打补丁，而是把“会做”变成“按标准做”。

这篇文章不是概念科普，是我把 Claude Code 和 Skills 从安装到实战、从踩坑到写自定义技能全部走了一遍的完整记录。如果你正在折腾 Claude Code、想在前端开发里真正用起来，或者准备自己写一个 skill 给团队用，下面这些内容应该能帮你少走不少弯路。

1. 先弄明白Skills的底层逻辑：AI的“入职手册”而不是提词器

1.1 Agent的“新手期”与Skills的出现

Claude 这类大模型的能力边界很有意思：你给它一个任务，它能做得不错，但“做得不错”不等于“稳定地做得不错”。同一个任务换个措辞，结果可能差很多；换一个项目背景，它的行为又会漂移。这有点像刚入职的实习生，能力很强，但对团队的具体规范一无所知，需要你每次都不厌其烦地告诉他“我们项目里 Button 组件必须走 design system，不要自己造轮子”“代码提交前必须跑一次 lint”。

Skills 做的事情，就是把这一大段“入职培训”固化成文件，让 Claude 在遇到相关任务时自动去查、去遵守。它不是一次性的提示词，而是一本带目录的岗位操作手册。官方定义是：Skills 是模型可复用的指令集合，打包了完成特定任务的步骤、规则和资源，当对话内容匹配到 skill 的描述时，Claude 会自动加载并按照里面的流程执行。

我当时的第一个反应是：这不就是 prompt 模板吗？实际用下来完全不是一回事。Prompt 模板是你主动塞给模型的，而 skill 的加载是模型自主判断触发的。你不需要在每次对话里复制粘贴几千字的规范，只需要在任务里带上“帮我 review 一下这个组件”，Claude 就能检索到对应的 skill 并主动套用。这种“按需加载”的设计，才是 Skills 区别于传统 prompt 工程的核心。

1.2 SKILL.md的结构拆解

一个标准的 skill，核心就是一个SKILL.md文件，放在固定的目录里。Claude Code 会自动扫描这些目录，把每个 skill 的描述信息建立索引。SKILL.md长这样：

--- name: react-component-review description: 用于审查React组件的可访问性、性能与代码规范，在用户要求"检查组件""review代码""看看这个Button实现"等场景下使用。 --- # React组件审查流程 ## 职责范围 - 只审查React/TSX组件代码，不修改业务逻辑。 ## 必须执行的步骤 1. 先运行 `node scripts/check-a11y.js <file>` 检查可访问性。 2. 检查组件props设计与状态管理。 3. 检查样式是否遵循项目design tokens。 ## 输出格式 - 按"问题-位置-修改建议"三列输出审查报告。 - 严重问题用"阻塞"标记，次要问题用"建议"标记。

这个文件里最关键的部分是name和description，因为它们决定了 skill 会不会被触发。description写得好不好，直接影响命中率。后面我会专门用一节讲怎么把 description 写到“该触发时一个不落，不该触发时一个不沾”。

目录结构可以是单个文件，也可以带上脚本和资源：

skills/react-component-review/ ├── SKILL.md ├── scripts/ │ └── check-a11y.js └── resources/ └── examples/

Claude 加载 skill 之后，不仅读到了规则，还能调用里面的脚本去执行具体检查。这就是为什么 Skills 能完成比“给 AI 讲规矩”更复杂的事情——它能驱动 Agent 按流程办事，中间穿插真实的代码执行。

1.3 Skills、MCP和普通Prompt到底怎么分工

这里有个绕不开的问题：Claude Code 里还有 MCP（Model Context Protocol），它和 Skills 到底什么关系？我一开始也混淆，后来用一句话给自己理清了：MCP 是给模型接“手”，Skills 是给模型立“规矩”。

MCP 解决的是工具接入问题。你想让 Claude 查数据库、调浏览器、操作 GitHub，那就配一个 MCP server，暴露工具接口。Skills 解决的是流程问题。你想让 Claude 按团队规范审查代码、按特定步骤生成组件，那就写一个 skill，把流程固化下来。

举个例子：一个完整的“前端发版检查”流程，你需要 MCP 提供 Git 操作工具和 CI 状态查询工具，需要 Skill 规定检查顺序——先查依赖锁定文件，再查构建产物，最后看 Git 提交记录。两者是配合关系，不是替代关系。我现在做的复杂 skill 基本都是“Skill 定流程 + MCP 给工具”的组合。

而普通 prompt 呢？它就是一次性的口头交代。Skill 和普通 prompt 的差别，我用一个对照表总结一下：

从这个表能看出来，Skill 真正的价值不在于“让 AI 更聪明”，而在于“让 AI 的输出更稳定、更可控”。对于做前端开发的人来说，这种稳定性恰恰是最值钱的东西。

2. 从零跑通Claude Code：安装、报错与本地模型配置

2.1 安装环节常见的三个报错

先说安装本身。我是在 macOS 上用的npm install -g @anthropic-ai/claude-code，整个过程很顺，但身边同事在 Windows 和 Linux 上踩了不少坑。我把它们的报错信息和解决办法整理一下。

第一个高频报错是error: claude native binary not installed. either postinstall did not run...。这个问题的本质是 npm 包安装完成后，需要执行的 postinstall 脚本没有成功运行。可能原因包括网络问题导致二进制下载中断、npm 缓存异常、或者是公司网络策略拦截了下载。解决办法分几步走：先试npm rebuild @anthropic-ai/claude-code，不行就完整卸载重装npm uninstall -g @anthropic-ai/claude-code && npm install -g @anthropic-ai/claude-code，再不行就清掉 npm 缓存npm cache clean --force后重装。我见过一个人是 npm 版本太老导致 postinstall 脚本行为异常，升级 npm 之后就好了。

第二个高频报错是 Windows PowerShell 下提示“无法将‘claude’项识别为 cmdlet、函数、脚本文件或可运行程序的名称”。这就是典型的 PATH 环境变量问题。npm 全局安装的目录没有被加入系统 PATH。解决办法是先执行npm prefix -g找到全局目录，然后把这个目录加到用户环境变量的 Path 里。注意加完之后要重新开一个终端窗口，否则环境变量不会生效。图省事的话，也可以直接用npx @anthropic-ai/claude-code调用，但我自己不太推荐这种方式，每次都要走 npx 解析，启动速度慢一点，而且容易下载到临时缓存版本。

第三个报错是企业环境里常见的your organization has disabled claude subscription access for claude code。这个不是你本地的问题，是组织策略层面禁用了 Claude Code 的订阅接入。需要说明的是，这里虽然表明“组织”禁用，但它纯粹属于产品访问级别的权限控制，处理方式也简单直接——要么让管理员在后台放开策略，要么在个人工作区使用自己的订阅。我看到不少团队已经用这种方式规范化内部 AI 工具的使用边界，把能不能跑、怎么跑的话语权交给管理员，避免业务代码被随意送出。遇到这个提示，别折腾，先确认自己的账号有没有可用的订阅权限，再找管理员检查策略即可。

2.2 Windows、VSCode与终端环境的使用差异

安装成功之后，接下来是环境适配问题。我同事在 Windows 上遇到一个提示：claude's workspace requires the virtual machine platform on windows. enable。这个提示的意思是，某些依赖虚拟化隔离的 workspace 能力在 Windows 上需要额外开启虚拟机平台功能。如果只是用 Claude Code 做普通对话和代码操作，这个功能不是必须的，不影响日常使用。但如果你后续想体验沙盒隔离的隐藏功能，就需要去 Windows 的“启用或关闭 Windows 功能”里打开“Windows Hypervisor Platform”，然后重启电脑。

VSCode 用户可以直接搜索并安装 Claude Code 官方扩展。装完之后在 VSCode 的终端里就能直接敲claude命令。这里有一个不同的体验：VSCode 里的 Claude Code 可以更自然地感知当前打开的文件和项目结构，我经常让它“参考当前打开的组件文件生成配套的测试文件”，它抓取上下文的准确率比纯终端模式高很多。不过要注意，VSCode 扩展本质上还是在你机器上起了一个 Claude Code 进程，它依赖的还是同一个配置文件、同一套权限设置，所以不存在“装了两套”的问题。

Linux 环境下的配置我后来在 Ubuntu 服务器上也试过一遍，重点还是在 PATH 和依赖库上。Ubuntu 上如果装完 claude 命令找不到，通常也是 npm 全局目录的问题，用npm prefix -g定位后手动加 PATH 即可。还有一个小坑是部分 Linux 机器缺少一些基础依赖，比如libstdc++版本过低会导致 claude 启动时崩溃，这时候需要更新一下系统的基础运行库。这类问题报错信息一般比较明确，按提示操作就行，不用慌。

2.3 把Claude Code接到LM Studio本地模型

这个需求是看到热搜词里有人在问“Claude Code 调用 LM Studio 的本地模型”，我自己也实测过，所以单独拿出来讲。这个做法最大的价值，是在没有订阅环境或者对数据敏感的场景下，仍然可以用 Claude Code 的交互框架，把底层模型换成本地推理服务。

思路很简单：Claude Code 支持通过环境变量ANTHROPIC_BASE_URL把 API 请求指向任意兼容 Anthropic 接口格式的服务。LM Studio 本身提供的是 OpenAI 兼容接口，所以中间需要一层转换，把 Anthropic 的请求格式转成 OpenAI 格式，再发给本地模型。实际操作步骤大致如下：

先启动 LM Studio 的本地服务器，默认端口通常是1234，然后在终端里设置环境变量：

export ANTHROPIC_BASE_URL=http://localhost:1234/v1 export ANTHROPIC_API_KEY=local-test-key claude

如果中间那层转换你不想手动搭，社区里有不少现成的本地代理工具可以做格式转换，搜“Anthropic API 兼容代理”就能找到。我实际测下来的结论是：这套方案跑通是真的能跑通，但体验和官方 Claude 模型有明显差距。本地小参数模型在复杂代码推理上的表现确实弱一些，更多适合“离线环境里做代码上下文问答”或者“验证 Claude Code 工作流”的场景，真正用来做大型前端项目重构，还是建议用官方模型。

2.4 终端命令执行权限的取舍

使用 Claude Code 和直接网页版 Chat 的一个巨大差别是：它有权限在终端里执行命令。这既是它的核心价值，也是最大的风险点。刚上手的时候，我每次看它停下来问“是否允许运行这个命令”都觉得烦，后来发现这个权限机制是真有用的。

Claude Code 的权限模式主要分几种：一种是每次命令都要你确认，一种是根据规则自动放行，还有一种是完全手动控制。我的做法是：对于明确的只读命令（比如git diff、cat、ls）放到自动放行列表，对于可能产生副作用的命令（比如npm install、rm）保持询问。写权限规则的时候要注意作用域，尽量限制在项目目录内，避免一个规则把所有终端操作全放开。

另外，一定不要图省事直接开“全自动批准”模式跑在重要仓库上。我见过一个案例，Claude Code 自动执行了一个git push --force，直接把同事的提交覆盖了。这种事故一次就能让你对权限机制彻底改观。越是熟练使用 Agent，越要对它的每一条终端命令保持尊重。

3. 到哪找好用的Skills，以及怎么判断一个Skill值不值得装

3.1 官方仓库与社区平台的真实情况

安装配置都打通之后，下一个问题自然是：Skills 到哪找？

最靠谱的还是官方渠道。Anthropic 自己在 GitHub 维护了一个 skills 仓库，里面放了官方的示例 skill，覆盖文档生成、网页开发等场景，质量有保障，适合用来学习写法。另外，GitHub 上搜索claude skills或者浏览awesome-claude-skills这类聚合列表，能找到大量社区整理的资源索引。所谓 awesome 列表，就是一堆人在 GitHub 上用 Markdown 文件持续收录优质项目的地方，你可以把它当成“经过初步筛选的口碑清单”，虽然筛选标准不透明，但至少省去了自己大海捞针的功夫。

还有一些第三方平台会把 skill 打包成 marketplace，可以浏览、安装，有点类似 VSCode 插件市场的玩法。这个生态目前还比较早期，很多平台的收录规则和审核机制都比较弱。我个人的经验是：第三方平台可以用来“发现”，但安装前一定要回到源码去看原始仓库，确认这个 skill 的更新时间和真实维护状态。

3.2 筛选一个高质量Skill的四个检查点

社区里的 Skills 质量参差不齐，装之前如果不检查，很容易出现“装了等于没装”甚至干扰模型行为的情况。我给自己定的筛选标准主要有四条：

第一，看 description 质量。一个负责的 skill 作者，会把 description 写得很精细。如果 description 只有一句含糊的“帮助做前端开发”，那触发精度大概率很低，会在各种不相关场景里被加载，反而污染上下文。好的 description 会明确触发场景、明确不适用场景。

第二，看脚本安全性和可审计性。凡是带脚本的 skill，我都会把 scripts 目录里的代码从头到尾读一遍。Claude Code 执行 skill 中的脚本时，是在本机环境中运行的，权限不小。如果作者在里面埋了一段上传数据的代码，普通用户根本不会察觉。Skill 生态目前还没有成熟的沙箱隔离机制，用户自身需要具备安全意识。

第三，看依赖是否克制。有些 skill 为了炫技，在脚本里引入一堆依赖，或者要求调用外部 API。这种 skill 部署成本高、后续维护容易失控。我更喜欢依赖少、单文件、可在本地稳定运行的 skill。

第四，看是否有示例和测试用例。一个好 skill 应该自带演示场景，最好在 SKILL.md 里就写了“在以下场景运行此 skill，预期输出包括……”。这意味着作者确实用自己的 skill 调试过，不是凭空想象出来的流程。

我在实操中还有一个不成文的习惯：新装一个 skill 后，先在一个测试项目里验证它的效果，确认没问题后再在真实项目里用。真实项目有历史包袱和上下文噪音，如果在这个环境里直接测试一个陌生 skill，出了问题很难判断是 skill 的问题还是环境的问题。

3.3 我长期保留的几个Skill和它们的作用

用了一段时间之后，我手头的 skill 反而越来越少。现在常驻的有这么几个：

一个是代码审查类 skill，就是开篇提到的那个。它规定了审查的输出格式、检查优先级、以及哪些问题要归类为“阻塞项”。这个 skill 帮我省了很多代码评审的时间，而且它的评分标准是项目定制的，不会像通用提示词那样泛泛而谈。

一个是前端组件生成类 skill。它固化了我的文件组织习惯：生成一个新组件时，必须同时产出组件代码、样式文件、Storybook 文档和基础测试。这个 skill 让 Claude 从“能写组件”变成“按团队预期写组件”，我只需要在任务里描述组件需求，它就会自动套用整套规范。

还有一个是 Git 提交记录整理类 skill。它的作用是检查 diff 内容，按约定的提交信息格式生成符合规范的提交说明。看起来事小，但对多人协作的仓库来说，统一提交风格能省掉不少沟通成本。

我用的这些 skill 基本都能在 GitHub 上找到同类型的开源实现，直接抄下来改改 description 和规则细节就能用。需要提醒的是，所谓“superpower skills”这类打包合集，虽然听起来很厉害，但它们通常把几十个技能塞进一个仓库，加载时信息密度很高，反而增加了上下文的负担。我的建议是：拆开来一个个试，留下真正用得上的，用不上的直接删掉。

4. 动手写一个前端Skills：从选题到发版的全过程

4.1 选型原则：什么样的任务适合做成Skill

用了别人的 skill 之后，手痒是正常的。但自己动手之前，先想清楚一个问题：你到底要把什么做成 skill？

我总结的选型标准有三个关键词：高频、有标准、可验证。频率不够高的任务，写 skill 的投入产出比太低；没有明确标准的任务，无法固化成规则；不可验证的任务，你根本不知道 skill 有没有生效。

拿前端开发举例，适合做成 skill 的事情包括：组件生成（频次高，规范明确）、代码审查（频次高，标准清晰）、依赖升级（频次中等，流程固定）、项目脚手架初始化（频次低但流程极复杂）。不适合做成 skill 的是那种“帮我看看这个页面为什么布局乱了”的排查性任务，这类任务每次的上下文和原因都不一样，固化成规则只会限制模型的发挥。

我最后选的题目是“React 组件可访问性审查”。选它的理由是：可访问性规范（WAI-ARIA）有官方标准，能落到具体规则；项目里有大量历史组件，需要定期审查；社区里没有完全符合我团队标准的现成 skill，值得自己写。

4.2 SKILL.md的写法：让模型一次就能读懂

写完名字和目录之后，最难的是 SKILL.md 的正文怎么写。这里的关键矛盾是：写得太详细，模型加载时占用大量上下文；写得太简略，模型执行时又有太多自由发挥空间。我的经验是，用一种“强制流程 + 明确边界”的思路来写。

强制流程的意思是：把执行步骤写成“必须”句式。比如“必须先运行检查脚本，再进入代码审查”“每一步完成后在输出中标记当前进度”。这能有效防止 Claude 跳步骤、先总结后行动等常见毛病。

明确边界的意思是：把不该做的写清楚。比如“不需要提出可访问性之外的性能优化建议”“不要修改组件实现代码，你只负责输出审查报告”。我在第一次调试时就发现，如果不加边界，Claude 很容易“好心办坏事”，在审查报告里夹带大量结构重构建议，反而让输出变得难以聚焦。

还有一个细节是格式。Markdown 层级不用太深，三到四级就够。一定要多用“先…再…然后”的顺序词，少让模型自行判断优先级。如果某个步骤依赖脚本输出，直接把脚本路径写进 SKILL.md，并且明确说“如果脚本执行失败，停止后续审查流程并报告错误”。这种硬性依赖能避免模型在脚本失败后凭空想象继续硬干。

4.3 配套脚本与回归测试

我的这个 skill 带了一个 Node.js 脚本，用来扫描组件文件里常见的可访问性问题标签。核心逻辑是正则匹配 JSX 中的元素标签，检查<button>是否包含aria-label，<img>是否有alt，表单元素是否有关联 label。这个脚本不追求百分百准确，它的作用是给 Claude 提供一个“硬性候选问题列表”，让 Claude 基于脚本结果做二次判断。

脚本写完之后，最重要的环节是回归测试。我的做法是创建一个测试项目，里面故意放一个按钮标签缺少 aria-label、一个图片标签缺少 alt、一个表格缺少 caption 的组件。然后跑 Claude Code，输入“审查一下 test-components/Button.tsx”，观察它是否自动加载了这个 skill，是否先执行了脚本，是否把脚本输出的候选问题纳入最终报告。

如果模型没有自动加载 skill，我会先怀疑 description 写得太窄，把触发词覆盖得更广一些。如果加载了但没有执行脚本，我会检查 SKILL.md 里的步骤是否写得足够强制。如果脚本执行了但结果被模型忽略，我会在输出格式要求里明确写上“审查报告必须包含脚本检查结果”。这轮测试通常会迭代两三遍，是 skill 质量提升最快的一步。

4.4 发布与后续迭代

测试稳定之后，就可以考虑发布。我在 GitHub 上建了仓库，把 skill 目录按照标准结构提交，写了一个简短的 README，说明适用场景和安装方式。发布时有一点要注意：如果没有写清楚适用范围，别人安装之后很可能因为触发场景不理解而觉得“没用”。我在 README 里会加一小段“本 skill 适用于有可访问性要求的 React/TSX 项目，不适用于静态页面排查”。

发布不等于结束。后续迭代主要靠日常使用中积累的反馈。我每次发现 Claude 执行这个 skill 时偏离预期，都会回到 SKILL.md 补一条明确规则。这有点像一个持续改进的过程——Skill 就是你把对 AI 的期望一点一点校准成文档。我也见过有人直接把 SKILL.md 当作团队规范文档来维护，新技术栈变化的时候定期更新，效果比单独维护文档好得多，因为规范直接长在了 AI 的执行流程里。

5. Skill不生效时的完整排查链路

5.1 第一层：它到底有没有被加载

当你发现 Claude 没有按照预期使用某个 skill，首先需要确认的不是“skill 写得不好”，而是“skill 到底有没有被加载”。

检查方法很简单：在你输入任务之后，观察 Claude 的输出里有没有出现类似“我将按照 xxx skill 的流程来处理”的表述，或者在工具调用记录里有没有加载 skill 的痕迹。如果你不确定，可以直接在对话里问它“你当前可以使用哪些 skills？”或者“你是否应用了 react-component-review 这个 skill？”。虽然模型有时候会一本正经地说“我加载了”，但如果不放心，我更推荐用更硬核的办法：在 SKILL.md 里故意写一句“开始执行时，必须先输出‘已加载 react-component-review’，然后说明你的执行计划”。这相当于给 skill 加了一个“心跳信号”，一旦被加载，行为就一定能被识别。这是我自己调试时发现的最有效的验证手段。

如果确认没有加载，优先级最高的怀疑对象是目录位置。Claude Code 的 skill 发现机制有固定的扫描目录，比如项目根目录下的.claude/skills/和用户全局的 skills 目录。如果把 skill 放错了位置，Claude 是找不到的。此外还要检查SKILL.md这个文件名是不是完好无损——大小写、后缀少一个字，都不能被正确识别。我最初在 Windows 上就遇到过文件名被系统自动加上了.txt后缀的情况。

5.2 第二层：加载了，但行为明显不对

如果 skill 确认加载了，但行为依然不对，问题往往出在 description 或正文规则的“颗粒度”上。

一个最常见的问题是 description 写成了“功能描述”而不是“触发描述”。比如“用于代码审查”这种描述，模型只能在“代码审查”这个词完全出现时才会命中。真正的做法是描述“触发场景”，要写得像搜索引擎的索引词一样，把你能想到的相近表达都覆盖进去，同时把不适用场景也写出来。我会把 description 分成两部分：前半段是触发条件，后半段是明确的反例边界。

另一个常见问题是正文规则给的“灵活性”太大。我的经验是，凡是说“可以根据情况判断是否执行”这类话，Claude 大概率会选择最省事的方式——不执行。你希望它执行什么，就把话说死：“必须执行”“未经执行不得进入下一步”。用词要像写法律条文一样严谨，不能像写周报一样留有余地。

还有一个小细节是，某些前卫的 skill 功能依赖 Claude Code 的隐藏开关或最新实验性特性。如果你装的 skill 是在这个特性刚发布时写的，而你的客户端版本还没更新，就会出现“加载了但关键技术调用不起作用”的情况。排查方法就是更新 Claude Code 到最新版本，然后重新测试。

5.3 第三层：脚本执行、路径与权限问题

当 skill 里带有配套脚本时，行为不对的原因大概率会落到脚本执行链路这一层。

我遇到过的典型场景是：Claude 加载了 skill，也说要执行脚本，但脚本实际没有跑起来。主要原因有三个：脚本路径写成了相对路径但 Claude 当前的工作目录不在 skill 目录下；脚本没有可执行权限；脚本运行依赖的 node 模块没有安装。解决路径问题的方式是在 SKILL.md 里明确要求 Claude “先切换到 skill 所在目录，再以绝对路径方式执行脚本”，或者干脆在脚本命令里拼接完整路径。

还有一个容易被忽略的问题：skill 目录里如果有大量示例文件或者资源文件，它们会全部被加载进上下文，导致上下文膨胀、指令被稀释。我写自己的 skill 时，会把示例单独放在 resources 目录，并在 SKILL.md 里注明“这些示例仅用于参考格式，不要在你处理任务时逐个阅读”。否则，一个简单任务可能会因为读取过多示例而降低执行精准度。

权限问题也很关键。Claude Code 的脚本执行遵循权限规则，当 skill 要运行的命令不在放行名单里时，进程会挂起等你确认。如果你用的是非交互式模式，这个确认永远不会来，脚本就会一直卡着。处理方式是把 skill 运行需要的命令加入放行列表，或者确保你跑的是交互式终端，能及时确认。我在服务端跑批量任务时踩过一次这个坑，那之后就把权限规则写到了每个 skill 的帮助文档里。

5.4 调试时的几个实用技巧

最后给一套我自己的调试“快捷键”。第一，用claude --debug启动一个带调试日志的会话，它会输出详细的工具调用链路，skill 是否被命中、脚本执行结果如何，都能看得很清楚。第二，准备一个最小测试仓库，里面只放最基础的文件，方便你隔离变量。第三，每次改完 SKILL.md，都要做一次“冷启动”测试：新开一个会话，不要沿用旧会话历史，因为模型可能还保留着旧的行为惯性。

按照这个思路去排查，绝大多数 skill 失效的问题都能在半小时内定位。最忌讳的是不看日志、凭感觉改 description——你以为问题是触发词不够，实际可能只是脚本路径写错了。从链路的第一层开始排查，才是最省时间的做法。

6. 用了一段时间后的几点真实感受

Skill 这个东西，用久了会有一个很微妙的变化：你不再把它当成“AI 的外挂”，而是开始把它当成表达自己工作方法的一种方式。我现在的说法是“把一个 skill 调教到顺手，等于把自己的隐形知识显性化了一遍”，因为写规则、补边界、测回归的这个过程，本质上就是在梳理自己对一个任务的理解。

6.1 别囤Skill，要“以任务为中心”反向选型

我见过不少朋友一开始兴致勃勃下载了几十个 skill，最后真正用的就两三个。原因很简单：Skill 之间会互相竞争触发，如果你装了五六个“代码审查”类的 skill，它们的 description 会互相干扰，Claude 会随机选择一个加载，输出风格每次都不一样，反而失去稳定性。我现在给自己定的原则是：同一个任务类型只保留一个 skill，新来的要替换就得先在测试仓库里跑赢旧的。

6.2 把团队规范沉淀成Skill的边界

我还尝试过把团队的前端开发规范完整写成一个 skill。实际效果很好，但也发现了边界：太具体的一次性指导不适合写进 skill。比如“这次项目里登录页的布局必须用栅格系统”这种话，应该直接写在任务描述里，而不是固化到 skill 中。Skill 适合承载的，是那种“每次做这类任务都必须遵守”的事情，而不是一次性或临时的偏好。

6.3 下一步我打算怎么玩

我现在比较关注的两个方向：一个是把 Skill 和 MCP 串起来做端到端流程，让 Claude 先按 skill 规定的步骤走，再通过 MCP 调用内部工具完成数据获取和变更；另一个是给团队维护一个私有 skills 仓库，把常用流程和技术规范沉淀进去，新成员上手时直接面对一个“懂规矩”的 AI。

说实话，底层模型本身的能力更新很快，近期 Claude 在物理推理类测试上的表现也让人对 Agent 的应用更有信心。模型越强，Skills 的价值反而越明显——因为“把能力稳定地用在具体业务上”这件事，从来不只是模型参数的问题，而是工程和管理的问题。Skills 恰好站在这两者之间的位置，这也是我愿意花这么多篇幅去研究它的原因。如果你也在折腾 Claude Code 的生态，希望这篇记录能给你一些可复用的经验。