如果你正在用 Claude Code 讀陌生程式庫、修舊系統錯誤，或想讓產品、資料、營運同事用自然語言交付技術任務，現在最該問的問題已經變得更具體：誰來定義任務，誰來驗收結果，團隊要把哪些專業知識寫進工作流？
Anthropic 在 2026-06-16 發布 Agentic coding and persistent returns to expertise，分析約 40 萬個 Claude Code 工作階段（session）與約 23.5 萬名使用者。這份官方研究和 ５月 arXiv 論文 Coding Beyond Your Training 放在一起看，訊號很一致：AI 寫程式代理（AI coding agent）正在降低技術切換成本，但最會放大成果的仍是使用者對問題、系統與風險的理解。
這篇文章更新原本的 Claude Code 研究整理，重點放在一個實務判斷：Claude Code 可以幫你跨進陌生技術，但你要用清楚任務、測試、權限與程式審查把結果拉回可控範圍。
兩份研究各自看見什麼？
| 來源 | 看的是什麼 | 可採信的重點 | 使用限制 |
|---|---|---|---|
| Anthropic 2026-06 官方研究 | 約 40 萬個 Claude Code 工作階段，時間範圍是 2025-10 到 2026-04 | 人多半決定「做什麼」，Claude 多半決定「怎麼做」；領域專業越高，每次指令能推動的工作越多 | 來源是 Anthropic 自家產品資料，要把它視為早期使用訊號，不等同所有開發工具或所有公司 |
| arXiv 2026-05 論文 | 5,838 名 GitHub 開發者，追蹤 Claude Code 採用前後的月度行為 | 採用後月提交、參與程式庫、使用語言與新語言嘗試都上升 | 作者明確提醒識別限制，不能把結果講成嚴格因果 |
Anthropic 的研究更接近「使用者真的怎麼和 AI 代理分工」。arXiv 論文更接近「採用後 GitHub 行為有沒有變」。兩者合起來，能補上常見討論的盲點：Claude Code 的重點逐漸從單次補完幾行程式，移向更快理解陌生系統，並把專業判斷轉成可執行任務。
Anthropic 的新訊號：人定義問題，Claude 執行路徑
Anthropic 對互動式代理式編碼（agentic coding）的描述很值得企業採購和團隊導入參考。研究指出，在典型工作階段中，人負責大多數規劃決策，也就是決定「要做什麼」；Claude 負責大多數執行決策，也就是決定「怎麼完成」。
這個分工對新手和資深工程師都重要。Claude Code 不會自動知道你的業務規則、相容性限制、合規邊界或資料風險。如果你只丟一句「幫我修好」，它會用模型推測可行路徑；如果你明確給出驗收條件、風險檔案、測試指令與不要碰的區域，它能把執行力放在更安全的軌道上。
Anthropic 還提到，使用者越有領域專業，Claude 每次指令能完成的工作越多；在程式任務（coding tasks）中，不同主要職業的成功率平均接近軟體工程師。這個訊號不能解讀成跳過基本驗證，反而說明真正有價值的輸入是問題知識。懂流程的人、懂客戶需求的人、懂資料的人，只要會把限制講清楚，也能更有效指揮 AI 代理。
arXiv 研究：技術邊界被往外推
５月的 arXiv 論文 Coding Beyond Your Training 觀察 5,838 名 GitHub 開發者，將第一次出現 Claude 共同作者提交（co-authored commit）視為採用時間點，並用尚未採用者作對照。研究估計採用後出現以下變化：
| 指標 | 論文摘要中的估計效果 | 實務解讀 |
|---|---|---|
| 月提交數 | +41 | 活動量上升，仍要搭配品質與維護成本解讀 |
| 參與程式庫數 | +1.5 | 開發者更常跨到其他專案 |
| 使用的程式語言種類（distinct programming languages） | +0.83 | 使用語言範圍變廣 |
| 新使用語言數（newly-used languages） | +0.31 | 嘗試新語言的門檻下降 |
| 累積使用語言數（cumulative lifetime languages） | +0.51 | 技術邊界有持續外擴跡象 |
這些數字最值得追的地方，是「切換成本」下降。你從 Python 程式庫切到 Go、Rust、Terraform 或陌生前端框架，痛點通常落在讀懂目錄、找入口、理解慣用寫法（idiom）、跑測試、判斷錯誤訊息與評估風險。Claude Code 這類工具如果能把這些步驟變成可問、可跑、可驗證的流程，開發者就更敢接觸陌生任務。
這也呼應 AI coding agent 研究總覽 的方向：真實採用已經開始留下 GitHub 痕跡，但每個數字都要搭配任務類型、程式審查品質與風險控管來解讀。
開發者怎麼把研究變成練習？
把 Claude Code 當成「跨技術邊界訓練器」會比單純要求它多寫幾行 code 更有效。你可以用三種練習重新設計自己的工作流。
１. 先讓它做陌生程式庫導覽
不要一開場就改檔。先要求它建立地圖：
請先讀這個程式庫，整理主要模組、資料流、測試方式、部署入口、最值得先看的 5 個檔案。先不要改任何檔案。這個練習對應 Anthropic 研究中的「人負責規劃」。你先用問題定義方向，再讓 Claude 收集證據。
２. 讓它列假設與驗證方式
遇到錯誤時，先要求它列出可能原因，暫時不要直接修：
這個測試失敗。請列出 3 個可能原因、每個原因要檢查哪些檔案、最小驗證指令是什麼。先不要改檔。這會迫使你看懂推理路徑，也避免自己變成只按 accept 的操作者。
３. 把驗收條件寫進每次任務
改動前先給它明確邊界：
請找最小可行修正。不要重構 public API，不要碰 migration。改完後跑 npm test，並列出仍需人工 review 的風險。如果你已經在用 Claude Code，下一步可以把常用限制寫進 CLAUDE.md。Anthropic 文件也把 CLAUDE.md 定位為專案根目錄中的持久指令，用來保存程式碼標準（coding standards）、架構決策、偏好的函式庫與審查清單。更完整的工具教學可接著讀 Claude Code 工作流與保命設定。
企業導入：速度之外，還要驗收專業知識
企業採購 AI coding agent 時，常見錯誤是只比 demo 速度或模型分數。這兩份研究給的管理訊號更務實：如果成功率與使用者的領域理解相關，那企業要驗收的是「專業知識如何被轉成可重複流程」。
建議用這張表評估：
| 導入問題 | 可驗收證據 | 失敗訊號 |
|---|---|---|
| 任務定義是否清楚？ | 議題（issue）或提示詞（prompt）內有驗收條件、限制、測試指令 | AI 代理只能靠猜，拉取請求（PR）需要大量返工 |
| 專案知識是否可讀？ | CLAUDE.md、README、架構決策紀錄（ADR）、操作手冊（runbook）能說清楚架構與禁止事項 | 知識只在資深工程師腦中 |
| 權限是否分層？ | 唯讀（read-only）、受控寫入、拉取請求審查（PR review）、敏感檔案阻擋 | 一開始就能改正式環境設定或 secrets（密鑰） |
| 驗證是否可重跑？ | 持續整合（CI）、程式碼檢查（lint）、單元測試、人工審查清單都能對應任務 | 只看 AI 代理自己說「已完成」 |
| 風險是否回到人身上？ | 高風險檔案、資料庫結構（schema）、身分驗證、帳務、資安改動需要指定審查者 | AI 產出的變更沒有責任歸屬 |
如果你要做正式概念驗證（PoC），可以把這張表和 企業 AI Coding Agent 評估指南 搭配使用。導入順序應該從唯讀（read-only）導覽、小型修補、受控拉取請求（PR），再走到流程自動化；權限一次開滿，通常會把程式審查與資安風險提前放大。若要看越界風險案例，可延伸讀 Overeager coding agents 研究整理。
關鍵判斷：專業知識變成新的槓桿
Claude Code 的新研究沒有讓工程判斷變得不重要。它讓工程判斷更早出現在流程裡：任務怎麼切、限制怎麼寫、測試怎麼跑、哪些變更要退回、人要在哪裡介入。
對個人開發者，這代表你可以把 AI 代理當成學習與跨域工具，用它加速讀陌生系統、理解錯誤、建立修改假設。對企業，這代表 AI 寫程式代理的導入價值除了產量，也包括縮短新人導入（onboarding）、降低舊系統（legacy）知識集中、讓更多人安全接觸原本不敢碰的任務。
最可引用的一句話是：Claude Code 正在把「會不會親手寫每一行」的重要性往後移，把「能不能定義正確任務並驗收結果」的重要性往前推。
FAQ
Anthropic 這份研究能證明 Claude Code 一定提升生產力嗎？
不能這樣讀。它是 Anthropic 對自家 Claude Code 使用資料的隱私保護分析，可以提供很有價值的早期訊號，但不等於所有公司、所有任務、所有工具都會得到同樣結果。比較穩健的說法是：在這批觀察資料中，Claude Code 使用呈現人機分工、任務複雜度上升與領域專業放大效果。
不會寫程式的人可以用 Claude Code 完成技術任務嗎？
可以從唯讀（read-only）導覽、文件整理、資料分析、測試失敗解釋開始。若要改真實程式碼，仍需要工程師或能負責該系統的人驗收。Anthropic 的訊號是領域專業很重要；不知道業務限制、資料風險與驗收條件的人，交給 AI 代理的任務也更容易失控。
企業導入 Claude Code 最先該管什麼？
先管權限和驗收。第一階段建議只做程式庫導覽、文件整理與低風險錯誤分析；第二階段才允許小型修補；第三階段要求拉取請求（PR）、測試、程式審查與稽核紀錄（audit log）。資安、身分驗證、帳務、資料庫結構（schema）、正式環境設定應該維持更高人工審查。