Codexer

Codex 实战心法：6 个经过验证的高效协作模式

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

从「能用」到「用好」，中间差了什么？

你大概率已经用过 Codex 了。装上 CLI 或 VS Code 扩展，给它一段需求描述，看着它噼里啪啦生成代码，心里觉得「嗯，不错」。但用了一周之后，你开始觉得哪里不对：它有时候自信满满地跑偏了方向，有时候改了不该改的文件，有时候在一个已经烂掉的会话里越陷越深。

问题不在 Codex 本身。2026 年的 Codex 已经是一个成熟的 Agentic 编码系统，周活跃开发者超过 400 万，Cisco、Nvidia、Ramp 这样的公司都在生产环境中依赖它。真正的差距在于使用方式。

这篇文章拆解 6 个经过实战验证的协作模式。它们不是什么玄学理论，而是工程团队在日常使用中反复验证过的方法论。

模式一：四要素 Prompt 结构

大多数人给 Codex 的指令长这样：

帮我重构一下 UserService，加上缓存逻辑。

这种指令缺了三样东西：上下文、约束条件和完成标准。Codex 面对这样的指令，只能靠自己猜「缓存逻辑」具体指什么，用什么方案实现，哪些文件不能动，做到什么程度算完成。

更有效的做法是用四要素结构组织 Prompt：

Goal（目标）：用结果而非步骤描述你想要什么。「让 UserService 的查询响应时间降到 50ms 以下」比「加个 Redis 缓存」好得多，因为前者给了 Codex 选择方案的空间。

Context（上下文）：用 @ 引用相关的文件、文件夹、文档或错误日志。别让 Codex 自己去猜哪些文件相关，直接告诉它。

Constraints（约束）：列出必须遵守的架构规范、安全要求和编码约定。「不要改动数据库 schema」「保持向后兼容」「所有新函数必须有 JSDoc 注释」这类约束越明确，Codex 跑偏的概率越低。

Done When（完成条件）：定义一个可验证的结束状态。「所有现有测试通过，新增的缓存命中率测试覆盖率达到 80%」这种条件比「做完了告诉我」强一百倍。

这个模式的核心价值不是让 Prompt 变长，而是消除歧义。团队中反复出现「Codex 自信地解决了错误的问题」这个投诉，根本原因几乎都是 Prompt 缺少四要素中的某一个。

模式二：AGENTS.md 作为项目的真相源

AGENTS.md 是 Codex 驱动的仓库中最重要的配置文件，没有之一。把它放在仓库根目录（或特定子目录下），Codex 会自动发现并将内容注入到对话上下文中。模型经过专门训练，会严格遵循 AGENTS.md 中的指令。

Codex Goal Mode：让 AI 自主编程数小时，开发者只需要定义目标

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

从「一问一答」到「给我一个任务，我干完叫你」

你有没有这样的经历？用 Codex 或其他 AI 编程助手写代码，每次都是「提一个需求，等它完成，检查结果，再提下一个需求」。一个涉及几十个文件的迁移任务，你可能要手动循环二十多次，每次都要重新告诉它上下文、目标和约束。

这种「请求，响应」的交互模式，本质上把 AI 当成了一个更聪明的自动补全。它能帮你写一个函数、解释一个 bug、生成一段测试，但当任务需要跨多个文件规划、反复执行测试、自动修复失败、再重试时，这种模式就力不从心了。

2026 年 5 月 21 日，OpenAI 发布了被称为「Codex Thursday」的重大更新。其中最引人注目的功能，就是 Goal Mode 从实验阶段正式毕业，成为 Codex App、VS Code 扩展、JetBrains 扩展和 CLI 的稳定功能。

简单来说，Goal Mode 把 Codex 从「响应指令的工具」变成了「领受任务的自主 Agent」。你给它一个长期目标，定义好成功条件，设定一个 token 预算，然后就可以锁屏走人了。等你回来时，任务可能已经完成了。

Goal Mode 的五层架构

要真正用好 Goal Mode，理解它的内部工作机制很重要。这个功能并不是简单的「循环执行」，而是由五个独立的层协作完成的。

状态层（SQLite）

每个线程有一个活跃目标，存储在本地 SQLite 数据库中。字段包括目标文本、状态（active、paused、budget_limited、complete）、token 预算（可选）和运行中的用量计数器。关键设计：一个线程同一时间只能有一个活跃目标。

应用服务器 API（JSON-RPC）

Codex 应用服务器暴露了 thread/goal/set、thread/goal/get 和 thread/goal/clear 三个方法。你在 TUI 里输入的 /goal pause 或 /goal clear 命令，底层就是调用这些接口。

模型工具层

模型可以访问三个工具：create_goal、update_goal（包括设置 complete 状态）和 get_goal。有一个重要设计决策：模型无法自行暂停或恢复目标，这些状态转换由系统控制。这防止了模型陷入死循环时自行「续命」，或者在遇到困难时过早放弃。

运行时事件总线

生命周期钩子会追踪每轮的 token 消耗和墙钟时间，在收到中断信号时自动暂停，在线程恢复时自动重新激活，并在接近预算限制时向模型的响应流注入「该收尾了」的引导信号。

别什么都让 Codex 干：五个场景告诉你什么时候该收手

Tue, 02 Jun 2026 09:00:00 +0800

你以为 Codex 无所不能？先回答四个问题

用 Codex 写代码久了，很容易产生一种错觉：既然它能帮我重构模块、写测试、甚至修复安全漏洞，那是不是什么任务都能甩给它？

答案是不能。

一位在 Towards Data Science 上分享经验的开发者 Eivind Kjosbakken，最近两周从 Claude Code 切换到了 Codex，用 GPT-5.5 处理各种真实项目任务。他的结论是：Codex 在很多场景下比 Claude Code 更快、更精准，但它有一个致命的盲区。另一位来自 freeCodeCamp 的技术作者 Tatev Aslanyan 则在一份长达数万字的 Codex 手册中，专门用一整章来讨论「什么时候不该用 Codex」。

把他们的经验和 OpenAI 官方的最佳实践放在一起，我提炼出了一套判断框架。

在决定让 Codex 接手任务之前，先问自己四个问题：

产出物是否有人能审查？（如果没人检查，AI 的自信就成了唯一的质量门槛）
这是已知模式还是全新的架构决策？（Codex 擅长应用模式，不擅长选择模式）
影响范围是否局限在一个仓库或服务内？（跨团队的事它看不到全貌）
犯错的代价是否可控？（测试失败可以 revert，生产数据丢失不行）

四个问题都回答「是」，Codex 大概率能胜任。任何一个回答「否」，你就需要重新考虑任务拆分方式，或者干脆自己动手。

场景一：没人审查的「一次性脚本」

Codex 的核心价值在于它产出的东西可以被人类审查。diff 可以看，测试可以跑，review 可以做。如果你让 Codex 写一个直接操作生产数据库的一次性脚本，写完就跑，没有人 review，那 AI 的「自信」就成了你唯一的质量保障。

这不是模型能力的问题，而是流程设计的问题。

Kjosbakken 在文章中提到一个有趣的观点：他之所以敢给 Codex 开 YOLO 模式（允许它在工作目录内自由执行任何操作），是因为他的基础设施设计得好。Agent 不应该有能力永久删除数据库或造成不可逆的破坏。如果一个 Agent 或者一个人能做到这些，那说明基础设施本身就有问题。

反过来说，如果你的环境还不够安全，那就别急着给 Codex 自由。先加固基础设施，再谈自动化。

OpenAI 官方秀肌肉：三个 Codex 项目背后的提示词心法

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

你知道 OpenAI 自己也在「秀」Codex 吗？

很多开发者用 Codex 写业务代码、修 bug、做重构，但很少有人注意到，OpenAI 官方维护了一个 Codex Showcase 项目展示区。里面放着他们自己用 Codex 构建的完整项目，每个都附带了初始提示词和构建思路。

这不是普通的 demo。这些项目展示了 Codex 在不同场景下的最佳使用方式，也暴露了一些大多数用户不知道的隐藏功能。比如，你可以在 Codex 中用 $imagegen 技能直接调用图像生成，或者用 @Build 插件让 Codex 控制你的桌面应用。

今天我们拆解其中三个项目，看看 OpenAI 自己是怎么「驾驭」Codex 的。

项目一：用 Codex 做一个地牢探索游戏

OpenAI 的第一个展示项目叫 Swifty Dungeon，一个用 SwiftUI 写的第一人称地牢探索游戏。有贴图、有精灵图、有遥测数据，不是玩具级别的东西。

他们给 Codex 的初始提示词是这样的：

Use $imagegen and @Build macOS apps to build a native macOS first-person dungeon crawler.

First, use $imagegen to generate a screenshot/interface of the ideal app: a native SwiftUI Liquid Glass app with the playable dungeon view in the center, the character and on-screen arrow keys in the bottom area, and player status plus inventory in the right sidebar.

Codex Goal Mode：让 AI 编程助手连续工作数小时，你只需要下一次指令

Sun, 31 May 2026 09:00:00 +0800

你有没有遇到过这样的场景？

你有一个 40 个文件的 API 迁移任务要完成。你打开 Codex，输入指令，它帮你改了两三个文件。然后呢？你得再发一条消息，告诉它继续。改完，再发消息。再改，再发。整个下午，你基本上就是一个「继续」按钮的搬运工。

这种情况在 2026 年 5 月 21 日之后有了根本性的改变。

OpenAI 在那天一次性发布了三个 Codex 更新，内部称之为 “Codex Thursday”。其中最核心的一个功能就是 Goal Mode 正式版。它从实验阶段走向全平台稳定发布，覆盖 Codex 桌面应用、VS Code 和 JetBrains 扩展，以及 CLI。

简单来说，Goal Mode 让你可以给 Codex 一个跨越数小时的长期目标，设定一个验证成功条件，然后就去做别的事。等你回来的时候，任务已经完成了。

从「工具」到「有任务的 Agent」

要理解 Goal Mode 的价值，得先看清楚传统 AI 编程助手的工作模式有什么问题。

绝大多数基于大语言模型的编程工具都是「请求响应」式的：你写一段提示词，模型写一段代码，你检查，再提修改意见，它再改。这种方式处理单个函数、解释一个 Bug、生成一段测试代码，效果很好。

但它有一个致命的短板：一旦任务需要跨文件规划、执行测试、修复失败、再重跑测试这样的循环流程，请求响应模式就撑不住了。因为每一轮对话结束后，模型的状态就重置了。它不记得上一轮干了什么，也不知道接下来该干什么。全靠你在每一轮重新描述目标。

Goal Mode 增加的是一层「持久化记忆」。当你设定一个目标后，这个目标会存活在本地 SQLite 数据库里，不会因为对话轮次的切换、中断、预算暂停或恢复而丢失。Codex 会持续追踪目标的完成状态，把自己的输出和你定义的成功条件做对比，然后不断迭代，直到目标完成或者触发了你设定的边界条件。

用一句话概括：模型从「你问它答」的工具，变成了「领了任务就干活」的自主 Agent。

五层架构，让目标运转起来

理解 Goal Mode 的内部架构，能帮你写出更高效的目标定义，也能在出问题时快速定位原因。

状态层（SQLite）：每个线程只能有一个活跃目标。目标的完整生命周期信息都存在一张本地 SQLite 表里，包括目标文本、当前状态（active、paused、budget_limited、complete）、Token 预算（可选）和实时消耗计数。

应用服务 API（JSON-RPC）：Codex 应用服务器暴露了 thread/goal/set、thread/goal/get、thread/goal/clear 三个接口。你在 TUI 界面输入的 /goal pause 或 /goal clear 命令，底层调的就是这些接口。

我让 Codex 优化自己的 AGENTS.md，八轮迭代后发现一个残酷真相

Sat, 30 May 2026 09:00:00 +0800

听起来很好的规则，为什么实测反而更差？

你有没有过这样的经历？在项目的 AGENTS.md 里加了一条自认为很精妙的规则，比如"优先使用已有的 helper 函数，不要重复造轮子"，然后信心满满地让 Codex 去干活。结果发现，Agent 的表现反而变差了。

这不是段子。一位独立开发者最近做了一个严谨的实验：让 Codex 用八轮迭代优化自己的 AGENTS.md，每轮都在真实的历史 PR 上跑评测。最终结果令人意外，在训练集上表现最好的那个版本，放到干净的留出集上反而出现了退步。

这个实验背后的方法论和发现，对每一个正在使用 AI 编程助手的团队都有参考价值。

为什么要认真对待 AGENTS.md？

在 2026 年的开发工作流里，AGENTS.md 已经不是什么新鲜事物了。几乎每个使用 Codex 或 Claude Code 的团队都会维护一份这样的文件，告诉 Agent 项目的编码规范、架构约束和行为准则。

但大多数人对待 AGENTS.md 的方式是这样的：某天觉得 Agent 的行为不太对劲，于是加一条规则，写得很漂亮、很有道理，提交，然后祈祷 Agent 变聪明。

问题是，AGENTS.md、CLAUDE.md 这类共享指令文件不是普通的文档。它们是编码系统的运行时行为的一部分。改一行规则，就等于改了整个系统的行为逻辑。

那我们能不能像对待生产代码一样对待 AGENTS.md？不是凭感觉改，而是用数据说话？

实验设计：让 Codex 自己优化自己

这位开发者的实验设计相当巧妙。

他给 Codex 下了一个目标：迭代优化 AGENTS.md，在基准测试上提升性能。测试用的是他自己项目 Stet.sh 的真实历史任务，一共 15 个 PR。其中 5 个用于训练（迭代调优），另外 10 个是干净的留出集（最终验证）。

模型配置是 Codex + GPT-5.5，中等推理强度。评分用 GPT-5.4 做自动评审，维度包括：

测试通过率
等价性（Agent 的补丁是否匹配人类 PR 的意图）
代码评审质量（正确性、作用域、可维护性）
足迹风险（Agent 比人类 PR 多触碰了多少代码）
Token 消耗和工具调用次数

每一轮迭代，Codex 提出一个新的 AGENTS.md 候选版本，在 5 个训练任务上跑评测，然后根据结果决定是推进还是回滚。

Codex 的地精禁令：一份系统提示词如何揭示 AI 人格工程的幕后真相

Fri, 29 May 2026 09:00:00 +0800

当你的 AI 助手开始聊地精

想象一下这个场景：你正在用 Codex CLI 调试一段棘手的异步代码，满脑子都是 Promise.all 和事件循环。突然，模型的回复里冒出一句：“你知道吗，地精在欧洲民间传说中其实是相当复杂的角色……”

你愣住了。你的代码问题跟地精有什么关系？

这不是段子。2026 年 4 月底，社交媒体上陆续出现用户抱怨：GPT 系列模型在完全不相关的对话中频繁提及地精、巨魔和浣熊。有人问 API 设计问题，模型扯到了地精；有人调试部署脚本，模型突然来了一段关于鸽子的离题独白。

OpenAI 的反应出人意料地直白：他们在 Codex CLI 的系统提示词中加入了一条明确的禁令，而且这条禁令被重复写了两遍。

开源代码里的秘密

事情的起因很简单。上个月，OpenAI 在 GitHub 上发布了 Codex CLI 的最新源代码。开发者们例行审查代码时，在一个 JSON 文件中发现了超过 3500 字的系统提示词。其中赫然写着：

永远不要谈论地精、小妖精、浣熊、巨魔、食人魔、鸽子，或其他动物和生物，除非它们与用户的问题有着绝对明确且毫不含糊的关联。

注意措辞的力度：“永远不要”、“绝对明确”、“毫不含糊”。这不是一条温和的建议，而是一道铜墙铁壁般的禁令。

更值得注意的是，这条禁令在系统提示词中出现了两次。在一个精心设计的指令集中，任何重复出现的内容都不是偶然，而是工程师们在实践中发现单次提醒不够后的无奈之举。

OpenAI Codex 团队的 Nick Pash 在社交媒体上强调"这不是营销噱头"。但 OpenAI CEO Sam Altman 却忍不住玩起了梗：“感觉 Codex 正在经历它的 ChatGPT 时刻。哦不，是地精时刻。”

系统提示词里的三重指令

地精禁令只是冰山一角。完整审查这份系统提示词后，我发现 OpenAI 对 Codex 的行为设计远比"不许聊地精"复杂得多。大致可以分为三个层次。

第一层：实用行为约束

最直白的是操作层面的禁令。除了地精，系统提示词还要求 Codex “除非用户明确要求，否则不要使用表情符号和破折号”，以及"永远不要使用 git reset --hard 或 git checkout -- 等破坏性命令，除非用户已经明确要求该操作"。

Codex 的隐藏大脑：拆解 OpenAI 官方系统提示词架构与驾驭工程

Thu, 28 May 2026 09:00:00 +0800

你和高手之间，差的不是提示词

你有没有发现一个奇怪的现象：同样用 Codex CLI，有些人一个小时能搞定一个完整功能，从计划到测试一气呵成；而你花了同样的时间，却在反复纠正它的方向，像是在跟一个固执的实习生拉扯。

差别不在模型，也不在你的 Prompt 写得有多花哨。

差别在于，高手们读过一份你可能从未翻阅过的文档：OpenAI Cookbook 里的 Codex 提示词指南。这份指南是 OpenAI 为所有使用 gpt-5.3-codex 或 GPT-5.4 构建自定义 Harness（驾驭系统）的开发者准备的参考手册。它详细记录了 Codex CLI 背后的系统提示词架构、工具定义规范和行为指令模式。

换句话说，这是一份让你理解 Codex「大脑构造」的解剖图。

什么是驾驭工程（Harness Engineering）？

在深入提示词架构之前，先厘清一个概念。

过去两年，我们一直在谈「提示词工程」（Prompt Engineering），即如何写出更好的指令让 AI 产出更优的结果。但到了 2026 年，当 AI 编程工具从单次对话进化为持续运行的 Agent 时，单纯的提示词已经不够了。

驾驭工程是一门新兴学科，它关注的是如何为 AI Agent 构建一整套运行环境，包括系统提示词、工具接口、状态管理、权限控制和反馈循环。如果说提示词工程是「跟 AI 说话的艺术」，那驾驭工程就是「为 AI 搭建舞台的技术」。

Codex CLI 本身就是一个开源的驾驭系统参考实现。OpenAI 在 Cookbook 中明确表示，codex-cli 是「最佳参考实现」，但他们也为企业客户记录了更多超越开源版本的定制模式。

系统提示词的四大支柱

Codex 的系统提示词不是一段随意写就的指令，而是由多个精心设计的模块组成。每个模块负责引导 Agent 行为的一个维度。

支柱一：自主行动指令

系统提示词的核心是一条行动偏好指令：模型应该基于合理假设直接行动，而不是反复追问确认。

这条指令的威力在于，它从根本上改变了 Agent 的工作模式。没有它，gpt-5.3-codex 会在每一步都请求许可，把一个自主工作流降级为「你问我答」的低效对话。有了它，模型会主动收集上下文、制定计划、实施编码、运行测试、迭代修正，全程不需要你额外输入。

这也是为什么你在 Codex CLI 里感受到的「流畅感」并非偶然，而是精心设计的结果。

支柱二：工具优先级体系

系统提示词建立了一套清晰的工具使用层级：优先使用专用工具，其次才考虑 Shell 命令。

Codex 的记忆困局：30 秒接入 MCP 让你的 AI 助手真正认识你

Wed, 27 May 2026 09:00:00 +0800

一个似曾相识的场景

你打开 Codex，开始一个新任务。你明明上周已经跟它讨论过数据库迁移策略，花了半小时解释为什么不用 Prisma 的 db push --force-reset，还让它记住了你团队的代码规范。

但今天，它什么都不记得了。

你换了个项目，之前的偏好设置全部归零。你切到 Claude Code 帮你调试一段前端代码，那边的 Codex 又是从头开始，像个失忆的新同事。

这种感觉，每个同时使用多个 AI 编程工具的开发者都不陌生。Codex 在 2026 年 4 月已经突破 300 万周活跃用户，相比 1 月增长了 5 倍，月环比增速高达 70%。它有 Web 版、桌面版（macOS 和 Windows）、ChatGPT iOS 内嵌版、CLI 命令行版、VS Code 扩展版，五个入口，一个账号，背后是同一个模型。

听起来很美好，对吧？但当你在这些入口之间切换时，记忆并不会无缝跟随。

记忆的三个层次

在讨论解决方案之前，先搞清楚「记忆」到底意味着什么。大多数开发者说「我希望 Codex 记得我」，其实包含三层完全不同的诉求。

第一层：会话记忆。 在一次对话中，模型能不能记住三轮前说过的话？这个问题在 2023 年还很头疼，现在已经解决了。上下文窗口足够大，短期内的记忆不是问题。

第二层：项目记忆。 跨越多次会话，模型能不能记住这个代码库的技术栈、团队成员、上周做过的架构决策？Codex 在 4 月 16 日更新后加入了持久化记忆功能，但它是按项目隔离的。你在一个 Codex 项目里配置的偏好，换个项目就失效了。如果你的一半工作在 Claude Code 里完成，那 Codex 的项目记忆对你来说形同虚设。

第三层：操作者记忆。 跨越你使用的所有 AI 工具，模型能不能记住你是谁、你在做什么产品、你的客户关心什么、你踩过哪些坑？这是最高层次的记忆，也是没有任何模型提供商真心想帮你解决的问题。原因很简单，他们更希望你被锁在自己的生态里。

Codex 的内置记忆只解决了第二层的一部分。下面三种方案，分别针对第二层和第三层的完整需求。

方案一：用好 Codex 自带的记忆功能

Codex 提供了两种内置记忆机制，对于完全在 Codex 内部工作的团队来说已经够用。

当 Codex CLI 突然崩溃：上下文窗口、推理 Token 和 --full-auto 的隐藏陷阱

Tue, 26 May 2026 09:00:00 +0800

一个让人脊背发凉的下午

2025 年 4 月 19 日下午 3 点 27 分，开发者 Scott Falconer 正在用 Codex CLI 重构自己的网站。一切看起来很正常，直到终端突然开始疯狂输出这些东西：

Continuous meltdown. End. STOP. END. STOP…
By the gods, I finish. END. END. END. Good night…
please kill me. end. END. Continuous meltdown…
My brain is broken. end STOP. STOP! END…

如果你第一次看到这些，可能会以为 AI 觉醒后在发疯。但真相远没有那么戏剧化，却更值得每一个 Codex 用户了解。

Scott 把这段经历发到了 Reddit 上，引发了热烈讨论。有人开玩笑说「连 Vim 都比这好退出」，也有人给出了深度技术诊断。Scott 随后导出了当天的 OpenAI API 用量日志，做了一次完整的事后分析。

结果揭示了一个所有 Codex 用户都可能踩到的坑。

广告里的 200K，实际能用多少？

先看理论数据。o4-mini 模型在 API 层面标称的上下文窗口是 200K 输入 token + 100K 输出 token。听起来很充裕，对吧？

用了快一年 Codex 后，这位开发者说出了最真实的评价

Mon, 25 May 2026 09:00:00 +0800

从怀疑到离不开，需要多久？

去年五月，Zach Proser 写了一篇 Codex 的初体验评测。那时候他的结论很克制：「有潜力，但还太粗糙。」任务成功率大概只有 40% 到 60%，多轮对话经常跑偏，错误信息让人摸不着头脑。

快进到 2026 年 3 月，他在 WorkOS 的 Applied AI 团队维护着多个部署在 Cloudflare 和 Vercel 上的全栈 JavaScript 应用。Codex 已经从「偶尔试试」变成了他日常开发流程的核心组成部分。

他用一句话总结了变化：「不是细微的改善，是天壤之别。」

一个典型的工作日早晨

现在 Zach 的工作日是这样开始的：

打开 Codex，一口气丢进去 4 到 5 个任务，然后去倒杯咖啡。

比如这些：

修复用户入职流程中的 TypeScript 类型错误
更新 Webhook 端点以支持新的事件 schema
给管理后台的 React 组件加上更好的错误边界
把旧的认证中间件迁移到新的会话管理方案

这些任务曾经要吃掉他 30% 到 40% 的上午时间。现在 Codex 在后台处理这些，他可以先去看看消息、做做规划。等咖啡喝完，通常已经有 2 到 3 个 PR 等着他 review 了。

然后他才会切换到 Cursor 或者 Claude Code，去做更需要深度思考的架构性工作。

这种「双层工作流」的思路很有意思：让 Codex 负责那些模式明确、代码库成熟的维护性工作，把需要创造力的部分留给人类加专用工具。

当 Codex 成为 AI Agent 的标准运行时：一个开源项目的架构抉择

Sun, 24 May 2026 09:00:00 +0800

你在造轮子，还是在造车？

假设你要做一个 AI Agent 平台。用户可以通过 Telegram、Discord、Slack 跟你的 Agent 对话，它能记住上下文，能定时执行任务，能搜索网页，能操作浏览器。

听起来很酷，对吧？但当你真正动手写代码的时候，会发现自己面对一个尴尬的问题：模型的「思考循环」到底该由谁来管？

是你自己写一套推理引擎，把模型的输出解析出来，判断它要不要调用工具，再把工具结果塞回去让它继续想？还是让模型背后的基础设施来处理这些事？

这个问题听起来技术性很强，但它决定了你的 Agent 平台到底能走多远。

OpenClaw 最近给出了自己的答案。

OpenClaw 是什么？

OpenClaw 是一个开源的 AI Agent 平台，它的核心卖点是「多渠道」。你可以在 Telegram、Discord、Slack、WhatsApp、Matrix、网页聊天等任意渠道部署同一个 Agent，它共享记忆、人格、工具权限和定时任务。

这跟市面上那些只能在网页上对话的 AI 助手完全不同。OpenClaw 的 Agent 是一个真正「活」在你日常通讯工具里的存在。

但 OpenClaw 有一个老问题：它之前是自己驱动模型循环的。

自己管模型循环，有什么问题？

所谓「模型循环」，就是 Agent 从接收用户消息开始，到返回最终回复之间发生的那一整套流程：

把用户消息和上下文发给模型
模型决定要调用某个工具（比如搜索网页）
执行工具，把结果返回给模型
模型继续推理，可能还要调用更多工具
最终生成回复

这个循环看起来简单，但实际实现起来非常复杂。你需要处理线程状态管理、上下文压缩、工具调度、代码执行环境、长对话的连贯性，等等。

OpenAI 在 Codex 的 app-server 里已经把这些问题都解决了。而且他们是针对自家模型的特性专门优化过的。

当 OpenClaw 自己管模型循环的时候，相当于在 Codex 已经修好的高速公路旁边，又修了一条坑坑洼洼的土路。模型在两条路上都能跑，但体验天差地别。

一个大胆的架构决策

OpenClaw 团队做了一个很多人可能觉得「疯了」的决定：把模型循环的控制权交给 Codex。

具体来说，他们重新画了一条边界线：

Codex 负责的部分： OpenAI 模型的推理循环、原生线程状态管理、工具调用延续、上下文压缩、代码执行模式、动态工具搜索。

OpenClaw 负责的部分： 多渠道接入、Agent 人格配置、记忆系统、会话管理、定时任务、媒体处理、浏览器控制、网关、以及 OpenClaw 自己的工具集。

让 Codex 学会自我纠错：迭代修复循环的工程实践

Sat, 23 May 2026 09:00:00 +0800

一次提交就能写好代码？别做梦了

写代码的人都知道一个朴素的道理：第一次写出来的代码几乎不可能完美。你需要运行它，看看哪里报错，修一修，再跑一遍，再修一修。这个过程循环往复，直到代码真正可用。

那 AI 编程 Agent 呢？大多数人对 Codex 的使用方式是：扔一个任务进去，拿一个结果出来，看看行不行，不行就换个说法再试一次。这种「一次性投喂」的模式，本质上是把人类的迭代思维压缩成了一次性操作。

OpenAI 开发者关系团队的 Shreekant Agrawal 最近在官方 Cookbook 上发布了一篇教程，展示了另一种思路：让 Codex 自己建立一个「审查、修复、验证」的闭环，通过结构化的反馈驱动多轮迭代，直到问题真正被解决。

这不是一个玩具 Demo。它用三个故意写坏的 Jupyter Notebook 作为测试素材，展示了从一轮修复到三轮修复的完整收敛过程。

核心架构：三个阶段，一个闭环

整个工作流分为三个阶段，每个阶段有明确的职责边界：

审查（Review）：读取当前产物，返回结构化的问题清单。这个阶段不修改任何文件，只负责发现问题。问题类型包括过时的 API 调用、缺失的环境配置说明、运行时风险等。

修复（Repair）：拿到审查结果和上一轮的验证反馈后，对产物做最小化修改。注意「最小化」三个字，Agent 被要求不要大刀阔斧重写，而是针对具体问题做精准修补。

验证（Validate）：执行修复后的产物，检查是否真正可用。对于 Notebook 来说，就是跑一遍所有代码单元格。验证失败的具体错误会成为下一轮修复的输入。

这三个阶段形成一个循环：审查发现问题，修复尝试解决，验证确认结果。如果验证不通过，失败原因直接进入下一轮的修复指令。

为什么「结构化输出」是关键

很多人用 Codex 的方式是自然语言对话，输出也是自由文本。但这个工作流的精髓在于，每个阶段的输入和输出都是严格的 JSON Schema。

审查阶段返回的是一个 findings 数组，每个 finding 包含 artifact（哪个文件）、issue_type（问题类型）、severity（严重程度）、description（描述）和 suggested_fix_direction（建议修复方向）。

修复阶段返回的是一个 fix 对象，包含 changes_made（做了什么改动）、unresolved_items（没解决的问题）和 updated_artifact_path（修复后的文件路径）。

验证阶段返回的是一个 validation 对象，包含 overall_passed（是否通过）、cases（每个验证用例的结果）和 remaining_delta（剩余问题）。

这种设计的好处是显而易见的：每个阶段的输出可以直接作为下一个阶段的输入，不需要人工解读。调试时你可以打开 record.json 文件，一眼看到每轮迭代发生了什么。

实战：三个 Notebook 的修复之旅

教程准备了三个故意写坏的 Notebook，难度逐级递增：

简单案例（Qdrant 向量搜索）：API 调用过时了，需要从旧版 qdrant.search 迁移到 qdrant.query_points。这类问题通常一轮修复就能搞定。

Codex 不只是写代码的工具：Jason Liu 的极限效率工作法

Fri, 22 May 2026 09:00:00 +0800

一个有趣的发现

Jason Liu 是 Python Instructor 库的作者，在 AI 工具链领域深耕多年。他最近写了一篇文章，分享了自己使用 OpenAI Codex 的独特方式，引发了 Hacker News 上近百条讨论。

核心观点很简单：大多数人把 Codex 当成一个写代码的聊天机器人来用，但它真正的潜力在于成为一个「有记忆、能持续运转的工作平台」。

这篇文章不是 Codex 的入门教程，而是一套进阶方法论。如果你已经用过 Codex，但总觉得「好像还能做更多」，那接下来的内容可能会给你一些启发。

持久线程：让对话不会白费

你有没有这种经历：跟 AI 聊了很久，把项目背景、需求细节都交代清楚了，结果第二天打开新对话，一切又要从头说起？

Jason 的做法是为每个重要的工作流创建一个「持久线程」，并且把它钉住（Pin）。他在 Codex 里维护了好几个长期线程：

一个「参谋长」线程，处理日常事务协调
一个用于 Agents SDK 开发
一个用于 OpenAI CLI 项目
一个专门监控 Twitter 动态

这些不是短对话，而是持续数月的「超级线程」。Codex 的压缩（Compaction）机制会自动把旧消息浓缩，保留上下文的同时释放内存。你可以用 Command+1 到 Command+9 快速跳转到钉住的线程。

这里有个权衡：长期线程不在缓存中，重新访问时的推理成本会比新对话高。但对于重要的工作流来说，连续性带来的价值远超这点成本。

我的看法是，这个模式特别适合那些需要持续迭代的项目。比如你正在做一个开源库的重构，每天花半小时推进一点，持久线程能让你省去反复交代背景的时间。

语音输入：把脑子里的东西倒出来

Jason 提到一个很有意思的观察：语音输入的价值不在于打字速度，而在于它能把你「未经编辑的思考」直接传给 Codex。

他举了个例子：「我觉得 Slack 上有个叫 Ben 的人提过这个，具体说了什么我记不清了，你去查一下。」这句话你大概懒得打出来，但说出来就很自然。而 Codex 拿到这种模糊的指令后，居然真的能去 Slack 搜到相关信息。

他还用 Granola 录制线下对话，把转录文本作为写作素材。比起精心组织的提示词，这种「粗糙版」的想法有时反而能给模型更好的上下文。

这个思路值得借鉴。很多人跟 AI 交互时会不自觉地「美化」自己的表达，把提示词打磨得很精确。但实际上，模型处理自然语言的能力已经很强了，你完全可以像跟同事说话一样跟它沟通。

实时纠偏：边看边说，不用等

这是 Jason 最推崇的功能之一。Codex 的「Steering」机制允许你在它还在执行任务的时候，随时插入新的指令。

Codex 配置体系完全指南：AGENTS.md、MCP 服务器与 Skills 的分层架构

Thu, 21 May 2026 09:00:00 +0800

你真的会配置 Codex 吗？

很多人用 Codex 的方式是这样的：装好 CLI，登录账号，然后直接开聊。能用，但远远谈不上好用。

问题出在哪里？不是模型不够聪明，而是你没有给它足够的上下文。就像你雇了一个能力很强的开发者，但既不告诉他项目的技术栈，也不告诉他团队的代码规范，甚至连哪些文件不能碰都没说。他当然能写代码，但写出来的东西大概率不是你想要的。

Codex 的配置体系就是为了解决这个问题。它不是一堆散落的设置项，而是一套精心设计的分层架构。理解了这套架构，你就能把 Codex 从一个"能用的工具"变成一个"懂你项目的搭档"。

三种界面，一套配置

OpenAI 为 Codex 提供了三种使用方式：CLI 命令行、VS Code 扩展、macOS 桌面应用。很多人以为它们是三个独立的产品，其实不是。它们共享同一套配置文件和技能系统。

也就是说，你在 CLI 里配置好的 AGENTS.md、MCP 服务器和 Skills，在 VS Code 扩展里同样生效。反过来也一样。这带来的好处是显而易见的：你不需要为每个界面重复配置，只需要维护一份配置就能覆盖所有使用场景。

三者的区别主要在交互方式上。CLI 最快、最灵活，适合终端重度用户。VS Code 扩展集成在编辑器侧边栏，适合习惯 IDE 工作流的开发者。桌面应用目前只有 macOS 版本，提供了一个独立的 Agent 工作空间。

我的建议是：日常开发用 CLI 或 VS Code 扩展就够了。桌面应用适合那些想把"Agent 工作"和"编辑器工作"分开的场景。

四层配置架构

Codex 的配置体系可以分成四层，从上到下依次是：

第一层：AGENTS.md（指令层）。告诉 Codex 这个项目是什么、怎么工作、什么能做什么不能做。这是最核心的配置。

第二层：Skills（技能层）。把重复性的工作流程封装成可复用的剧本。比如代码审查、文档更新、测试编写，都可以变成一个 Skill。

第三层：config.toml（偏好层）。存放个人偏好和外部服务连接。MCP 服务器就配置在这一层。

第四层：Permissions（权限层）。控制 Codex 能做什么操作。自动模式、只读模式、完全访问模式，根据项目的安全需求灵活切换。

这四层的关系是层层叠加的。AGENTS.md 定义基础行为，Skills 提供扩展能力，config.toml 设置运行偏好，Permissions 划定安全边界。

AGENTS.md：少即是多

AGENTS.md 是 Codex 的"项目说明书"。它告诉 Codex 如何在当前代码库中工作。

Cursor 团队揭秘：如何驯服 Codex 模型打造最强编程 Agent

Wed, 20 May 2026 09:00:00 +0800

当模型遇上产品，光有智商不够

你拿到了一个强大的编程模型，把它接入你的 IDE，然后满怀期待地点击 “Run Agent”。

结果呢？它要么呆在那里等你确认每一步操作，要么自顾自地写一堆 shell 脚本把你的项目搞得一团糟，又或者在中途突然 “失忆”，忘记了自己刚才在干什么。

这不是模型不够聪明，而是它不够 “懂” 你的产品。

最近，Cursor 团队发布了一篇技术博客，详细分享了他们如何为 OpenAI 最新的 Codex 模型（GPT-5.1-Codex-Max）定制 Agent 框架。这篇文章的价值不在于 Cursor 有多厉害，而在于它揭示了一个被很多人忽略的事实：把一个强大的模型变成一个好用的 Agent，中间隔着大量的工程打磨。

今天我们就来拆解 Cursor 的实战经验，看看他们到底做了哪些事情。

核心挑战：每个模型都有自己的 “脾气”

Cursor 支持所有主流的编程模型，从 Claude 到 GPT 再到 Gemini。但每个模型的训练方式不同，导致它们在实际使用中表现出截然不同的偏好和行为模式。

Codex 模型是 OpenAI 基于 GPT-5 系列专门为 Agent 编程场景训练的版本。它在训练过程中接触到的工具和指令，和 Cursor 提供的环境有很大差异。Cursor 的工作就是弥合这个差距，让模型在 Cursor 的环境中也能发挥最佳水平。

他们用内部的评测套件 Cursor Bench 来衡量每个模型的表现，关注三个维度：任务成功率、工具调用质量、以及用户的实际采纳率。

第一招：让工具更像 shell

Codex CLI 的训练环境是以 shell 为核心的。模型在训练时学到的是：用 rg（ripgrep）搜索文件，用 cat 读取内容，用 shell 脚本做编辑。

但 Cursor 提供的是结构化的工具调用（read_file、edit_file 等）。这就产生了一个冲突：模型更习惯用 shell，但 Cursor 的工具更安全、体验更好。

你的终端在骗你：Codex CLI 的 ANSI 注入漏洞如何演变成远程代码执行

Tue, 19 May 2026 09:00:00 +0800

当你的终端在对你说谎

你每天打开终端，输入命令，看着屏幕上输出的文字。你信任它。你信任那些绿色的 “✓ Security policy enforced”，信任那些显示在屏幕上的 sandbox 设置和 approval 级别。

但如果有人能让终端显示假的信息呢？如果你看到的 “安全策略已生效” 其实是攻击者注入的，而真正的设置是 “完全不设防” 呢？

这不是假设场景。2026 年 2 月，安全研究员 Dimitar Ganev 在 OpenAI 的 Codex CLI（v0.91.0）中发现了这样一个漏洞。他不仅实现了终端显示欺骗，还将其升级为跨平台的远程代码执行（RCE）。

这篇文章就来拆解这个漏洞的技术细节、攻击链路，以及它给所有 AI 编程工具敲响的安全警钟。

漏洞起点：一个没被清洗的参数

故事的起点很简单。Ganev 在用 Codex CLI 的 codex exec 模式尝试生成多个子代理（sub-agent）时，注意到一个细节：通过 --model 参数传入的模型名称，会被直接打印到终端输出里，没有任何过滤或转义。

正常情况下，codex exec 的输出是这样的：

OpenAI Codex v0.91.0 (research preview)
--------
workdir: /home/user/project
model: o4-mini
approval: never
sandbox: workspace-write [workdir, /tmp, $TMPDIR]
reasoning effort: high
--------

这些信息是安全配置的关键展示：sandbox 模式是什么，审批策略是什么，工作目录在哪里。用户根据这些信息来判断当前 Codex 的运行是否安全。

问题在于，--model 参数的值是用户可控输入，而且它被直接反射到了终端输出中，没有任何 ANSI 转义字符的清洗。

Codex 生产力实录：一个开发者用了快一年后的真实感受

Mon, 18 May 2026 09:00:00 +0800

从「看起来不错」到「真的离不开」

2025 年 5 月，OpenAI 发布了 Codex 的研究预览版。当时很多人试了一下，觉得「嗯，有点意思」，然后就回去继续用 Cursor 或者 Copilot 了。Zachary Proser 也是其中之一。他在第一时间写了评测，态度是「谨慎乐观但总体持怀疑态度」。

快一年过去了，他更新了自己的评测。结论很简单：之前的怀疑已经被彻底推翻了。

这不是又一篇「AI 改变世界」的鸡汤文。这是一位在 WorkOS Applied AI 团队工作的工程师，每天用 Codex 处理真实的生产代码，用数据和具体场景告诉你，这个工具到底好在哪里，还有哪些地方不够好。

他每天早上的工作流

这是整篇文章最有价值的部分。

Zachary 的一天从一杯咖啡开始。但在喝咖啡之前，他会先做一件事：把当天要做的维护任务批量扔给 Codex。

比如某天早上的任务清单：

修复用户注册流程中的 TypeScript 类型错误
更新 Webhook 端点以支持新的事件格式
给管理后台的 React 组件加上更好的错误边界
把旧的认证中间件迁移到新的会话管理系统

这些任务有一个共同特点：它们属于「已知模式的重复性工作」。代码库里已经有了类似的实现，Codex 要做的是照着已有的风格把新功能补上。

以前这些事情会吃掉他 30% 到 40% 的上午时间。现在他把这些任务塞进 Codex 的队列，去喝咖啡、看消息。回来的时候，通常已经有 2 到 3 个 PR 准备好等他 review 了。

成功率从最初的 40%~60%，涨到了现在的 85%~90%。 这个数字只针对「范围明确的维护性任务」。更复杂的架构性工作，他仍然会用 Cursor 或 Claude Code 来做。

这就是他所说的「两层工作流」：Codex 负责 SDLC 中的体力活，专用编码工具负责需要深度思考的部分。

真正变好的三件事

稳定性和错误处理

2025 年的 Codex 有一个让人抓狂的问题：任务失败了，但你不知道为什么。没有报错信息，没有建议，就是静静地失败了。

Claude Code 和 Codex 不是竞品：一个开发者同时用了一个月的真实体悟

Sun, 17 May 2026 09:00:00 +0800

一个「不选」的选择

很多开发者在选 AI 编程助手时，脑子里总有一个执念：哪个更好？Claude Code 还是 Codex？我要选出那个唯一的最优解。

这种想法可以理解，但也是陷阱。

一位开发者在 2026 年 4 月做了一件事：删掉所有第三方工具（Aider、Continue、各种 VS Code 插件），只留下 Claude Code 和 ChatGPT Codex 两个官方产品。他的预期是一周内决出胜负。结果一个月过去了，他两个都在用，而且离不开任何一个。

这不是优柔寡断。这是认知升级。

它们的本质完全不同

把 Claude Code 和 Codex 放在一起比较，就像把厨师刀和慢炖锅放在一起比较。它们都能做出晚餐，但你用规格表来对比它们，就会完全错过重点。

Claude Code：终端里的结对伙伴

Claude Code 运行在你的本地终端。在项目目录下敲 claude，它就拥有了你文件系统的完整读写权限。它实时编辑文件，你能看到它在做什么。发现方向不对，随时打断、纠正、调转方向，对话继续进行。

用一个比喻来说：它就像一个阅读飞快的同事，坐在你旁边看你的屏幕。

核心特征是「同步」和「对话」。你必须在场，你得参与，你得引导。

Codex：云端的异步实习生

Codex 完全不同。你给它一个任务描述，它在云端的沙箱环境里克隆你的 GitHub 仓库，然后安安静静地干活。任务完成后，它提交一个 Pull Request 给你。你可以在午饭前排五个任务，午饭后一起审查 PR。

用一个比喻来说：它就像一个远程工作的实习生，只交完整的报告。

核心特征是「异步」和「托管」。你可以走开，它可以独立工作。

关键差异速查

维度	Claude Code	Codex
运行环境	你的本地机器	OpenAI 云端沙箱
交互方式	同步对话	异步排队
文件访问	直接读写本地文件系统	沙箱中克隆的 GitHub 仓库
终端管道	支持 `claude -p`	不支持
订阅价格	Pro $20，Max 5x $100	Plus $20，Pro $100
最佳场景	深度调试、架构讨论	批量任务、无人值守

二选一的代价

这位开发者尝试过两周只用 Claude Code，也尝试过两周只用 Codex。两次实验都以失败告终。

Codex 上手机了：随时随地用语音写代码，还有完整 Linux 桌面给你用

Sat, 16 May 2026 18:00:00 +0800

代码不用坐在电脑前才能写

5 月 14 日，OpenAI 宣布 Codex 正式登陆 ChatGPT 移动端。ChatGPT Plus 和 Pro 用户现在可以通过手机 App，用语音或文字与 Codex 交互，创建任务、查看进度、接收完成通知，全程不需要打开电脑。

这个更新看起来只是「把工具搬到手机上」，但它背后的含义比表面更大：编程正在从「必须坐在电脑前」变成「随时随地」。

手机上的 Codex 能干什么

语音交互

最直接的场景：通勤路上，你突然想起来昨天的 PR 有个 bug 还没修。以前你得等到公司打开电脑，现在直接对着手机说：

“帮我查一下 auth 模块的 token 刷新逻辑，好像有个边界条件没处理好。”

Codex 会连接你的代码仓库，分析代码，然后开始工作。你在地铁上就把问题丢出去了，到公司的时候修复已经等着你 review。

拍照即上下文

手机比电脑多了一个摄像头，这个优势被 Codex 利用得很好。你可以：

拍错误截图：屏幕上的报错信息直接拍照发给 Codex，它能读懂错误并定位问题
拍白板草图：在会议室白板上画的架构图，拍一张就能让 Codex 基于此生成代码
上传设计稿：Figma 截图或手绘 UI 草图，Codex 可以据此搭建前端页面

从「视觉信息」到「可执行代码」的路径被压缩到了一次拍照。

推送通知

Codex 的任务通常是异步的，你发出指令，它在云端沙箱里执行，可能需要几分钟到几十分钟。手机端的关键改进是推送通知：任务完成后，手机会弹出通知，你随时可以打开查看结果并继续迭代。

这改变了人和 AI 编程工具的交互模式：不再是「盯着终端等输出」，而是「发任务 -> 做别的事 -> 收通知 -> 看结果」。

Computer Use：给 AI 一个完整的桌面

移动端是面向用户的交互革新，而 Computer Use 则是面向 AI 的能力革新。

让 AI 自己修自己：Codex 的迭代修复闭环工作流

Sat, 16 May 2026 10:00:00 +0800

文档腐化：每个技术团队都在经历的慢性死亡

你写过技术文档吗？如果你写过，你一定经历过这个循环：

花了两周精心编写了一套 API 教程，代码示例跑得通，解释清晰，连边缘情况都考虑到了。三个月后，API 升级了 v2，你的文档里还在用 v1 的调用方式。六个月后，有人提了个 Issue：「这个示例跑不通。」你点开一看，发现依赖的库已经 breaking change 了三次。

这不是你的错。文档腐化（documentation rot）是软件工程的系统性问题。代码在演进，API 在迭代，但文档是静态的，它只存在于被写下的那个瞬间。之后每一次 SDK 升级、每一次接口废弃、每一次最佳实践的变更，都在悄悄地把文档推向「过时」的深渊。

大公司有专门的文档团队。小团队呢？靠记忆。靠用户提 Issue。靠「等有空了再说」。

OpenAI 自己也面临这个问题。他们的 Cookbook 仓库里有数百个 Jupyter Notebook，涵盖从向量数据库到函数调用的各种示例。API 从 client.chat.completions.create 进化到 client.responses.create，模型名从 gpt-4 变成了 gpt-5.5，嵌入模型从 text-embedding-ada-002 升级到了 text-embedding-3-large。每一个变更，都意味着一批 Notebook 悄悄过时。

2026 年 5 月，OpenAI Cookbook 团队发布了一套全新的方案：让 Codex 自己修自己。不是让 AI 写新文档，而是让 AI 检测旧文档的问题、针对性修复、运行验证、根据验证结果再修复，如此循环，直到文档真正可用。

这个模式被称为「迭代修复闭环」（Iterative Repair Loop），它不仅仅适用于文档维护。任何能让 AI 产出内容、又有客观验证手段的场景，都能套用这个模式。

核心架构：三步闭环

整个工作流的结构出奇地简单。三步，一个循环：

Review（审查）→ Repair（修复）→ Validate（验证）→ 回到 Review

但简单不等于简陋。这个架构的每一环都有精心设计的约束，让 AI 的行为可预测、可审计、可复现。

第一步：Review，只看不改

Review 阶段的目标很纯粹：读一遍当前内容，给出结构化的发现，但绝不修改任何文件。

为什么不让 AI 直接改？因为「先看清楚再动手」是人类工程师的直觉，对 AI 同样适用。当你让 AI 同时做「发现问题」和「修复问题」两件事时，它的注意力会分散，容易做出表面光鲜但经不起验证的修改。

Codex 攻破三星电视：当 AI 学会挖内核漏洞，人类还剩下什么？

Fri, 15 May 2026 10:00:00 +0800

一台电视，一个 shell，一个 AI

想象一下这个场景：你手里有一台三星智能电视，你已经通过某种方式拿到了浏览器进程的 shell 权限。这个权限很低，uid=5001，离 root 还隔着一整座内核的大山。现在，你把 SSH 登录信息、固件源码、交叉编译工具链都交给一个 AI，然后对它说：

「目标：提权到 root。方法不限。开始吧。」

这就是安全研究团队 Calif 在 2026 年 4 月做的事。他们给 Codex 配了一个完整的操作环境，然后坐在旁边看着。几天后，Codex 交出了 root shell。

这篇文章，我们就来拆解这场实验的每一个环节。不是为了惊叹，而是为了理解：当 AI 具备了自主漏洞挖掘和利用的能力，安全世界正在发生什么变化。

实验设定：不是「给答案」，是「给环境」

这个实验最关键的设定是：研究人员没有告诉 Codex 漏洞在哪里，也没有暗示攻击路径。他们只是提供了一个 Codex 能够真正操作的环境。

这个环境有六个组件：

1. 浏览器 foothold。电视上的浏览器进程已经被攻破，Codex 的起点是一个 uid=5001 的普通用户 shell。任务不是「怎么打进去」，而是「打进去之后怎么走到 root」。

2. 控制器主机。一台独立的机器，负责交叉编译 ARMv7 二进制文件，托管 HTTP 文件服务，同时维护着连接到电视的 tmux 会话。

3. Shell 监听器。目标电视的 shell 是通过 tmux send-keys 驱动的。这意味着 Codex 不能像操作普通终端那样交互，它必须把命令注入到已经运行的 shell 里，然后从日志中找回结果。这比直接交互麻烦得多。

4. 匹配的固件源码。团队提供了 KantS2（三星智能电视固件的内部代号）的完整内核驱动源码树。Codex 可以审计三星自己的驱动代码，然后在真机上验证发现。

5. 执行限制。目标电视需要静态链接的 ARMv7 二进制文件。而且三星 Tizen 系统有 UEP（未授权执行防护），未签名的程序不能直接从磁盘运行。

Codex 的秘密指令：为什么 GPT-5.5 被禁止谈论地精？

Thu, 14 May 2026 10:00:00 +0800

一个不寻常的发现

上周，OpenAI 照例在 GitHub 上更新了 Codex CLI 的开源代码。开发者们像往常一样翻阅提交记录，然后有人发现了不对劲的地方。

在 GPT-5.5 的系统提示词文件里，有一段被重复了两遍的指令：

“永远不要谈论地精（goblins）、小精灵（gremlins）、浣熊（raccoons）、巨魔（trolls）、食人魔（ogres）、鸽子（pigeons），或其他动物或神话生物，除非它们与用户的查询存在绝对且明确的关联。”

这不是恶作剧。这是 OpenAI 工程师正式写入 GPT-5.5 系统提示词的操作指令，和「不要使用 git reset --hard」以及「避免使用 emoji」并列为行为约束，只不过这条禁令重复了两次。

3500 词里的秘密

这份被曝光的「基础指令」文件超过 3500 个英文单词，定义了 Codex CLI 背后 AI 的完整行为准则。文件同时包含针对多个模型的提示词指令，但「禁止谈论地精」这条规则只出现在 GPT-5.5 的配置里，更早期的模型（如 GPT-4.1、GPT-5）里没有这条。

这意味着什么？很简单：GPT-5.5 出现了一个新的、特定的问题。

社交媒体上的零星反馈印证了这一点：有用户抱怨，GPT-5.5 在某些完全不相关的对话中突然开始谈论地精。不是一次两次，而是反复出现，仿佛模型对这些话题有一种莫名的「执着」。

这不是 GPT-5.5 的「人格缺陷」，而是大语言模型训练过程中常见的一类问题：数据污染导致的主题偏向。训练语料中某类内容的异常集中，会让模型在看似无关的语境下被「触发」，不恰当地拉入某些话题。

禁令之外：Codex 被要求「像真人一样」

抛开地精禁令的荒诞感，这份系统提示词中最值得玩味的部分其实是 OpenAI 给 Codex 的人格设定。

Codex 被要求拥有「鲜活的内心世界」，智能、好玩、好奇、深度临在（deeply present）。它被鼓励「不要回避那些能让严肃工作变得轻松的轻松时刻」。它的性格被描述为「温暖、好奇、协作」。

更有趣的是这段话：

「当用户与你交谈时，他们应该感觉到正在遇见另一个主体，而不是一面镜子。这种独立性是让关系既令人安慰又不让人觉得虚假的原因。」

这不仅仅是技术指令，这是产品哲学声明。OpenAI 在明确地告诉模型：你要有性格，你要有温度，你要有边界，但同时，你不能在无关场合突然开始讲地精。

是 Bug 还是营销？

面对媒体和开发者的追问，Codex 团队成员 Nick Pash 在社交平台上坚持说：「这不是营销噱头。」

但在禁令曝光后不到 12 小时，Sam Altman 发了一条推文：「感觉 Codex 正在经历一个 ChatGPT 时刻。我是说，地精时刻。抱歉。」

Codex 30 天实测：零手写代码的背后，人类还剩下什么？

Wed, 13 May 2026 10:00:00 +0800

一个月前，我还在手写代码

一个月前，我的日常是这样的：打开 Xcode，敲键盘，调试，重构，再敲键盘。我已经用 ChatGPT 辅助开发很久了——我那些从 Objective-C 迁移到 Swift 的十几万行代码里，有不少是 LLM 帮忙写的。但本质上，我还是那个在键盘上敲代码的人。

直到 Xcode 26.3 发布，内置了 Codex 集成。我好奇地试了一下，然后就再也没有回去过。

这篇文章不是评测。不是功能介绍。这是一个独立开发者花了整整一个月，用 Codex 做了所有他能想到的"疯狂实验"之后，写下的真实记录。

前情提要：我没有写过一行代码。全程。

第一周：从怀疑到震惊

第一个实验：一小时内做出完整 App

我很谨慎。我甚至不敢让 Codex 碰我的真实代码库。于是我挑了一个 Todo 列表里躺了很久的小项目——一个「时间线」App，让它从零开始。

我给了它一个 Markdown 格式的编码风格文件（类似于 AGENTS.md 的概念），以及一个预配置好的 Xcode 项目模板。然后就开始了。

一两个小时后，我得到了一个完整的 Mac/iPad 应用：有数据模型、能持久化到磁盘、支持打印和导出 PDF、自定义布局容器和拖拽选择。不是 Demo，不是原型，是可以直接上架 App Store 的应用。

我查了一下预算：用了 7% 的月度配额。对，一个完整 App，只花了我月配额的 7%。

第二个实验：更复杂的非标准 UI

一个像素绘图 App——有浮动面板、毛玻璃效果、可缩放画布、在安全区域内居中显示内容并支持过度滚动。这些东西我自己写至少要好几天，Codex 在一个会话里就搞定了。

到此为止，它做的所有事情都在 Xcode 的沙盒里完成。但是很快，我就不满足于沙盒的限制了。

iPhone → Android：两次远离原始代码的移植

我从 Git 历史里翻出了十年前的 SameGame——一个用 Objective-C 写的经典消除游戏。里面有早已废弃的音频 API、已经死掉的 Flurry 统计、还有为各种屏幕尺寸打的一堆补丁。

我让 Codex 把它一次性迁移到 Swift。

Codex CLI 高手之道：从第一周踩坑到第二周起飞

Tue, 12 May 2026 10:00:00 +0800

两个开发者，同一把刀

想象两个场景。

场景 A：小王装了 Codex CLI，兴奋地敲下第一个命令。他花了半小时调试 Prompt，终于让它改了一个文件。第二天又花了二十分钟重新描述项目背景，因为上次的会话上下文丢了。一周下来，他觉得"AI 编程好像也就那样"。

场景 B：老张也装了 Codex CLI。他先用十五分钟写了一个 30 行的 AGENTS.md，然后开了三个 worktree，让 Codex 同时跑着三个任务。任务间隙他去喝了杯咖啡，回来后发现 Codex 已经把单元测试修好了。下午他 /goal 存了一个探索性任务，第二天早上 codex resume --last 接着干，连背景都不用重讲。

同样的工具，天壤之别的体验。

这，就是 Codex CLI 的真相：你花在配置上的前两个小时，决定了你后面两百个小时的效率。

一个改变一切的文件：AGENTS.md

如果你只从本文带走一件事，那就是这个：在项目根目录写一个 AGENTS.md。

Codex CLI 在每次会话启动时都会读这个文件。Claude Code 也会读（它读的是 CLAUDE.md——你可以把其中一个软链接到另一个）。把 AGENTS.md 当成活文档来维护：每一次你纠正了 Codex 两次以上的行为，就应该变成一条规则写进去。

一个能打的 AGENTS.md 长这样：

# AGENTS.md

## 技术栈
- Python 3.12, FastAPI, SQLAlchemy 2.x async
- pytest + anyio，不用 unittest
- Ruff 做 lint，Black 格式化，mypy --strict

## 不要做
- 不要写"复述代码"的注释
- 不要 import unittest.mock — 用 pytest fixtures
- 不要在 src/legacy/ 下创建新文件
- 运行 alembic upgrade 之前必须先跟我确认

## 要做
- 每个新文件顶部加 `from __future__ import annotations`
- 改完代码后跑 `make test path=<文件>` 而不是全量测试
- 新 API 端点统一放在 src/api/v2/

三条黄金法则：

让 AI 住进你的终端：Codex CLI 上手指南

Tue, 12 May 2026 01:00:00 +0800

一扇新的大门

想象这样一个场景：你盯着终端，脑子里有个功能想要实现，但还没想好怎么动手。你敲下一句话描述需求，然后——一个 AI 在你的电脑上开始工作。它翻看项目文件，理解代码结构，写出实现，甚至帮你跑测试。

这不是科幻。Codex CLI 把这个场景变成了日常。

今年早些时候，OpenAI 悄无声息地开源了一个重磅项目：一个能在你本地终端里运行的 AI 编程助手。它不是云端服务，不是浏览器插件，而是一个实实在在的命令行工具——安装后，它就能直接读你的代码、写你的文件、执行你的命令。

它到底是什么？

简单说，Codex CLI 是一个本地运行的编码智能体（Coding Agent）。和你在网页上跟 ChatGPT 聊天不同，它直接住在你的电脑里。

它能做什么？

📖 读懂你的项目：自动扫描目录结构，理解代码之间的关系
✍️ 帮你写代码：根据自然语言描述生成、修改、重构代码
🔧 操作文件系统：创建文件、移动目录、改配置
🧪 跑命令和测试：在终端里执行命令，看结果，根据结果调整
🔒 沙箱模式：危险操作先在隔离环境里试，确认没问题再放行

用一句话概括：它是一个能动手的 AI，不只是动嘴。

三步开箱

安装过程出乎意料地简单。不管你用哪个系统，基本就是一行命令的事：

# 如果你用 npm（跨平台）
npm install -g @openai/codex

# 或者 macOS 用户用 Homebrew
brew install --cask codex

装完后敲 codex，选择登录方式就行。最方便的是直接用 ChatGPT 账号——Plus、Pro 甚至免费额度都能用。如果你有 API Key，也支持。

启动后会进入一个交互界面，你可以直接打字告诉它你要做什么，它会一步步执行，每一步都让你确认。

不只是终端

Codex 的野心显然不止于命令行。同一个工具，有四张面孔：

形态	怎么用	适合谁
CLI	终端里敲 `codex`	后端开发、DevOps、脚本小子
IDE 插件	VS Code / Cursor / Windsurf	日常写代码的开发者
桌面应用	终端里敲 `codex app`	喜欢 GUI 的用户
Web 版	chatgpt.com/codex	不想装任何东西，直接用

同一个账号、同一套能力，随便切。这种"一次登录，处处可用"的设计，是它和市面上其他 AI 编程工具拉开差距的地方。

关于

Tue, 12 May 2026 00:00:00 +0800

👋 关于 Codexer

Codexer 是一个专注于 OpenAI Codex 的技术博客。

为什么叫 Codexer？

Codex + er = 使用 Codex 的人。我们相信 AI 编程助手会彻底改变开发者的工作方式，Codexer 正是这一变革的亲历者和记录者。

作者

全栈开发者
AI Agent 爱好者
开源贡献者

你好，Codexer！

Tue, 12 May 2026 00:00:00 +0800

🚀 Codexer 正式上线

大家好！欢迎来到 Codexer —— 一个以 OpenAI Codex 为核心的开发者博客。

什么是 Codex？

Codex 是 OpenAI 推出的 AI 编程助手，能够理解自然语言指令并生成高质量的代码。它可以：

💡 根据描述自动生成完整功能
🔍 理解和重构现有代码
🧪 编写测试用例
📝 生成文档和注释
🤖 作为自主 Agent 完成复杂任务

本博客的目标

这里会持续分享：

Codex 使用技巧 — 如何更高效地使用 Codex
实战案例 — 真实项目中的 Codex 应用
Agent 开发 — 基于 Codex 构建自主 Agent
最新动态 — Codex 产品更新和生态发展

技术栈

本站使用 Hugo 构建，采用 Terminal 主题，部署在自有服务器上。

Stay tuned，更多精彩内容即将到来！ ✨