其实在不少 AI Coding 的内容下，一直有不少人说，AI 写的代码不够好用，甚至感觉很傻，是不是自己的大模型能力不行？为什么感觉我的 AI 和别人的 AI 好像不是一个东西？这个效果怎么可以上生产？
实际上还真不是，虽然说不同大模型的能力上限确实是一个原因，但是实际你对 AI 工程的管理方式，还有你使用的 Agent 工具，也是影响 AI 编程结果的核心因素，例如：
同样是 Claude ，但是它在 Claude Code、Cursor、Antigravity 、Copilot、OpenCode、Kiro 和 Junie 里的表现可是天差地别，孰好孰坏就不用我多说了吧？
另外你是在单纯 Prompt AI 还是管理 AI 工程，整个生产体验也会不一样，用 AI 不是说完几句话就可以不管等结果，比如常见的 SDD （Spec-Driven Development）的开发管理方式，它就需要很多文档来进行迭代、记录和索引：
当然，我们今天要说的是 OpenAI 的 AI 工程实践，讲的是：
OpenAI 如何使用 Codex ，在五个月内完全不使用任何人工代码来构建并发布一款产品。
首先 OpenAI 明确了一个核心观点：软件工程的核心正在从「写代码」转向「构建 AI 执行系统」（harness），工程师不再是“写代码的人”，而是设计 AI 工作环境的人。
他们主要是做了一个真实的生产实验，通过 3 名工程师，在五个月的时间，完全通过 codex 完成一个 100 万行代码的项目，期间所有代码、测试、CI、文档都由 Codex agents 自动生成，而人主要负责定义规则、结构和流程。
OpenAI 在这里用 Harness Engineering 来表示这个场景，可以简单理解 Harness Engineering = 为 AI Agent 构建运行系统，它负责控制 agent、提供工具、管理执行和校验结果。
这里需要五个月的时间，主要是因为项目早期进展太慢，瓶颈也不是出在 Codex 上，而是因为环境定义不够完善，导致 Agent 缺乏实现高层目标所需的工具、抽象概念和内部结构，这就和我们之前说的一样，我们没给 AI 一个完善的 Agent 运行条件，所以很多不必要的人工介入和返工都是在这里产生。
很多时候你的 token 就是这样浪费的。
针对这个，OpenAI 提供了一个 Harness 的核心实践经验：
1、 Context Engineering
你需要给 AI 足够的上下文，因为 agent 的能力高度依赖上下文，你给的需求描述，决定了每次 Token 消费的有效性，例如常见有：
- repo 文档
- API 文档
- 代码结构
- 设计规范
这个有个最重要的是，不要设计一个大型的 AGENTS.md 文件，这是很致命的一个问题，这个我们在《GENTS.md 真的对 AI Coding 有用吗》 聊过，冗长的文档反而会产生副作用， OpenAI 也是这样， AGENTS.md 只是作为目录， AGENTS.md 只保留了大约 100 行，主要用做映射，并提供指向其他更深层次的链接：
AGENTS.md
ARCHITECTURE.md
docs/
├── design-docs/
│ ├── index.md
│ ├── core-beliefs.md
│ └── ...
├── exec-plans/
│ ├── active/
│ ├── completed/
│ └── tech-debt-tracker.md
├── generated/
│ └── db-schema.md
├── product-specs/
│ ├── index.md
│ ├── new-user-onboarding.md
│ └── ...
├── references/
│ ├── design-system-reference-llms.txt
│ ├── nixpacks-llms.txt
│ ├── uv-llms.txt
│ └── ...
├── DESIGN.md
├── FRONTEND.md
├── PLANS.md
├── PRODUCT_SENSE.md
├── QUALITY_SCORE.md
├── RELIABILITY.md
└── SECURITY.md
比如在这里：
- 设计文档也是一个目录，里面包括验证状态和一套定义以 Agent 为主的运行原则
- 架构文档提供了域和包分层的顶层映射图
- 架构文档提供了域和包分层的顶层映射图
- plan 分形态，轻量级的临时计划用于小的变更，而复杂的工作则记录在执行计划中 ，并附带进度和决策日志，这些日志会被提交到代码库
这些文件结构，可以有效让 Agent 能够循序渐进从一个较小的、稳定的切入点开始，并理解下一步该关注什么，而不是一开始就被大量信息淹没上下文。
2、 Tooling
让 agent 能执行真实操作，不是每次由人工来执行，例如：
- Git
- shell
- CI
- test runner
- build system
因为 agent 不只是会生成代码，而是 写代码 → 运行 → 修复 这样的流程闭环，才是 Agent 完整的能力，例如：
让 Codex 在本地审查自己的修改，同时请求本地和云端的其他特定 Agent 进行审查，并响应任何反馈，循环迭代，直到所有 Agent 审查都满意为止（实际上就是一个 Ralph Wiggum 循环 ）。
这个过程里 Codex 直接使用标准开发工具（gh、本地脚本和嵌入在代码库中的技能）来收集上下文信息，不需要人工复制粘贴到命令行界面。
这里换个 agent 审核很重要， 因为就算时间同一个模型，换个上下文窗口就很容易找到自己写的 bug， 因为干净的上下文可以脱离 author 的思维惯性，所以在 AI 开发里，review 肯定不要在当前窗口，用一个 subagnet 或者新的窗口才会有真的 review 效果。
OpenAI 还让项目 App 能够根据 Git Worktree 单独启动，这样 Codex 每次更改都可以启动并运行一个实例，可以同时并行进行项目修改和调整验证。
3 、Feedback loops
Agent 需要一个完整的自动反馈系统，例如
- CI
- 单元测试
- linter
- 静态分析
只有这样 Agent 才能实现自驱动，这也是很多 AI Coding 里经常确实的环节，因为只有明确的测试约束和验收标准，才能让 AI 实现自验自测，减少人工介入：
agent 写代码
→ 测试失败
→ agent 修复
→ 再次运行
在 OpenAI 这个项目里，项目的日志、指标和追踪信息通过一个本地可观测性堆栈暴露给 Codex，这个堆栈对于任何给定的Worktree 都是临时场景。
Codex 运行在完全隔离版本上，其中包括对应的日志和指标，这些日志和指标会在任务完成后被销毁，而 Agnet 可以使用 LogQL 查询日志，使用 PromQL 查询指标，有了这些上下文信息，诸如“确保服务启动在 800 毫秒内完成”或“这四个关键用户旅程中的任何跨度均不超过两秒”之类的提示，对于AI 就变得更好处理。
4、 Architectural Constraints
最后，限制 AI 的行为也很重要，例如：
- 代码结构
- 模块边界
- API 规则
- lint rules
这些规则让 agent 不会写出混乱代码，并尽可能按照规范来输出代码，这里有一个比较有意思的是：最好的 Agent 管理就是让 Agent 能够直接从代码库中推断出完整的业务领域。
所以作为工程师，需要在代码里逐步添加更多上下文信息，比如「讨论某些讨论的需求结论」，「针对某个需求变更需要做什么调整」，这些都是很重要的架构和约束信息， Agent 才不会在某些修改，把迭代了三次的按键又改回了第一版的 UI 。
另外， Agent 在边界清晰、结构可预测的环境里最有效，所以一个层级分明，流向清晰的结构才是最利于 Agent 维护，例如：
在每个业务领域（例如应用设置）内，代码只能通过一组固定的层级（类型 → 配置 → 存储库 → 服务 → 运行时 → 用户界面）进行“前向”依赖，而横切关注点（身份验证、连接器、遥测、功能标志）通过一个明确的接口Providers 进入，任何其他方式都被禁止，并且会强制执行。
目的很简单，就是：集中执行边界，允许本地自主，在 OpenAI 的观点里，生成的代码不一定总是符合人类的风格偏好，但这没关系，只要输出正确、易于维护，并且便于后续代理运行，就达到了标准。
事实上如果一个管理得当的 Agent 工程，在后期可以实现非常高效的并向开发能力，比如多 Agnet 多 Worktree ：
Planner Agent
│
┌───────────────┼───────────────┐
│ │ │
Code Agent1 Code Agent2 Code Agent3
│ │ │
Worktree1 Worktree2 Worktree3
│ │ │
Test Test Test
│ │ │
└────── Merge / PR ────────┘
这时候每个 Agent 可以同步处理一个 Bug 或者一个 Feature ，然后基于对应的 Git worktree 去验证和实施，最终再合并提交结果。
所以，可以看到，在古法编程里，传统软件开发是：
设计
→ 写代码
→ 测试
→ 部署
而在 Agent-first 开发场景下，工程师的只能变成了：
设计 harness
→ agent 生成代码
→ agent 测试
→ agent 修复
→ agent 提交 PR
而在这个场景里，工程师主要负责 review、架构设计、信息输入和方向决策，同时 OpenAI 也在过程中提供了对应实验经验：
- 复杂技术对 AI 不友好，所以优先选择：boring technologies、标准库、明确 API ，这些 AI 更好理解的技术方向
- 文档不是给人看的，而是给 agent，前面我们聊过，文档要编程机器可读上下文
- 小任务效果优于大任务，细分任务很重要
- 自动反馈很重要，就像是前面我们聊过的，尽可能让 AI 获取问题自己测试，自己反馈，比如我在 Flutter 场景，Agent 就会自己修改后直接运行
flutter run，并通过终端实时获取日志查看是否有问题
从这个我们可以看出来，目前 AI 产品的竞争力不在模型，而在 harness，好的 harness 比如 Claude Code，Codex 是能决定模型的上限，因为 harness 可以决定：
- AI 能访问什么工具
- AI 能获得多少上下文
- AI 能否自我修复
所以，现在你明白了，为什么 AI Coding 不是简单的 Prompt Engineering ，而应该是一个 Harness Engineering，因为你的项目需要持续迭代，也需要持续修改，AI 是健忘的，你任务就是让它可以在需要时轻松想到过去，再实现未来。
而开发者也正在从设计代码的角色，转向设计 AI 和 Agent 运行环境的角色。
PUA
当然，如果前面的对你来说太难，你可以试试用这个 pua-skill.pages.dev/ 这个 PUA Skills 来提升你的 AI 效果。
要知道 AI 最擅长的就是最短路线实现，说人话就是： AI 很擅长偷懒，而 AI 的每次「磨洋工」，都会给你带来 Token 的浪费，所以这时候 PUA 这个 Skill 就起到了意想不到的作用。
最主要这个 Skill 还通过了不同大厂的 PUA 风格，并给出了对应的评分效果，比如：
- 阿里的闻味道 / 揪头发 / 照镜子 方法论驱动，强制 5 步结构化思考，产出可追溯的调试链路，适合复杂多层 bug：「你的方法论沉淀在哪？你的体系化思考能力呢？」
- ByteDance 的坦诚直接上强度，速度优先，直接指出问题，适合明确的单点 bug 「坦诚直接地说，你这个 debug 能力不行，Context, not control」
另外，可以看到在作者提供的数据里，PUA 对 AI 来说确实可以起到一定作用，特别是出现错误场景的情况下，不得不佩服这个作者的脑洞：
所以，如果你觉得 AI Harness 方法论太麻烦了，或者可以体验下这个 Skill 。
