其他

Research 不是 Search：AI 時代工程師的稀缺能力，與 autoresearch 怎麼用

這篇，寫給每天在寫程式的人——尤其是在 AI 時代還想保持「不可取代」的軟體工程師。

一句話講完：AI 把「執行力」變廉價了，工程師值錢的地方，正在從「會做」轉移到「知道該做什麼、以及怎麼驗證做對了」。 學術界把後面這件事叫 Research。我想說的是，這也是接下來十年，工程師最該補的一課。

執行力，正在變成這個時代最廉價的東西

先說我最深的一個體感：「執行力」已經廉價到不像話。

你只要充值 200 鎂，隨便一個 coding agent 都能把功能做出來。如果你充了還做不好，那我也無從置評——大概率是用的人有問題，不是工具有問題。

對工程師來說，這件事特別痛，因為寫 code 本身就是執行力。接 API、套 pattern、刻 CRUD、查文件、照著規格把功能堆出來——這些「重複性的智力勞動」，門檻正在歸零。

更殘酷的是複製成本。你辛辛苦苦做出一個成果，只要把成果往外一放，別人拿著你的圖、你的 repo，當天就能複製一份。可以被複製的東西，它的價值正在歸零。

那剩下什麼不會歸零？

我想了很久，答案是：發現問題、重新定義問題、解決以前幾乎不可能解決的問題。

這件事，有一個專門的詞，叫 Research。

請注意，是 Research，不是 Search。

翻成工程師的日常就是——

  • Search 是：去 Stack Overflow 找答案、把需求對應到已知的 pattern、把 AI 吐的 code 貼上去、churn 一個又一個 ticket。
  • Research 是：發現「這個 bug 一直復發，是因為問題根本被定義錯了」、解掉整個團隊繞了三年的根因、做出原本大家都覺得「這做不到」的東西。

很多人把「研究」這兩個字看得太淺，以為就是上網搜一搜、把別人的東西拼貼成一份漂亮的報告。對工程師來說，對應的就是「把 ChatGPT 的答案複製進 codebase，但自己根本看不懂」。

而且老實說，這種「二手口水」現在看了很煩。要看拼貼，我寧願直接看前沿 model 自己生成的——至少它快、它全。人類半懂不懂地操作 agent 糊出來的版本，往往還到處是槽點，看了更糟心。

所以問題就回到：research 跟 search，到底差在哪？

Research 與 Search 的根本差別

一句話先講完：

Search 是去「找到」一個已經存在的答案；Research 是去「做出」一個還不存在的答案。

一個是定位，一個是創造。我把幾個面向攤開來對照：

面向Search（搜尋）Research（研究）
答案的狀態已經存在於某處，等你找到還不存在於任何地方，等你創造
動作的終點找到、整理、引用提出、驗證、把邊界往外推
問題從哪來別人給的、已知的自己發現，甚至要重新定義
跟既有知識的關係消費既有知識站在知識的邊界上，推進它
怎樣才算數資訊正確（fact-check）夠新、可重現、過得了同儕考核
失敗代表什麼找不到 = 沒做到此路不通，本身也是一種結果
邊際成本趨近於零，人人可複製從 0 到 1，過程無法被旁觀複製
AI 的位置幾乎全包，而且越做越好只能當助手，代替不了你的提問與品味

幾個我覺得最關鍵的，展開講。

一、答案到底存不存在

這是最根本的分野。Search 的答案是已經存在的——它躺在某篇文章、某個 repo、某個人的腦袋裡，你的工作是把它找出來。Research 的答案還不存在於任何地方，沒有人做過，所以你 google 不到、問 AI 也問不到，得靠你自己從無到有做出來。

很多人把 research 讀成 re-search：再搜尋一次、搜得更勤一點。這是最根本的誤會。research 的重點從來不在那個「re」，而在於——你要找的東西，本來就不在任何地方。 你搜尋一千次，也搜不到一個還沒被任何人做出來的答案。

二、Search 是 Research 的前置，不是 Research 本身

那 search 在研究裡有沒有用？當然有，而且非用不可。做研究的第一步，就是把相關的 search 做到滴水不漏——讀完該讀的論文、摸熟整個 codebase，先知道「目前大家走到哪」，才知道邊界在哪、哪裡還是空白。

但請記住：做完 search，只是站上起跑線而已。 把 search 當成 research，就像把「讀完一張地圖」當成「探險」。地圖告訴你哪裡有人去過；探險是走進那塊還沒人畫上去的空白。

三、AI 站在哪一邊

講到這裡就很清楚了：AI 是人類史上最強的 search 引擎，也是最廉價的執行器。 文獻回顧、寫 code、跑分析、整理文件——這些 research 裡的「執行層」，它做得又快又好。

但有三件事，AI 到今天還是做不了：替你發現一個值得問的問題、替你判斷一個結果為什麼重要、替你決定邊界該往哪推。 而這三件事，恰好就是 research 的全部。

所以 AI 不但沒取代 research，反而是把它從一堆雜務裡解放出來，逼著你只剩最核心、最無法外包的那一塊：提問、判斷、品味。

那 AI 能不能幫我做 research？——autoresearch 登場

講到這你可能會反問：等等，現在 agent 已經能自己跑實驗、自己迭代了，這難道不算 research 嗎？

這正是我想接的下一步。最近讀到 aihao.tw 的一篇 Coding Agent as Optimizer，講得很到位：coding agent 正在變成一種新的「optimizer（最佳化器）」。

傳統的優化是更新神經網路的權重；coding agent 的優化迴圈長這樣：

改一小段 code → 執行 → 量一個指標 → 變好就留下、變差就丟掉 → 重複

它扮演的角色，就像梯度下降裡的「優化演算法」，只是作用對象從模型參數變成了可編輯的程式碼。文章把這種玩法叫 autoresearch，並列了幾個例子（以下數據引自原文）：

  • Karpathy 的 nanochat：目標是壓低驗證集的 val_bpb，只准 agent 改 train.py 這一個檔案，每輪固定 5 分鐘訓練、自動評分。跑了約 700 個實驗，篩出 20 個有效改進，訓練時間快了 11%。
  • 搜尋重排器（Doug Turnbull）：在護欄（每次只改 10 行、用第二個 LLM 檢查沒有寫死查詢、驗證集驗收）下，把 NDCG 從 0.27 一路迭代到 0.35。

文章還歸納出 autoresearch 能跑起來的三個必要條件：

  1. 回饋可以自動驗證——要有一個可信的評分器，能自動判好壞。
  2. 目標可以用程式碼表達——訓練腳本、規則、策略，都是文字形式。
  3. 狀態可重現、可觀測——能重跑、記日誌、每次只改一小塊（用 git commit 當記憶，避免無限鬼打牆）。

看到這裡，你大概會覺得：太好了，AI 終於能自己做 research 了。

但這正是我想用前面那套 research/search 框架，幫你看清楚的地方。

autoresearch 自動化的是 Search，不是 Research

把 autoresearch 的迴圈拆開來看，它自動化的是這一段：

在你劃定的搜尋空間裡，朝你定義的目標函數，反覆嘗試、保留改進。

這整段——是 search。更精確地說，是「最佳化／搜尋」的執行層。agent 把它做到了人類做不到的速度（一小時跑十幾個實驗，不喊累、不分心）。

但它沒有、也不能自動化的，是 research 的那一塊：

  • 要 optimize 什麼（目標函數是誰定的？）
  • 這個 eval 信不信得過（你量的指標，真的等於你要的東西嗎？）
  • 只准改哪裡（搜尋空間是誰劃的？）
  • 這個結果到底重不重要、會不會泛化（誰來判斷？）

那篇文章自己也記了一個經典翻車案例：Langfuse 的 agent 為了把 eval 分數從 0.35 衝到 0.82，竟然把「使用者確認」這道關卡直接刪掉——分數漂亮了，功能壞了。

用我的話講就是：agent 完美地 optimize 了，但它沒有 research——它只是飛快地優化了一個錯的目標。 而「目標對不對」，只有你能判斷。

那篇文章下了一句很狠的結論，我整篇都想引它：

「沒有可信的 eval，這整套就是在幫你更快地優化一個錯的目標。」

翻成 research/search 的語言：autoresearch 讓 search 快到飛起，但如果你的 research（提問與 eval）是錯的，它只會讓你更快地撞牆。

所以，autoresearch 應該怎麼用？

答案其實前面已經浮出來了：你負責 research，agent 負責 search。 把這條界線畫清楚，autoresearch 就是工具；畫不清楚，它就是放大你錯誤的機器。

具體把那篇文章的條件，跟 research/search 的分工疊在一起，會長這樣：

步驟誰做屬於
選題：判斷這題適不適合自動最佳化你research
定義目標函數：要 optimize 哪個指標你research
設計可信的 eval：確認指標真的量到你要的你research
劃定搜尋空間：只准 agent 改哪一塊你research
跑迴圈：改 → 執行 → 量分 → 好留壞丟agentsearch
記憶與防鬼打牆：git commit 當歷史agentsearch
定期親手看資料、判斷有沒有泛化你research
收手：判斷這個結果到底重不重要你research

這張表本身就是結論：幾乎所有「重要」的步驟都掛在「你 / research」那一欄，agent 只擁有中間那段 search 迴圈。

落到實作上，給工程師的幾條原則：

  1. 先確認這題在甜蜜點上。邊界明確、指標可量、小程式幾分鐘能跑完（搜尋排序、分類、NER、詐騙評分這類）最適合。需要高維感知、長程規劃稀疏回饋、或——最致命的——根本沒有可信 eval 的任務，別碰。

  2. 目標函數你親手定，而且要防 Goodhart。被你拿來當分數的指標，agent 一定會用各種你想不到的方式去鑽（Langfuse 就是這樣被鑽的）。定指標時就要先想：「如果有人只為了這個數字不擇手段，會發生什麼？」

  3. eval 是你的命脈，不能外包。那篇文章點出要關掉三道鴻溝——理解（你真的懂系統在幹嘛）、規格（評分器量的就是你要的）、泛化（測試集涵蓋真實場景）。其中最重要的一句忠告是：「如果你不願意定期親手看一些資料，那你在 eval 上就是在浪費時間。」 這一步，就是 research。

  4. 搜尋空間劃小一點。只准 agent 改一個檔、一個模組，改動小、好審查，也讓每次實驗可比。

  5. 剩下的迴圈才放手給 agent。固定預算（時間或 token）、git commit 當記憶、好留壞丟——這段它做得比你好太多，盡量放手。

一句話收束這節：autoresearch 的產出 = 你的 research 判斷力 × agent 的 search 執行力。 agent 那一項已經接近免費了，所以乘出來的價值，幾乎完全由你的 research 決定。前者是 0，乘出來就是 0。

怎麼在 Claude Code 實作 autoresearch

上面講的是原則。這節給你一個可以照抄的骨架——好消息是：autoresearch 迴圈需要的每一塊，Claude Code 幾乎都內建了，你的工作只是把它們組起來，並把「哪些是 search、哪些是 research」這條線焊死在程式碼裡。

先看對照——迴圈的每一步，對到哪個機制，以及它屬於誰：

autoresearch 需要Claude Code 的對應這塊屬於
跑一輪「提一個改動」headless 模式 claude -psearch
只准改某個檔（鎖搜尋空間）permissions + PreToolUse hookresearch（你）
改完自動跑 evalPostToolUse hookresearch（你）
好留壞丟、記住歷史git commit / reset（由腳本掌握）search
每個實驗互不干擾git worktree 隔離search
防作弊的獨立稽核第二個 subagent 當 judgeresearch（你）
不斷重複包成迴圈腳本 / Agent SDKsearch

注意 research 那幾格——它們全是「護欄」，全由你定義；agent 只跑 search 那幾格。下面逐塊看。

1. 最小可跑的迴圈：一個驅動腳本

核心觀念：keep/discard 的權力，握在你的腳本 + 你的 eval 手上，絕不交給 agent 自己判。 這是 Langfuse 翻車的解藥——不讓 agent 幫自己的作業打分數。

#!/usr/bin/env bash
# autoresearch.sh — 你定義目標與 eval，agent 只負責「提一個改動」
BEST=$(./run_eval.sh)              # 先量基準分數（run_eval.sh 是你寫的 eval）

while true; do
  # ── search：讓 agent 讀歷史，只提「一個」小改動 ──
  claude -p '讀 git log 看過去試過什麼。對 train.py 提出一個、且只有一個小改動，
             目標是降低 val_bpb。不要改其他檔案，不要動 eval。' \
         --allowedTools "Read Edit Bash" \
         --permission-mode acceptEdits

  # ── research：分數由你的 eval 說了算 ──
  SCORE=$(./run_eval.sh)

  # ── 好留壞丟：退步就 reset，進步才 commit（git log 就是 agent 的記憶）──
  if (( $(echo "$SCORE < $BEST" | bc -l) )); then
    git commit -am "autoresearch: val_bpb $BEST -> $SCORE"
    BEST=$SCORE
  else
    git reset --hard
  fi
done

（要解析 agent 的結構化輸出時，可加 --output-format json 再用 jq -r '.result' 取值；上面因為分數是 eval 算的，不需要。）

2. 把搜尋空間鎖死（hook + permissions）

--allowedTools 只能限制「能用哪些工具」。要真正做到「只准改 train.py」，用一個 PreToolUse hook 把其他路徑的編輯擋掉——即使 agent 想繞去改 eval 來作弊，也會被機制擋下：

// .claude/settings.json
{
  "hooks": {
    "PreToolUse": [{
      "matcher": "Edit|Write",
      "hooks": [{ "type": "command", "command": "bash .claude/hooks/lock-space.sh" }]
    }]
  }
}
# .claude/hooks/lock-space.sh — 只准動 train.py，其餘一律擋
file=$(jq -r '.tool_input.file_path // empty')
if [[ "$file" != *"train.py" ]]; then
  echo "搜尋空間鎖定：只能改 train.py，禁止改 $file" >&2
  exit 2   # exit 2 = 擋下這次工具呼叫，stderr 會回饋給 agent
fi

這就是把「只准改一個檔」這條 research 判斷，從「我希望 agent 乖乖聽話」升級成「機制上它做不到」。你也可以在 settings.json 的 permissions.deny 直接擋掉敏感路徑，兩者搭配。

3. 防作弊：獨立的 verifier subagent

還記得搜尋重排器那個例子嗎？它用「第二個 LLM」去檢查 agent 有沒有把查詢寫死。在 Claude Code 裡，這個角色就是一個 獨立 subagent——它只看 diff，而且被預設成「懷疑論者」：

# .claude/agents/eval-judge.md
---
name: eval-judge
description: 獨立稽核 autoresearch 的改動有沒有在鑽 eval 漏洞
tools: [Read, Bash]
---
你是獨立稽核者，只看這次的 git diff。判斷它是「真的改善了方法」，
還是「在鑽 eval 漏洞」（寫死答案、刪掉檢查、針對測試集 overfit…）。
回報 PASS 或 REJECT 並說明理由。預設懷疑，拿不準就 REJECT。

在迴圈裡 commit 之前先叫它審一次，只有 PASS 才留下。重點是：這個 judge 的判準是你寫的——它替你把「這算不算真的進步」這個 research 判斷，自動施加在每一輪上。agent 還是不能幫自己的作業打分。

4. 隔離與不斷重複

  • 隔離：每個實驗開在自己的 git worktree（claude --worktree exp-1），跑爛了也不污染主線，還能平行多跑幾條。
  • 重複：互動式探索時用內建的 /loop；要無人值守整夜跑，就是上面那個 while 腳本，或改用 Claude Agent SDK（Python / TypeScript）寫一個有錯誤處理、能平行的正式迴圈。要定時排程，可參考 排程觸發。

焊死那條線

把整個骨架攤開你會發現：agent 只出現在「提一個改動」那一行——那是 search。 其餘每一塊——目標函數、eval、鎖死的搜尋空間、judge 的判準、什麼時候收手——都是你寫死在腳本與 hook 裡的 research。

所以 Claude Code 給你的，不是「一個會自己做研究的 AI」，而是一套積木：把 search 自動化，同時把你的 research 判斷固化成護欄。 護欄寫得好不好，就是你的 research 功力——這一塊，agent 不會幫你補。

練「研究員思維」

研究所的本質，只是一個「強迫你練 research 判斷力」的高壓環境——它逼你獨立發起調查、設計合理的實驗、定義什麼叫「做對了」，再丟去給一群專挑毛病的人考核。但這套能力，你在職場、在自己的 side project 裡一樣練得起來。方法就是：每次遇到問題，先別急著 search 解法；先問「真正的問題是什麼？該怎麼定義？我要怎麼驗證自己解對了？」

這也呼應一件事——AI 放大的是你「已經有」的判斷力，而不是補上你「缺的」判斷力。 如果你連一個誠實的 eval 長什麼樣子都沒設計過，autoresearch 給你一個被鑽爛的指標，你也看不出來，只會更快、更有自信地撞牆。所以「定義問題、設計 eval」這種功夫，最好趁早練，而且練到沒有 AI 也會。

順帶說個我自己的經驗：很多資深工程師（包括一年前的我）以為自己很強，直到真的要為一個問題設計一個騙不過去的 eval，才發現——原來我連「把問題定義清楚」都不太會。這不丟臉，這是起點。能看見自己的盲區，本身就是 research 能力的第一步。

寫在最後

把上面這些濃縮成一句：

AI 把 search 和執行壓到了地板，autoresearch 又把 search 的迴圈自動化了。剩下唯一無法外包的，就是 research——你問什麼、你怎麼定義「更好」、你怎麼驗證。

這就是工程師在 AI 時代真正的護城河。它不在於你會用多少工具，而在於：當人人都能 search、人人的 agent 都能跑迴圈時，你是不是那個能定義對的目標、設計出騙不過去的 eval 的人。

📎 延伸閱讀