測試 Skill 並非愈多愈好：47 個 Skill 令 AI 不知該用哪個
测试 Skill 不是越多越好：47 个 Skill 的仓库，AI 不知道该用哪个
作者所在團隊把測試 Skill 從 47 個合併為 12 個，改按能力類型而非業務模組劃分。合併後，12 個 Skill 的 description 合計少於 2000 Token，作者稱 AI 選擇更準確，維護成本亦下降。文章將 Skill 分為測試設計、執行、數據及治理四類，並提出大型團隊可參考 9–15 個的健康區間。
2026-10-30 7
版权
版权声明：
本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《 阿里云开发者社区用户服务协议》和 《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写 侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。
简介： 去年底，团队将测试用例设计全流程封装为47个Agent Skill，但很快遭遇AI选错、上下文爆炸、维护失控三大问题。经复盘，按“能力类型”而非“业务模块”合并为12个精炼Skill，显著提升准确率与可维护性。核心结论：Skill贵精不贵多，健康数量为9–15个。
去年年底，我们团队搞了一个大工程——把测试用例设计的全流程，全部封装成 Agent Skill。
当时我很兴奋。需求拆解一个、用例生成一个、场景补全一个、质量评审一个……每个环节单独封装，完美。
三个月后，我们的 Skill 仓库里躺着 47 个测试 Skill。需求拆解拆成了“登录需求拆解”“订单需求拆解”“支付需求拆解”；用例生成拆成了“正向用例生成”“异常用例生成”“边界用例生成”；每个 Skill 单独看都合理。
然后噩梦开始了。AI 不知道用哪个。 测试同学不知道装哪个。上下文被撑爆了。
我花了整整两周，把 47 个 Skill 合并回了 12 个。今天把踩过的坑和合并的逻辑完整复盘一遍。
一、先看一组数据：Skill 不是越多越好
SkillsBench（2026年2月，Amazon、CMU、Stanford、Oxford 联合发布）的研究发现：小而模块化的 Skill（2—3 个模块）显著优于大型数据转储。拆得太碎，效果反而更差。
另一个实测数据更直接：有团队把 87 个 Skill 全部塞进 Claude Code，总大小 898KB，上下文被压得死死的。后来拆成“轻量 SKILL.md + 详细 INSTRUCTIONS.md”的两层结构，总大小降到 27KB，压缩了 97%。
Skill 数量不是越多越好，是越“精”越好。
二、47 个 Skill 带来的三个问题
问题一：AI 选错 Skill
Claude Code 启动时，会把所有 Skill 的 description 预加载进上下文，用来判断该触发哪个。47 个 Skill 意味着 47 条 description 同时在上下文里抢注意力。
问题是，很多 description 长得差不多。“正向用例生成”“异常用例生成”“边界用例生成”——三个 Skill 的触发条件高度重叠。AI 收到“帮我生成登录功能的测试用例”时，它该选哪个？它可能选正向，可能选异常，也可能三个都不选，直接给你一段通用文本。
Skill 越多，description 之间的区分度越低，AI 选错的概率越高。
问题二：上下文被撑爆
每个 Skill 被触发时，完整的 SKILL.md 正文会被加载进上下文。一个中等复杂的 Skill，正文 200—400 行，折合几千 Token。如果 AI 在一次任务里触发了三四个 Skill，上下文很快就被塞满。
更麻烦的是，上下文被占满之后，AI 的注意力会下降。它可能漏掉 Skill 里的某条规则，可能忘记自检清单，可能生成到一半就“忘了”前面的约束。
Skill 不是“装了就生效”，它是要吃上下文的。装得越多，每个 Skill 能分到的注意力越少。
问题三：维护成本爆炸
47 个 Skill，意味着 47 个文件要维护。业务规则变了，你要改多少个文件？用例模板更新了，你要同步多少个 Skill？
我们当时的真实情况是：优惠券规则改了，涉及“用例生成”“场景补全”“质量评审”三个 Skill，每个都要改。改完之后，还有一个 Skill 忘了更新，导致生成的用例和评审标准不一致。
Skill 的维护成本，和数量是平方关系——不只是每个要维护，还要保证它们之间不冲突。
三、合并的逻辑：按“能力类型”拆，不按“业务模块”拆
我花了两周做合并，核心逻辑只有一条：按“能力类型”拆分，不按“业务模块”拆分。
错误示范：按业务模块拆
登录需求拆解 Skill
订单需求拆解 Skill
支付需求拆解 Skill
这三个 Skill 的流程完全一样——读 PRD、提取功能点、识别业务规则、输出测试地图。区别只是“读的是哪份 PRD”。
按业务模块拆，等于把同一套方法论复制了 N 遍。
正确示范：按能力类型拆
需求拆解 Skill（适用于所有模块）
用例生成 Skill（适用于所有模块）
场景补全 Skill（适用于所有模块）
质量评审 Skill（适用于所有模块）
“需求拆解”是一种能力，不管拆解哪个模块，方法论是一样的。业务差异通过输入参数来区分，而不是新建一个 Skill。
判断标准：如果一个 Skill 的流程可以复用到另一个业务模块，它就不该按业务模块拆。
四、47 个合并成 12 个：最终结构
合并之后，我们团队的测试 Skill 从 47 个变成了 12 个，分四类：
测试设计类（4个）
prd-to-test-map：需求拆解→测试地图
test-case-generator：测试地图→结构化用例（合并了正向/异常/边界/权限四个）
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 按需加载。
五、合并之后，发生了什么？
第一，AI 选对的概率上去了。 从 47 条 description 减到 12 条，每条 description 的区分度大幅提升。AI 收到“生成登录用例”时，只会触发 test-case-generator，不会在三个相似的 Skill 之间犹豫。
第二，上下文不再被撑爆。 12 个 Skill 的 description 加起来不到 2000 Token，AI 有足够的注意力处理任务本身。
第三，维护成本降下来了。 优惠券规则改了，只需要改 test-case-generator 和 test-scenario-completion 两个 Skill，不用在 47 个文件里大海捞针。
六、避坑指南
坑一：按业务模块拆 Skill。 “登录需求拆解”“订单需求拆解”——流程一样，拆开只是增加维护成本。按能力类型拆，业务差异用输入参数区分。
坑二：一个工作流拆成五六个 Skill。 “读PRD提取测试点”“生成正向用例”“生成异常用例”“生成边界用例”“生成权限用例”——这五步从来没有单独用过，每次都是串起来跑。合并成一个 Skill，内部包含五个步骤。
坑三：SKILL.md 写成百科全书。 超过 500 行就开始浪费 Token。详细模板、示例、业务规则库放到 references/ 目录，正文只留核心流程。
坑四：description 写得太像。 三个 Skill 的 description 都在说“生成测试用例”，AI 没法区分。每个 Skill 的 description 要写清楚“什么场景下用它，什么场景下不用”。
坑五：只建不删。 Skill 仓库需要定期清理。三个月没被触发过的 Skill，要么是 description 写错了，要么是根本不需要。删掉它，比留着占上下文强。
七、Skill 数量的“健康区间”
基于我们团队的实践和 SkillsBench 的研究，我给一个参考区间：
1—3 个 Skill：适合个人或小团队，覆盖最核心的 1—2 个测试环节。
4—8 个 Skill：适合中型测试团队，覆盖需求、用例、执行、评审全流程。
9—15 个 Skill：适合大型团队，每个 Skill 对应一个明确的能力类型。
超过 15 个：需要认真审视，大概率有可以合并或删除的。
判断标准不是“数量”，是“每个 Skill 是不是只做一件事、description 是不是足够区分、有没有三个月没被触发过的”。
最后
Skill 不是“能力勋章”。装得越多，不代表能力越强，只代表上下文越挤、AI 越容易选错。
47 个 Skill 的仓库，不是“丰富的资产”，是“混乱的负担”。合并成 12 个之后，AI 反而更能干活了——因为每个 Skill 的职责清晰了，description 区分度上去了，上下文有空间了。
Skill 的价值不在“多”，在“每个都能被准确触发、准确执行”。
下次你发现自己在建第三个“XX模块用例生成”Skill 的时候，停下来，问一句：这个 Skill 和已有的那个，流程是不是一样的？
如果一样，合并它。你的 AI 会感谢你。
本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料，主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容，侧重测试实践、工具应用与工程经验整理。
來源：阿里雲開發者社區 AI · developer.aliyun.com