建设 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 原生工程团队的关键不是“人退出开发”，而是把人放到更高杠杆的位置：定义目标、设计约束、审查质量、承担责任。