---
title: "建設 AI 原生工程團隊"
description: "把 OpenAI 的 AI-native engineering guide 轉成可執行的團隊落地框架：哪些交給 agent，哪些仍由工程師負責。"
verifiedAt: "2026-05-06"
---

import { Cards, Card } from 'fumadocs-ui/components/card';

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

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

> [!IMPORTANT]
> 團隊採用 Codex 時不要從“全流程自動化”開始。先選低風險、證據充足、驗證明確的 workflow，再逐步擴大 agent 責任。

<Cards>
  <Card title="官方 AI-native guide" href="https://developers.openai.com/codex/guides/build-ai-native-engineering-team">
    檢視 OpenAI 對 AI-native engineering team 的完整官方說明。
  </Card>
  <Card title="Enterprise Admin" href="/zh-Hant/docs/codex/official/06-team-integration/54-enterprise-admin">
    瞭解企業管理、許可權、cloud/local 開關和治理入口。
  </Card>
  <Card title="Managed Configuration" href="/zh-Hant/docs/codex/official/06-team-integration/55-managed-config">
    用組織級配置統一團隊預設值和安全策略。
  </Card>
</Cards>

## 核心變化

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

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

這帶來三類變化：

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

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

## Delegate、Review、Own

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

```mermaid
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 找相關模組。
- 標出模糊需求、依賴和風險點。
- 起草任務拆分和驗收建議。

工程師負責：

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

最小實踐：

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

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