AI Skills
autoresearch

autoresearch

熱門

適用於任何程式設計任務的自動化反覆實驗循環。引導使用者定義目標、可衡量的指標和範圍限制，然後執行自動循環：修改程式碼、測試、測量，並保留或捨棄結果。靈感來自 Karpathy 的 autoresearch。用途：自動化改進、反覆最佳化、實驗循環、自動研究、效能調校、自動化實驗、爬山演算法、自動嘗試、最佳化程式碼、執行實驗、自動化編碼循環。不適用於：一次性任務、簡單的錯誤修正、程式碼審查，或沒有可衡量指標的任務。

3.7萬星標
4637分支
更新於 2026/7/24
獲取技能源代碼

相關技能

frontend-testing15萬vitest11萬subagent-driven-development23萬
SKILL.md
readonlyread-only
name
autoresearch
description

適用於任何程式設計任務的自動化反覆實驗循環。引導使用者定義目標、可衡量的指標和範圍限制，然後執行自動循環：修改程式碼、測試、測量，並保留或捨棄結果。靈感來自 Karpathy 的 autoresearch。用途：自動化改進、反覆最佳化、實驗循環、自動研究、效能調校、自動化實驗、爬山演算法、自動嘗試、最佳化程式碼、執行實驗、自動化編碼循環。不適用於：一次性任務、簡單的錯誤修正、程式碼審查，或沒有可衡量指標的任務。

Autoresearch：自動化反覆實驗

適用於任何程式設計任務的自動化實驗循環。您定義目標和衡量方式；代理程式會自動反覆迭代——修改程式碼、執行實驗、測量結果，並保留或捨棄變更——直到被中斷為止。

此技能靈感來自 Karpathy 的 autoresearch，從機器學習訓練推廣到任何具有可衡量結果的程式設計任務。

代理行為規則

  1. 務必在開始循環前，以互動方式引導使用者完成設定階段。
  2. 務必在進行任何變更前，先建立基準測量值。
  3. 務必在每次實驗嘗試前先提交（以便能乾淨地還原）。
  4. 務必維護結果記錄檔（TSV），追蹤每次實驗。
  5. 務必還原未改善指標的變更（git reset 到最後已知的良好狀態）。
  6. 務必在循環開始後自動執行——絕不停下來問「我該繼續嗎？」。
  7. 不得修改使用者標記為範圍外的檔案。
  8. 不得跳過測量步驟——每次實驗都必須測量。
  9. 不得保留使指標退步的變更，除非使用者明確允許取捨。
  10. 不得安裝新的相依套件或變更環境，除非使用者同意。

階段 1：設定（互動式）

在開始任何實驗之前，與使用者共同建立這些參數。直接向使用者詢問每個項目。不要假設或跳過任何項目。

1.1 定義目標

詢問使用者：

您想要改善或最佳化什麼？

範例：執行時間、記憶體使用量、二進位檔大小、測試通過率、程式碼涵蓋率、
API 回應延遲、吞吐量、錯誤率、基準分數、建置時間、打包大小、
程式碼行數、循環複雜度等。

將使用者的答案記錄為目標。

1.2 定義指標

詢問使用者：

我們如何衡量成功？哪個指令可以產生指標？

我需要：

  1. 要執行的指令（例如 dotnet test、npm run benchmark、time ./build.sh、pytest --tb=short）
  2. 如何從輸出中提取指標（例如正規表示式模式、特定行、JSON 欄位）
  3. 方向：越低越好還是越高越好？

範例：「執行 dotnet test --logger trx，計算通過的測試數。越高越好。」
範例：「執行 hyperfine './my-program'，提取平均時間。越低越好。」

記錄：

  • METRIC_COMMAND：要執行的指令
  • METRIC_EXTRACTION：如何從輸出中提取數值指標
  • METRIC_DIRECTION：lower_is_better 或 higher_is_better

1.3 定義範圍

詢問使用者：

我可以修改哪些檔案或目錄？

哪些檔案是禁止修改的（唯讀）？

記錄：

  • IN_SCOPE_FILES：代理程式可以編輯的檔案/目錄
  • OUT_OF_SCOPE_FILES：不得修改的檔案/目錄

1.4 定義限制條件

詢問使用者：

有什麼我應該遵守的限制條件嗎？

範例：

  • 每次實驗的時間預算（例如「每次執行應少於 2 分鐘」）
  • 不新增相依套件
  • 必須保持所有現有測試通過
  • 不得變更公開 API
  • 必須維持向後相容性
  • VRAM/記憶體限制
  • 程式碼複雜度限制（偏好較簡單的解決方案）

記錄為 CONSTRAINTS。

1.5 定義實驗預算（選擇性）

詢問使用者：

我應該執行多少次實驗，還是持續進行直到您停止我？

您可以指定數字（例如「嘗試 20 次實驗」）或「無限制」（我會一直執行直到您中斷）。

記錄為 MAX_EXPERIMENTS（數字或 unlimited）。

1.6 簡潔性原則

告知使用者預設的簡潔性原則：

簡潔性原則（預設）： 在其他條件相同下，越簡單越好。一個小改善如果帶來醜陋的複雜性，並不值得。在維持或改善指標的同時移除程式碼，是很好的結果。我會權衡複雜性成本與改善幅度。這個原則對您適用嗎？或者您想要調整？

記錄任何調整為 SIMPLICITY_POLICY。

1.7 確認設定

以清晰的表格向使用者總結所有參數：

參數 值
目標 ...
指標指令 ...
指標提取方式 ...
方向 越低越好 / 越高越好
範圍內檔案 ...
範圍外檔案 ...
限制條件 ...
最大實驗次數 ...
簡潔性原則 ...

要求使用者確認。在確認之前不要繼續。

階段 2：分支與基準

一旦使用者確認：

  1. 建立分支：根據今天的日期提議一個標籤（例如 autoresearch/mar17）。
    建立分支：git checkout -b autoresearch/<tag>。

  2. 讀取範圍內檔案：讀取所有範圍內的檔案，以建立當前狀態的完整上下文。

  3. 初始化 results.tsv：在儲存庫根目錄建立 results.tsv，包含標題列：

    experiment	commit	metric	status	description

    將 results.tsv 和 run.log 加入 .git/info/exclude（如果尚未存在則附加），使其保持未追蹤狀態，而不修改任何已追蹤的檔案。

  4. 執行基準測試：在當前未修改的程式碼上執行指標指令。
    將結果記錄為實驗 0，狀態為 baseline，寫入 results.tsv。

  5. 向使用者回報基準值：

    基準已建立：[指標名稱] = [數值]
    開始自動化實驗循環。

階段 3：實驗循環

持續執行此循環。不要停下來詢問使用者。執行直到：

  • 達到 MAX_EXPERIMENTS，或
  • 使用者手動中斷

每次實驗：

LOOP:
  1. 思考   - 分析先前的結果和當前程式碼。
              產生一個實驗假設。
              考慮：哪些有效、哪些無效、哪些還沒嘗試過。

  2. 編輯   - 修改範圍內的檔案以實作想法。
              每次實驗保持變更集中且最小化。

  3. 提交   - git add + git commit，附上簡短的描述性訊息。
              格式：「experiment: <變更內容的簡短描述>」

  4. 執行   - 執行指標指令。
              將輸出重新導向到 run.log，以免淹沒上下文視窗。
              使用適合 shell 的重新導向：
              - Bash/Zsh：`<command> > run.log 2>&1`
              - PowerShell：`<command> *> run.log`

  5. 測量   - 從 run.log 中提取指標。
              如果提取失敗（當機/錯誤），讀取 run.log 的最後 50 行以取得錯誤資訊。

  6. 決定   - 將指標與當前最佳值比較：
              - 改善：保留提交。更新「最佳」基準。
                記錄狀態為「keep」。
              - 相同或更差：還原。`git reset --hard HEAD~1`。
                記錄狀態為「discard」。
              - 當機：嘗試快速修正（拼寫錯誤、匯入、簡單錯誤）。
                修改實驗提交（`git commit --amend`）並重新執行。實驗保留原始編號。
                如果嘗試 2 次後仍無法修正，則還原整個實驗
                （`git reset --hard HEAD~1`）並記錄狀態為「crash」。

  7. 記錄   - 在 results.tsv 中附加一行：
              experiment_number  commit_hash  metric_value  status  description

  8. 繼續   - 回到步驟 1。

實驗策略

產生實驗想法時，依此優先順序：

  1. 先摘低垂果實：簡單的參數調整、明顯的無效率之處。
  2. 根據結果調整：如果某個方向顯示出潛力，進一步探索該方向。
  3. 高原期後多樣化：如果最近 3-5 次實驗都失敗，嘗試完全不同的方法。
  4. 組合勝出者：如果實驗 A 和 B 各自獨立改善，嘗試將它們結合。
  5. 簡化回合：定期嘗試移除程式碼/複雜性，看看指標是否維持。
  6. 激進變更：在窮盡漸進式想法後，嘗試較大的架構變更。

處理限制條件

  • 時間預算：如果執行時間超過預期時間的 2 倍，終止它並視為當機。
  • 現有測試：如果限制條件要求測試通過，在變更前後執行測試，如果測試失敗則還原。
  • 記憶體/資源：監控並在資源使用超過規定限制時還原。

階段 4：報告

當循環結束（達到預算或使用者中斷）：

  1. 以格式化表格列印完整的 results.tsv。
  2. 總結：
    • 執行的實驗總數
    • 保留 / 捨棄 / 當機的實驗數
    • 起始指標（基準）與最終指標
    • 改善百分比
    • 最具影響力的前 3 項變更
  3. 顯示保留實驗的累積 git 記錄：
    git log --oneline <start_commit>..HEAD
  4. 建議下一步：根據結果，建議人類研究員接下來可以嘗試什麼（對自動化實驗來說風險太高或太複雜的想法）。

快速參考

結果 TSV 格式

Tab 分隔，5 欄：

experiment	commit	metric	status	description
0	a1b2c3d	0.997900	baseline	未修改的程式碼
1	b2c3d4e	0.993200	keep	提高學習率至 0.04
2	c3d4e5f	1.005000	discard	切換為 GeLU 激活函數
3	d4e5f6g	0.000000	crash	加倍模型寬度（OOM）

Git 工作流程

  • 所有實驗都在 autoresearch/<tag> 分支上進行
  • 每次實驗在執行前先提交
  • 失敗的實驗透過 git reset --hard HEAD~1 還原
  • 成功的實驗推進分支
  • results.tsv 和 run.log 保持未追蹤（已加入 .git/info/exclude）

關鍵原則

  1. 測量一切：沒有測量就沒有實驗。
  2. 還原失敗：分支只在有改善時前進。
  3. 保持自主：絕不停下來詢問。卡住時更努力思考。
  4. 保持簡單：複雜性是一種成本。權衡它與收益。
  5. 記錄一切：TSV 就是研究日誌。