大多数人用 AI 编程助手的方式，其实是错的。
包括我自己。之前用 GitHub Copilot，后来又试了 Cursor、Claude Code 和 Codex。刚开始觉得挺神奇，让 AI 生成一段代码，几分钟就出来了。用多了就发现不对劲，生成的代码虽然能跑，质量参差不齐。有时候代码越改越乱，还不如自己写。
直到看了 OpenAI 工程师的实战分享，我才明白问题出在哪。
他们用 Codex 在 28 天内开发了 Sora Android 应用。4 个工程师，50 亿 tokens，搞定一个生产级应用。
OpenAI 有什么秘密武器吗？其实并没有。他们用的也就是已经开源的 Codex，现在任何开发者都可以安装使用。关键在于怎么用。
OpenAI 的核心就四个步骤：把 AI 当新员工培训，用计划文档引导长任务，让多个 AI 并行工作，重新定位人的角色。今天，我就带你一起看看 OpenAI 工程师是如何做到的。
大多数人踩过的坑
最常见的 AI 编程用法是什么？给 AI 扔一句话：帮我从零构建一个 XXX 应用。
OpenAI 的工程师也试过。开发 Sora Android 时，他们最初就是这么干的，给 Codex 提示词：根据 iOS 代码构建 Sora Android 应用，开始吧。结果呢？代码倒是生成了一大堆，技术上能跑，但产品体验很差，代码也不可靠。他们很快就放弃了。
AI 生成的代码为什么会这样？说白了，AI 的本能是让东西跑起来，而不是考虑长期可维护性。本该扩展现有的 view model，它却新建了一个；明明业务逻辑应该在 repository 层，它却放在 UI 层。用 OpenAI 工程师的话说，Codex 的本能是让东西跑起来，而不是优先考虑长期的代码整洁度。
真相其实很简单。AI 编程助手不是魔法棒，而是一个刚入职的高级工程师。能力很强，但需要入职培训，需要了解团队规范，需要明确的任务目标。
既然 AI 是个新员工，那就得按照新员工的方式来对待，先不着急开始干活，做好入职培训才是第一步。
第一步：先建地基，再盖大楼
时间紧，项目重，怎么办呢？ Fred Brooks 有句名言：给一个延迟的软件项目增加人手，只会让它更晚完成。OpenAI 团队没有违背这个定律，而是用了一个巧妙的方式：每个工程师都配备了 Codex，大幅提升单个工程师的影响力。
同时，在项目启动阶段，OpenAI 团队花了大量时间建立基础架构。手动设计模块化、依赖注入、导航系统，人工实现了身份验证和基础网络层。再亲手写了几个代表性功能，展示整个代码库应该遵循的规则和模式。
有了这些基础，再让 AI 参考这些文档和代表性功能列表，最终 Codex 写了大约 85% 的代码。但正是那精心设计的 15% 的基础，避免了后期昂贵的重构和返工。
当然，光有基础架构还不够。有些任务可能要跑几个小时，甚至一整夜。这种长时间任务怎么让 AI 保持在正确的轨道上？这是第二个关键点。
第二步：用计划文档引导长时间任务
OpenAI 工程师 Friel 在《Vibe Engineering with OpenAI’s Codex》中分享了一个案例：用 Codex 将一个构建工具从 Kotlin 完全重写为 Rust。从零开始，空目录，要求 100% 兼容原项目，包含完整的测试套件。
Rewrite https://github.com/Tinder/bazel-diff.git in Rust as bazel-differrous, starting from scratch in this empty dir.
Use that repo as a submodule to write tests against. Use an execplan in plans/ to track your work and complete all of these requirements autonomously.
Your driving goal is 100% full CLI compatibility between bazel-diff and bazel-differrous.
Definition of done:
- [ ] Well structured, modular implementation in modern, async Rust, with support for tracing, profiling, etc.
- [ ] Design documents and other written artifacts in docs/ describing decisions made architecting the project
- [] Thorough support for Bazel Bazel and Bazel Bazel "bzlmod" system, including new tests using MODULE. bazel.
- [ ] Full CLI compatibility as a drop-in replacement for bazel-diff
- [ ] Passing tests with a test harness you write that verifies output is byte-for-byte equal to bazel-diff
- [ ] A comprehensive test suite with at least ten times the tests as bazel-diff
- [ ] Use 'cargo-nextest' with timeouts to ensure tests are fast and reliable
- [ ] GitHub Actions tested with 'nektos/act' to build, test, format, and lint
- [ ] A 'Justfile" which can build, run tests, and verify all of the claims above
- [ ] A great CONTRIBUTORS. md and other repository documentation
- [ ] README. md describing bazel-differous and showcasing its performance improvements over bazel-diff
- [ ] CREDITS! Credit the authors of bazel-diff for creating a great tool and the Bazel community
结果？Codex 独立工作了约 12 小时，完成了整个重写。
12 小时的运行产生了什么？不是 10 万行垃圾代码，而是约 500 行高质量代码、超过 200 轮的测试迭代、通过所有 CI 检查，还有完整的文档。这些代码被直接合并到了生产环境。
关键就在于 Exec Plan 这个东西。执行计划。
在开始实际编码前，让 Codex 先理解系统，读取相关文件，总结功能如何工作；制定计划，创建一个迷你设计文档，说明哪些文件需要修改、引入哪些新状态、逻辑如何流动；保存计划到文件中，以便跨会话使用；最后按照计划，一步步实现。
对于长时间运行的任务，Codex 还会创建一个监督者子代理，定期提醒主代理：这是你的总体目标，这是用户的要求，保持专注。
掌握了单个 AI 的用法，还可以更进一步。这是第三个技巧。
第三步：把一个 AI 变成一个团队
OpenAI 的 Codex 支持一个叫 Best of N 的功能（目前仅在 Codex Cloud 中支持）。用同一个提示词，让 4 个 Codex 实例同时工作，探索不同的实现方案。完成后，你会看到 4 个不同方案的实现细节，可以选择最好的那个，或者从每个方案中汲取灵感。
在 Sora Android 项目的高峰期，OpenAI 团队经常同时运行多个 Codex 会话。一个在做视频播放，一个在做搜索功能，一个在处理错误处理，有时还有一个在写测试或做重构。感觉不再像是用一个 AI 编程工具，而更像是在管理一个 AI. 团队。
但这也带来新的挑战。开发瓶颈从写代码变成了做决策、给反馈和集成变更。你从独奏者变成了乐队指挥。每增加一只虚拟的手，都会增加协调成本。
说到这里，可能有人会问：AI 能干这么多活，那工程师还要干什么？这正是我想说的第四点。
第四步：重新定位人类的角色
在 OpenAI 内部，超过 92% 的技术人员在使用 Codex。所有的 Pull Request 都会经过 Codex 审查。结果是捕获了很多复杂的 bug，工程师平均产出的 PR 数量增加了 70%，但这些都是真正合并到生产环境的高质量 PR。
如果 Codex 写了 85% 的代码，工程师在做什么？
架构和系统设计还是要人来做。Codex 不擅长做长期权衡，不知道如何在可维护性、性能和开发速度之间找到平衡。用户体验也离不开人。Codex 看不到应用实际运行的样子，不能注意到滚动感觉不对，或者某个流程令人困惑。
产品方向和品味更是要人来把握。如果你是那个对某个问题痴迷了数月或数年的人，你就拥有独特的视角来决定解决方案应该是什么样的。
代码审查变得更重要了。人类从写代码转向审查代码。但这不是负担，因为你有更多时间仔细阅读 PR、思考架构、测试应用。
有趣的是，OpenAI 内部不仅工程师在用 Codex，非技术团队也在用。产品经理用 Codex 创建功能原型，销售团队用 Codex 提出关于代码库的技术问题。这减轻了工程师的负担。
明天的超级工程师需要深刻的系统理解，需要与 AI 长期协作的能力，还需要品味和判断力。
写在最后
总结一下，OpenAI 工程师的实战经验可以归纳为几个核心原则：
把 Codex 当作新入职的高级工程师对待。它有能力，但需要入职培训和明确的指导。
先建立基础和规范。创建 AGENTS.md 文件，记录代码风格、架构模式、团队惯例。用代码展示而非文字描述，手写 1-2 个代表性功能，让 AI 从中学习。
对于复杂任务，使用计划文档。先让 AI 理解系统、制定计划，再编码。代码审查不能省，即使是 AI 写的代码也要认真审查。
给予丰富的上下文，让 AI 访问相关的代码库、文档、已有实现。对于不确定的方案，用 Best of N 并行探索，同时尝试多种方法。
当 CI 失败时，把日志输出粘贴给 AI，让它修复。AI 擅长也乐于编写广泛的单元测试，让它多写。长时间任务往往能产生最好的结果，要有耐心。
也有一些要避免的：
- 不要直接让 AI 构建整个应用，没有上下文和基础的一次性生成质量通常很差。不要跳过架构设计，AI 的本能是让东西跑起来，而不是优先考虑长期可维护性。
- 不要期待 AI 推断你的偏好，每个 AI 实例都需要了解你的架构模式、产品策略、内部规范。不要让 AI 独自做重大架构决策，在哪里引入抽象、如何组织模块这些需要人类判断。
曾经可能需要我们四到六周才能实现的全新功能，现在几天就能完成 V1。这不仅仅是速度的提升，更是一种思维方式的转变。从能做什么到想做什么，从被积压的任务清单压垮到主动探索新的可能性。
当然，AI 的进步也重新定义了软件工程师的工作。写代码的时间少了，但对人的要求反而更高了。你需要理解产品设计、把握架构全局、指导"AI 新员工"、审核它生成的代码、在它出错时把它拉回正轨。从某种意义上说，我们从代码的生产者变成了代码的 orchestrator。
好的工程师不再是写代码最快的那个，而是最会用 AI、最懂架构、判断力最强的那个。
相关资源
- How we used Codex to build Sora for Android in 28 days https://openai.com/index/shipping-sora-for-android-with-codex/
- OpenAI Forum: Vibe Engineering with OpenAI’s Codex https://forum.openai.com/public/clubs/developers-and-startups-y6l6m/videos/event-replay-vibe-engineering-with-openais-codex-2025-12-03
欢迎长按下面的二维码关注 Feisky 公众号，了解更多云原生和 AI 知识。
