Karpathy把訓練AI那套搬到寫代碼

Andrej Karpathy開源了一個叫autoresearch的項目，核心邏輯簡單粗暴：讓AI自己跑實驗、看結果、改參數，循環幾天，模型就變強了。這套原本用來訓練大語言模型的自動化流程，現在被人搬到了日常寫代碼的場景里。

一位長期用Claude Code的開發者看完代碼后，直接動手改了個版本。他的目標不是訓練模型，而是讓AI助手自己優化自己的"工作習慣"——怎么拆解任務、怎么查代碼庫、怎么保證輸出風格一致。這相當于給Claude裝了個自動迭代的反饋系統。

從煉丹到寫代碼，同一套自動化邏輯

Karpathy的原版autoresearch針對的是LLM訓練場景。你定好一個指標（比如驗證集上的bits per byte），然后讓Claude Code自動改訓練代碼、跑實驗、記錄結果。能提升指標就保留，不行就回滾。整個過程可以無人值守跑上幾天。

這位開發者平時寫代碼已經高度依賴Claude Code，但他發現自己的"使用方式"很隨意。測試新技巧靠感覺，優化流程靠人工復盤。他形容這是"不科學"的——沒有對照實驗，沒有穩定指標，改進全靠拍腦袋。

于是他決定把autoresearch的骨架抽出來，套到coding skill的優化上。

一個典型的coding skill長這樣：接收任務→探索代碼庫→制定計劃→執行→自我審查。他要做的，就是設計一套實驗機制，讓這個流程本身自動進化。

三個硬指標，卡住AI的 output 質量

原版autoresearch只用單一指標（val_bpb）決定生死，但寫代碼顯然更復雜。這位開發者設計了三個關鍵指標：

第一，代碼是否通過測試。這是底線，沒商量。

第二，是否符合項目規范。包括命名風格、文件組織、注釋習慣——這些往往寫在項目的CONTRIBUTING.md或者團隊內部文檔里，但AI經常選擇性忽略。

第三，人工審查通過率。模擬真實的code review場景，看AI生成的代碼能不能過得了人類同事那關。

為了簡化，他先用二元評分：過/不過。未來可以擴展成更細粒度的打分，但二進制足夠啟動循環。

無狀態循環：每次迭代都是全新的開始

整個auto-improve loop的設計刻意保持無狀態。每次迭代從當前最佳版本出發，生成一個候選變體，跑完整套測試，根據三個指標決定是晉升為新baseline還是丟棄。

這意味著系統不會"記住"之前失敗的嘗試，也不會被局部最優困住。每次都有機會徹底重構skill的結構，而不是在現有框架上修修補補。

這種設計有個副作用：如果某次迭代把skill改崩了，直接丟棄就行，不會污染后續實驗。代價是可能重復探索相似的空間，但換來了穩定性和可并行性。

開發者提到，這套機制理論上可以讓AI完全自主地"訓練"自己的coding skill，針對特定代碼庫和團隊習慣持續優化，不需要人類盯著每一步。

落地前的三道坎

想法很干凈，實現起來還有一堆麻煩。

測試用例從哪來？需要大量真實的"任務-參考代碼"pair，覆蓋不同復雜度、不同領域的場景。自己造數據容易過擬合，用生產代碼又有隱私問題。

指標怎么量化？"符合規范"和"通過審查"都有主觀成分。兩個人review同一份代碼可能給出不同結論，怎么讓AI學會這種模糊判斷？

還有成本問題。每個候選版本都要跑完整套測試，如果skill本身調用API或者操作數據庫，實驗開銷會指數級膨脹。

這些坑不會在設計階段顯形，只有真正跑起來才知道深淺。開發者說他會在有初步結果后繼續分享——目前還停留在紙面推演。

如果這套機制跑通，意味著AI助手的進化方式會發生質變。不再是廠商統一推送模型更新，而是每個團隊、每個代碼庫都能養出自己的"定制化AI同事"。你的Claude和我的Claude，半年后可能完全是兩種工作風格。

這種分化是效率的極致，還是協作的噩夢？當AI的技能樹開始碎片化，人類程序員該怎么跟不同"性格"的AI搭檔？