2026年3月，Matt Van Horn 在X 平台發了一篇長文，標題很直接：《我所知道的每一個Claude Code 技巧》。這篇貼文的瀏覽量最終停在913,000 次，留言區吵成了一鍋粥。

引爆爭論的不是某個具體指示或配置參數，而是他在開頭寫下的一個說法：No IDE。他在描述自己的工作狀態時提到，整個過程沒打開過一次圖形化編輯器，所有的開發作業都發生在終端命令列和一份叫做plan.md 的檔案裡。有人看後覺得荒謬，問他程式碼閱讀、調試、重構怎麼辦；也有資深工程師在下面留言說「這就是我一直在找的方式」。

兩個月後，中文開發者meng shao 將這套方法連同社區衍生的實踐整理發布，冠以“智能體工程實戰竅門全錄”之名。它不是工具評測，而是一組圍繞著「Research → Plan → Work」循環展開的操作原則，背後是22 個可複現或可討論的具體技巧。

本文整理了網路上討論最多的一些AI工作流程操作指南，從中我們或許可以得到一些共通點的東西。

關上IDE，到底丟掉了什麼

圖形化IDE 提供給開發者的不只是程式碼編輯區。它是一套完整的感官系統：語法高亮讓你一眼看出變數和關鍵字的區別，即時錯誤提示在輸入過程中就告訴你哪裡出了問題，斷點調試允許你逐行觀察變量狀態的變化，文件樹和麵包屑導航幫你在大項目裡不迷路。這整套視覺回饋機制構成了一個預設假設：寫程式碼的人需要親眼看到每一行程式碼的狀態。

終端命令列+ Markdown 檔案的工作流程把這層視覺保護殼拆掉了。你面前只剩一個閃爍的遊標，和一份你親手寫下的計畫文件。沒有紅色波浪線標示的錯誤，沒有自動補全彈窗，沒有文件樹。 Matt Van Horn 在推文中使用了“No IDE”這個詞，它的真正含義不是拒絕所有圖形化工具，而是把開發的控制邏輯從“逐行手動確認”變成了“批量委派執行”。

Boris Cherny 是Claude Code 的負責人，他在2025 年底到2026 年初透過Threads 和其他管道分享了他自己的Claude Code 使用方式。他的做法是CLI 優先，把plan mode 作為所有任務的起點。這跟IDE 的思考方式有一個本質區別：在傳統IDE 裡，人是主動的代碼生產者，AI 補全只是輔助；在計劃驅動的終端工作流程裡，人是方向制定者和驗收者，代碼的生成和實現路徑由Agent 自主選擇。

放棄IDE 丟掉的是「親手敲每一行程式碼」的安全感。這聽起來像是損失，但對於已經在大型專案中經歷過大量上下文切換的開發者來說，這也是一種卸載。因為你不再需要在讀程式碼、寫程式碼、搜尋文件、切換文件這些動作之間反覆跳躍。你只需要把一個需求講清楚，然後把執行過程交給一組並行運作的Agent。

meng shao 在總結中提出的框架是“人主導方向、智能體執行”，IDE 時代人既要主導方向又要執行細節，兩個角色纏在一起。新工作流程試圖把這兩個角色拆開，人只做前半段。

plan.md 不是文檔，是一份契約

這套工作流程出現最多的檔案名稱就是plan.md。它聽起來像專案文檔，但實際功能完全不同。

專案的README 或開發文件是給人讀的，用來解釋架構決定、記錄介面約定、幫助新成員上手。 plan.md 的主要讀者不是人，是Agent。它的結構圍繞著三個東西：問題定義、解決方案描述、Checkbox 形式的執行清單。 meng shao 在推文中把這層關係講得很直白：plan.md 的作用是「約束智能體不偷懶」。

LLM 在長會話中有一個已知問題，社區稱之為「上下文腐敗」。當對話歷史越來越長，模型對早期目標的注意力會自然衰減。它可能在中途忘記最初的需求邊界，也可能偷懶跳過某些檢查步驟。社群中一個名為「潔癖.skill」的計畫專門針對這個問題，提供了自動整理會話檔案、更新持久化記憶庫的方法。它的核心判斷是，Agent 的長期表現不取決於單次Prompt 的質量，而取決於是否有穩定的外在記憶機制。

plan.md 就是這個外在記憶。它在檔案系統上落盤，不隨會話結束而消失。每一個新的Agent 會話都可以從這份文件重新載入上下文，而不是依賴上一輪對話中已經衰減的聊天記錄。

Compound Engineering 是支撐這套工作流程的核心開源插件，由Every Inc. 的Kieran Klaassen 開發。它提供了一組命令列指令，其中/ce:plan可以根據開發者的輸入自動產生plan.md 的初稿。生成之後，開發者的工作是審查和修正：Agent 可能會對技術選型有錯誤的假設，可能會低估某個模組的複雜度，也可能完全誤解業務邏輯。人在這時的介入不是微調程式碼，而是在計畫文件中註入Agent 不知道的領域知識，然後把修正後的計畫交還給Agent 執行。

這個設計與Boris Cherny 在Claude Code 使用原則裡強調的一點高度一致：把人類專家的判斷集中在計劃審查這一個節點，而不是分散在執行的每一步。用他的話來說，如果每一步都要人盯著確認，那跟手動寫程式沒有本質區別。

一份有效的plan.md 不會很長。它通常包含清晰的驗收條件，每個條件都可以對應到一個Checkbox。這些Checkbox 是給Agent 看的執行錨點，也是給人看的驗收標準。開發者在Work 階段完成後，不是去讀程式碼，而是去檢查這些Checkbox 是否逐一打勾。

一個需求的三種形態：Research → Plan → Work

這套工作流程最核心的骨架，是Research、Plan、Work 三個階段所構成的一個閉環。它不複雜，但每一段的工具支援和人的介入方式有清晰的分工。

Research 階段的目標是讓Agent 在動手之前先建立資訊優勢。常用的方式是使用/ce:brainstorm指令，或載入特定的Research 技能包。 Matt Van Horn 開源了一個叫last30days-skill 的技能，GitHub 星標數在2026 年3 月底已超過10,000。它的功能是讓Agent 並行抓取Reddit、X 平台、Hacker News 等社群在過去30 天與指定主題相關的內容，然後輸出一份結構化的分析摘要。假設你要啟動一個涉及新技術棧的項目，你的Agent 可以在幾分鐘內拉回社區裡關於這個技術棧的最新評價、已知的坑、推薦的替代方案，而不是讓你手動打開十幾個瀏覽器標籤。

Research 完成後的產出並非最終答案，是資訊輸入。這些資訊進入Plan 階段，成為生成plan.md 的素材。

Plan 階段使用/ce:plan指令。 Agent 基於Research 階段的發現、開發者輸入的初始需求、以及專案現有的程式碼上下文，產生一份plan.md 草稿。 Compound Engineering 的設計概念是80% 的時間花在規劃和審查上，20% 花在執行上。這個比例初看很激進，邏輯其實直接：一份寫得清楚、邊界明確、驗收條件具體的計劃，可以讓執行階段的返工成本降到最低。

開發者在Plan 階段要做的事情包括：修正Agent 對技術方案的錯誤假設、補入Agent 不知道的業務限制、調整任務拆分粒度和執行順序、在Checkbox 裡加入Agent 容易跳過的邊緣情況。這個審查過程本身也是一種“外在記憶注入”，因為人們在這時把那些在對話中很難自然出現的隱性知識寫進了計劃文件。

Work 階段使用/ce:work指令。 Agent 讀取plan.md，將任務拆分為子任務，派發給子Agent 並行執行。 Boris Cherny 曾經分享過一個數字：使用這種plan 驅動的工作流程，他在一個月內產出了259 個PR。這個數字說明的不是程式碼質量，而是當執行階段的決策權被下放給Agent 之後，人的瓶頸不再在打字速度上。

三個階段之間有一個容易被忽略的關鍵點：Research 和Plan 階段可以多次循環。如果Agent 在Plan 階段暴露了資訊缺口，可以隨時切回Research 模式補充。 Work 階段開始後如果發現計畫有誤，也可以回到Plan 階段修正。這個循環不是線性的瀑布流，是允許回退和調整的環。

六條能馬上試起來的技巧

在目前已公開的資訊中，以下六條技巧都有明確的出處和足夠細節來支撐一個開發者直接嘗試。它們不是抽象原則，是具體到「開啟終端機敲什麼」「把什麼寫進檔案」「用哪個工具」的操作。

技巧一：有想法立刻產生計劃，不要自己先在腦中推演。

meng shao 在原帖中把這條放在很前面的位置。他的邏輯是，人的大腦善於審閱，不善於憑空建構複雜邏輯的完整樹狀結構。開發者在接到一個新需求時，習慣性在腦中反覆推演實現路徑，但這個過程效率極低，因為工作記憶的容量有限。正確的做法是在想法出現之後立刻讓Agent 生成第一版計劃，即使它粗糙、有錯誤、需要大量修正。審閱有問題的計劃，比從零開始寫一份完美計劃要輕鬆得多。

技巧二：自己不讀計劃，讓Agent 把計劃總結成幾句話。

長計劃文件的閱讀本身就是一項目成本。 Boris Cherny 在22 條Tips 中的一條是使用自然語言指令讓Agent 提供TLDR，或用「eli5」讓它用最直白的方式解釋計畫的核心要點。如果你有5 分鐘時間審閱，把前3 分鐘交給Agent 的摘要，後2 分鐘只檢查你覺得有風險的部分。這項技巧的本質是把「閱讀理解」這件事也委派出去，人只看自己必須看的內容。

技巧三：多終端並行。

Matt Van Horn 在推文中提到他會同時開啟4 個以上的終端機窗口，讓不同的Agent 實例處理不同的子任務。一個在做前端頁面，一個在寫後端接口，一個在跑測試，一個在抓文檔。這套做法把傳統的單執行緒開發變成了多執行緒調度。代價是，你需要自己管理不同終端的輸出和狀態，沒有圖形化的工作台幫你統一監控。對於習慣在一個IDE 視窗裡掌握全局的開發者來說，剛開始會有「不知道哪一邊出錯」的焦慮感。

技巧四：用語音取代鍵盤輸入複雜架構指令。

meng shao 提到使用monologue 等語音工具進行輸入。具體的做法是，面對一個需要長篇描述的系統設計思路，​​不是敲鍵盤逐字輸入，而是用語音把整個思路講出來，讓語音轉文本工具把內容灌入終端或計劃文件。 Matt Van Horn 把這條稱為“Get Voice-Pilled”，他認為語音比打字更容易保持複雜架構思維的連貫性，因為說話的速度和邏輯流的自然展開節奏更匹配。這項技巧對中文開發者的實際效果目前還缺乏足夠回饋，monologue 的中文語音支援能力也待進一步確認。

技巧五：郵件觸發非同步任務。

Matt Van Horn 在2026 年4 月的一條推文中分享了一個具體場景：他在哄孩子睡覺時，透過agentmail 工具給自己的Claude Code 實例發了一封郵件，觸發了遠端程式碼建置任務。等孩子睡著後，建造已經跑完，結果在終端機裡等他驗收。這本質上是把開發行為從「必須坐在電腦前」的物理約束中解放出來，讓Agent 在後台持續工作。前提是你對Agent 的信任程度夠高，願意在看不到螢幕的情況下讓它自主執行。

技巧六：把工具棧當成技能市場來用。

AgentSkills 等計畫提供了一個核心理念：開發者不需要從零建構每一個Agent 能力。文件管理、新聞監控、網頁抓取這些通用能力已經有社群維護的技能包可以載入。在終端工作流程裡，載入一個新技能的操作量級接近裝一個插件，你只需要在設定裡聲明技能包的來源和參數，Agent 就能自動取得對應的工具呼叫能力。 Claude Code Video Toolkit 作為社群實踐的一例，為CLI 環境增加了視訊內容的理解能力，雖然應用場景還比較垂直，但它說明了終端Agent 的能力邊界可以透過技能包持續擴展。

這個流程什麼時候會反噬你

這套工作流程的反對聲音並不少。綜合社區討論，問題主要集中在三個方向。

第一個問題是適用人群的邊界。 Boris Cherny 的22 個Tips 本身就有隱含前提：使用者需要有足夠的架構拆解能力和Prompt 約束能力。能獨立完成系統設計的人，知道「該讓Agent 做什麼、不做什麼」的邊界在哪裡。對於還需要IDE 的錯誤提示、程式碼高亮和斷點偵錯來理解程式碼邏輯的開發者來說，關掉圖形化編輯器等於關掉了自己熟悉的資訊擷取通道。這不是能力高低的問題，是工作方式依賴的感知通道不同。新手開發者透過逐行調試來建立對程式運行過程的心智模型，這個學習過程在終端工作流程裡缺乏替代方案。

第二個問題是風險集中。在傳統IDE 裡，錯誤是在執行過程中逐漸暴露的：編譯錯誤、類型不符、執行時異常。人有機會在每一個環節發現並修正問題。在計畫驅動的工作流程裡，所有決策審查被壓縮到Plan 階段這一個節點。如果人在這個節點的審查不夠徹底，錯誤會在Work 階段被Agent 忠實且有效率地放大。等你發現的時候，可能已經有多個文件被錯誤邏輯污染。

第三個問題Matt Van Horn 自己提過，他管它叫「AI Psychosis」。這個字指的不是AI 出了問題，而是人出了問題：建構Agent 循環本身會帶來強烈的智力快感，類似策略遊戲中不斷優化的正向回饋。開發者可能沉迷於打磨Agent 工作流程本身，不斷嘗試新的技巧、加入新的子Agent、優化Plan 的結構，而忘記了一個基本問題：你到底在為用戶交付什麼價值。工具變成了目的，需求被放在了第二位。

這三個問題指向同一個結論：plan.md 驅動的終端工作流程是為「清楚知道自己想要什麼」的人設計的效率放大器，不是為「還在摸索自己該做什麼」的人設計的學習工具。它的適用邊界不在於技術堆疊的選擇，在於使用者的階段。如果你是那個已經在紙上畫出完整系統架構的人，這套工作流程能讓你的執行速度快一個數量級。如果你還在透過動手寫程式來理解問題本身，那IDE 的視覺回饋體係就是你暫時不該丟掉的拐杖。

目前這套工作流程的核心組件包括運行環境層的Claude Code CLI 或Codex CLI、流程管理層的Compound Engineering 插件、技能擴充層的last30days-skill 和agentmail 等項目。它們都在快速迭代中，指令格式、檔案約定、插件體系存在變動的可能。現在入場的開發者需要接受一個事實：你踩的坑可能還沒有社區答案，因為整個鏈路還處在早期實踐階段，遠未達到「穩定工具鏈」的標準。但這恰好也是第一批趟路的人能建立認知優勢的窗口期。