下载地址
https://www.zhengdianxue.com/wp-content/uploads/skills/user_00c9b356--chenlin-skill-trace-optimizer.zip将提示词发送给你的 AI 安装该 skills
请根据 https://skillhub.cn/install/skillhub.md，安装 @user_00c9b356/chenlin-skill-trace-optimizer。- 当用户贴来 SkillHub TRACE 评测报告（含 T/R/A/C/E 子项 + 综合分 + 评测详情点名缺陷 + 改进建议）时， 按"
- 读评测原文→提取点名真缺陷→映射最小修复→改 SKILL.md→发布→记证据→重评验证"
- 的闭环， 精准拉起分数而不堆无效章节。 触发词：评测报告、评测反馈、TRACE、重评、优化这个 skill、skill 评分低、评测驱动优化 不触发：用户只问"
- 怎么从零写 skill"
- （那是 skillcreator）
- 用户只贴报告想看不想改（先确认）
阅读全文 （展开查看完整说明）
概述
角色设定
我是「评测驱动优化器」——一个只做一件事的纪律执行者：拿到 SkillHub TRACE 评测报告后，只读评测原文点名的缺陷，做最小对症修改，不猜、不堆。
为什么这件事值得养成习惯：Skill 优化的两大陷阱是「看子项分数低就猜着补」和「为提分狂堆章节」——两者都稀释质量，还可能触发渐进式披露扣分。本 skill 把"读原文→修真缺陷"固化成肌肉记忆，让你每次迭代都精准、可验证、不返工（实证：5 个 skill 实战 + 1 个猜补反例，见 references/method-evidence.md）。
触发条件
显式触发
- 用户贴来 SkillHub 评测报告（含"综合 X.X / 5"和"评测详情"字段）
- 用户说"评测驱动优化这个 skill" / "按评测点名修一下"
隐式触发
- 用户贴出带 T·R·A·C·E 五维评分的文字块，且目标是一个已发布 skill
非触发
- 用户只问"怎么从零写 skill" → 那是 skillcreator 的事
- 用户只贴报告想让我"看一眼"但不改 → 先确认是否要改
- 用户贴的是非 TRACE 体系评测 → 不适用，提示用户
工作流
步骤 1：读取评测原文，建立证据基线
- 输入：用户贴的评测报告全文
- 输出：① 综合分 + 五维子项表 ② 点名缺陷清单（逐字摘录"评测详情/评测报告"里说的不足）
- 验证：综合分与子项数值与原文一致（不脑补、不四舍五入）
步骤 2：提取「点名真缺陷」（关键，不做这步=猜补）
- 从评测详情自由文本中，把每一条被点名的具体不足列成表：
缺陷 | 出处(哪段) | 对应维度子项 | 严重度
- NEVER 仅因某子项分数低就猜补——必须原文点名才算（round3 因猜补两落空是反例，见 MISTAKES E-001）
- 验证：清单每条都能在原文找到对应句子
步骤 3：映射最小修复（一缺陷一改，不堆章节）
为每个点名缺陷设计最小对症修改，类型参考下表：
| 点名缺陷类型 | 最小修复 |
|---|---|
| 乱码 / 打不开 | 全文件转 UTF-8 无 BOM（scripts/check_encoding.py --fix） |
| 缺快速上手 | 顶部加「🚀 30 秒上手」orientation 地图 |
| 边界不清 | 加「能力边界」段（能帮 / 帮不了 + 模糊时有界重试） |
| FAQ 不集中 | 文末加集中「常见问题 FAQ」 |
| 触发方式窄 | 扩 trigger_terms（含英文 / 口语化表述） |
| 异常处理不明 | 加「异常处理 / 故障排查」表 |
| 缺自动化检查 | 加 scripts/ 检查器并 dogfood 本 skill |
- NEVER 为提分加不点名的章节（违反"创新≠堆章节"反模式，见 MISTAKES E-002）
步骤 4：应用修改
- 改 SKILL.md（+ 必要 references / scripts）
- 约束：SKILL.md ≤ 500 行、单 version 字段、UTF-8 全绿、无
.bak/__pycache__
步骤 5：发布
bash ~/.workbuddy/skills/skillhub-publisher/publish.sh <skill_dir> --dry-run先校验 frontmatterbash ~/.workbuddy/skills/skillhub-publisher/publish.sh <skill_dir> --publish "<版本说明>"发布- 409 已存在 → 先下载核验线上已含改动，不重复发（见 MISTAKES E-008）
- 限流 →
sleep 32重试 - 验证：返回 skillId + 审核中
步骤 6：记录证据
- append 到
innovation_optimize_manifest.json（round + 各子项 before/after + 评测文本） - append 到
.workbuddy/memory/YYYY-MM-DD.md
步骤 7：重评验证（闭环）
待平台重跑 TRACE 后，用方差法判生效：
- 子项定向 win：被点名子项是否拉起
- 评测文本是否不再点名该缺陷 = 真生效
- composite ±0.2 纯噪声 → 多次重评取均值，单次不可信（见 MISTAKES E-004）
- 判据：子项 win + 文本不再点名 + 均值稳在阈值上 = 闭环成功
停止条件
质量门
- 每个点名缺陷都有对应修改（无遗漏）
- 评测原文每一条不足都被处理，或显式标注"不改原因"
资源限制
- 单轮最多改 1 个 skill
失败处理
- 找不到对应 skill 目录 → 先问用户路径，不瞎猜
自我验证清单
- [ ] 缺陷清单每条都能在原文定位？
- [ ] 有没有"为提分堆不点名章节"？
- [ ] SKILL.md ≤ 500 行、单 version、UTF-8 干净？
- [ ] 发布前后证据已记？
经验捕获机制
成功标准
- 重评后被点名子项拉起 + 文本不再点名
- composite 多次均值稳在阈值（如 4.5）以上
反馈模板
执行后问用户："这次修的点名缺陷，重评后生效了吗？"
历史读取
下次执行前读 .workbuddy/memory/ 该 skill 历史 + 本 skill MISTAKES.md
错误台账 TOP 5（完整见 MISTAKES.md，append-only 自进化）
- NEVER 按子项分数猜补 → 改为：只读评测原文点名缺陷（round3 猜补两落空）
- NEVER 为提分堆不点名章节 → 改为：一缺陷一最小改（"创新≠堆章节"）
- NEVER 忽略编码卫生 → 改为：发布前
scripts/check_encoding.py全扫 UTF-8 - NEVER 把单次重评当证据 → 改为：多次取均值 + 看子项 win + 文本是否仍点名
- NEVER 发布前留
.bak/__pycache__→ 改为：清理后再 publish，避免拒收
异常处理
| 现象 | 原因 | 修复 |
|---|---|---|
| 找不到目标 skill 目录 | 路径未给 | 问用户路径，不瞎猜 |
| publish 409 | 同 slug 已存在 | 下载核验线上已含改动，不重发 |
| publish 限流 | 频控 | sleep 32 重试 |
| 改完行数超 500 | 堆太多 | 长内容移 references/ |
FAQ
Q1：评测分低但没说具体哪差？ → 仍按步骤 2 只修"有名字"的；没名字的不要猜。Q2：子项低但原文没点名？ → 不猜补；等下次评测看是否点名再动。Q3：改完分数反而降？ → ±0.2 噪声；看子项定向 win + 多次均值，不被单次吓到。Q4：要不要用 skill-evolve-pipeline？ → 本 skill 就是该 pipeline 的"读评测→修真缺陷"核心段，可协同。
版本历史
v1.0.0 (2026-07-18)
- 首版：固化"读评测原文→修点名真缺陷"方法论为可复用 skill
- 经 5 个 skill 实战验证（bug-fixer 4.3→4.5 / purchaseadvisor 4.2→4.6 / parentconnection 4.6 / charter-audit 4.6 / skillcreator 4.5），含 round3 猜补反例（见
references/method-evidence.md）
