在 Agent 时代如何做软件工程
—— OpenAI 如何用 Codex 构建一个 100 万行代码的系统
最近 OpenAI 工程团队分享了一篇非常值得工程师阅读的文章：
原文： https://openai.com/zh-Hans-CN/index/harness-engineering/
文章讲述了他们进行的一次实验：
构建一个真实的软件产品，但整个代码库没有一行代码是人工编写的。
所有代码，包括：
- 应用逻辑
- 测试
- CI/CD
- 文档
- 运维脚本
- 内部工具
全部由 Codex 生成。
而人类工程师只做一件事：
设计系统、约束和反馈循环。
最终他们用 3 个工程师 在 5 个月内构建了一个接近 100 万行代码的系统。
这篇文章其实揭示了一个重要趋势：
软件工程正在从 “写代码” 转变为 “设计 AI 能工作的系统”。
下面我把这篇文章的核心内容拆解出来，分析它对未来工程模式意味着什么。
一、实验：一个完全由 AI 生成代码的产品
OpenAI 团队从 一个空 Git 仓库开始。
初始架构由 Codex + GPT-5 自动生成，包括：
- 项目结构
- CI 配置
- 代码格式规则
- 包管理
- 应用框架
- AGENTS.md
甚至：
指导 AI 如何在仓库中工作的文档，也是 AI 写的。
5 个月后结果：
- 约 100 万行代码
- 1500+ Pull Request
- 团队只有 3 个工程师
- 平均 每人每天处理 3.5 个 PR
系统已经有：
- 内部日活用户
- 外部 Alpha 用户
换句话说：
这不是 Demo，而是一个真实运行的产品。
他们的核心原则是：
Humans steer, agents execute. 人类掌舵，AI 执行。
二、工程师角色发生了变化
在这个体系下：
工程师几乎不写代码。
工程师的工作变成：
1️⃣ 设计系统结构 2️⃣ 定义任务目标 3️⃣ 设计反馈循环 4️⃣ 构建 AI 能使用的工具
换句话说：
以前：
工程师 -> 写代码 -> 提 PR
现在：
工程师 -> 描述任务
-> 运行 Agent
-> Agent 提 PR
-> Agent review
-> 自动修复
整个流程类似这样：
Engineer
↓
Prompt
↓
Codex
↓
Open PR
↓
Agent Review
↓
Fix
↓
Merge
很多时候：
PR review 也是 AI 做的。
三、系统必须“对 Agent 可读”
一个非常重要的经验：
Agent 看不到的知识 = 不存在。
例如：
- Slack 讨论
- Google Docs
- 人脑记忆
对 AI 来说都是 不可见的知识。
因此他们做了一个关键决定：
把代码仓库变成唯一的信息来源。
所有内容都写入 repo：
- 架构文档
- 设计文档
- 产品规格
- 执行计划
- 技术债务
- 决策记录
目录结构大概是这样：
AGENTS.md
ARCHITECTURE.md
docs/
├ design-docs/
├ exec-plans/
├ product-specs/
├ references/
├ SECURITY.md
├ RELIABILITY.md
└ QUALITY_SCORE.md
AI 通过这个结构：
- 找信息
- 推理系统
- 修改代码
他们称这种方式为：
Agent-readable repository
四、不要写 1000 行 prompt
他们曾尝试：
一个巨大 AGENTS.md
结果完全失败。
原因是：
1 情境窗口是稀缺资源
长文档会挤掉：
- 代码
- 任务
- 重要上下文
2 过多规则会失效
当所有东西都重要：
其实没有东西重要。
3 文档会腐烂
如果维护成本太高：
文档会变成：
过期规则的坟场
他们最后采用的方法是：
AGENTS.md 只做目录
类似：
AGENTS.md
↓
ARCHITECTURE.md
↓
docs/
↓
design-docs/
也就是：
给 AI 一张地图，而不是一本说明书。
五、架构必须严格
Agent 在这种环境下有一个特点：
会复制已有模式。
如果架构不严格：
代码会快速漂移。
因此他们强制使用：
严格分层架构
例如：
Types
↓
Config
↓
Repo
↓
Service
↓
Runtime
↓
UI
规则：
- 只能向下依赖
- 不允许跨层调用
所有规则通过：
- custom linter
- 结构测试
自动执行。
也就是说：
架构约束是机器执行的。
六、吞吐量改变了工程文化
Agent 写代码的速度远远超过人类。
这带来了一个新问题：
代码吞吐量远大于人类审查能力。
因此他们改变了传统工程文化：
以前：
严格 gate
必须 review
CI 必须通过
现在：
快速 merge
问题后修
因为：
等待的成本比修复更高。
七、AI 可以自动完成整个开发流程
随着工具完善，现在 Codex 已经可以：
自动完成整个开发流程：
1️⃣ 验证代码库状态 2️⃣ 复现 bug 3️⃣ 录制 bug 视频 4️⃣ 实现修复 5️⃣ 运行应用验证 6️⃣ 录制修复视频 7️⃣ 提 PR 8️⃣ 处理 review 9️⃣ 修复 CI 🔟 自动 merge
人类只在必要时介入。
八、新问题：AI 会制造“技术债”
完全 AI 开发会带来一个问题：
AI 会复制错误模式。
例如：
- 不一致的实现
- 不合理 abstraction
- 重复工具
他们最初的做法是：
每周五清理 AI 代码。
后来发现不可扩展。
最终解决方法是：
把工程原则写进代码。
例如：
- 禁止 YOLO parsing
- 强制 typed SDK
- 优先共享工具库
然后：
定期运行 Refactor Agent。
类似：
自动垃圾回收（GC）。
九、真正稀缺的资源：人类注意力
这篇文章最后总结了一句话：
软件工程的瓶颈不再是写代码，而是人类注意力。
未来工程体系的核心问题变成：
- 如何设计环境
- 如何设计反馈循环
- 如何设计约束系统
而不是：
写代码。
十、对未来软件工程的启示
这篇文章透露了一个非常重要的趋势：
软件工程正在进入：
Agent-first engineering
未来工程师更像：
系统设计师
而不是：
代码工人
未来的核心能力可能是：
- 架构设计
- Agent workflow
- 工程自动化
- feedback loop 设计
- 工程知识建模
而不是：
- 写 CRUD
结语
这篇文章其实说明了一件事：
AI 不只是写代码工具。
它正在改变：
软件工程本身的结构。
未来的软件团队可能会变成：
少量工程师
+
大量 AI Agent
+
高度结构化的代码仓库
而工程师的核心价值将变成：
设计 AI 能高效工作的系统。