三个月前我问了团队一个问题：“你们每天用AI写代码，有没有发现自己在反复描述同一类需求？”
安静了五秒后，有人说：“写单元测试的Prompt，我大概复制粘贴了不下50次。”
问题就在这里。
一、你在"用AI"，但AI没有在"学你"
2026年的AI编程工具已经足够强大。Cursor、Claude Code、Copilot，随便拿一个出来都能在30秒内生成一个CRUD接口。但一个尴尬的事实是：
你用了半年AI，AI对你的代码风格、业务偏好、踩过的坑一无所知。
每次新开一个对话，AI又回到了出厂状态。你需要重新解释项目结构、再次强调编码规范、第N次纠正它不要用已经废弃的那套API。这不是你的问题——这是"每次从零开始"这个模式的天花板。
Skill沉淀，就是要打破这个天花板。
它和"Cursor Rules"或"项目 .cursorrules 文件"不一样。Rules是静态约束（“不要用var”、“用ES6语法”），而Skill是一套可复用的经验资产——包含了你在某个具体场景下的判断逻辑、最佳输入输出格式、已知的坑和规避策略。
二、先搞清楚什么值得沉淀：三维筛选法
不是所有重复操作都值得封装成Skill。判断标准有三个维度：
维度一：频率
过去两周，这件事你做了多少次？
| 频率 | 判断 |
|---|---|
| ≥5次/周 | 必须沉淀 |
| 2-4次/周 | 值得沉淀 |
| ≤1次/周 | 暂时放一放 |
实操动作：花5分钟翻一下你最近两周的AI对话记录（Cursor的Session History、Claude Code的对话列表），标记出重复出现的任务类型。你大概率会看到——写单元测试、生成接口文档、代码审查、数据库迁移脚本、配置文件生成——这几类占据了80%以上的重复。
维度二：认知密度
这个任务需要你做多少次判断？
“把users表的所有字段列出来”——不需要判断，直接让AI查就行，不值得沉淀。
“根据这个PRD写一套RESTful API，要考虑到权限分级、数据脱敏、幂等性设计”——这里有至少三个判断点：权限模型选RBAC还是ABAC、哪些字段需要脱敏、幂等键怎么设计。认知密度高的任务，沉淀后的ROI最高。
维度三：复用半径
这个Skill未来能在多少个场景复用？
- 个人级：只有你自己用（比如你习惯的某种异常处理模式）
- 项目级：当前项目内所有模块都能用（比如统一的分页查询封装）
- 团队级：其他同事也能直接用（比如团队的代码审查检查清单）
- 跨项目级：换个项目依然有效（比如通用的API设计规范校验）
复用半径越大，沉淀优先级越高。
一张筛选表帮你快速决策：
| 任务 | 频率 | 认知密度 | 复用半径 | 是否沉淀 |
|---|---|---|---|---|
| 生成单元测试 | 15次/周 | 中 | 团队级 | ✅ |
| 接口文档生成 | 8次/周 | 低 | 项目级 | ✅ |
| 一次性的数据迁移脚本 | 1次 | 高 | 个人级 | ❌ |
| 代码审查 | 10次/周 | 高 | 团队级 | ✅ |
三、Skill封装的四个进化阶段
不要一上来就追求完美。Skill的成熟度是逐步演进的：
阶段一：原始Prompt——“每次手写”
帮我把这个Service类写一下单元测试，用JUnit5，覆盖率要80%以上。 Mock掉所有外部依赖，重点是异常分支的覆盖。这是大多数人的起点。问题很明显：每次都要把"JUnit5"、“Mock外部依赖”、"覆盖异常分支"这些话说一遍。
阶段二：模板化Prompt——“复制粘贴改”
## 单元测试生成模板 - 框架：JUnit5 + Mockito - 覆盖率目标：≥80%（分支覆盖） - 必须覆盖的场景： 1. 正常路径 2. 参数为null 3. 外部依赖抛异常 4. 边界值（空列表、最大最小值） - Mock策略：所有Service/Repository层依赖全部Mock - 命名规范：方法名_场景_预期结果进步在于固定了格式和约束，但依然是你在驱动AI。
阶段三：可执行Skill——“一行触发”
真正Skill化的关键特征是用最少的输入触发最完整的执行。达到这个阶段需要三个要素：
要素1：上下文自动注入
你的Skill不应该假设AI知道项目结构。应该在Skill内部声明需要哪些上下文，然后让AI自动去读取。
触发词：/gentest 自动动作： 1. 读取当前打开的文件 2. 识别所有public方法 3. 读取项目 pom.xml 确认JUnit版本 4. 查找已有的测试文件，沿用其风格 5. 生成测试代码要素2：失败模式预置
一个成熟的Skill必须知道"什么情况下会失败"以及"失败了怎么办"：
已知坑点： - 如果被测方法依赖静态工具类 → 提示使用 MockedStatic - 如果被测方法操作文件 → 建议使用 TemporaryFolder Rule - 如果存在循环依赖 → 先输出依赖图让用户确认这个部分的价值极高——它把你过去踩过的坑固化成了AI的行为准则。
要素3：输出格式契约
AI的输出不能是自由发挥。你的Skill要明确输出格式：
输出格式： 1. 【覆盖概览】列出每个方法的测试覆盖计划 2. 【测试代码】完整可运行的代码 3. 【未覆盖说明】标注哪些分支无法覆盖及原因阶段四：自适应Skill——“越用越准”
这是目前的前沿阶段。在Skill中加入反馈收集机制：
每次生成后记录： - 生成的测试用例数 - 实际通过率（用户手动反馈） - 用户修改的代码行数积累数据后可以优化Prompt、调整策略。这一步不一定现在就要做，但脑子里要有这根弦。
四、实操：30分钟搭建你的第一个Skill
拿最常见的场景——"代码审查"来走一遍完整流程。
Step 1：回顾你的审查习惯（5分钟）
打开你最近三次Code Review的记录，总结你每次必查的项目：
- 空指针/空列表处理
- SQL注入风险
- 异常是否正确向上抛出而非吞掉
- 日志级别是否合理
- 是否有不必要的数据库查询（N+1问题）
把这些列成一个清单，这就是你Skill的核心骨架。
Step 2：写成结构化模板（10分钟）
## Code Review Skill ### 触发方式 将代码粘贴到对话中，加一句 "review this"。 ### 审查维度（按优先级） 1. **安全**：SQL注入、XSS、未授权访问、敏感信息泄露 2. **空值处理**：所有外部输入、数据库查询结果、集合操作 3. **异常处理**：不允许空catch块、不允许吞异常不记录日志 4. **事务边界**：写操作是否在事务内、事务粒度是否合理 5. **性能**：N+1查询、循环内数据库调用、不必要的大对象创建 6. **代码风格**：命名是否一致、是否有魔法数字、注释是否过期 ### 输出格式【安全风险】
- 第X行：… | 严重程度：高/中/低 | 建议：…
【空值风险】
- 第X行：… | 建议：…
【异常处理问题】
- 第X行：… | 建议：…
【性能问题】
- 第X行：… | 建议：…
【风格建议】
- 第X行：… | 建议：…
### 已知踩坑 - 不要在 Lombok @Data 生成的 equals/hashCode 上做关联查询 - 数据库字段修改后检查所有相关的 MyBatis XML - 确认 Redis key 有过期时间Step 3：实战验证（10分钟）
拿一段真实代码喂进去，看输出质量。记下不满意的地方——格式不对？漏了检查项？误报太多？——然后回到模板里修正。
Step 4：迭代（持续）
每次用它审查完代码后，如果有新的检查项被遗漏，立即补充进Skill。一个月后，你的审查Skill会包含你团队所有的血泪教训。
五、Skill管理：别让你的经验资产变成信息垃圾
沉淀了10个Skill之后，最大的敌人是找不到和用不了。
个人Skill索引（轻量版）
一个Markdown文件就够了：
# 我的Skill索引 ## 编码阶段 | Skill名 | 用途 | 触发方式 | 更新时间 | |---------|------|----------|----------| | gen-test | 生成单元测试 | /gentest | 2026-06-28 | | gen-api-doc | 生成接口文档 | /gendoc | 2026-06-25 | | cr-check | 代码审查 | review this | 2026-06-27 | ## 重构阶段 | Skill名 | 用途 | 触发方式 | 更新时间 | |---------|------|----------|----------| | db-migrate | 生成数据库迁移脚本 | /migrate | 2026-06-20 | ## 部署阶段 | Skill名 | 用途 | 触发方式 | 更新时间 | |---------|------|----------|----------| | deploy-check | 部署前检查清单 | /predeploy | 2026-06-15 |Skill的版本管理
Skill也是代码，需要版本管理。建议：
- 每个Skill存为一个独立文件（Markdown或YAML）
- 放Git仓库里，和项目代码一起管理
- 每次修改记录ChangeLog：改了哪里、为什么改
- 定期清理：超过1个月没用过的Skill归档，3个月没用过的删除
团队Skill共享的三个原则
如果你想把个人Skill推广到团队：
原则1：先验证再推广。个人稳定使用2周以上才进入团队库，避免半成品消耗他人时间。
原则2：有人维护。每个团队Skill必须指定Owner，没人管的Skill三个月后就会过期。
原则3：效果可量化。“用了代码审查Skill后，线上Bug减少20%”——这种数据比"感觉好用"有说服力得多。
六、常见疑虑与解答
Q：我只是一个普通开发者，沉淀Skill是不是太"重"了？
A：不需要一开始就追求完美。今天的你，把一个常用的Prompt保存到备忘录里，就是在做Skill沉淀。关键在于意识——承认"AI不会自动记住你的经验"，然后有意识地去固化它。
Q：AI进化这么快，今天沉淀的Skill明天会不会过时？
A：会过时。但过时的是具体指令（比如"用JUnit5"），不过时的是方法论（“测试要覆盖异常分支”）。把判断逻辑写进Skill里，工具语法随时可以替换。
Q：我用的是Cursor/Copilot/Claude Code，Skill怎么跨工具迁移？
A：把Skill的核心定义为"场景描述 + 约束条件 + 输出格式"，这三样东西是工具无关的。迁移时只需要改触发方式和上下文注入方式，核心逻辑不用动。
七、从现在开始
如果你读完只做一件事，我建议是：
打开你最近两周的AI对话记录，找出你重复描述最多的那一类需求，花20分钟把它写成结构化模板。
这个动作本身，就是你Skill体系的起点。
AI编程的下一个分水岭，不是工具之争，而是经验资产化能力之争。那些能把每一次使用AI的经验都沉淀为可复用资产的人，会成为这个时代的"十倍开发者"——不是因为他们比AI更强，而是因为他们让AI站在了自己所有经验的基础上工作。
本文基于个人实践与团队观察撰写，文中提到的所有框架和工具均为示例，可根据实际技术栈替换。
)
