一個GitHub倉庫在72小時內(nèi)被fork了800多次，不是新模型，是一套讓AI自己優(yōu)化自己的實驗框架。Andrej Karpathy——那個從OpenAI離職、又在特斯拉帶自動駕駛團隊、現(xiàn)在做AI教育的男人——把這套叫autoresearch的東西扔了出來。

簡單說：你讓Claude Code跑一個循環(huán)，幾小時或幾天后，得到一個更好的模型。整個過程寫在program.md里，像一份"技能說明書"。

但有個程序員發(fā)現(xiàn)，這玩意根本不用來訓(xùn)模型，改改就能讓AI自己學(xué)會寫更好的代碼。

從"煉丹"到"碼農(nóng)"：同一套邏輯換了個場景

Karpathy的原版設(shè)計是給大模型訓(xùn)練用的。核心就一句：用實驗結(jié)果驅(qū)動下一代版本的生成。你跑實驗、看指標、自動改代碼、再跑，循環(huán)往復(fù)。

這位程序員（我們叫他作者）不搞模型訓(xùn)練，但天天用Claude Code寫代碼。他的痛點很實在：怎么讓AI生成的代碼既符合團隊規(guī)范，又能過得了人眼審查？

他現(xiàn)在靠"感覺"優(yōu)化——試個最佳實踐，覺得有用就加進工作流；代碼審查發(fā)現(xiàn)問題，再回頭修流程。這辦法能用，但不夠科學(xué)。

看到autoresearch之后，他意識到：既然能自動優(yōu)化訓(xùn)練流程，為什么不能自動優(yōu)化"讓AI寫代碼"的流程？

把代碼生成變成可測量的實驗

作者設(shè)計了一個技能自動改進循環(huán)，對標Karpathy的原版框架。

先定義一個標準技能流程：接收任務(wù)→探索→規(guī)劃→執(zhí)行→審查。去掉需要人類介入的交互環(huán)節(jié)，純自動化。

關(guān)鍵是讓實驗可重復(fù)、指標可比較。你需要一組測試用例：輸入是任務(wù)描述，輸出是參考代碼。

原版autoresearch用一個指標（val_bpb，驗證集比特/字符）決定版本生死。但代碼質(zhì)量沒法用一個數(shù)概括，作者設(shè)計了多維度評分：

最終簡化為二元判斷：通過/不通過。夠粗暴，但跑得起來。

循環(huán)結(jié)構(gòu)照搬原版：生成候選版本→跑測試→計算指標→選最優(yōu)→進入下一輪。每輪狀態(tài)獨立，不依賴歷史記憶。

理論上可行，坑還在后面

作者自己也列了一堆待解難題：

測試用例從哪來？真實業(yè)務(wù)代碼涉密，公開數(shù)據(jù)集又不夠貼合。指標設(shè)計更是玄學(xué)——代碼可讀性和執(zhí)行效率經(jīng)常打架，怎么加權(quán)？

還有版本爆炸問題。Karpathy訓(xùn)模型可以跑幾天，代碼技能迭代如果每次都要完整執(zhí)行測試集，成本和時間怎么控制？

最麻煩的是反饋延遲。模型訓(xùn)練的損失曲線實時可見，代碼質(zhì)量的"好"往往要等人類審查后才能確認，這打破了自動循環(huán)的前提。

作者說這些坑得在實現(xiàn)和早期運行中才能摸清。他打算先跑起來，有初步結(jié)果再分享。

一個值得玩味的細節(jié)

整個設(shè)計里最"產(chǎn)品經(jīng)理"的決策，是那個二元評分。作者明明列了多維度指標，最后卻選了通過/不通過。

他的解釋藏在字里行間：設(shè)計階段要簡單，跑起來再迭代。這和Karpathy的原版思路一致——先讓循環(huán)轉(zhuǎn)起來，再優(yōu)化測量精度。

現(xiàn)在倉庫里只有框架描述，沒有實現(xiàn)代碼。但fork數(shù)還在漲，顯然不少人想試試：如果AI能自己學(xué)會寫更好的代碼，程序員的工作會變成什么？

作者最后留了個問題沒答：當AI開始優(yōu)化"讓AI寫代碼"的流程，人類審查者在這個循環(huán)里，到底算什么角色？