SkillHub 评测驱动优化器

它解决什么问题

Skill 迭代有两条最常见的弯路：看到子项分数低就开始猜着补，或者为了拉高综合分往 SKILL.md 里狂堆章节。前者在改不存在的缺陷，后者会让文档越来越臃肿，反而稀释质量，甚至触发 SkillHub 的渐进式披露扣分。这个技能把「读评测原文 → 只修真缺陷」固化成流程，让每次优化都有据可依、可验证、不返工。

它如何工作

核心流程分七步，每一步都有明确输入输出和验证方式：

• 建立证据基线：完整读取评测报告，摘出综合分、T·R·A·C·E 五维子项，再逐字摘录「评测详情」里点名的具体不足——不脑补、不四舍五入。
• 提取点名真缺陷：把每条被点名的不足整理成「缺陷 / 出处 / 对应子项 / 严重度」清单。关键规则是：NEVER 仅因某子项分数低就猜补，必须原文点名才算。
• 映射最小修复：按缺陷类型套用对应的对症改法，比如缺快速上手就加 🚀 30 秒上手 地图，触发方式窄就扩 trigger_terms，编码乱码就用 scripts/check_encoding.py --fix 转 UTF-8 无 BOM。一缺陷一改，不堆不点名的章节。
• 应用与发布：改完跑发布脚本，先 --dry-run 校验 frontmatter；遇到 409 先下载核验线上版本，限流则 sleep 32 重试。约束 SKILL.md ≤ 500 行、单 version 字段、无 .bak / __pycache__ 残留。
• 记录证据：append 到 innovation_optimize_manifest.json 和当日 memory 日志，留下 before/after 子项数据和评测文本。
• 重评验证：用方差法判生效——被点名子项拉起、评测文本不再点名该缺陷才算真生效；综合分 ±0.2 视为噪声，需多次重评取均值。

适用边界

• 仅适用于 SkillHub TRACE 体系评测。贴来其他体系的评测报告不适用，会明确提示。
• 单轮只处理 1 个已发布 skill；从零写 skill 是 skillcreator 的职责，不归它管。
• 修完后分数短期下降不必慌，先看子项定向 win 和文本是否仍点名，不被单次噪声吓到。
• 找不到目标 skill 目录时会先问路径，不瞎猜——这是写进错误台账 E-001 的纪律。