Harness Engineering：当人类不再写代码，软件工程反而更高效在未来的软件工程领域，随着人工智能和自动化技术的发展，Harness Engineering（可理解为工具链工程或自动化工程）可能会成为主流。这种趋势下，软件工程可能会变得更加高效

Harness Engineering：当人类不再写代码，软件工程反而更"工程"了 导语 2026 年 2 月，OpenAI 发了一篇博客，标题是 Harness engineering: leveraging Codex in an agent-first world。 文章讲了一件听起来挺疯狂的事：他们用 Codex Agent 从零构建了一个软件产品，五个月交付上线，代码量约一百万行——没有一行是人写的。 不是"大部分由 AI 生成"，不是"人写框架 AI 填细节"，而是从第一个 git commit 开始，应用逻辑、测试、CI 配置、API 文档、内部工具、可观测性堆栈——全部由 Codex 自主产出。人类工程师全程只做一件事：设计环境，然后看着 Agent 干活。 这篇文章在技术圈引发了剧烈讨论。有人说这是"软件工程的终结"，有人说这是"新一轮炒作"。 我觉得都不对。这是软件工程的一次范式迁移——工程师不是消失了，而是从"写代码的人"变成了"设计笼子的人"。 OpenAI 管这套方法论叫 Harness Engineering。Harness 这个词很妙——它既有"驾驭"的意思（驾驭一匹烈马），也有"挽具"的意思（套在马身上的缰绳和鞍具）。一个词同时说清了两件事：Agent 是干活的马，工程师是造缰绳的人。 这篇文章拆解这套方法论的核心思路、技术细节和工程哲学。 原文：https://openai.com/index/harness-engineering/ 一、先看数据：3 个人，5 个月，100 万行代码 在聊方法论之前，先感受一下这个实验的规模： 指标 数据 开发周期 5 个月 起始团队 3 名工程师 后期团队 7 名工程师 代码规模 ~100 万行 人工编写的代码 0 行 处理的 PR 数量 ~1,500 个 人均日处理 PR 3.5 个 效率提升 相比手写代码快 ~10 倍 产品状态 已上线，有内部 DAU 和外部 Alpha 测试者 3 个人，每天处理 3.5 个 PR，5 个月干了 1500 个 PR。 如果是传统开发模式，这至少需要 20-30 人的团队。 但更值得注意的是后面发生的事：团队从 3 人扩展到 7 人后，吞吐量不但没有因为沟通成本增加而下降，反而继续增长。这违反了布鲁克斯法则（"向进度落后的软件项目增加人手，只会使其更加落后"），说明这套工作方式的扩展性和传统团队完全不同。 为什么？因为人和人之间几乎没有代码层面的依赖了。每个工程师面对的不是"我在写的代码和你在写的代码会不会冲突"，而是"我设计的环境和你设计的环境是否兼容"。后者的耦合度天然更低。 二、核心理念：人类掌舵，Agent 划桨 Harness Engineering 的核心观点可以浓缩为一句话： 工程师的工作不再是编写代码，而是设计环境、明确意图、构建反馈回路。 这三个词值得展开说。 2.1 设计环境 传统软件工程中，"环境"是指开发环境——IDE、编译器、依赖管理。在 Harness Engineering 中，"环境"的含义被极大扩展：你的整个代码仓库、架构约束、Linter 规则、文档结构、CI 管线，都是 Agent 的运行环境。 Agent 不是在"你的代码库里帮你写代码"，而是"在你设计的环境里自主完成任务"。环境设计得好，Agent 写出的代码自然规范；环境设计得烂，Agent 就会四处漂移。 这有点像城市规划：你不需要亲自盖每一栋楼，但你需要划定道路、规定容积率、制定建筑规范。楼是开发商盖的，但城市的样子是规划师决定的。 2.2 明确意图 传统开发中，PM 写 PRD，工程师理解需求后写代码。在 Harness Engineering 中，工程师做的事更接近 PM：把模糊的大目标拆解成 Agent 能执行的小任务序列。 OpenAI 团队称之为"深度优先工作法"： 把一个大功能拆成多个独立模块 每个模块进一步拆成设计 → 编码 → 测试 → 评审 每一步都明确输入、输出和验收标准 然后提示 Agent 逐个构建 注意：这不是"写更好的 Prompt"。这是把软件架构的思维方式从"我怎么实现这个功能"迁移到"我怎么描述这个功能，使得 Agent 能独立实现它"。两者的抽象层次完全不同。 2.3 构建反馈回路 这是最关键的一环。Agent 会犯错，会漂移，会产生低质量代码。Harness Engineering 的核心信仰不是"Agent 不会出错"，而是"出错了能快速被发现和纠正"。