智能体时代的软件工程：从写代码到设计系统
智能体时代的软件工程：从写代码到设计系统
OpenAI 如何用 Codex 从零开始构建产品，3 个月内完成 100 万行代码，工程师角色发生根本性转变
概述
本文总结了 OpenAI 内部的一项颠覆性实验：构建并交付一款软件产品的内部 beta 版，其中没有一行代码是人工编写的。
规模对比
| 指标 | 传统模式 | OpenAI 实验 |
|---|---|---|
| 开发者角色 | 编写代码、手动审查 | 设计环境、明确意图、构建反馈回路 |
| 代码贡献 | 100% 人工编写 | 100% AI 生成 |
| 完成时间 | 数月到数年 | 3 个月 |
| 代码量 | - | 约 100 万行 |
| 工程师规模 | 大型团队 | 3 人核心团队 |
| 日均 PR 吞吐 | - | 3.5 个 PR/人/天 |
更有意思的是，随着团队从 3 人扩展到 7 人，PR 吞吐量不降反升（Python SDK：182 → 226，+24%；TypeScript SDK：134 → 231，+72%）。
该产品有数百名内测用户，包括每天都在使用的内测高级用户。据估计，他们只用了手工编写代码所需时间的 1/10。
核心洞察：工程师角色的根本性转变
1. 从”执行者”到”设计者”
传统工程团队的核心工作：编写代码、测试、修复。
OpenAI 的核心理念：人类掌舵，智能体执行。
工程师的优先事项排序发生了变化：
- ❌ 手动编写代码
- ✅ 设计系统、明确意图、构建反馈回路
- ❌ 直接审查每一行代码
- ✅ 指导智能体完成有用的工作
2. 深度优先工作方式
当事情进展不如预期时，解决方案不是”更努力一点”，而是：
让 Codex 来完成工作。
人类工程师会追问：
“究竟还需要什么样的能力，我们又该如何让这个能力对智能体来说既清晰可读又可强制执行？”
这是”深度优先的工作方式”：
- 将更大的目标拆解为更小的构建模块（设计、代码、评审、测试等）
- 提示智能体去构建这些模块
- 用它们去解锁更复杂的任务
3. 不写代码的原则
OpenAI 团队的核心理念：
不手动编写代码。
从一开始，代码仓库就由智能体塑造。人类工程师从未直接贡献过任何代码。
技术实践：如何让智能体高效工作
一、提升应用程序的可读性
随着代码吞吐量增加，人工 QA 能力成为瓶颈。解决方案：让应用程序的内容对 Codex 直接可读。
具体措施：
| 能力 | 实现方式 | 效果 |
|---|---|---|
| 启动控制 | 应用程序可以根据 git worktree 启动 | Codex 可以为每次更改启动并驱动实例 |
| 调试能力 | 将 Chrome DevTools 协议接入智能体运行 | 复现错误、验证修复、推理 UI 行为 |
| 日志查询 | 创建本地可观测性堆栈 | 使用 LogQL 查询日志、PromQL 查询指标 |
| 可观测性工具 | 日志、指标、追踪记录 | Codex 在独立版本上运行，任务完成后删除所有内容 |
结果：Codex 单次运行可持续工作超过六小时（通常在人类睡眠时间），大幅提升吞吐量。
量化提示变得可行：
- “确保服务启动在 800ms 内完成”
- “这四个关键用户旅程中的任何跨度都不得超过两秒”
二、代码仓库作为记录系统
早期的失败尝试：”一本大型的 AGENTS.md”
OpenAI 最先尝试了使用”一个大型的 AGENTS.md”文件，结果失败：
问题：
- 情境是一种稀缺资源 - 巨大的指令文件会挤掉任务、代码和相关文档
- 过多的指导反而变得无效 - 当一切都”重要”时，一切都不重要了
- 智能体模式匹配而非导航 - 最终会进行本地模式匹配，而不是有意识地导航
- 无法核实和会立即腐烂 - 单个 blob 不适合机械检查（覆盖率、新鲜度、所有权、交叉链接），因此漂移是不可避免的。
成功的方案：内容目录 + 渐进式披露
新的架构：
- 简短的 AGENTS.md（约 100 行）：用作地图，指向更深层次的信息来源
- 结构化的 docs/ 目录：被视为记录系统
- 设计文档：已被编目和索引
- 架构文档：提供域和包分层的顶层地图
- 计划文档：复杂工作记录在执行计划中，附带进度和决策日志
- 已知技术债务：版本控制并集中存放
关键原则：渐进式披露（Progressive Disclosure）
智能体从一个小的稳定切入点开始，并被指导下一步该去哪里查看，而不是一开始就被淹没。
我们严格执行这一点。专职的 linter 和 CI 作业会验证知识库的更新状况、是否已交叉链接且结构正确。一个定期运行的”doc-gardening”智能体会扫描那些不再反映真实代码行为的过时或废弃文档，并发起修复用的 Pull Request。
三、规范架构与”品味不变式”
1. 严格的边界控制
架构围绕一个严格的架构模型构建：
- 每个业务域划分为一组固定的层
- 依赖方向经过严格验证
- 仅允许有限的一组边
- 横切关注点（认证、连接器、遥测、功能标志）通过单一显式接口进入：Providers
其他任何内容都不被允许，并将通过自动化方式强制执行。
2. 什么是”品味不变式”（Taste Invariants）
OpenAI 通过自定义的代码检查器和结构测试来强制执行规则，这些规则会：
- 静态地强制执行结构化日志记录
- 强制模式和类型的命名约定
- 强制文件大小限制
- 强制特定平台的可靠性要求
关键洞察：
在以人为本的工作流程中，这些规则可能会让人感到迂腐或束缚。
有了智能体，它们就成了倍增器：一旦编码，它们就能立即应用于所有地方。
3. 局限 vs 自主
OpenAI 非常明确：
中央层面强制执行边界，在本地层面允许自主权。
你非常重视界限、正确性和可重复性。在这些边界内，团队或智能体在解决方案的表达方式上拥有很大的自由。
人类品味 vs 生成代码风格：
- 生成的代码不总是符合人类的风格偏好
- 这没关系
- 只要输出是正确的、可维护的，并且对未来的智能体运行而言清晰易读，就可以算作达标
4. 品味反馈回路
人类的品味会不断反馈到系统中：
- 审查评论
- 重构的 Pull Request
- 面向用户的 Bug
这些反馈会被记录为文档更新，或直接编码到工具中。
示例： 不使用通用的 p-limit 风格包，而是投入使用了带并发的 map 辅助函数：
- 与 OpenTelemetry 仪表紧密集成
- 具备 100% 的测试覆盖率
- 其行为完全符合运行时预期
项目成效数据
代码仓库规模
- 起始时间： 2025 年 8 月下旬（空仓库）
- 5 个月后： 约 100 万行代码
- 代码仓库结构： 从应用逻辑、基础设施、工具、文档到内部开发者工具应有尽有
Pull Request 吞吐
| 指标 | 前 3 个月 | 后 3 个月 | 增长 |
|---|---|---|---|
| 总 PR 数 | 316 | 457 | +45% |
| Python SDK PR 数 | 182 | 226 | +24% |
| TypeScript SDK PR 数 | 134 | 231 | +72% |
| 人均吞吐 | ~3.5 PR/天（3 人） | ~3.5 PR/天（7 人，不降反升） |
重要洞察：
- 吞吐量提升不是因为 AI 能力更强，而是工作模式变了
- 人类不再手动编写代码，而是专注于设计和系统优化
- 智能体专注于执行，工程师专注于让智能体能高效执行
产品规模
- 内测用户： 数百名（包括每天都在使用的内测高级用户）
- 生产环境： 已投入使用
- 交付周期： 经历了交付、部署、故障和修复的整个过程
吞吐量改变：从阻塞门到快速循环
传统的合并理念
- PR 必须经过人工审查
- 大量阻塞
- 周期长
- 测试偶发失败通常需要后续重跑来解决
智能体驱动的模式
- PR 生命周期很短
- 减少阻塞门
- 纠错成本低
- 等待成本高
OpenAI 的实践：
在低吞吐量环境中，这样做是不负责任的。而在这里，这通常是正确的选择。
但在高吞吐量环境中（智能体主导），这通常是正确的选择：
减少阻塞门，允许智能体快速合并，人类主要在需要判断时介入。
熵与垃圾收集：维持代码库健康
问题：智能体会复制现有模式
完全自主的智能体会：
- 复现代码仓库中已存在的模式
- 包括那些不均衡或不够理想的模式
- 随着时间推移，这不可避免地导致漂移
解决方案：”黄金原则” + 后台清理
OpenAI 建立了一个循环清理流程：
1. 黄金原则
带有主观意见的机械规则，旨在保持代码库的可读性和一致性，例如：
- (1) 更倾向于使用共享的实用程序包，而不是手工编写的辅助工具
- (2) 不会使用”YOLO 式”探测数据 — 会验证边界，或依赖类型化的 SDK
- (3) 会定期运行一组后台 Codex 任务，扫描偏差、更新质量等级，并发起有针对性的重构 Pull Request
2. 后台清理
大多数任务可以在一分钟内完成审查并自动合并。
技术债务就像一笔高息贷款：
不断地以小额贷款的方式偿还债务，总比让债务不断累积，再痛苦地一次解决要好得多。
人类的品味一旦被捕捉，就会持续应用于每一行代码。这使得团队能够每天发现并解决不良模式，而不是让它们在代码库中传播数天或数周。
智能体的自主水平提升
跨过的重要门槛
代码仓库最近跨过了一个重要门槛：使 Codex 能够端到端地驱动一个新功能。
智能体现在可以端到端完成
给定一个提示，智能体现在可以：
验证与修复
- 验证代码库的当前状态
- 重现已报告的漏洞
- 录制一个演示故障的视频
- 实施修复措施
- 通过运行应用程序来验证修复
- 录制第二个视频，演示解决方案
审查与反馈
- 回应智能体和人类反馈
- 仅在需要判断时才交由人工处理
测试与构建
- 检测并修复构建故障
- 仅在需要判断时才交由人工处理
合并更改
- 在无需人工批准的情况下完成
重要限制：
此行为在很大程度上取决于此代码仓库的具体结构和工具，不应在没有类似投入的情况下假定它可以泛化 — 至少目前还不行。
给”我们”的核心启发
1. 投入精力的方向要改变
从”写代码”转向”设计系统、明确意图、构建反馈回路”。
- ❌ 编写代码不再是核心竞争力
- ✅ 构建让智能体能高效执行的环境和工具才是稀缺资源
2. 给智能体一张地图，不是一本说明书
AGENTS.md 不应该成为百科全书。
- 保持简短（约 100 行）
- 用作地图，指向更深层次的信息来源
- 真实信息存储在结构化的 docs/ 目录中
- 通过渐进式披露引导智能体探索
3. 品味不变式是智能体的倍增器
在以人为本的工作流程中是束缚，在智能体驱动的流程中是倍增器。
- 一旦编码，它们就能立即应用于所有地方
- 品味反馈回路：文档更新、重构 PR、编码到工具
4. 及时将知识嵌入代码仓库
随着智能体能力不断增强，越来越多的情境需要推送到仓库中：
- 如果智能体无法发现它，就会像迟了三个月入职的新员工一样对其一无所知
- 将系统的更多部分转化为智能体可以检查、验证并直接修改的形式，可以提高杠杆效应
5. 量化与数据驱动决策
不要只是说”请审查发布”，而是给出：
- 具体的证据
- 风险评估
- 后续行动建议
示例（发布审查）：
1
2
3
4
5
6
7
8
🟢 GREEN LIGHT TO SHIP. Minor-version bump includes expected breaking change (Python 3.9 drop) with no concrete regressions found.
Scope summary:
- 38 files changed (+1450/-789)
Python 3.9 drop
- Risk: 🟡 MODERATE. Users pinned to Python 3.9 will be unable to install 0.9.0 release.
- Action: Ensure release notes clearly call out Python 3.9 drop.
6. 为智能体设计架构
显然的是：构建软件仍然需要纪律，但纪律更多地体现在支撑结构上，而不是代码上。
保持代码库一致性的工具、抽象和反馈回路变得越发重要。
未来：仍然在学习的内容
尚不清楚的问题
在一个完全由智能体生成的系统中：
- 架构连贯性会如何随着时间的推移而演变
- 模型的功能不断增强时，系统将如何演变
明确的方向
构建软件仍然需要纪律，但：
- 纪律更多地体现在支撑结构上，而不是代码上
- 保持代码库一致性的工具、抽象和反馈回路变得越发重要
当前最棘手的挑战
集中在：
- 设计环境
- 反馈回路
- 控制系统
帮助智能体实现目标：大规模构建和维护复杂、可靠的软件。
结论：智能体时代的工程师
OpenAI 的这项实验揭示了一个正在发生的转变：
工程师的核心竞争力变了
| 传统工程师 | 智能体时代的工程师 |
|---|---|
| 编写代码的能力 | 设计系统、明确意图、构建反馈回路的能力 |
| 审查代码的能力 | 识别缺失内容并将其反馈到系统的能力 |
| 验证测试的能力 | 验证智能体产出的能力 |
| 直接解决 bug 的能力 | 定义清晰约束和触发条件的能力 |
可应用的框架
OpenAI 的实践提供了一个可复用的框架：
技术层面：
- Skills + AGENTS.md + GitHub Actions
- 严格的架构边界 + 层依赖
- 可观测性工具（日志、指标、追踪）
- 黄金原则 + 后台清理
管理层面：
- 深度优先工作（目标拆解）
- 渐进式披露（不要一次给出所有信息）
- 品味不变式（将规则编码为可执行检查）
- 品味反馈回路（将人类偏好嵌入系统）
最终洞察
“我们仍在学习的是：在一个完全由智能体生成的系统中，架构连贯性会如何随着时间的推移而演变。”
关键不在于使用多少 AI，而在于如何系统化地使用 AI：
- 📦 将知识包为可复用的 Skills
- 📋 在 AGENTS.md 中明确规则和触发条件
- 🤖 用脚本处理确定性任务
- 🧠 让模型负责上下文相关的决策
- 🔄 在 CI 中稳定运行已验证的工作流
这种”技能驱动维护”的模式值得任何正在探索智能体时代的开源项目借鉴。