如果你以为 OpenAI 内部使用 Codex 的方式一定很"炫技"，那你可能会失望。

工程领导力通讯的作者 Gregor Ojstersek 最近拜访了 OpenAI 旧金山办公室，和 Codex 开源项目的技术负责人 Michael Bolin 聊了聊。Michael 之前在 Meta 是 Distinguished Engineer，参与创建了开源构建工具 Buck，还写过一本关于 Google Closure 的技术书。

当他展示自己的 AI 辅助工程工作流时，Gregor 最大的感受是：太简单了。

写规范 → 下指令 → 审代码。

就这三步。没有眼花缭乱的多 Agent 编排，没有精心设计的提示词模板，没有复杂的自动化流水线。只有清晰的思考、准确的判断和快速的迭代。

从权限系统说起#

他们聊的项目是 Codex CLI 的权限系统，一个面向企业用户的大功能。企业客户需要功能丰富，但同时也需要精细的权限控制：谁能用什么功能、AI 能访问和修改什么、沙箱边界的约束等等。这个项目团队做了好几个月，规模不小。

但整个流程的起点，是一个 Notion 文档。

Michael 在 Notion 里写了技术规范，描述了需要支持的需求和功能。然后让团队成员 review、提意见、补充遗漏、讨论方案。等所有人的意见都被回应、规范定稿之后，才开始动手写代码。

这个"先写规范"的步骤，Michael 认为至关重要。它不是 AI 时代的什么新花样，而是老派工程师的基本功：想清楚再动手。

Notion 连接器：上下文的神来之笔#

正式开始编码时，Michael 没有把需求复制粘贴给 Codex，而是直接贴了一个 Notion 链接。

Codex 的 Notion 连接器会直接读取文档内容，包括需求描述、团队评论和讨论历史。相比手动复制粘贴并重建上下文，这种直接"喂原始资料"的方式让 Michael 赞不绝口。

他的第一句指令也很直接：“现在我想构建这个。先做一个计划，把工作拆分成合适大小的 PR。”

Michael 特别强调，他不想要 2000 行的巨型 PR，因为最终是人要去 review 的。Codex 初步生成的代码被拆成 6 个 PR，然后他们逐个 review、测试、处理合并冲突、迭代优化。

这个数字很有意思。2000 行拆成 6 个 PR，平均每个 300 多行，这是一个人类工程师 comfortable 的 review 粒度。Michael 说，他经常提醒 Codex：“有人要 review 这些代码，拆成人类能看的大小。”

合并冲突让 AI 来处理#

我问 Michael，AI 生成的代码处理合并冲突会不会很痛苦？毕竟同时开着好几个 PR，可能都在改同一个文件。

他的回答出乎意料：Codex 处理合并冲突比他本人更有纪律性。

他写了一个专门的 skill（Codex 的自定义指令集），里面定义了处理合并冲突的规范流程。其他工程师在并行修改代码时，他只需要把这个 skill 交给 Codex，让 AI 自己去处理冲突。一致、可靠、不偷懒。

为什么让 AI 直接创建 PR#

目前大多数工程师偏好"AI 辅助"模式：用 Cursor、Claude Code 或者 Codex 在本地写代码，人来做最后的提交。但 Michael 偏好另一种方式：让 Codex 直接创建 PR。

他的理由非常务实：CI 要跑 15 到 20 分钟。

与其等人写完代码再推上去等 CI，不如让 Codex 创建 PR 的瞬间 CI 就开始跑。他们还建了一个叫"babysitting PRs"的 skill，一旦 PR 创建好了，Codex 会自动盯着 CI 的运行状态，失败了就自动修复。

他还有一个反直觉的做法：不让 Codex 在本地跑大部分测试。 因为 CI 会在 Mac、Linux、Windows 三个平台上都跑一遍，本地跑全套测试只会浪费机器资源。想象一下，同时处理 5 到 6 个改动，如果每个都跑全量测试，本机基本上就没法干活了。

与其在本地耗着，不如把 PR 推上去让 CI 并行跑，人继续做下一件事。

用好"相关 PR"这个金矿#

Michael 还有一个常被忽视的习惯：引用关联的 PR。

在做新功能时，他会把相关的历史 PR 链接给 Codex。这些 PR 里包含代码变更、讨论、评论和决策。把这些上下文喂给 AI，能显著提升它理解代码库和做出正确判断的能力。

这其实是一种"授人以渔"：不是每次都从头解释需求，而是让 AI 自己去读相关的历史决策。

大 PR 的终结者#

Michael 提到，过去他经常因为 PR 太大而拒绝别人的提交，这在以前可能会引起争论，因为拆分工作本来就需要额外精力。但 AI 时代不一样了：你只需要对 Codex 说一句"帮我拆成更小的 PR"，它就做了。

这让"可审查的 PR 尺寸"从争论变成了一个可以自动执行的标准。每个 PR 做什么、改了什么，一清二楚。

朴素背后的原则#

Michael 的工作流之所以让人意外，不是因为它"炫"，恰恰是因为它"不炫"。它回到了一些最基本的工程原则：

  • 先想清楚再编码。 规范不是给 AI 看的，是给自己和团队看的。
  • 控制批处理大小。 人不擅长 review 2000 行的 diff，不管代码是谁写的。
  • 善用上下文。 给 AI 喂原始资料（Notion 链接、相关 PR）比手写提示词更有效。
  • 并行优于串行。 CI 能并行跑就不要在本地跑，把等待时间交给机器。
  • 工具为人服务。 让 AI 处理重复性工作（合并冲突、CI 监控），人专注于判断和设计。

这些原则在 AI 出现之前就已经存在，只不过 AI 让它们更容易执行。

总结#

看完 Michael 的分享，我最大的感受是：AI 辅助工程的真谛不在于"用 AI 做了什么了不起的事"，而在于"用 AI 把原本就应该做的事情做得更好、更快、更一致"。

写规范、拆 PR、控粒度、跑 CI、引上下文，这些都是经典软件工程实践。AI 不是来取代它们的，而是来放大它们的效果的。

有时候最好的技术实践，就是那些朴素到让人忘记它其实是"最佳实践"的东西。

参考来源：