女媧.skill發布一周，GitHub star破了9000+

昨天天接受新京報記者采訪的時候，她問我這個skill花了多長時間制作完成的，我有點不好意思的說實際完成初步設計的過程只有2-3小時，但其實在這個過程中經過了無比多輪的迭代，而這個迭代單純靠我自己完全沒能力做到。

那...是怎么做到的呢？

其實就是在做了50多個自己日常使用的skill之后，我設計了一套讓Skill可以自主完成進化，提升質量的系統。

一套進化體系。

我的53個skill是在不同時間、不同狀態下寫的。有些是凌晨三點靈感來了一口氣寫完的，有些是趕著deadline匆忙搭的。有些skill我用了上百次，迭代到第七八版。

這種狀態在skill只有十幾個的時候還能靠手感維護。但過了50個之后，手動維護就崩了。你不知道哪個skill的frontmatter寫得不規范，哪個skill的工作流有步驟缺失，哪個skill看著結構完美但跑出來的效果其實很差。

我需要一個系統。

一個能自動評估所有skill質量、找出短板、提出改進、驗證效果、只保留有用修改的系統。

然后我刷到了Karpathy的autoresearch。

Karpathy那個7萬star的項目，做了一件什么事

今年3月，Karpathy開源了autoresearch。一個月不到，GitHub上71k+ ?

它做的事情用一句話就能說清楚：讓AI自己跑實驗、自己評估結果、只保留有改進的修改。一個只能向前轉的棘輪。

具體來說：AI agent自動修改訓練代碼，跑5分鐘看loss有沒有下降，降了就保留這次修改（git commit），沒降就回滾（git revert）。每小時大約12個實驗，一晚上能跑100個。

Shopify的CEO拿它優化模板引擎，性能提升了53%。

看到這個項目的時候我愣了一下。這個模式，不只能用來訓練模型。它能用來優化任何有明確評估標準的東西。

比如我的skill。

其實自然界早就在用這套邏輯了。達爾文的進化論本質上就是一個棘輪：隨機變異產生候選方案，自然選擇保留有利的、淘汰有害的，時間足夠長，草履蟲就變成了人。進化沒有設計師，沒有路線圖，它唯一的規則就是「活下來的留下，死掉的消失」。

Karpathy做的事情，是把進化論工程化了。autoresearch里每一次實驗就是一次隨機變異，loss下降就是「活下來」，git revert就是「被自然淘汰」。你猜怎么著，這個邏輯放到skill上也完全成立。

所以我給這個skill取名叫達爾文。

我把autoresearch的思路搬到了Skill優化上

達爾文.skill的核心邏輯和autoresearch完全一樣，只是換了優化對象。autoresearch優化的是訓練代碼，達爾文優化的是SKILL.md。autoresearch用loss判斷好壞，達爾文用一套8維度的加權總分。兩者都用git做版本控制：改好了commit，改差了revert。

但有一個關鍵區別。

autoresearch是全自主的。loss是一個數字，大就是大，小就是小，機器自己比就行。

Skill的「好壞」沒這么簡單。一個skill跑出來的結果好不好，有時候需要人來判斷。所以我加了一個autoresearch里沒有的東西：Human in the Loop（人在回路）。每個skill優化完后系統會暫停，把改動的diff、分數變化、測試輸出的對比擺出來，等我看過確認了才繼續下一個。

這不是偷懶。有些判斷，目前還是人比機器靠譜。

五條原則，每條都是踩坑踩出來的

寫這個skill之前，我已經手動優化過38輪skill了。38次git commit，每次都是手動讀skill、手動找問題、手動改、手動驗證。

這38次下來，我摸出了5條原則：

01 單一可編輯資產。每次只改一個SKILL.md。我早期犯過一次錯：同時改了7個perspective skill的觸發詞和中文表達適配，結果有些變好了有些反而變差了，完全沒法判斷是哪個改動導致的。從那以后，一次一個，絕不貪多。

02 雙重評估。 光看skill寫得規不規范是不夠的。我有個skill，格式完美、步驟清晰、frontmatter無可挑剔，但實際跑出來的效果還不如不加skill。純結構審查發現不了這種問題。所以評估必須分兩層：結構評分看「寫得對不對」，實測評分看「用起來好不好」。

03 棘輪機制。 分數只能升不能降。改完之后比改前差了？git revert，當這次修改沒發生過。這是autoresearch最優雅的設計，我直接搬過來了。

04 獨立評分。 修改skill的agent不能是評分的agent。自己改完自己評，那不叫評估，叫年終自評里給自己打「超出預期」。必須讓一個完全獨立的子agent來打分。

你可能覺得這條多此一舉。讓改skill的agent自己評一下不就行了？2001年安然暴雷的時候，全世界才反應過來一件事：安然的審計師安達信，同時也是安然的咨詢顧問。自己給自己審計，審了個寂寞。后來美國出了薩班斯法案，核心就一條：審計獨立性。做賬的和查賬的必須是兩撥人。道理放到AI agent身上一模一樣。改skill的agent對自己的修改有天然的認知偏差，它會傾向于覺得自己改得不錯。讓另一個完全沒參與修改過程的agent來評分，才能得到一個冷靜的數字。

05 人在回路。 前面說過了。機器做初篩，人做終審。

8個維度，100分制

怎么給一個skill打分？我設計了8個維度，分成兩組。

結構維度占60分，考察6個方面：Frontmatter寫得規不規范（8分），工作流是否步驟清晰（15分），有沒有處理異常情況（10分），關鍵決策前有沒有讓用戶確認（7分），指令夠不夠具體到可以直接執行（15分），引用的文件路徑是否真的存在（5分）。

效果維度占40分，只考察2個方面：整體架構是否合理（15分），以及最關鍵的，拿真實的測試prompt跑一遍，輸出質量到底怎么樣（25分）。

為什么實測表現的權重最高？因為一個skill可以在結構上拿滿分，但跑出來一坨。反過來，一個寫得粗糙但跑起來特別好用的skill，其實比格式完美但沒用的skill有價值得多。

權重分配就是我的態度：實際效果比紙面規范重要。

優化循環長什么樣

整個過程分5個階段，但只有1個是核心。

前面的準備工作比較直接：初始化環境、為每個skill設計測試prompt、跑一遍基線評估建立起點分數。這些是Phase 0到Phase 1。

Phase 2是整個系統的心臟。它做的事情很簡單：找到這個skill得分最低的維度，針對它改一個具體的東西，改完讓獨立子agent重新打分。漲了就留，沒漲就revert。每個skill最多跑3輪。

Phase 3是匯總，輸出一張Before/After的分數表。

每個階段之間都有人類確認的檢查點。系統不會悶頭跑完所有步驟。

棘輪：我最喜歡的部分

舉個例子。假設一個skill的基線分數是72。

第1輪優化后，分數漲到78。保留。
第2輪優化后，分數反而降到75。比當前最優的78還低。回滾。有效基線還是78。
第3輪換個方向優化，分數到84。保留。
第4輪繼續，到87。保留。

最終：72 → 87，凈提升15分。中間那次失敗的嘗試被干凈地回滾了，不會留下任何痕跡。

棘輪的美感就在這里：你可以放心做實驗，失敗不會傷害你。只有成功會被保留。

我后來想了想，棘輪可能是人類發明過的最被低估的結構。科學是一個棘輪：你可以提出錯誤的假說，但一旦一個理論被證偽，它就永遠出局了，人類的知識總量只會增加。民主制度設計里也藏著棘輪：權利一旦被寫進憲法，收回去的成本就極高。甚至你的git歷史本身就是一個棘輪：每個commit都是一個存檔點，你永遠可以回到任何一個過去的好狀態。達爾文.skill只是把這個古老的結構，用在了一個很新的地方。

實際跑了一下，什么效果

我拿自己的skill做了實驗。38次git commit的優化記錄都在倉庫里，挑幾個典型的說說。

huashu-slides（做PPT的skill），5輪優化，是改動最多的一個。第一輪發現最大的問題是style-samples引用了一個不存在的目錄，直接導致skill執行出錯，改成可選引用后立刻提升。第二輪補充了Path B的錯誤處理和生成后必檢清單。第三輪做了5種風格的實測，給每種風格標注了噪點風險分級。第四輪是防泄漏鐵律，把所有base style精簡為短模板。第五輪四項并行沖刺，目標90分。5輪下來，從一個「能用但隨時可能翻車」的skill變成了「你可以去泡杯咖啡回來看結果」級別的可靠。

comedy（脫口秀編劇skill），優化前的問題很典型：風格選擇沒有結構，每次調用都要重新描述想要什么風格，跟每次去理發店都要從頭解釋「就上次那樣」一個道理。優化后加了風格選擇三方案制、推薦矩陣、反默認規則，還補了2個新風格的demo。一輪搞定，改動不大但效果很明顯。

7個perspective skill（芒格、費曼、塔勒布、馬斯克、道金斯、納瓦爾、芒格），這是一次批量優化。先統一做了一輪角色扮演規則和身份卡的補充。第二輪擴展Frontmatter觸發詞和調研來源。第三輪添加示例對話提升實測表現。第四輪收緊觸發詞、加中文表達DNA適配。第五輪把參考內容拆分到references目錄。5輪下來，每個perspective skill從「能用」變成了「風格穩定、不會漂移、有自檢清單」。

但更重要的是過程中發現的共性問題。很多skill都缺少邊界條件處理（如果用戶給了一個模糊的輸入怎么辦？），很多skill的frontmatter描述太短（Claude不知道什么時候該觸發這個skill），很多skill引用了不存在的文件路徑。這些是手動維護時很難發現的模式。

和Anthropic官方skill-creator的區別

說到skill優化，可能有人會問：Anthropic官方不是有個skill-creator嗎？

確實有，我也裝了，經常用。skill-creator是一個很好的工具，它的流程是：捕獲意圖→訪談→寫SKILL.md→跑測試→根據反饋迭代→優化觸發描述。對于從零開始創建一個新skill來說，skill-creator是最佳選擇。

但skill-creator解決的是單個skill的創建和調優。它假設你坐在電腦前，一對一地和它協作打磨一個skill。

達爾文.skill解決的是另一個問題：當你有53個skill的時候，怎么系統性地發現哪些該改、改什么、改了之后有沒有變好。 它是批量的、自主的、有棘輪保護的。

兩者的關系更像是「手工裁縫」和「質量管理體系」。裁縫做衣服，QA確保每件衣服都達標。你不能讓裁縫自己當QA，否則每件衣服都是「設計靈感」，沒有一件叫「質量問題」。

事實上，我在達爾文的評估體系里就參考了skill-creator的一些標準，比如觸發描述的覆蓋度、測試prompt的設計方法。

女媧造人，達爾文進化

女媧.skill解決的是「從0到1」的問題：輸入一個人名，輸出一個可運行的思維框架。它是造人的。

達爾文.skill解決的是「從1到N」的問題：你已經有了一堆skill，怎么讓它們全都變得更好？它是讓所有人進化的。

如果女媧是一個工廠，達爾文就是這個工廠的質檢+持續改進系統。

其實達爾文的機制已經融入了女媧的生產流程。如果你用過女媧.skill，你可能注意到它生成完一個skill之后不會直接交給你，而是會自動啟動一個「Phase 5雙Agent精煉」。這個精煉階段里，Agent A用的就是達爾文的8維度評估體系（工作流清晰度、邊界條件、檢查點設計、指令具體性），Agent B用的是skill-creator視角的觸發條件評審。兩個Agent并行跑完，主Agent綜合報告，應用改進，再交付。

這也是為什么女媧生成的skill質量普遍還不錯的原因之一。出廠就經過了一輪進化。

它們形成了一個完整的閉環：女媧造skill，達爾文磨skill。造完就優化，優化發現的模式又反哺造的過程。

這是一個meta級別的基礎設施。有了它，整個skill生態的質量有了底線。

和autoresearch的關系

我想專門說一下這件事。

達爾文.skill的設計100%受Karpathy autoresearch啟發。棘輪機制、單一資產優化、自主實驗循環，這些核心概念都來自autoresearch。我做的工作是把它從模型訓練的領域搬到了Skill優化的領域，并且加上了Human in the Loop（人在回路）和雙重評估兩個適配。

autoresearch證明了一個優雅的普適模式：對任何有明確評估標準的資產，你都可以讓AI自主實驗、自主迭代、只保留改進。

模型訓練可以。論文寫作可以。Skill優化也可以。

這個模式的遷移性極強。你有任何需要持續優化的東西，都值得想想能不能套上這個框架。

開源

達爾文.skill今天開源了。

跑在自己的Skill前面

我之前寫過一篇「把同事作為skill」，里面有句話：「把自己的工作流程Skill化的人，恰恰是最不容易被Skill替代的人。因為他把重復的部分交給了Skill，自己騰出手來去想新的東西。他永遠跑在自己的Skill前面。」

達爾文.skill讓這件事又往前推了一步。以前是你把流程變成skill，然后自己去做更有趣的事。現在連「讓skill變得更好」這件事本身，也可以交給一個skill來做了。

我的那些skill處理的是我已經想清楚的部分，是標準化了的、可重復的流程。調研怎么做，配圖怎么生成，排版怎么走，這些它們自己流轉自己跑。而我在這上面干的事情，是思考和迭代。達爾文做的，是把「迭代」這件事也自動化了一層。

不過說到底，達爾文.skill解決的問題比skill優化本身更大。它驗證了一個我覺得很重要的直覺：當你給任何創造性工作加上「只保留改進」的約束時，時間就站在了你這邊。 你不需要每一步都走對，你只需要確保走錯的那步不留痕跡。

這個道理適用于skill，也適用于寫作、做產品、甚至過日子。

安裝

GitHub: https://github.com/alchaincyf/darwin-skill

npx skills add alchaincyf/darwin-skill

裝完在Claude Code里說「優化所有skills」或者「優化某個skill」就行。

如果你和我一樣，手里有一堆skill但不確定它們的質量到底怎么樣，這個工具會給你一個清晰的數字。