达尔文.skill

核心用法

darwin-skill 是一套受Karpathy autoresearch启发的自主skill优化系统，核心流程为「评估→改进→实测验证→人类确认→保留或回滚」。当用户触发"优化skill"、"skill评分"、"自动优化"等关键词时启动。

8维度评估体系（总分100）

• 结构维度60分：Frontmatter质量、工作流清晰度、边界条件覆盖、检查点设计、指令具体性、资源整合度
• 效果维度40分：整体架构、实测表现（关键差异点——用测试prompt跑真实输出对比baseline）

三阶段工作流

1. Phase 0.5：设计2-3个测试prompt，用户确认后进入评估
2. Phase 1：基线评估，生成评分卡，等用户确认
3. Phase 2：hill-climbing优化循环，每轮只改一个维度，用独立子agent重跑测试，总分严格提升才保留，否则git revert

关键设计

• 棘轮机制：只保留改进，自动回滚退步
• 评分独立性：效果维度必须用子agent或干跑验证，避免「自己改自己评」
• 人在回路：每个skill优化完展示git diff和分数变化，等用户确认再继续
• 探索性重写：连续瓶颈时可选全盘重构，突破局部最优

显著优点

• 实测驱动：不只看写得规不规范，更看改完后实际跑出来的效果是否更好
• 可解释性强：每轮改动单一维度，归因清晰，results.tsv完整记录历史
• 风险可控：git分支隔离，revert而非reset，用户随时可介入回滚
• 与花叔生态对齐：尊重中文为主、简洁为上的风格

潜在缺点

• 资源消耗大：每个skill需跑2-3次子agent测试，全量优化成本较高
• 测试prompt质量依赖人：设计不佳会导致优化方向偏差
• 效果评分主观性：即使子agent评分，「输出质量」判断仍有主观成分
• 收敛速度不确定：局部最优时需要探索性重写，增加不确定性

适合人群

• 拥有5个以上skills、需要系统化管理质量的中高级用户
• 愿意投入时间理解评估逻辑、参与人在回路确认的技术型用户
• 追求"可测量改进"而非"感觉变好"的数据驱动型用户

常规风险

• 过度优化：可能为追求分数提升而牺牲skill简洁性（有文件大小150%约束缓解）
• 测试泛化不足：测试prompt覆盖不全时，优化后的skill在真实场景中可能退化
• 子agent失败降级：资源不足时退化为干跑验证，评分可靠性下降
• git操作依赖：环境若无git或分支冲突，可能中断流程

核心用法

darwin-skill 是一款受 Karpathy autoresearch 启发的自主优化工具，专为提升 Claude Code skills 质量而设计。它通过「评估 → 改进 → 实测验证 → 人类确认 → 保留或回滚」的完整闭环，实现对 skills 的持续迭代优化。

8 维度评估体系（总分 100）

• 结构维度（60 分）：Frontmatter 质量、工作流清晰度、边界条件覆盖、检查点设计、指令具体性、资源整合度
• 效果维度（40 分）：整体架构合理性、实测表现（关键创新）

典型工作流程

1. Phase 0.5：为每个 skill 设计 2-3 个测试 prompt，覆盖典型场景
2. Phase 1：基线评估——结构评分由主 agent 完成，效果评分由独立子 agent 执行（避免「自评自改」偏差）
3. Phase 2：hill-climbing 优化循环——针对最低分维度逐轮改进，git commit 追踪，只保留严格进步的版本
4. Phase 2.5：必要时经用户同意后进行「探索性重写」，突破局部最优
5. Phase 3：生成完整优化报告，含分数变化、测试对比、主要改进点

关键机制

• 棘轮机制：新总分必须严格高于旧总分才保留，否则自动 git revert
• 人在回路：每个 skill 优化后暂停等用户确认，避免失控
• 双重评估：不仅看 SKILL.md 写得是否规范，更看改完后实际跑出来的效果
• 独立评分：效果维度必须用子 agent 或「干跑验证」，杜绝自我偏差

显著优点

1. 方法论严谨：借鉴 autoresearch 的科学研究范式，将 skill 优化从「凭感觉」升级为「可度量、可复现」的实验流程
2. 防回退设计：棘轮机制确保质量只升不降，避免「越改越差」
3. 实测导向：40% 权重放在「实测表现」，杜绝纸上谈兵
4. 透明可追溯：results.tsv + git 历史完整记录每次实验，便于复盘
5. 灵活适配：支持全量优化、单个优化、仅评估不改、查看历史等多种使用模式
6. 安全友好：纯 Markdown，无可执行代码，通过 CLS-Certify A 级认证

潜在缺点与局限性

1. 依赖子 agent：效果维度最佳实践需 spawn 子 agent，若环境受限只能「干跑验证」，评估准确度下降
2. 测试 prompt 质量敏感：测试 prompt 设计不当会导致优化方向跑偏，需用户 Phase 0.5 仔细确认
3. hill-climbing 局部最优：虽设计了「探索性重写」逃生舱，但仍可能错过更优的结构性重组方案
4. 时间成本较高：完整流程涉及多轮评估+实测+人类确认，不适合追求极速的场景
5. git 依赖：要求 skills 目录为 git 仓库，纯文件系统环境无法使用版本控制功能
6. 无法评估自身：skill 无法优化自己的 SKILL.md，存在「观察者盲区」

适合人群

• skill 作者：希望系统提升 skill 质量、建立质量基线的创作者
• 团队维护者：管理大量 skills 需要持续质量监控的技术负责人
• 质量审核员：需要对 skills 进行客观评分的评审角色
• 学习者：通过评分反馈理解「好 skill」与「差 skill」的区别

常规风险

1. git 操作风险：虽使用 revert 而非 reset --hard，但用户仍需确认分支状态，避免与本地未提交修改冲突
2. 测试 prompt 泄露敏感信息：设计测试数据时需脱敏，避免在 git 历史中留下真实业务数据
3. 过度优化：hill-climbing 可能在细枝末节上消耗过多轮次，建议在连续 2 个 skill 无改进时主动触发「探索性重写」或结束优化
4. 子 agent 成本：频繁 spawn 子 agent 可能触发 API 限流或产生额外费用，大规模优化时需规划分批执行