Skill 体检：30 个 Skill 全凭感觉？体检器先自曝了 8 个"假 0 分"
AI 健康三部曲 · 第 1 篇（Skill 体检）
这是一个真实故事，所有数字都来自我刚跑完的一次全量体检。
我给自己的 Skill 体系写完体检器，兴冲冲跑了一遍。
它甩给我一份 9 个"不及格"的名单。
我正准备逐个开刀，越查越不对劲------其中 8 个，是体检器自己看错了。
更尴尬的是：翻体检日志发现，这个问题 10 天前就记录过。
今天这篇，把故事讲完，也把体检器交给你。
一、先说说我为什么需要一个体检器
1. 从"写了 3 个 Skill"到"写歪了 30 个"
大概半年前，我开始用 SKILL.md 管理 AI 的工作方式------把"怎么审代码""怎么写技术方案""怎么发版本"这些方法论写成文件，让 AI 带着规范干活。
一开始很爽。写一个，喂给 AI，效果立竿见影。
然后事情开始失控：
- 3 个变 10 个，10 个变 34 个；
- 有人写"前端规范"，有人写"发布流程"，风格全看当天状态；
- 有的 Skill 有护栏（什么不能做写得清清楚楚），有的直接一句"你是个资深工程师"就完事了；
- 同一个 Skill，版本号在文件里写
0.1.0，在注册表里却是1.0.0。
到了 30 多个的时候，我问自己一个问题：
这些 Skill，哪个写得好？我说不出来。
"感觉不错"是我的全部评估体系。这不是工程，这是玄学。
2. 三个真实翻车现场
这不是危言耸听，全是我体检时抓出来的真事：
翻车 1：版本号打架
有个 Skill 文件头写着 version: 0.1.0，但体系注册表里登记的是 1.0.0。体检一跑，这样的"双版本" Skill 有 5 个。
问题大吗？想象一下：你写了个脚本按版本号判断"该不该更新这个 Skill"，它读到两个值------信谁？
翻车 2：10 个 Skill 在"裸奔"
34 个 Skill 里，10 个没有任何护栏章节。
护栏是什么？就是"必须做 / 禁止做 / 降级怎么办"这类说明。没有护栏的 Skill 就像没写"员工手册"的岗位------AI 执行时全凭自由发挥。
举个具体的：如果有个 Skill 涉及"整理我的笔记文件"，护栏该写"只读不删、移动前备份"。没写会怎么样？AI 帮你"整理"的时候顺手删几个文件，你连申诉对象都没有。
翻车 3：好坏没有共同标准
同样两个 Skill：
- 甲：结构完备、触发词清晰、有降级说明------但我"感觉"它平平无奇；
- 乙：写得激情澎湃、例子生动------但没有任何异常处理。
凭感觉，我会给乙更高分。但真要上线给团队用，甲才靠谱。
直觉和经验，只在样本量小的时候有效。数量一上去，你需要的是尺子。
3. 你的体系到该体检的时候了吗？
我给这个问题列了个信号清单，命中 3 条以上，体检就有价值：
| 信号 | 说明 |
|---|---|
| Skill 超过 15 个 | 手工维护开始顾不过来 |
| 换过 AI 工具（Cursor → Claude Code 等） | 迁移后总有几个失效，但你不知道是哪几个 |
| 记不清某个 Skill 上次什么时候改的 | 时间信息缺失的典型症状 |
| 出现过"同一个 Skill 两个版本号" | 元数据漂移，只会越来越严重 |
| 想给别人分享/开源你的 Skill | 外人拿走跑不起来时，你需要知道为什么 |
| 说不清"我的 Skill 体系健不健康" | 缺一把统一的尺子 |
二、体检器长什么样
1. 一条流水线：体检 → 评分 → 修改建议
市面上给代码做体检的工具很多（lint、CI、SonarQube），但给 Skill 体系做体检的，基本没有------毕竟 SKILL.md 这个格式本身就刚流行不久。
所以我干脆自己做了一个：skill-inspector。
它的设计目标很明确：一条流水线跑完三件事，输出一张单子------
vbnet
┌─────────────────────────────────────────────────────┐
│ skill-inspector 体检流水线 │
├─────────────────────────────────────────────────────┤
│ │
│ Step 0 目标定位 显式路径 / 当前工作区 / 全局目录 │
│ │ │
│ Step 1 体系发现 扫描所有 SKILL.md + 读元信息 │
│ │ → 体系画像（几个 Skill / 几个域） │
│ │ │
│ Step 2 流程体检 入口路由 + 死路径检测 │
│ │ │
│ Step 3 结构对照 分层是否合理 + 协作是否断链 │
│ │ │
│ Step 4 覆盖度评分 8 维 41 项检查（40 分制） │
│ │ │
│ Step 5 逐 Skill 100 分制评分（格式 60 + 内容 40）│
│ │ │
│ Step 6 合并报告 一句话结论 + 明细 + P0/P1/P2 │
│ │
└─────────────────────────────────────────────────────┘三层检查各管一段：
| 检查层 | 回答什么问题 | 输出 |
|---|---|---|
| 流程体检 | 体系跑起来会断在哪？ | 流程图 + 死路径清单 |
| 结构对照 | 层级定位和实际职责对得上吗？ | 分层表 + 协作断链 |
| 覆盖度评分 | 体系"长得全不全"？ | 8 维雷达 + 40 分制 |
| 逐 Skill 评分 | 每个 Skill "写得好不好"？ | 100 分制评分卡 |
| 合并报告 | 我到底该改什么？ | P0/P1/P2 建议清单 |
2. 覆盖度：8 个维度、41 项检查
最容易写成"玄学"的部分，我全部做成了可勾选的检查项。倒扣制：每个维度满分 5 分，逐条验证，命中扣分项就扣，最低 0 分。
8 个维度（对任意 Skill 体系通用）：
| # | 维度 | 检查什么 |
|---|---|---|
| 1 | 结构完整度 | SKILL.md 规范 / 元信息完整 / 命名一致 |
| 2 | 入口与编排 | 入口明确 / 注册表一致 / 无死路径 / 兜底 |
| 3 | 协作接口 | 跨 Skill 协作声明 / 引用目标存在 / 方向标注 |
| 4 | 安全防护 | 护栏章节 / 权限声明 / 降级策略 / 敏感数据 |
| 5 | 文档完善度 | README / CHANGELOG / 文档与实现一致 |
| 6 | Token 管理 | 大文件切分 / 渐进披露 / 读取策略 |
| 7 | 安装可搬运性 | 无私有路径 / 安装说明 / 外人可用 |
| 8 | 维护活跃度 | 版本语义化 / 多处一致 / 时间信息 |
每个维度下面是 4~6 条具体检查项，一共 41 项。举几条实际的样子：
markdown
### D3-1：结构完整度
| 检查项 | 怎么验证 | 扣分 |
|--------|---------|:---:|
| C1.1 SKILL.md 存在且大小写精确 | ls 目录/SKILL.md | 无效整卡不计分 |
| C1.2 frontmatter 完整 | name/description/metadata 三必需 | -1 |
| C1.3 name 规范 | kebab-case 且与目录名一致 | -1 |
| C1.4 附属目录用途分明 | 目录名在 9 种白名单内 | -0.5 |
| C1.5 正文有章节结构 | 二级标题 ≥ 4 个 | -0.5 |
| C1.6 无空文件 | 无 <100 字节的占位文件 | -0.5 |这些检查项有个硬性纪律：全部逐条输出 ✅/❌ + 依据，禁止跳过、禁止主观加减分。体检报告里每个数字都必须能在源文件里找到出处------这是体检器可信的前提。
3. 评分：100 分制的两把尺
覆盖度看"体系长得全不全"，评分看"每个 Skill 写得好不好"。评分是两阶段：
| 阶段 | 满分 | 内容 |
|---|---|---|
| 第一阶段：格式规则 | 60 | 目录结构 10 / name 10 / description 格式 10 / 可选字段 5 / 渐进式披露 15 / 可选目录 10 |
| 第二阶段：内容质量 | 40 | description 质量 10 / 正文质量 15 / 渐进披露设计 10 / 目录内容 5 |
有一条致命门控 ：SKILL.md 缺失或大小写不对（比如 skill.md）→ 直接 0 分，没有申诉空间。
≥80 分算"达标"（Premium），<80 分进修复清单。这个分数线是拍的吗？是------但它给了所有 Skill 一把统一的尺，比"感觉不错"强一万倍。
4. 从"前端专属"到"通用版"：解耦的故事
这个体检器其实有个前身。
我最早写的版本叫 fe-skill-inspector，是给"前端域体系"专门用的------它的检查逻辑里硬编码了前端体系的文件清单："读 fe-hub 的路由表""对照 fe-base-skill 的五步检测"。
自己用没问题。问题出在一次分享：
朋友：你这个体检器能给我用吗？我有一堆 Cursor rules 想体检。
我：可以，但......它只认我的前端目录结构。你拿去，第一步"读 fe-hub"就崩了。
一个只能体检自己的体检器，价值砍掉一半。
所以有了通用版 skill-inspector 。改造的核心就一件事：把"体检目标"从写死改成参数化------
bash
# 三种目标定位方式，自动按优先级尝试
1. 显式路径 "体检 ./my-skills" → 校验路径存在
2. 当前工作区 扫描 ./skill/*/SKILL.md、./.agents/skills/*/...
3. 全局目录 回退到 ~/.agents/skills/再加上"仅向发现结果负责"的扫描方式------不读任何私有清单，全部现场 find 扫描。结果就是：零私有依赖。任何人的任何 Skill 目录，扔给它就能体检，哪怕只有 1 个 Skill、没有 hub、没有分层。
顺便说一句，前身 fe-skill-inspector 没有被废弃------它保留为"前端域专员"，负责前端体系的深度体检（44 项前端专属检查）。通用版管"广度"，专员管"深度"，两者配合。
三、首次实战：43 个 Skill 的体检实录
1. 体检口径
先交代清楚这次体检的对象和范围，后面所有数字都对得上账：
markdown
体检目标：我的 AI Skill 体系仓库
体系画像：43 个 SKILL.md
├── skill/ 目录 34 个（通用 Skill）
├── agent/ 目录 8 个（域级 Hub）
└── 根目录 1 个（meta-hub 总入口）
另有 7 个知识模块 + 50 条注册记录参与交叉验证体检分两条线跑：41 项覆盖度检查（40 分制）+ 逐 Skill 评分（100 分制）。
2. 先说好消息
体检报告不只有病，也有健康的部分。这次有三项"满分通过"：
| 检查项 | 结果 |
|---|---|
| 注册表一致性 | 50 条注册记录 ↔ 实际文件 全部对上（0 个"注册了但文件不存在"，0 个"有文件但没注册"） |
| 依赖完整性 | 62 条 Skill 间的依赖引用，0 断链（每个被引用的对象都真实存在） |
| 安装可搬运性 | 0 处硬编码私有路径（没有 /Users/xxx/... 这种"换个电脑就跑不起来"的写法） |
说实话，这三个满分是我最欣慰的。因为它们证明体系的"骨架"是健康的------之前每次架构调整后我都会顺手修注册表和依赖引用，这次体检算是把之前的功夫都验了一遍。
3. 再看坏消息
| 问题 | 数量 | 一句话解释 |
|---|---|---|
| 字段漂移（文件 vs 注册表） | 9 处 | 5 个版本号 + 3 个域字段 + 1 个层级------两边打架 |
| 无护栏 Skill | 10 个 | 没有"必须做/禁止做"的边界说明 |
| 无时间信息 | 15 个 | 不知道这个 Skill 是上周写的还是去年写的 |
| 超 500 行大文件 | 6 个 | 最大的 676 行，每次触发全量进上下文 |
| 缺 metadata 块 | 6 个 | 文件头部信息不完整 |
| 无版本号 | 3 个 | 连个 version: 都没写 |
版本漂移的 9 处里，最典型的是 5 个"规范层"Skill：
csharp
backend-base-skill 文件里 0.1.0 vs 注册表 1.0.0
design-base-skill 文件里 0.1.0 vs 注册表 1.0.0
meta-skill-inspector 文件里 0.1.0 vs 注册表 1.0.0
pm-base-skill 文件里 0.1.0 vs 注册表 1.0.0
test-base-skill 文件里 0.1.0 vs 注册表 1.0.0看出了吗？这 5 个是同一批写的，同一个错误犯 5 次------文件里的版本号改过，注册表里的没同步（或者反过来）。
还有 3 个"域字段"漂移特别有意思：
arduino
pm-hub 域字段：文件写 product vs 注册表写 pm
vh-hub 域字段：文件写 vh vs 注册表写 virtual-human同一件事两个名字。体检器在这里暴露了一个治理漏洞：没人规定过域字段该用全称还是缩写。最后是我的规范里白纸黑字写了"禁止缩写"，才把标准定下来------但存量没清理。
4. 覆盖度得分：27 / 40
8 个维度跑完，总分 27/40 ，成熟度评级 🟠 C 级（能跑但脆弱）：
| 维度 | 得分 | 主要扣分原因 |
|---|---|---|
| 结构完整度 | 4/5 | 6 个 Skill 缺文件头部 metadata |
| 入口与编排 | 5/5 | 满分：入口明确、注册表全对、兜底分支存在 |
| 协作接口 | 4.5/5 | 部分协作表只写对象名，没写"交接格式" |
| 安全防护 | 0/5 | 五项检查全未过（护栏/权限/降级/敏感/证据） |
| 文档完善度 | 4.5/5 | 4 处字段漂移 |
| Token 管理 | 3/5 | 6 个大文件 + 15 个缺读取策略说明 |
| 安装可搬运性 | 5/5 | 满分：无私有路径、安装验证实测通过 |
| 维护活跃度 | 1/5 | 版本不一致 5 处、无版本 3 个、无日期 15 个 |
| 总分 | 27/40 | 🟠 C 级 |
安全防护那一栏的 0 分，我得诚实说一下：这是五个细分项"团灭"的结果------护栏覆盖 29/43、降级兜底 19/43、敏感数据护栏 8/34、证据纪律声明 3/34。
但注意分布：我的编排层 （hub 级别的入口）和体检类工具 其实是有护栏的------真正裸奔的是那些"写手类"Skill（撰写、生成、规划类）。属于重点覆盖、专项欠账。
5. 评分卡：88.5 分的真实成绩
100 分制评分我直接用脚本批量跑（npx tsx bin/skill-score-batch.ts），50 个条目跑完输出：
原始输出：达标（≥80 分）41 个 ｜ 低于 80 分 9 个
平均分 74.4 ｜ 中位数 88等等------平均 74.4，中位数 88？差了将近 14 分。
这个诡异的差距，就是文章开头那个故事的入口。
四、体检器自己的病：9 个"不及格"背后
1. 名单里混进了 8 个"假 0 分"
先把 9 个"不及格"全部拉出来看看：
meta-hub 0 分 ❌ Skill 目录不存在
architecture-patterns 0 分 ❌ Skill 目录不存在
frontend-security-audit 0 分 ❌ Skill 目录不存在
web-performance-engineering 0 分 ❌ Skill 目录不存在
modern-css-engineering 0 分 ❌ Skill 目录不存在
ai-coding-metacognition 0 分 ❌ Skill 目录不存在
i18n-a11y-engineering 0 分 ❌ Skill 目录不存在
fe-infra-engineering 0 分 ❌ Skill 目录不存在
business-hub 79 分 （真实低分）第一反应是心里一凉：meta-hub 0 分？！
meta-hub 是我的体系总入口------路由、知识管理、内容发布全靠它。它要是挂了，这篇文章都不会存在（此刻我写文章用的就是它）。
但冷静下来看错误信息："Skill 目录不存在"。不是"内容质量差"，不是"结构不规范"，而是------找不到目录。
可它明明就在那里。
2. 追查：两类"盲区"
打开评分脚本的代码，问题一目了然。脚本里有个定位函数长这样：
ts
function findSkillDir(rootDir: string, name: string): string | null {
const skillPath = join(rootDir, 'skill', name); // 查 skill/<名字>/
if (existsSync(skillPath)) return skillPath;
const agentPath = join(rootDir, 'agent', name); // 查 agent/<名字>/
if (existsSync(agentPath)) return agentPath;
return null; // ← 两个地方都找不到？直接放弃
}它只认两种目录位置。而我的体系实际有三种结构：
盲区 1：根目录的特权居民
meta-hub 是整个体系的总入口，它的 SKILL.md 直接放在仓库根目录------不归 skill/ 管，也不归 agent/ 管。脚本的两个探测点，全落空。
盲区 2：寄宿型的知识模块
另外 7 个"0 分"更冤。它们根本不是独立 Skill------是嵌在大 Skill 内部的知识模块：
objectivec
fe-engineer-pack/
├── SKILL.md
├── knowledge/ ← 模块们住在这里
│ ├── architecture-patterns.md
│ ├── frontend-security-audit.md
│ ├── web-performance-engineering.md
│ └── ...这些模块按"知识文档"设计，本来就不该用 Skill 的 100 分制标准去评（它们没有独立 SKILL.md 结构）。但脚本不知道这层区别------查到名字就按 Skill 找，找不到就判 0 分。
错误分类完成：8 个 0 分里，1 个是"评分器找不到真 Skill"，7 个是"评分器评错了对象"。真实低分只有 1 个：business-hub 的 79 分。
把误报剔除后重算：
markdown
修正后：42 个有效样本
平均 88.5 分 ｜ 中位数 88
达标（≥80）41 个 ------ 达标率 97.6%从"平均 74.4、9 个不及格"，到"平均 88.5、1 个不及格"------这才是体系的真实成绩。
3. 更尴尬的：这个问题 10 天前就记录过
故事到这本来可以结束了：找到 bug，修掉，收工。
但我有强迫症，去翻了体检日志------因为我隐约记得"8 个 0 分"这个数字眼熟。
日志翻到了 10 天前，2026-09-08 的全体系体检报告，M10 检测项原文：
M10｜Skill 质量评分扫描｜⚠️
有效评分 37 个：平均 88.1，Premium 35 个（94.6%）；低分 2 个：investment-research-assistant 78、meta-hub 79 → ✅ 已修复......
8 个 0 分属脚本误报（meta-hub 在根目录 + 7 个 knowledge 文件非独立 Skill 目录）
看到了吗？这个问题 10 天前就被发现了，写得清清楚楚。
当时的处理是：人工剔除误报、修正报告数字、把真实存在的问题（两个低分 Skill）修掉------然后收工。
唯独没有修脚本本身。
为什么？诚实复盘当时的心理：体检是"每个月跑一次"的活，脚本误报一次，人工读数就好了，"为了 8 个误报去改脚本不值得"。
10 天后，同一个脚本，同一个误报，我又人工剔除了一遍。
这就是治理里最经典的陷阱：把"工具的 bug"当成"数据的问题"来处理。数据修正只解决这一次，工具修复才解决以后每一次。
类比到医疗场景：体检报告上写着"疑似阴影"，你看了一眼觉得"应该是误报"，用笔划掉，归档。三个月后复查------同一个位置，同一个阴影。区别是：这次你终于决定做个 CT 看清楚。
4. 修复方案：3 行代码 + 1 个判断
问题既然定位清楚了，修复也简单。两个 P0 修改：
ts
// 修复 1：findSkillDir 补根目录探测（3 行）
function findSkillDir(rootDir: string, name: string): string | null {
const candidates = [
join(rootDir, 'skill', name),
join(rootDir, 'agent', name),
join(rootDir, name), // ← 新增：根目录直系（meta-hub 这类）
];
// 修复 2：根目录探测要校验 SKILL.md（防误判普通目录）
for (const dir of candidates) {
if (existsSync(join(dir, 'SKILL.md'))) return dir;
}
return null;
}
ts
// 修复 3：knowledge 型条目跳过 100 分制评分（口径不适用）
const layer = registryEntry.layer; // 从注册表读层级
if (layer === 'knowledge') {
results.push({ skillName: name, grade: 'N/A', note: '知识模块，非独立 Skill' });
continue; // 不进评分流程，不计入均分
}修复之后，每次批量评分不再产出 8 个假 0 分，真实均分 88.5 直接全量呈现。这个修复已经列入我的 P0 清单------下个版本见。
顺手交代一下体检器自己的评分：89/100（格式 59/60 + 内容 30/40）。它给自己也打了分，失分项写在自己的报告里：描述质量不够、正文祈使句偏多。一个体检器敢体检自己、敢把失分项写在报告里------这是它值得信任的原因。
五、修改建议：完整的问题清单
体检的最后一环是"处方"。以下是这次体检开出的完整清单（9 条），按优先级排：
P0（必修：不做问题持续存在）
| # | 做什么 | 为什么 | 改动量级 |
|---|---|---|---|
| 1 | 修评分脚本：补根目录探测 + knowledge 条目标 N/A | 每跑一次就产出 8 个假 0 分，误导治理决策 | 小（~15 行） |
| 2 | 统一 5 处版本号 + 补 3 个缺失版本 | 版本是"谁更新谁陈旧"的第一依据，两处打架就没法信 | 小 |
| 3 | 修正 4 处域/层级字段漂移（product→pm、vh→virtual-human 等） | 按域聚合的统计全靠这个字段，混用会失真 | 小 |
P1（建议修：P0 之后收益明显）
| # | 做什么 | 为什么 | 改动量级 |
|---|---|---|---|
| 4 | 为 10 个无护栏 Skill 补护栏章节 | 护栏是 AI 执行的行为边界，没有边界的 Skill 在新环境容易越权 | 中 |
| 5 | 降级兜底补齐（19/43 → 目标 35+） | 决定"意外输入时是死掉还是优雅退化"，近 6 成没写 | 中 |
| 6 | 日志/记录类模块补"不记录敏感信息"护栏 | 这三类读的是会话、行为、知识内容------最靠近隐私却最没护栏 | 小 |
P2（可选加固：有余力再做）
| # | 做什么 | 为什么 | 改动量级 |
|---|---|---|---|
| 7 | 676 行大文件切分到附属目录 | 大文件每次触发全量进上下文，浪费 Token 稀释注意力 | 中 |
| 8 | 15 个 Skill 补时间信息 | 没有时间就无法判断"是不是老古董" | 小 |
| 9 | 输出分析类 Skill 扩散"证据纪律"声明 | "不得编造数据、无法检测就标注"是审查类工具的立身之本 | 小 |
最小改动路径
如果时间有限，只做 3 个 P0 ：预计覆盖度分从 27 → 30.5/40（76%，从 C 级升到 B 级），同时评分脚本恢复全量可信。
这就是"体检报告"的正确打开方式------不是列一堆问题吓人，而是给出排序好的、带量级的、有预期收益的行动清单。P0 全是"小改动大收益"，半天能做完。
六、你也能用：三步跑完你自己的体检
体检器已经打包好了，任何 SKILL.md 体系都能直接跑。三种用法：
1. 完整体检（默认）
bash
你：Skill 体检
或：体检 ./my-skills输出一张完整报告：体系画像 → 流程体检 → 结构对照 → 覆盖度 8 维评分 → 逐 Skill 评分卡 → P0/P1/P2 清单。
2. 评分模式（只要分数）
你：给这些 Skill 打分跳过深度检查，直接输出 100 分制评分卡 + 低分修复建议。适合"先摸底"。
3. 复检模式（修完再看）
你：再体检一次自动对比上次报告：哪些修好了、哪些没修、覆盖率提升多少。未修复的 P0 项自动升级为本次最优先事项------防止"体检报告归档吃灰"。
适用 / 不适用
| 适合 | 不适合 |
|---|---|
| 自研 SKILL.md 体系（任意规模：1 个到 100 个） | 体检 Agent 系统的架构设计（用 agent-arch-inspector） |
| 想开源/分享前做一次自检 | 单点的深度代码审查（用 fe-skill-inspector 这类域专员） |
| 团队协作前统一质量标准 | 替代 CI/lint（它管"Skill 体系"，不管"代码") |
| 定期复检追踪退化 | 只想修复某个 Skill 的具体写法（用 skill-creator） |
七、速记表
| 你想做什么 | 用什么 |
|---|---|
| 体检任意 Skill 体系 | skill-inspector（体检→评分→建议，一张单子） |
| 打分 | 评分模式，100 分制 + 达标线 80 |
| 修完复检 | 复检模式，自动对比上次报告 |
| 体检 Agent 架构 | agent-arch-inspector（下一篇） |
| 体检整个体系 | meta-hub system-health（第三篇） |
| 结论写作原则 | 每个数字有出处，每条建议有后果解释 |
本次体检的最终结论一句话：骨架健康（0 幽灵注册、0 断链、0 私有路径），债务集中在"元数据一致性"和"安全兜底"两处------3 个 P0 修复（半天）可从 C 级升 B 级。
避坑指南
| 问题现象 | 原因 | 解决方法 |
|---|---|---|
| 评分脚本报"Skill 目录不存在"但文件明明在 | 定位函数只认固定目录结构（skill/ 和 agent/） | 补探测点 + 校验 SKILL.md 存在 |
| knowledge 型模块被评 0 分 | 用 Skill 的评分标准去评非 Skill 对象 | 按 layer 字段分流，非 Skill 标 N/A |
| 体检发现的工具 bug 反复出现 | 修了报告数据，没修工具 | 修复项指向工具本身，而不是当次输出 |
| 版本号在两个地方不一致 | 多处登记没有同步机制 | 建立"一处真相 + 自动校验"（体检复检兜底） |
| Skill 越写越多但说不清质量 | 缺少统一评价标准 | 用检查清单 + 评分卡替代"感觉" |
十、常见问题（Q&A）
Q1：我只有 5 个 Skill，也需要体检吗？
需要，但不用跑一次 41 项全量。5 个 Skill 时，真正该担心的是"版本号、护栏、触发词"这三件事------先跑评分模式，低于 80 分的再深查。体检器是为了省时间，不是为了增加仪式感。
Q2：41 项检查必须全部跑一遍吗？
不是。完整体检默认跑 41 项，但你可以按目标裁剪：只想摸底质量 → 评分模式；只想查注册表和依赖 → D1+D2；定期复检 → 只扫变更集。清单的价值是"需要时拿得出"，不是"每次都必须勾完"。
Q3：评分低于 80 分就一定要修吗？
80 分是"达标线"，不是"生死线"。低于 80 分进入修复清单，按 P0/P1/P2 排序。最小改动路径是：先修 P0（通常半天内能完成），P1/P2 有余力再动。不要因为一个 79 分的 Skill 卡住全量发布。
Q4：体检器能自动帮我修好 Skill 吗？
不能，也不应该。skill-inspector 只出报告。修 Skill 是 skill-creator 或人工的事------诊断和手术分开，才能避免"既当裁判又当运动员"。
Q5：多久体检一次合适？
建议两个触发条件：一是每次大改后（新增/重构超过 5 个 Skill），二是固定周期（比如每月一次）。别把体检当成"年度大扫除"，它应该是日常维护的一部分。
Q6：这个体检器能用于别人的 Skill 体系吗？
可以。通用版不依赖任何私有目录结构，只要你的 Skill 是 SKILL.md 格式，扔给它就能跑。这也是它从前端专属版改过来的原因。
写在最后
这篇的核心其实不是"教你做一个体检器"，而是一个立场：
你的 AI 资产（Skill、Agent、工作流）和代码一样，会腐化、会漂移、会负债。而且因为它们"看起来只是几个 markdown 文件"，腐化的时候你毫无察觉。
今天这篇是三部曲的第一篇------微观视角，体检的是"单个 Skill 写得好不好"。
下一篇，视角升一级：Agent 体检。
乱编 API 的编程助手、错误一路传递的 Agent 流水线、越塞越贵的客服记忆------三个真实翻车现场，用五维审查矩阵逐个拆解。
我们下篇见。
本文相关产出：
想要本文的完整体检脚本？
体检器（skill-inspector）+ 41 项检查清单 + 100 分制评分规则 + 批量评分脚本------都已打包好，评论区留言或私信我，直接发你。