终于有人聊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 里还有 MCPModel Context Protocol它和 Skills 到底什么关系我一开始也混淆后来用一句话给自己理清了MCP 是给模型接“手”Skills 是给模型立“规矩”。MCP 解决的是工具接入问题。你想让 Claude 查数据库、调浏览器、操作 GitHub那就配一个 MCP server暴露工具接口。Skills 解决的是流程问题。你想让 Claude 按团队规范审查代码、按特定步骤生成组件那就写一个 skill把流程固化下来。举个例子一个完整的“前端发版检查”流程你需要 MCP 提供 Git 操作工具和 CI 状态查询工具需要 Skill 规定检查顺序——先查依赖锁定文件再查构建产物最后看 Git 提交记录。两者是配合关系不是替代关系。我现在做的复杂 skill 基本都是“Skill 定流程 MCP 给工具”的组合。而普通 prompt 呢它就是一次性的口头交代。Skill 和普通 prompt 的差别我用一个对照表总结一下维度普通 promptSkill触发方式用户每次手动输入模型根据描述自动加载可复用性复制粘贴容易漏改文件化版本可控可携带资源很难附带脚本可包含脚本、示例、数据适合场景一次性任务高频、标准化、有规范约束的任务从这个表能看出来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 上遇到一个提示claudes 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_URLhttp://localhost:1234/v1 export ANTHROPIC_API_KEYlocal-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-labelimg是否有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 的生态希望这篇记录能给你一些可复用的经验。