OpenAi 引出 Harness Engineering概念

原文：https://openai.com/index/harness-engineering/

核心成就：从 0 到 100 万行代码

• 零人工编码：所有的应用程序逻辑、测试、配置、文档和工具链全部由 Codex 编写。
• 极高的效率：3 到 7 名工程师在 5 个月内完成了通常需要数倍时间的任务，处理了约 1500 个拉取请求（PR）。
• 真实运行：这不仅仅是个 Demo，而是一个拥有数百名内部和外部用户的真实产品。

---

五大关键工程策略

1. 重新定义工程师的角色

在“智能体先行”的世界里，工程师不再是“码农”，而是系统架构师和环境设计师。

• 工作重心：不再是纠结语法，而是设计环境、指定意图（Prompt）并构建反馈回路。
• 深度优先解决问题：当 AI 无法完成任务时，工程师不接手写代码，而是反思“AI 缺少什么工具或信息？”，然后为 AI 提供这些能力。

2. 精简的上下文管理（地图而非手册）

AI 的上下文空间是有限的，给它 1000 页的说明书会适得其反。

• 地图模式：项目根目录的 AGENTS.md 仅有约 100 行，作为导航地图，指引 AI 去哪里寻找具体的文档或代码。
• 渐进式披露：只给 AI 当前任务相关的最核心信息，避免信息过载导致 AI 犯错。

3. 让应用程序对 AI “可读”

为了让 AI 能自己修复 Bug，团队构建了专门供 AI 使用的观测工具：

• AI 专用调试：集成 Chrome DevTools 协议，让 AI 能直接获取 DOM 快照和截图。
• 临时观测堆栈：为 AI 的每一次代码运行生成临时的日志（Log）和指标（Metrics）系统，AI 可以通过查询语句（如 PromQL）自行分析性能瓶颈。

4. 强制性的架构与“审美”

为了防止 100 万行代码变成一团乱麻，团队设定了极其严格的规则：

• 分层架构：代码必须按照固定的层级（类型 -> 配置 -> 服务 -> UI）单向依赖。
• 自动执法：通过 AI 编写的自定义代码检查工具（Linters）强制执行这些规则。一旦 AI 偏离架构，系统会自动拦截并报错。

5. 持续的“垃圾回收”

AI 容易产生“AI 废话（Slop）”或者重复低效的模式。

• 金科玉律（Golden Principles）：将人类的编程审美（如“优先使用共享包”而非“手写助手函数”）编码进系统。
• 自动重构：运行后台 AI 任务，定期扫描代码库中的坏习惯，并自动发起重构 PR 进行清理。

---

结论与启示

这种模式证明了：软件工程的本质正在从“编写”转向“管理”。虽然代码是 AI 写的，但纪律性（Discipline）反而变得更加重要。工程师需要花费更多精力去设计脚手架、抽象层和反馈系统，从而驾驭 AI 释放出指数级的生产力。

您想了解文中提到的具体技术细节（如具体的架构图）吗？或者需要我为您总结其中关于“AI 自动化工作流”的具体步骤？