Codex 实践 on Codexer

当 AI 开始调教 AI：Codex 与 Claude Code 的智能体优化实战

Fri, 19 Jun 2026 09:00:00 +0800

想象这样一个实验：你给两个 AI 编程助手各自分配一个容器，里面塞进一个 AI 智能体应用、一百条运行日志、一个评分指标，然后告诉它们一件事：「把这个智能体的表现优化到最好」。没有详细的步骤说明，没有专门的评测工具，也没有 prompt 优化框架的 API。就是一个裸容器、一份数据、一个目标。

它们会怎么做？

Andrew Jesson 做了这件事。他把 Claude Code 和 Codex 分别放进相同的容器环境，让它们各自优化五个不同类型的 AI 智能体应用。结果很有意思：两个助手都交出了超越基线的方案。但他更关注的不是结果本身，而是它们在过程中展现出的工程行为。

五个应用，一个任务

实验覆盖了五类智能体应用：

应用领域	任务描述	评分方式
软件工程	在 Linux 环境中完成长周期编程任务	验证器评分（0–1）
商业管理	多轮 CEO 智能体驱动商业模拟	按时完成的任务数
NER 命名实体识别	从句子中提取人名、组织、地点等实体	实体集完全匹配
NDA 合同解析	从 OCR 文本中提取生效日期、管辖地、签约方等	F1 分数
科学研究	从沙箱数据和遮蔽的 PDF 复现天体物理论文	与论文值的二进制匹配

每个应用先用 gpt-5.4-mini 运行基线（最多 100 个任务），产出推理日志和评分反馈。然后优化智能体（Claude Code 用 claude-sonnet-4-6，Codex 用 gpt-5.4）被放进容器，拿到这些数据和一份简短的 skill 文件。

这份 skill 文件说了什么？四句话：浏览数据 → 添加 prompt 变体 → 测试 → 迭代。仅此而已。

当百万行代码没有一行是人写的：OpenAI 用 Codex 从零构建产品的工程实践

Thu, 18 Jun 2026 09:00:00 +0800

想象一下这个场景：你的团队交付了一个产品，代码仓库里有大约一百万行代码，一千五百个 Pull Request，有日常用户在使用，有 alpha 测试者在反馈。一切看起来很正常，对吧？

但有一个细节：这百万行代码里，没有哪怕一行是人类工程师亲手写的。

这不是科幻设定。这是 OpenAI 一个内部团队过去五个月的真实经历。他们用 Codex 从零搭建了一个完整的产品，所有代码，包括应用逻辑、测试、CI 配置、文档、可观测性工具、内部脚本，全部由 AI Agent 生成。人类工程师从未直接提交过任何一行代码。

Ryan Lopopolo 在 OpenAI 官方博客上详细记录了这次实验。这篇文章不是 PR 通稿，而是一份诚实的工程复盘：什么碎了、什么加倍了、人的时间应该花在哪里。我觉得这是近期关于 AI 编程最值得一读的实战报告。

起点：一个空的 Git 仓库

故事开始于 2025 年 8 月底。团队往一个空仓库里做了第一次提交，内容是 Codex CLI 用 GPT-5 生成的初始脚手架：仓库结构、CI 配置、格式化规则、包管理器设置、应用框架。连第一篇 AGENTS.md 文件都是 Agent 自己写的。

没有人类写的「锚定代码」。这意味着整个仓库从一开始就是 Agent 的领地，不存在一个「先由人搭好骨架再由 AI 填充」的阶段。

五个月后，仓库膨胀到百万行级别，贡献了约 1500 个 PR。团队从最初几个人扩展到七名工程师。产品有数百内部用户在使用。

这里有一个反直觉的发现：早期进展比预期慢。不是因为 Codex 不行，而是因为环境不够「具象」。Agent 缺少工具、抽象层和内部结构来支撑它朝高层目标前进。

换句话说，Codex 不是缺算力，而是缺 context。

第一条教训：给 Agent 一张地图，别给一千页说明书

团队最初试过一个朴素的策略：把所有规则写进一个巨大的 AGENTS.md。结果呢？惨败。

问题有三个层面。第一，巨大的指令文件会挤占任务的上下文空间，Agent 要么漏掉关键约束，要么开始优化错误的优先级。第二，当所有东西都被标记为「重要」时，就没什么是重要的了，Agent 变成了局部模式匹配而非全局导航。第三，单体文档变成过时规则的坟场，Agent 分不清哪些还适用，人类也懒得维护。

他们的解决方案是把知识库结构化为一个分层的目录系统。核心的 AGENTS.md 只有大约 100 行，起的是 「地图」 的作用，而非「百科全书」。它告诉 Agent 去哪里找设计文档、架构决策记录、质量评分、领域边界说明。

Codex 进阶手册：六个支柱解锁 AI 编程助手 100% 潜能

Wed, 17 Jun 2026 09:00:00 +0800

你很可能用错了 Codex。

不是说你做了什么明显的蠢事。恰恰相反：Codex 的工作方式本身就反直觉。你以为它是一个更聪明的 ChatGPT，但它其实更像一个新来的同事，每次走进你的项目目录时都带有「失忆症」：它会写代码，但不知道你的项目结构长什么样、用哪个测试框架、哪些目录不能碰。

解开 Codex 全部潜能的关键，不是更花哨的提示词，而是给它持久化的记忆：关于你的代码仓库、你的编码规范、你的工作流程。

本文基于 OpenAI 官方 Codex 文档中的 「六支柱框架」 和 「八个常见错误」，结合我三个月的实战踩坑，帮你把 Codex 从「一个会写代码的聊天窗口」升级为「真正懂你项目的 AI 队友」。

先理解一个心理模型

Codex 不需要更多的指令，它需要的是更稳定的上下文。

每次 Codex 开始处理你的任务时，它会读取文件、理解结构、然后动手。但如果没有持久化的配置，它会在每次会话结束后忘掉一切。解决这个问题的六个支柱是递进式的：

AGENTS.md → 配置文件 → MCP 连接 → 技能包 → 自动化

每个支柱都建立在前面之上。你不需要第一天就把六个全搞定，但理解了它们之间的关系，你就知道该从哪里开始。

支柱一：每个任务都给足上下文

在开始一个任务之前，确保 Codex 知道：

项目结构：源码在哪、测试在哪、配置在哪？
技术栈：什么语言、什么框架、什么构建工具？
编码规范：代码风格、命名约定、过往踩过的坑
当前状态：最近改了什么、出了什么错？

你当然可以在每次对话里手动输入这些信息。但有一个好得多的办法：支柱二。

支柱二：AGENTS.md — 写给 AI 看的使用说明书

AGENTS.md 是一份写给 AI Agent 的 README。 Codex 会在每次会话开始时自动读取它。这是你投入产出比最高的一件事，没有之一。

里面写什么？

类别	示例
目录结构	`src/` 是源码，`db/schema/` 是禁区
启动命令	`pnpm dev`，`docker compose up`
测试/构建/检查	`pnpm test`，`pnpm build`，`pnpm lint`
工程规则	TypeScript 禁用 `any` 类型
约束条件	不要修改 `db/schema/` 目录
完成标准	「通过 `pnpm test` 才算做完」

三层优先级

~/.codex/AGENTS.md → 个人全局默认设置
repo-root/AGENTS.md → 团队共享规范
subdirectory/AGENTS.md → 局部规则（优先级最高）

越靠近工作目录的文件优先级越高。你可以给前端和后端设置不同的规则。

对话 Codex 技术负责人：最好的 AI 工程实践，朴素得让人意外

Mon, 15 Jun 2026 09:00:00 +0800

如果你以为 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。”