OpenClaw 創辦人公開嘅 AI 寫 Code 10 條原則
GitHub 有史以來最快攞星項目嘅創建者 Peter Steinberger 分享同 AI 編程代理協作嘅 10 條實戰原則。
睇完 OpenClaw（舊名 Clawdbot）創辦人 Peter Steinberger 嘅訪談之後，我真係受到唔少衝擊。佢亦係 GitHub 有史以來攞星速度最快嘅項目嘅締造者。
Peter 係一個經營咗 13 年 60-70 人公司、賣咗之後休息咗三年再返嚟嘅資深開發者。佢講嘅 AI 時代開發，同我哋大部分人嘅認知完全唔同。
簡單嘅開始
一開始冇咩宏大嘅商業計劃。佢只係抱住「玩下 AI」嘅心態起步，因為想喺出街嗰陣透過 WhatsApp 同屋企部電腦傾偈，所以就整咗呢個工具。
決定性嘅頓悟時刻
轉捩點發生喺一次旅行。佢畀代理發咗條語音訊息，但佢從來冇寫過語音支援功能。點知代理自己辨識咗 Opus 檔案格式，搵到 ffmpeg 做轉換，定位到 API 金鑰，完成咗轉錄同翻譯，然後將回覆發返嚟。嗰一刻佢意識到，代理係「聰明又識變通嘅野獸」。
基於呢啲經歷，Peter 歸納咗 AI 寫 code 嘅 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 條原則指向嘅方向只有一個：放低完美主義、用架構討論代替程式碼審查、畀代理自行驗證、同時開多個代理。
呢啲全部都收斂於「打造一個開發者唔使親手寫 code 嘅環境」。AI 時代真正嘅實力唔係寫好 code，而係設計一個唔寫 code 都可以解決問題嘅體系。
參考資料：
訂閱通訊
獲取關於我最新項目、文章同埋 AI 和 Web 開發實驗嘅更新。