AI 加速的關鍵是把人放進控制迴路
我在 LMM Labs 讀到一個很值得拆解的早期案例：兩人團隊用 ChatGPT 協助討論與草擬，讓 Codex 檢查 repository、修改檔案、執行測試和診斷，最後由人明確核准後才透過 GitHub Actions 部署到 Azure。33 天內，作品集從 8 個增加到 14 個，其中 12 個有雲端部署證據，檢查點累積 574 個 passing tests，4 次成功部署耗時 2 分 09 秒到 9 分 41 秒。這些數字很吸引人，但我更在意它暴露出的系統設計。
這不是把一個聊天機器人接到 CI 就結束，而是把工作切成三種不同的權限。人負責定義問題、驗收條件和發布決策，模型負責把模糊討論轉成候選實作，Codex 則在可檢查的程式環境裡操作，CI 用測試與部署紀錄留下證據。換句話說，模型的自主性被放在執行層，人類仍掌握規格層與風險閘門。這種分工比單純追求更大的上下文或更強的 agent 更接近可維護的工程架構。
從 NLP 系統的角度看，最重要的瓶頸不是生成速度，而是規格能否被轉成可驗證的觀測量。人說「這個功能可以上線」仍然太含糊，必須落成測試案例、錯誤邊界、部署健康檢查與回滾條件，模型才有機會在有限範圍內高品質工作。574 個通過測試的價值也不只是數量，它們把模型輸出的不確定性，轉換成團隊可以反覆檢查的介面。不過，測試通過不等於需求正確，未覆蓋的情境、錯誤的資料假設，以及使用者體驗仍需要人工判斷。
這個案例對小團隊的可複製做法，是先建立三道閘門：第一道由人寫出可判定的完成條件，第二道讓模型只能在分支和沙盒中修改並提交證據，第三道把部署權限設成明確的人工核准。每次失敗都要記錄是規格、工具、程式還是環境造成，否則只會把偶然成功誤認成流程能力。LMM Labs 也特別提醒，這些成果不能直接推導出總開發時間縮短多少，或 AI 帶來多少百分比效益。我認為這個保留反而是案例最成熟的部分：真正值得量化的不是 AI 看起來多聰明，而是團隊能否用可追溯的檢查點，持續把錯誤成本關在發布之前。
作者：陳思維