"CSV 匯出已修好，只剩檢查" - 工作就這樣告一段落。隔天您打開專案，卻不清楚哪些檔案改過、匯出是依據哪個版本檢查的，以及檢查停在哪裡。
若要接著做、又不必重新調查，下一個階段需要已保存的結果、檢查資訊，以及接下來要做的事。我們用同一個任務來看交接怎麼做：工作可以由同一個工作階段、幾位執行者，或分兩次處理的您來完成。
交接可供查閱的結果
購物清單的 CSV 匯出功能壞了。需求是：匯出內容只包含畫面上顯示的資料列，順序也要一致。清單為空時，約定保留標題列，不含資料列。欄位格式和分隔符號都不必更動。
別只留下 "已修好，尚待檢查"，我們要寫下能找到變更並接續工作的紀錄。以下的雜湊值和結果都是假設的教學範例，並非實際執行的結果。
HANDOFF
目標：CSV 只包含目前畫面上顯示的資料列，順序也相同。
輸入版本：基礎 commit 4f1c2ab。
交接狀態：fix-export 分支上的 commit 9d3e740，沒有其他修改。
結果：src/export-csv.js - 匯出會使用篩選和排序後的清單。
已於 9d3e740 手動檢查：原始資料列為 A、B、C；畫面上是 C、A；
CSV 資料列是 C、A，沒有 B。標題列不算資料列。
尚未檢查：空清單；"只顯示未完成項目" 模式。
決策：欄位格式和分隔符號維持不變。
下一步：主要工作階段檢查剩下的兩種情境。
整體任務狀態：檢查尚未完成。字母代表清單中的三筆資料。這個情境一次檢查兩件事：隱藏的 B 沒有出現在匯出檔中，而且 C、A 的順序與畫面一致。如果清單本來就只有兩筆資料，最後匯出兩列並不能證明篩選有效；不篩選也會得到相同結果。
您可以把紀錄存成 HANDOFF.md，或補進現有的任務文件。欄位沒有固定標準，重點是下一位執行者即使看不到前一段對話，也能連同必要檔案一起開啟紀錄。
如果是透過指令檢查，請一併記下指令、實際結果和程式碼版本。"12 項全數通過" 沒說明檢查了什麼行為。手動測試則要記下輸入資料、操作，以及觀察到的結果，就像上面的範例。
您可以請 Claude Code 先整理草稿："根據目前的檔案和已完成的檢查，準備一份交接紀錄。區分事實與假設。註明檢查所依據的狀態、尚未完成的部分，以及接下來從哪裡繼續。不要把尚未完成的檢查說成已通過。" 使用前，請先核對版本與檔案是否一致，再把結果和手動檢查紀錄或指令輸出比對。
訂出進入與退出條件
交接時，下一個階段要能判斷收到的資訊是否足夠。以這個任務來說，可以用三列說明。
| 階段 | 輸入 | 輸出 | 驗收條件 |
|---|---|---|---|
| 釐清 | 需求與目前的檔案 | 附上程式碼參照的錯誤原因、預期行為 | 已確定要匯出哪些資料列、順序如何，以及清單為空時的處理方式 |
| 修改 | 已確認的行為與輸入版本 | 匯出功能的修改，以及本機檢查紀錄 | 已保存的狀態可供使用、已列出修改的檔案，且已區分檢查過與尚未檢查的內容 |
| 檢查 | 交接的狀態與測試情境 | 各情境的觀察結果、限制和注意事項 | 結果對應到交接的版本；每個情境都有結果，注意事項也列出下一步 |
最右邊這欄最重要。進入檢查階段時，它回答的是 "現在可以開始檢查了嗎？" 即使修改內容描述得再完整，也仍可能有錯；檢查完成後也可能發現問題，需要退回修改。一份有用的報告，不一定帶來成功的消息。
如果沒有註明版本，先確認檔案目前的狀態。您可以檢查現況，但不能未經核對就把舊報告套用到新狀態。各階段不必分配給不同的代理，也不一定要用不同文件：小型任務可以在同一個工作階段中走完三個階段，只留一份紀錄。
保存已確認的狀態
交接紀錄裡很容易把三件不同的事混在一起：
- 已保存的程式碼狀態 - 可還原的特定版本；
- 工作進度紀錄 - 做了什麼、檢查了什麼、有哪些共識；
- 結果驗收 - 判斷目前成果是否足以達成目標。
commit 會指出其中保存了哪些檔案。但如果 commit 之後又有其他變更，單靠這個參照就無法描述完整的交接狀態：那些修改也要另外保存、列出，新檔案也一樣。交接一組變更時，也要註明用來比較的原始版本。只提供分支名稱不夠，因為分支還會繼續變動。
想像一下：紀錄寫著 9d3e740，但負責匯出的程式檔在該版本之後又被編輯過。接手的人認得這個雜湊值，實際操作的卻是另一份程式碼。他得先查明改了什麼。如果修改影響資料列的篩選或排序，先前檢查 C、A 的結果就不能證明目前的行為；如果只改了註解文字，本身不代表需要重跑測試情境。
不一定每個步驟都要建立 commit，也不必把自己和別人的修改全塞進同一個 commit。重要的是完整保存交接狀態，讓接手的人能取得；保存方式則依照專案規範。如果檔案不在原處，先檢查已保存的版本。如果變更從未保存，光靠一則紀錄也還原不了。
恢復對話本身不會讓檔案回到紀錄描述的版本。Claude Code 的修改快照也不涵蓋所有變更：透過 Bash 做的修改不會被追蹤，還原其他執行者的變更也有其限制。因此，交接要以已保存的檔案及其版本為準。詳情請參閱：Checkpointing。
釐清停止的原因
"行不通" 至少可能代表三種不同情況。
本機執行中斷。指令尚未完成，或檢查執行到一半就中止。先確認哪些操作已經完成、哪些內容已經變更。如果問題已排除，而且重跑不會重複已完成的動作，就可以重做尚未完成的步驟。以這個例子來說，我們約定重試一次；如果又中斷，就記下停止原因，以及接續工作需要什麼。重試次數要看操作而定，無限重試也不會讓問題更清楚。
預期行為不明確。例如，執行者不知道啟用篩選器時哪些資料列才算顯示中。他會先核對已記錄的需求；如果裡面沒有答案，就向負責需求的人提出問題。得到答覆後再繼續修改，重跑指令無法代替這個答案。
新資訊推翻了原先的決策。後來發現，CSV 是由另一個程式讀取的。釐清後，大家決定改用不同的欄位組合，也不再要求維持順序。工作要退回釐清階段：記錄新條件，重新檢視依賴這項條件的修改與檢查。先前跑過的情境或許仍有參考價值，但已無法驗證更新後的整個任務。
這裡要退回釐清階段，因為原始決策改變了。如果需求不變，只是在實作中發現錯誤，那麼退回修改階段就夠了。只需重新檢視受該決策影響的結果。
從目前狀態接續工作
恢復工作時，請依序做這五件事：
- 完整閱讀交接紀錄，包括尚未檢查的部分；
- 將交接狀態與目前可用的檔案及額外變更比對；
- 如果有操作中斷，先查明執行結果；
- 確認哪些先前的結果仍然有效；
- 執行下一個尚未完成的步驟，並更新紀錄。
回到一開始的例子，需求沒有改變。下一個工作階段開啟交接紀錄並核對狀態：commit 9d3e740 可用，沒有其他修改，資料和檢查條件也都相同。C、A 情境已完成，結果仍然適用，不必重新撰寫修正內容。
接著，接手的人檢查空清單。依照任務需求，CSV 應只留下標題列，不含資料。在這個教學範例的後續情境中，檢查結果正是如此。只要把結果補進紀錄，再更新尚未完成的步驟即可：
已於 9d3e740 手動檢查：空清單匯出只包含標題列。
先前檢查的 C、A 情境仍然有效。
尚未檢查："只顯示未完成項目" 模式。
下一步：主要工作階段檢查這個模式。
整體任務狀態：檢查尚未完成。交接紀錄也隨著工作進度更新了。剩下的兩個情境中，已完成一個，另一個仍清楚列在紀錄裡。部分成果還不足以達成原始目標；若要把檢查移到另一個任務，則需要另外決定是否調整範圍。
如果執行中斷，可能需要從頭重跑中斷的測試情境：不是每種工具都能從中間繼續。只要程式碼、輸入資料和條件仍然一致，先前已完成的檢查就仍然有效。
即使沒有收到結果回覆，操作也可能已經完成。重試資料傳送、發布或寫入檔案之前，先確認動作是否已發生。在哪裡執行並不能保證安全：本機指令也可能再次加入相同資料。在結果尚未確認前，不要用重試取代狀態檢查。
由誰準備交接紀錄
Claude Code 可以整理事實、核對下一個階段所需的輸入，並執行已確認的步驟。您則要確認紀錄是否符合檔案和執行結果。對需求有疑問或要變更範圍時，應由人或指定負責人決定；在我們的流程中，最終驗收也由人負責。
保存版本有助於接續工作，但不會擴大執行者的權限。如果交辦的是檢查匯出功能，有還原點不代表可以順便更改欄位格式。交接之後，任務範圍依然有效。
GO TO FULL VERSION