如果你想在一支技术团队里真正推广 AI 编程，可能最先遇到的瓶颈不是模型不够强，也不是工具不够多，而是“不知道怎么让每个人都稳定地用起来”。个人折腾 AI 辅助开发是一回事，整个团队形成统一打法是另一回事。近期看到 Matt Pocock 关于 AI Skills 的分享，里面提到的“7 步工作法”非常接地气，既讲清楚了 AI Skills 是什么，也给出了从个人试水到团队推广的完整路径。这篇文章就围绕这套方法论展开，结合 Claude 等工具的 AI Skills 实践，整理成一份可以直接参考的团队落地指南。
1. 为什么团队推广 AI 编程这么难
先聊一个很常见的场景：团队里总有那么一两个人，用 AI 写代码用得飞起，commit 速度明显变快，但是你把同一个工具推荐给其他人，对方用了一个下午就放弃了。问原因，回答五花八门——“提示词太难写”“它写的代码风格跟我不一样”“每次都要重复解释项目背景”“它给的方案不够深入，改了不如自己写”。
这些问题的本质其实是一致的：AI 工具的使用方式没有沉淀下来。个人用户可以靠肌肉记忆记住自己常用的提示词套路，但团队协作中每个人都在重新发明轮子，AI 的发挥水平自然参差不齐。
Matt Pocock 提出的解法，就是引入AI Skills（AI 技能）这个概念。它不是某个具体的提示词模板，而是一套将“高效使用 AI 的上下文、规则和流程”打包成文件、可在团队内复用的机制。你可以把它理解为：给 AI 写一份“岗位说明书”，告诉它你的项目背景、代码规范、常用命令、以及遇到某类任务时该按什么流程处理。
AI Skills 解决的是三个核心问题：
- 上下文复用：不再每次从头给 AI 解释项目是什么、用什么框架、目录结构如何。
- 行为约束：让 AI 的输出风格贴近团队规范，而不是每次碰运气。
- 知识沉淀：团队里某个人摸索出的高效用法，可以通过 AI Skill 文件快速传播给所有人。
当 AI Skills 在团队内形成了统一的标准，AI 编程的效率才不是“某几个人的特例”，而是“整个团队的基本盘”。
2. AI Skills 到底是什么
要理解 AI Skills，先得理解 Agent Skills 这个技术概念。2025 年 Claude 推出并开源了 Agent Skills，本质上是一套让 AI 通过“额外技能文件”获得专业能力的机制。它和传统的提示词工程最大的区别在于：技能文件不是几行 prompt，而是一整套结构化指令包，通常由SKILL.md主文件配合示例、参考文档、脚本等目录组成。
一个标准的 AI Skill 文件结构大致如下：
my-skill/ ├── SKILL.md # 技能主文件，包含说明、规则和流程 ├── references/ # 参考文档目录 │ ├── code-style.md │ └── project-architecture.md └── examples/ # 示例目录 ├── good-example.ts └── bad-example.ts其中SKILL.md是最核心的文件，它使用 Markdown 编写，内容通常包含：
- 技能的名称、用途和适用场景。
- 使用该技能时需要遵守的规则。
- 处理任务时的具体步骤或流程。
- 输入输出格式要求。
- 示例和反例。
Matt Pocock 本人是 TypeScript 和 React 领域的知名开发者，他做的很多 AI Skills 尝试都是围绕前端工程化展开的。比如在 Total TypeScript 的教学体系里，他通过 AI Skill 把授课风格、代码规范、练习难度标准告诉 AI，让 AI 生成的教学内容能够自动匹配他的要求。
下面是一个非常精简的 SKILL.md 示例，用来展示它的基本写法：
--- name: frontend-review description: 前端代码审查技能，适用于 React + TypeScript 项目 --- # 前端代码审查技能 ## 适用场景 - Pull Request 提交前的代码自查 - 对他人代码进行 review 并提供改进建议 ## 审查规则 1. 优先检查 TypeScript 类型是否正确，禁止使用 `any`。 2. React 组件必须使用函数式组件写法，禁止使用 class 组件。 3. 样式优先使用 Tailwind CSS，不要引入新的 CSS 文件。 4. 逻辑必须拆分到自定义 Hook 中，禁止把复杂逻辑写在 JSX 里。 5. 每个函数必须标注返回值类型。 ## 输出要求 - 按“严重问题 / 建议优化 / 风格提示”三档分类输出。 - 每个问题必须附带对应的代码行号和修复示例。可以看到，这不是一句“请帮我 review 代码”的提示词，而是把团队规范、判断标准、输出格式全部固化成了文件。任何人拿到这个 Skill 文件，都能让 AI 按统一标准执行任务。
3. 认知升级：从“会写代码”到“会写 AI Skills”
Matt 的 7 步工作法中，最先强调的不是技术细节，而是一个观念转变：AI 时代的核心竞争力，从“会不会写代码”变成了“会不会定义任务”。
传统的编程工作流里，人类负责把大任务拆成函数、模块、系统，然后逐行实现。AI 编程的工作流里，人类更多负责描述意图、划定边界、校验结果。这时候“提示词写得好不好”就不再是文字表达能力的问题，而是任务拆解能力和规范制定能力的问题。
这就是 AI Skills 的深层价值——它把“人类如何定义任务”这件事从随意发挥变成了工程化流程。团队里不要求每个人都成为提示词专家，只需要有人把大家公认的高效做法写成 Skill 文件，其他人拿来即用。
Matt 还把 AI 编程的发展分成了几个阶段，帮助团队理解自己处在哪个位置：
| 阶段 | 特征 | 团队状态 |
|---|---|---|
| 探索期 | 个人尝试 AI 工具，提示词零散 | 效率提升不稳定，经验无法传播 |
| 模板期 | 团队整理了一批提示词模板 | 有一定复用，但场景覆盖不全 |
| 技能期 | 团队建立 AI Skills 体系，按场景打包 | 上下文、规则、流程统一沉淀 |
| 平台期 | AI Skills 结合自动化工具和 Agent 流程 | 形成团队级 AI 工作流 |
很多团队其实还停留在第一阶段，而 Matt 这套工作法要做的就是帮团队尽快走到第三阶段和第四阶段。
4. 7 步工作法完整拆解
下面进入本文的重点，Matt 提出的让整个团队用上 AI Skills 的 7 步工作法。我会用自己的理解重新梳理，并补充对应的实操示例和落地建议。
4.1 第一步：盘点团队里的“黄金提示词”
任何团队里，总有那么几个用 AI 特别顺手的人。Matt 建议的第一步，不是急着写什么规范文档，而是先做一轮内部调研，把团队里已经验证有效的“黄金提示词”收集起来。
所谓“黄金提示词”，要满足三个条件：
- 高频使用：写代码、写测试、改 bug、做 review 等每周都会遇到的任务。
- 效果稳定：同一个提示词在不同人、不同代码库上都能产出可用的结果。
- 可复制可传播：脱离原始作者后，其他人照着用也能理解。
收集的方式可以采用一个简单的模板，让团队成员提交自己的高效提示词：
| 字段 | 填写说明 | 示例 |
|---|---|---|
| 任务类型 | 这个提示词解决什么问题 | 生成 React 组件的单元测试 |
| 原始提示词 | 你实际输入给 AI 的文本 | 请为这个组件编写 Jest 测试，覆盖正常、异常和边界情况 |
| 使用的模型/工具 | Claude / GPT / Copilot 等 | Claude 3.5 Sonnet |
| 效果描述 | 输出结果是否稳定、需要多少轮修正 | 生成质量较高，只需微调断言 |
| 适用项目 | 在哪些项目上验证过 | 公司后台管理系统、电商前端 |
这一步的目的，是让团队意识到：我们不是没有 AI 经验，而是这些经验没有被系统化。盘点完成后，通常会有一批重复度很高的任务类型浮出水面，比如“生成单元测试”“解释这段代码的逻辑”“按照规范做 Code Review”。这些高频任务就是第一批 AI Skill 的最佳候选。
4.2 第二步：选定试点场景，聚焦一到两个高频任务
很多团队推广 AI 编程失败，是因为一开始就想覆盖所有场景。Matt 的方法恰恰相反：不要全面铺开，选一到两个高频、高价值、低风险的任务作为试点。
选择试点场景可以参考这三个标准：
- 频率高：团队每周都会遇到，用来验证 Skill 的复用价值。
- 价值显性：完成后可以量化比较，比如“从 30 分钟缩短到 10 分钟”。
- 容错性好：即使 AI 生成结果不完美，也不会直接影响生产环境。
以我接触过的团队为例，比较适合做 AI Skills 试点的任务包括：
- 为新写的接口生成单元测试。
- 生成符合项目风格的 TypeScript 类型定义。
- 自动生成数据库表结构对应的实体类。
- 根据 Git diff 生成 PR 描述和变更说明。
- 代码提交前的规范检查（未使用的变量、魔法数字、命名规范等）。
其中，“根据 Git diff 生成 PR 描述”是非常好的入门场景，因为它风险低、格式固定、边界清晰。下面就是一个能直接用的 SKILL.md 示例，最简版可以做 5 分钟上手演示。
4.3 第三步：为试点任务编写第一版 AI Skill
选定试点任务后，就要开始写第一个 AI Skill 文件了。这一步的技术含量并不高，关键是要遵循“先最小可用、再持续迭代”的原则，不要一上来就追求大而全。
写 AI Skill 的核心原则：
- 专注单一场景：一个 Skill 只解决一类任务，不要试图包含所有知识。
- 规则明确具体：不要写“请生成高质量代码”这种模糊指令，要写“函数必须显式标注返回值类型”这样的可检查规则。
- 附上示例：一个好的示例胜过十行规则描述，因为 AI 能从示例中推断你的偏好。
- 从问题出发生成：把团队真实遇到的高频问题作为 Skill 的能力范围。
以“生成 PR 描述”为例，第一版 SKILL.md 可以这样写：
--- name: pr-description description: 根据 Git 变更记录生成规范的 PR 描述 --- # PR 描述生成技能 ## 适用场景 - 开发者提交 PR 前，需要快速生成描述 - Code Review 时帮助 reviewer 快速了解变更范围 ## 输入要求 - 需要提供 `git diff` 或变更文件列表 - 如果有相关需求单号或 commit message，一并提供 ## 生成规则 1. 描述使用简体中文，控制在 200 字以内。 2. 必须包含三个部分：变更背景、主要改动、影响范围。 3. 变更背景需要从代码变更中推断业务意图，不要编造需求内容。 4. 主要改动按模块分类列出，不要逐文件罗列。 5. 影响范围需要标注可能受影响的现有功能。 6. 如果存在破坏性变更（如接口签名修改、数据库表结构变更），必须在描述中显著标注。 ## 输出模板 ```markdown ## 变更背景 （1-2 句说明本次变更要解决的问题） ## 主要改动 - 模块A：具体改动说明 - 模块B：具体改动说明 ## 影响范围 - 受影响的功能和模块 ## 注意事项 - 破坏性变更或需要关注的风险点写完之后，可以先用一个真实的 git diff 做测试，看看 AI 的输出是否符合预期。第一版效果不完美很正常，重点是把流程先跑通。 ### 4.4 第四步：创建团队共享的 AI Skills 仓库 当第一个 Skill 验证有效后，就需要考虑存放和分发的问题了。Matt 建议的做法是：**为团队创建一个独立的 AI Skills 仓库，按目录组织，配合版本管理和变更记录**。 推荐的项目结构如下：ai-skills/ ├── README.md ├── skills/ │ ├── pr-description/ │ │ ├── SKILL.md │ │ └── examples/ │ ├── test-generation/ │ │ ├── SKILL.md │ │ └── examples/ │ └── code-review/ │ ├── SKILL.md │ └── references/ ├── templates/ │ └── skill-template.md └── docs/ └── usage-guide.md
在这个仓库的管理上，有几点工程经验值得分享： **命名规范**：Skill 目录名统一使用 `kebab-case`（短横线分隔），避免使用带空格的目录名，方便在命令行直接引用。 **版本记录**：在 SKILL.md 的 frontmatter 中增加 `version` 字段，每次修改后递增。更新 Skill 时，要在 README 或 CHANGELOG 中记录变更内容，便于团队了解最新版本的变化。 **分级权限**：建议设置一个 AI Skill 的“owner”角色，负责审核合入、统一格式、处理冲突。否则很容易出现同一个 Skill 出现三四个风格不同的分支版本。 **安全边界**：AI Skills 可能会包含内部代码规范、项目架构信息，仓库权限要控制好。如果项目涉及敏感信息，需要对 Skill 文件做脱敏处理。 在实际使用中，团队的 AI 工具（比如支持 Claude Code 的环境）可以通过命令行参数直接指定要加载的 Skills 目录。示例命令大致如下： ```bash # 将团队 AI Skills 仓库克隆到本地 git clone git@your-server:ai/ai-skills.git ~/.team-ai-skills # 在支持 Agent Skills 的工具中通过环境变量指定技能目录 export CLAUDE_SKILLS_DIR="$HOME/.team-ai-skills/skills"需要说明的是，不同工具加载 Skills 的方式并不完全一致，具体参数需要参考你使用的工具文档，这里重点演示的是“团队统一维护、个人按需加载”的思路。
4.5 第五步：建立“组合式” Skills，应对复杂任务
单一 Skill 的能力始终有限。当团队积累到一定数量的基础 Skill 后，就可以考虑将它们组合起来，应对更复杂的任务。
Matt 在演示中经常提到一个观点：AI Skills 应该像乐高积木一样，可以自由组合。比如团队可以建立一个“新功能开发”的 Skill，它内部编排多个子技能：
开发新功能 ├── 需求理解 Skill：拆分用户故事，整理功能清单 ├── 代码规范 Skill：约束项目结构和代码风格 ├── 测试生成 Skill：为每个功能点生成对应的单元测试 └── 文档生成 Skill：更新 README 和接口文档这种组合式 Skill 的核心，是定义子技能之间的调用顺序和数据流转。在 SKILL.md 里，可以通过明确的流程描述来实现：
## 执行流程 1. 调用“需求理解”技能，输出功能拆解清单。 2. 基于功能清单，调用“代码生成”技能生成核心代码。 3. 为每个新增函数调用“测试生成”技能，产出单元测试。 4. 最后调用“文档生成”技能，更新项目文档。 5. 输出所有产物的文件路径，并以任务清单形式列出待人工确认项。这种设计方式的优势是：
- 基础 Skill 可以被多个组合 Skill 复用。
- 新增场景时，不需要从零编写，更多是重新编排。
- AI 处理复杂任务时，步骤更清晰，不会遗漏关键环节。
4.6 第六步：低门槛推广，让团队“用起来再说”
AI Skills 写好了，仓库建好了，接下来最难的一步是：让团队真正用起来。Matt 在这个问题上强调了“低门槛起步”和“降低迁移成本”的原则。
推广时一定要避免的误区是：要求团队成员先读完整套文档、参加完培训、理解所有原理后再开始使用。正确做法是，先让 Skill 的最基本用法变得足够简单，最好简单到“复制一条命令就能用”。
一个有效的推广路径是：
第一周：个人尝鲜。挑选团队里对 AI 工具接受度最高的 3 到 5 个人，让他们在低风险任务中试用第一批 Skill，收集反馈。
第二周：结对扩散。让已经用得顺手的成员主动帮其他成员配置环境，手把手演示一个完整个流程。这个阶段的关键是解决“最后一公里”的环境问题，比如工具版本差异、网络配置、仓库权限等。
第三周：纳入流程。将 AI Skill 的使用嵌入到团队现有的开发流程中，比如在 PR 模板中增加一栏“由 AI 生成的变更摘要”，或者在代码提交流程中增加一条“运行 pr-description 技能生成描述”的检查项。
第四周：反馈迭代。收集使用过程中的问题，以周会的形式快速迭代 Skill 文件。
这个过程中，Matt 特别强调了一个点：不要追求一次完美，要让团队看到即时收益。哪怕一个 Skill 只能帮成员节省 5 分钟，也值得推广。
4.7 第七步：度量效果，持续迭代
最后一步是建立效果度量机制。没有度量，AI Skill 就会慢慢变成一堆没人维护的僵尸文件。
推荐的度量维度包括：
| 度量维度 | 度量方式 | 参考目标 |
|---|---|---|
| 使用覆盖率 | 团队中每周至少使用一次 AI Skill 的人数占比 | 4 周内达到 80% |
| 任务提效 | 对比使用 Skill 前后完成同一类任务的耗时 | 核心任务缩短 30% 以上 |
| 输出质量 | AI 生成的代码/文档被人工修改的比例 | 二次修改率不断下降 |
| Skill 维护活跃度 | 每周 Skill 文件的更新次数、新增数量 | 保持持续迭代状态 |
同时要建立一个反馈渠道。最简单的方式是在 AI Skills 仓库中建一个feedback/目录，每个 Skill 下放一个issues.md文件，成员在使用过程中可以直接记录问题：
# pr-description 使用反馈 ## 2025-06-01 | 问题：描述中缺少数据库变更的标注 - 场景：修改了 users 表的索引 - 期望：自动识别 schema 变更并在“影响范围”中标注 - 建议：在输入要求中增加“可选提供 sql migration 文件路径”迭代的节奏建议是：每周花 30 分钟处理反馈、合并更新、发布新版本。当 AI Skills 进入“使用-反馈-迭代”的正循环后，团队整体的 AI 编程能力就会持续提升。
5. 结合热点：AI Skills 在编程场景中的最佳实践
Matt 的方法虽然面向团队推广，但对个人开发者同样有很高参考价值。结合近期社区对 AI Skills 的讨论，这里再补充几个编程场景中的高频实践。
5.1 场景一：让 AI 按照你的代码风格工作
团队里经常出现一个问题：AI 生成的代码风格和自己的完全不一致。不用愁，可以把代码风格固化成 Skill 文件，甚至可以把项目里几个代表性文件作为示例放入 Skill 的examples/目录。
--- name: code-style description: 按本项目代码风格生成 TypeScript 代码 --- # 代码风格约束 ## 结构规范 - 文件内顺序：import → 类型定义 → 工具函数 → 主组件/主函数 → 导出。 - 函数定义优先使用 `function` 声明，避免过度使用箭头函数。 - 组件 `props` 优先使用 interface，而不是 type。 ## 命名规范 - 组件文件：PascalCase - 工具函数：camelCase - 常量：SCREAMING_SNAKE_CASE ## 反例（以下写法不允许出现） - 使用 `any` 类型 - 组件内部定义嵌套组件 - 在 render 中执行副作用操作 ## 示例 参考 examples/good-example.tsx 和 examples/bad-example.tsx注意，规则不能只写“要规范”这种大话，必须每个点都能机械检查和判断。这样 AI 在执行时才有明确依据。
5.2 场景二：让 AI 成为项目文档的“自动维护者”
很多团队文档维护不及时，本质原因是“写文档的时间被压缩了”。用 AI Skill 可以大大降低文档维护成本。
做一个名为doc-architect的 Skill，输入是近期代码变更的 commit 记录，输出是更新后的 README 接口列表和模块说明。SKILL.md 中的输出模板可以这样定义：
## 输出要求 根据最近的 git log，对比当前 README.md 内容，输出以下内容： 1. 新增接口列表（包含路径、方法、用途） 2. 变更接口列表（包含变更内容和兼容性说明） 3. 新增模块说明 4. 过时内容标注（不再存在的接口，标注“已废弃”）这种 Skill 的价值在于：它把“文档维护”从每周一次的大工程变成了每次提交后的自动动作，让文档始终与代码保持同步。
5.3 场景三：基于“Vibe Canonical”的 AI 辅助思路
Claude 推出了一个 Concepts 概念，其中有“Vibe Canonical”的说法，大意是“让 AI 学会团队既有的工作偏好和编码风格”。这个概念和 Matt 的 AI Skills 方法论是相通的：
- Vibe 是团队长期形成的技术偏好和协作方式。
- Canonical 是指这种偏好被固化成标准、可参考的形态。
- AI Skills 正是实现 Vibe Canonical 的一种载体。
简单来说，团队文化和技术风格不再只存在于老员工的脑子里，而是可以通过 Skill 文件传递给 AI，再由 AI 传递给每一个新成员，这就是所谓的“团队级的 Vibe Canonical”。比如，新员工入职后，在 AI 工具中加载团队的 code-style 和 architecture 技能，写出来的第一版代码就能比较贴近团队风格，大幅缩短适应期。
6. AI Skills 的工程化实现：一个完整示例
为了让你更直观地理解，这里用一个实际场景来演示完整的 AI Skill 创建过程。假设你的团队使用 React + TypeScript，经常需要为新组件生成测试文件。
6.1 创建 Skill 目录结构
mkdir -p react-test-generator/{examples,references}6.2 编写 SKILL.md 主文件
--- name: react-test-generator description: 为 React + TypeScript 组件生成 Testing Library 单元测试 version: 1.0.0 --- # React 组件测试生成技能 ## 适用场景 - 新组件开发完成后，需要补充单元测试 - 已有组件改动后，需要同步更新测试用例 ## 输入要求 1. 组件源文件路径或完整组件代码 2. 组件依赖的 props 类型定义（可选） 3. 项目中已有的测试风格示例（可选） ## 生成规则 1. 使用 @testing-library/react 和 vitest。 2. 测试文件与组件同目录，命名为 `组件名.test.tsx`。 3. 必须覆盖以下测试场景： - 正常渲染：组件成功挂载，核心节点出现在文档中。 - 交互行为：按钮点击、表单输入等用户操作触发正确回调。 - 边界条件：可选 props 缺省时组件行为正确。 - 加载状态：如果组件有异步逻辑，测试 loading 状态。 4. 查询优先使用 `getByRole` 和 `getByLabelText`，避免使用>// 文件路径：examples/UserCard.test.tsx import { render, screen } from '@testing-library/react'; import userEvent from '@testing-library/user-event'; import { describe, it, expect, vi } from 'vitest'; import { UserCard } from '../UserCard'; describe('UserCard', () => { const defaultProps = { name: '张三', email: 'zhangsan@example.com', onFollow: vi.fn(), }; it('正常渲染用户姓名和邮箱', () => { render(<UserCard {...defaultProps} />); expect(screen.getByText('张三')).toBeInTheDocument(); expect(screen.getByText('zhangsan@example.com')).toBeInTheDocument(); }); it('点击关注按钮时触发 onFollow 回调', async () => { const user = userEvent.setup(); render(<UserCard {...defaultProps} />); const followButton = screen.getByRole('button', { name: /关注/i }); await user.click(followButton); expect(defaultProps.onFollow).toHaveBeenCalledTimes(1); }); it('不传 email 时不渲染邮箱区域', () => { render(<UserCard {...defaultProps} email={undefined} />); expect(screen.queryByText(/@example\.com/)).not.toBeInTheDocument(); }); });6.4 在支持的 AI 工具中使用
以支持 Claude Agent Skills 的编码工具为例，将上面的react-test-generator目录放入指定的 Skills 目录后，你只需要给 AI 一条指令：
请为 src/components/UserCard.tsx 生成测试文件。AI 会自动加载react-test-generator技能，按照 SKILL.md 中的规则生成符合团队要求的测试代码，而不是仅仅给出一个泛泛的测试模板。
7. 常见问题与排查思路
在团队推广 AI Skills 的过程中，很容易遇到下面几类问题，这里整理成一张排查表，方便对照处理。
| 问题现象 | 常见原因 | 解决思路 |
|---|---|---|
| AI 没有加载 Skill 文件，输出和普通对话没有区别 | Skill 目录路径配置错误；文件名不是 SKILL.md | 检查工具的环境变量和目录结构，确认 SKILL.md 是否在顶层 |
| Skill 中写了规则但 AI 不遵守 | 规则表述太模糊，AI 无法机械判断 | 把“代码风格要好”改为“函数必须显式标注返回类型”这种可检查的规则 |
| Skill 在不同项目上表现差异很大 | Skill 中项目上下文信息不够，依赖了某个特定项目的结构 | 将通用规则和项目特定配置分离，项目专属内容放到 references/ 中独立文件 |
| 团队成员反馈“还是手写更快” | Skill 的输出结果与团队实际风格差距大，需要大量人工修改 | 收集反例，将团队典型代码放入 examples/ 中，让 AI 对齐示例风格 |
| Skill 文件改来改去，版本混乱 | 缺少版本管理和变更记录 | 在 SKILL.md 中增加 version 字段，每次更新后在 CHANGELOG 中记录 |
| 维护 Skill 花费时间太多 | 追求一次写全所有规则，没有做到最小可用 | 第一版只覆盖 3 到 5 条核心规则，先用起来再逐步补充 |
| 使用 Skill 时泄露了敏感信息 | Skill 文件包含内部代码或凭据信息 | 对 Skill 文件做审查，使用占位符替换敏感内容，仓库设置最小权限 |
其中最重要的一条经验是：不要一次性写一个包含 50 条规则的巨型 Skill。AI 对规则过多、相互冲突的指令会无所适从。最佳粒度是每个 Skill 聚焦一个场景，规则控制在 5 到 10 条。
8. 最佳实践与工程建议
结合 Matt 的分享和团队的实际情况，下面这几条建议值得重点落实。
8.1 Skill 文件也走代码评审
AI Skills 本质上是一段“配置代码”，它们同样会影响团队的工程质量。建议把 Skill 文件的变更纳入代码评审流程，由技术负责人或 Skill owner 审核。这种做法的额外好处是：在 review Skill 文件的过程中，大家会对团队的代码规范、工具链选择进行一次自然讨论，很多时候能发现既有的规范文档已经过时了。
8.2 给 Skill 分层：基础技能 + 场景技能 + 组合技能
不要把所有的规则都塞进一个文件。我推荐将团队 AI Skills 分成三个层次：
- 基础技能：与具体项目无关的通用能力，比如“代码审查”“测试生成”“文档生成”。
- 场景技能：针对某类具体任务的技能，比如“生成 React 组件的测试”“生成 Spring Boot Service 层代码”。
- 组合技能：把基础技能和场景技能编排成完整的任务流，比如“新功能完整开发流程”。
分层的价值在于：当团队启动一个新项目时，基础技能可以直接复用；场景技能只需少量调整；组合技能则能帮助新成员快速上手项目的完整开发链路。
8.3 定期清理“僵尸” Skill
Skill 也需要“断舍离”。建议每季度做一次盘点，把长期没有人使用、没有更新的 Skill 归档或删除。判断标准很简单：
- 这个 Skill 在过去一个季度被使用过多少次？
- 它是否还适应当前团队的技术栈？
- 是否有其他的 Skill 已经覆盖了相同场景？
保留少量高质量、高频使用的 Skill，比堆积一堆大而全但没人用的 Skill 要有效得多。
8.4 安全合规边界
最后强调一下安全边界。团队在推广 AI 编程时，要明确哪些代码和数据可以被发送给 AI 工具，哪些不可以。
- 涉及用户隐私数据、密钥、数据库连接串、内部业务敏感信息的代码不要进入 AI 上下文。
- Skill 文件中如果引用了内部系统架构，需要评估泄露风险。
- 建议团队制定一份 AI 工具使用规范，明确“什么能喂给 AI、什么不能”，并把它写进入职文档。
同时要提醒团队成员：AI 生成的安全相关代码（认证、鉴权、SQL 拼接、文件上传等）必须经过人工严格审查，不能直接信任。
9. 实践心得
Matt 这套 7 步工作法背后，最值得学习的其实是一种“系统化思维”：个人使用 AI 靠灵感，团队使用 AI 靠制度。AI Skills 最大的价值不在于某一个文件写出了多漂亮的提示词，而在于它提供了一种让 AI 使用经验可以在团队内部持续积累和传播的载体。
在实际落地过程中，最重要的一步永远是第一步——找到那个高频、高价值、低风险的场景，写一个最小的 Skill 跑通流程。哪怕只是一个“根据 git diff 写 PR 描述”的 Skill，只要它能稳定节省团队每天 10 分钟的时间，它就有价值。
当第一个 Skill 真正被团队成员主动使用、主动提出改进建议时，团队 AI 编程的飞轮就已经转起来了。后续要做的，只是顺着这个轮子，不断把新的经验固化下来、传播出去。
如果这篇文章对你有帮助，不妨从今天开始，盘点一下你团队里最常用的 3 个 AI 提示词，把它们改写成 Skill 文件，找一个愿意尝鲜的同事试试看。也欢迎在评论区分享你团队推广 AI 编程时遇到的坑和心得，一起交流一起进步。
