企业官网建设流程全解析

如果一年前有人告诉我，AI 编程助手能靠一套“技能包”变成 TypeScript 专项顾问，我大概率会觉得这是营销话术。直到我把 Matt Pocock 的 Superpowers Skills 装进 Claude Code，用真实项目跑了三个月，才明白为什么前端圈最近都在聊 Skills。不是普通 prompt，而是一整套可复用的工作协议——它对 AI 的行为约束力，比想象中强得多。这篇文章就围绕 Matt Pocock 这套 Skills，讲讲它到底是什么、怎么手动装进 Claude Code、实战怎么用，以及如何动手写一个自己的 Skills。

先说结论：这套东西最适合两类人。一类是天天跟 TypeScript、React 打交道的业务前端，想减少 AI 写出的“能跑但类型稀烂”的代码；另一类是团队里负责制定编码规范的人，想把沉淀出来的研发流程直接“喂”给 AI，而不是一遍遍复制粘贴上下文。如果你是纯后端或者只写脚本，可以看思路，但直接照搬意义不大。

1. 先搞懂：Matt Pocock 的 Skills 到底是什么

1.1 从 Claude Code 的 Skills 机制说起

Claude Code 里说的 Skills，简单理解就是一组有固定格式的 Markdown 指令文件。每个 Skill 包含两大部分：头部是元信息，写名字和描述；正文是具体的操作步骤、约束规则和示例。当你在对话里提出某个需求时，Claude Code 会根据描述自动判断该调用哪个 Skill，然后把 Skill 里的内容当成临时附加的系统指令来执行。

用生活化类比就是：你雇了一个助手，平时你说什么他做什么，但效果不稳定。现在你把“怎么泡茶”的标准流程写成一张卡片挂在墙上，助手看到“泡茶”两个字就会主动按卡片上的流程走，先烧水再洗杯，温度多少，闷几分钟。Skills 就是那张卡片，Claude Code 是那个会看卡片的助手。

这个机制最大的好处是复用。你今天总结出来的最佳实践，明天、后天、下个项目都能用。而且 Skills 可以放在项目目录下，跟着仓库走，新同事 Clone 代码后，AI 助手自动就具备团队规约。

1.2 Superpowers 这套 Skills 有什么不一样

Matt Pocock 是 TypeScript 教育的知名人物，做过 Total TypeScript 课程，自己也长期在开源项目里折腾类型系统。他做的这套 Superpowers Skills，并不是教你写一行行提示词，而是把一套完整的软件工程流程塞给了 Claude Code。

我最开始用的时候，只当它是普通的技能包，后来看了里面的内容才反应过来，真正值钱的是那几条“死规矩”。比如要求 AI 在任何修改前先写失败测试；比如重构时必须“小步前进”，每改完一个方法就停下来跑测试；比如处理 Git 操作时不能直接git push，而是要先查看状态、审查 diff、再提交。这些规则写的不是“你应该做什么”，而是“你必须做什么”，语气完全是工程规范而不是建议。

这正是很多 AI 编码项目翻车的根源：模型能力很强，但没有纪律。让它自由发挥，它能三分钟写出几百行代码，可惜一半是过度设计。Superpowers 这套东西相当于给模型套上了一条“安全带”，强制它按人类工程师的节奏工作。

2. 手动安装：从 GitHub 把 Skills 装进本地环境

2.1 安装前要准备的工具和目录

手动安装前，先确认三个基础件：Git、Node.js、Claude Code CLI。Git 用来拉取仓库，Node.js 是 Claude Code 的运行环境，CLI 本身就不多说了。注意版本别太旧，Node 建议 18 以上，Claude Code 保持在最新版，否则解析新格式的 Metadata 可能出问题。

然后要决定装在哪里。Claude Code 支持两种 Skills 位置：

• 用户级：放在~/.claude/skills下面，所有项目都能用，适合放通用技能。
• 项目级：放在当前项目的.claude/skills下面，只对这个仓库生效，适合放团队专属规范。

Matt Pocock 的 Superpowers 属于通用技能，我建议放在用户级。好处是以后开任何一个新项目，这些技能都能自动被加载，不用每个仓库都复制一遍。如果你只想在某个具体项目里试水，那放项目级更稳妥，不会污染其他工作目录。

2.2 克隆与放置的具体步骤

手动安装的流程不复杂，但有几个坑。我踩过最深的一个，是把整个仓库目录直接当成了 Skills 目录——结果 Claude Code 扫描不到任何技能，因为技能实际是在仓库里某个子文件夹中。

正确做法是这样：

1. 先把仓库克隆到一个临时目录。例如git clone https://github.com/mattpocock/superpowers.git，注意这里只是示例，实际地址要以你找到的仓库为准。
2. 进入仓库后，找到真正存放 Skills 的目录。不同仓库结构不同，可能是skills、superpowers或pull目录。用ls查看，看到一堆带名字的子文件夹，每个文件夹里都有SKILL.md，那这里就对了。
3. 把整个 Skills 目录复制到目标位置。如果是用户级，就执行cp -r ./对应目录 ~/.claude/skills/。如果目标位置还不存在，先mkdir -p ~/.claude/skills。
4. 复制完检查一下目录树，确保是~/.claude/skills/xxx/SKILL.md的层级。如果直接变成~/.claude/skills/skills/xxx/SKILL.md，Claude Code 可能认不出来，路径层级很敏感。

注意：不要只拷贝单文件。有些技能会引用同目录下的辅助文件或模板，只拿一个SKILL.md骑出去会导致技能运行到一半报错。

2.3 验证 Skills 是否被识别

装好之后别急着干活，先验证。最直接的办法是重新启动 Claude Code，让它的加载器重新扫描目录。启动后你可以输入一句类似“列出当前可用的 Skills”的指令，注意不是斜杠命令，而是自然语言询问。如果安装成功，它会把技能名和对应描述列出来。

我遇到过一种尴尬情况：技能列表里明明有，但让它执行时它还是按平时套路来。这时候检查一下当前项目目录是不是有另一个.claude/skills目录，项目级技能会覆盖用户级同名技能。还有可能是描述写得太模糊，AI 没判断出来该调用。这个需要检查每个SKILL.md的 description，看是否覆盖了你想要触发的场景。

3. 核心技能拆解：我常用的几个 Skill 与适用场景

3.1 测试先行（TDD）Skill 怎么用

Matt Pocock 的 TDD Skill 是我最常用的一个。过去我让 AI 写功能，它经常先写实现再补测试，甚至不写测试。装上这个 Skill 后，只要一句“用 TDD 方式给某个函数补全逻辑”，Claude Code 就会按固定流程走：先写一个失败的测试用例，跑一次确认失败；接着写最小实现让测试通过；最后回头审视代码，尝试重构。如果你自己没要求它写测试，但只要任务涉及代码修改，一些 Skill 会主动要求先列测试计划。

具体效果举个例子。我之前写过一个计算价格折扣的函数，考虑到会员等级和促销活动，逻辑分支很多。让 Claude Code 直接用 TDD 流程改，它第一步没写任何业务代码，而是先列出四个测试场景：普通会员、金卡会员、叠加活动、活动过期。确认这几个场景覆盖完整后，再开始写实现。整个过程，每轮修改都跑测试，明显比直接让它“给个函数”稳得多。

这个 Skill 的边界也很清晰：它只适用于函数级、逻辑型的改动。如果让 AI 改 UI 样式，用 TDD 就有点反应过度，毕竟视觉验证不靠单测。

3.2 类型安全重构 Skill 的实操要点

前端项目到了一定阶段，类型重构就像拆炸弹。改一个接口类型，组件传参跟着报错，连带把 store 也带崩。Matt Pocock 那套重构 Skill 特别强调“小步重构”和“保持行为不变”，这两条我太认可了。

实际操作时，我会让 AI 先扫描项目的类型配置，定位tsconfig.json的strict开关和当前类型错误数量。然后每次只处理一个模块，改完立刻跑类型检查tsc --noEmit。如果错误超过预期，立刻回滚，重新解读类型之间的关系。

有人觉得这样太慢，但重构追求的是安全，不是速度。我曾经让 AI 一次性改了十几个文件的类型，结果出现大量any和类型断言，表面错误清零，实际类型覆盖形同虚设。后来切到这个小步重构 Skill，每次改动控制在两三个文件内，最终错误数从八十多个降到个位数，过程中心态也稳。

3.3 Git 操作与代码审查 Skill 的用法

Superpowers 里的 Git 相关技能，刚开始我觉得有点 “管太宽”，用久了才发现它防住了好多手滑操作。简单说，它要求 Claude Code 在提交前必须先看git status和git diff，确认改动内容，生成符合规范的提交信息，然后经过你确认才执行提交。

有一回我让它处理一份需要拆分的改动，结果它把几个不相关的文件卷进了同一个提交。虽说现在有git reset能救，但万一已经 push 到远端就要和同事解释半天。用这套技能后，它会在提交信息里写出每个文件的改动原因，并提醒我检查是否有多余文件。这种“确认确认再确认”的工作流，非常适合几个项目同时进行的场景。

代码审查相关的技能也很有用。丢给它一个 diff，它能按类型安全、边界条件、可读性几个维度输出审查意见，而且每条意见都会指向具体行号。比直接让 AI“帮我 review 代码”要规范得多。

4. 自己动手写一个 Skills：从零到上手

4.1 Skills 文件的标准结构

官方没有把规则定死，但 Matt Pocock 这套是很好的模板。一个标准技能目录结构长这样：

.claude/ skills/ my-skill/ SKILL.md example.ts

核心文件是SKILL.md，开头用 YAML frontmatter 声明元信息。最简单版：

--- name: my-skill description: 当用户需要处理 XXX 场景时使用。包括 A、B、C 关键词…… --- # 技能正文 步骤、规则、示例……

name必须唯一，description是灵魂。Claude Code 判断什么时候调用技能，主要靠 description 和当前任务的语义匹配。很多自写技能不生效，根本不是格式问题，而是 description 写得太泛。

4.2 编写描述和指令的技巧

关于 description，我建议写成“触发条件 + 使用场景 + 排除条件”三段式。例如：

description: 当用户需要对 React 组件进行性能优化时使用，尤其是避免不必要的重渲染。如果只是修改样式或文案，不要使用本技能。

把“什么时候不用”也写进去，能显著减少误触发。我最早写的技能 description 只有一句“用于性能优化”，结果每次提性能两个字都得触发一遍，后来加上排除条件才算消停。

正文部分则要避免概念化。不要光写“确保代码质量高”，要写可操作步骤。比如：

1. 列出当前组件的 props、state、context 来源。
2. 找出每次渲染都会变化的对象和函数。
3. 判断是否需要用React.memo或useMemo，不要盲目使用。
4. 修改后运行npm run lint与npm run type-check。

定义验收标准也很有用。告诉模型“当以下条件全部满足时，任务才视为完成”。这样比让它自由发挥强得多。

4.3 让 Agent 真正“理解”你的 Skill：示例项目

假设我想写一个“生成表单校验规则”的 Skill。描述可以写成：

description: 根据表单字段定义生成 zod 校验规则，或为已有规则增加字段校验。仅适用于前端 TypeScript 项目。

正文里给出输入格式和输出格式，附带一个简单的示例。示例不能太长，但要完整。下面是个迷你示范：

## 输入示例 字段：email，类型：string，必填：是，格式：邮箱 ## 输出示例 z.object({ email: z.string().email('邮箱格式不正确'), })

然后写几条硬性规则：

• 所有错误消息必须使用中文。
• 必须导出最终的 schema，命名规范是表单名称 + Schema。
• 如果字段没有额外约束，不要生成多余的校验链。

这样写完，你可以用一个小测试工程验证：故意描述一个模糊需求，看模型是否调用了这个技能。多试几次后调整描述措辞，直到触发稳定。

5. 实战记录：用 Claude Code 完成一个前端类型错误修复

5.1 需求描述

我在维护一个 React + TypeScript 的中型项目，最近要增加一个“优惠券叠加使用”的功能。老代码里order对象的结构比较复杂，类型定义还是几年前的，里面一堆any。新需求要读取order.coupons，但在部分订单里这个字段是undefined，导致页面渲染时直接报 “Cannot read properties of undefined”。

需求本身不复杂，但这只动了老类型，很容易改一个地方炸一片。我打算用 Claude Code 配合 Matt Pocock 的类型重构技能来处理。

5.2 配合 Skills 的执行过程

启动 Claude Code 后，我先输入：“请用类型安全重构技能，修复order.coupons可能为 undefined 的问题，不要改变现有业务逻辑。”

AI 没有直接改代码，而是先给我输出一份分析日志，包括：

• order类型的定义文件位置。
• coupons字段在多少个组件里被使用。
• 当前是否有测试覆盖。
• 建议先把coupons定义为可选数组，再逐个访问点增加判空。

我非常意外的是，它接下来没有一上来就写代码，而是问我要不要先创建几个测试用例来锁定现有行为。这就是技能里的规则起了作用——步骤顺序被写死了，AI 想跳过都不行。

确认后，它先创建了两个测试：一个订单没有coupons字段，一个订单有多个优惠券且数量超过零。然后才开始修改类型定义。每次改完文件，都会跑tsc --noEmit和相关的单测，再进入下一个模块。

5.3 踩坑与结果复盘

中途出了一个插曲：有个组件原本直接访问order.coupons.length，类型改成可选后这里报错。AI 本能地想把order.coupons改成order.coupons || []，我看了下不对，因为那个组件要判断“用户是否使用了优惠券”，不是真的需要默认空数组。于是我在对话里纠正了一下，AI 马上调整方案，改成先if (!order.coupons) return null再渲染。

这个小插曲说明技能不是万能的。它能规定流程，但业务语义还是要人来把关。最终改动涉及 6 个文件，类型错误从 23 个降到 0，单测从 47 个增到 59 个，全部通过。整体耗时大约四十分钟，比我手工改快，也比我不加限制地让 AI 乱改安全得多。

6. 常见问题与排查技巧实录

6.1 Skills 不生效？查这五个地方

第一个检查SKILL.md文件是否存在于正确的目录层级，路径里不能多套一层文件夹。第二个检查description是否简练明确，过于模糊的技能很难被触发。第三个检查是不是存在同名覆盖，项目级技能优先于用户级。第四个检查当前会话是不是旧的，很多情况下重启 Claude Code 就会重新扫描技能。第五个检查有没有开启权限限制，如果你限制了 AI 读取文件系统，技能里的辅助文件自然读不到。

我过去遇到技能不生效，八成都是路径多套了一层，或者把整个 README 仓库复制进去了。建议装完就用find ~/.claude/skills -name "SKILL.md"看一下，能列出多少技能文件一目了然。

6.2 多个 Skills 冲突怎么办

问题往往是这样的：装了 Matt Pocock 的通用测试技能，又装了团队内部的测试规范技能，两边指令有冲突。比如通用技能要求先写测试，团队规范要求先评审测试计划。AI 有时会两个都参考，结果行为不可预测。

解决方法是合并或删减。我自己的原则是：团队规范技能优先级更高，就把 Matt 那套里涉及测试流程的部分抽出来，跟团队规范合并成一个新技能，删掉原技能。不要幻想 AI 能完美权衡，你替它权衡最省心。

6.3 实用资源配置建议

不同的 Skills 对上下文长度和权限的设置敏感度不同。TDD 类的技能会在循环里跑测试，消耗的 response 次数比较多，如果没有开启自动批准工具调用，你需要不停手动确认。建议在安全项目里把claude:allow-tools配置得宽松一点，比如允许执行npm test、tsc --noEmit，否则体验极其割裂。

另外，技能文件不要贪多。我见过有人一次装二十多个技能，AI 每轮都要在大堆描述里做匹配，很容易选错。最佳实践是个人目录只放最常用的五六个，项目目录放团队专属的两三个，保持精简。

7. 个人体会：Skills 的边界在哪里

我自己实际用了大半年下来，最大的体会就是：不要把 Skills 当成魔法棒。它的本质是“将优秀工作流固化给模型”，但前提是你已经知道什么流程是优秀的。Matt Pocock 这套 Superpowers 之所以好用，是因为他先花了很多年研究 TypeScript 和测试实践，然后把那些被验证过的经验变成规则。我们抄规则容易，抄背后的判断力很难。

另外一个小技巧，写自定义技能时不要追求覆盖所有场景。本来想一个技能搞定“代码生成 + 测试 + 重构 + 提交”，结果每个环节都做得浅。拆开成单个技能反而更灵活，AI 可以按需组合调用。

如果你刚开始尝试，建议先只装一个 TDD 技能，找一个不紧急的函数改一改，体验一下被节奏约束的感觉。那个过程会有点不适应——AI 突然不炫技了，但每一步都走得很稳。等你熟悉了这种工作方式，再慢慢扩展其他技能。这条路走通之后，你会发现团队多年沉淀的研发规范，终于有了一个可以随身携带的载体。