skillhub-004-skillforge/references/optimize-mode.md

优化模式 —— 将已有技能升级至 V2

让一个可用的技能在其存在的目标结果上变得可测量地更好 —— 而不仅仅是包装得更精美。一个不改变结果输出的整洁重构不是 V2。这是指标驱动的优化 —— 定义可测量的"更好"，进行实验，只保留有效改动 —— 将其应用于技能的输出。

何时使用

技能已存在并能正确触发，但你怀疑其输出可以更强 —— 更好的决策、更少的遗漏、更精准的写作、更可靠的结果。不适合修复一个失效的触发器（那属于质量修复）或创建全新的东西（那是 forge 的职责）。

优化循环

1. 定义结果 + 如何衡量它

用一句话说明该技能的优秀输出应该是什么样子 —— 指实际世界的结果，而非"结构良好"。然后选择一个你确实能运行的衡量方式：

• LLM 作为裁判的评分标准（3–5 个加权维度，1–5 分评分）—— 主观输出的默认选择（备忘录、评审、研究）。判断是否使用裁判的硬性标准：如果一个人类必须阅读输出才能判断它是否更好，那就使用裁判。
• 硬性指标（一个有明确方向性的数字）—— 适用于有客观目标的输出。

没有指标 → 没有优化。"感觉更好"不是结果。在改变任何东西之前先把评分标准写下来。

2. 设置关卡（防止作弊的步骤）

仅有指标会被钻空子 —— 优化循环会找到一种方法来获得高分，而输出却变得更差。定义关卡：通过/不通过检查，用于淘汰一个候选方案，即使它得分最高。（这是从 evo/ce-optimize 中学到的教训："没有关卡，优化循环会找到钻指标空子的方法。"）

• 退化关卡 —— 捕获明显有问题的结果（输出为空、技能删掉了自己一半的流程、输出只有一行）。成本低；优先运行。
• 防作弊审查 —— 验证 V2 没有把评分标准的答案偷偷塞进技能、硬编码测试用例，或通过缩小范围来取胜。一个仅靠"应试"才通过的改动属于失败。
• 留出集检查 —— 保留你的基准测试的一部分（见步骤 5），这些用例是改动未曾针对调优的。

任何未通过任一关卡的改动，无论得分多高，均予丢弃。

3. 质量审计（必要但不充分）

对当前技能运行 forge 的评审清单：描述即路由器、行数预算、渐进式披露、基于真实失败构建的注意事项、反模式、三阶段测试。记录修复项 —— 但请记住，这些改进的是可靠性/包装，而不是结果天花板。不要止步于此；这正是此模式要摆脱的陷阱。

4. 结果研究（提升天花板的部分）

研究技能的领域，寻找能提升步骤 1 中结果指标的最新技术和证据。进行多来源的网页搜索（并且，如果你碰巧运行了一个集成了知识库的研究技能，可以让它在那里进行叠加 —— 可选，非强制）。

• 围绕结果来构建查询，而非技能：对于一个评审技能，问"哪些技术能捕获最多的真实缺陷"；对于一个备忘录技能，问"是什么让决策备忘录改变了决策"；对于一个辩论技能，问"最新的超越单轮输出的多智能体讨论方法"。
• 只提取具体的、有证据支持的改动：一个新的流程步骤、一个启发式规则、一个更好的默认值、一个需要防范的失败模式。每个候选改动应注明来源及其针对的结果维度。
• 跳过那些有趣但不会改变指标的发现。

5. 合成 V2

将获胜的候选改动与质量修复整合进技能。然后：

• 添加一个 ## Changelog 章节：## V2 (YYYY-MM-DD)，每项改动占一行 —— 改了什么、为什么改、以及证据/来源。读者必须能够将每一个 V2 的改动追溯到某条质量规则或某项研究发现。
• 保持行数预算；将新细节推入 references/，而不是膨胀 SKILL.md（更多上下文并不一定更好 —— 自动膨胀会降低智能体的表现）。
• 保留技能的语调和触发器；优化流程，而不是重写其身份。

6. 验证 —— 在基准测试上（使用训练/验证集划分）衡量 V2 与 V1 的对比

在基准测试上对 V1 和 V2 都进行评分 —— 使用一小批留出的真实任务，而非单个示例。目标约 10–20 个代表性任务，覆盖技能实际面临的各种形态（evo 的 SealQA 运行使用了 20 个）。尽可能进行盲评（一个不知道哪个输出是 V1 哪个是 V2 的裁判）。

划分数据集。 将基准测试分为两部分：调优子集（你的改动在迭代过程中可能已隐含过拟合的用例）和验证子集（从未被改动过程见过 —— 真正的胜利条件）。在验证集上对 V2 评分。如果验证集表现退步而调优集改进，说明改动过拟合了；丢弃它。这是 SkillOpt 的纪律应用于手动运行循环的体现，它捕获了最常见的虚假胜利：一个"更好"的技能实际上学会了测试用例而不是任务本身。

• 首先应用关卡（步骤 2）：丢弃任何未通过关卡或防作弊审查的 V2，即使它得分更高。
• 只保留那些在留出任务上确实改变了指标的改动。如果一个受研究启发的改动得分更差，丢弃它并在变更日志中注明原因。
• 如果 V2 整体上未能击败 V1，那它就不是真正的 V2 —— 要么迭代（回到步骤 4），要么回退。发布一个并未带来可测量改进的"V2"正是此模式要防止的失败。
• 在变更日志中记录 V1→V2 的差值（例如："裁判评分 3.8 → 4.8，跨越 20 个任务；最大提升：风险暴露"）。

深入优化 —— 可选的外部升级工具

以上步骤是自包含的：一个 V2，手动运行，快速，无需其他工具。老实说，手动运行相当于"一个周期，批次大小为 1"。当您需要进行认真的优化 —— 多个假设、并行实验、持续数小时的基准测试、论文级别的验证 —— 并且您已安装了专门的优化工具时，可升级到该工具。以下三个工具均适用，且均独立于此技能（需单独安装）：

• ce-optimize（Compound Engineering 插件）—— 将其 spec 指向技能文件作为 scope.mutable，将您的基准测试作为指标，将您的关卡作为 degenerate_gates；它在 Claude Code 内运行并行工作树实验，只保留通过关卡的优胜者，然后收敛。最适合会话内的工作流集成。
• evo（开源，evo-hq.com）—— 针对基准测试优化整个技能目录，采用并行探索、树搜索（保留并合并专家）、以及防作弊审计器。最适合跨技能集的优雅架构。
• SkillOpt（微软，MIT 许可，arxiv 2605.23904)—— 以神经网络风格训练 Markdown 技能：周期、小批量、学习率、验证关卡，以 best_skill.md 作为当前冠军。附带标准化基准测试（SearchQA、ALFWorld、DocVQA、SpreadsheetBench、OfficeQA）并发表过论文。最适合基准驱动型的严谨性要求。

如果您没有安装以上任何一个工具，上述循环本身是完整的。此技能独特提供的（而通用优化器不具备的）是：结果研究假设来源（步骤 4）和技能质量审计（步骤 3）。

输出

• V2 技能（同一目录；旧版本可通过 git 恢复）。
• 一个包含证据链和实测差值的 ## Changelog 条目。
• 研究简报保存在技能旁（或您的知识库中），在变更日志中关联引用。

注意事项

• 整理 ≠ 优化。 如果你的 V2 差异全是格式化和 frontmatter 改动，那你跳过了步骤 4（结果研究）。
• 未测量的"改进"会导致倒退。 没有步骤 6，你就无法区分真正的提升和听起来合理的提升 —— 而源自研究的想法恰恰是那种听起来合理的类型。在基准测试上测量。
• 没有关卡 → 指标被钻空子。 步骤 2 的防作弊审查不是可选项。一个裁判评分突然提高，只是因为技能学会了奉承评分标准（或悄悄缩小了自己的范围），这实际上是穿着胜利外衣的倒退。
• 只有一个用例的基准测试就是一则轶事。 单个测试用例会过拟合。使用留出集；这是委员会评审 A/B 测试（一个问题 —— 具暗示性）与真实验证（evo 的 20 个用例）之间的区别。
• 不要批量添加研究内容。 只纳入那 2–4 个真正改变指标的改动，而非所有发现。更长的技能通常是更差的技能。
• 手动运行路径一次只处理一个技能。 对于多个技能或长时间运行，那是升级到 ce-optimize/evo 的信号，而不是手动硬干。

血统

此模式借鉴了三条汇聚工作线的指标驱动优化纪律 —— 将其范围限定于单个技能，并前置了一个其他方案不具备的结果研究假设来源：

• Compound Engineering ce-optimize —— spec + 关卡 + 并行工作树实验 + 持久化。
• evo（alokbishoyi97、evo-hq.com）—— 并行探索、树搜索、关卡、防作弊审计器。
• Microsoft SkillOpt（arxiv 2605.23904)—— 神经网络风格训练（周期/批次/验证关卡）基于标准化基准测试；步骤 6 中训练/验证集划分纪律的来源。