OpenAI发布Codex实战手册，GPT5.1的持续工作极限为2小时17分钟

2小时17分钟，这是截至2025年8月，前沿AI模型在保持50%成功率的前提下，能够维持连续推理工作的时长。这个数字意味着AI已经从处理“秒级”的代码片段，跨越到了处理“小时级”的复杂工程任务。

基于此背景，OpenAI针对其编程工具Codex发布了一份基础却至关重要的指南：《Building an AI-native engineering team》构建AI原生工程团队。

这份文档不光是为了展示GPT5.1，更多是为了教用户怎么用。它最大的亮点在于为软件开发的每一个阶段（规划、设计、构建、测试、部署）都提供了一份拿来即用的“实战启动清单 (Getting started checklist)”。

本文将结合这些清单，精读这份Codex使用手册，带您了解如何从零开始构建一个“委托 (Delegate) - 审查 (Review) - 拥有 (Own)”的AI原生工作流。

核心范式转移：Delegate, Review, Own

在传统的开发模式中，工程师的大部分时间消耗在“翻译”工作上，即将需求翻译成代码，将设计翻译成组件。而在AI原生团队中，这种模式被一个新的循环所取代：

• Delegate (委托)：将机械性、多步骤、耗时的执行工作交给AI智能体。
• Review (审查)：工程师运用专业判断力，验证AI的产出是否符合架构标准、安全规范和业务逻辑。
• Own (拥有)：工程师保留对核心架构、产品意图和最终质量的绝对控制权。

这并不是要取代工程师，而是将他们从繁琐的实现细节中释放出来，专注于更高维度的系统推理。

第一阶段：规划与设计 (Plan & Design)

在项目启动阶段，最大的摩擦力往往来自“未知”。工程师需要花费数天时间挖掘代码库，才能确定一个新功能是否可行，或者涉及哪些服务。

规划：智能体作为“可行性分析师”

AI智能体现在可以介入规划阶段，通过读取功能规格说明书并将其与现有代码库进行交叉引用。它们能瞬间追踪代码路径，列出受影响的服务列表，并在写一行代码之前标记出规格说明书中的歧义。

设计：原型设计的“超光速”

设计阶段常被基础设置工作（Boilerplate）拖慢。智能体通过多模态能力，彻底改变了这一现状。工程师可以直接将设计稿截图喂给AI，智能体能瞬间生成符合团队设计系统（Design System）的组件代码。

启动清单 (Actionable Checklist)

• 从简单分类开始：不要试图一步到位。先让Agent负责对Issue或功能请求进行标记（Tagging）和去重。
• 逐步升级：尝试让Agent根据功能描述自动向Ticket添加子任务。
• 多模态输入：使用支持图像输入的Coding Agent，直接从设计图生成代码。
• 标准化组件：通过MCP（模型上下文协议）公开你的组件库，让Agent能够“看见”并调用现有的UI组件。

第二阶段：构建 (Build)

构建阶段是工程师痛感最强的地方，也是AI智能体影响最深远的领域。

告别“上下文切换”

在大型单体仓库（Monorepo）中，工程师往往花费大量时间在“寻找正确的做事方式”上。AI智能体不仅是代码生成器，更是“第一手实施者 (First-pass Implementer)”。

现在的Agent能够在一次长时间运行的任务中，跨越数十个文件，处理数据模型、API、UI组件、测试和文档。如果遇到构建错误，它们会像人类工程师一样，根据错误信息调整代码，直到构建成功。

工程师的新角色：从Implementer到Editor

当AI处理了CRUD逻辑、样板代码和基础连线后，工程师的注意力转移到了Review (审查)和Own (拥有)上，评估架构影响，定义新的抽象，以及处理模糊的产品需求。

启动清单 (Actionable Checklist)

• 明确的任务：从定义明确的任务开始，不要给Agent模糊的指令。
• 引入规划文件：让Agent使用规划工具，或者编写一个PLAN.md文件并提交到代码库中，作为它执行任务的路线图。感兴趣您可以参考下：

• 验证执行：检查Agent尝试执行的命令是否成功运行。
• 反馈循环：在AGENTS.md文件中迭代指令，解锁Agent运行测试和Linter的能力，让它能接收反馈并自我修正。

第三阶段：测试与审查 (Test & Review)

在许多团队中，测试覆盖率往往是截止日期压力下的牺牲品。AI原生团队通过反转这一流程来解决问题。

测试：从“事后补救”到“单一事实来源”

随着AI接管代码实现，测试变得比以往任何时候都重要，它们成为了应用功能的真理来源 (Source of Truth)。AI擅长阅读需求文档并生成测试用例，特别是那些人类容易忽略的边缘情况（Edge Cases）。

审查：规模化的代码卫士

代码审查（Code Review）通常在“耗时深究”和“草草了事”之间两难。AI审查不同于传统的Lint工具，它能理解运行时行为，跨文件追踪逻辑。但文档强调，必须使用专门针对代码审查训练的模型，避免通用模型的“噪音”。

启动清单 (Actionable Checklist)

• 测试先行：引导模型作为一个独立的步骤来实现测试，并在进入功能实现之前，验证新测试确实会“失败”（红灯测试）。
• 覆盖率指南：在你的AGENTS.md文件中明确设定测试覆盖率的标准。
• 建立“黄金标准”：收集并保存工程师完成的高质量PR（包含代码和评论）作为“评估集”，用来衡量AI工具的审查质量。
• 选择专业模型：务必选择专门针对Code Review训练的模型，通用模型往往会产生过多无用的Nitpick（吹毛求疵）。

第四阶段：文档与运维 (Document & Maintain)

文档：活的知识库

文档最怕“过期”。AI原生团队将文档生成嵌入到了发布流水线中。Agent可以读取代码并生成Mermaid格式的架构图、API文档，甚至在Release过程中自动分析Commit历史生成变更摘要。

运维：连接上下文的桥梁

故障排查通常需要在日志工具、代码仓库和部署系统之间反复横跳。通过MCP (Model Context Protocol)，AI智能体可以连接到日志聚合器（如Databricks, Azure DevOps），在IDE中直接分析错误日志并关联到Git历史中的具体变更。

启动清单 (Actionable Checklist)

• 嵌入发布流：识别哪些工作流（例如发布周期）可以自动生成文档。
• 连接工具：通过CLI或MCP Server将AI工具连接到你的日志和部署系统。
• 设定权限：明确定义Agent的访问范围（Scope）和权限，确保它能访问相关日志但又符合安全最佳实践。
• 模版化Prompt：为常见的运维查询创建复用Prompt，例如“调查端点X的错误”或“分析部署后的日志峰值”。

关键技术：AGENTS.md与MCP

要实现上述愿景，OpenAI提出了两个关键的技术，这相当于为AI团队构建了“基础设施”。

1.AGENTS.md：AI的员工手册

就像新员工入职需要阅读手册一样，AI智能体也需要指导。OpenAI建议在使用codex时，最好在代码库根目录维护一个AGENTS.md文件。

• 用途：定义代码风格、测试覆盖率要求、文档模板以及允许AI运行的命令。
• 效果：通过将这些上下文硬编码到文件中，每次Prompt都会自动携带这些“隐性知识”，确保AI生成的代码符合团队惯例。

2. MCP (Model Context Protocol)：打破工具孤岛

MCP是连接AI模型与外部世界的标准协议。

• 用途：它允许AI安全地连接到你的日志系统、设计工具、数据库和内部API。
• 效果：没有MCP，AI只是一个聪明的聊天机器人；有了MCP，AI才能真正看到你的运行时环境，执行数据库查询，成为一个全栈工程师。

结论：进化，而非替代

OpenAI的这份指南向我们展示了软件工程的未来图景：工程师并不会消失，但“什么是工程”的定义正在被改写。

以前，工程能力的衡量标准可能是你写代码的速度、对语法糖的熟练度。 现在，工程能力取决于你分解问题的能力、设计系统架构的眼光，以及指挥AI智能体群协同工作的领导力。

正如文档结尾所言：这种转变不需要激进的推倒重来，而是通过一个个具体的workflow开始的。从今天开始，在你的仓库里建一个AGENTS.md，试着按照上述清单将第一个Issue分类任务委托给AI，你就是在构建未来的AI原生工程团队。

文章来自于“AI修猫Prompt”，作者 “AI修猫Prompt”。