前言

一个团队的真实困境

我之前观察过一个五人前端团队。他们的代码评审有个固定流程：每个 PR 都要至少两个人 review，按团队规范走一遍。规范文档放在 Confluence 上，写得很认真，二十几页。

跑了半年之后，问题暴露出来了。

老张每次都在评论里写”useEffect 缺依赖数组”。这句话他写了一百多遍，因为团队里有人就是会忘。小王是新来的，他每次都漏掉 XSS 检查，不是不知道，是没养成肌肉记忆。Leader 出于无奈，把 review checklist 打印出来贴在工位上，第三天就被人摘了。

文档不是没用，是没有执行机制。它躺在 Confluence 上，没有谁的 IDE 会自动加载它，没有谁的 CI 会强制校验它，没有谁会在每次写代码前先翻一遍。规范的执行完全依赖”人类记得”，而人类的记忆力，是这套体系里最脆弱的一环。

这就是 AI Skill 想解决的问题。

Skill 是一种把”知识 + 执行规则”打包成 AI 能理解的模块的方式。形式很简单——一个 SKILL.md 文件，里面写清楚这个能力解决什么问题、什么时候触发、按什么步骤做。Claude Code 把这个文件加载进来之后，AI 在合适的场景下会自动按里面的规则工作。

你可以把它想成”会被实际执行的文档”。

回到那个五人团队的例子——如果他们把 review 规范写成一个 Skill，放到项目的 .claude/skills/code-review/SKILL.md，结果会怎样？

这听起来像理想化的描述。书里要做的，是把这个理想拆成具体的工程实践。

写给三类人：

第一类：你已经在用 Claude Code 或类似的 AI 编程工具，知道它能完成日常任务，但还没想过用 Skill 来固化你团队的最佳实践。这本书会从认知层面带你重新理解 AI 协作的可能性。

第二类：你想构建一个团队级的 AI 能力体系。你不只想让 AI 帮你写代码，还想让它按你的方式写、按你团队的规范审、按你公司的安全策略部署。这本书会从工程层面给你一套可落地的方法论。

第三类：你想把领域知识封装成 AI 模块对外发布。Skill 在某种意义上是 AI 时代的”开源包”——用别人的 Skill 复用别人的工程经验。这本书会从设计层面教你怎么写出别人愿意装、装上之后真好用的 Skill。

不需要机器学习背景。需要的是：熟悉一门主流编程语言、用过 AI 编程工具、对工程化和团队协作有自己的看法。

全书围绕一个真实案例展开：把”代码评审”这件事，从一份死文档，一步步打磨成一个生产级的 Skill。每章对应一个版本的演进，仓库里的 skills/code-review-snapshots/ 保留了每个阶段的完整代码。

六个部分按”认知 → 创造 → 协作 → 评估 → 治理 → 实战”的顺序展开：

第一部分认知篇——理解 Skill 是什么、为什么这种形态可行、它和 Prompt、Agent、Plugin 的区别在哪。如果你对 Skill 还停留在”听过没用过”的阶段，从这里开始。

第二部分创造篇——从最小可用的 10 行 SKILL.md 开始，一步步加上结构化输出、动态上下文、外置知识、插件化规则。这部分是全书的核心，对应案例的 v1 到 v5。

第三部分协作篇——Skill 在团队里怎么共享、怎么版本管理、怎么避免互相冲突。这部分讲的是工程化，对个人开发者可以略读。

第四部分评估篇——一个 Skill 好不好用，凭直觉判断不够。这部分介绍 eval 的方法论，让 Skill 的质量可量化。

第五部分治理篇——大规模使用 Skill 之后会出现的问题：权限、审计、安全边界、回滚机制。属于”做大之后才会遇到”的话题，前期可跳过。

第六部分实战篇——把前五部分的内容综合应用到几个完整的场景：前端项目的全流程 review、后端 API 的安全审计、文档生成 Skill。

附录里有 5 分钟快速入门、常见模式速查、跟 Claude Code 官方 skill-creator 的对照表。

Skill 这个领域还在快速演进，本书基于的 Claude Code 版本和 SDK 接口可能在书出版后已经更新。原理不会变——一个 AI 能理解的可执行知识包，这件事的本质是稳定的。具体 API 的差异请以官方文档为准，仓库会跟进维护。

写 Skill 跟写代码不太一样。代码追求严谨、消除歧义、把每种边界情况都列清楚。Skill 追求的是”让 AI 理解为什么”——很多时候，加上一段解释为什么这样做的话，比写 50 条 MUST 都管用。这件事书里会反复出现，因为它是这个领域最反直觉、也最重要的一条经验。

往下读，先从那个五人团队的故事开始。