AutoResearch 解析：前端團隊的自主研究迴圈實作

看懂 AutoResearch 在解決什麼問題，並把「可量測的自動迭代」帶進你的前端工作流。

前言

很多前端工程師第一次聽到 AutoResearch，會直覺認為那是 ML 研究員的玩具，和 UI、TypeScript、產品迭代距離很遠。這個判斷只對一半。AutoResearch 真正有價值的地方，不是「它在訓練小型語言模型」，而是它把研究流程拆成可重複執行的回圈：提出假設、改動系統、跑實驗、看指標、保留有效變更。

這個回圈其實和前端日常非常接近。你在做 bundle size 優化、渲染效能調校、A/B 實驗、甚至 CI 品質閘道，本質上都在做同一件事：用可量測指標去淘汰不工作的想法。

因此，這篇文章不把 AutoResearch 當新聞，而是當一種工程方法：它為什麼值得前端圈關注、和常見 AI coding agent 有何差異、以及你今天就能借鏡的實作方式。

Andrej Karpathy 的脈絡：為什麼是他先做這件事

Andrej Karpathy 的公開作品通常有兩個特徵：

以最小可理解程式碼呈現核心觀念，而不是先堆大型基礎設施。
強調可驗證的指標與實驗紀錄，讓改動不是靠感覺決策。

AutoResearch 延續同一思路。它把研究空間收斂到一個小而真實的訓練環境，讓 agent 對單一檔案持續改動，在固定時間預算下反覆實驗。重點不是「一次改很多」，而是「在一致的評估條件下，快速試錯並留下可追溯紀錄」。

把這個脈絡套回前端，就是把效能優化、架構選型、提示工程（prompt engineering）從一次性討論，變成長時間可持續的系統。

AutoResearch 核心機制：不是更聰明的提示詞，而是更嚴格的回圈

先用一句話定義 AutoResearch：

AutoResearch 是一個「目標導向的自治實驗流程」，讓 agent 在固定資源限制內持續提出改動並以單一評估指標決定去留。

可以把它拆成五個元件：

Program：人類定義目標、邊界、成功條件。
Mutable Surface：允許 agent 改動的範圍（例如單一檔案或單一模組）。
Experiment Runner：每次改動後自動執行測試或訓練。
Metric Gate：用固定指標比較新舊版本。
Logbook：完整紀錄每輪假設、變更與結果，避免重踩同一坑。

下面是前端情境可直接改造的 program.md 範例（可執行流程，內容可依專案調整）：

# Goal
在不降低 Lighthouse Accessibility 分數的前提下，提升首頁 Performance 分數至少 5 分。

# Constraints
- 只能修改 `src/pages/index.tsx` 與 `src/components/hero/*`
- 不可移除既有功能與追蹤事件
- 每輪實驗最多修改 120 行

# Evaluation
1. `pnpm build` 必須成功
2. `pnpm test` 必須全綠
3. `pnpm lhci` 取得 `performance` 與 `accessibility`
4. 僅當 `performance` 上升且 `accessibility` 不下降才接受變更

# Iteration Budget
- 最多 20 輪
- 任一輪失敗就回滾該輪改動，進入下一輪

再來是可以在 CI 執行的評分腳本，用來把「是否接受該輪改動」變成明確規則：

// scripts/evaluate-experiment.ts
import { readFileSync } from "node:fs";

type LhciReport = {
  categories: {
    performance: { score: number };
    accessibility: { score: number };
  };
};

function load(path: string): LhciReport {
  return JSON.parse(readFileSync(path, "utf8")) as LhciReport;
}

const base = load("./artifacts/base-lhci.json");
const candidate = load("./artifacts/candidate-lhci.json");

const perfDelta = candidate.categories.performance.score - base.categories.performance.score;
const a11yDelta = candidate.categories.accessibility.score - base.categories.accessibility.score;

// 核心 gate：效能要進步，且可及性不能退步
if (perfDelta > 0 && a11yDelta >= 0) {
  console.log("ACCEPT", { perfDelta, a11yDelta });
  process.exit(0);
}

console.error("REJECT", { perfDelta, a11yDelta });
process.exit(1);

這段程式本身不神奇，但它揭示一個關鍵：AutoResearch 的價值來自「穩定評估介面」，不是 agent 本身多厲害。

和常見 AI agent / research workflow 的差異

很多團隊已經在用 AI agent 幫忙寫 code review、補測試、產生重構 patch。這些都很實用，但和 AutoResearch 有三個結構性差異：

任務型 vs. 迭代型。一般 coding agent 偏向單輪任務（完成一張 ticket）；AutoResearch 追求多輪疊代（連續 10 到 100 輪）。
輸出導向 vs. 指標導向。一般 workflow 的終點是「有一份可合併的 diff」；AutoResearch 的終點是「指標可證明更好」。
人工判讀為主 vs. 評估器判讀為主。一般流程常在 PR 階段才人工決定好壞；AutoResearch 把大部分淘汰決策前移到自動評估階段。

所以如果你只是把 ChatGPT prompt 換長一點，或加上多步驟 chain，通常還不算 AutoResearch。真正的門檻是你有沒有把「變更接受條件」變成機器可重複執行的規則。

前端場景下的啟發：三個可以先做的小型落地

1. Bundle / Runtime 雙指標調校

把 webpack 或 Vite 產物大小，以及關鍵頁首屏渲染時間綁在同一個 gate。只追 bundle 可能犧牲 runtime，雙指標能避免「優化了一邊、打壞另一邊」。

2. Design System 變更的回歸研究

當你調整 token 或元件 API，可讓 agent 自動跑 visual regression 與 a11y 掃描，只有兩者都過關才保留。這比只看 snapshot 更接近產品真實風險。

3. Prompt + Tooling 要一起看

前端團隊常把 prompt tuning 與工具腳本分開討論，但 AutoResearch 觀點是兩者一起優化。這會比單獨調 prompt 更穩定，因為行為邊界有工具層兜底。

限制與風險：不處理這些，AutoResearch 只會製造更多雜訊

Hallucination 與錯誤歸因

agent 會編造「看似合理」的改動理由。若你的評估指標太少，可能接受了短期有效、長期有害的 patch。建議至少保留一個產品層指標（例如真實 user flow 成功率）避免模型只對 benchmark 投機。

評估成本與算力預算

多輪實驗很容易燒掉 CI 時間。實務上要先定義停止條件，例如連續 5 輪無提升就終止。

資料品質與可重現性

沒有固定資料切分、沒有固定 seed、沒有一致執行環境時，指標波動會讓你誤判。AutoResearch 想成立，先決條件是可重現，不是更大模型。

安全與權限邊界

agent 若可直接碰 production credentials，風險遠高於收益。建議將可寫範圍限制在 sandbox 分支，且用短效憑證執行自動化。

常見問題 / 注意事項

AutoResearch 一定要從 ML 訓練開始嗎？

不用。你可以先從「有明確分數函數」的前端問題開始，例如 Lighthouse、Vitest pass rate、Playwright flaky rate。

沒有 H100 或高階 GPU，還有價值嗎？

有。對前端團隊來說，重點是流程設計，不是追最大模型。即使只在一般 CI runner 跑較小實驗，也能建立可持續的改進機制。

我們已經有 AI code assistant，還要做這套嗎？

如果你已能穩定把「提案 -> 實驗 -> 指標 -> 採納」自動化，價值會高於單次寫碼加速。兩者不是互斥。

總結

AutoResearch 真正帶來的，不是新名詞，而是可複製的工程紀律：先定義可量測目標，再讓 agent 在受控邊界內高速試錯，最後由指標決定改動命運。

對前端工程師的具體 takeaway 很簡單：

把你最常做的優化工作，改寫成可重複執行的實驗回圈。
用「固定評估 + 明確 gate」取代主觀好壞判斷。
從小問題開始（例如首頁效能或 a11y），先跑出第一個能連續改進的流程。

當你做到這一步，AutoResearch 就不再只是 AI 圈話題，而是你團隊可以累積複利的實作能力。