[RSCH] 12 分鐘閱讀OraCore 編輯部

Anthropic 讓 coding agent 變研究 ops

我拆 Anthropic 的社科調查,整理出 coding agent 真正適合插進研究流程的位置,最後附可直接複製的工作流模板。

分享 LinkedIn
Anthropic 讓 coding agent 變研究 ops

我拆 Anthropic 的社科調查,整理出 coding agent 真正適合插進研究流程的位置,最後附可直接複製的工作流模板。

我用 AI 跑研究流程有一陣子了。老實說,前面都還行,寫點摘要、改段落、補幾行 code,看起來很勤快。但一碰到真的分析,我就開始煩:它會很自信地亂接路徑、亂猜欄位、把不存在的變數寫進去,然後裝沒事。你叫它修,它就一直點頭。這種工具很像會做筆記的實習生,不像能上線幹活的人。

直到我看到 Anthropic 這篇 Coding agents in the social sciences,我才比較清楚問題在哪。它不是在吹模型多會寫字,而是在問:coding agent 到底卡進研究流程的哪一段?這篇不是新聞稿,是一份對 1,260 位 quantitative social scientists 的調查,數字很直接,也很刺眼。

最有意思的是,大家都說自己有用 genAI,但真正把 coding agents 放進工作核心的人還不多。這個落差很重要,因為它說的不是「有沒有接觸 AI」,而是「你有沒有把它當成能執行工作的工具」。前者很容易,後者才會真的改變你的研究節奏。

1) 不是 AI 用戶與否,而是你有沒有把它拉進執行層

訂閱 AI 趨勢週報

每週精選模型發布、工具應用與深度分析,直送信箱。不定期,不騷擾。

不會寄垃圾信,隨時可取消。

“81% of respondents said yes. But ... only 20% of respondents use coding agents.”

翻譯一下就是:大多數人都碰過 AI,但只有少數人真的把 coding agent 當成工作流的一部分。這個差距不是小事,因為 chatbot 跟 coding agent 根本不是同一類工具。前者比較像幫你改字,後者比較像能進 repo、看檔案、跑程式、撞錯誤、再修一次。

Anthropic 讓 coding agent 變研究 ops

Anthropic 這份調查是 2026 年 2 月到 3 月做的,樣本是 1,260 位 quantitative social scientists。這個規模夠我拿來看趨勢,但我不會把它當成全世界研究圈的聖旨。它真正有價值的地方,是把「AI 使用」切成兩層:一般 genAI 使用,跟真正的 coding agent adoption。

我自己的感受也差不多。很多團隊嘴上說有在用 AI,實際上只是偶爾叫它幫忙寫一小段 code,或改一個摘要。那不叫流程改造,那叫試水溫。只要工具沒碰到執行層,它就還沒真的介入研究生產線。

實操上,我會把研究工作拆成三段:

  • idea support:找方向、整理文獻、列出假設
  • draft support:修文字、改格式、補說明
  • execution support:寫分析 code、跑結果、修錯誤

如果你的工具只停在前兩段,就不要誇張地說它在「重塑研究」。它只是幫你省一點瑣事而已。

2) 真正有用的地方,是它能碰到分析 code

“The most common use, for both coding agent users and others, is for coding up analysis of quantitative data: 97% of coding agent users and 77% of other AI users report using it to generate code.”

這句我很買單,因為它把焦點放回最無聊、但最值錢的地方:分析 code。大家愛講 AI 寫論文、寫 introduction、寫總結,可是 Anthropic 的資料顯示,最常見的用途其實是把量化資料的分析程式寫出來。老實說,這才合理。真正卡人的通常不是靈感,而是那堆重複、髒、容易出錯的分析工作。

白話一點說,coding agent 的價值不是「幫你寫得像人」,而是「幫你把研究流程往前推」。我如果叫模型寫一個 regression script,我要的不是第一版很漂亮,我要的是它能在實際環境裡跑,跑壞了知道原因,然後自己再修。這才像工作,不像作文。

我之前做過一個 survey analysis pipeline,資料格式很亂,欄位名稱又不穩。一般 chatbot 很快就開始亂掰,給我不存在的變數,還假裝那些 cleaning step 本來就有。這種時候,能看檔案、能讀錯誤訊息、能根據 runtime feedback 回頭修的 agent,才真的有用。

Anthropic 提到的 Claude CodeCodexCursor,我會把它們都看成同一類東西:不是寫作玩具,是工作流工具。你如果只把它當 autocomplete,用法就太小了。

實操上,我會先讓 agent 做這種任務:

  • 讀資料並檢查欄位
  • 產生一版分析腳本
  • 真的跑一次,收集錯誤
  • 根據錯誤修正,再輸出變更摘要

這一套很土,但土的方法通常比較可靠。因為它要求工具面對真實環境,而不是只在聊天框裡耍嘴皮子。

3) adoption 不平均,這件事很值得警惕

“Those with typically male names have adopted coding agents at more than twice the rate of respondents with typically female names.”

這段我看了有點不舒服,但它很重要。Anthropic 說,通常是男性名字的受訪者,採用 coding agents 的比例是通常是女性名字者的兩倍以上。再往下看,頂尖大學的研究者更常用,經濟學和政治學的採用率也高於 public health、education、communications。早期職涯研究者比 tenure 教授更常用。

Anthropic 讓 coding agent 變研究 ops

翻譯一下就是:這不是單純的「誰比較愛嘗鮮」,而是資源、訓練、壓力、文化一起在推。你本來就離 code 比較近,你就更容易上手;你本來就得快點出成果,你就更想找加速工具;你在大學層級越高,越可能有同儕、經費、和試錯空間。

我不想把這種差異講成中性的。工具分布從來都不平均,但當工具開始影響研究勞動的速度,差異就會被放大。誰更快搭起專案、誰更快清資料、誰更快出圖,這些差距最後都會反映在成果上。

Anthropic 也很小心,這些只是描述性結果,不是因果結論。這點我認同。會用 coding agent 的人,可能本來就比較會發 paper、比較敢試新工具、或比較常碰 code。工具可能只是把原本的差距放大,不一定是自己創造了差距。

實操上,如果你是 lab lead 或 team lead,我會很直接地做三件事:

  • 找一個很會用的人,配一個懷疑派,做同一個 task
  • 把 workflow 寫清楚,不要只講工具名稱
  • 追蹤的是 setup time 有沒有下降,不是大家有沒有覺得很酷

如果你不刻意設計,最後只會是本來就快的人更快而已。

4) 它比較像在推進前段流程,不是幫你收尾

“Coding agent users are starting more projects, posting more working papers, submitting more grants, and possibly sending out more conference submissions.”

這段是我覺得最實用的地方。Anthropic 說,coding agent 使用者在前段流程看起來更活躍:開更多專案、貼更多 working paper、送更多 grant。可是到了 journal submission 那一層,差異就沒那麼明顯。也就是說,它比較像幫你把事情啟動,不一定幫你把事情收乾淨。

這很符合我自己的經驗。研究最煩的地方,常常不是第一版分析,而是那些零碎到不行、但沒做就會卡住的事情:專案結構、資料清理、重跑、補圖、改欄位、處理版本差異。coding agent 很適合吃這些雜事,因為它就是在幫你削掉摩擦。

但最後送出去那一步不一樣。你還是要判斷論點夠不夠硬、檢查是不是過度解讀、確認 robustness checks 有沒有被偷懶。這些不是 agent 最擅長的部分。它可以幫你把中間段落弄順,但不該替你決定研究要怎麼被世界理解。

Anthropic 也提醒,這些結果是受訪者回報過去六個月的狀況,不是實驗證明工具造成了改變。這種保留我覺得很必要。可就算只是描述性訊號,也夠我判斷:如果我要投資一套 agent 工作流,我應該先放在最磨人的中段,而不是幻想它會替我把整篇 paper 收尾。

實操寫法很簡單:

  • 讓 agent 做專案 scaffold
  • 讓它產分析腳本和 table
  • 讓它做 robustness 變體
  • 讓它重畫圖、重跑結果、整理 appendix code

但 final claims、論證框架、submission decision,這些我還是會自己握著。因為那才是研究者該負責的地方。

5) 風險不是亂寫答案,而是把研究管線變成新瓶頸

“These tools could accelerate science and make it more daring... They could also amplify disparities in research resources and exacerbate congestion in the scholarly record.”

這句我覺得比前面所有生產力敘事都重要。Anthropic 很直白:工具可能讓科學更快,也可能讓資源差距更大,還可能讓學術紀錄更塞。這不是危言聳聽,這是很現實的副作用。

白話講,如果 coding agent 降低一篇 paper 的生產成本,那它也同時降低 mediocre paper 的生產成本。研究系統本來就已經很擠了,現在只是讓更多東西更快進來。快,不等於好;便宜,也不等於值得。

還有一個更麻煩的地方:當 AI 開始幫你做更多分析選擇,這些選擇就會慢慢變成默認值。哪個 cleaning step 被省略、哪個 robustness check 被當標準、哪種 model default 被一直重複使用,這些都不是小細節。久了之後,它們會變成學科的預設機器。

我看過團隊一旦習慣某個工具,就直接照著模型第一個建議走,根本不再問為什麼。那很方便,也很危險。因為方便一久,默認就會變成教條。

實操上,我會要求 agent 的輸出不只是結果,而是過程紀錄:

  • 每個步驟的 log 要保留
  • 每個分析選擇都要有人類解釋
  • 正式採用前,至少要有一次不靠 agent 的獨立重跑

如果它連這關都過不了,那它就不該直接進你的 paper。

6) 這份調查真正有價值的地方,是它把下一場爭論講清楚了

“We will publish results from this experiment in the future.”

Anthropic 說這只是 baseline wave,後面還有一個 randomized experiment,會讓研究者拿到 Claude Code。這很關鍵。因為調查只能告訴我們誰已經在用、怎麼想、用在哪裡;實驗才有機會回答:它到底有沒有真的提升生產力。

翻譯一下就是,我們現在還在早期。眼下大家多半是靠 anecdote、靠自我選擇、靠局部觀察在吵。更好的問題不是「coding agent 能不能幫忙」,這答案其實已經很明顯了。更好的問題是:它在哪裡最有用、誰拿得到、又會怎麼改變研究分工。

我喜歡這種寫法,因為它沒有走兩個最懶的極端:不是「AI 會接管社科」,也不是「這沒什麼」。它只是把流程拆開來看,然後承認工具正在重組研究工作,但影響分布得很不平均。

如果你自己也想做 workflow,我會建議你不要先問「agent 要不要做全部」。先問的是:哪一段最耗時間、最容易出錯、但又不需要太多判斷?那一段才是你該先丟給它的地方。

可抄的模板

# coding-agent 研究工作流模板(量化研究版)

## 1) 先定義任務
- 研究問題:
- 資料來源:
- 期待輸出:
- 不可碰的限制:

## 2) 把 agent 放進執行層
你可以直接貼這段:

"你現在在一個研究 repo 裡工作。你的任務是:
1. 先檢查資料檔與專案結構,
2. 寫出分析程式,
3. 實際執行程式,
4. 根據 runtime error 修正,
5. 把每個改動講清楚。

不要自己發明欄位、檔名或結果。
如果資訊不夠,先問,不要硬猜。
最後只回傳:最終 code、執行過的命令、分析選擇的簡短說明。"

## 3) 強制留下工作痕跡
接受輸出前,要求它列出:
- 用到的檔案路徑
- 執行過的 command
- 遇到的 error
- 怎麼修的
- 假設了什麼
- 最後產生了哪些 table / figure

## 4) 人類要保留的部分
這些不要交給 agent:
- 最終結論
- 因果解讀
- paper framing
- 是否送出
- 倫理與風險判斷

## 5) 最適合交給它的工作
- 專案 scaffold
- data cleaning
- regression / table generation
- robustness checks
- figure 重跑
- appendix code 整理

## 6) 不適合交給它的工作
- 編造方法
- 沒 review 就寫結論
- 偷改研究問題
- 隱藏失敗的 run
- 用 default 取代判斷

這就是我會真的拿去用的版本。它不是要你迷信 agent,而是把它卡在最省力、也最不容易出大包的地方。速度可以拿,判斷不要丟。

原始來源是 Anthropic 的 Coding agents in the social sciences。我上面拆的是這篇調查的觀點,模板則是我根據它描述的工作模式,加上我自己在研究流程裡踩過的坑整理出來的。