OpenClaw 創辦人公開的 AI 程式開發 10 項原則

看完 OpenClaw（前身為 Clawdbot）創辦人 Peter Steinberger 的訪談後，我受到了相當大的衝擊。他也是 GitHub 有史以來獲星速度最快的專案締造者。

Peter 是一位經營了 13 年 60-70 人公司、完成出售後休息了三年再復出的資深開發者。他對 AI 時代開發的理解，與我們大多數人的認知截然不同。

簡單的開端

一開始並沒有什麼宏大的商業計畫。他只是抱著「玩玩 AI」的心態起步，因為想在外出時透過 WhatsApp 和家裡的電腦對話，所以做了這個工具。

決定性的頓悟時刻

轉折發生在一次旅行中。他給代理發了一則語音訊息，但他從來沒寫過語音支援功能。結果代理自己辨識了 Opus 檔案格式，找到 ffmpeg 進行轉換，定位到 API 金鑰，完成了轉錄和翻譯，然後把回覆發了回來。那一刻他意識到，代理是「聰明且足智多謀的野獸」。

基於這些經歷，Peter 歸納了 AI 程式開發的 10 項原則。

放下完美主義才能與 AI 協作

管理 70 人團隊的經驗讓他學會了接受不符合自己風格的成果。程式碼和你的偏好不完全一致但能正常運作，那就夠了。這種彈性成為了他與代理協作時最大的資產。

讓代理自行驗證工作成果

Peter 把這稱為「閉合迴圈（Close the loop）」。編譯、lint、執行、驗證 - 全部由代理自己完成。人類在中間確認的環節會成為瓶頸，拖慢整體速度。

Pull Request 已死，Prompt Request 時代來了

程式碼本身不如產生程式碼的 prompt 重要。外部 PR 基本拒絕，只擷取核心想法重新做成 prompt。他的兄弟也用同樣的方式工作 - 說明這個模式已經在擴散。

用架構討論取代程式碼審查

即使在 Discord 上，核心團隊也不討論程式碼細節。他們只討論系統架構、重大決策和方向。實作細節是代理的事 - 這個觀念已經深入整個團隊。

同時運行 5 到 10 個代理

不在單一任務上死磕，而是把多個任務並行排隊。擬定計畫、交給代理，馬上轉到下一個。Peter 說這樣才能保持「心流狀態」。

在規劃階段投入驚人的時間

和代理充分來回溝通，打磨計畫。質疑、修改、反駁、直到滿意為止。他偏好用 Codex 而非 Claude Code 來執行，因為 Claude Code 會在運行中提確認問題，打斷心流。計畫夠扎實，執行階段幾乎不需要介入。

故意給出模糊指令

指令太具體會讓 AI 只在那個範圍內行動。有意留出空間，讓代理發現你沒想到的方向。親自試過後發現確實有效 - 經常會出現意想不到的解決方案。當然不需要每次都這樣做。

別等遠端 CI 的 10 分鐘，本地直接測試

遠端 CI 流水線等 10 分鐘太浪費了。設計系統讓代理在本地直接跑測試。回饋迴圈越短，迭代速度越快。

絕大多數程式碼不過是無聊的資料轉換

應用程式碼的大部分就是「把資料從一種形式轉換成另一種形式」。沒必要執著於這些，交給代理就好。精力應該放在系統設計上，而不是資料搬運上。

喜歡發布產品的人更容易適應 AI

喜歡解演算法題的開發者反而在 AI 轉型中更吃力。比起實作細節，更關心成果和發布的人適應得更快。這是我在身邊經常觀察到的規律。

Peter 的未來展望

他預測無數應用會消失，只留下 API。不需要打開 MyFitnessPal 手動輸入，只要給代理發一張食物照片，它就會自動計算卡路里並調整你的健康目標。

總結

可以有各種爭論，但 Peter 的 10 項原則指向的方向只有一個：放下完美主義、用架構討論代替程式碼審查、讓代理自行驗證、同時運行多個代理。

這一切都收斂於「打造一個開發者不必親自寫程式碼的環境」。AI 時代真正的實力不是寫好程式碼，而是設計一個不寫程式碼也能解決問題的體系。

參考資料：

• Peter Steinberger 訪談（上）
• Peter Steinberger 訪談（下）