从同事.skill到女娲.skill，再到达尔文.skill

同事.skill 是一种很朴素的想法。

把某个同事脑子里的套路、经验、检查清单，做成一个可以被调用的流程。

你不是在“复制一个人”。

你是在把组织里最容易被浪费的部分——重复劳动——压缩成一个接口。

女娲.skill 把这件事往前推了一步。

同事.skill 需要你先有一个同事。

女娲.skill 让你可以“造”一个同事。

输入一个名字、一段人格设定、一套约束，它就能产出一个可运行的思维框架。

从 0 到 1。

从“依赖既有经验”到“批量生产经验”。

但真正危险的地方也在这儿：当你开始拥有几十个 skill，你会遇到一个更现实的问题——你已经不知道它们哪一个在悄悄变坏。

frontmatter 不规范。

步骤漏了关键检查。

引用的路径早就不存在。

最要命的是：写得很漂亮，但跑出来很一般。

你维护不过来。

这就是达尔文.skill 出现的背景。

它解决的不是“怎么造 skill”。

它解决的是“怎么让 skill 自己进化”。

进化的关键不是灵感，是棘轮

Karpathy 的 autoresearch 给了一个特别工程化的隐喻：

随机改一点。

跑一个短实验。

指标变好就保留，变差就回滚。

一个只能向前转的棘轮。

自然界早就这么干了。

随机变异产生候选。

自然选择保留有利的。

时间足够长，草履虫就变成了人。

达尔文.skill 把这套机制搬到 skill 上：

改 SKILL.md → 用一套评分体系评估 → 分数涨了 commit → 分数降了 revert。

你可以放心试错。

失败不会留下疤。

只有成功会被沉淀。

Skill 不是功能，是复利

很多人把 skill 当成“外挂”。

但真正的价值在于它是复利资产：

用得越多，改得越多，越贴合你的真实工作。

问题是，人类没有精力长期维护几十个 skill。

于是大多数人的 skill 系统会走向两个结局：

要么停在第一版。

要么越改越乱。

达尔文.skill 的意义在于，它把“维护”也变成了可自动化的流程。

从此你不需要每次靠手感。

你只需要守住一条底线：分数只能升不能降。

从女娲到达尔文：从“造人”到“造环境”

女娲解决的是生产。

达尔文解决的是选择。

一个负责让候选方案大量出现。

一个负责让劣质方案无法存活。

这其实就是我们在 wiki 里常写的 Harness 逻辑：

模型会越来越强。

真正的壁垒，是系统能不能持续进化。

Evals 不是测试。

Evals 是训练信号。

你给系统一个“只保留改进”的约束，时间就站在你这边。

回到标题：同事 → 女娲 → 达尔文

同事.skill：把一个人的经验压缩成接口。

女娲.skill：把造接口这件事自动化，让候选大量涌现。

达尔文.skill：把筛选接口这件事自动化，让系统只能变好。

三步走完，你得到的已经不是一堆 skill。

你得到的是一个能自我修复、自我进化的工作系统。

参考：https://mp.weixin.qq.com/s/4ICQJGwa2MD616_oFmJb4w