通用 Skill 测评专家

要解决的问题

写 Skill 的人常有一种错觉：规则越细，模型执行得越好。实际经验恰恰相反——当 SKILL.md 堆到 700 行、当「必须/禁止」出现 50 条以上、当所有规则平铺在同一层级，模型对单条规则的遵从率会掉得比预期快得多。更麻烦的是，这类失败很难靠通读文档发现：结构冗余、注意力分配、负向约束的启动效应，都是 LLM 认知层面的工程问题，而不是「内容对不对」的问题。

这个技能把 Skill 工程质量审计拆成可重复执行的流程，评审对象是 Skill 作为大模型指令系统的质量，而不是它的领域知识是否正确——领域内容交给领域专家判断。

工作方式

核心是一条带门控的工作流：先输出量化统计块（主体行数、估算 token 数、硬规则条数），之后每一步打分都必须引用这些数字，跳过统计直接给分视为评审无效。

整个过程被三条铁律约束：所有扣分必须附原文证据（行号/章节/文本），「感觉不太好」不算理由；修复方案必须给出 当前写法 → 建议改为 的完整对照，让作者能照抄执行；能用数字的地方一律用数字。

工作模式有两种。单次评审模式接收用户直接提交的 Skill，输出诊断报告。迭代驱动模式被 Skill 工程师的工作流阶段（PHASE 4/6/7）调用，额外输出修改指令列表——每条包含位置、当前写法、替换文本与原因，Builder 可以不做判断直接执行，修复后再触发下一轮评审，形成闭环。

八个评审维度

• A. 架构与 Token 经济性（15 分）：检查主体行数是否挤占生成空间，参考资料是否通过渐进式披露分离；多 Skill 体系还要核对单次运行时的加载量上限。
• B. LLM 注意力适配（15 分）：把每条 P0 规则所在行号换算成总行数的百分比，落在 30%–70% 区间即标为危险区——模型存在 U 型注意力曲线，中段指令遵从率最低。
• C. 规则工程质量（20 分，权重最高）：统计硬规则条数、检查 P0/P1/P2 分级（P0 超过 5 条等于没有优先级）、逐条校验条件-动作格式、扫描规则冲突，并统计正向指令与负向约束的比例。
• D. 知识效率（10 分）：用「不给这段指令，模型裸跑会自动做到吗」筛掉预训练已有的通用知识。
• E. 示例设计质量（10 分）：关注示例数量、子类型覆盖，以及同质化示例带来的锚定污染。
• F. 工作流与门控设计（15 分）：阶段划分、通过/失败判据、前置淘汰、质检与执行的分离度，以及产出物是否强制通过工具写入文件而非口头宣称完成。
• G. 输出规范与格式约束（10 分）：是否有可直接复制的结构化模板与格式锚点。
• H. 鲁棒性与边界处理（5 分）：未覆盖场景的回退策略与冲突解决优先级。

总分 100，映射到 S/A/B/C 四档评级。

适用边界与注意点

它只做工程审计，不会替你判断领域内容是否正确：代码生成类 Skill 的算法正确性仍需测试用例说话。被审 Skill 不完整时，受影响维度标注「信息不足」而非猜测缺失内容；纯知识型 Skill 没有工作流，对应维度记 N/A 并按剩余维度折算。评审多 Skill 体系的一员需要提供关联 Skill 的行数信息，否则单次加载量的估算不成立。

另一点是反确认偏误机制：评审开始时预设「至少有 3 个需改进点」，逐维度寻找直到确认找不到为止。这让它的「无问题」结论，比随手翻一遍文档得到的「看起来还行」更有分量。