https://codexer.com/tags/ai-engineering/Recent content in AI Engineering on CodexerHugozh-cnMon, 15 Jun 2026 09:00:00 +0800https://codexer.com/posts/2026-06-15-codex-tech-lead-simple-workflow/Mon, 15 Jun 2026 09:00:00 +0800https://codexer.com/posts/2026-06-15-codex-tech-lead-simple-workflow/<p>如果你以为 OpenAI 内部使用 Codex 的方式一定很&quot;炫技&quot;，那你可能会失望。</p> <p>工程领导力通讯的作者 Gregor Ojstersek 最近拜访了 OpenAI 旧金山办公室，和 Codex 开源项目的技术负责人 Michael Bolin 聊了聊。Michael 之前在 Meta 是 Distinguished Engineer，参与创建了开源构建工具 Buck，还写过一本关于 Google Closure 的技术书。</p> <p>当他展示自己的 AI 辅助工程工作流时，Gregor 最大的感受是：<strong>太简单了。</strong></p> <blockquote> <p>写规范 → 下指令 → 审代码。</p> </blockquote> <p>就这三步。没有眼花缭乱的多 Agent 编排，没有精心设计的提示词模板，没有复杂的自动化流水线。只有清晰的思考、准确的判断和快速的迭代。</p> <h2 id="从权限系统说起">从权限系统说起</h2> <p>他们聊的项目是 Codex CLI 的权限系统，一个面向企业用户的大功能。企业客户需要功能丰富，但同时也需要精细的权限控制：谁能用什么功能、AI 能访问和修改什么、沙箱边界的约束等等。这个项目团队做了好几个月，规模不小。</p> <p>但整个流程的起点，是一个 Notion 文档。</p> <p>Michael 在 Notion 里写了技术规范，描述了需要支持的需求和功能。然后让团队成员 review、提意见、补充遗漏、讨论方案。等所有人的意见都被回应、规范定稿之后，才开始动手写代码。</p> <p>这个&quot;先写规范&quot;的步骤，Michael 认为至关重要。它不是 AI 时代的什么新花样，而是老派工程师的基本功：<strong>想清楚再动手。</strong></p> <h2 id="notion-连接器上下文的神来之笔">Notion 连接器：上下文的神来之笔</h2> <p>正式开始编码时，Michael 没有把需求复制粘贴给 Codex，而是直接贴了一个 Notion 链接。</p> <p>Codex 的 Notion 连接器会直接读取文档内容，包括需求描述、团队评论和讨论历史。相比手动复制粘贴并重建上下文，这种直接&quot;喂原始资料&quot;的方式让 Michael 赞不绝口。</p> <p>他的第一句指令也很直接：<strong>&ldquo;现在我想构建这个。先做一个计划，把工作拆分成合适大小的 PR。&rdquo;</strong></p>