0 行手写代码，百万行产品：OpenAI 的 AI 原生开发到底怎么玩的？

题外话：

今天公司裁员了。受影响的主要是前端和测试，后端研发也有一些。公司效益是主因，但 AI 的影响也占了不小的比重。不只是我们，很多大公司最近也接连有动作。预感今年对程序员、对整个国内软件开发行业，都会是特别的一年。大家加油吧。

最近在读 OpenAI 刚发的一篇博文。标题叫 "Harness engineering: leveraging Codex in an agent-first world"。读完之后的感受很复杂------一方面是对技术趋势的兴奋，另一方面是对行业变化的焦虑。

这篇文章讲的事情很简单：OpenAI 内部一个小团队，从一个空的 git 仓库开始，用 0 行手写代码，5 个月交付了一个百万行级别的内部产品。每一行代码------业务逻辑、测试、CI 配置、文档、可观测性工具------全部由 Coding Agent 生成。

3 个工程师，平均每人每天 3.5 个 PR，效率是传统方式的 10 倍。

这不是 demo，不是 POC，是一个有真实日活用户的产品。

这篇文章适合正在思考 AI 如何改变软件开发流程的工程师和技术管理者。不管你是想了解前沿实践，还是想为团队找到 AI 落地的方向，都值得花时间读一读。

太长不看版

Harness Engineering 不是一个工具，是一套让 AI Agent 能可靠工作的工程体系
核心转变：工程师从"写代码的人"变成"设计环境、指定意图、构建反馈循环的人"
仓库本身就是知识系统------Agent 看不到的东西，等于不存在
架构约束不是可选项，是 Agent 能跑起来的前提条件
文档不是写给人看的附属品，而是 Agent 的导航地图
自定义 linter 和结构化测试是"机械化执行品味"的关键手段
技术债像高利贷，用"垃圾回收"机制持续偿还比攒着爆发好得多
传统的 code review 和合并门禁在高吞吐场景下反而成了瓶颈

一、什么是 Harness Engineering？

先从一个类比说起

如果把 AI Agent 比作一匹马，那 Context Engineering（上下文工程）解决的是"怎么跟马沟通"的问题------给它正确的指令、足够的信息。而 Harness Engineering 解决的是另一个问题：缰绳、马鞍、围栏和道路维护。

不管马多聪明，你不可能同时安全地跑十匹马，除非这些基础设施到位。

这个类比来自 SmartScope Blog，很精准地抓住了 Harness Engineering 的本质：它不是关于模型本身，而是关于模型周围的一切。

Martin Fowler（对，就是那个写《重构》的 Martin Fowler）在读完 OpenAI 这篇文章后，把 Harness 的组成拆成了三类：

上下文工程（Context Engineering）：持续增强的代码库内知识库，加上 Agent 对可观测性数据、浏览器导航等动态上下文的访问能力
架构约束（Architectural Constraints）：不仅靠 LLM Agent 监控，还有确定性的自定义 linter 和结构化测试
垃圾回收（Garbage Collection）：定期运行的 Agent，扫描文档不一致和架构违规，对抗熵增和衰退

Latent Space 的总结更直接：

"在每一个工程学科中，harness 都是同一个东西：连接、保护和编排组件的那一层------它本身不做具体的工作。"

换句话说，模型是原始智能，Harness 是让它变得有用的那套系统。

graph TB subgraph Harness["Harness Engineering 体系"] direction TB CE["上下文工程
Context Engineering"] AC["架构约束
Architectural Constraints"] GC["垃圾回收
Garbage Collection"] end subgraph CE_Detail["上下文工程"] KB["仓库内知识库
AGENTS.md / docs/"] OB["可观测性接入
Logs / Metrics / Traces"] BR["浏览器驱动
Chrome DevTools"] end subgraph AC_Detail["架构约束"] LI["自定义 Linter"] ST["结构化测试"] LA["分层架构规则"] end subgraph GC_Detail["垃圾回收"] DS["文档扫描 Agent"] QG["质量评分追踪"] RR["自动重构 PR"] end CE --> CE_Detail AC --> AC_Detail GC --> GC_Detail classDef main fill:#1A9090,stroke:#0d5454,color:#fff classDef sub fill:#0d5454,stroke:#1A9090,color:#e0f0f0 classDef detail fill:#1a2e2e,stroke:#1A9090,color:#b0d8d8 class CE,AC,GC main class CE_Detail,AC_Detail,GC_Detail sub class KB,OB,BR,LI,ST,LA,DS,QG,RR detail

业界怎么看？

Harness Engineering 这个概念一出来，社区反应很有意思。

看好的一方认为这是 AI 编程从"辅助工具"到"工程范式"的关键跳跃。Towards AI 的文章直接用了"Beyond Copilot"这个标题，认为 2026 年是从 Copilot 模式转向 Agentic Harness Engineering 的转折点。

持保留态度的也不少。Nonsense.io 的作者坦言："我读完之后一直在想，这到底是一百万行不可维护的垃圾代码，还是对近期软件工程未来的一瞥？"

Martin Fowler 则提出了一个关键问题：这套体系能不能用在已有的老项目上？ 她把这比作"在一个从来没跑过静态分析的代码库上第一次开启 lint------你会被告警淹没"。

这些不同的声音恰恰说明了一件事：Harness Engineering 不是银弹，但它确实指向了一个值得认真对待的方向。

二、OpenAI 的实践：从空仓库到百万行代码

实验设定

OpenAI 这个实验的约束条件非常极端：0 行手写代码。

2025 年 8 月底，第一个 commit 落入一个空仓库。初始脚手架------仓库结构、CI 配置、格式化规则、包管理器设置、应用框架------全部由 Coding Agent CLI 生成。甚至指导 Agent 如何在仓库中工作的 AGENTS.md 文件，本身也是 Agent 写的。

5 个月后的成绩单：

指标	数据
代码规模	约 100 万行
PR 数量	约 1,500 个
团队规模	起初 3 人，后扩展到 7 人
人均日 PR	3.5 个
效率提升	约 10 倍
手写代码	0 行

工程师角色的重新定义

这里最值得工程师警惕的是：人的角色变了。

过去：工程师写代码，Agent 辅助。现在：Agent 写代码，工程师设计环境。

OpenAI 团队的原话是："Humans steer. Agents execute."（人类掌舵，Agent 执行。）

具体来说，工程师的日常工作变成了：

拆解目标：把大目标分解成 Agent 能处理的小构建块
描述任务：通过 prompt 描述意图，启动 Agent
构建反馈循环：当 Agent 卡住时，不是"再试一次"，而是问"缺了什么能力？怎么让它对 Agent 可读、可执行？"
验证结果：审查产出，把人类品味反馈回系统

他们甚至把大部分 code review 也交给了 Agent。一个 PR 的生命周期大致是：Agent 写代码 → Agent 自审 → 请求其他 Agent review → 根据反馈迭代 → 所有 Agent reviewer 满意后合并。人类可以介入 review，但不是必须的。

让 Agent "看见"更多

随着代码产出速度上来，瓶颈转移到了人类 QA 能力上。团队的应对策略是：让更多东西对 Agent 可读。

浏览器驱动：通过 Chrome DevTools Protocol，Agent 可以直接操作应用 UI------截图、DOM 快照、导航。这意味着 Agent 能自己复现 bug、验证修复、推理 UI 行为。

可观测性接入：每个 git worktree 都有独立的可观测性栈（Victoria Logs / Metrics / Traces）。Agent 可以用 LogQL 查日志、用 PromQL 查指标。这样一来，"确保服务启动在 800ms 内完成"这种 prompt 就变得可执行了。

他们经常看到单次 Agent 运行持续工作 6 个小时以上------通常是在人类睡觉的时候。

仓库即知识系统

这是整篇文章里我认为最有洞察力的部分。

OpenAI 团队试过"一个大 AGENTS.md"的方案，失败了。原因很直觉：

上下文是稀缺资源：一个巨大的指令文件会挤占任务、代码和相关文档的空间
什么都重要 = 什么都不重要：Agent 会局部模式匹配，而不是有意识地导航
立刻腐烂：没人维护的大文件变成过时规则的坟场
难以验证：单一文件不适合做机械化检查

所以他们把 AGENTS.md 当作目录，而不是百科全书。真正的知识库是一个结构化的 docs/ 目录：

sql 复制代码

AGENTS.md              ← 约 100 行，只是地图
ARCHITECTURE.md
docs/
├── design-docs/       ← 设计文档，带验证状态
├── exec-plans/        ← 执行计划，分 active/completed
├── product-specs/     ← 产品规格
├── references/        ← 外部参考（llms.txt 格式）
├── DESIGN.md
├── FRONTEND.md
├── QUALITY_SCORE.md   ← 质量评分
└── SECURITY.md

核心原则是渐进式披露：Agent 从一个小而稳定的入口开始，被教会"下一步去哪里找"，而不是一上来就被信息淹没。

更关键的一句话："从 Agent 的视角看，任何它在运行时无法访问的东西，等于不存在。"

那个在 Slack 里对齐的架构决策？如果没有写进仓库，对 Agent 来说就是不可见的------就像一个三个月后入职的新人也不会知道一样。

架构即护栏

文档只能解决一半问题。另一半靠机械化的架构约束。

OpenAI 团队围绕一个严格的分层架构模型构建应用。每个业务领域被划分为固定的层级，依赖方向严格校验，允许的边只有有限的几条：

复制代码

Types → Config → Repo → Service → Runtime → UI

跨切面关注点（认证、连接器、遥测、特性开关）通过唯一的显式接口 Providers 进入。其他一切都被禁止，并通过机械化手段强制执行。

他们的原话很到位："这是你通常会推迟到有几百个工程师时才做的架构。用 Coding Agent 的话，这是一个早期前提条件：约束才是让速度不带来衰退的东西。"

具体的执行手段包括：

自定义 linter：强制结构化日志、命名规范、schema 和类型的命名约定、文件大小限制
结构化测试：验证依赖方向、层级边界
品味不变量：平台特定的可靠性要求
错误信息即上下文：自定义 lint 的错误信息被设计成可以直接注入 Agent 上下文的修复指令

在人类优先的工作流里，这些规则可能显得吹毛求疵。但对 Agent 来说，一旦编码，就在所有地方同时生效。

垃圾回收机制

Agent 会复制仓库中已有的模式------包括不好的模式。时间一长，漂移不可避免。

团队最初的做法是每周五手动清理"AI 垃圾"，占了 20% 的工作时间。显然不可持续。

后来他们把"黄金原则"编码进仓库，建立了定期清理流程：

后台 Agent 定期扫描偏差
更新质量评分
自动开重构 PR
大部分 PR 一分钟内可审完，自动合并

这就像垃圾回收。 技术债像高利贷------持续小额偿还，远好过攒着一次性爆发。人类品味只需捕获一次，然后在每一行代码上持续执行。

三、落地核心要素：复制这套体系需要什么？

读完 OpenAI 的实践，一个自然的问题是：如果我想在自己的团队里落地，需要具备哪些要素？

1. 仓库即唯一真相源（Repository as System of Record）

不是可选项，是前提。

所有设计决策、架构规范、产品规格都必须以版本化的 Markdown 存在于仓库中
AGENTS.md 只做目录，不做百科全书（控制在 100 行左右）
建立 docs/ 结构化知识库，支持渐进式披露
定期运行"文档园丁"Agent，扫描过时文档并自动修复

2. 机械化的架构约束（Mechanically Enforced Architecture）

靠人记不住，靠 Agent 也不够，靠工具强制执行。

定义严格的分层架构和依赖方向
用自定义 linter 强制命名规范、日志格式、文件大小等
用结构化测试验证模块边界（类似 ArchUnit）
lint 错误信息要写成 Agent 能理解的修复指令

3. Agent 可观测性（Agent-Legible Observability）

Agent 不能只写代码，还要能"看到"代码运行的效果。

每个工作分支/worktree 配备独立的可观测性栈
Agent 能查询日志（LogQL）、指标（PromQL）、链路追踪（TraceQL）
Agent 能通过浏览器协议驱动 UI，截图、快照、导航
应用可按 worktree 独立启动和销毁

4. 持续的质量治理（Continuous Quality Governance）

不是一次性的代码审查，是持续运转的质量机器。

建立质量评分体系，按领域和架构层追踪
后台 Agent 定期扫描、评分、开修复 PR
技术债追踪器版本化管理
最小化阻塞式合并门禁------在高吞吐场景下，修正比等待便宜

5. 渐进式自治（Progressive Autonomy）

不是一步到位，是逐步放权。

graph LR A["Level 1
Agent 写代码
人类审所有 PR"] --> B["Level 2
Agent 自审 + 互审
人类抽查"] B --> C["Level 3
Agent 端到端驱动
人类只在需要判断时介入"] C --> D["Level 4
Agent 自主发现问题
复现、修复、验证、合并"] classDef level fill:#1A9090,stroke:#0d5454,color:#fff class A,B,C,D level

OpenAI 团队目前已经到了 Level 4：给一个 prompt，Agent 能验证代码库状态 → 复现 bug → 录屏 → 修复 → 验证 → 再录屏 → 开 PR → 响应反馈 → 处理构建失败 → 必要时升级给人类 → 合并。

但他们也坦言：这高度依赖仓库的特定结构和工具，不应假设可以直接泛化。

要素总览

要素	核心动作	反模式
仓库即真相源	所有知识版本化入库	知识散落在 Slack、Google Docs、人脑中
机械化架构约束	自定义 linter + 结构化测试	靠口头约定或 wiki 文档
Agent 可观测性	独立可观测性栈 + 浏览器驱动	Agent 只能写代码，看不到运行效果
持续质量治理	后台 Agent 定期扫描修复	每周五手动清理"AI 垃圾"
渐进式自治	逐步放权，编码信任	要么完全不信任，要么一步到位

写在最后

读完 OpenAI 的这篇实践，有几个想法想分享。

第一，这是一个基于全新仓库的实验。 从空仓库开始，面向 Agent 构建，没有历史包袱。Martin Fowler 提出的那个问题很尖锐：老项目怎么办？给一个从来没跑过静态分析的代码库装上 harness，大概率会被告警淹没。这是大多数团队面临的现实。

第二，国内现有开发流程的转变会更困难。 很多团队的最终 QA 基本全依赖测试团队的手工测试，开发自己写的单元测试覆盖率低、集成测试缺失、文档更新不及时。这种模式下，Agent 根本没有足够的上下文来理解系统行为。要落地 Harness Engineering，不是加个工具的问题，而是要重建整个质量保障体系------这对很多团队来说，可能比重写代码还难。

第三，AI 编程会惩罚每一个没有好好遵循软件开发流程的人。 这句话听起来有点刺耳，但确实是这篇文章给我最大的启发。那些你一直觉得"以后再补"的东西------软件文档、测试用例、边界定义、架构规范------在 AI 原生开发的世界里，不是锦上添花，而是基础设施。Agent 需要这些东西来理解你的系统，才能自动介入。

第四，纪律没有消失，只是换了个地方。 OpenAI 团队的原话是："Building software still demands discipline, but the discipline shows up more in the scaffolding rather than the code."（构建软件仍然需要纪律，但纪律更多体现在脚手架而非代码本身。）

问题到这里还没结束。Harness Engineering 目前还是一个很早期的概念，OpenAI 自己也承认不知道这套体系在年级尺度上的架构一致性会如何演化。但方向已经很清楚了：未来的软件工程，不是写更多的代码，而是建更好的缰绳。