建設 AI 原生工程團隊

AI 原生工程團隊不是“讓 agent 寫所有程式碼”。更準確的變化是：把重複、可驗證、可回復的工程環節交給 Codex，讓工程師把注意力放回產品判斷、架構取捨、質量標準和最終責任。

OpenAI 的 AI-native engineering guide 按軟體開發生命週期拆解了 coding agents 的落點。本頁把它整理成團隊可以執行的框架。

核心變化

AI coding 的重心正在從補全程式碼，轉向執行任務。

flowchart LR
    Autocomplete["補全<br/>下一行程式碼"] --> Pairing["協作<br/>解釋、探索、區域性修改"]
    Pairing --> Agent["Agent<br/>跨檔案執行任務"]
    Agent --> Team["團隊流程<br/>計劃、實現、測試、審查、維護"]

這帶來三類變化：

• 機械實現會更多交給 agent 起草。
• 工程師會更早定義規格、約束和驗證。
• 團隊質量控制會從“人手寫每一行”轉向“人負責標準、審查和最終決策”。

但 ownership 沒有消失。生產程式碼、架構方向、安全風險和產品取捨仍由人負責。

Delegate、Review、Own

落地時最有用的劃分是三層責任：

flowchart TB
    Delegate["Delegate<br/>交給 Codex 做第一版"]
    Review["Review<br/>工程師審查和修正"]
    Own["Own<br/>團隊承擔最終責任"]

    Delegate --> Review --> Own

可以交給 Codex 的工作：

• 初步 feasibility 分析。
• 根據明確 spec 起草實現。
• 查詢相關檔案和呼叫鏈。
• 生成測試初稿。
• 總結 release diff。
• 做 PR 初步審查。
• 根據日誌和程式碼做 incident triage。

必須由工程師審查的工作：

• 架構是否合理。
• 行為是否符合產品意圖。
• 效能、安全、許可權、資料邊界是否正確。
• 測試是否真的覆蓋核心風險。
• agent 是否走捷徑、寫 stub、繞過約束。

必須由團隊擁有的責任：

• 優先順序和產品方向。
• 長期架構和抽象邊界。
• 生產釋出和回復判斷。
• 合規、安全、客戶影響。
• 團隊規範和質量標準。

這條線畫不清，團隊就會在“完全不信 AI”和“盲目放權”之間搖擺。

按 SDLC 落地

Plan：先讓 Codex 做程式碼感知的分診

適合交給 Codex：

• 讀取 feature spec。
• 對照 codebase 找相關模組。
• 標出模糊需求、依賴和風險點。
• 起草任務拆分和驗收建議。

工程師負責：

• 判斷優先順序。
• 決定範圍切分。
• 確認工作量估計是否可信。
• 處理跨團隊取捨。

最小實踐：

请只读分析这个需求。
输出涉及模块、未知问题、风险点、建议拆分和需要人工确认的决策。
不要修改文件。

Design：讓 Codex 加速原型，不替代體驗判斷

適合交給 Codex：

• 根據設計稿或文字說明生成元件初稿。
• 應用現有 design tokens。
• 找出可複用元件。
• 提醒可訪問性和狀態覆蓋缺口。

工程師和設計師負責：

• 體驗方向。
• 設計系統一致性。
• 互動細節。
• 元件抽象邊界。

最小實踐是從內部 prototype 開始，不要直接讓 agent 改全站設計系統。

Build：讓 Codex 做 first-pass implementation

適合交給 Codex：

• 按明確 spec 實現一個小功能。
• 補齊 CRUD、API wiring、UI 狀態、錯誤處理。
• 按專案模式生成 boilerplate。
• 根據構建或測試失敗修正實現。

工程師負責：

• 業務邏輯正確性。
• 關鍵抽象。
• 效能路徑。
• 資料遷移和相容風險。

最重要的規則是：feature spec 必須明確，驗證必須可執行。

Test：讓測試成為 agent 的反饋系統

Codex 能寫測試，但團隊仍要定義什麼叫好測試。

適合交給 Codex：

• 根據 spec 列測試用例。
• 為邊界條件補測試初稿。
• 修復因程式碼演進導致的測試失效。
• 執行測試並根據輸出迭代。

工程師負責：

• 判斷測試是否覆蓋真實使用者行為。
• 防止 agent 寫無意義 stub。
• 保證失敗測試先證明問題存在。
• 維護測試金標準。

測試越可靠，agent 越能在反饋裡自我修正。

Review：讓 Codex 做 baseline review

適合交給 Codex：

• 初步檢查 PR 中的邏輯漏洞。
• 查詢 race condition、資料關係、錯誤硬編碼。
• 對照規範發現遺漏測試或風險。
• 給 reviewer 彙總改動面。

工程師負責：

• 最終 review 和 merge。
• 判斷架構一致性。
• 處理高風險評論。
• 對生產結果負責。

AI review 的目標不是增加評論數量，而是提高高風險問題的召回率。低訊號 nitpick 應被壓制。

Document：把文件更新放進交付鏈

適合交給 Codex：

• 總結模組職責。
• 根據 diff 更新內部文件。
• 為 release 生成變更摘要。
• 生成 Mermaid 系統圖初稿。

工程師負責：

• 文件結構。
• 關鍵設計決策背後的原因。
• 對外文件、品牌、法務和安全風險。

文件不應靠“有空再補”。可以把 Codex 文件任務作為 PR 或 release 的固定檢查項。

Deploy and Maintain：先做診斷，不直接放權修生產

適合交給 Codex：

• 聚合日誌、部署記錄和相關程式碼路徑。
• 找出可疑 commit。
• 提出可能根因和驗證步驟。
• 起草低風險 hotfix。

工程師負責：

• 判斷根因是否成立。
• 決定修復、回復或降級。
• 審批生產變更。
• 事後覆盤和長期改進。

生產環境裡，agent 應先是診斷加速器，再逐步進入受控修復流程。

團隊落地順序

不要一次性把所有 SDLC 階段都接入 Codex。推薦順序：

1. 從只讀分診和 PR 摘要開始。
2. 讓 Codex 做小功能 first-pass implementation。
3. 把測試、lint、型別檢查接入 agent 反饋迴圈。
4. 沉澱 AGENTS.md、profiles、managed config 和審查規範。
5. 再接入 issue、design、logging、deployment 這類系統。
6. 最後建設可觀測性和評估集，持續衡量質量。

每一步都要有回復方案、許可權邊界和人工審查點。

成熟度判斷

一個團隊是否真正 AI-native，不看使用了多少 agent，而看這些問題是否有答案：

• 哪些任務可以交給 Codex，哪些不能。
• Codex 的預設許可權是什麼。
• 它能執行哪些測試和工具。
• AGENTS.md 是否明確寫了團隊規範。
• AI 產物由誰 review，誰最終負責。
• 如何評估 agent 輸出質量。
• 失敗時如何回復和覆盤。

如果這些問題沒有答案，先補治理，不要擴大自動化範圍。

AI 原生工程團隊的關鍵不是“人退出開發”，而是把人放到更高槓杆的位置：定義目標、設計約束、審查質量、承擔責任。