@mvanhorn：我所知道的每一項 Agentic 程式開發技巧（2026 年 6 月） 三個月前，我發布了《我所知道的每一項 Claude Code 技巧》，獲得了 91…

我所知道的每一項 Agentic 程式開發技巧（2026 年 6 月）

三個月前，我發布了《我所知道的每一項 Claude Code 技巧》，獲得了 91 萬 3 千次觀看。當時 @kevinrose 問我該用什麼 IDE，我的回答是：「不需要 IDE。只要有 plan.md 檔案和語音輸入就夠了。」

這過去被稱為「Vibe Coding」。大約在去年感恩節前後，模型能力已經強大到讓這些玩具般的工具變得實用，也就是現在大家所說的「Agentic 程式開發」。這是我能持續產出的唯一原因。今年我發布了 last30days（2.7 萬顆星）、Printing Press（4 千多顆星），以及剛上線的 Agent Cookie，並成為了一些開源界最大專案的頂級貢獻者：Python、Go、GStack 和 Paperclip。自從高中畢業後，我就沒再寫過什麼有價值的軟體了。以下就是我的技巧。

HACKS

YOLO TL;DR 技巧：將整篇文章貼給你的 Agent，告訴它根據內容規劃並設定好所有項目，然後一個一個技巧地執行。這就是我的整套堆疊，完全不需要自己閱讀。

一有想法，立刻建立一個 CE plan.md

這依然是第一守則，也是我學到最重要的事情。

當我一有想法，就會執行 /ce-plan 來建立一個 plan.md。不是「讓我思考一下」，也不是「讓我開始寫程式」。每次都是 /ce-plan。它也支援圖片，所以任何你能捕捉到的東西都是起點：

瘋狂的產品點子：/ce-plan。
GitHub 上的 Bug：複製 Issue 連結，貼上，/ce-plan。
終端機錯誤：按下 Cmd+Shift+4 截圖，Ctrl+V 貼上，/ce-plan fix this。
截圖、錯誤訊息、設計草圖、Slack 對話串：通通丟進去。

當想法還很模糊，連我自己都不知道要什麼時，我會先用 /ce-brainstorm 與 Agent 一起梳理，等想法清晰後再執行 /ce-plan。

在底層，/ce-plan 會並行展開研究型 Agent。一個負責閱讀你的程式庫、找出模式並檢查你的規範；另一個搜尋你過去的解決方案以獲取經驗。如果主題需要，還會有更多 Agent 去研究外部文件和最佳實踐。這一切同時進行，然後整合並寫出一個結構化的 plan.md：問題是什麼、解決方法、需要修改哪些檔案、帶有核取方塊的驗收標準，以及從你自己的程式碼中提取的模式。這一切都基於你的儲存庫、你的規範、你的歷史紀錄，而不是通用的建議。

/ce-work 會根據該計畫進行建置。Context 爆掉了？開啟一個新 Session，指向該計畫，從上次中斷的地方繼續。計畫就是那個能存活於任何狀況下的檢查點。

傳統開發是 80% 寫程式，20% 規劃。這完全反過來了。思考過程都在計畫裡，執行則是機械化的。

來自 @kieranklaassen 和 @trevin 的 Compound Engineering 是讓這一切成真的 plugin。

我成了它的超級粉絲，接著成為貢獻者，現在我是核心團隊之外的第三大貢獻者。我現在的規則是：除非真的只是改一行程式碼，否則一定要先有 plan.md。

HACKS

安裝 Compound Engineering：/plugin marketplace add EveryInc/compound-engineering-plugin
貼上截圖、Bug 連結或錯誤訊息，然後執行 /ce-plan，接著 /ce-work。
想法模糊？先執行 /ce-brainstorm。

不要去讀 plan.md

我總是會建立 plan.md，但我幾乎從不閱讀它。計畫是給 Agent 看的，你這個傻瓜。

強迫計畫存在會讓 Agent 不會偷懶。這會讓它們進行研究、承諾一種方法、寫下驗收標準，然後確實達成。一個有計畫的程式開發 Agent 能交付完成的工作，沒有計畫的 Agent 則會偷工減料並提早結束。計畫就是韁繩。

所以我讓它寫計畫，我只掃一眼標題，然後執行 /ce-work。如果有疑問，我會在 Session 裡直接問：「等等，為什麼選這個方法？」或者要求一個 TLDR。又或者，當我不理解時，我會說：「eli5 this plan（用五歲小孩聽得懂的方式解釋這個計畫）。」我看完那一段話，點點頭，繼續工作。我不會坐在那裡讀 300 行 Markdown。那是 Agent 的家庭作業，不是我的。

建立計畫，信任計畫，不要讀計畫。

HACKS

不要讓自己去讀計畫。直接在 Session 裡問：TLDR？、eli5 this plan，或是「等等，為什麼選這個方法？」

將 /ce-plan 用於你最深度的非工程工作，為計畫本身做個計畫

人們以為 /ce-plan 和 /ce-work 只是用來寫程式的。自三月以來我學到最重要的一點是：並非如此。我現在進行的最深度知識工作都跑在同樣的迴圈裡，訣竅在於讓第一個計畫成為「計畫的計畫」。這也不是我強迫程式工具去做它不擅長的事：/ce-plan 內建了一種通用的規劃模式，正是為了這類非程式工作而設計的。

這不僅限於商業問題。策略文件、產品規格、競爭分析、董事會更新，通通適用同一個迴圈。

這是一個真實案例。我與前 GV 研究合夥人 Michael Margolis 見面，他以「靶心客戶法（bullseye-customer method）」聞名，我們討論了一個我正在醞釀的商業挑戰。他叫我讀他的書，網上有免費 PDF。過去的做法是掃一眼然後就忘了。但我打開了 Claude Code 並大約這樣說：

「/ce-plan 為這個計畫做個計畫。我即將給你兩樣東西：Margolis 的書（PDF 格式），以及我剛才與他開會的兩小時 Granola 逐字稿，裡面有我們討論的完整背景。我想要一個深思熟慮的計畫，說明如何將我的商業問題、那場對話以及書中的教訓結合起來，變成我真正能用的東西。現在先不要寫那份文件，寫文件是後續的工作。現在我只需要一個計畫，說明你將如何閱讀這本書、挖掘逐字稿，並產出一份優秀的文件。」

它花了接下來 45 分鐘建立了一個史詩級的計畫。

這也是我知道讓 LLM 不偷懶的唯一最佳技巧。直接要求產出成果，它就會偷工減料。要求它先規劃如何產出成果，然後執行該計畫，它每次都會產出深度版本。

HACKS

深度非程式工作：/ce-plan 為計畫做個計畫，將所有背景資料和逐字稿交給它，然後執行 /ce-work。

擁抱語音輸入

語音轉 LLM 與語音轉其他任何東西都不同。轉錄內容不需要完美，因為聽者理解上下文。它會猜測麥克風收錄錯誤的部分。你可以含糊不清、說到一半停下、重新開始一句話。語音之所以終於好用，是因為另一端的東西夠聰明，能填補這些空白。

我的設定：

Mac：Monologue (來自 Every) 或 Wispr Flow。選一個，將語音輸入到任何聚焦的應用程式，對著 Claude Code 說話。我在辦公室買了一個鵝頸麥克風。

手機：跳過 Monologue 和 Wispr Flow，在 iOS 上切換太麻煩了。Apple 內建的聽寫功能就夠用了，因為你是在跟 LLM 對話，而不是人類。它可以搞砸一半的字，但 Agent 還是聽得懂。隨意的筆記沒問題。

老實說：我獨處時很擅長語音輸入。在辦公室裡我卻很掙扎。人們說你可以對著麥克風小聲說話，但我發現我實際上做不到，因為我不想顯得沒禮貌或打擾周圍的人。所以共享辦公室裡的辦公桌仍然是我這套工作流程的弱點。如果你在開放式辦公室裡解決了語音輸入問題卻又不顯得突兀，請告訴我怎麼做。我是真心想請教。

HACKS

Mac：安裝 Monologue 或 Wispr Flow。手機：使用 Apple 聽寫。買個鵝頸麥克風。

在 cmux 中開啟大量分頁

這就是我一天實際的度過方式。四到六個 cmux 分頁，有時更多，每個都是獨立的 Session：

一個在寫計畫。
一個根據另一個計畫進行建置。
一個在跑 last30days。
一個在修復測試上一個東西時發現的 Bug。

當 /ce-plan 在一個視窗中啟動研究時，我會切換到另一個視窗，對已經寫好的計畫執行 /ce-work。當那個在建置時，第三個視窗會貼入一個新的 Bug。等我繞回來時，第一個已經完成並在等待了。

我聽說 Orca 在行動端工作方面做得很好。我也曾是 Ghostty 的死忠擁護者，但在 Ghostty 中我漏掉了太多通知。

HACKS

使用 cmux。
保持 4 到 6 個分頁開啟，每個分頁處理不同的任務。

將終端機預設為 Claude 或 Codex，而不是 Shell

新分頁應該直接開啟 Claude Code，而不是 Shell。開啟分頁，你就在跟 Agen…

Видео @mvanhorn：我所知道的每一項 Agentic 程式開發技巧（2026 年 6 月） 三個月前，我發布了《我所知道的每一項 Claude Code 技巧》，獲得了 91… канала easyvibecoding