OpenClaw 作者 Peter Steinberger 如何看 AI 軟體開發？從 OpenClaw 到閉環編程

Sun, 17 May 2026 20:02:26 +0800

Peter Steinberger 的經歷很適合用來觀察 AI 軟體開發正在發生什麼變化。

他不是「突然被 AI 帶火的新人」。在 OpenClaw 之前，他已經是 PSPDFKit 的創辦人，長期做 PDF 渲染、文件處理和開發者工具。這類產品很難靠概念包裝取勝，必須面對效能、相容性、API 設計、企業客戶和長期維護。

所以，當 Steinberger 後來用 AI 工具做出 OpenClaw，並圍繞 AI Agent、個人自動化和 AI 編程發表觀點時，重點不只是「一個人寫了很多程式碼」。更值得看的，是他把多年軟體工程經驗和新一代 AI coding agent 結合後，對開發流程的重新理解。

AI 編程不是魔法按鈕

很多人討論 AI 編程時，會把它簡化成兩個極端。

一種說法是：AI 已經能寫程式碼，程式設計師快沒用了。

另一種說法是：AI 寫的程式碼不可靠，真正工程還是得靠人手寫。

Steinberger 的經驗更接近第三種：AI 讓軟體開發的操作單位變了，但沒有取消工程判斷。

過去，開發者主要以「編輯程式碼」為中心工作。需求拆解、架構判斷、寫實作、跑測試、修 bug，都圍繞人工修改程式碼展開。

AI coding agent 介入後，開發者越來越像在管理一個執行系統：

說明目標。
提供上下文。
約束邊界。
讓 agent 修改程式碼。
執行測試和檢查。
根據結果繼續迭代。

這不是簡單把鍵盤交給模型，而是把人從「每一行都親手敲」轉到「定義方向、設計回饋、判斷結果」。

為什麼他不喜歡把這叫 vibe coding

圍繞 Steinberger 的討論裡，一個高頻詞是 vibe coding。

這個詞原本用來形容一種新開發方式：開發者用自然語言描述想法，讓 AI 生成大量程式碼，再透過執行結果和回饋不斷調整。

但 Steinberger 對這個詞並不完全買帳。公開報導中提到，他認為 vibe coding 容易變成一種貶義表達，暗示 AI 輔助開發只是「憑感覺亂生成」，忽視了背後的技能、判斷和經驗。

這個批評有道理。

真正有效的 AI 編程並不是隨便輸入一句話，然後相信模型輸出。它需要：

能把模糊需求拆成可執行任務。
能識別模型是否誤解了目標。
能設計測試和驗收標準。
能判斷程式碼結構是否會影響長期維護。
能知道什麼時候應該停止生成、轉向人工審查。

換句話說，AI 降低了寫程式碼的摩擦，但沒有降低理解系統的責任。

閉環才是關鍵

Steinberger 相關訪談和文章裡，經常被總結出的一個核心思路是「閉環」。

只讓 AI 生成程式碼，是開環。

讓 AI 生成程式碼、執行程式碼、讀取錯誤、修復問題、再執行測試，才更接近閉環。

這個差別非常重要。

開環生成很容易製造表面可用的軟體。頁面能打開，功能看起來有，程式碼也不少，但一旦進入真實場景，就會暴露狀態管理、權限、異常處理、邊界條件和部署問題。

閉環開發要求輸出必須被回饋約束。最簡單的閉環是：

寫清楚目標。
讓 AI 修改程式碼。
自動執行測試、型別檢查、lint 或構建。
把錯誤回饋給 AI。
重複直到通過。
最後由人審查關鍵路徑。

這也是 AI 軟體開發真正能提高效率的地方。不是因為模型一次就寫對，而是因為它可以快速參與「生成、驗證、修復」的循環。

經驗越多，越能用好 AI

AI 編程最容易產生的誤解之一，是「經驗不重要了」。

Steinberger 的案例反而說明，經驗會變得更重要，只是作用方式變了。

一個有經驗的工程師更容易判斷：

哪些任務適合交給 agent。
哪些模組需要先寫測試。
哪些改動風險太高，不該讓 AI 大範圍重構。
哪些生成程式碼只是看起來合理。
哪些問題應該透過架構調整解決，而不是繼續補丁式修復。

AI 可以生成大量候選方案，但候選方案越多，越需要判斷力。沒有經驗的人可能會被「能跑起來」迷惑，有經驗的人更會追問：能不能維護？能不能擴展？會不會破壞安全邊界？出了問題能不能定位？

這也是為什麼 AI coding agent 並沒有讓軟體工程變成純聊天。它更像把一部分執行勞動外包出去，同時放大了規劃、審查、驗證和取捨的重要性。

OpenClaw 的意義不只是專案本身

OpenClaw 被關注，不只是因為它是一個開源 AI agent，也不只是因為它的增長速度快。

它更像一個信號：開發者開始希望 AI 不只回答問題，而是能接入真實工具，完成真實動作。

傳統聊天機器人停留在對話框裡。它可以解釋程式碼、寫草稿、給建議，但很多時候還需要人複製、貼上、打開軟體、執行命令。

Agent 的方向是把模型接到工具上：

檔案系統。
瀏覽器。
終端。
郵件。
日曆。
第三方服務。
專案倉庫。

一旦模型能使用這些工具，軟體開發的邊界就會變化。AI 不再只是「程式碼補全」，而會參與專案閱讀、任務拆解、檔案修改、測試執行、PR 整理和工作流自動化。

這也是 Steinberger 加入 OpenAI 後被關注的原因。他代表的不是單個開發者故事，而是一種產品方向：個人 agent 會從演示玩具走向日常工作層。

這對普通開發者意味著什麼

對普通開發者來說，Steinberger 的經驗不一定能直接複製。

不是每個人都能同時管理多個 agent，不是每個專案都適合高強度 AI 生成，也不是每個團隊都能接受「先生成再快速迭代」的節奏。

但有幾件事值得學。

第一，先把任務寫清楚。

AI 對含糊目標很敏感。你說「優化一下」，它可能改風格、改結構、加功能、刪邏輯。你說「把登入失敗時的錯誤提示從英文改成中文，不改變認證流程」，結果通常更可控。

第二，把驗證命令固定下來。

如果一個專案沒有測試、沒有構建命令、沒有 lint，AI 就很難形成閉環。哪怕只是最基礎的 npm test、go test ./...、pytest、hugo，也比完全靠肉眼檢查強。

第三，控制改動範圍。

一次只讓 AI 處理一個模組、一個 bug、一個頁面，通常比讓它「重構整個專案」更可靠。

第四，保留人工審查。

尤其是認證、支付、權限、資料刪除、部署腳本、資料庫遷移、安全配置這些地方，不要因為程式碼是 AI 生成的就降低審查標準。

第五，復盤 prompt 和失敗模式。

如果 AI 經常誤解某類任務，就把約束寫進專案規則、agent instructions 或技能檔案。AI 編程能力不是只來自模型，也來自你給它搭建的工作環境。

AI 軟體開發會走向哪裡

Steinberger 的故事說明，AI 軟體開發正在從「輔助寫程式碼」走向「組織軟體生產流程」。

早期 AI 編程工具的價值主要是補全函式、解釋報錯、生成模板。現在的變化是，agent 可以跨檔案工作，可以呼叫工具，可以執行檢查，可以根據回饋繼續修復。

這會帶來幾個趨勢：

第一，個人開發者的產能上限會提高。

一個人可以同時推進更多原型、腳本、內部工具和小型產品。但產能提高不等於品質自動提高。越快生成，越需要驗證。

第二，專案結構會更重要。

程式碼越清晰，測試越明確，文件越完整，AI 越容易正確修改。混亂專案對人難，對 AI 也難。

第三，軟體工程師會更像工作流設計者。

未來重要的不只是會不會寫某門語言，而是能否把需求、上下文、工具、測試、部署和權限組織成一個可控循環。

第四，安全邊界會更敏感。

Agent 能做事，就可能做錯事。它能讀檔案、執行命令、存取服務，也意味著權限、審計和回滾會成為 AI 開發環境的基礎設施。

小結

Peter Steinberger 的 AI 軟體開發觀，最有價值的地方不是「AI 生成了多少程式碼」，而是他展示了一種新的開發姿勢。

人不再只是在編輯器裡逐行輸入，而是在設計目標、管理 agent、構造回饋迴路、審查結果和調整系統。程式碼仍然重要，但程式碼不再是唯一的勞動中心。

如果說傳統軟體開發強調「把程式碼寫對」，AI 軟體開發會更強調「讓系統持續產出可驗證的正確結果」。

這不是降低工程門檻那麼簡單。它是在改變工程能力的形態：從手工實作，轉向任務分解、上下文管理、工具編排、自動驗證和最終判斷。

Peter Steinberger on KnightLi的博客