Matt Pocock 實際示範如何使用 Claude Code 完成一個跨越多個 context window 的大型功能開發。影片核心在於展示「先規劃、再執行」的多階段計畫（multi-phase plan）工作流程，包括如何設定 rules 檔案讓輸出更精簡、如何利用 GitHub Issues 在不同 context window 間傳遞計畫，以及如何在 plan mode 和 auto-accept 模式間靈活切換。

原影片連結：https://www.youtube.com/watch?v=kZ-zzHVUrO4

影片重點

• 大型功能開發應先使用 plan mode 規劃，再切換到 auto-accept 模式執行
• 在 rules 檔案中設定「極度精簡」原則，讓計畫輸出更容易閱讀
• 設定規則讓每次計畫結尾附上未解決問題（unresolved questions），形成多步驟互動表單
• 當計畫太大時，要求 Claude 將計畫拆成多階段（multi-phase），避免超出 context window
• 使用 GitHub Issues 儲存計畫，作為跨 context window 的持久化資產
• 每個階段完成後檢查 context 使用量，適時清理或重建 context window
• 自訂 status line 顯示 repo、branch 和檔案狀態，提升開發效率
• 使用 claude --continue 指令可無縫恢復中斷的對話

詳細內容

[00:00] 開場與任務背景

Matt Pocock 開門見山說明這是一部「不太一樣的影片」——他想展示自己實際使用 Claude Code 工作的完整流程。他正在為一個內部 CLI 工具新增功能（與他的 AI Hero 課程相關），但他強調「做什麼不重要，重要的是怎麼做」。

這個功能的規模相當大，預計會超出單一 context window 的容量。他的初始 prompt 是用語音輸入（dictation tool）口述的，並且他已經將 Claude Code 切換到 plan mode。他指出：每當要開始一個大型工作時，永遠先從建立計畫開始。

[01:00] Plan Mode 的探索與釐清問題

啟動 plan mode 後，Claude Code 開始自主探索程式碼庫。它啟動了 explore sub agent 來了解現有的 CLI 結構，搜尋不同的檔案和模式。Matt 等待的是它能找出規格中不清楚的地方，然後回傳一份計畫。

接著出現了非常酷的環節：Claude Code 回來提出了一系列釐清問題。例如「你要從 repo 的哪裡取得 commit diffs？」、「要用位置引數還是必要選項？」、「exercise 編號要嚴格匹配還是彈性匹配？」——這就像一個多步驟表單，讓開發者在正式開始前把需求定義清楚。回答完所有問題後，就可以提交讓 Claude 繼續生成計畫。

[02:05] 計畫輸出與 Rules 檔案的關鍵設定

Claude Code 產出的計畫非常精簡、容易閱讀。Matt 解釋這是因為他在 rules 檔案（user memory）中做了關鍵設定。他按下 escape 暫時退出，用 /memory 指令打開 rules 檔案來展示。

他的 user memory 只有大約 43 行，內容非常精練。其中最關鍵的一條規則是：「在所有互動和 commit messages 中，極度精簡，為了精簡可以犧牲文法。」這就是為什麼計畫輸出如此好讀。Matt 表示這是他加進 rules 中「百分之百最喜歡的設定」，絕對不會拿掉。

其他規則還包括：PR comments 格式、changesets 的使用方式、使用 GitHub CLI 作為與 GitHub 互動的主要方式、建立分支時加上名字前綴（如 matt/）等。最重要的是：「在每個計畫結尾，給我一份未解決問題的列表，同樣要極度精簡。」

[03:40] 回答問題並進入多階段計畫

Matt 使用語音輸入工具口述答案來回覆未解決問題，提交後 Claude Code 繼續生成新版計畫。他強調一個重要觀察：「到目前為止我們還沒有寫任何程式碼。這全都是在寫程式碼之前的規劃。」

新的計畫沒有未解決問題了，但 Matt 的直覺告訴他這個工作量太大。如果工作太大，就會超出 LLM 的 context window。他的策略是：選擇「繼續規劃」而不是開始執行，然後要求 Claude 把計畫拆成多階段（multi-phase plan）。這個動作會讓 Claude 將工作分解成一組可跨多個 context window 執行的實作步驟。

[04:33] 監控 Context Window 與執行階段

拿到多階段計畫後，Matt 開始擔心 context window 的使用量。他退出計畫，執行 context 指令檢查：目前有 83.7% 的可用空間，只用了約 33K tokens。確認狀態健康後，他切換到 auto-accept edit 模式，開始執行 phase one。

遇到一個小插曲——Claude 仍然以為自己在 plan mode，Matt 直接告訴它「請直接開始 phase one」就解決了。

趁 Claude 執行的同時，Matt 介紹了他自訂的 status line：顯示當前 repo（相對路徑）、所在分支、staged/unstaged/new 檔案數量。他提到希望 Claude Code 未來能在 status line 中顯示 token 使用量，這是 Cursor 做得很好的地方。

[05:36] Phase One 完成與程式碼審查

Claude Code 要求建置專案（PNPM build），Matt 同意並設定「以後不用再問」。他選擇不在過程中逐步審查，而是等完成後再看。

Phase one 完成後，他用 Ctrl+C 退出 Claude，執行 code . 打開 VS Code 來審查變更。透過 Git diff 查看器可以看到新增了 get-diffs.js，以及更新了 internal 相關檔案。其中有一個 TypeScript 錯誤，但那是原本就存在的，不是 Claude 造成的。

一個很棒的細節是：Claude 在程式碼中留下了 phase 2 的 TODO 標記，這意味著進入下一階段時，程式碼本身就有提示指引執行方向。

[05:50] Claude Continue 與跨階段工作流程

Matt 展示了 claude --continue 指令，可以無縫恢復之前的對話。這個流程適合需要暫時退出 Claude 執行 CLI 指令後再回來的場景。

每個階段完成後，他會提交或暫存變更，讓不同階段之間的差異一目了然。檢查 context 後確認 phase one 只用了約 3K tokens，空間非常充裕，可以直接繼續 phase two。

他指出一個重要策略：完成規劃後，可以在 auto-accept 模式下較為積極地讓 Claude 自由執行，因為我們已經理解了實作方向。Phase two 順利完成，phase three 也接著完成。

[07:11] 處理外部變更：Auto Formatter 的意外

Phase three 完成後，Matt 不小心在 VS Code 中儲存了檔案，觸發了 auto formatter 產生了一些格式變更。由於 Claude Code 不知道外部發生了什麼，他直接告訴 Claude：「把這些檔案重新讀進你的 context」。Claude 精確地按照指示只重新讀取了檔案，沒有做多餘的動作。

[07:38] 跨 Context Window 的計畫持久化

Matt 接著示範了一個關鍵技巧：當需要重置 context window 時，如何保存計畫？他的答案是使用 GitHub Issues。他讓 Claude 建立一個 GitHub issue，其中包含完整的多階段計畫，已完成的項目標記為已勾選，未完成的保持未勾選。

這是透過 gh issue create 指令完成的。有了這個「雲端資產」後，他就可以放心地清理 context window。清理後 context 只剩下 16K tokens（來自 memory files、system tools 和 system prompt），完全沒有對話訊息。

然後他只需要告訴 Claude：「取得 GitHub issue #24，執行 phase 4」。在決定使用 plan mode 還是 auto-accept 時，他考慮到 context 已經完全清空，plan mode 會強制做一些探索，但最終選擇了 auto-accept，讓 Claude 直接從計畫取得資訊開始執行。Phase 4 和 phase 5 都順利完成。

[09:18] 核心理念與最終建議

Matt 總結了核心流程：將工作拆分成多個階段非常重要，但不一定要每個階段都用獨立的 context window。可以在同一個 context 中執行多個階段，邊做邊檢查 context 使用量。將計畫存在雲端（GitHub Issues）的好處是其他人也能留言、非同步協作。

這套流程的本質是：充分的前期規劃思考，加上在 auto-accept 模式下讓 AI 自由執行。Matt 在 AI Hero 和 Everite 的所有開發工作都使用這套方法。

他的三大核心建議：

1. 在 memory file 中加入「極度精簡」的規則
2. 讓 Claude 在每次計畫結尾產出未解決問題列表
3. 使用 GitHub CLI 建立 issues，在多個 context window 間共享上下文

我的想法

這部影片最有價值的觀點不是 Claude Code 本身的功能展示，而是 Matt 展現的「人機協作思維模式」。他不是被動地讓 AI 做事，而是主動設計了一套讓 AI 輸出品質更高的系統：透過 rules 檔案控制輸出格式、透過多階段計畫管理複雜度、透過 GitHub Issues 實現持久化。

特別值得注意的是他對 context window 的管理意識。很多開發者在使用 AI 編程工具時不會關注 context 的消耗，導致在長對話中品質逐漸下降。Matt 的做法是定期檢查、主動拆分、善用外部儲存——這些其實是軟體工程中「資源管理」概念的延伸。

另一個啟發是 rules 檔案的精簡原則。讓 AI 的輸出更精簡不只是美觀問題，更直接影響了 context 的消耗效率和計畫的可讀性。這條規則可能是使用任何 AI 編程工具時最值得借鏡的設定之一。