把"测试用例生成"拆成4个Skill是天才，拆成20个是灾难
大家好，我是某互联网公司的测试总监。
去年年底，我们团队搞了一个大工程——把测试用例设计的全流程，全部封装成Agent Skill。
当时我很兴奋。Skill这东西太香了——需求拆解一个、用例生成一个、场景补全一个、质量评审一个……每个环节单独封装，完美。
然后，噩梦开始了。
三个月后，我们的Skill仓库里躺着47个测试Skill。需求拆解拆成了"登录需求拆解""订单需求拆解""支付需求拆解"……用例生成拆成了"正向用例生成""异常用例生成""边界用例生成"……每个Skill单独看都合理，合在一起就是一场灾难。
AI不知道用哪个。测试同学不知道装哪个。上下文被撑爆了。
我花了整整两周，把47个Skill合并回了12个。
今天这篇文章，就是我花了两周踩坑换来的4条铁律。
一、先看一组数据：Skill不是越多越好
先说一个让我印象深刻的实测数据。
SkillsBench（2026年2月，Amazon、CMU、Stanford、Oxford联合发布）发现：小而模块化的Skill（2-3个模块）显著优于大型数据转储。
什么意思？把一个任务拆成2-3个Skill，效果最好。拆得太碎，反而更差。
另一个数据来自实际项目：有团队把87个Skill全部塞进Claude Code，总大小898KB，上下文被压得死死的。后来他们把每个Skill拆成"轻量SKILL.md+详细INSTRUCTIONS.md"的两层结构，总大小直接降到27KB，压缩了97%。
Skill数量不是越多越好，是越"精"越好。
二、我踩过的三个坑
坑一："需求拆解"拆成了10个
最开始，我觉得"每个功能模块单独做一个需求拆解Skill"很合理。登录一个、订单一个、支付一个……结果就是：
AI不知道该用哪个。因为description长得差不多，它经常选错
测试同学分不清区别。打开Skill列表，满屏都是"XXX需求拆解"
维护成本爆炸。改一个通用规则，要改10个文件
教训：按"能力类型"拆分，而不是按"业务模块"拆分。
"需求拆解"本身是一种能力——不管拆解哪个模块，方法论是一样的。把方法论封装成一个Skill，业务差异通过输入参数来区分，而不是新建一个Skill。
坑二：把"一个工作流"拆成了"5个独立Skill"
我最早的"测试用例生成"流水线是这样的：
Skill A：读PRD提取测试点
Skill B：生成正向用例
Skill C：生成异常用例
Skill D：生成边界用例
Skill E：生成权限校验用例
每个Skill单独触发，但从来没有单独用过。每次都是用完整流水线，5个Skill串在一起用。
问题是，每个Skill都有自己的description、自己的加载开销。5个Skill分别加载，上下文消耗是1个Skill的5倍。
教训：如果一个工作流的步骤从来不会单独使用，就把它们合并成一个Skill。
最终我把5个合并成了1个——test-case-generator，内部包含5个步骤，一次性跑完。
坑三：SKILL.md写成了百科全书
最早写的那个"测试用例生成"Skill，SKILL.md有800多行——包含了详细的用例模板、几十个示例、完整的业务规则库。
结果就是：每次调用这个Skill，800行全被加载进上下文。单次调用消耗的Token是合理设计的5倍以上。
教训：SKILL.md只放核心流程（<500行），详细内容移到references/目录。
Claude的渐进式披露机制设计得很清楚：SKILL.md的YAML头信息始终加载（~100 tokens），正文在Skill触发时加载（<5k tokens理想），references/只在需要时读取。
把800行全塞进SKILL.md，等于废掉了这个机制。
三、4条铁律
踩完这些坑之后，我总结出了4条铁律。现在团队新建Skill，必须过这4条。
铁律一：一个Skill只做一件事
这是最基础的一条。如果一个Skill的description里出现了"和"字，大概率是拆错了。
判断标准：用一句话说清楚这个Skill是干什么的。如果一句话说不完，说明它干了太多事。
❌ 错误："生成测试用例并进行质量评审和格式转换"
✅ 正确："根据需求描述生成结构化测试用例"
为什么要这样？ Claude靠description决定用哪个Skill。description越清晰，AI选得越准。
铁律二：2-3个模块原则
SkillsBench的发现很明确：2-3个模块的Skill表现最好。
一个测试用例生成流水线，拆成4个Skill（需求拆解→用例生成→场景补全→质量评审）是极限。拆成5个以上，就开始反噬了。
判断标准：如果你需要5个以上的Skill才能完成一个完整工作流，说明粒度太细了。把其中2-3个合并。
铁律三：SKILL.md不超过500行
Anthropic官方推荐：SKILL.md正文目标约200行，最多500行。
超过500行，必须拆分——把详细内容移到references/目录，SKILL.md只留核心流程和导航。
判断标准：打开SKILL.md，滚动条超过两屏，就该拆了。
铁律四：description + when_to_use不超过1536字符
这是Claude路由预算的硬限制。description写太长，AI根本看不全。
判断标准：description要写清楚"什么时候用"，而不是"它有什么用"。
❌ 坏的："帮助用户生成测试用例"
✅ 好的："当用户提到'生成测试用例''编写测试''测试场景'等意图时触发"
四、一张速查表：粒度对不对，看这5个信号
信号
说明
怎么办
description里出现"和"
一个Skill干了多件事
拆成2-3个独立Skill
SKILL.md超过500行
内容太多，上下文浪费
移到references/
5个以上Skill才能完成一个工作流
粒度太碎
合并相关Skill
AI频繁用错Skill
description区分度不够
重写description
同一个Skill被反复调用完成不同任务
粒度太粗
按能力类型拆分
一个简单的判断方法：如果一个Skill你愿意分享给其他团队用，粒度大概率是对的。如果它只在你自己的项目里能用，粒度可能太细了。
五、最终方案：12个Skill怎么拆的
踩完坑、合并完之后，我们团队的测试Skill从47个变成了12个。分类是这样的：
测试设计类（4个）：
prd-to-test-map：需求拆解→测试地图
test-case-generator：测试地图→结构化用例（合并了正向/异常/边界/权限4个）
test-scenario-completion：基于历史Bug补全隐藏场景
test-case-reviewer：质量评审+改进建议
测试执行类（3个）：
api-test-executor：接口自动化测试
ui-test-executor：UI自动化测试（Playwright）
performance-test-executor：性能测试（JMeter）
测试数据类（2个）：
test-data-generator：批量构造测试数据
test-data-validator：数据一致性校验
测试治理类（3个）：
coverage-analyzer：覆盖率分析与缺口定位
test-impact-analyzer：代码变更影响分析
test-report-generator：测试报告生成
每个Skill都是一件事，description清晰，SKILL.md控制在200-400行，references按需加载。
最后
Skill不是越细越好，是越"稳"越好。
拆得太粗，一个Skill干太多事，AI理解不了、执行不准。拆得太细，几十个Skill互相打架，AI选不对、上下文撑爆。
2-3个模块、SKILL.md<500行、description精准——这三条卡住，大概率不会翻车。
下次你封装Skill的时候，先问自己三个问题：
这个Skill能用一句话说清楚吗？
它的SKILL.md超过500行了吗？
它和已有的Skill有重叠吗？
三个问题都过关，再动手写。
不然，你就是在给自己制造下一堆技术债。
本文系作者基于真实项目经验的总结。文中所有数据和案例均来自2026年实际落地项目。
