Skill 装得越多反而越卡越乱，是时候进行一次冲突检查了

如果你也在支持 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.15C3占资源常驻加载体积过大、没分层常驻 token 超阈值且无分块加载C4共享依赖共用同一个配置/数据库/状态文件一方改动静默破坏另一方引用的资源路径/表名/环境变量相同C5抢工具同一个浏览器/端口/MCP 工具被多个 Skill 抢占声明了同一个运行时资源这五种里C1、C2 是路由层的冲突——直接影响 AI 会调谁C3 是成本层的冲突——影响每轮花多少 tokenC4、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~300C1/C2 候选按功能域分组后,每域每类型只保留相似度最高的 Top-15 组主报告(汇报层 Top 冲突/处方) 按功能域拆附录S4 极限300Top-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触发契约15description 写清做什么何时调用何时不调用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 分是 L355~79 是 L230~54 是 L130 是 L0四档评级到底在衡量什么这点必须说清楚否则容易被误读成评分高 很安全。这套评级衡量的是 Skill 的可靠性 / 完成度——能不能稳定把它承诺的功能执行到位不是安不安全数据安全与合规是另一回事不在这个评分里。级别通俗名得分准确含义L3放心用≥80能稳定完成承诺的功能复杂场景也可靠出问题能自己兜住L2基本能用55~79常规场景能完成但缺异常处理/自检复杂输入可能出错L1不太成熟30~54只能处理理想样例真实业务容易翻车L0不建议用30基本不可用用了大概率白折腾五、把两个机制串成一条流水线冲突矩阵和健壮性评分单独看都有用但真正解决问题需要把它们串起来。完整的流程是这样的范围扫描 → 清单盘点 → 三维分类 → 冲突检测 → 评分 → 综合处方 → 报告输出 → 完成每一步的职责和产出阶段做什么产出范围扫描确定查哪些目录workspace 全局扫描范围声明清单盘点只读 frontmatter 目录树 静态指标不读正文Skill 清单 JSON三维分类按功能域 / 交互模型 / 生命周期分类分类表冲突检测静态比对 LLM 确认证据冲突矩阵评分静态信号 LLM 八维打分评分表综合处方冲突矩阵 × 评分 → 处方建议处方清单报告输出生成结构化报告检查报告这里有几个设计细节值得展开说。细节一清单盘点阶段绝对不读正文为什么因为读正文是 token 大头。30 个 Skill 每个读一遍正文可能就是十几万 token还没开始分析上下文就满了。所以清单阶段只读 frontmattername/description/version和目录结构算个 token 估算值就够了。正文留到后面需要确认证据时按分组、按批次读。细节二三维分类是冲突检测和评分的分组基础分类不是走过场。按功能域分组后同组的 Skill 才是最可能冲突的——两个都做文档生成的 Skill 才需要重点比对一个做文档生成一个做磁盘清理的几乎不可能冲突。评分也按组分批每批控制在 3 个 Skill 以内每批正文预算不超过 1 万 token避免单批超限。细节三处方不是简单的删掉综合处方要把冲突和评分结合起来看不是看到冲突就让删。常见的处方类型有处方适用场景保留 A合并 B功能重复B 的能力被 A 覆盖保留 A、B划清边界功能相关但有差异各自补反触发说明保留 A、B明确分工顺序分层协作但有抢占风险定好谁先谁后整改瘦身/加边界/加反触发单个 Skill 膨胀或误触发移除/归档已废弃、被完全取代而且有个铁律只出处方不代执行。所有合并/归档/改文件的操作都要用户确认后手动做——因为自动删 Skill 太危险万一误判呢。细节四独立审核不能自己查自己整条流水线里还嵌了一个独立的审核角色auditor在三个关键节点做盲审评分之后——审分类标签有没有证据、高分冲突证据够不够、评分口径有没有跑偏处方之后——审处方和冲突矩阵是不是一致报告出来之后——审报告完不完整、汇报层数据和明细层数据有没有矛盾盲审的意思是审核方只拿静态指标和各阶段的最终产物文件不接收主控的路由判断和其他角色的推理过程。证据不足时要自己重新读被检 Skill 的文件复核。发现问题就打回重做同一节点重试 3 次还不行就标记失败转人工。六、跑一遍看看真实环境的检查报告长什么样说了这么多原理,来看实际效果。前面讲的这套冲突矩阵 健壮性评分机制,我自己把它实现成了一个叫 skill-medic 的工具——下文提到的检查流程、报告格式、FAQ 里讨论的行为,指的都是这个工具。这里先把它是什么交代清楚,后面再看到相关内容就不会突兀。在一个装有 20 多个 Skill 的真实环境里,用 skill-medic 跑完整流程,最终会生成一份结构化的 Markdown 报告,分人话汇报层和专业明细层两部分。人话汇报层给只想用 Skill 的人看报告开头不是一堆术语而是一段大白话总结。比如健康度总评本次共检查 29 个 Skill。放心用L37 个 基本能用L25 个 不太成熟L11 个 不建议用L01 个。放心用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 评测标准吸收进来。但联网标准和内置冲突时以内置为准差异记录在报告里。QSkill 装了几百个跑得动吗跑得动。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 不是装得越多越好。真正影响使用体验的不是数量而是有没有被查清楚——冲突在哪、谁不靠谱诊断清楚了留谁删谁自然就有数了。三套核心机制冲突矩阵——用静态比对 语义确认两层方式把 5 类冲突功能重复 / 抢着响应 / 占资源 / 共享依赖 / 抢工具自动找出来高严重度必须有多条证据。健壮性评分——用静态信号 语义判断两层方式从 8 个维度给每个 Skill 打分定出四档成熟度放心用 / 基本能用 / 不太成熟 / 不建议用。规模分级——按活跃 Skill 数自动分四档S1/S2/S3/S4大规模场景下候选按功能域分组 Top-K 降噪、报告切摘要主报告 附录少则精多则省不套一套方案。把它们串成一条带独立审核的流水线跑一遍就能得到一份人话汇报 专业明细双层的检查报告针对每个冲突和每个 Skill 给出留/并/改/删的建议——注意只是建议真正的合并、归档、改文件这些动作都需要你自己确认后手动执行。如果是用 Skill 的人定期用 skill-medic 跑一遍体检心里对哪些能用、哪些别依赖有个数就好如果是写 Skill 的人那七个反模式可以当作自查清单发布前过一遍心里更有底。感兴趣的可以下载来用用看GitHub 地址https://github.com/songzhou666/skill-medic/releases