---
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="/docs/codex/official/06-team-integration/54-enterprise-admin">
    了解企业管理、权限、cloud/local 开关和治理入口。
  </Card>
  <Card title="Managed Configuration" href="/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 原生工程团队的关键不是“人退出开发”，而是把人放到更高杠杆的位置：定义目标、设计约束、审查质量、承担责任。
