skill-autoresearch

Skill Autoresearch

当任务是使用冻结的本地基准改进可复用的仓库产物时，请使用此技能。

约定很简单：先判断是否确实有必要进行棘轮迭代，然后冻结评判标准，为当前产物建立基线；仅在需要时做一项有意义的更改，再次运行相同的测试框架，只保留经测量确认的改进，并记录保留和回退的更改。

此技能有意限定在仓库本地。它负责为 SKILL.md、SOP、提示词、模板和工作流文档提供适合 Markdown 和 Git 的棘轮迭代。如果实际需求涉及产品级跟踪记录、托管仪表板或应用／运行时评估，请转交其他工具处理，不要假装此技能可以取代 LangSmith、Braintrust、Weave 或 Promptfoo。

编辑前请阅读以下支持文件：

• references/eval-guide.md
• references/loop-charter-template.md
• references/run-packets-and-route-outs.md

何时使用此技能

• 可复用的 SKILL.md 或工作流文档表现不稳定，需要有边界的改进循环。
• 你需要判断当前产物是否值得再进行一次棘轮迭代，还是应当选择「目前没有进行棘轮迭代的理由」。
• 你想在不于运行中途变更基准的前提下，完善触发条件、转交路径或执行步骤。
• 你需要在主要边界得到验证后，才添加或更新 references/、evals/、精简版内容或发现用语。
• 你需要仅追加记录保留和回退的历史，以便其在 Git 和 PR 审查中留存。
• 你想以可重复的方式回答「这次编辑是否确实改进了产物？」

何时不要使用此技能

• 用户已经明确知道想要的改写内容，不需要基准测试循环。
• 目标没有代表性提示词，或没有稳定的行为评估方式。
• 实际工作是针对 train.py / program.md / val_bpb 运行受 GPU 限制的 karpathy/autoresearch 实验 → 请使用 autoresearch。
• 实际工作涉及托管式提示词或应用评估、生产环境跟踪记录、大型数据集或实验仪表板 → 请转交 LangSmith、Promptfoo、Braintrust 或 Weave 处理。
• 你准备同时更改产物和评估器。

必要输入

在明确以下内容之前，不要开始修改：目标产物、3-5 个代表性提示词或场景、3-6 项二元评估、重新运行／预算规则，以及除主要产物外允许更改的支持文件。

在此之前，先判断是否有证据支持以下三种结果之一：

• 基线可能未通过，需要进行真正的棘轮迭代；
• 主要产物没有问题，但支持内容已发生偏移；
• 或目前没有进行棘轮迭代的理由。

说明

步骤 1：选择一个数据包

开始任何编辑之前，将请求归一化为一个主要数据包。

skill_autoresearch_packet:
  primary_packet: ratchet-eligibility | benchmark-readiness | charter-freeze | baseline-score | one-change-mutation | support-sync | final-report | route-out
  target_artifact: SKILL.md | SOP | prompt-template | workflow-doc | other
  evidence_shape: prompts-and-evals | dry-run-checklist | repo-validators | mixed | unknown
  support_scope: none | references-only | evals-only | compact-only | discovery-surfaces | mixed
  confidence: high | medium | low

数据包含义：

• ratchet-eligibility — 判断运行是否应以「目前没有进行棘轮迭代的理由」结束、转入 support-sync，还是继续进行真正的基准测试循环
• benchmark-readiness — 在冻结提示词／评估／范围之前，不得开始循环
• charter-freeze — 在任何修改之前编写循环约定
• baseline-score — 为当前产物创建快照并记录实验 0
• one-change-mutation — 只做一项有意义的更改，然后重新运行，决定保留或回退
• support-sync — 仅在核心棘轮迭代得到验证后更新精简版／文档／清单；如果主要产物已完善且只有支持内容发生偏移，也可更新
• final-report — 总结基线到最终状态的变化、保留／回退次数以及剩余失败项
• route-out — 请求实际属于托管式评估工具或 ML autoresearch

步骤 2：阅读目标内容及相邻界面

先阅读主要产物，然后只查看重要的支持界面：

• 链接的 references/、evals/、scripts/ 或精简版本
• 如果可发现性可能发生变化，则查看 README、设置或清单中的措辞
• 如果已有棘轮机制，则查看此前循环的产物

记录：

• 该产物的实际作用
• 哪些情况应触发它
• 它应将哪些情况转交出去
• 当前的失效模式
• 是否存在过时的发现说明或支持内容偏差
• 下一步最可能的状态是 no ratchet justified、support-sync，还是实际的变更循环

步骤 3：在启动循环前判断是否适合棘轮优化

编写章程前，先回答三个问题：

1. 当前基线是否已经达到现行标准？
2. 实际问题是否仅仅是支持界面内容偏差？
3. 是否有具体证据表明，棘轮优化值得付出相应成本？

如果答案表明 no ratchet justified，就停止并报告这一结果。 如果主要产物已经足够好，但文档、清单或精简界面存在偏差，则转为 support-sync，不要假装已经进行了变更循环。 只有在基线确实不合格，或有明确且有证据支持的提升空间值得追求时，才继续进入基准测试循环。

步骤 4：固定评估器

编辑前，先编写 loop-charter.md。

章程必须固定以下内容：

• 本次运行的目标
• 当前基线
• 一个主要可变产物
• 固定的评估框架
• 允许纳入范围的支持文件
• 时间、迭代次数和工具预算
• 本次运行中排除的方向

规则：

• 运行期间不得更改提示词、评估措辞或评分规则
• 如果评估器发生变化，则开始新的对比轨道
• 即使之后更改了支持文件，也只能保留一个主要可变产物

步骤 5：仅构建二元评估

使用 references/eval-guide.md。

适用于技能和工作流产物的强评估类别：

• 触发精确度
• 转交清晰度
• 执行确定性
• 产物实用性
• 基准测试规范性
• 发现界面同步（仅在本次运行改变定位时）

规则：

• 只使用是／否检查
• 优先选择可观察的检查项，而非主观偏好
• 不要对同一项失效重复评分
• 基线和变更运行使用相同的提示词集

步骤 6：评估当前产物的基线

1. 将当前版本复制为基线产物，例如 SKILL.md.baseline
2. 记录实验 0
3. 使用固定的评估框架为当前版本评分
4. 在进行任何更改前总结失效情况

决策关口：

• 如果基线已轻松通过，且不存在实质性的支持内容偏差，则停止并报告 no ratchet justified。
• 如果基线表现良好，只有精简内容、文档或清单存在偏差，则转到 support-sync 并明确说明。
• 只有在基线确实不合格，或章程明确指出有证据支持的提升空间值得追求时，才继续进行变更。

步骤 7：逐项进行变更

这是核心循环：

1. 检查未通过的输出或产物界面
2. 提出一个假设
3. 只改动一项有意义的内容
4. 使用相同的评估框架重新运行
5. 与基线及当前最佳版本进行比较
6. 只保留能提高分数的更改
7. 除非章程明确优先考虑歧义更少或入口内容更精简等次要指标，否则撤销持平或导致退化的更改
8. 将结果追加到运行日志

有效的变更：

• 收紧薄弱的触发条件描述
• 将关键边界规则提前
• 添加一个有针对性的支持文件，以弥补明确的可用性缺口
• 删除导致过度触发的冗余指令
• 将稳定的细节移至参考文件，以缩减臃肿的入口内容

无效的变更：

• 同时重写技能和评估器
• 尚未验证核心边界就大幅改动多个文件
• 为提高召回率而堆砌关键词
• 追求风格而非可测量的行为

步骤 8：只有在递进优化机制奏效后，才同步辅助界面

如果主要变更实质性地影响了可发现性、引导流程、命名或用法，则同步：

• evals/evals.json
• 精简变体，例如 SKILL.toon
• 发现清单，例如 skills.json / 精简索引
• 文档/设置界面，例如 README.md、本地化 README 条目或设置提示词

只有在冻结的评估器证明主要产物改进合理后，才执行此操作。

步骤 9：记录每次实验

使用仅追加的产物。最低限度的材料包括：

• loop-charter.md
• 基线副本
• 结构化结果（results.tsv、results.json 或同等格式）
• 通俗易懂的变更日志 / 实验日志

每次实验都应记录：

• 保留还是回退
• 分数变化
• 一句话概述变更
• 假设
• 尚存的问题

步骤 10：也将此规则应用于此技能

如果目标产物是 skill-autoresearch 本身，不要将其排除在循环之外。

验证：

• 根据冻结的评分标准评估目标技能
• 只有在主要递进优化机制奏效后，才同步辅助界面
• 最终措辞仍保留冻结的评估器、单次单项迭代、仅追加日志以及明确的保留/回退决定

输出格式

返回一份精简的递进优化报告：

# Skill Autoresearch Report

## Packet
- Primary packet:
- Target artifact:
- Why this packet fits:

## Frozen harness
- Prompts / scenarios:
- Binary evals:
- Validators:
- Scope limits:

## Baseline
- Current score:
- Main failures:

## Mutation result
- Change tried:
- Keep or revert:
- Score delta:
- Remaining failures:

## Support sync
- Updated surfaces:
- Deferred surfaces:

## Next state
- Recommended next move:
- Artifact paths:

示例

示例 1：修复触发条件

输入

改进这个过时的技能。它触发得太频繁了，我想要一个有边界的循环，而不是全面重写。

正确方向

• 数据包：one-change-mutation
• 先冻结提示词/评估
• 只改写描述或路由退出措辞
• 根据测量结果决定保留还是回退

示例 2：修复基准漂移

输入

我在重写技能时一直改测试。即便如此，也请帮我优化它。

正确方向

• 数据包：benchmark-readiness 或 charter-freeze
• 在评估器冻结前阻止运行继续
• 如果必须更改评判标准，指示维护者启动新的对比轨道

示例 3：后续同步发现界面

输入

现在技能更好了。README、设置提示词和精简措辞可能已经过时。

正确方向

• 数据包：support-sync
• 只有在主要递进优化已得到验证后才进行；或者主要产物本身已经没问题，只是辅助界面出现了偏差
• 同步清单/文档，不要把大规模文档改动说成主要实验

示例 4：递进优化未获支持

输入

当前技能已经通过我们的冻结检查，评审反馈也不错。我只是觉得还可以继续微调。

正确方向

• 数据包：ratchet-eligibility
• 除非维护者能指出有具体证据支持的改进空间，否则结论应为 no ratchet justified
• 保护已通过检查的基线，避免不必要的改动

示例 5：路由退出

输入

我需要在线追踪、数据集对比和用于我们应用提示词的托管仪表板。

正确方向

• 数据包：route-out
• 说明这项工作适合 LangSmith、Promptfoo、Braintrust 或 Weave，而不是在仓库本地对技能进行递进优化

最佳实践

1. 将 no ratchet justified 作为有效的成功状态，而不是假定每次运行都需要修改。
2. 在首次实际编辑前冻结评估器。
3. 即使辅助文件也在范围内，仍只保留一个主要可变产物。
4. 一次只改动一项有意义的内容。
5. 优先使用有代表性的提示词，而不是完美的玩具案例。
6. 记录失败的实验，而不只是成功的实验。
7. 只有在同一测试框架仍能通过时，才将缩小入口视为有效的次要收益。
8. 只有在主要递进优化机制奏效后，才同步精简内容/文档/清单。
9. 明确区分仓库本地的技能维护、托管评估平台和 ML autoresearch。

参考资料

• 上游 autoresearch-skill
• Karpathy/autoresearch
• Promptfoo
• LangSmith 评估