我大約有九個月的時間將 Claude Code 作為我的主要開發工具，而我所建立的工作流程，與大多數人使用 AI 編碼工具的方式截然不同。大多數開發者輸入提示，有時使用計畫模式，修正錯誤，然後重複。更沉迷於網路的人則會組合各種迴圈、MCP、Gas Town（還記得那些嗎？）等等。這兩種情況下的結果都是一團糟，對於任何非瑣碎的任務都會完全崩潰。
我將要描述的工作流程有一個核心原則：在您審閱並批准書面計畫之前，絕不讓 Claude 編寫程式碼。這種規劃與執行的分離是我做的最重要的事情。它能避免浪費精力，讓我掌控架構決策，並以極少的 token 使用量產生顯著更好的結果，而不是直接跳到編寫程式碼。
每一個有意義的任務都始於一個深入閱讀的指令。我要求 Claude 在做任何事情之前，先徹底理解程式碼庫的相關部分。而且我總是要求將發現的結果寫入一個持久的 markdown 檔案，而不是僅僅在聊天中進行口頭總結。
深入閱讀這個資料夾，深入了解它的運作方式、它的功能以及所有細節。完成後，在 research.md 中撰寫一份詳細的學習與發現報告。
詳細研究通知系統，了解其複雜性，並撰寫一份詳細的 research.md 文件，包含關於通知如何運作的一切知識。
瀏覽任務排程流程，深入了解它並尋找潛在的錯誤。系統中肯定存在錯誤，因為它有時會執行本應被取消的任務。持續研究該流程，直到找到所有錯誤，不要停止，直到找到所有錯誤為止。完成後，在 research.md 中撰寫一份詳細的發現報告。
注意這些措辭：「深入地」、「非常詳細地」、「複雜性」、「瀏覽所有內容」。這不是敷衍。沒有這些詞，Claude 只會粗略閱讀。它會讀取一個檔案，僅從簽名層級了解一個函數的作用，然後繼續。您需要表明表面閱讀是不可接受的。
書面產物（research.md）至關重要。這不是為了讓 Claude 做功課。這是我的審閱介面。我可以閱讀它，驗證 Claude 是否真正理解了系統，並在任何規劃發生之前糾正誤解。如果研究是錯誤的，計畫就會是錯誤的，實施也會是錯誤的。垃圾進，垃圾出。
這是 AI 輔助編碼中最昂貴的失敗模式，而且不是語法錯誤或糟糕的邏輯。而是那些孤立地工作但破壞周圍系統的實施。一個忽略現有快取層的函數。一個沒有考慮 ORM 約定而進行的遷移。一個複製了其他地方已存在邏輯的 API 端點。研究階段可以防止所有這些情況。
在我審閱完研究報告後，我會在另一個 markdown 檔案中要求一份詳細的實施計畫。
我想建立一個新功能 <名稱與描述>，該功能擴展系統以實現 <業務成果>。撰寫一份詳細的 plan.md 文件，概述如何實施此功能。包含程式碼片段。
列表端點應支援基於游標的分頁，而不是偏移量。撰寫一份詳細的 plan.md 文件，說明如何實現這一點。在建議更改之前閱讀原始碼檔案，並根據實際程式碼庫制定計畫。
生成的計畫始終包含對方法的詳細解釋、顯示實際變更的程式碼片段、將被修改的檔案路徑，以及考慮因素和權衡。
我使用自己的 .md 計畫檔案，而不是 Claude Code 內建的計畫模式。內建的計畫模式很糟糕。我的 markdown 檔案讓我擁有完全的控制權。我可以在我的編輯器中編輯它，添加內嵌註解，並且它作為一個真實的產物保留在專案中。
我經常使用的一個技巧：對於那些我曾在開源儲存庫中見過良好實施的、封閉的功能，我會將該程式碼作為參考與計畫請求一起分享。如果我想添加可排序的 ID，我會貼上一個做得好的專案中的 ID 生成程式碼，並說「他們就是這樣做可排序 ID 的，請撰寫一份 plan.md 文件，解釋我們如何採用類似的方法。」當 Claude 有一個具體的參考實施而不是從頭開始設計時，它的工作效果會顯著提高。
但計畫文件本身並不是有趣的部分。有趣的部分是接下來發生的事情。
這是我工作流程中最獨特的部分，也是我增加最多價值的部分。
在 Claude 撰寫完計畫後，我會在我的編輯器中打開它，並直接在文件中添加內嵌註解。這些註解會糾正假設、拒絕方法、添加限制，或提供 Claude 所沒有的領域知識。
註解的長度差異很大。有時一個註解只有兩個字：「非可選」放在 Claude 標記為可選的參數旁邊。其他時候，它可能是一個段落，解釋業務限制或貼上一個程式碼片段，顯示我期望的數據形狀。
一些實際的註解範例：
然後我將 Claude 重新導向到該文件：
我在文件中添加了一些註解，請處理所有註解並相應地更新文件。暫時不要實施。
這個循環會重複 1 到 6 次。明確的「暫時不要實施」保護措施至關重要。沒有它，一旦 Claude 認為計畫足夠好，就會立即跳到編寫程式碼。在我說可以之前，它還不夠好。
markdown 文件充當了我與 Claude 之間共享的可變狀態。我可以按照自己的步調思考，精確標記出錯誤的地方，並在不丟失上下文的情況下重新參與。我不是試圖在聊天訊息中解釋一切。我是在指向文件中問題所在的確切位置，並在那裡寫下我的修正。
這與試圖通過聊天訊息來指導實施有根本性的不同。計畫是一個結構化的、完整的規格，我可以整體審閱。而聊天對話則需要我滾動瀏覽才能重建決策。計畫總是勝出。
三輪的「我添加了註解，請更新計畫」可以將一個通用的實施計畫轉變為一個完美契合現有系統的計畫。Claude 在理解程式碼、提出解決方案和編寫實施方面非常出色。但它不知道我的產品優先級、用戶的痛點，或者我願意做出的工程權衡。註解循環是我注入這些判斷的方式。
在實施開始之前，我總是要求進行細粒度的任務分解：
在計畫中添加詳細的待辦事項列表，包含完成計畫所需的所有階段和單獨任務 - 暫時不要實施。
這會創建一個清單，在實施過程中作為進度追蹤器。Claude 會隨著進度標記項目為已完成，因此我可以隨時快速查看計畫，確切了解進度。這在持續數小時的會話中尤其有價值。
當計畫準備就緒時，我發出實施指令。我已將其精煉為一個標準提示，並在不同會話中重複使用：
全部實施。當您完成一個任務或階段時，請在計畫文件中將其標記為已完成。在所有任務和階段都完成之前不要停止。不要添加不必要的註解或 jsdocs，不要使用任何或未知的類型。持續運行類型檢查以確保您沒有引入新問題。
這個單一提示包含了所有重要的內容：
我在幾乎每一次實施會話中都使用這個確切的措辭（帶有細微變化）。到我說「全部實施」時，所有決策都已做出並經過驗證。實施變成了機械性的，而不是創造性的。這是故意的。我希望實施是無聊的。創造性的工作發生在註解循環中。一旦計畫正確，執行應該是直接的。
沒有規劃階段，通常會發生的是 Claude 在早期做出一個合理的但錯誤的假設，並在此基礎上構建了 15 分鐘，然後我不得不撤銷一系列更改。「暫時不要實施」保護措施完全消除了這種情況。
當 Claude 正在執行計畫時，我的角色從架構師轉變為監督者。我的提示變得顯著縮短。
規劃時的註解可能是一段話，而實施時的修正通常是一句話：
Claude 擁有計畫和正在進行的會話的全部上下文，因此簡短的修正就足夠了。
前端工作是最具迭代性的部分。我在瀏覽器中進行測試並快速發出修正：
對於視覺問題，我偶爾會附加螢幕截圖。一張錯位表格的螢幕截圖比描述它更快地傳達了問題。
我也經常引用現有程式碼：
這比從頭開始描述設計要精確得多。成熟程式碼庫中的大多數功能都是現有模式的變體。一個新的設定頁面應該看起來像現有的設定頁面。指向參考可以傳達所有隱含的要求，而無需詳細說明。Claude 通常會在進行修正之前閱讀參考檔案。
當某件事走錯方向時，我不會試圖修補它。我會撤銷並重新範圍界定，丟棄 git 變更：
撤銷後縮小範圍幾乎總是能產生比試圖逐步修復錯誤方法更好的結果。
即使我將執行委託給 Claude，我也從未給予它對要構建內容的完全自主權。我會在 plan.md 文件中進行絕大多數的主動指導。
這一點很重要，因為 Claude 有時會提出技術上正確但對專案錯誤的解決方案。也許該方法過於複雜，或者它更改了一個系統其他部分依賴的公共 API 簽名，或者它選擇了一個更複雜的選項，而一個更簡單的選項就足夠了。我擁有關於更廣泛系統、產品方向和 Claude 所沒有的工程權衡的上下文。
從提案中挑選：當 Claude 識別出多個問題時，我會逐一處理：「對於第一個問題，只使用 Promise.all，不要讓它過於複雜；對於第三個問題，將其提取到單獨的函數中以提高可讀性；忽略第四和第五個問題，它們不值得複雜性。」我正在根據我對目前重要事項的了解做出項目級別的決策。
修剪範圍：當計畫包含「錦上添花」的功能時，我會主動刪除它們。「從計畫中刪除下載功能，我現在不想實施這個。」這可以防止範圍蔓延。
保護現有介面：我知道有些東西不應該改變時，我會設定硬性限制：「這三個函數的簽名不應改變，調用者應該適應，而不是庫。」
覆蓋技術選擇：有時我會有 Claude 不會知道的特定偏好：「使用這個模型而不是那個模型」或「使用這個庫的內建方法而不是編寫自定義方法。」快速、直接的覆蓋。
Claude 負責機械執行，而我負責判斷。計畫預先捕獲了重大決策，而選擇性的指導則處理了實施過程中出現的較小決策。
我在一個長時間的會話中執行研究、規劃和實施，而不是將它們拆分到單獨的會話中。一個單獨的會話可能從深入閱讀一個資料夾開始，經過三輪計畫註解，然後執行完整的實施，所有這些都在一個連續的對話中完成。
我沒有看到大家談論的在 50% 上下文窗口後出現的性能下降。實際上，到我說「全部實施」時，Claude 已經花費了整個會話來建立理解：在研究中閱讀文件，在註解循環中完善其心智模型，吸收我的領域知識修正。
當上下文窗口填滿時，Claude 的自動壓縮會保留足夠的上下文以繼續進行。而計畫文件，這個持久的產物，則以完整的保真度倖存於壓縮。我可以隨時將 Claude 指向它。
深入閱讀，撰寫計畫，註解計畫直到正確，然後讓 Claude 不間斷地執行整個過程，沿途檢查類型。
就是這樣。沒有魔法提示，沒有複雜的系統指令，沒有巧妙的技巧。只是一個將思考與打字分開的紀律性管道。研究可以防止 Claude 做出無知的更改。計畫可以防止它做出錯誤的更改。註解循環注入了我的判斷。而實施指令則允許它在所有決策都做出後不間斷地運行。
試試我的工作流程，你會驚訝於在沒有一個註解過的計畫文件介於你和程式碼之間的情況下，你怎麼能用編碼代理發布任何東西。
我還在開發 polylane，因為到 2026 年，沒有人應該值班。