很多人用 AI 编程，一开始效率很高，过几天就慢下来了。
原因不是 AI 不行，而是每次都在重复解释同样的事情：
- 项目用什么技术栈。
- 代码风格是什么。
- 测试怎么跑。
- 什么文件不能动。
- 输出结果要按什么格式。
- 做完以后要怎么验收。
这些内容如果每次都重新写，就是一次性提示词。
如果把它们沉淀成固定说明，让 AI 每次都按同一套规则工作，就是 Skill。
Skill 到底是什么
你可以把 Skill 理解成“给 AI 的岗位说明书 + 项目工作规范”。
普通提示词解决的是一次任务：
帮我给这个函数写单元测试。
Skill 解决的是一类任务：
以后凡是补测试，都先列测试矩阵，再生成代码，再检查边界。
必须使用项目现有测试框架，不允许引入新依赖。
输出时必须说明验证命令。
区别在于：提示词是临时沟通，Skill 是流程资产。
什么内容适合写进 Skill
适合写进 Skill 的内容，一般有 5 类。
第一类：技术栈约束。
比如项目使用 React、Next.js、Vue、NestJS、Spring Boot、Django、PostgreSQL、Prisma 等。AI 不应该每次都猜。
第二类：代码风格。
比如是否使用 TypeScript、是否允许 any、组件怎么命名、接口怎么分层、错误处理怎么写。
第三类：工作流程。
比如先分析再修改、先写测试再实现、修改后必须跑什么命令。
第四类：安全边界。
比如不能改生产配置、不能提交密钥、不能删除迁移文件、不能重构无关模块。
第五类：输出格式。
比如每次结束都要输出修改文件、验证方式、风险点、后续建议。
一个最小可用的 Skill 模板
下面这个模板可以直接拿去改。
# Skill: 项目开发助手
## 目标
帮助我在当前项目中完成小范围功能开发、问题修复和测试补齐。
## 工作原则
- 先理解项目结构，再提出方案。
- 未经确认，不做大范围重构。
- 优先复用项目已有工具、组件和风格。
- 不引入新依赖，除非明确说明原因并获得确认。
- 不修改无关文件。
## 开发流程
1. 阅读相关代码。
2. 输出需求理解和影响范围。
3. 给出实现方案。
4. 小步修改代码。
5. 运行或说明验证方式。
6. 总结改动、风险和测试缺口。
## 测试要求
- 优先补充单元测试或接口测试。
- 必须覆盖正常流程和边界条件。
- 如果无法运行测试，要说明原因。
## 输出格式
- 需求理解
- 修改文件
- 验证方式
- 风险点
- 后续建议
这个 Skill 不复杂，但已经能避免很多 AI 编程里的失控问题。
不同场景可以有不同 Skill
我建议至少准备 4 个常用 Skill。
第一个：需求分析 Skill。
目标是把模糊想法变成可开发需求。它应该要求 AI 输出目标用户、核心场景、MVP 范围、边界情况和验收标准。
第二个：代码开发 Skill。
目标是约束 AI 小步改代码。它应该强调先读代码、再给方案、最后修改，并且禁止无关重构。
第三个：测试补齐 Skill。
目标是让 AI 先列测试矩阵，再写测试代码。它应该覆盖 happy path、异常输入、权限、空数据、重复提交等场景。
第四个：上线检查 Skill。
目标是上线前做 checklist。它应该检查环境变量、构建命令、数据库迁移、日志、回滚方案和监控。
Skill 写得越具体，AI 越稳定
很多人写 Skill 只写一句：
你是一个资深全栈工程师，请帮我写高质量代码。
这句话几乎没有约束力。
更好的写法是：
当你修改代码时：
1. 必须先说明要改哪些文件。
2. 每次只围绕当前任务修改。
3. 不允许新增依赖。
4. 如果发现需要重构，先提出建议，不要直接做。
5. 修改后输出验证命令。
AI 不是因为你称它“资深”才变强，而是因为你给了它清楚的工作边界。
如何在真实项目里使用 Skill
可以按这个顺序来。
第一步，把项目固定信息写进去。
包括技术栈、启动命令、测试命令、目录结构、常见坑。
第二步，把团队约定写进去。
包括命名规范、错误处理、日志规范、API 返回格式、提交前检查。
第三步，把常用任务流程写进去。
比如新增接口、改页面、补测试、修 bug、写部署文档。
第四步，每次踩坑后更新 Skill。
比如 AI 曾经乱改样式、乱加依赖、漏跑测试，就把这些约束补进去。
Skill 不是一次写完的，它应该随着项目经验持续更新。
一个测试补齐 Skill 示例
# Skill: 单元测试补齐
## 目标
为已有业务代码补充可维护的测试。
## 流程
1. 先阅读被测代码和已有测试。
2. 先输出测试矩阵，不要直接写代码。
3. 测试矩阵必须包含正常流程、边界值、异常输入和业务风险。
4. 人工确认后再生成测试代码。
5. 只测试公开行为，不测试私有实现细节。
## 约束
- 使用项目现有测试框架。
- 不引入新测试库。
- 不为了测试修改业务逻辑，除非明确指出必要性。
- 测试名称要描述业务行为。
## 输出
- 测试矩阵
- 新增/修改的测试文件
- 运行命令
- 未覆盖风险
这个模板特别适合团队第一次引入 AI 编程，因为测试任务可验证、风险低、收益明显。
Skill 不是万能的
Skill 解决的是“重复说明”和“流程稳定性”，不是替你做判断。
你仍然要检查：
- AI 是否理解了真实业务。
- 输出是否符合项目现状。
- 代码是否能跑通。
- 测试是否覆盖了关键风险。
- 有没有引入安全问题。
Skill 的作用是把 AI 从“随机发挥”拉回“按流程工作”。
最后
如果说提示词是一次沟通，Skill 就是工作流沉淀。
真正会用 AI 编程的人，不是收藏了几百条提示词，而是把自己的经验变成稳定、可复用、可迭代的规则。
你可以先从一个最小 Skill 开始：规定 AI 在改代码前必须先读项目、说明影响范围、给出验证方式。
只要这一步做到，AI 编程的失控感就会明显下降。
下一篇我会写：如何让 AI 帮你做需求分析。因为在写代码之前，最重要的不是生成代码，而是把问题定义清楚。
