Peter Steinberger：用 Codex 打造 OpenClaw 的實戰心法，從 AI Agent 使用技巧到重新定義軟體開發
在 AI Agent 改變軟體開發方式的這段時間，OpenClaw 創造者 Peter Steinberger 是非常值得研究的人物。
Peter 曾經花十多年打造 PSPDFKit，將它發展成具有數十名員工的軟體公司。出售股份、離開公司後，他經歷嚴重的職業倦怠，有一段時間甚至不想再碰電腦。後來，AI Coding Agent 讓他重新找回創造軟體的樂趣。他曾經以 Claude Code 作為主力工具，接著深入使用 Codex，並利用 Coding Agent 開發出 OpenClaw。
他最值得關注的，不只是能在短時間內寫出大量程式碼，而是如何把 AI Agent 當成真正的工程搭檔：讓它讀懂程式碼庫、討論設計、執行工作、檢查錯誤、更新文件，甚至協助維護 Agent 自己的原始碼。
Peter 在 Lex Fridman Podcast #491、2025 年的《Just Talk To It》以及 Startup School 2026 等公開分享中，詳細談過這套方法。最有趣的是，他的偏好與 Claude Code 創造者 Boris Cherny 並不完全相同。Boris 曾非常重視 Plan Mode，也介紹團隊使用 Worktree、Hooks 和 Skills 的習慣；Peter 則偏愛簡單對話、平行終端機、相同工作目錄與持續迭代。他同時也承認，自己的方法會隨模型的能力進步而改變。
這篇文章不是逐字稿，而是根據不同時間的訪談與 Peter 本人文章，整理其 AI Agent 使用經驗、Codex 與 Claude Code 的比較、實際操作技巧，以及 OpenClaw 發展過程中的成功與教訓。
一、從 PSPDFKit 到 OpenClaw：他熱愛的是創造，而不只是寫程式
Peter 多年來都是親手寫程式的工程師。他創辦 PSPDFKit，長期處理複雜的 PDF 軟體技術，也帶領過大型軟體團隊。但是在離開公司後，他陷入嚴重的職業倦怠，甚至花了很長一段時間遠離電腦。
當 AI Coding Agent 開始真正具備軟體開發能力，他又重新感受到創作的樂趣。後來他才明白，自己真正熱愛的是 Building，也就是把想法變成可以使用的產品，程式設計只是達成目的的方法。
一個讓人煩躁的小問題，催生出 OpenClaw
2025 年 11 月的一個下雨天，Peter 正讓多個 Coding Agent 同時工作。他起身去廚房找東西吃，回來卻發現其中一個 Agent 因為小問題卡住了。當時沒有方便的方法可以從手機傳送 Prompt，讓家裡的電腦繼續處理工作。
他開啟新的終端機，直接把構想交給 Coding Agent。大約一小時後，WhatsApp 與電腦間的雙向訊息中繼器就能運作了。它後來逐步支援更多通訊方式、記憶與工具操作，最終發展成 OpenClaw。
Peter 最初沒有龐大的商業計畫，只是想解決自己真正遇到的問題。他先成為產品的第一個使用者，再讓朋友試用。當朋友們對這個還很陽春的 Agent 產生驚喜甚至恐懼的反應，他才逐漸發現這件事可能有更大的市場。
到了 Startup School 2026，他仍然把「先做自己真的想用的東西」視為重要原則。他認為，在軟體愈來愈容易開發的時代，能讓人願意親自使用、持續改進的產品，比多寫幾個功能更重要。
二、從 Claude Code 走向 Codex：Peter 如何選擇工具？
Peter 早期非常喜歡 Claude Code。他在 2025 年初接觸這種透過終端機與模型協同開發的方式，後來甚至為了增加並行工作量，使用多個訂閱帳號。隨著模型進步，他逐漸減少使用傳統 IDE，通常只在需要閱讀 Diff 時才開啟。
到了 2025 年 10 月發表《Just Talk To It》時，Peter 表示自己已完全轉向以 Codex CLI 為日常主力。在後來的 Lex Fridman 訪談中，他也明確指出，即使自己創造了 OpenClaw，深入開發軟體時仍然大量使用 Codex。
這是一種工作流程偏好，不是永遠有效的模型排行榜。Peter 特別提醒，新模型需要時間熟悉，應該給自己一段完整的實際使用期，不要僅憑短短一次測試就判斷工具能力。
Codex：先讀懂系統，再長時間專心工作
Peter 認為，在他當時比較的 GPT-5.3 Codex 與 Claude Opus 4.6 之間，Codex 通常更願意先搜尋大量程式碼、理解架構，然後才開始實作。他偏好先與 Codex 深入討論設計方向，確定後讓它獨立工作，可能十幾分鐘、數十分鐘，甚至更久，不需要不斷進行社交式對話。
Claude Code：互動密集、創意強、迭代快速
Peter 並沒有否認 Opus 的優點。他認為 Opus 是非常強大的通用模型，擅長互動、語氣與創造性探索；如果使用者懂得引導，有時甚至可以寫出更有美感的程式碼。但在他當時的經驗中，Claude Code 比較容易急著開始動工，需要更多即時修正與討論。這是他個人的使用感受，也受到當時的模型版本與產品介面影響。
實際工作不是二選一
Peter 並不把 Codex、Claude Code 和 OpenClaw 當成完全相同的產品。他認為 Codex 適合長時間工程開發，OpenClaw 更像能透過手機與通訊軟體操作的個人助理；OpenClaw 甚至可以再喚醒 Codex 或 Claude Code 來執行專門的 Coding 工作。
三、Peter 的十五項 Agentic Engineering 實戰技巧
這些技巧主要整理自 Peter 的《Just Talk To It》與 Lex Fridman 訪談。它們反映 Peter 在不同時間的真實使用習慣，不是官方推薦的唯一標準配置，也不代表每個專案都應該照單全收。
技巧 1：先討論問題，不要讓 Agent 一收到需求就立刻寫程式
Peter 不喜歡為了每項工作建立長篇規格書或複雜的 Plan Mode 工作流。如果他尚未決定做法，通常直接用自然語言交代：「先討論一下」、「提出幾個方案，暫時不要修改檔案」，等選擇完成後再告訴 Codex 開始實作。
例如，可以先問：「讀取這個功能所涉及的檔案，整理目前架構、可能受影響的模組，以及兩到三種實作方案。先不要寫程式。」待方案明確，再要求它執行並驗證。這段文字是依照 Peter 方法整理的操作示例，不是他的逐字 Prompt。
他的核心不是反對規劃，而是認為規劃本身也可以透過簡單對話完成。遇到複雜問題，他一樣會花時間研究方案，必要時甚至要求第二個模型審查。
技巧 2：把 Agent 當成第一次進入程式碼庫的工程師
人類可能已經熟悉整個專案，但新的 Agent Session 可能完全不知道背景。數十萬行程式碼也不可能每次都完整放進 Context Window。
因此 Peter 會提供少量關鍵指引，例如提醒它修改某功能時，不要只看目前檔案，還必須閱讀另外兩個相依模組。他不是要替 Agent 決定每一行程式碼，而是用自己對系統的全局理解，協助 Agent 找到真正重要的上下文。
技巧 3：對於原始碼裡找得到的答案，要求 Agent 自己去查
有時 Agent 一開始會提出很多問題，Peter 會先判斷它們是否真的需要人類決策。如果答案應該存在於程式碼、設定檔或文件中，他會要求 Agent 多讀一些資料，先自己回答。只有涉及使用者真正的需求、風險偏好和產品取捨時，才需要人類拍板。
這樣可以減少無意義的反覆詢問，同時保留必要的澄清與人工判斷。不要讓 Agent 瞎猜，也不要替它回答本來可以自行查明的事。
技巧 4：用截圖傳遞介面需求，而不是寫冗長的 UI 說明
Peter 曾說，當時至少有一半的 Prompt 會附帶截圖。當他想修改某個網頁介面時，直接把截圖放進 Codex，再說明想改什麼。Agent 可以辨識畫面上的文字與元件，回到程式碼庫找到對應實作。
這使得原本必須用很多句話描述的畫面，可能只需要一張截圖加上一兩句指令。Peter 通常不會花時間精細標註，除非真的需要消除歧義。
技巧 5：大量使用語音 Prompt，但簡單的 Shell 操作照樣打字
Peter 是語音輸入的重度使用者，曾使用 Wispr Flow 等工具，直接用說話方式描述需求。他甚至開玩笑說，一度因為對 Agent 說太多話而喉嚨失聲。
但他沒有把所有操作都變成語音。切換目錄、執行短命令等事情，鍵盤仍然更快；語音最適合用在描述背景、討論設計與交代較複雜任務。
技巧 6：在終端機同時運行三到八個 Codex
在《Just Talk To It》中，Peter 分享自己習慣使用三乘三的終端機網格，讓三到八個 Codex Session 平行工作。某個 Agent 處理主要功能，其他 Agent 研究問題、修小 Bug、整理文件，或執行較小的相關工作。
他曾試過 Git Worktree，但對自己的日常工作方式來說，仍然偏好許多 Session 在同一個工作目錄中執行。這是與部分 Claude Code 團隊工程師很不同的選擇。
技巧 7：依據 Blast Radius 分派平行任務
Peter 很重視一項修改的「爆炸半徑」（Blast Radius），也就是它可能影響多少檔案、多少功能以及多少共用資源。如果好幾個 Agent 同時進行大型重構，Git Commit、測試與整合會變得難以管理。
他偏好一項較大的主要工作，搭配多項影響範圍小的任務。如果某個實驗可能改動大量架構，他仍然會將它放進獨立目錄。平行執行的價值，不是把 Session 開到最多，而是讓它們互不阻礙地前進。
技巧 8：使用原子化 Commit，讓 Agent 只提交自己的修改
當多個 Agent 共用工作目錄，每個 Agent 必須知道其他 Session 也可能正在修改檔案。Peter 因此不斷調整自己的 Agent 指示文件，要求 Codex 只提交自己變動的檔案，不要因為看到其他未提交的內容，就擅自重置或合併其他 Agent 的工作。
他也使用少量自訂命令，例如 /commit、/automerge 和 /massageprs，協助處理 PR 和 Git 操作。不過，他強調自己不常使用大量 Slash Commands，有時只要簡單輸入「commit」即可。
這種同目錄並行方式必須搭配嚴格的 Git 邊界與檔案歸屬管理；對不熟悉的生產環境，不應直接照搬而不先建立備份與隔離措施。
技巧 9：如果小任務異常耗時，按 Esc 中斷並詢問狀態
Peter 已建立一種直覺，能估計某項修改應該花多少時間、涉及多少檔案。如果看似簡單的 UI 微調卻讓 Codex 工作幾個小時，他會懷疑是不是方向錯了。
他的做法是按 Esc 暫停，問它目前在做什麼、為何花了這麼久。可能是 Agent 找錯專案、漏讀關鍵模組，也可能是架構本來就不適合直接加入這項功能。這時，重新討論通常比繼續燃燒 Token 有效。
技巧 10：審查 PR 時，先問「想解決什麼問題？」
Peter 處理大量 Pull Request 時，不一定從第一行程式碼開始閱讀。他常先要求 Codex 說明 PR 原本要解決的痛點，再問目前實作是不是最佳方案。
如果 Codex 沒有讀過相關模組，他就會指引它補足上下文，討論是否存在更好的架構。有時他選擇直接重構，而不是在設計較差的 PR 上不斷疊補丁。這讓 Code Review 回到需求和架構，而不只是檢查語法。
技巧 11：Code Review 是風險管理，不是平均閱讀每一行程式碼
Peter 曾說自己不再讀所有程式碼，但後來明確解釋：他指的是不再浪費時間讀每一段重複或低風險的程式碼。若只涉及 UI 小幅調整、畫面正確且測試通過，他可能很快就接受；涉及資料庫核心、重要架構、權限或陌生人提交的程式碼，就會仔細審查。
在 Startup School 2026，他進一步把這種選擇稱為風險管理，也特別說明他的私人開源專案與 OpenAI 內部工作流程標準不同；依照他當時的說法，OpenAI 的程式碼仍然會經過人工逐行審查。
技巧 12：完成功能後，立刻問「如果重做一次，會怎麼設計？」
Agent 在真正完成一項功能後，通常比一開始更加理解現有系統。因此，Peter 經常利用同一個 Session 追問：如果現在重新設計，是否存在更簡潔的方案？哪些模組需要立即重構？
這個問題能利用模型剛剛累積的上下文，找出第一次實作時沒有意識到的結構問題。他不喜歡每個階段都清空 Session，導致下一個 Agent 必須從頭閱讀程式碼。
技巧 13：趁上下文還完整，補齊測試與文件
Peter 不認為功能跑起來就可以結束。每完成一項功能或修正，他常要求 Agent 再檢查測試覆蓋率，尤其是容易忽略的 Edge Cases。文件也應該與功能同時交付：原理、模組位置、操作方式和重要設計取捨，應由剛做完工作的 Agent 趁記憶猶新時整理完成。
他的實作節奏是「討論、開發、測試、必要時重構、補充文件」，不必把每個階段都分給完全沒有共享上下文的 Session。
技巧 14：定期清理技術債，約五分之一時間花在重構
在 2025 年 10 月的個人文章中，Peter 估計自己當時約花 20% 的時間在重構，而實際的重構仍由 Agent 執行。工作包含利用 jscpd 找出重複程式碼、knip 搜尋未使用的檔案與依賴、eslint 檢查規則，以及整理大型檔案、更新相依套件、改善慢速測試與補齊文件。
AI 讓新增功能太容易，如果只是一直要求 Agent 加功能，從不整理架構，程式碼庫會越來越難以維護，反過來讓 Agent 更難找到正確的修改位置。
技巧 15：CLI 優先，MCP 只在真正有價值時使用
Peter 認為不少 MCP 只是在既有 CLI 外面再加一層包裝，不一定划算。例如 GitHub 已經有成熟的 gh CLI，Agent 可以直接閱讀說明並執行命令，不必載入大量 MCP 工具描述占用 Context Window。
這不表示他一概反對 MCP。當它能提供明顯不同的能力，例如瀏覽器除錯與互動測試時，他一樣會使用 chrome-devtools-mcp 等工具。重點是降低工具與上下文成本，而不是追求最多的整合介面。
四、進階工作法：第二個模型審查設計，但不要建立不必要的虛擬組織
在較困難的架構工作中，Peter 會先與 Codex 討論需求，必要時讓 Codex 整理成規格文件，再交給另一個高能力模型審查，看看是否有更好的方案。最後挑選有價值的建議放回原本的 Session。
這不代表每一件事都必須啟動固定數量的 Agent、設定虛擬 CEO、CTO 或建立複雜的編排流程。Peter 曾試用多種 Agent Framework，但他認為很多產品只是在彌補當時模型的限制；模型愈聰明，愈應該重新問自己是否仍然需要那些框架。
他也重視可見性。相較於將研究藏在大量難以追蹤的 Sub-agent 裡，早期的 Peter 有時更喜歡直接開另一個終端機視窗，清楚看見它載入了什麼上下文，以及研究到哪一步。
五、從不用 Worktree 到調用十二個 Sub-agent：方法為何會改變？
Peter 的觀點不是「Sub-agent 永遠不好」，而是反對在不必要的情況下硬套複雜架構。
在 Startup School 2026 的問答中，他分享自己前一天讓 Codex 調用了 12 個 Sub-agent，先分析整個專案，再拆解不同功能模組，分別執行壓力測試與 Code Review。這些 Agent 會把檢查結果回報給其他 Session，協助判斷哪裡值得更深入測試。
當模型具備更成熟的任務分解與協調能力，這種多 Agent 工作就可能變得實用。差異在於，主 Agent 能根據實際任務安排合作，而不是人類為每項工作預先規定一套僵化的虛擬部門架構。
但 Peter 也提醒，自動化測試無法完整取代人類親自體驗軟體。UI 的手感、互動是否自然、產品是否真的有趣，仍然需要人親手操作。
六、Session、Context 與運算資源：真正的瓶頸可能不在模型
Peter 不傾向在每次完成工作後就清空上下文。他認為，如果 Session 已經讀懂大量關鍵模組，而且討論、實作、測試正在同一個主題上持續推進，這些上下文就是有價值的資產。
到了 Startup School，他更傾向讓每個 Session 對應一個明確主題，而不是不斷建立毫無背景的新對話。但是如果上下文已經混亂、偏離問題或成本過高，也應該整理或重啟。
當大量 Agent 同時執行工作，Peter 認為運算資源管理會成為重要瓶頸。例如某項測試一口氣使用十多個執行緒，如果多個 Session 同時跑，電腦就可能因資源不足而逾時。針對 macOS 原生應用，雲端 Linux 環境也無法直接取代所需的測試設備。
他曾使用一直開著的工作室電腦，透過 Jump Desktop 或其他遠端工具存取，避免筆電必須長時間維持運轉；也為了讓 Agent 執行 GUI 操作不干擾自己，使用獨立機器。這些技巧背後的重點不是某種硬體品牌，而是讓 Agent 有合適的執行環境，並避免人與 Agent 爭奪同一個桌面。
七、OpenClaw：從手機傳送一句話，到軟體自己修改自己
Peter 讓 OpenClaw 知道自己使用的模型、工具、執行架構、文件和程式碼位置，因此它能在適當授權下研究自己、分析錯誤，甚至修改自身原始碼。
他在 Lex Fridman 訪談中分享，除錯時會直接問 Agent：「你現在可以使用哪些工具？你能試著呼叫嗎？你看到了哪些錯誤？讀一下原始碼，找出可能原因。」這是一種由軟體本身參與維護的工作方式，但仍需要版本控制、測試與權限邊界。
一則意外的 WhatsApp 語音訊息
Peter 曾不經意傳送一則語音訊息，Agent 卻自行分析收到的檔案、尋找可用工具、完成語音處理並回覆。這個瞬間讓他感到真正神奇：他沒有為每一種可能的操作預先準備固定功能，Agent 卻能使用現有工具組合出解法。
Codex 負責深入開發，OpenClaw 負責生活與任務協調
Peter 清楚區分長時間的軟體開發與個人助理場景。遇到需要數小時專注開發的任務，他喜歡坐在大螢幕前操作 Codex；需要在手機上隨時交代工作、調查 GitHub 連結或處理生活任務時，OpenClaw 則比較自然。OpenClaw 甚至可以將工作交給 Codex 或 Claude Code 等 Coding Agent。
這意味著未來的個人 Agent，不只是聊天視窗，而可能成為呼叫各種專門工具與 Agent 的協調層。
八、OpenClaw 爆紅後的教訓：功能愈容易加，愈需要說不
OpenClaw 從個人作品快速成長為大型開源專案，Peter 卻發現自己被大量 Issue、PR、資安回報、媒體採訪與行政工作占滿。他甚至一度不再使用自己最初熱愛的產品。
在 Startup School，他承認曾經接納太多新功能，為了保持相容性又增加大量設定選項，使測試和維護變得極為複雜。他以當時約 9,500 種配置組合為例，說明即使程式碼由 Agent 快速產生，也不代表維護成本會消失。
因此，他在後來的新開源專案中會建立 vision.md，說明產品定位與期望方向。新的功能即使很酷，也不一定適合加入核心；有些需求更適合做成外掛、擴充功能或獨立 Skill。
資安不能只靠 Markdown Prompt
在 OpenClaw 早期，Peter 曾透過 agents.md 告訴 Agent，除非指令來自自己，否則不要執行危險工具操作。但當專案面對真實攻擊與大量使用者後，他投入更多資源建立 Sandbox、白名單、權限機制和檔案存取限制。
這是很重要的教訓。Prompt 可以引導行為，但不能取代作業系統層級的安全邊界。個人實驗階段願意承擔的風險，不能不加區分地移植到正式營運服務。
使用者依賴的模型供應商，也會影響產品命運
Peter 說過，OpenClaw 雖然主要利用 Codex 和 GPT 建立，但它的 Harness 一度高度針對 Opus 最佳化。當模型供應商的訂閱與使用條件變動，就可能影響產品可用性與使用者體驗。他因而更加重視不同模型與執行環境的相容性。
但這不代表他拒絕先進雲端模型。真正的問題是：如果你的產品依賴某種模型使用方式，也必須把供應商的政策與商業條件視為架構風險。
九、永遠運作的 Agent，還需要學會避免浪費資源
Peter 認為，高度自主的 Agent 在技術上愈來愈可行，但「始終保持運作」不代表「始終消耗大量 Token」。
他提到早期 Heartbeat 設計不夠精緻。如果一個擁有龐大 Context 的 Session 被定時喚醒，在快取失效之後重新載入全部上下文，可能只是為了確認沒有新工作，卻浪費驚人的運算量。
未來的 Agent 系統需要更聰明的觸發條件、記憶管理、計算資源調度、停止條件與任務優先順序。簡單說，就是先判斷「值不值得做、值不值得現在做」，再決定是否啟動模型。
他還提到 Loop、Graph、Workflow 等名詞，核心仍然是自動化：接收事件、獲取輸入、進行必要判斷、執行動作、觀察結果。Agent 讓這些自動化流程更有彈性，但沒有改變工程師一直以來想讓系統替自己工作的基本目的。
十、他為什麼不主張把產品開發全部交給全自動流程？
Peter 希望 Agent 能自主完成更多工作，卻不贊成人類從產品創造過程中徹底消失。他認為最好的產品，往往不是預先寫出龐大規格後一次生成，而是先做小原型、親自使用、感受缺陷、突然產生新的點子，然後快速迭代。
他不認為 Agent 能夠替開發者完成所有品味、趣味和產品取捨。哪些功能值得加入核心、怎樣的互動才讓人開心、什麼時候該停止加功能，這些仍然是創造者的重要工作。
這也解釋了他為何會讓 Agent 大量寫程式，卻仍親自玩產品，甚至願意在覺得不好玩時重新思考整個方向。
十一、Peter 與 Boris Cherny：兩種不同的 AI Agent 工程哲學
兩人都非常了解傳統軟體工程，也都樂於把大量程式碼交給 Agent。但他們的個人風格不完全相同。
Boris 早期曾強調 Plan Mode，Claude Code 團隊則分享 Worktree、Hooks、Skills 和多種自動化做法。Peter 更偏好直接討論、不固定使用 Worktree，並利用截圖、語音與終端機視窗保持快速迭代。
兩人都重視驗證，但 Peter 特別強調要按風險決定 Code Review 深度，以及讓自己親自感受產品品質。他也不排斥 Sub-agent，卻認為不能為了架構而架構。
這不是誰比較厲害的問題，而是說明一件事：在模型能力快速進步的環境中，連最頂尖的開發者也不斷修改自己的方法。真正值得學習的不是照抄某一套工具配置，而是理解每種做法為何在當時有效。
十二、Fun Is Velocity：當軟體很容易開發，專注才真正稀缺
在 Startup School 2026，Peter 用一句話形容他的核心心得：Fun is velocity，好玩就是速度。
當他興奮地打造自己真正想用的工具，往往能以驚人速度持續交付；當大量外部需求與行政工作讓他遠離創造的樂趣，產品反而停滯在愈來愈繁複的設定選項裡。
Peter 認為，未來最困難的不一定是撰寫程式碼，而是找到值得解決的問題、維持注意力、判斷產品該往哪裡走，以及讓使用者真的喜歡它。
他曾經以為自己愛的是寫程式，後來才發現他更熱愛創造。AI Agent 讓程式設計的技術門檻降低，卻沒有自動替人類解決產品價值、信任、體驗和長期維護等問題。
當 Coding Agent 能替人類完成越來越多實作，創造者真正重要的能力，反而是理解自己想創造什麼，並且持續把它打磨成值得使用的產品。
參考訪談與資料
本文依據以下來源整理，不是 Peter 原始訪談的逐字轉載。個別工作方法、模型名稱、數字與產品功能，應以當時發表時間理解；正式使用工具前仍須確認最新文件。
- Peter Steinberger：Startup School 2026 訪談（站長先前保存之中文逐字稿）
- Y Combinator／Root Access：What Happens When Everyone Lets It Cook（2026-08-10）（另開新分頁）
- Lex Fridman Podcast #491：Peter Steinberger／OpenClaw 完整訪談（另開新分頁）
- Peter Steinberger：Just Talk To It — The No-BS Way of Agentic Engineering（2025-10-14）（另開新分頁）
- Peter Steinberger：About（人物與職涯資訊）（另開新分頁）
