如果你也在支持 Skill 的 AI 编码助手里装了一堆 Skill，却发现越用越卡、越用越乱——我之前也是这样，这篇整理的就是在这个过程中摸索出来的一些经验。
如果你自己动手写过 Skill，但还没来得及把质量兜底的机制搭起来，下面这些踩坑后的整理可能也值得一读。

---

一、先说一个很多人没意识到的问题：Skill 不是装得越多越好

如果你也在用 AI 编码助手，大概率经历过这样的场景：

看到社区里有人分享了一个"自动生成操作手册"的 Skill，装上；又看到一个"浏览器自动探索页面"的 Skill，装上；再来一个"数据报表自动出图"的，装上；还有"代码审查"“磁盘清理”“游戏设计文档”……一个接一个，列表越来越长。

然后某天你随口说一句"帮我扫描这个页面"，AI 居然犹豫了一下，或者干脆调了个你不熟悉的 Skill 去执行，结果跟你想的不一样。再或者，你发现每轮对话的 token 消耗肉眼可见地涨上去了，响应也变慢了，但你说不清是哪个 Skill 在拖后腿。

更尴尬的是，有些 Skill 是你自己照着教程写的，跑 demo 没问题，一上真实业务就各种翻车——缺了信息不追问直接编、遇到异常直接崩、把几万字说明一股脑塞进上下文。

问题不在于 Skill 本身不好，而在于缺少一套把它们"查清楚"的机制——谁和谁重复、谁会抢响应、谁不靠谱，这些问题不先诊断出来，想管也无从下手。

怎么把已经装上去的一堆 Skill 查清楚——谁和谁在重复、谁会抢着响应同一个请求、谁占资源太多、谁其实根本不靠谱，以及针对每个问题给出留/并/改/删的建议。写 Skill 的部分也会顺带整理一下：那些容易踩的边界坑，其实是有规律可循的。

---

二、问题到底出在哪：三类典型症状

在动手解决之前，先把"越用越乱"这件事拆开看。实际环境中，问题通常归为三类。

症状一：多个 Skill 抢着响应同一个请求

这类问题只出现在特定操作方式下,先说清楚什么情况会触发、什么情况不会。

不会出现的情况(可以放心用):

• 你用斜杠命令显式调用,比如 /explore-tool 探索这个系统——IDE 已经把请求直接路由给 explore-tool,不经过自然语言匹配,AI 不会"犹豫"
• 你在消息里明确点名 Skill,比如"用 explore-tool 帮我探索这个系统"——AI 会优先按你的明确意图走
• 你的 IDE 提供手动选择 Skill 的入口,你从列表里点了一个——同样绕过了自动路由

会出现的情况(需要警惕):

• 你只用自然语言描述需求,不点名任何 Skill,比如直接说"帮我扫描这个页面"“探索一下这个系统”——这时候 AI 会拿你的话去匹配所有 Skill 的 description,谁匹配度高就调谁
• 你装的 Skill 数量多了(十几个以上),而且其中几个的 description 触发词重叠——比如好几个浏览器相关的 Skill 都写着"浏览器"“自动化”“扫描页面”,你说"帮我扫描这个页面",AI 会发现好几个都匹配,路由就变得不确定
• 更麻烦的是,即使这次调了 A,下次同样的话可能调 B,结果不稳定,你还不一定意识到是路由在飘

举个具体例子:装了三个浏览器探索类 Skill——A、B、C,它们的 description 里都有"浏览器"“页面”“采集"这些词,而且都没写"何时不要调用"的说明。你说"帮我看看这个页面有什么元素”,AI 可能在 A、B、C 之间随机选一个。如果三个 Skill 的探索深度、产出格式不一样,你拿到的结果就不稳定——明明是同一个请求,这次详细、下次简略,排查起来很费劲。

根因是:这些 Skill 的 description 只写了"能干什么",没写"不能干什么"(也就是没有"反触发"说明),触发面重叠太大。注意,问题不在 Skill 数量多,而在于触发面重叠 + 缺反触发说明——数量再多,只要每个 Skill 的触发面清晰、互不重叠,自然语言路由一样稳定。

症状二：上下文被撑爆，token 烧得心疼

这个症状的出现也是有条件的,跟 Skill 自身的加载机制和你怎么用都有关系。

会明显感觉到的情况:

• Skill 本身的说明文档特别长(几万字),而且没有做分层加载——被激活后,每次对话都会把全文塞进上下文(这类叫"常驻加载")
• 你同时激活了好几个这种"常驻大块头"Skill——单个 5000 token 不显眼,五六个叠起来就是两三万,每轮对话的固定成本就上去了
• 对话轮次多、上下文累积长的时候——常驻部分是每轮都重新计入的,轮次越多,重复消耗越明显

不太会感觉到的情况:

• Skill 做了分层加载(把 SKILL.md 拆成"常驻索引 + 按需加载的分块"),只有索引常驻,正文用到时才加载——这种即使总文档量大,常驻成本也低
• 你只激活了一两个 Skill,而且单个文档不大——成本增量在噪声范围内
• IDE 对 Skill 的加载策略本身有优化(比如只加载 description 用于路由,正文按需展开)——这时候"常驻"的其实只是 description

所以这个症状的根因要分两层看:Skill 自身没做分层加载是内因,同时激活多个大块头 Skill是外因,两个叠加才会明显感觉到 token 消耗和响应变慢。

症状三：自己写的 Skill 跑 demo 没问题，上真实业务就翻车

这个症状的出现条件比较直接——只要你写 Skill 的时候只想着理想流程,没考虑异常和边界,真实业务一定会撞上。但撞上的具体场景是有规律的:

容易翻车的场景:

• 输入数据不完整或有脏数据——比如用户给的文件路径不存在、Excel 列名跟预期对不上、API 返回了空字段。如果 Skill 缺了信息不追问直接编,就会产出看起来对、其实错的结果
• 文件编码、格式异常——比如遇到带 BOM 的 UTF-8、GBK 编码的中文文件、超大文件(几十 MB)。如果 Skill 只有"正常读文件"一条路径,遇到这些直接崩
• 处理量超出预期——比如 Skill 设计时假设一次处理几百行,真实业务喂进来几万行,上下文爆了或者超时
• 多轮交互中状态丢失——比如 Skill 用临时变量记中间结果,没有落盘,中间断一次续跑就丢

不容易翻车的场景:

• 输入永远是规整的 demo 数据,字段齐全、编码统一、规模可控——这种场景下,只要核心逻辑写对了,Skill 就能跑
• 任务是单次、无状态的——不依赖中间产物、不需要断点续跑,出错重试就行

所以这个症状的根因是:写 Skill 的时候只验证了"理想路径能走通",没验证"异常输入会怎样、边界在哪、出了错能不能兜住"。demo 跑通只是起点,真实业务的鲁棒性靠的是异常处理、边界约束和产出校验。

这三类问题，光靠人肉翻 Skill 文件是很难查全的——装了 30 个 Skill，两两组合就是 400 多对，手工比对不现实。真正能帮上忙的，是一套能自动把冲突关系找出来、自动给每个 Skill 的健壮性打个分的机制。

下面就来拆解这两套机制。

---

三、机制一：冲突矩阵——把 Skill 之间的"暗斗"摆到台面上

什么是冲突矩阵

简单说，就是一张"N × N"的表，行和列都是你装的 Skill，交点的单元格写明"这两个 Skill 之间有没有冲突、什么类型的冲突、有多严重"。

但"冲突"这个词太笼统了，实际中至少有 5 种完全不同的冲突类型，检测方法和影响都不一样：

编号	通俗名	到底是什么	怎么检测
C1	功能重复	两个 Skill 干的是同一件事	仅同功能域内比对：description 关键词重叠 ≥20（或 ≥8 且相似度 ≥0.12）；跨域不做 C1 判定
C2	抢着响应	同一个请求会命中多个 Skill	非模板词交集 ≥4 且至少一方没写"反触发"；跨域对需更高信号：交集 ≥8 且相似度 ≥0.15
C3	占资源	常驻加载体积过大、没分层	常驻 token 超阈值且无分块加载
C4	共享依赖	共用同一个配置/数据库/状态文件，一方改动静默破坏另一方	引用的资源路径/表名/环境变量相同
C5	抢工具	同一个浏览器/端口/MCP 工具被多个 Skill 抢占	声明了同一个运行时资源

这五种里，C1、C2 是"路由层"的冲突——直接影响 AI 会调谁；C3 是"成本层"的冲突——影响每轮花多少 token；C4、C5 是"运行时"的冲突——可能导致一个 Skill 改了东西，另一个悄悄坏了。

检测怎么做：静态比对 + 语义确认

如果纯靠 LLM 去读每个 Skill 的正文再判断，30 个 Skill 要读 30 份文档，token 消耗惊人。所以更合理的做法是两层：

第一层：纯静态比对，不耗 LLM 上下文。 用脚本把所有 Skill 的 description、目录结构、引用的文件路径、声明的工具都扫一遍，用规则算相似度和交集，产出"冲突候选"。比如：

• C1 用 description 关键词的 Jaccard 相似度 + 交集数量判定
• C2 看非模板词的交集大小，以及有没有"何时不要调用"的说明
• C3 估算常驻加载的 token 数（SKILL.md + 每次必加载的分块索引）
• C4 提取每个 Skill 引用的配置文件名、数据库表名、环境变量名，精确比对
• C5 提取声明的 MCP 工具、浏览器、端口，精确比对

这一层跑完，你会得到一份类似这样的候选清单（JSON 片段）：

{
  "C1": [
    {
      "skill_a": "docs-skill-a",
      "skill_b": "docs-skill-b",
      "jaccard": 0.848,
      "overlap_count": 84,
      "keywords": ["文档", "在线", "新建"],
      "severity": "candidate"
    }
  ],
  "C2": [
    {
      "skill_a": "browser-skill-a",
      "skill_b": "browser-skill-b",
      "overlap_count": 6,
      "keywords": ["浏览器", "自动化"],
      "severity": "medium"
    }
  ]
}

注意 severity 这里是 candidate（待确认）——因为静态比对只能给出"嫌疑"，到底是不是真冲突、严重度多高，还需要读正文确认。

第二层：LLM 按分组确认证据。 把候选冲突按功能域分组，每组一批读双方正文，确认证据、判定严重度。关键是：高严重度的冲突必须有至少 2 条独立证据，否则只能标"待确认"，避免误判导致你误删 Skill。

一个容易被忽略的细节：基础设施型共享

有一种情况要特别处理：某个资源（比如一个公共配置文件、一个公共数据库）被 4 个以上的 Skill 引用。如果按两两组合生成冲突对，矩阵会爆炸（C(30,2) = 435 对）。

正确的做法是：这种"基础设施型共享"单独聚合展示，标个低严重度，不生成两两对。因为大家都用同一个公共资源是正常的，只有当其中一方改动可能影响其他人时才需要关注。

另一个容易被忽略的问题：Skill 多了，候选会爆炸

上面说的基础设施型共享是"资源被多人引用"导致的爆炸。还有另一种爆炸更棘手：Skill 数量本身多了，两两组合的候选对数量是 O(N²) 增长的。

• 20 个 Skill → C(20,2) = 190 对,逐个核对还扛得住
• 100 个 Skill → C(100,2) = 4950 对,逐个精析 token 就爆了
• 300 个 Skill → C(300,2) = 44850 对,根本跑不动

如果对所案例都套同一套"全量精析"方案,小规模浪费、大规模崩盘。更合理的做法是按规模分档,少则精、多则省:

档位	活跃 Skill 数	冲突候选处理	报告形式
S1 精细	≤20	不降噪,保留全部真候选,逐冲突核对	完整 9 部分明细,无附录
S2 标准	21~80	不降噪,保留全部真候选,分批精析	完整 9 部分明细,无附录
S3 摘要	81~300	C1/C2 候选按功能域分组后,每域每类型只保留相似度最高的 Top-15 组	主报告(汇报层 + Top 冲突/处方) + 按功能域拆附录
S4 极限	>300	Top-K 收紧到每域每类型 10,且同类型处方批量聚合	同 S3,但降噪更狠、处方聚合

这个分档的关键在于:降噪只动 C1/C2 候选,而且是按功能域分组后域内排序取 Top-K——不是全局砍,是每个域里只留最像的那几对。实测数据:150+ Skill(S3)候选收敛到 294 组;361 Skill(S4)候选 200 组、处方经聚合从数百条降到 184 条。

报告形式也跟着档位变:S1/S2 给完整明细报告;S3/S4 切成"摘要主报告 + 每功能域附录"——主报告只放汇报层和 Top 冲突/处方,完整明细按域拆到附录文件里。这样大规模场景下主报告不会膨胀到无法阅读,想深究某个域再去翻对应附录。

这里还有个设计细节值得提一句:Skill 数量到 S3/S4 级别时,处方也会批量聚合——比如 50 个 Skill 都缺 CHANGELOG,原本会生成 50 条 maintain 处方,聚合后变成一条"以下 50 个 Skill 建议补 CHANGELOG"。但 merge/boundary/schedule 这类需要逐对决策的处方不聚合,保持每个冲突对独立给建议。

---

四、机制二：健壮性检测——一个 Skill 靠不靠谱怎么看

冲突矩阵解决的是"Skill 之间"的关系问题。但还有一类问题：一个 Skill 单独看，到底靠不靠谱？ 这就需要另一套机制——成熟度评分。

为什么要分维度，不能只打一个总分

如果只给一个"好不好用"的总分，你不知道问题出在哪，也没法针对性改。更合理的是拆成几个维度，每个维度独立打分 + 给证据。

参考业界已有的几套 Skill 评测框架（六轴结构评分、企业级 Skill 评测、五维质量体系），可以归纳出八个维度，覆盖一个 Skill 从"能不能被正确触发"到"能不能长期维护"的全链路：

#	维度	满分	满分长什么样	扣分信号
1	触发契约	15	description 写清"做什么+何时调用+何时不调用"	description 太短、没有反触发
2	流程机制	15	有编号的阶段/步骤，每步有输入产出	通篇人设形容词、无步骤
3	异常与熔断	12	缺信息会停下追问、有 fallback、有最大轮次	缺材料直接编、无失败处理
4	产出控制	13	有中间产物、交付前自检、有验收标准	执行完直接输出
5	边界与上下文	12	明确可读范围、有阈值、有分层加载	无边界、单文件超长
6	内容价值密度	13	核心是业务方法论和判断规则	只有输出模板、常识占大头
7	工程配套	10	有可执行工具层、配置、README、版本	需要工具层却没有
8	维护健康度	10	有 CHANGELOG、版本号、更新痕迹	只有 zip 备份、文档不一致

八个维度满分加起来正好 100 分。

评分也要分两层：静态信号 + 语义判断

和冲突检测一样，评分也不能纯靠 LLM 从头读。同样是两层：

第一层：脚本扫静态信号。 对每个维度，脚本会去文件里找"候选证据"——比如维度 1（触发契约）会检查 description 长度、有没有"何时调用/不要调用"这类词；维度 5（边界）会检查有没有分块加载结构、估算 token 数。输出长这样：

{
  "name": "skill-medic",
  "desc_len": 196,
  "desc_has_antitrigger": true,
  "dim1_trigger": ["何时调用", "应触发", "不要调用"],
  "dim2_flow": ["阶段", "当"],
  "dim3_exception": ["信息不足", "失败", "重试", "熔断"],
  "dim4_output": ["自检", "中间产物"],
  "dim5_boundary": {"hits": ["分层", "chunk"], "has_chunks": true},
  "dim7_engineering": {"has_tools": true, "has_readme": true},
  "dim8_maintain": {"has_changelog": true}
}

关键理解：信号命中 ≠ 得分。 命中词只是"候选证据"，最终给多少分要由 LLM 结合正文判断。反过来，某个维度信号为空是真实的扣分线索——比如维度 4 一个自检词都没命中，那这个 Skill 的"产出控制"大概率有问题，要重点查。

第二层：LLM 对照细则逐维打分。 结合静态信号 + 抽样正文，每个维度给分 + 一句话证据 + 扣分定位（具体哪个文件哪一节）。

评分口径必须锁死

这里有个容易踩的坑：如果 LLM 每次评分口径都不一样（这次每维打 0-100 再加权，下次每维打 0-满分），结果就不可复现。所以评分规则必须强约束：

• 每维给分上限 = 该维满分（比如维度 1 满分 15，只能给 0~15）
• 总分 = 八维之和（满分 100）
• 定级阈值固定：≥80 分是 L3，55~79 是 L2，30~54 是 L1，<30 是 L0

四档评级到底在衡量什么

这点必须说清楚，否则容易被误读成"评分高 = 很安全"。这套评级衡量的是 Skill 的"可靠性 / 完成度"——能不能稳定把它承诺的功能执行到位；不是"安不安全"（数据安全与合规是另一回事，不在这个评分里）。

级别	通俗名	得分	准确含义
L3	放心用	≥80	能稳定完成承诺的功能，复杂场景也可靠，出问题能自己兜住
L2	基本能用	55~79	常规场景能完成，但缺异常处理/自检，复杂输入可能出错
L1	不太成熟	30~54	只能处理理想样例，真实业务容易翻车
L0	不建议用	<30	基本不可用，用了大概率白折腾

---

五、把两个机制串成一条流水线

冲突矩阵和健壮性评分单独看都有用，但真正解决问题需要把它们串起来。完整的流程是这样的：

范围扫描 → 清单盘点 → 三维分类 → 冲突检测 → 评分 → 综合处方 → 报告输出 → 完成

每一步的职责和产出：

阶段	做什么	产出
范围扫描	确定查哪些目录（workspace + 全局）	扫描范围声明
清单盘点	只读 frontmatter + 目录树 + 静态指标，不读正文	Skill 清单 JSON
三维分类	按功能域 / 交互模型 / 生命周期分类	分类表
冲突检测	静态比对 + LLM 确认证据	冲突矩阵
评分	静态信号 + LLM 八维打分	评分表
综合处方	冲突矩阵 × 评分 → 处方建议	处方清单
报告输出	生成结构化报告	检查报告

这里有几个设计细节值得展开说。

细节一：清单盘点阶段绝对不读正文

为什么？因为读正文是 token 大头。30 个 Skill 每个读一遍正文，可能就是十几万 token，还没开始分析上下文就满了。所以清单阶段只读 frontmatter（name/description/version）和目录结构，算个 token 估算值就够了。正文留到后面需要确认证据时，按分组、按批次读。

细节二：三维分类是冲突检测和评分的分组基础

分类不是走过场。按功能域分组后，同组的 Skill 才是"最可能冲突"的——两个都做"文档生成"的 Skill 才需要重点比对，一个做"文档生成"一个做"磁盘清理"的几乎不可能冲突。评分也按组分批，每批控制在 3 个 Skill 以内，每批正文预算不超过 1 万 token，避免单批超限。

细节三：处方不是简单的"删掉"

综合处方要把冲突和评分结合起来看，不是看到冲突就让删。常见的处方类型有：

处方	适用场景
保留 A，合并 B	功能重复，B 的能力被 A 覆盖
保留 A、B，划清边界	功能相关但有差异，各自补"反触发"说明
保留 A、B，明确分工顺序	分层协作但有抢占风险，定好谁先谁后
整改（瘦身/加边界/加反触发）	单个 Skill 膨胀或误触发
移除/归档	已废弃、被完全取代

而且有个铁律：只出处方，不代执行。所有合并/归档/改文件的操作都要用户确认后手动做——因为自动删 Skill 太危险，万一误判呢。

细节四：独立审核，不能自己查自己

整条流水线里还嵌了一个独立的审核角色（auditor），在三个关键节点做盲审：

1. 评分之后——审分类标签有没有证据、高分冲突证据够不够、评分口径有没有跑偏
2. 处方之后——审处方和冲突矩阵是不是一致
3. 报告出来之后——审报告完不完整、汇报层数据和明细层数据有没有矛盾

盲审的意思是：审核方只拿静态指标和各阶段的最终产物文件，不接收主控的路由判断和其他角色的推理过程。证据不足时，要自己重新读被检 Skill 的文件复核。发现问题就打回重做，同一节点重试 3 次还不行就标记失败转人工。

---

六、跑一遍看看：真实环境的检查报告长什么样

说了这么多原理,来看实际效果。前面讲的这套"冲突矩阵 + 健壮性评分"机制,我自己把它实现成了一个叫 skill-medic 的工具——下文提到的检查流程、报告格式、FAQ 里讨论的行为,指的都是这个工具。这里先把它是什么交代清楚,后面再看到相关内容就不会突兀。

在一个装有 20 多个 Skill 的真实环境里,用 skill-medic 跑完整流程,最终会生成一份结构化的 Markdown 报告,分"人话汇报层"和"专业明细层"两部分。

人话汇报层：给只想用 Skill 的人看

报告开头不是一堆术语，而是一段大白话总结。比如：

健康度总评：本次共检查 29 个 Skill。放心用（L3）7 个 ｜ 基本能用（L2）5 个 ｜ 不太成熟（L1）1 个 ｜ 不建议用（L0）1 个。

放心用（L3）：示例 Skill A、示例 Skill B……
不太成熟（L1）：示例 Skill C——只适合演示，处理真实业务文档容易出错，别用在正式项目。

接着是"最需要注意的问题 TOP 榜"，每条都是三句话：问题是什么 / 影响你什么 / 建议怎么办。比如：

问题：浏览器探索类 Skill 有 2 个触发面高度重叠
影响：当你说"帮我扫描页面"时，AI 可能随机选一个，结果不稳定
建议：以后明确说用 A 还是 B，或者只保留一个

最后是"你现在最该做的 2~3 件事"——只给不用改文件的使用类建议，普通用户直接照做就行。

专业明细层：给想深究或想改 Skill 的人看

往下翻是完整的清单表、分类表、冲突矩阵、八维评分明细、处方清单、历史对比。比如冲突矩阵部分长这样：

A × B	冲突类型	冲突点	严重度	影响你什么
docs-skill-a × docs-skill-b	功能重复（C1）	文档在线新建，相似度 0.85	高	两个做同一件事，不知道该用哪个，建议只留一个
browser-skill-a × browser-skill-b	抢着响应（C2）	浏览器自动化，交集 6 词	中	说"扫描页面"时两个都会响应，AI 随机选
big-skill	占资源（C3）	常驻 7000+ token，无分层	中	每次对话都加载约 7000 字说明，拖慢响应

八维评分明细则会列出每个 Skill 每一维的得分、扣分定位（具体哪个文件哪一节），以及一句通俗评估。

行动建议按角色分流

报告最后的"行动建议"是分两栏的：

• 7.1 使用建议（给 Skill 的使用者）：不用改文件，覆盖"注意什么/有什么风险/什么需求别指望它"
• 7.2 改造建议（给 Skill 的创建者/维护者）：需改文件，包含精确的文件路径 + 改动内容 + 执行方式 + 优先级

这样，只是用 Skill 的人看 7.1 就够，想根治的转发给 Skill 作者处理 7.2。

---

七、写 Skill 时容易踩的边界坑

如果你自己也写 Skill，上面的检查流程其实会把常见的"反模式"一个个暴露出来。这些坑是有规律的，整理出来对照着看，能少走不少弯路。

反模式 1：纯角色扮演，无流程控制

通篇写"你是一位 XX 专家，要专业、严谨、全面"，没有编号步骤、没有阶段节点。结果是任务完全交给模型自由发挥，换个场景就崩。

相对稳妥的做法：任务拆成有序的阶段/步骤，每步有唯一目标和输入产出。

反模式 2：只有输出模板，没有业务方法论

只规定了输出长什么样（表格、报告格式），但没说怎么得到这份结果。遇到模糊输入，模型直接编数据填进模板。

相对稳妥的做法：把信息抽取规则、冲突取舍标准写进去，模板只是最后一步的外壳。

反模式 3：缺信息直接脑补

用户输入不完整时不追问，直接编造缺失信息补齐。产出不可信，风险全转给用户。

相对稳妥的做法：信息不足时停下，明确列出还缺哪些材料，不编造。

反模式 4：无异常处理，单一路径

只有一条理想路径，没有分支判断、没有 fallback。遇到坏文件、编码错误、超长文档直接崩。

相对稳妥的做法：设计分支逻辑，失败有回退方案。

反模式 5：无边界约束，上下文膨胀

不限定可读文件范围、不限定最大处理量，常驻加载数万 token。Skill 越多，每轮成本越高。

相对稳妥的做法：明确阈值、分层加载、超限拒绝。

反模式 6：无自检直接交付

执行完直接输出，没有自查。模型幻觉、遗漏直接流入最终产物。

相对稳妥的做法：交付前强制 checklist 自检。

反模式 7：无触发契约，什么请求都接

description 只写"能干什么"，不写"不能干什么"。别的任务也乱调用，污染上下文。

相对稳妥的做法：同时写"何时调用"和"何时不要调用"。

这七条反过来，其实就是八维评分里维度 1~5 要考察的核心内容。写 Skill 的时候对照着自查一遍，比起上线了再被检查出问题，要省事不少。

---

八、还有一个容易忽略的能力：增量审计

Skill 不是静态的——你会装新的、改旧的、删不用的。如果每次都全量查一遍，既慢又浪费。更合理的是支持增量审计：和上次的清单对比，只精析新增和变更的项。

实现上也不复杂：每次检查完，把本次清单归档为"上次清单"（_medic_last_inventory.json），下次检查时先做一次 diff：

{
  "added": ["browser-skill-b", "docs-skill-c"],
  "removed": ["old-skill"],
  "changed": ["report-skill-a"]
}

然后只对 added 和 changed 的项跑精析，其余沿用上次的分类和评分。报告里还会有一栏"上次的问题解决了吗"，形成闭环。

对于团队场景，这个能力特别有用：合并改动前跑一遍增量审计，确认没有引入新的冲突，再合进去。

---

九、关于 skill-medic，你可能想问的几个问题

上面几章把 skill-medic 的检查流程和报告都过了一遍，下面是几个使用前大家常会担心的问题，一并说清楚。

Q：会不会误判导致我误删 Skill？
不会。skill-medic 只给建议不代执行，所有改动需你确认后手动做；而且高严重度冲突必须有至少 2 条独立证据，证据不足的标"待确认"。

Q：会不会越界读我的业务数据？
不会。skill-medic 只做"抽象层"检查——识别类型、看关系、查体积、提取资源依赖的字段名和路径。不读业务数据内容、不读服务器配置值、不分析业务逻辑对不对（那是另一类单体质量自检工具的活）。密钥只记字段名不记值。

Q：中途中断了怎么办？
skill-medic 有断点续跑机制。每一步的产出都即时落盘，中断后再次调用会从断点继续，不丢进度。

Q：评分标准会过时吗？
skill-medic 的评分标准是版本化的（内置基线 8-axis-v0.1）。超过 30 天没更新、或首次使用时，会联网搜最新的 Skill 评测标准，吸收进来。但联网标准和内置冲突时以内置为准，差异记录在报告里。

Q：Skill 装了几百个，跑得动吗？
跑得动。skill-medic 按活跃 Skill 数自动分四档（S1 ≤20 / S2 21~80 / S3 81~300 / S4 >300），大规模场景下 C1/C2 候选按功能域分组后只保留 Top-K，报告切成"摘要主报告 + 每域附录"。实测 361 个 Skill 场景：候选从 O(N²) 的 6.5 万对收敛到 200 组，处方经聚合降到 184 条。

Q：能不能查得更严一点？
可以。触发时说"严格模式"即可——评分时要求强证据才给分、低证据一律标"待确认"，审核抽检率从 30% 提到 50%，冲突全量精析，定级阈值不变但判定更保守。适合重要任务前的一次性从严体检。

---

十、写在最后

回到开头的那个问题：Skill 不是装得越多越好。真正影响使用体验的，不是数量，而是有没有被查清楚——冲突在哪、谁不靠谱，诊断清楚了，留谁删谁自然就有数了。

三套核心机制：

1. 冲突矩阵——用静态比对 + 语义确认两层方式，把 5 类冲突（功能重复 / 抢着响应 / 占资源 / 共享依赖 / 抢工具）自动找出来，高严重度必须有多条证据。
2. 健壮性评分——用静态信号 + 语义判断两层方式，从 8 个维度给每个 Skill 打分，定出四档成熟度（放心用 / 基本能用 / 不太成熟 / 不建议用）。
3. 规模分级——按活跃 Skill 数自动分四档（S1/S2/S3/S4），大规模场景下候选按功能域分组 Top-K 降噪、报告切摘要主报告 + 附录，少则精多则省，不套一套方案。

把它们串成一条带独立审核的流水线，跑一遍就能得到一份"人话汇报 + 专业明细"双层的检查报告，针对每个冲突和每个 Skill 给出留/并/改/删的建议——注意，只是建议，真正的合并、归档、改文件这些动作都需要你自己确认后手动执行。

如果是用 Skill 的人，定期用 skill-medic 跑一遍体检，心里对哪些能用、哪些别依赖有个数就好；如果是写 Skill 的人，那七个反模式可以当作自查清单，发布前过一遍心里更有底。

感兴趣的可以下载来用用看：

GitHub 地址： https://github.com/songzhou666/skill-medic/releases

---