47个测试Skill的仓库让AI不知道用哪个，按“能力类型”合并成12个才稳，Skill数量到底有没有上限？

目录

一、导言：47个Skill的仓库为什么“不会选”

先把场景还原清楚。某测试团队在半年内把自动化测试相关的Agent Skill从最初的3个扩展到了47个：接口用例生成、断言补全、Mock数据构造、边界值枚举、日志解析、失败归因、用例去重、覆盖率缺口分析、缺陷复现脚本、回归集裁剪……每一个Skill单独看都合理，都有明确的输入输出契约，也都通过了各自的单元测试。问题出现在把它们同时挂载到同一个Agent运行时之后：面对“帮我给这个登录接口补一组边界用例”这样的请求，模型有时调用“边界值枚举”，有时调用“接口用例生成”，有时先调“用例去重”再调“断言补全”，路径不稳定，结果也不稳定。

这不是模型“变笨了”，而是仓库的组织方式把一个本可以结构化的问题摊平成了纯语义匹配问题。47个Skill的name与description字段被拼接进系统提示或工具清单，模型需要在一次前向推理中完成“理解意图—比对描述—排除近义项—决定调用”的全过程。当候选从个位数涨到几十个，描述之间的语义距离被压缩，区分度下降，选择的不确定性随之上升。

该团队最终的做法是把47个Skill按“能力类型”合并为12个能力簇（capability cluster），每个簇对外暴露一个入口Skill，簇内差异通过参数与子流程表达。改造后，路由稳定性明显改善，回归结果可复现。这个案例引出了本文要回答的核心问题：Skill数量到底有没有上限？如果有，上限由什么决定？

笔者的基本判断是：把“上限”理解为一个固定数字（比如20、50、100）是方向性错误。真正起作用的是三个变量的乘积——候选空间的有效规模、单个Skill的描述信息量、以及评测集对歧义的覆盖度。数量只是这三个变量的外在表现。换句话说，一个组织良好的80个Skill仓库，可能比一个组织混乱的25个Skill仓库更“稳”。本文的分析主线由此展开：Skill治理的核心是把扁平候选列表改造成分层索引，数量上限是分层质量的结果而非原因。

二、问题定义：Skill选择是一个受限检索问题

2.1 先把概念钉死：什么是Skill

在Agent工程语境下，Skill通常指一段可被模型按需调用的能力封装，包含三个要素：声明（名称与描述）、契约（输入输出与前置条件）、实现（脚本、提示模板或外部服务调用）。它与传统函数调用的关键差别在于：函数由程序员在编译期确定调用点，而Skill由模型在推理期通过自然语言描述进行选择。这一差别决定了Skill的“可发现性”与“可区分性”和它的功能实现同等重要。

本文讨论的“测试Skill”特指面向软件测试活动的Skill集合，覆盖用例设计、数据构造、执行编排、结果分析与缺陷处理等环节。这类Skill有一个共同特征：语义高度相邻。边界值枚举与等价类划分在描述上都涉及“输入域”“取值”“覆盖”，失败归因与日志解析都涉及“错误信息”“堆栈”。语义相邻意味着候选之间的区分成本高，这正是47个Skill场景失控的直接诱因。

2.2 形式化：选择过程等价于一次受限检索

把Skill选择写成检索问题，有助于看清瓶颈所在。设请求为q，Skill集合为S = {s₁, s₂, …, sₙ}，每个Skill有描述向量d(sᵢ)。模型实际完成的是在候选集上的一次近似最近邻判断：

ŝ = argmax_{s ∈ S}  sim(q, d(s)) · 1[ s 满足前置条件 ]

其中：
  sim(·,·)  为模型内部的语义相似度（不可直接观测）
  n = |S|   为候选规模
  前置条件由契约声明，构成硬过滤

这个式子揭示了两件事。第一，n 增大时，argmax 的“亚军差距”（top-1 与 top-2 的分数差）通常收窄，选择对描述措辞的微小变化变得敏感。第二，硬过滤条件如果写得不够严格，前置条件几乎不起作用，候选集退化为全集。47个Skill的仓库往往两条都中：描述高度同质，前置条件形同虚设。

本文评述：把Skill选择类比为检索并非修辞。信息检索领域关于“候选规模—排序质量”的研究早已指出，当候选集扩大而查询表达不变时，排序模型的区分压力会转移到特征工程与负样本构造上。Agent的Skill路由缺少显式的负样本训练环节，因此这种压力只能由描述文本和分层结构来承担。这解释了为什么“多写几句description”在Skill数量较少时有效，超过某个规模后边际收益迅速衰减。

2.3 三个可观测的症状

在工程上，Skill选择失控通常表现为三个可观测症状，它们可以作为是否需要重构的早期信号：

这三个症状的共同点是：它们都不指向某个Skill的实现缺陷，而指向Skill集合的组织缺陷。因此修复手段不应是逐个调优Skill描述，而应回到集合层面重新设计索引结构。

三、原理拆解：路由歧义、上下文预算与评测熵增

3.1 路由歧义：语义相邻的代价

路由歧义的根源是描述空间的“拥挤”。当两个Skill的描述在嵌入空间中距离很近时，模型需要在极小的语义间隙上做出判断，而这种判断对措辞高度敏感。测试领域的Skill天然拥挤：以“生成测试数据”为例，至少可以拆出基于规则的构造、基于Schema的构造、基于生产流量采样的构造、基于约束求解的构造等若干变体，它们的描述都包含“测试数据”“生成”“约束”等高频词。

笔者认为，歧义不是靠“写得更详细”能根治的。描述越长，包含的共享词越多，反而可能加剧拥挤。有效的做法是改变索引维度：不再让所有Skill在同一层竞争，而是先用一个粗粒度维度（能力类型）把候选切分成互斥的若干组，组内再比较。这相当于把一次大范围检索拆成“先分类、后匹配”的两级检索，每级的候选规模都显著缩小。

3.2 上下文预算：Skill清单本身是成本

Skill的声明信息需要进入模型的上下文窗口。以常见的工具调用格式为例，每个Skill的名称、描述、参数Schema合计约80至200个token（取决于描述详略与参数复杂度，此处为工程估算区间，非特定文献数据）。47个Skill意味着每轮对话固定占用约4k至9k token的清单开销，这部分开销与请求本身无关，却持续挤占推理预算。

更隐蔽的代价是注意力稀释。上下文中的候选清单越长，模型在生成调用决策时需要维持的“候选对照表”越大，长尾候选被误选的概率上升。这与长上下文检索中“中间位置信息利用率下降”的现象在机制上同源：信息都在窗口里，但有效利用并不均匀。本文评述：把Skill清单视为“免费”的元数据是一种常见误解，它和检索增强中的文档块一样，是消耗预算的资源，必须按预算管理。

3.3 评测熵增：为什么越加Skill越难评估

评测层面的问题常被低估。每新增一个Skill，评测集就需要补充对应的正例，同时还要补充它与既有Skill的“负例对”（即那些容易被误选的情形）。负例对的数量随Skill数量呈组合式增长：n个Skill理论上存在 n(n−1) 个有向混淆对。即便只覆盖语义相邻的子集，维护成本也随规模快速上升。

结果是评测集的覆盖度跟不上Skill的增长速度，通过率变成一个信息量很低的指标——它无法区分“真的选对了”和“碰巧选对了”。笔者把这种现象称为评测熵增：随着候选增多，评测结果的不确定性上升，团队对系统真实能力的判断反而变模糊。合并为12个能力簇的一个附带收益，是把混淆对的数量压到可维护的范围内，让评测重新具备区分力。

3.4 三者的耦合关系

路由歧义、上下文预算与评测熵增不是三个独立问题，而是同一结构缺陷的三个投影。扁平列表导致歧义，歧义迫使团队增加描述长度以图区分，描述变长又推高上下文开销，开销上升促使团队精简评测以控制成本，评测变薄又让歧义难以被发现。这是一个正反馈回路，单点修补无法跳出。

四、技术路线：按“能力类型”合并为12个能力簇

4.1 什么是“能力类型”

能力类型（capability type）指Skill在测试流程中承担的职能角色，而非它处理的对象或使用的技术。区分这两者至关重要：按对象分（接口、UI、性能）会得到互相重叠的类别，因为同一个对象上可以施加多种职能；按技术分（规则、模型、求解器）则与技术演进强耦合，稳定性差。按职能分，得到的类别近似互斥且覆盖完整。

笔者采用的职能划分依据是测试活动的基本环节：理解需求与规格、设计用例、构造数据、准备环境、执行与编排、判定结果、分析失败、管理缺陷、评估覆盖、维护回归、生成报告、治理资产。这十二个环节对应十二个能力簇，每个簇吸收原先散落在该环节上的多个细粒度Skill。

4.2 合并判据：什么该合、什么不该合

合并不是简单地把文件塞进同一个目录。判断两个Skill是否应合并，笔者建议用四条判据，满足三条以上即可合并：

判据	含义	反例（不应合并）
同职能	在测试流程中处于同一环节，输出物类型相同	用例生成与失败归因，输出物不同
同契约	输入参数可归并为同一Schema，差异可用枚举或可选字段表达	输入分别是自然语言与二进制日志，Schema无法统一
可参数化	差异可通过参数（策略、模式、阈值）表达，而非分支逻辑	差异涉及完全不同的执行环境与依赖
同评测集	可以用同一组请求与断言覆盖，混淆对可枚举	需要完全不同的评测协议与指标

本文评述：这四条判据的实质是把“合并”从文件操作提升为接口设计。合并后的能力簇必须提供一个稳定的对外契约，簇内差异被封装为参数与子流程。若合并后契约变得臃肿（参数超过十余个、模式分支难以枚举），说明合并过度，应回退拆分。这个“合并—回退”的边界判断，比任何固定的数量阈值都更可靠。

4.3 十二个能力簇的参考划分

下表给出一套可直接落地的参考划分，覆盖47个测试Skill的典型分布。表中“吸收数”为示意值，用于说明合并比例，不同团队的实际分布会有差异。

能力簇	职能	吸收的典型Skill	吸收数
规格理解	解析需求与接口定义	OpenAPI解析、需求抽取、字段语义标注	4
用例设计	生成与优化用例	边界值、等价类、场景法、组合覆盖	7
数据构造	生成测试数据	Mock、Schema生成、流量采样、约束求解	6
环境准备	搭建与清理环境	容器编排、依赖注入、数据清理	3
执行编排	调度与重试	用例排序、并发控制、失败重试	4
结果判定	断言与校验	断言补全、Schema校验、快照比对	4
失败分析	归因与复现	日志解析、堆栈归因、复现脚本生成	5
缺陷管理	缺陷描述与去重	缺陷摘要、相似缺陷检索、严重级判定	3
覆盖评估	覆盖率与缺口分析	行覆盖、分支覆盖、接口覆盖缺口	3
回归维护	回归集裁剪与更新	用例去重、优先级排序、失效用例识别	3
报告生成	汇总与呈现	结果汇总、趋势对比、报告模板填充	3
资产治理	Skill与用例资产管理	命名规范检查、重复检测、版本比对	2

合计吸收47个，输出12个能力簇。需要强调的是，这12个簇不是终点，而是一级索引。簇内仍可保留多个实现，但对外只暴露一个入口，簇内实现的选择由入口Skill根据参数决定，不再交给模型在全局范围内猜测。这一改动把“模型选Skill”变成了“模型选能力类型 + 入口Skill选实现”，两级决策的候选规模分别约为12和3至7，均处于可控区间。

4.4 入口Skill的契约设计

入口Skill的契约设计是合并成败的关键。一个可用的入口应满足三点：参数能覆盖簇内主要差异、默认值合理、错误信息能引导模型修正调用。下面给出一个“用例设计”能力簇入口的示意结构（伪代码，非特定框架语法）：

skill: test_case_design
description: >
  面向接口/功能规格生成测试用例。支持边界值、等价类、
  场景法、组合覆盖四种策略，可组合使用。
inputs:
  spec:        {type: object, required: true}   # 规格或接口定义
  strategy:    {type: enum, values: [boundary, equivalence,
                scenario, combinatorial], default: boundary}
  max_cases:   {type: integer, default: 20}
  constraints: {type: array, items: string, default: []}
outputs:
  cases:       {type: array}   # 统一用例结构
preconditions:
  - spec 至少包含一个输入字段定义
errors:
  SPEC_INCOMPLETE: 提示缺失字段，建议先调用规格理解簇

注意 errors 字段的作用：它把簇间协作显式化。当规格不完整时，入口不是返回模糊失败，而是给出可执行的下一步建议。这比让模型在47个Skill中自行摸索要稳定得多。本文评述：错误信息是Skill契约中被长期忽视的部分，它实际上是路由系统的一部分——好的错误信息能把一次失败的调用转化为一次正确的跨簇调用。

五、操作路径：从47到12的七步迁移法

理论说清楚之后，落地需要可执行的步骤。以下七步法来自对该类仓库重构过程的归纳，每一步都有明确的产出物与验收标准，可按序执行，也可在团队规模较小时合并执行。

第一步：盘点与打标

导出全部Skill的声明信息，为每个Skill打上“职能环节”标签（对应4.3节的十二类）。打标由熟悉测试流程的工程师完成，不由模型自动完成——这一步的准确性直接决定后续合并质量。产出物是一张Skill清单表，包含名称、描述、输入输出、依赖、调用频次、最近一次修改时间。验收标准：每个Skill有且仅有一个主职能标签，允许有至多两个次标签。

第二步：统计调用共现

从运行日志中统计Skill的调用序列，计算两两共现频率。共现频率高的Skill对，通常意味着它们在流程上相邻或功能上可合并。产出物是共现矩阵。验收标准：矩阵覆盖最近一个完整迭代周期的日志，样本量足以支撑频率估计（建议不少于数千次调用，具体阈值视调用总量而定）。

第三步：识别高风险簇

结合职能标签与共现矩阵，找出“同职能且高共现”的Skill组，这些就是高风险簇。按3.4节的提示，簇规模超过6至8个即需优先处理。产出物是高风险簇清单及优先级排序。验收标准：清单中的每一组都能说清楚“为什么它们容易被混淆”，而不是笼统地归为“都是测试相关”。

第四步：设计入口契约

为每个高风险簇设计入口Skill的契约，包括参数、默认值、前置条件与错误码。这一步应产出契约文档而非直接写实现，目的是先对齐接口再动手。验收标准：契约能覆盖簇内至少80%的既有调用场景（按日志统计），剩余场景要么归入其他簇，要么明确标记为暂不支持。

第五步：实现与适配

实现入口Skill，把簇内原有实现作为子流程接入。适配的重点是参数映射与错误转换：原有Skill的输入参数映射到入口参数，原有错误码映射到入口错误码。这一步容易出现“入口只是转发、没有真正收敛”的问题，验收时要检查入口是否承担了参数校验与默认值填充的职责，而不是原样透传。

第六步：双轨回归

在切换前，让新旧两套Skill清单并行运行一段时间，用同一评测集对比。对比指标至少包括：任务完成率、无效调用率、平均调用步数、调用路径方差。产出物是对比报告。验收标准：新清单在完成率不下降的前提下，无效调用率与路径方差显著下降。若完成率下降，需定位是契约覆盖不足还是评测集本身有偏。

第七步：下线与固化

确认新清单稳定后，下线旧Skill，并把命名规范、契约模板、评测集维护流程固化为团队规范。这一步常被省略，导致几个月后Skill数量再次膨胀。验收标准：新增Skill必须声明所属能力簇，且不得在已有簇内新增对外入口；确需新增入口的，须走评审。

关于Skill声明格式与工具调用协议的细节，可参考 Anthropic 的工程博客中关于工具使用与提示设计的讨论（anthropic.com/engineering），以及 OpenAI 关于函数调用的官方文档（platform.openai.com/docs/guides/function-calling）。这些资料侧重协议层，本文侧重集合组织层，两者互补。

六、关键数据与案例：合并前后的可验证对比

6.1 数据来源说明

本节数据分为两类，需明确区分。第一类为公开资料，包括工具调用协议文档、检索与排序领域的公开研究结论，用于支撑机制层面的判断。第二类为模拟数据，用于说明合并前后的指标变化趋势，其数值由笔者基于该案例的定性描述与常见工程经验构造，不代表任何特定团队的真实测量结果，读者应将其视为示意而非实证。

模拟数据的构造方式如下：设定47个Skill分布在12个职能环节，其中用例设计、数据构造、失败分析三个环节分别聚集7、6、5个语义相邻Skill；设定评测集包含200条请求，每条请求有明确的目标Skill；路由过程建模为在候选描述向量上的带噪最近邻选择，噪声幅度随候选规模与描述相似度上升。该模型是简化的，仅用于展示趋势方向。

6.2 合并前后的示意对比

指标	47个扁平Skill（模拟）	12个能力簇（模拟）	变化方向
首次调用命中率	约 0.71	约 0.89	上升
无效调用率	约 0.18	约 0.06	下降
平均调用步数	2.6	1.9	下降
调用路径方差	高	低	下降
清单上下文开销	约 4k–9k token	约 1k–2.5k token	下降
混淆对维护量	组合式增长	线性可控	下降

再次强调，上表为模拟数据，用于说明方向而非给出精确数值。真实项目中，命中率的绝对值会因模型、提示、评测集质量而差异很大，但“候选规模压缩带来区分度提升”这一方向性结论在检索与排序的公开研究中有一致支持。

6.3 一个具体的失败归因案例

以“失败分析”簇为例。合并前，该环节有5个Skill：日志解析、堆栈归因、复现脚本生成、环境差异比对、偶现问题识别。面对“这个用例昨天过今天挂，帮我看看”的请求，模型经常先调日志解析，拿到结果后再调堆栈归因，但有时会跳过日志解析直接调偶现问题识别，导致信息不足而失败。

合并后，入口Skill failure_triage 接收原始日志与用例元数据，内部按固定顺序执行解析、归因、偶现判定，并把“环境差异比对”作为可选子流程。模型只需判断“这是不是失败分析类请求”，无需判断“该先调哪个”。这一改动把一次多步决策压缩为一次单步决策，路径方差随之下降。

本文评述：这个案例说明，合并的收益不只来自候选减少，更来自把模型不擅长的“流程排序”转移到了确定性代码中。模型擅长语义判断，不擅长在多步流程中保持稳定顺序。能力簇的入口实际上是一个“流程封装器”，它把顺序性知识从推理期移到了实现期，这是工程上更可靠的安排。

七、数量上限：经验边界、理论约束与反例

7.1 为什么“固定数字”是错的

业界常有人问“Skill最多多少个”，并期待一个数字。笔者认为这个问题本身需要改写。原因有三：其一，Skill的声明信息量差异极大，一个描述20字的Skill与一个描述200字、带复杂Schema的Skill，对上下文的占用不可同日而语；其二，Skill之间的语义距离分布不同，一个高度正交的Skill集合与一个高度重叠的集合，可承受的规模不同；其三，评测集质量不同，覆盖充分的评测集能支撑更大的规模，因为歧义能被及时发现和修正。

因此，数量上限应表述为一个条件性边界：在给定描述信息量、语义正交度与评测覆盖度下，系统能稳定路由的最大候选规模。脱离这三个条件谈数字，没有工程意义。

7.2 三个约束的量化思路

虽然没有普适数字，但三个约束可以分别量化，从而给出团队自己的边界估计。

上下文约束。设单个Skill声明平均占用 t 个token，上下文预算中分配给Skill清单的比例为 p，总预算为 B，则候选规模上限约为 pB/t。以 B=128k、p=0.05、t=150 估算，上限约40余个。这个估算说明，在长上下文模型下，上下文本身通常不是最先触顶的约束——真正先触顶的是区分度。

区分度约束。设候选集中语义最相邻的两个Skill的相似度为 s，模型在该相似度下的判别准确率为 a(s)。当 s 超过某个阈值时，a(s) 快速下降。工程上可通过构造混淆对评测集来估计这个阈值，进而估计在给定描述风格下可稳定区分的候选密度。这一约束通常比上下文约束更早生效。

评测约束。设需要覆盖的混淆对数量为 m，单条评测的维护成本为 c，团队可投入的评测维护预算为 E，则 m ≤ E/c。由于 m 随候选规模呈组合式增长，这一约束往往是最硬的。实践中，团队常在评测覆盖不足时仍继续增加Skill，导致“看起来能用、实际不可控”。

7.3 分层如何抬高上限

分层索引的作用是把上述三个约束同时放松。上下文层面，一级索引只暴露12个入口，清单开销大幅下降；区分度层面，每级候选规模缩小，最相邻对的相似度下降；评测层面，混淆对从全局组合缩减为簇内组合加簇间少量边界对，维护量线性化。

这意味着“上限”不是固定的，而是随索引层数变化的。两层索引（能力簇 + 簇内实现）能支撑的规模，显著高于一层扁平列表。若需要更大规模，可以引入第三层（能力域），但层数增加会带来新的成本：层级判断本身也需要模型决策，层数过多会让“选层”变成新的歧义来源。笔者建议层数控制在两到三层，超过三层后收益递减且调试困难。

7.4 反例：什么时候不该合并

合并并非总是正确。以下情形应保持拆分：权限边界不同的Skill（如涉及生产环境写入与只读查询），合并后难以做细粒度授权；执行环境隔离的Skill（如本地执行与远程沙箱），合并会引入不必要的依赖；计费或审计要求不同的Skill，合并会模糊成本归属。这些情形下，拆分带来的管理清晰度高于合并带来的路由收益。

本文评述：这说明“按能力类型合并”是一条主线索，但不是唯一原则。工程决策永远是权衡，能力类型解决的是语义歧义，权限、环境、计费解决的是治理边界。当两者冲突时，应以治理边界优先，因为语义歧义可以通过描述优化部分缓解，而治理边界一旦模糊，会带来合规与安全风险。这一点在测试场景中尤其重要，因为测试Skill经常需要触碰生产数据的脱敏副本。

八、对比与局限：分层索引不是银弹

8.1 与其他组织方式的对比

组织方式	优点	局限
扁平列表	实现简单，新增无门槛	规模一大即失控，评测难覆盖
按对象分（接口/UI/性能）	直观，与团队分工对齐	类别重叠，同一职能散落多处
按能力类型分层（本文）	候选压缩，评测可控，契约稳定	前期设计成本高，需治理机制配套
向量检索动态召回	规模弹性好，无需人工分类	召回质量依赖嵌入模型，可解释性弱

向量检索动态召回是一种值得关注的替代路线：不预先分类，而是每次请求动态召回top-k个Skill。它在大规模场景下有优势，但有两个实际问题。其一，召回质量依赖嵌入模型对测试领域术语的理解，通用嵌入模型在“边界值”“等价类”这类术语上的区分度未必足够；其二，动态召回的可解释性弱，出问题时难以定位是召回错了还是选择错了。笔者认为，分层索引与动态召回可以结合：一级用能力类型做硬分类，二级在簇内用向量召回，兼顾可控性与弹性。

8.2 本文方法的局限

必须承认，能力类型划分带有主观性。十二类划分依据测试活动的基本环节，但不同组织的流程差异会导致边界不同：有的团队把“环境准备”并入“执行编排”，有的把“缺陷管理”并入“失败分析”。这种主观性不影响方法有效性，但意味着划分结果不能直接照搬，需要按团队实际调整。

其次，入口Skill的契约设计需要较强的接口抽象能力。把多个Skill的差异收敛为参数，要求设计者同时理解各实现的细节与共性，这不是所有团队都具备的条件。契约设计不当会导致“入口臃肿”或“入口透传”，前者让模型难以填参，后者等于没合并。

第三，本文的模拟数据不能替代真实测量。方向性结论有公开研究支撑，但具体收益幅度必须由各团队用自己的评测集测量。任何声称“合并后必然提升X%”的说法都缺乏普适性。

8.3 与相关研究的关联

Skill路由问题与工具学习（tool learning）研究密切相关。该方向关注模型如何理解工具描述、选择工具并填充参数，公开研究普遍指出描述质量与候选规模是影响成功率的关键因素。本文的贡献不在于提出新的路由算法，而在于从工程组织角度给出可操作的集合重构路径。若读者希望深入了解工具学习的学术脉络，可参考该领域近年综述（见文末参考文献），并注意区分学术基准与工程场景的差异：学术基准的候选规模通常较小，工程场景的候选往往更多且语义更拥挤。

在检索与排序方面，候选规模对排序质量的影响是经典议题。本文借用其结论解释Skill路由，但需说明类比边界：检索的查询与文档是异质的，而Skill选择中请求与描述同为自然语言，同质性更高，这既让语义匹配更容易，也让近义干扰更严重。这一差异意味着检索领域的经验不能直接照搬，需要针对同质候选做专门设计。

九、结论与展望：把Skill当接口治理，而不是当文件堆放

回到开头的问题：Skill数量到底有没有上限？本文的答案是——有，但它不是一个固定数字，而是描述信息量、语义正交度、评测覆盖度与索引层数共同决定的条件性边界。47个测试Skill之所以让AI“不知道用哪个”，根因不在数量本身，而在扁平列表把结构性问题摊平成了语义匹配问题。按能力类型合并为12个能力簇，本质是给候选集建立一级索引，把一次大范围检索拆成两级小范围检索，从而同时缓解路由歧义、上下文开销与评测熵增。

在操作层面，七步迁移法给出了从盘点到固化的完整路径，其中双轨回归与治理固化是最容易被跳过、也最不该跳过的两步。在边界层面，权限、环境、计费三类治理边界应优先于语义合并，冲突时以治理为先。在展望层面，分层索引与向量召回的结合、以及面向Skill集合的自动化一致性检查，是值得投入的方向。

笔者认为，Skill治理的长期命题是把Skill当接口治理，而不是当文件堆放。接口治理的核心是契约、版本、兼容性与废弃策略；文件堆放的核心是“先加上再说”。前者让规模增长可控，后者让规模增长成为负债。测试领域的Skill尤其需要前者，因为测试活动本身强调可重复与可验证——如果Skill集合自身都不可重复、不可验证，用它来保障质量就失去了逻辑基础。

最后给出一条可立即执行的建议：不要急着数Skill总数，先数一数“语义最相邻的那一簇有几个”。如果超过8个，就从那一簇开始合并，用双轨回归验证，再逐步推广。这比一次性重构全部47个Skill风险更低，也更容易在团队内形成共识。

参考文献与拓展资源

文章声明