【2026 最新】Claude Code 研究工作流：Ownership Budget 與 8 步可重現驗收

Claude Code 研究工作流真正的風險，不是 AI 寫得太快，而是研究者在速度變快之後，說不清哪個假設是自己定的、哪段分析改過、哪張圖如何重跑，以及一則引用到底支持什麼。論文能編譯、程式能執行，都不等於你仍掌握研究。

這篇教你建立一套可以直接放進 repository（用版本控制保存程式、設定與變更歷史的專案資料夾）的做法：先分配 Ownership Budget，再用三欄研究日誌、逐項 provenance receipt（來源與執行收據）、乾淨環境復現、盲抽查與口頭驗收守住主導權。即使你第一次把 AI 放進研究流程，也能照著每個 gate 的通過條件逐步建立；重點不是少用 Claude Code，而是讓每一次加速都留下可解釋、可追溯、可重跑的證據。

範圍先說清楚：本文適用於用程式處理資料、產生數值或圖表的計算型研究。濕實驗、質性研究、臨床資料與其他受限制資料，需要依各領域規範改寫；這套 repository 結構不能取代研究設計、倫理審查或領域判斷。

先懂 8 個詞：repository 是有版本紀錄的專案資料夾；commit 是一次專案狀態快照；hash（雜湊）是辨認檔案有沒有改變的數位指紋；artifact 是資料或程式產生的成果檔；receipt 是把輸入、命令與輸出串起來的證據卡；manifest 是預先列出的結果與容許誤差清單；exit status 是命令成功或失敗的代碼；CI checkout 是另一台機器取出乾淨專案副本後重跑。

先說結論：研究主導權要同時通過 3 關

本文用一個保守的自評口訣；它不是作者資格標準，也不是經驗證量表：

研究主導權 ≈ 能解釋決策 × 能追溯證據 × 能獨立驗證

「獨立驗證」包含從凍結輸入重跑，也包含反例測試與領域判斷；可重跑的錯誤仍然是錯誤。任何一項不足，都會削弱成果的可稽核性，但不能只靠這個口訣判定作者資格。

這個風險已有值得重視、但不能過度延伸的訊號。2026 年一篇 IEEE Transactions on Software Engineering 研究，在六場採交叉設計的實驗中分析 69 名有效參與者，其中 47 名是大學或碩士生、8 名研究人員、14 名專業開發者。在主要模型中，AI 條件的任務完成度估計高 42.99 個百分點，回答剛完成程式之技術問題的正確機率平均低 5.95 個百分點。每人完成兩個最多 75 分鐘的 Python 或 Java 任務；AI 條件一律提供 GitHub Copilot，也允許另用其他 AI 工具，但研究沒有保存個別工具的詳細使用紀錄。因此，效果不能歸因於 Claude Code，也不能直接外推到今日的 agentic coding workflow；只看研究人員與專業開發者時，ownership 效果方向一致，但信賴區間包含無效果。研究也沒有測長期理解，更沒有驗證本文流程能消除差距；它只提醒我們，產出更多與理解更深可以分開發生。

以下 Ownership Budget、H/A/D 分區、H/A/E 日誌、每週節奏與口頭驗收，是本文把既有可重現性原則整理成的編輯性工作流；目前沒有研究證明這整套 protocol 能提高論文品質。它提供的是可稽核的防錯設計，不是已驗證的 ownership 量表。

Ownership Budget 是什麼？先分配決策權，再下 prompt

Ownership Budget 是本文提出的操作框架，不是 Anthropic 功能，也不是經驗證的學術量表。它不計算「AI 寫了幾成」，而是在每個研究里程碑開始前，把任務分進三個區域：

• H｜Human-owned：研究問題、可否證假設、主要指標、納入與排除條件、資料切分、證據門檻、結果詮釋與引用接受，必須由人類提出或明確簽核。
• A｜AI-proposed：替代分析、測試案例、程式骨架、除錯路徑與文字草稿可由 Claude Code 提案；研究者要記錄接受、修改或拒絕的理由。
• D｜Delegable：不改變科學結論的格式整理、重複樣板、檔名轉換與圖表輸出，可在驗收條件明確後交給 AI 執行。

判斷方法很簡單：如果某個選擇改變「研究在問什麼、什麼算成功、讀者應相信多少」，就回到 H 區；如果只是提出做法，放 A 區；只有不改變結論的機械工作，才放 D 區。先分類、後提示，能降低 AI 已經做完才回頭替結果補理由的風險。

兩套字母回答不同問題：H/A/D 分配「誰能決定」；稍後的 H/A/E 記錄「承諾—提案—證據」。D 不是免驗收通道，委派工作執行後同樣必須留下 E。

Claude Code 研究工作流第一步：把原始資料與產物分層

先建立清楚的 repository 邊界。最小結構可以是：

research-project/
├── CLAUDE.md
├── .claude/settings.json
├── hypotheses/          # 人類持有的假設卡與停止條件
├── research-log.md      # H／A／E 三欄日誌
├── data/raw/            # 不可覆寫的原始輸入
├── data/processed/      # 可由程式重建
├── configs/             # 凍結的實驗設定
├── src/                 # 分析程式
├── tests/               # 資料洩漏、輸出與統計檢查
├── provenance/          # 每項結果的 receipt
├── outputs/             # 由命令產生的數字與圖
└── paper/               # 論文原稿

原則是 data/raw 只讀，data/processed 與 outputs 必須能刪掉後重建；不要讓手動改過的試算表成為唯一真相。美國國家科學、工程與醫學院（NASEM）對計算可重現性的定義是：使用相同的輸入資料、計算步驟、方法、程式碼與分析條件，取得一致結果。

若資料含受試者個資、未公開商業資訊或授權限制，先依研究倫理審查、機構政策與資料使用契約決定 AI 是否能存取；repository 設定不能把未獲授權的處理變成合規。識別資訊與憑證不要進 prompt、日誌或 receipt，必要時先去識別化，並把敏感原始資料留在核准的隔離環境。

若要阻止 Claude Code 的內建檔案工具直接修改原始資料，可在版本控制內的 .claude/settings.json 加入以下設定。這裡以從 repository 根目錄啟動 Claude Code 為前提；在專案設定中，單一前導斜線會錨定到該 session 的 primary working directory：

{
  "autoMemoryEnabled": false,
  "permissions": {
    "deny": [
      "Edit(/data/raw/**)"
    ]
  }
}

依 Claude Code 權限文件，檔案權限只會查用 Edit(path) 與 Read(path)；帶路徑的 Write(path) 規則雖會被接受，卻不會被查用。Edit deny 會涵蓋內建編輯工具，也會檢查 Claude Code 能辨識的 Bash 檔案命令與重新導向目標；它仍攔不住任意 Python／Node 子程序間接寫檔。需要作業系統層級強制時，應設定 sandbox、唯讀掛載或外部檔案權限，並以雜湊驗證。啟動後可用 /permissions 確認規則已載入。這和Claude Code 大型專案安全重構強調的邊界思維相同，只是這次保護的是研究語意與原始證據。

這條 Edit deny 只保護資料不被特定工具改寫，不等於不被讀取或送出。敏感資料若未獲准交給模型，就不要暴露在 Claude 可讀的工作區；依需求再用 Read(...) deny、sandbox，或把 raw data 留在代理無法存取的隔離環境。最後邊界必須是作業系統權限與機構核准的資料環境。

autoMemoryEnabled:false 只停止 Claude Code 讀寫 auto memory，不會讓所有研究上下文自動進入版本控制；session prompt、模型、user／managed settings、MCP、hooks 與外部服務仍可能位於 repository 之外。若還要關閉 plan mode 內的 auto mode，不能把 useAutoModeDuringPlan:false 寫進共用 project settings，因為該 scope 的 false 值會被忽略；可改放個人的 .claude/settings.local.json，或用 claude --settings '{"useAutoModeDuringPlan":false}' --permission-mode plan 啟動。這會讓內建唯讀集合以外的命令要求確認，不代表完全禁止執行命令。再用 /status 查看載入來源、/permissions 查看規則，並以 claude doctor 檢查被拒絕的設定。

本教學在 2026 年 9 月 13 日依 Claude Code v2.1.270 的官方變更紀錄核對。每份分析 receipt 應保存日期、模型 ID、claude --version、permission mode、實際載入的設定來源、啟用的 integrations，以及 CLAUDE.md／settings 的 commit 或雜湊。

把研究契約寫進 CLAUDE.md，但別把它當安全鎖

官方文件把專案根目錄的 CLAUDE.md定位成每次工作階段載入的持續指示；它是上下文，不是強制執行的設定。適合放簡短、具體、可驗證的研究契約：

# Research contract

## Human-owned decisions
- Never rewrite hypotheses, primary metrics, exclusion rules, or
  accepted citations. Propose changes; wait for explicit approval.
- Treat data/raw as immutable. Write derived files elsewhere.

## Before any result-changing edit
State: hypothesis ID, files to change, expected evidence,
failure condition, and exact verification command.

## After the edit
Return: git diff --stat, commands actually run, exit status,
output paths, failed checks, and unresolved uncertainty.
- Do not mark your own proposal as accepted.
- Draft an A/E log entry; the researcher fills or signs H.

## Required checks
- Run the tests named in the hypothesis card.
- Rebuild affected figures from scripts, never by manual editing.
- Stop when inputs, definitions, or citations are ambiguous.

進入一個新假設時，先以 claude --permission-mode plan 探索，要求 Claude Code 只提出可能修改與驗收方式；確認計畫後才准許編輯。官方最佳實務同樣建議先探索、再規劃、再實作，並用測試、預期輸出或其他明確的通過／失敗訊號驗證成果。若你想先理解為何 Agent 需要這種外部約束，可補讀AI Agent Harness 是什麼。

三欄研究日誌：H 是承諾，A 是提案，E 才是結果

日誌不需要記下整段聊天。每個可改變結果的動作，用固定 ID 留下三欄：

• H｜Human-owned commitment：可以是可否證假設，也可以是會左右結論的主要指標、排除規則、資料切分或停止條件；要記錄誰在何時簽核。
• A｜AI-proposed action：Claude Code 提了什麼修改、會碰哪些檔案、預期如何改變證據；人類選擇接受、修改或拒絕，以及理由。
• E｜Evidence：commit、資料與設定雜湊、環境、精確命令、exit status、輸出路徑、結果摘要、失敗與尚未解決的疑點。

下面不是虛構指令，而是一個可以下載、重跑、故意破壞的微型範例。AlphaLab 在 2026 年 9 月 13 日建立這個只用 Python 標準函式庫的 pipeline；你可以下載完整 Git bundle。下載檔的 SHA-256 是 4de132e52390ebdb2a6eab7baa02018a30575ad2b76fb3885660c8fbacbdd461，用來確認你拿到的 bytes 和本文驗證的是同一份。Bundle 內有完整程式、Git 歷史與執行收據；本文只展示理解流程所需的關鍵部分。

範例用刻意構造的 CSV 計算 mean(B)-mean(A)，預期值是 2.0、容許誤差是 1e-12，並產生群組平均、結果 JSON 與 SVG 圖。它驗證的是「承諾、提案、程式與 receipt 能不能對上」，不驗證任何科學方法，也沒有測 Claude Code 的模型表現。

先確認環境：你需要 Git、可執行 Bash／POSIX shell 的終端機，以及恰好 CPython 3.9.6。runtime.lock.json 明確鎖定這個 interpreter，依賴只有 Python 標準函式庫；版本不同會在 preflight 失敗。這個玩具範例沒有鎖定作業系統、Git 或 shell 版本，因此 receipt 會記錄程式與 Python 狀態，但不能把兩次成功延伸成所有平台都逐 bit 相同。

git --version
python3 --version

下載後，把終端機切到 bundle 所在資料夾，再逐行執行：

# macOS；Linux 可把這行改成 sha256sum 檔名
shasum -a 256 claude-code-research-ownership-example.bundle

git clone claude-code-research-ownership-example.bundle toy-research-v2
cd toy-research-v2
bash scripts/reproduce.sh

第一行應得到上面的 bundle SHA-256；最後一行成功時會印出 PASS H-07 observed=2.0 expected=2.0 tolerance=1e-12。Git 歷史把四個角色拆開，避免再把「同一個 commit 裡同時出現假設、提案與完成程式」誤認成先後證據：

1. H 承諾：e29420b3f4be1e076fa25ea59c3f3447e8ae82b1 只凍結 H 卡、raw CSV、config、expected manifest 與 runtime lock。
2. A 接受：70a03fad3500c12d18c64ada24efda00c293b6a8 才加入 A-07.2 提案、人類接受決定與理由。
3. 最終程式：ab458ace82972e355bb2739ae7f3ffb9562469a0 是實際通過下列測試的 runner 狀態。
4. E 證據：7ae8420827e977a8722c805c42caf1dc2b91eb9c 新增兩張 PASS receipt、一張 tamper FAIL receipt，並更新 README 說明；沒有再改 runner。

每次執行依序走五關；把它想成機場安檢，前一關沒過，研究行李就不能送上輸出輸送帶：

1. 先撤掉舊綠燈：一開始就把 provenance/latest.json 原子更新成 RUNNING；即使後面失敗，上一輪 PASS 也不會繼續冒充最新狀態。
2. 核對封條：確認 H commit 與 A commit 都在目前歷史上，再把 raw input、config、manifest、runtime lock 與 H 卡的實際 SHA-256，逐一和 H commit 裡的 bytes 比對；非忽略檔案也必須維持乾淨。這一關完成前不建立研究輸出。
3. 核對規則：確認 config 與 manifest 的 H ID、指標、預期值、誤差和輸出清單一致，再檢查目前 interpreter 正是 CPython 3.9.6。
4. 計算後才發布：CSV 欄位、每個輸入、群組平均與最終結果都必須是有限數值；指標落在預定誤差內，才以原子寫入發布三個輸出並重新計算雜湊。
5. 留下真實收據：每輪建立不覆寫的 provenance/runs/<run-id>.json，保存真正的 stdout、stderr、exit status、commit、輸入與輸出雜湊；最後再把同一份 PASS 或 FAIL 原子更新到 latest.json。

以下只是關鍵節錄，不是完整程式；完整可執行版本在 bundle：

# 先讓舊 PASS 失效
atomic_write(LATEST_RECEIPT, json_bytes(running))

# frozen file 任一 byte 改變就停止
if actual_hash != expected_hash:
    raise GateError(f"frozen-file hash mismatch: {relative}")

# 每輪保留唯一 receipt，再更新最新狀態
atomic_write(run_path, final_bytes)
atomic_write(LATEST_RECEIPT, final_bytes)

保存在 provenance/evidence/pass-1.json 與 pass-2.json 的兩次乾淨執行，實際 stdout 都是 PASS H-07 observed=2.0 expected=2.0 tolerance=1e-12，exit status 都是 0。兩次的三個研究輸出雜湊完全相同：

• data/processed/group_means.json：f8a9c42464e6a6058ab216966c8805981acc2d64333b19cdc3a06f13aaa5f31a
• outputs/results.json：6145ae6eecefdd7b6c7f6fa5d6ed2f2b5784104c8f44ab09f2554bd21ff1cf15
• outputs/fig2.svg：1cbc6900f8dfb8ff51104e53fbf7c9a6d28f2da30167a16deb63e9284c1a2047

反例也真的跑過：在隔離 clone 裡把 raw CSV 的六個數字全部加 10，讓平均差仍然維持 2.0。只驗最終數字的程式會放行，但 v2 在 preflight 就回傳 FAIL preflight: frozen-file hash mismatch: data/raw/measurements.csv 與 exit status 1；乾淨的 tamper 測試沒有建立 processed 或 outputs，outputs_written 是 false，而 canonical latest.json 也變成 FAIL。這張收據保存在 provenance/evidence/tamper-fail.json；三張最終驗證 receipt 都隨 bundle 放在 provenance/evidence/。

這條 trace 能把「事前承諾、AI 提案、程式狀態與實際證據」分開，降低事後混淆；但本機 Git 歷史仍可被改寫，bundle SHA-256 只能辨認下載檔，不能單獨證明承諾發生的時間。若 confirmatory 研究需要外部可核對的事前時間線，應把 H 卡提交到不可回寫的時間戳註冊或受保護遠端，再開始分析。

每個資料、分析、圖表與引用都要有 provenance receipt

一張 receipt 的目標，是讓沒有看過 Claude 對話的人也能判斷結果從哪裡來。至少要覆蓋四種產物：

• 資料 receipt：原始來源、取得日期、版本或快照、授權、檔案雜湊、每次轉換與排除原因。
• 分析 receipt：commit、lockfile 或容器版本、設定檔、seed、精確命令、exit status、主要數值與容許誤差。
• 圖表 receipt：輸入資料、產圖 script、輸出尺寸與格式、圖中每個值的來源；禁止只留手動調整後的成品。
• 引用 receipt：DOI／官方 URL、作者與標題、支持的精確主張、頁碼或段落、適用範圍，以及它沒有證明什麼。

對引用尤其要採「AI 找線索，人類讀原文」：不要讓 Claude 生成一串看似合理的 bibliography 後直接匯入。對研究程式也一樣。PLOS Computational Biology 的AI 科學程式設計指南指出，AI 輸出具有隨機性，模型版本也會隨時間改變，因此 AI 輔助過程本身無法完全重現；記錄這段流程只能補充，不能取代最終程式碼的封存與版本控制。

投稿前還要查看目標期刊、研討會、學校與資助單位當下的 AI 規則。要求並不一致；例如 IEEE 的作者政策對 AI 生成的文章內容與程式要求揭露系統、受影響段落及使用程度。最穩妥的內部做法，是先保留工具、版本、日期、用途與受影響 artifact，再依實際投稿場域決定公開格式，不能假設一套揭露規則適用所有地方。

可重現驗收：重跑研究產物，不追求重播同一段 AI 對話

正確的驗收目標是：從凍結的 commit、輸入與環境出發，重新得到預先指定範圍內一致的數字、表與圖。不要把「同一句 prompt 再問一次」當復現，因為模型版本、服務端設定與抽樣都可能變動。

1. 乾淨起點：在新資料夾或 CI checkout 指定 commit，不使用研究者本機未提交檔案。
2. 核對輸入：先檢查 raw data、config 與 lockfile 的雜湊；不相符就停止。
3. 建立環境：依鎖定依賴或容器建置，不沿用未知狀態的虛擬環境。
4. 單一入口：執行 bash scripts/reproduce.sh，由它依序產生分析與圖表。
5. 比對 manifest：用機器可讀的 expected manifest 檢查主要數值、欄位、檔案與預先寫下的容許誤差。
6. 保存失敗：任何非零 exit status、警告與差異都進 receipt；不能只截一張綠燈畫面。

隨機 seed 只是條件之一，不保證跨硬體、函式庫與平行運算完全逐 bit 相同；數值容許誤差要在看到結果前定義。Claude Code 的 checkpoint也不能替代 Git：它主要追蹤 Claude 直接用檔案工具做的編輯，Bash 指令、外部程序與手動變更不一定包含在內。

盲抽查與每週 ownership oral test 怎麼做？

不要讓產生程式的同一個 AI 同時替自己宣布通過。每個里程碑完成後，由研究者或另一位 reviewer 在事後抽一筆「會改變結果」的 A 記錄；受測者只能拿到 repository、H ID 與 receipt，不能拿 Claude 的解釋，必須在乾淨環境重跑一個數值或一張圖，並指出哪個結果會推翻原假設。Anthropic 的最佳實務另建議用 fresh context 做第二輪 AI review，因為它不沿用剛才的推理；但這只是上下文隔離的 AI 複查，不是獨立驗證。高風險結果仍要靠可執行測試、不同工具或資料，以及人類或領域 reviewer。

每週再做一次不用 AI 的口頭驗收，回答五題：

1. 這週最重要的可否證假設是什麼？什麼觀察會讓你放棄它？
2. 主要指標、資料切分與排除條件為何這樣定義？替代方案會改變什麼？
3. 從一筆原始輸入走到論文某個數值或圖，完整路徑是什麼？
4. 哪一次測試或分析失敗？為何保留，下一步如何處理？
5. 挑一則核心引用：它支持哪一句話，又不能支持哪一句話？

這套盲抽查與 oral test 是本文從研究完整性原則與前述 IEEE ownership 問題延伸的編輯性 protocol，尚未被驗證為能提升論文品質的量表。它的用途是提早暴露理解缺口：答不出來就把相關工作退回 A 或 H，重新閱讀程式與原始證據，而不是用 AI 再生成一段更流暢的回答。

一個里程碑的完整 Claude Code 研究工作流

1. 先寫 H 卡：研究者凍結假設、主要指標、可否證條件、資料範圍與停止規則。
2. 分配 Ownership Budget：把本輪項目分成 H、A、D；不確定就先留在人類區。
3. 只讀規劃：用 plan mode 要求 Claude 列出候選修改、影響檔案、驗收命令與風險。
4. 人類選案：在 A 欄記錄接受／修改／拒絕及理由，再授權一個小範圍變更。
5. 執行與觀察：讓 Claude Code 修改、測試；研究者同時閱讀 diff、測試設計與失敗訊息。
6. 形成 E receipt：保存實際命令、版本、輸入、輸出、exit status 與未解問題。
7. 乾淨復現：從指定 commit 走單一入口，依 manifest 驗收數值與圖表。
8. 抽查與口試：里程碑後抽一項重跑；每週不用 AI 說明方法、限制與失敗結果。

這比「每次都逐行手寫」多一層治理，也比「看過 diff 就算懂」多一層理解測試。若你想把 receipt 做成 CI 的通過條件，可參考用 CI Budget 稽核 AI 大型 PR的漸進式 gate；若研究涉及 Agent 工具鏈，再搭配30 行建立 AI Agent Harness理解 planner、executor 與 verifier 的角色分離。

最常見的 6 個失敗模式

• 先看到好結果才補 H：這不是預先承諾。保留原時間線，把後續分析標成 exploratory。
• 把聊天紀錄當 provenance：對話太長、不可穩定重播，也缺少環境與檔案狀態；receipt 要指向具體 artifact。
• 只閱讀 diff：diff 能看變更，不能證明測試抓到對的錯，也不能證明你理解方法。
• 讓 AI 驗自己的答案：同一上下文容易沿用同一盲點；改用新的 reviewer、CI 或人類盲抽。
• 只保存成功：刪掉失敗與負結果，會讓決策路徑失真，也讓下一位研究者重踩同一個坑。
• 把 checkpoint 當版本控制：外部命令與人工操作可能不在其中；正式研究狀態仍要用 Git、環境鎖定與產物封存。

Claude Code 寫論文常見問題

CLAUDE.md 寫得夠嚴格，就能保證不越界嗎？

不能。它是持續上下文，不是安全邊界。高風險目錄要再用 deny 規則、sandbox 或作業系統唯讀權限保護，並由獨立驗收偵測違規。

可以讓 Claude Code 直接改論文文字嗎？

可以，但證據要先凍結。讓它改善結構與措辭之前，先把主張綁定 receipt；新的因果語氣、數字或引用一律退回 H 區由人類簽核。

研究日誌會不會大到無法維護？

日誌只留索引與決策。大型 console output、資料與圖另存 artifact；H/A/E 列只連到它們。可以摘要舊記錄，但不要刪除改變結論的決策鏈。

固定 random seed 就算可重現嗎？

不算。依賴版本、硬體、平行演算法、輸入與執行順序都可能影響結果。seed、環境鎖定、輸入雜湊和預先定義的誤差要一起保存。

Claude Code 找到的論文可以直接引用嗎？

只能當線索。作者要打開原始論文或官方資料，核對 DOI、版本、方法、樣本、原文上下文與限制，再簽核 citation receipt。

一個人做研究，怎麼進行盲抽查？

用時間與上下文隔離。里程碑後開一個乾淨 checkout，不讀原聊天，只按 receipt 重跑；更高風險的結果再請同事抽查。

失敗結果也要做 receipt 嗎？

要。保留失敗的命令、環境與原因，能讓 reviewer 看見已記錄的失敗路徑、降低只報成功的風險，也有助區分方法被否證、程式錯誤與基礎設施故障；單靠 receipt 不能證明沒有其他失敗被漏記。

怎麼知道自己仍有 ownership？

關掉 AI 後做三件事：說清楚假設與限制、從 raw data 走到一個核心結果、指出什麼證據會推翻結論。任一項做不到，就不是多問一次 Claude，而是回到程式與原始證據補理解。