昨天，我把審查方法整理成 Claude Code 可以使用的 skill，再包成 plugin。規則有地方放，下一次也不用從頭交代。

但如果現在有人問：「所以你省了多少時間？」我還答不出來，只能給他一個禮貌又不失尷尬的微笑。

Claude 執行多久，可以查紀錄。我花多少時間準備材料、核對判級、修正規則，卻沒有完整記下來。接下來還會繼續改，如果現在沒有留下起點，之後就算覺得更順，也說不清楚差在哪裡。

METR 2025 年對 16 位資深開源開發者做隨機對照：允許用 AI 時完成時間多了 19%，受試者事後仍覺得自己快了 20%。那是當年的工具與任務，數字不能套到現在；但「體感和實測可能反向」這件事不會過期。METR 研究

Day 1 問的是「工作有沒有變好」，Day 2 到 Day 4 圍著同一件審查工作，看 Claude Code 怎麼接、怎麼驗、規則放哪。第一幕最後這篇，先約定比較哪種工作、怎麼算，再開始蒐集。這把尺量的是交給 Claude 的工作，不限寫程式：機器花了多久、人花了多久、結果能不能接受，三件事分開記。

程式寫快了，省下的時間去了哪裡？

先用一組合成數字，把「早完成」和「少投入」拆開。以下全部是教學用的合成數字，不是公司工時，也不是 Day 4 案例的計時。

實作少了二十分鐘，人卻沒有少忙：審查與返工把省下的吃回去了；交付倒是早了一小時。更早交付看經過時間，人工減載看人的投入。 只報實作時間會藏住負擔轉移，只報總投入會漏掉交付提早。

合成示範；經過時間另外設定，不是人工分鐘相加。

還有第三件事：品質。更早交出去卻不符合原本的接受條件，就不算同一種成果。三樣要一起看。

先約好，接下來要怎麼比

整段交付最後都要看，但先從前兩天反覆遇到、要人工查證的那一段開始：一輪小型 PR 審查。Day 3、4 看過 Claude 能交回發現，人還得核對來源；我想知道調整審查方法後，查證與補件有沒有少，重要問題有沒有漏。DORA 的價值流分析也是這個思路：把步驟攤開，找摩擦在哪。DORA

先把比較規則寫成「基線卡」。它現在是量測計畫，累積了目前做法的資料才成為基線。

計時前再約定三件事：

• 輪次看程式版本。 同版程式只補需求或證據，仍是同一輪；修改程式重新送審，才另開一輪，不按 Claude 呼叫次數計算。
• 投入與經過時間分開。 人工投入含送審前準備，送審到核對完成的流程時間不含；若要量完整經過時間，另記準備起點。同一人同一分鐘只算一次，機器與人工不相加。
• 抽樣與漏記分開。 同時報應抽與實抽件數，未抽中的標「未納入」，不和漏記混。

Claude 二十五秒交回結果，我呢？

我翻出訂單取消案例的一次審查紀錄。Claude 花了約二十五秒，交回六條需要核對的發現。

有的在問規則在哪裡，有的指出假設還沒確認，也有的提醒呼叫端和測試證據沒交代。六條都有可追查的位置：

看起來已經替我做了不少事。

但接下來呢？我讀懂這六條花多久？哪些需要回頭找規格？補件後又查了多久？紀錄沒有寫。

把這次交付攤開，差別就很清楚：

這筆是一般提示審查，沒有載入 plugin，原件編號 G0-A；它碰核心規則，只拿來認欄位，不進上面小型 PR 的基線。

同一份材料、同一段提示，三天後重跑，結論變了。 第一次要求 Owner 確認，第二次改成要求補證據（五回合、19.1 秒、費用估值 US$0.0568），沒再指出自評不符。兩次 CLI 版本不同，一次不能當代表；量時間之前，先核對它到底交回了什麼。

我能回答 Claude 執行多久，還不能回答自己少忙了多少。 下一輪要補的，是工作紀錄裡人的那一半。

下次多記幾件事，才知道卡在哪裡

我不打算請大家把每件事逐分鐘填完，而是先選一個專案的小型 PR 審查，依基線卡觀察：約定期間與完成點，符合條件的都列入名冊，卡住的也保留；Claude 的執行資訊沿用紀錄，人補上為了確認結果做了什麼。沒有導入前基線，就從目前做法累積起點。

一個完全合成的教學案例：假設 Jira 有一張「修正列表排序」的工單。Claude 交回審查結果後，Reviewer 發現提供的需求是舊版，補上新版再請它確認。這一輪從準備材料到核對修正後的結果，留下這張紀錄：

這二十分鐘是人的投入，不含機器秒數。它證明不了省時，但指出一個可改的地方：時間花在重新確認需求版本。只看 Claude 多快回答，看不到這件事；所以人工補記除了分鐘，也要問卡點。

想自己拿一筆，可以這樣做

前面是我的既有紀錄。如果你想知道自己的 Claude Code 會留下哪些資料，可以用這個小練習拿一筆。它只幫你認識紀錄，不重現剛才的二十五秒，也不要求日常工作額外重跑。

第一步，準備一份你有權使用的 PR。 同一資料夾放四份材料：PR.md 修改說明、ticket.md 需求與驗收條件、diff.patch 差異、Program.cs 測試；檔名不同就把提示一併改。在該資料夾開 PowerShell，需先安裝並登入 Claude Code。

第二步，請 Claude 看一次，順便留下紀錄。 這段指令做三件事：讀取材料、只審查不改檔、把回答與執行資訊存進 run-demo.json。

claude -p "讀取 PR.md、ticket.md、diff.patch、Program.cs，僅審查，不修改檔案。用三句話說明這份 PR 缺什麼依據。" --model sonnet --effort low --safe-mode --tools Read,Grep,Glob --allowedTools Read,Grep,Glob --output-format json > run-demo.json

檔案存好後，先讀 Claude 的回答，看看它指出什麼缺件。這才是這次審查要做的工作；留下的數字，是幫我們回看這段工作，不是另一份成績單。

第三步，把工具紀錄和自己的投入放在一起。 打開 run-demo.json，確認執行成功後，先找下面四欄：

接著補上：自己讀材料、操作、核對回答與補件各花多久，卡在哪裡。事後回想就標「估」，不知道留未知。

這四欄為什麼自動就有？因為 claude -p 加 --output-format json 的回傳本來就帶著它們。互動模式在對話裡輸入 /cost 也看得到費用與時間。要每次自動落檔，session 開始與結束有 hook 可以掛；官方遙測是另一條路。

我的機器上那兩支 hook 已經掛著。把 09-15 到 09-19 16:14 的原始紀錄攤開：

三件事在數字裡。機器那半邊會自動來，但要先去重、配對、分清哪一欄量什麼，才敢加總。 自動也會被自己關掉：今天六次隔離實驗用了 --setting-sources ""，hook 跟著停，一筆都沒進帳。人工那半邊沒有任何機制會替你填，也不能從 session 時長推算。

我 09-17 用 Day 4 的合成材料跑過一次 demo-01：約十二秒、五回合、費用估值 US$0.0474。它交回的三句是：

這份 PR 最缺的是「規則位置」與「驗收預期的規則依據」：ticket 只有一句需求，已付款退款、已取消 no-op、null 拋例外都是作者自行假設。其次，「已確認／待確認」與「尚未驗證的路徑」欄位空白，呼叫端完全未被檢視。第三，測試由同一支 AI 依自己假設的規則編寫並自證通過，等於用假設驗證假設。

三句和 G0-A 的六條指向同一個缺口，用字與數量不同。執行成功看 is_error: false 與 subtype: success；成功不代表審查內容對。做到這裡，你有了一筆「Claude 做了什麼、人又補了什麼」的紀錄；單筆證明不了省時，但下次回看不必只靠印象。

記下來之後，團隊要改什麼？

第一輪先用一張共用表，照工作發生的順序記：

• PR 送審時： 填上工單、PR 版本與審查輪次，讓紀錄對得回這次修改。
• Claude 執行後： 附上既有執行紀錄，留下工具花了多久、交回什麼。
• Reviewer 核對完成時： 留下接受或退件結果、卡在哪裡，再依抽樣規則補上人工投入。
• 進入 CI 或部署時： 另記測試與部署結果，和前面的審查階段分開。

工單、PR 與 CI 通常已有事件紀錄；Claude Code 的執行資訊要確認是否保存，人工投入則需要另外補記。先挑一件工作，看看工單、PR／CI、Claude 執行與人工簡記這四種資料能不能對上。

task_id 用來連結資料，不是直接加總的指令。同一任務可能有多個 PR、審查輪次、session 與 run；對上任務後，仍要依各自識別碼核對重複事件、分清輪次與缺值。流程時間用約定的起訖事件計算，不能把多個 session 的時長相加當成交付經過時間。

依 G0-A 原件與作者記錄器狀態整理。圖中的「0 筆」指有效人工投入紀錄；全空的占位不計入。

先記一輪，看這些欄位能不能幫團隊找到卡點，再決定哪些重複動作值得自動化：送審時自動建草稿、執行後自動帶入工具紀錄，人補查證與判斷。工具執行結束不等於人核對完成。這套整合目前是設計。

設計示意。程式整理事件，skill 補問，人確認；團隊依可比較的紀錄決定下一輪。

到了約定的回看時間，先確認這批工作可不可比、漏了哪些，再看卡點。延續合成情境：如果多筆審查都卡在需求版本不明，先調整送審材料，不是判定 Claude 不好用。

除了想觀察的改動，其餘條件盡量一致，同期的人員與模型變動也留下來。比的是協作方式調整前後，推不成「有 AI 比沒有 AI 快」。這接回 Day 2 的 Retro：挑一個卡點，改一次，用同樣的尺回看。

這把尺，最後要回答 Day 1 的問題

Day 1 的五層問題，不能靠一份 Claude 執行紀錄全部回答。把目前有的與缺的放在一起：

「今天有沒有」那一欄是起點，後面每一次調整都回到這五個問題交帳；有證據的回答，沒有證據的留下未知。

回到一開始：我真的比較輕鬆了嗎？

• 先訂量測計畫，再累積基線。 約定工作範圍、期間、起訖與品質，只蒐集必要資料。
• 工具紀錄、人工投入與品質一起看。 Claude 執行得快，還不足以代表整件工作改善；同一段提示重跑結論會變，一次不能當代表。
• 第一筆自己拿。 一個最小指令、四個欄位、幾格憑印象標估的人工分鐘，就是起點。
• 紀錄要帶來下一個決定。 Retro 選一個卡點調整，再以相同口徑回看，不拿個人活動量排名。

今天先把審查的終點寫成「人工核對完成」。但這句話對我、Claude 和下一位接手的人，是否代表同一件事？這也是開始記錄之前，需要一起約定的事。

參考資料：

本文實作紀錄

• Claude Code 審查紀錄： G0-A 為原始審查，V-G0-A 為同材料與提示的重跑，demo-01 為另一筆簡短練習。三筆均為唯讀、未載入 plugin；執行條件不完全相同，不作受控效能比較。正文秒數、費用與回答取自各次保存紀錄，公開原件見 Day 5 審查實跑紀錄。
• **記錄器盤點：**作者本機 SessionStart／SessionEnd hook，統計 2026-09-15 00:00 至 09-19 16:14：開始事件 21（startup 11、resume 4、compact 2、clear 1、無 session_id 的 headless 3）、結束事件 15；不重複 session_id 開始 14、結束 12；6 筆開始無對應結束（兩個長 session 的 resume／compact）、1 筆結束無對應開始（clear）。43.4 分鐘為 11 筆非空 machine_minutes 的原始加總，欄位為開始到結束的時間差，不代表模型執行時間或去重後使用量。人工 entries.jsonl 僅一筆占位、五個分鐘欄全空。09-19 六次實驗以 --setting-sources "" 執行，hook 未觸發。依 sessions.jsonl、entries.jsonl 與 hook 程式核對。
• 合成示例： 70／70 人分鐘、240／180 經過分鐘，以及 DEMO-123 的情節與 20 分鐘，均為教學設定，不是公司工時，也不是替上述實跑補出的人工紀錄。

方法參考

• METR，Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity（2025）與 2026 年實驗設計更新：後續研究指出選樣與並行計時的困難；2025 結果不能直接推論目前工具。
• Anthropic，Claude Code CLI reference、Monitoring usage、Manage costs、Hooks reference：--output-format json 欄位、內建 OTel、費用估值、生命週期事件；本篇未部署遙測與整合。
• DORA，Value stream mapping for software delivery；Forsgren 等，The SPACE of Developer Productivity（2021）；DevEx: What Actually Drives Productivity（2023）：量測方法的參考，不是本文 worklog 設計的驗證。