用途
Skill Autoresearch 适用于「在冻结的本地基准下改进可复用仓库产物」这一任务。它的适用范围是仓库本地的、对 markdown/git 友好的棘轮式改进，对象包括 SKILL.md、SOP、提示词、模板和工作流文档。
如果你真正需要的是产品级规模的追踪、托管看板或应用/运行时评估，应转出到 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 审查中留存的、仅追加的保留/回退历史。
- 想要对「这次编辑是否真的改进了产物」给出可复现的回答。
何时不使用
- 用户已经明确知道自己想要的确切改写，不需要基准循环。
- 目标没有代表性提示词，或没有稳定评估行为的方式。
- 任务其实是关于运行 GPU 密集的 karpathy/autoresearch 实验（train.py / program.md / val_bpb）→ 应使用 autoresearch。
- 任务其实是关于托管的提示词或应用评估、生产追踪、大数据集或实验看板 → 应转出到 LangSmith、Promptfoo、Braintrust 或 Weave。
- 你即将同时改动产物和评估器。
必需输入
在开始改动工作之前，必须明确：目标产物、3-5 个代表性提示词或场景、3-6 个二元评估项、重跑/预算规则，以及除主产物外允许涉及的支撑文件。
在此之前，先判断是否有证据指向以下三种结果之一：
- 基线很可能不通过，需要一次真正的棘轮改进；
- 主产物没问题，但支撑面发生了漂移；
- 或目前还不值得进行棘轮改进。
使用方式（步骤）
步骤 1：选择一个数据包（packet）。编辑前先把请求归一到唯一的主数据包：
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/setup/manifest 措辞；若已存在棘轮，阅读此前的循环产物。记录：产物的真实职责、应触发它的条件、它应转出什么、当前失败模式、任何过时的发现措辞或支撑漂移，以及下一个可能状态是「不值得棘轮」「support-sync」还是真正的改动循环。
步骤 3：在冻结循环前判断棘轮资格。写契约前先回答：基线是否看起来已满足当前标准？真正的问题是否只是支撑面漂移？是否有具体证据表明棘轮仍值得折腾？若指向「不值得棘轮」，停下并报告该结果。若主产物已良好但 docs/manifests/精简面漂移，转 support-sync，而不是假装发生了改动循环。只有当基线确实不通过，或存在明确的、有证据支撑的提升空间时，才继续进入基准循环。
步骤 4：冻结评估器。编辑前写 loop-charter.md。契约必须冻结：本次运行目标、当前基线、一个主要可变产物、固定的评估框架、范围内允许的支撑文件、时间/迭代/工具预算、本次运行中被否决的方向。规则：不得在运行中途更改提示词、评估措辞或评分规则；若评估器变化，另起新的对比轨道；即使支撑文件后续变化，也保持一个主要可变产物。
步骤 5：只构建二元评估。使用 references/eval-guide.md。适合技能与工作流产物的强评估类别：触发精确度、转出清晰度、执行确定性、产物有用性、基准纪律、发现面同步（仅当本次运行改变定位时）。规则：只用是/否检查；优先可观察检查而非主观品味；不要对同一失败重复扣分；基线与改动运行使用同一提示词集合。
步骤 6：为当前产物做基线。把当前版本复制为基线产物（如 SKILL.md.baseline）；记录实验 0；在冻结框架上给当前版本评分；在改动前先总结失败。决策门：若基线已轻松通过且没有实质支撑漂移，停下并报告「不值得棘轮」；若基线良好且只有 compact/docs/manifests 漂移，跳到 support-sync 并明确说明；只有当基线确实不通过，或契约列明有明确证据支撑的提升空间时，才继续改动。
步骤 7：运行单次改动。这是核心循环：检查失败输出或产物面；形成一个假设；只改一个有意义的地方；重跑同一框架；与基线和当前最佳比较；只保留能提升分数的改动；对持平或回退予以回退，除非契约明确偏好次级指标（如更低的歧义或更小的前门）。把结果追加到运行日志。好的改动示例：收紧薄弱的触发描述；把关键边界规则上移；添加一个聚焦的支撑文件以填补明确的可用性缺口；删除导致过度触发的噪声指令；通过把稳定细节移入 reference 来缩减臃肿的前门。坏的改动示例：同时重写技能与评估器；在核心边界尚未验证前就大规模多文件改动；为提高召回而堆砌关键词；为风格而非实测行为做优化。
步骤 8：仅在棘轮成立后才同步支撑面。若主改动实质性影响可发现性、上手引导、命名或使用，则同步：evals/evals.json；精简变体如 SKILL.toon；发现清单如 skills.json / 精简索引；docs/setup 面如 README.md、本地化 README 条目或 setup 提示词。要在主产物改进被冻结评估器验证之后再做。
步骤 9：记录每一次实验。使用仅追加产物。最低组合：loop-charter.md；基线副本；结构化结果（results.tsv、results.json 或等价物）；白话变更日志/实验日志。每次实验应记录：保留或回退、分数差、一句话改动摘要、假设、剩余失败。
步骤 10：把规则也应用到本技能自身。若目标产物就是 skill-autoresearch 本身，不要把它豁免于循环。验证：目标技能在冻结评分标准下的表现；仅当主棘轮成立后才同步支撑面；最终措辞仍保留冻结评估器、单次改动迭代、仅追加日志与明确的保留/回退决定。
适用场景与限制
它适合仓库本地的技能/文档/提示词/模板维护，尤其是当修改需要可衡量证据、可留存历史且不想做整体重写时。限制在于：它刻意限定在仓库本地；不替代 LangSmith、Promptfoo、Braintrust、Weave 等托管评估平台，也不替代 karpathy/autoresearch 这类 ML autoresearch；没有代表性提示词或稳定评估方式时不应使用；不应同时改动产物与评估器；用户已知确切改写时无需使用。