系列回顾主循环 · SkillsSkill 写完能跑不等于写得好。常见病是正向流程写得很满失败分支没有「与用户确认」写了但模型扫不到禁止项散落全文关键决策照样越界。这篇讲怎么用Darwin Skilldarwin-skill对已有SKILL.md做结构化优化——以本机优化unified-dev-workflow的实战为例。为什么不「自己改自己评」手改 Skill 的陷阱和手改 prompt 一样做法问题改完立刻自评「更好了」同 context 乐观偏差SkillLens 实证 LLM-as-judge 准确率仅约 46%只看绝对分涨跌换个 judge 同一份未改稿可晃 ±8 分——大半是换尺不是真退步一轮改三个维度分数升降无法归因Darwin 的对策很简单9 维 rubric先做 triage哪支最弱、先改谁每轮只改一个维度keep/revert 用 paired 比较同一 judge 一次读改前改后多数决不用绝对分 delta关键节点人审 CHECKPOINT核心理念可以记成一句话评估 → 改进 → 实测 / paired → 人类确认 → 保留或回滚灵感来自 Karpathy autoresearch度量从确定性 loss 换成了 LLM judge所以棘轮必须改成 paired。安装与调用把 Darwin 装到你的 skills 目录Cursor / Claude Code / 其它兼容 Agent Skills 的 runtime 均可注意措辞要runtime 中立别写成「只给 Claude Code 用」。常用话术你说Darwin 做什么评估 xxx skill//darwin 评测 xxxPhase 0.5–1设计测试 prompt 基线评分不改文件优化 xxx/优化所有 skills确认后进入 Phase 2 棘轮循环看看 skill 优化历史读results.tsv本机路径示例按你的安装位置调整~/.agents/skills/darwin/SKILL.md # 或 .cursor/skills/darwin-skill/ ~/.cursor/skills/your-skill/SKILL.md # 被优化的目标 ~/.agents/skills/darwin/results.tsv # 实验日志目标 skill 若不在 git 仓里用SKILL.md.bak.YYYYMMDD-HHMM代替git revert一样能棘轮。流程一张图Phase 0 定范围、建分支 / 备份、初始化 results.tsv ↓ Phase 0.5 为 skill 设计 2–3 条典型 test prompts → 人确认 ↓ Phase 1 9 维基线分结构主评 dim8 子 agent / 干跑→ 人确认 ↓ Phase 2 按加权缺口从弱到强 改 1 维 → commit/备份 → N3 paired judge → keep | revert 每 skill 结束再人审触顶或连续 slight 则停 ↓ Phase 3 汇总报告可选成果卡片绝对总分只做 triage。keep/revert 只看 paired 多数决。9 维 Rubric记权重不背细则#维度权重优化时常盯什么1Frontmatter7做什么 何时用 触发词禁空话尾巴2工作流清晰度12有序号、每步有输入/输出3失败模式编码12「触发 / 一线修复 / 仍失败兜底」三段式4检查点6必须有 / STOP / CHECKPOINT 视觉标记5可执行具体性18禁「建议/视情况」堆砌6资源整合4references 路径可达7整体架构12少废话、层次清楚8实测表现23带 skill vs 不带 skill 跑同一 prompt9反例黑名单6独立「不要做什么」章散落「禁止」不够Phase 2 诊断用加权缺口weighted_gap weight × (10 − score) / 10先修缺口最大的维。dim2/3/4 是相关簇修失败分支时检查点往往顺手变好——但仍建议一轮一维方便归因。实战优化unified-dev-workflow对象~/.cursor/skills/unified-dev-workflow/SKILL.md用途OpenSpec 竖切 issue TDD 的极简话术工作流uw 继续/uw #N/uw 归档…。1先定测试 promptPhase 0.5没有 test promptsdim8权重 23%就是瞎打分。我们用了三条典型场景idprompt期望1uw 继续读 change/tasks/issues只做下一步输出进度块2uw 给设置页加暗色模式开关只 propose不写实现等确认3uw 归档从未验收拒绝archive拉回阶段 4确认后再评——方向错了后面全是噪音。2基线Phase 1总分主要短板75.7dim3 失败分支弱dim4 有「确认」无 dim9 禁止项散落无专章dim8 用子 agent 做with-skill vs baseline计划级对比无真实仓库落代码时标dry_run无 skill新需求常直接写代码无验收也会归档有 skillpropose 停步、归档门禁清晰结论流程骨架已经对缺的是失败编码、显性人审、反例章。3三轮棘轮Phase 2轮次改什么内容pairedR1dim3新增「失败与恢复」9 行触发 / 一线 / 兜底3-0 betterR2dim4propose / 拆票 / 多 change / 验收处加 CHECKPOINT · STOP3-0 betterR3dim9独立「不要做什么」黑名单 9 条keep约束不改核心用途、不引入新依赖、体积不超过原稿150%本例约1.46×。无 git 时每轮先SKILL.md.bak.YYYYMMDD-HHMMpaired 判 worse 就从备份还原判 better 就保留。4收工后技能长什么样铁律 ↓ 失败与恢复三段式表 ← R1 ↓ 五阶段 CHECKPOINT ← R2 ↓ 交付检查 ↓ 不要做什么反例黑名单 ← R3日志写在 Darwin 的results.tsv便于以后复盘。优化完对使用者的好处Skill 作者改的是文档使用者感到的是 Agent 行为少假成功— push/gh/validate 失败有兜底不再静默勾 task、关 issue关键步会停— 未确认不写实现、不拆错票、不偷偷 archive坏习惯可对照— 「本地绿就关票」「无验收就归档」写在黑名单里Agent 更容易扫到调用方式不变— 仍说uw 继续变稳的是执行纪律不是让用户背长模板这才是 Darwin 相对「润色文案」的价值改可执行约束而不只是写得更像好文档。操作清单可复制1. /darwin 评测 skill名 2. 确认 test-prompts2–3 条 happy 一门禁场景 3. 看基线评分卡 → 记下加权缺口最大维 4. 回复「优化」进入 Phase 2 5. 每轮只改一维 → 等 paired 多数决 → 人审 OK 再下一轮 6. MAX_ROUNDS默认 3或连续 slight → 收工 7. 看 diff / bak / results.tsv决定是否留用高杠杆改法来自 Darwin 实战 HLHL-1检查点加 / 别只写「必须确认」HL-2失败表用「触发 / 一线 / 兜底」三段别只写症状HL-4连续两轮只是 slight/tie → 见好就收别硬凑轮次加废话反模式Darwin 自己的黑名单同 session 自评自改当 keep 依据用绝对分涨跌决定 revertgit reset --hard回滚应用revert或文件备份dry_run 比例过高还宣称「实测提升」和「手写一版更好的 Skill」差在哪手改Darwin改什么凭感觉按加权缺口 一轮一维怎么判更好自觉 / 绝对分paired 多数决 人审失败与人审容易漏rubric 强制 dim3 / dim4 / dim9可回滚看心情bak / git 棘轮手改适合从零写Darwin 适合已有 Skill 要稳态变好——尤其是「能跑但偶尔越界」的那种。小结先评再改test prompts → 9 维基线 → 人确认绝对分只排序paired 才 keep/revert优先补失败分支、显性检查点、反例专章每轮一维、控制体积、保留备份最终标准是 Agent执行时更守规矩不是 Markdown 更长下一步对你仓库里最常用的那支 Skill 跑一遍「仅评估」分数卡出来后再决定要不要进优化循环。参考Darwin Skillhttps://github.com/alchaincyf/darwin-skillSkillLensarXiv 2605.23899SkillOptarXiv 2605.23904本例目标 skill~/.cursor/skills/unified-dev-workflow/SKILL.md
