工作流 on Codexer

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 后，这位开发者说出了最真实的评价

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 不只是写代码的工具：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 生产力实录：一个开发者用了快一年后的真实感受

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 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/

三条黄金法则：