11个顶级Claude Code Skills实战指南：从代码审查到发布的全流程提效

我最早接触 Claude Code 的时候，真没把它当回事。那时候的感觉是：这玩意儿是个很会写代码的对话机器人，你给它一个需求，它能噼里啪啦生成一大片代码，但你也得花大量时间教它各种项目约定、代码风格、边界条件。后来我意识到，问题的根源不在模型能力，而在上下文——Claude Code 默认状态下就像一个刚入职的天才程序员，能力很强但没有岗位说明书。

Skills 就是这份岗位说明书。把技能文件放进.claude/skills/目录，Claude 在遇到对应场景时会先加载这套标准化作业流程，再动手干活。一次配置，反复生效，整个使用体验完全不一样了。这篇文章我想和你分享我实际用下来、反复对比后选出的 11 个顶级 Claude Code Skills，每一个都交代清楚它解决什么问题、怎么用、有什么坑。

1. 先别急着装：搞清楚 Skill 解决什么问题，你才知道为什么要有这11个

我刚接触 Skills 这个概念时，第一反应是“这不就是提示词嘛”。相信很多人也这样想过。但实际用下来，Skill 和普通提示词有着本质区别，理解这一点是正确选型的前提。

1.1 Skill 是结构化的“岗位说明书”，不是一句话吩咐

普通提示词是一次性的口头交代：“帮我按公司规范审查这段代码”。Skill 则是把这份交代变成一份长期有效的标准作业程序：它包含了触发条件、执行步骤、输出格式、模板、注意事项、甚至附带脚本和数据文件。

一个标准的 Skill 是一个独立目录，目录里必须有一个SKILL.md文件。文件头部用 YAML 写上技能名称和描述，正文部分就是让 Claude 按什么流程做事。比如我给自己写的一个代码审查技能，正文里会明确写：先看变更范围，再按逻辑错误、并发问题、安全风险、可维护性四个维度依次检查，最后按模板输出问题清单和修改建议。这一整套流程不是临场发挥，而是我多年做代码评审的经验沉淀。

你可以把 Claude 想象成一个外包团队。普通提示词是“你们看着办”，Skill 是“这是我们的操作手册，按这个来”。效果天差地别。

1.2 Skills 的触发逻辑：按需加载，不动声色

Claude Code 对技能的使用不是“全量塞进上下文”，而是按需加载。它的工作方式是这样的：当你提出一个任务，模型会根据 Skill 文件中的“描述”字段判断当前任务是否需要某个技能，需要时再把完整技能文档注入上下文。这种设计非常聪明——如果五十个技能全塞进上下文，上下文窗口早爆了，模型也没法聚焦。

除了自动触发，你也可以通过斜杠命令手动选择技能。比如输入/skills，Claude Code 会列出当前环境可用的技能清单，你直接挑一个用。这种方式在明确知道要干嘛的时候更可控。还有一种特殊情况：某些 Skill 被设计成在特定工具调用时才触发，比如 MCP 工具包里的技能，这种通常和外部服务绑定。

1.3 我筛选这11个技能时的标准

社区里能搜到的 Skills 数量已经非常庞大了，光 GitHub 上以 Claude Skills 为关键词的项目就有十几个 star 很高的仓库，更别提各种分散在各处的个人技能。我选技能只用五个标准：

• 增量价值大于零：不是把 Claude Code 本身就能做的事换个马甲，而是真正补充了额外的方法论或流程。
• 通用性够强：不绑定某一个人的私有工作流，换个项目、换个团队也能用。
• 维护状态良好：有更新记录，issues 有人回复，而不是一个发布后就没动静的死项目。
• 复杂度和收益成正比：有意义的技能一定会有一些复杂，但这种复杂能换来明显的产出质量提升。
• 可组合性强：技能与技能之间能协同作战，而不是互相打架。

拿这五条标准筛下来，我印象里实际试过的技能有好几十个，最后持续留在我的工作流里、让我愿意反复推荐的就是下面这 11 个。

2. 11个顶级 Claude Code Skills 全景表

在逐个拆解之前，先把全景表放在这里。后面每一个我都会展开细讲，但如果你时间有限，看这张表就能建立基本认知。

表里这 11 个技能，前三个属于“代码质量三件套”，是每天写代码都在用；第四个是调试杀手锏；第五和第六是动脑型技能，防止你写出一堆没法维护的代码和表结构；第七和第八解决的是日常高频但琐碎的基建操作；最后三个则是很多人会忽略但在关键时刻非常有用的“边缘技能”。下面我按照这个逻辑展开。

3. 代码质量三件套：审查、单测、重构为什么排在榜单最前面

代码审查、单元测试、重构，这三个动作是保证代码质量的三大支柱。把它们做成 Skills 的价值在于，很多团队其实有这套流程，但没有沉淀成方法论，每次都是靠人凭经验和心情执行。Skill 把这套流程固定下来，等于团队里多了一个永远保持同一标准的资深评审人。

3.1 Code Review 技能：让 Claude 用“资深审查人”的眼光读 PR

代码审查技能是我每天使用频率最高的一个，没有之一。写完全部改动之后，我不会马上提交，而是先把 diff 扔给 Claude Code，让它以资深代码评审人的角度做一轮完整的审查。

这个技能的核心能力有几个层面。第一层是基础的代码规范检查，比如命名、格式、明显的反模式。第二层是逻辑正确性分析，它会沿着代码路径推演，看有没有边界条件没处理、异常路径漏掉的。第三层是我更看重的：并发与安全分析。我自己写代码时经常陷入惯性，写完功能就自动忽略了竞态条件、空指针、数据竞争这些问题，但代码审查技能会专门过一遍这些维度。

在实践里，我用它抓出过一个非常隐蔽的问题。当时我们有个订单状态流转的服务，我在代码里写了一个乐观锁更新逻辑，自测时一切正常，但技能在审查时指出：在并发请求同时到达的场景下，我的修改和另一个服务的回调存在更新覆盖风险。要不是它说出来，这个问题上线后大概率会成为偶现的线上故障。

想让代码审查技能发挥最大作用，有一个关键配置：把团队的代码规范、基础库约定、以及历史踩坑记录写进技能文件里。我的代码审查技能里塞了一整份团队的 CONTRIBUTING 文档要点和几条容易触发的红线。这样它不是泛泛地审代码，而是按照我们团队的标准来审。

3.2 单元测试生成技能：让补测试不再像写作业

很多开发者不是不知道测试重要，而是觉得写测试很枯燥、很耗时。单元测试生成技能就是解决这个心理门槛的。它不只是一个“生成测试代码”的脚本，而是一套完整的测试策略助手。

它的工作流程大概是这样的：你先告诉它要对哪个模块生成测试，它会先阅读目标代码，梳理函数出入口、分支条件和异常路径，然后按照项目里已有的测试风格生成测试代码。这一点特别重要——代码风格统一的测试比花样百出的测试更值得维护。我见过很多 AI 生成的测试代码，花里胡哨但风格完全不一致，review 成本极高，反而没人想合并。

用了一段时间之后，我对它的边界有了清晰认识：它擅长的是分支覆盖、边界值验证、异常路径覆盖这类“穷举型”测试。但它不能替代你思考业务语义。比如一个“计算订单总价”的函数，它能生成价格正负、折扣叠加、税费计算这些分支的测试，但它不知道业务上“折扣不能低于成本价”这条隐含规则。所以我每次生成完测试，都会让它补一个“业务规则覆盖”检查，把这类骨架外的测试手动补上。

如果它生成的测试 mock 过度，导致测试变成摆设，别急着改代码，先检查技能的描述里有没有约束测试风格。我在技能里明确写了一行规则：尽量使用项目已有的测试基础设施和 mock 模式，不要引入新的测试框架。这一条改完，生成的测试质量直接上了一个台阶。

3.3 重构与坏味道扫描技能：技术债的“体检报告”

重构技能最爽的用法不是“帮我重构这段代码”，而是作为技术债的体检工具。以前我面对一个老项目，想重构但不知道从哪里下手，靠肉眼扫一遍代码，效率极低。有了重构与坏味道扫描技能之后，我会先让它做一次全量扫描，输出一份“坏味道报告”。

报告会按风险等级排列问题：哪些是重复代码块，哪些是过长函数，哪些模块间耦合严重，哪些类承担了太多职责。拿到报告后再决定哪些值得动、哪些不值得动。为什么要有这层筛选？因为重构不是把代码全改一遍就完事，好的重构是精准的、有目的的。无脑重构只会把稳定运行的老代码改出一堆回归 bug。

有一次我接手一个支付模块，这个模块历史很长，前后经过十几个人之手，代码风格极其混乱。我不是直接上手改，而是先让重构技能生成报告，然后挑出报告中标记为“高风险高收益”的部分，也就是影响面虽大但问题很严重的模块，提交方案给团队评审后，再分批重写。整个过程花了三天，但没有任何线上事故。

关于这个技能我有一个重要的心得：不要让它一次重构太大范围。Claude Code 处理代码的能力很强，但大范围重构时上下文容易丢失，改到后面它可能已经忘了前面改了什么。我的习惯是锁定单个文件或单个模块，重构完立即跑测试，确认无误再继续下一个。

4. 调试别靠猜：日志追踪类 Skill 的完整使用链路

Debug 是开发日常里最消耗精力的动作，也是我强烈建议用 Skill 固定下来的场景。以前我遇到线上 bug 的处理方式是：看报错堆栈，猜原因，加一堆日志，重新部署，看日志再猜。这种试错方式效率低，而且很容易把现场破坏掉。日志追踪调试技能改变了我处理问题的整个链路。

这个技能的核心思想是建立一套有章法的排查流程，而不是让 Claude 凭空猜答案。我平时的完整链路长这样。第一步，把完整的报错堆栈、相关代码片段、上下文信息都丢给它，它会根据堆栈位置迅速定位问题发生的代码路径。第二步，如果堆栈不足以定位根因，这个技能会设计一套日志插桩方案，告诉你应该在哪些函数入口、哪些边界条件处加日志。这一步的关键是“先设计再执行”，而不是盲目地满代码撒日志。第三步，拿到日志输出后，它会帮你做二分定位，把问题范围逐步缩小。

举一个我印象很深的例子。我们的服务有一个定时任务，每天凌晨会处理一批数据，但最近总是不定时地“卡住”，没有任何报错。我一开始完全没思路，后来我用调试技能走了一遍流程。它的日志插桩方案建议我重点监控三个位置：数据读取完成后的状态值、处理循环中间某个关键变量的变化、以及任务结束时释放资源的地方。部署后第二天早上，日志直接暴露出问题：在数据读取后，有个内存缓存的判断条件在特定数据量级下会短路，导致任务提前结束。报错堆栈完全看不到这个原因，不是靠猜能发现的。

日志追踪技能还有一个容易被忽略的价值：它会教你克制。以前我加日志是能加就加，生怕漏掉什么，结果日志输出量大到根本无法阅读。技能里内置的日志分级机制告诉我，只有达到“唯一标识一个错误路径”级别的信息才值得记，其他都是噪音。这一点改变了我的调试观念。

5. 架构规划与数据库迁移：两个“动脑”型技能的用法

代码写多了你会发现，真正值钱的不是码代码本身，而是写代码之前的方案设计。但很多人不愿意做设计，因为从零开始想架构是件伤脑筋的事。架构规划技能和数据库结构设计技能，就是强迫你在动工之前先动脑的两件工具。

5.1 Architecture Planner：先拆模块再写代码，减少返工

架构规划技能默认的工作方式是：在接收到开发任务之后，先不急着写实现，而是先产出架构设计文档。它会梳理需求的功能点、边界、依赖关系，然后给出模块划分、接口定义、数据流设计、异常处理策略。等你确认方案之后，再进入编码阶段。

一开始我不习惯这种“绕远路”的方式，觉得是在浪费时间。后来有一个需求让我彻底改观。当时要做一个新的权限系统，涉及用户、角色、资源、策略多个实体，逻辑复杂。如果直接上手写代码，大概率会边写边改、最后代码里全是临时补丁。我让架构规划技能先跑一遍，它输出了一份包含六张表、八组接口的设计方案。我拿着方案一看，发现一个关键路径设计有问题，在接口定义阶段就调整了，而不是等代码写一半再推翻。

这份技能还有一个隐藏价值，就是可以充当设计评审的“虚拟队友”。我把方案发给技能，它会从可扩展性、模块职责、调用关系几个维度挑毛病。虽说它挑出来的问题不是每条都对，但有一个人在你落笔之前帮你从多个角度打量方案，这种感觉很踏实。

5.2 数据库结构设计技能：表结构和迁移脚本的一次性正确

数据库设计是最容易出现“改了又改”的环节。一个字段类型定错了，后期数据量上来就得做数据清洗；一个索引漏加了，线上接口就直接超时。数据库结构设计技能帮我避免了大量这种低级失误。

具体使用方式是这样的：我告诉它业务场景和需要存储的数据对象，它会给出完整的建表语句、字段类型选择、索引建议、以及迁移脚本。如果表结构是改造现有的，它会先分析现有表的数据量、关联查询模式，然后给出兼容性改造方案，包括分批次迁移的策略。

有一回做用户画像系统的数据层升级，要把原来一张存储所有用户标签的宽表拆成若干张按标签维度分组的窄表。这个操作非常危险，因为涉及线上数据的读写切换。数据库设计技能给出的方案里，除了新的表结构，还包括一个双写过渡方案：新旧表并行写入一段时间，核对数据一致后再切换读取。如果没有这个设计，直接拆表，线上数据大概率丢一半。

和 MCP 数据库工具配合起来，这个技能会更顺手。MCP 连接真实数据库，提供当前表结构的实时信息，技能在此基础上做设计，就不会出现“设计出来的表结构明显不符合现有数据量”这类问题。

6. Git 与终端：高频操作中的两个基建技能

如果说上面这些技能影响的是代码质量的“天花板”，那 Git 工作流和终端命令这两个技能影响的就纯粹是每天的做事效率。它们不解决复杂逻辑，但能让你的日常操作更规范、更安全。

6.1 Git 工作流技能：提交规范与误操作的“后悔药”

Git 工作流技能解决两类问题。一类是规范性问题：提交信息怎么写、分支怎么命名、提交怎么拆分。另一类是救急性问题：误删分支怎么找回、提交信息写错了怎么改、多个提交怎么合并。

先说规范性。团队协作中，很难让每个人都老老实实写规范的提交信息，但有了技能之后，我会直接在提交前让 Claude 根据改动内容生成一份符合团队规范的提交信息。它不是简单把 diff 摘要填进去，而是会分析这次改动属于功能、修复、重构还是文档变化，然后按对应格式写出“做了什么、为什么做”的完整描述。提交历史的可读性大大提升，后续查问题也方便。

再说救急。有一次我执行git reset --hard把本地好几天的改动弄丢了，当时后背一凉。冷静下来后我想到 Git 工作流技能，它引导我用git reflog找回了我 reset 前的提交记录，然后通过 cherry-pick 把丢失的改动恢复了出来。没有这个技能的话，我可能得在那难受半天，然后去网上搜各种“找回 git 丢失提交”的文章。

6.2 终端命令技能：让安全成为一种默认设置

终端命令技能是一个很“轻”的技能，但使用频率极高。它的工作方式非常保守：当你把自然语言描述的目标交给他，比如“把 logs 目录下三天前的文件压缩归档”，它不会直接执行命令，而是先向你展示它准备执行的完整命令，并解释每一条命令的含义和潜在影响，等你确认后再执行。

这个设计很符合我的偏好。我见过很多 CLI 智能体一上来就是“我要执行某某命令”，一旦命令里面有 rm -rf 或者权限操作，你根本来不及反应就已经执行了。终端命令技能把“人机确认”作为强约束，等于在最关键的安全出口上加了一道闸。

这个技能在遇到权限场景时尤其好用。比如我经常需要查看一些服务占用的端口、调试 Docker 容器状态、检查某个进程的资源占用，以前这些命令我得一个个去查参数，现在直接用自然语言描述意图，它把完整命令给我并解释，我扫一眼确认执行就行。省下的时间积累下来非常可观。

7. 容易被忽视但价值不低的三个：结构图、发布准备、文档处理

榜单的最后三个技能，画结构图、准备发布、处理文档，都不是写代码的核心动作，但它们在项目生命周期里出现的频率一点也不低，而且是那种“没有它的时候你突然就手忙脚乱”的场景。

7.1 结构图生成技能：从代码库到可交付的架构图

写技术方案、向团队汇报、做交接文档，都绕不开画图。但我以前特别讨厌画架构图，用画图工具一点点拖框、连线，既花时间又容易漏关系。结构图生成技能解决的就是这个痛点。

它的工作模式是：你给它一段描述或者一个代码目录，它能自动生成 Mermaid 格式的图表代码，你再把它粘贴到 Markdown 文档里渲染就行。更厉害的是，如果直接给它一个代码仓库路径，它能先读懂模块间调用关系，然后画出一张依赖关系图。

我用这个技能的时候，最爱干的一件事是“画完再反向自查”。比如我给一个服务画时序图，画完之后对照实际代码路径走一遍，经常发现有些分支条件是我在设计时忽略的。结构图技能没把问题告诉我，但它画出来的图逼着我自己把逻辑理了一遍。这就是技能带来的隐性收益——它强迫你对自己的系统有完整认知。

7.2 发布准备技能：把发版从“惊险一跃”变成“按单执行”

发版是每个开发者压力最大的时刻之一。发布准备技能把这一整套流程变成了可检查、可追溯的标准动作。它的核心功能包括三个：根据 Git 提交记录生成变更日志、给出语义化版本升级建议、输出发布检查单。

最实用的是发布检查单。技能会根据最近一次发版到现在的所有提交，生成一份包含“需要执行的数据库迁移”“涉及的环境变量变化”“依赖变更”“需要回归的功能点”的文档。以前这些信息分散在多个提交里，要人工梳理一遍很容易漏掉，现在它一次性列出来，我只需要逐项确认。

我做过一次开源项目的维护，这个技能帮了我大忙。每次发版前我都要手工整理 changelog，给一堆 commit 归类成 feature、fix、docs、breaking change，实在痛苦。用技能之后，它能在几十秒内完成分类，而且分类的准确率比我手工整理高得多。

7.3 文档处理技能：PDF、DOCX、PPTX、XLSX 的手艺活

最后一个技能其实是 Anthropic 官方团队发布的一批文档处理类技能的综合体，包括 Docx、PDF、PPTX、XLSX 的处理能力。听起来和编程关系不大，但实际场景里经常遇到：客户发来一个 PDF 格式的需求文档，需要提取关键字段；要交一份技术方案的 Word 文档，需要按统一格式排版；要给老板做汇报，需要把代码里跑的数据指标整理成 PPT 和表格。

文档处理技能在这些场景中的价值不是“把文字抄出来”，而是能理解文档的结构和语义。比如让它把一个 PDF 合同里的关键条款提取成 JSON 结构，它能准确识别哪些是金额、哪些是期限、哪些是指标。让它根据一个数据 CSV 生成图表并嵌入 PPT，它能生成结构完整的演示文稿。

在安装这套官方技能时有个细节：它们是作为官方技能仓库提供的，里面每个技能都有独立的 SKILL.md 和辅助脚本。安装后注意控制技能的数量，别一口气全装上，否则无关技能会稀释上下文资源，拖慢处理速度。我只装了自己真正用得上的 PDF 和 PPTX 两个，其余按需再补。

8. SKILL.md 安装、验证与自定义的完整操作

前面讲了这么多技能，现在到动手环节。我猜已经有朋友迫不及待想去下载安装了。先别急，我先讲清楚安装机制和自定义方法，因为你迟早会不满足于现成的技能，想做点自己的版本。

8.1 技能目录结构与放置位置

Claude Code 的技能是“一个目录对应一个技能”的结构。目录名就是技能名，目录下必须有SKILL.md文件，还可以放参考文档、脚本、模板等附属文件。

• 用户级技能：放在~/.claude/skills/下，对所有项目生效。
• 项目级技能：放在项目根目录的.claude/skills/下，只对该项目生效。
• 代码库跟随型技能：放在仓库里跟着代码走，适合团队共享。

我个人的习惯是：通用的、方法论类的技能放用户级，和具体业务强相关的技能放项目级。比如“代码审查”这种跨项目通用的，放用户级；而“数据库结构设计”里融入了我们团队库表命名规范的，我就放项目级。

8.2 动手写一个最小技能

我们用一个简单的例子演示如何手写一个技能。假设我想做一个“需求拆解技能”，让 Claude 收到一个需求时先拆成任务清单。

mkdir -p ~/.claude/skills/task-breakdown cd ~/.claude/skills/task-breakdown touch SKILL.md

SKILL.md的内容结构如下：

--- name: task-breakdown description: 用于把模糊需求拆解为可执行的技术任务清单，适用于收到需求后开始编码之前。 --- # 需求拆解技能 你是一个拥有十年经验的资深技术负责人。当用户提出一个需求时，按照以下流程操作： 1. 先复述你对需求的理解，列出至少三个需要澄清的问题。 2. 根据需求拆解出技术任务，每个任务包含：任务描述、涉及模块、依赖关系、预计复杂度。 3. 输出结果必须使用 Markdown 表格，按依赖关系排列。 4. 如果需求中涉及数据模型变更，额外标注需要同步更新的迁移脚本和接口。 ## 输出格式 | 序号 | 任务 | 涉及模块 | 依赖 | 复杂度 | |------|------|---------|------|--------|

注意name和description是必填的，description尤其重要，因为模型靠它判断什么时候触发这个技能。描述要写得具体、包含触发场景关键词，但不能太长，否则模型在匹配时容易偏离。写完保存后，技能就生效了，在 Claude Code 中输入/skills就能看到新技能。

8.3 验证技能是否生效：三个调试技巧

我调试技能时常用三个方法。第一，直接输入/skills，看技能是否在列表里、描述是否是你想要的。第二，输入一个该技能应对应的任务，观察 Claude 的“思考过程”里是否出现该技能的加载动作。第三，临时在技能正文第一行加一句“如果成功加载本技能，请以'已加载需求拆解技能'开头”，这样可以从输出判断是否加载到位。

如果技能没被触发，大概率是description写得不准。太抽象的描述会让模型不知道何时启用，太具体的描述又会缩小适用场景。我的经验是，描述要写“在什么情况下用这个技能”，而不是“这个技能是什么”。比如“用于把模糊需求拆解为可执行的技术任务清单”就比“任务拆解”好得多。

9. 最近挺火但没进前11的几个方向：Superpowers、LaTeX、数学建模、图片生成

每次发技能相关的内容，总有人问我：你为什么不推荐 Superpowers？或者其他某个热门技能？这里我好好解释一下。

Superpowers 是一套社区知名度很高的技能集合，主打的是给 Claude Code 注入“元技能”级别的能力，比如深度思考、逐步推理、任务规划。它确实做得不错，而且安装非常方便，几乎是一键拉取。但对我来说，它不是不行，而是属于“更看个人风格”的工具。它对指令的理解方式会改变 Claude 的默认行为模式，和很多与具体业务绑定的技能搭配时容易发生指令冲突。如果你刚开始接触技能，用它做入门体验没问题，但如果你想长期稳定使用，我更建议按需定制自己的技能组合。

另外三个方向值得单列出来讲一下，因为它们代表了不同的技能品类。

LaTeX 排版技能，主要面向学术论文、技术报告等场景。它擅长把纯文本或 Markdown 内容转换成符合排版规范的 LaTeX 文档，还能处理数学公式、参考文献、图表环境。理工科背景、需要写 paper 或者现朋友，会比较喜欢这类技能。我认识一个做数学建模的朋友，他把整个团队的数据分析流程都做成了技能，从数据读取、特征工程到图表生成一步到位。

图片生成技能，在代码语境下的作用主要有两个：根据需求生成前端 UI 素材，以及根据系统结构生成示意图。这类技能通常依赖外部的图片生成模型，本质上是在 Claude Code 里包了一层外部能力。它有使用门槛，需要有对应的外部服务 key，但如果你有稳定的前端切图需求，它能省掉大量找素材的时间。

数学建模技能，则是把数学问题转化成可计算的代码。输入一个优化目标或者一组约束，它输出的是算法方案和可执行的数值计算代码。之所以没进前 11，是因为它的使用场景明显更垂直——你做个推荐系统的需求，用不上它；但如果你恰好要做一个调度优化类的问题，它就能派上大用场。

10. 一次真实的“技能组合拳”：从需求到上线的全过程演练

把单个技能讲清楚后，我想用一段完整的工作流把这些技能串起来，这样你能直观感受到它们怎么协同作战。

背景：我接到一个需求，要给后台系统加一个“批量导出订单报表”的功能，要求支持时间范围筛选、按字段排序、导出格式为 CSV，同时还要记录每次导出的操作日志。

拿到需求的第一件事，是让需求拆解技能跑一遍。它给我拆出了五个子任务：数据查询接口设计、CSV 导出实现、前端页面操作入口、操作日志记录、权限控制。每个子任务都标了依赖关系，我一看就知道先后顺序。

第二步，架构规划技能出手。它基于需求拆解的结果，给出了模块划分建议和接口定义。比如查询接口是走已有的报表服务还是新开一个，CSV 生成放前端还是后端，日志记录是同步还是异步。方案出来后，我和团队花十来分钟过了一遍，确认设计合理再开工。

第三步才进入编码阶段。服务端代码写好之后，我没有直接提交，而是先让代码审查技能跑一遍。它给我指出了两个问题：一个是 CSV 导出时对特殊字符的转义处理不完善，另一个是日志记录没有考虑失败回滚场景。这两个问题解决完，我才继续。

第四步，单元测试生成技能上场。我对导出模块生成了测试集，覆盖了空数据导出、超大数据量导出、特殊字符处理、权限不足拦截等场景。本地跑完后覆盖率从 0 直接拉到了 80% 以上，剩下的手工测试只补业务规则部分。

第五步，数据库结构设计技能检查操作日志表的设计。它建议把 operation_type、operator_id、query_params 这些字段加索引，因为后续查日志会按这些维度过滤。我当时不觉得这是问题，后来跑了一段时间才发现，日志表的数据量涨得飞快，没有索引的话查询会明显变慢。全靠它提前一步。

最后提交 PR 前，Git 工作流技能生成了规范的提交信息，把本次修改归类为功能新增，并附带简要描述。合并后发布准备技能生成了变更日志，提示这次发版新增了导入导出功能，需要同步更新接口文档。结构图技能还画了一张新的功能模块时序图，直接贴进了需求文档里。

从需求到上线的整个过程，十个技能几乎全都用上了。最明显的变化是，以前需要我反复提醒自己“别忘了测试”“别忘了日志”的那些事，现在变成了流程中自动发生的一环。

11. 使用 Skills 的教训：这些坑我替你们踩过了

技能用久了，多多少少也踩过一些坑。这里有四个典型的，分享出来帮大家避雷。

第一个坑是“贪多”。我最早装技能的时候，看到什么火装什么，一口气装了二十多个。结果 Claude 在匹配技能时反而出现选择困难——有些任务它能匹配到两三个技能，不知道怎么选，输出变得很不稳定。后来我做了减法，每个方向只保留一个最顺手的技能，效果立竿见影。技能的描述信息也是会占用上下文的，装了不用就是纯消耗。

第二个坑是“把技能写成超长提示词”。技能的价值在于沉淀标准和流程，而不是堆砌指令。如果一个技能有一万字，里面全是“你要仔细、你要全面、你不要遗漏”这类废话，那它和普通提示词没有任何区别。好的技能应该像一份可执行的清单：步骤清晰、模板明确、边界清楚。

第三个坑是忽略技能正文里的“护栏”。技能不是越强越好，而是要能安全地完成任务。我在设计技能时总会加几条硬性约束，比如“不得执行破坏性命令”“遇到不确定的需求必须向用户澄清”“输出代码必须通过静态检查”。这些护栏让技能在复杂场景下可预期，而不是自由发挥。

第四个坑是技能版本跟不上项目演进。项目结构发生变化后，技能里的描述可能已经过时，导致它给出的建议不适用。我现在的习惯是，每两周花一点时间审视一遍所有技能，看看有没有更新、有没有失效、有没有需要优化的地方。技能和代码一样，也需要维护。

最后说点真实的个人体会。技巧性的东西讲了这么多，我对 Skills 最大的感受是：它让我和 Claude Code 的关系从“雇佣了一个聪明但需要不断叮嘱的新人”变成了“合作一个有着稳定工作习惯的资深同事”。如果你刚从技能上尝到甜头，我给你一个最实在的建议：不要满足于安装别人做好的技能，去为自己最常做的事情写一个专属技能。它不需要多复杂，只要能把你的工作习惯固化下来，长期价值远超你下载的任何一个热门技能。