文章目录
- 1、前言：三分钟，主力工具被迫换了
- 2、这次不讲迁移教程，我只算三笔账
- 3、入口三分钟就换了，信任用了两周
-
- [3.1、6 月 28 日是开关，7 月 1 日才是迁移](#3.1、6 月 28 日是开关，7 月 1 日才是迁移)
- [3.2、80:20 变成 30:70，但"用得更多"只是第一层结论](#3.2、80:20 变成 30:70，但“用得更多”只是第一层结论)
- 3.3、最诚实的迁移指标，是工具何时不再成为话题
- [4、Codex 首先改变的，是我的"不信任成本"](#4、Codex 首先改变的，是我的“不信任成本”)
-
- 4.1、提示词变长，不一定是进步，也可能是保险费
- [4.2、工具调用从 10 次涨到 26 次，我反而不敢直接谈效率](#4.2、工具调用从 10 次涨到 26 次，我反而不敢直接谈效率)
- 4.3、我的第一条全局规则，不是增强能力，而是保护注意力
- [4.4、Agent 降低了开工成本，也制造了"开工通胀"](#4.4、Agent 降低了开工成本，也制造了“开工通胀”)
- 5、真正没变的，是我没有把"完成"的定义交给模型
- [6、同一个 CC 换了模型，让我看清"好用"不是一个维度](#6、同一个 CC 换了模型，让我看清“好用”不是一个维度)
- [7、迁移成功的信号：我终于不再每天讨论 Codex](#7、迁移成功的信号：我终于不再每天讨论 Codex)
- 8、总结：我迁移的，其实是一张失败地图
🍃作者介绍：AI 应用负责人/AI产品架构师，阿里云专家博主。专注 LLM 应用开发、Agent 系统设计、具身智能与工业 AI 落地。日常在大模型训练、Coding Agent 工具链、AI 产品商业化等方向持续输出实战内容。
🦅个人主页：@逐梦苍穹
🐼GitHub主页：https://github.com/XZL-CODE
✈ 您的一键三连，是我创作的最大动力🌹
1、前言：三分钟，主力工具被迫换了
2026 年 6 月 27 日晚上 23:54，我还在 Claude Code（下文简称 CC）里输入：
我本地的 Codex 好像启动不了，帮我排查一下。
当时两者的关系很清楚：CC 是主力，Codex 是备用。后者甚至还是一个需要前者帮忙维修的新工具。
第二天下午，关系突然反了过来。
- 6 月 28 日 17:32:17，我在 CC 中留下事发前的最后一条输入；
- 17:35:17，仅仅三分钟后，我在 Codex 中询问：这个情况是不是被 Anthropic 封号了？
入口切换只用了三分钟，不适应却持续了更久。
说句大实话，我最难受的不是 Codex 少了某个按钮，也不是某条命令换了名字，而是我突然不知道它会在哪里出错。
一款 Coding Agent 用熟以后，我们熟悉的不只是它会什么。更重要的是，我们知道它什么时候容易跑偏、什么时候可以放着跑、哪类"已完成"不能信、看到什么信号就该接管。这些判断很少被写进功能列表，却决定了我敢不敢把一项复杂任务真正交出去。
所以这次迁移最贵的部分，并不是重学命令，而是重新画一张 Codex 的失败地图。
迁到 Codex 两周后，我读取了本机的 ~/.claude/ 与 ~/.codex/。我想用真实记录验证一件事：工具换了以后，我究竟只是换了一套动作，还是连判断一项工作是否可信、是否完成的方式也换了？
数据最后指向了一个比"CC 和 Codex 谁更强"更有意思的结论：
真正昂贵的不是换工具，而是重新学习它会在哪里出错。
2、这次不讲迁移教程，我只算三笔账
上一篇《Claude Code 到 Codex 迁移：不是换工具，而是换工作流》，解决的是落地路径：主力工具换掉以后，怎样尽快让工作继续跑起来。
这篇不再做功能映射，也不再讲 Skill、Agent 和配置怎么迁。那部分再写一遍，只是把上一篇换个说法。
我更想算清楚三笔账。
2.1、主力账、信任账和判断账
第一笔是主力账。 Codex 的使用量到底有没有稳定超过 CC？如果只在封号当天打开过几次，那叫应急，不叫迁移。
第二笔是信任账。 我花了多少交互研究 Codex 本身？提示词为什么变长？这些额外动作，本质上都是新工具收取的"信任税"。
第三笔是判断账。 路径、证据、授权和验收这些行为有没有变化？如果它们稳定存在，就说明有些东西并不属于 CC，而是属于我自己。
Benchmark 回答不了这三笔账。模型分数再高，如果我每一步都要盯着，它也成不了主力工具。
2.2、统计口径与边界
我选取了两个长度完全相同的 15 天窗口：
- 迁移前：2026 年 6 月 13 日至 6 月 27 日；
- 迁移后：2026 年 6 月 28 日至 7 月 12 日。
7 月 12 日的数据已经完整纳入。为了保持前后窗口严格等长，我同时向前补入 6 月 13 日，使封号前后各覆盖连续 15 天。
CC 与 Codex 的日志结构并不相同，Token、内部消息和工具事件无法直接等价换算。本文只使用相对稳定的观察指标：
- 用户输入记录与活跃日期；
- Codex 线程数与涉及的工作目录；
- 输入长度、换行和行为关键词；
- 同一工具内部的工具调用变化；
- 权限、全局指令和模型使用记录。
这里先把边界说清楚：这些数据能反映我的注意力去了哪里，却不能直接证明节省了多少工时。输入更多、线程更多，甚至工具调用更多，都可能只是更忙，不一定是更快。
3、入口三分钟就换了，信任用了两周
3.1、6 月 28 日是开关，7 月 1 日才是迁移
封号发生后，我并没有立刻放下 CC：
- 6 月 29 日，CC 有 55 条输入，Codex 只有 17 条；
- 6 月 30 日，CC 仍略高于 Codex；
- 从 7 月 1 日开始，Codex 每一天的输入量都高于 CC。
6 月 28 日只是外部事件替我按下了切换键。真正的工作重心迁移，发生在 7 月 1 日之后。
6 月 29---30 日这段反复横跳，现在回头看并不是犹豫。我其实在快速摸 Codex 的边界：过程从哪里看、任务如何继续、什么状态算卡住、哪些行为和 CC 不一样。
重度用户面对新工具时，最先缺的通常不是教程，而是预测能力。只要我还不知道一次失败会以什么形式出现，就不敢完全放手。
3.2、80:20 变成 30:70，但"用得更多"只是第一层结论
| 指标 | 6月13---27日 | 6月28日---7月12日 |
|---|---|---|
| 两个工具的用户输入记录 | 606 | 792 |
| CC 输入 | 483，约 80% | 241，约 30% |
| Codex 输入 | 123，约 20% | 551，约 70% |
| Codex 新线程 | 46 | 113 |
| Codex 涉及工作目录 | 11 | 29 |
Codex 并不是封号以后才第一次出现。它的本地历史从 2025 年 11 月就已存在，2026 年 5 月也曾活跃 22 天；封号前的 15 天里，它已经承担约 20% 的输入。
6 月 28 日发生的不是"从零学习新工具"，而是一个长期备用入口被强制提拔成主力。这个区别很重要，因为它解释了我为什么能在几天内完成主备倒置，却依然有明显的不适应。
还有一个容易被误读的数据：总输入从 606 增加到 792，涨了约 31%。
我不打算把它包装成"生产力提升 31%"。这里面混着真实工作、配置排查、重复确认，以及把脑中旧习惯翻译成 Codex 能理解的显式约束。更准确地说，这 31% 里有一部分是迁移产生的 翻译损耗。
3.3、最诚实的迁移指标，是工具何时不再成为话题
迁移后的前 7 天，Codex 共出现 267 条用户输入，其中约 25.5% 在讨论 Codex 自身，主要涉及配置、权限、界面、Sub-agent 可见性、订阅和功能差异。
随后 8 天，也就是 7 月 5---12 日，Codex 共出现 284 条输入，其中工具相关内容只占 7.7%，约 22 条。虽然后一段多一天，但日均输入接近：38.1 条对 35.5 条，因此占比仍然有参考价值。
这里有意思了。
一个终端真正好用时，我不会每天和别人讨论终端；Git 真正进入工作以后，我也不会四分之一的时间都在研究 Git。第一周的 Codex 还不是基础设施，它本身就是项目。
到了后一阶段，输入量没有明显降低，但研究工具的占比下降约 70%。代码、文档、培训和真实项目重新成为主线。Codex 开始从"我要研究的对象"，变成"我拿来研究别的东西的入口"。
所以以后再判断一次工具迁移是否完成，我不会优先看打开次数，也不会看自己背下了多少配置。我会看一个更直接的指标：
工具不再是话题，才开始真正成为工具。
4、Codex 首先改变的，是我的"不信任成本"
4.1、提示词变长，不一定是进步，也可能是保险费
将"迁移前的 CC 输入"与"迁移后的 Codex 输入"对比：
- 输入长度中位数从 33 字增长到 44 字；
- 200 字以上长输入占比从 10.1% 增长到 16.9%；
- 多行输入占比从 12.4% 增长到 16.9%。
说句大实话，我不可能在两周内突然进化成了更优秀的 Prompt 工程师。
我只是开始更频繁地写明工作目录、修改边界、是否先讨论、成果保存位置和验收条件。每增加一句"只读不要改""先分析再执行""必须实际渲染"，都像是在为一个尚未完全信任的系统购买保险。
长提示词有两种来源：一种是需求真的复杂，另一种是用户不相信工具能补齐默认前提。我的数据显然混合了两者。
这也是为什么我不会把"Prompt 越长"当成成熟度指标。它有时代表表达更清楚，有时只是信任还没建立起来。提示词长度，也是一支信任温度计。
4.2、工具调用从 10 次涨到 26 次，我反而不敢直接谈效率
只在 Codex 内部比较，迁移前后活跃会话的工具调用中位数从 10 次增长到 26 次。
它说明 Codex 确实进入了更深的执行阶段：读取材料、修改文件、运行命令和验证结果，不再只是偶尔回答一个问题。
但 26 次工具调用既可能代表任务做得更完整，也可能代表走了弯路。日志能轻松记录"动了多少次"，却很难回答"少返工了多少次"。
这恰好暴露了 Agent 生产力评估里最容易偷换的概念：活跃度很好统计，交付质量很难统计。
所以这篇文章可以确认 Codex 参与得更深，却不能确认它让我快了多少。缺少工时、缺陷率和返工率时，任何"效率提升百分之多少"都只是包装。
4.3、我的第一条全局规则，不是增强能力，而是保护注意力
迁移前，CC 的全局指令重点围绕 Agent Teams 的生命周期：如何组队、分配任务、召唤成员、验收和关闭。
7 月 1 日创建的 Codex 全局指令却非常短，核心只有两点：
- 不要发送可有可无的过程播报；
- 多花时间思考，不必持续汇报进度。
这个变化比功能对比更诚实。
过去我先优化"Agent 团队怎么调度"，迁到 Codex 后，我先优化"哪些信息值得出现在我面前"。原因很简单：Agent 可以并行，人的注意力不能。
很多 AI 工具把 Token、上下文长度和并发量当成稀缺资源，但对重度用户来说，真正稀缺的是前台注意力。一个 Agent 每隔几十秒汇报一次，并不会让我更有控制感，只会迫使我不断切回它的节奏。
我需要的可观测性，是关键节点可验证，不是全过程围观。
4.4、Agent 降低了开工成本，也制造了"开工通胀"
15 天内，Codex 新线程从 46 增长到 113，涉及工作目录从 11 个增长到 29 个。
这当然说明 Codex 接住了更多真实工作，但它也精准放大了我的一个风险：看到新工具就想多开几个方向，把"能不能做"研究到极致，再决定"值不值得做"。
Coding Agent 最先降低的往往不是完成任务的成本，而是启动任务的成本。新建一条线程、丢进去一份材料、让它先分析，几乎没有心理负担。问题是，每一条新线程都给人一种"这件事已经开始推进"的错觉。
开工不等于推进，更不等于交付。
我现在更愿意把 Coding Agent 看成一个偏好放大器：本来擅长收敛的人，会更快交付；本来容易发散的人，会更快开出更多坑。Agent 不会自动修复人的工作习惯，它只会让原来的习惯运行得更快。
对我而言，这可能比 CC 和 Codex 的功能差异更值得警惕。
5、真正没变的，是我没有把"完成"的定义交给模型
5.1、五组行为指标，暴露了稳定的判断顺序
我对两段用户输入做了同口径的关键词与交互模式统计：
| 交互模式 | CC 迁移前 | Codex 迁移后 |
|---|---|---|
| 路径、目录、文件驱动 | 19.0% | 19.4% |
| 要求数据、日志、测试验证 | 11.6% | 15.1% |
| 明确结果与交付导向 | 6.4% | 6.7% |
| 先讨论、确认、对齐再执行 | 3.7% | 3.4% |
| 带问号的追问 | 16.6% | 15.4% |
除"要求证据和验证"提高 3.5 个百分点外，其余四项都只在很小范围内波动。
这不是心理学实验，关键词也不可能准确理解每句话。但趋势已经足够清楚：工具换了，我仍然习惯从真实目录开始，仍然要求日志和测试，仍然关心成果落在哪里。
更关键的是，"证据与验证"不降反升。面对一个更陌生的工具，我没有把验收交给它，反而抓得更紧。
执行可以自动化，完成的定义不能自动外包。模型可以说"已完成"，但页面能不能打开、测试是否通过、图片有没有遮挡，这些事情不由模型的语气决定。
我可以把操作权交给 Agent，但不会把验收权也交出去。
5.2、权限开得大，不代表信任得轻
迁移前，CC 约 78% 的活跃会话使用 bypassPermissions。
迁移后的 113 个 Codex 线程中，111 个采用免审批模式并关闭沙箱限制。两个产品的权限定义不能完全等价，但方向很一致：边界一旦说清楚，我希望 Agent 连续执行，不要每一步都回来问我。
这看起来和"加强验收"矛盾，其实恰好相反。
权限解决的是执行效率，验收解决的是结果可信度。权限越充分，Agent 能造成的变化越大，最后就越不能只听一句"完成了"。我的习惯一直是把两端拆开：执行阶段尽量放手，结果阶段尽量较真。
简单说就是：授权给执行，判断不外包。
5.3、规则文件不是资产，失败经验才是
这篇文章本身就是一个例子。
我没有直接让 Codex 根据主题生成正文，而是先读取两边日志、验证猜想，再检查封号后 CC 接入其他模型时做了什么。初稿完成后，我又拿已经发布的上一篇做重复度审查；发现定位相似，就整篇重写。
我现在留下来的规则也是这样。全局 AGENTS.md 里最先写下的不是增强功能，而是"不要发送可有可无的过程播报"；排查现有项目时，我经常把"不修改，只排查""先讨论，不做任何代码更改"写在第一屏；做视觉任务，则会要求 SVG 必须实际渲染。
前两类规则是在保护我的决策边界，后一类是在防止"源码正确"冒充"结果可用"。它们都不是凭空想出来的最佳实践，而是返工之后留下的疤。
规则文件看起来像配置，实际上更像失败经验的压缩包。每一条看似啰嗦的限制，背后通常都有一次真实的返工。
因此，真正可迁移的资产也不只是 AGENTS.md 里的文字，而是把一次纠偏变成下一次默认行为的能力。文件会过期，这种沉淀方式不会。
6、同一个 CC 换了模型，让我看清"好用"不是一个维度
封号后，CC 并没有立即从我的电脑上消失。我通过其他模型继续使用了它一段时间，这恰好提供了一个并不完美、但很有价值的控制变量。
6.1、熟悉的壳，确实能托住一部分体验
封号后的 35 个有效 CC 主会话中，有 28 个主要由 DeepSeek 或 Qwen 驱动；两者合计约占同期 CC assistant 记录的 70%，并产生了 1577 次工具调用。
这些会话承担了资料读取、知识整理、方案撰写、局部编码、报告和页面制作，不只是测试模型能不能回复。
结果很明确：边界清楚的读取、整理、搜索和局部修改，原来的 CC 外壳与 Skill 仍然有效。已经熟悉的交互方式，确实能降低一部分切换成本。
但这不是严格的 A/B 测试。封号以后，我已经在主动分流任务：边界清楚的更容易留在 CC，复杂任务更可能搬到 Codex，本身就有选择偏差。这组数据可以排除"我不适应只是因为换了壳"这一种解释，却不能拿来给模型简单排名。
6.2、但熟悉的壳，补不了模型能力和结果可信度
到了复杂技术演示、整体视觉审美、长文连贯性、事实严谨性和高风险系统操作，我需要明显更多纠偏。同样的 CC 界面和同样的本地规则，并没有复制出同样的输出上限。
如果一定要把这段体验压成一个工作模型，我会写成：
可托付程度 ≈ 模型能力 × 失败可预测性 × 结果可验证性
- 模型能力决定它理论上能做到哪里；
- 失败可预测性决定我是否知道什么时候该接管；
- 结果可验证性决定它说"完成"以后，我能不能独立确认。
我用熟了的 CC，优势不只是功能顺手，而是失败方式已经相对可预测；刚迁到 Codex 时，能力未必是最大问题，真正缺的是对失败边界的认识；CC 换成其他模型以后，熟悉的外壳还在，但模型上限发生了变化。
我用乘法，是因为这里有明显的短板效应。任何一项太低，最终体验都会迅速塌下来。一个强模型如果完全不可预测，很难托付；一个熟悉外壳如果能力不够，也只能承担边界明确的任务。
这比简单争论"CC 和 Codex 谁强"更接近我的真实使用体验。
7、迁移成功的信号：我终于不再每天讨论 Codex
如果把"能启动 Codex"当成迁移成功，6 月 28 日当天就完成了；如果要求所有 CC 习惯被一比一复刻，这次迁移可能永远完不成。
我给自己设的是一套更朴素的验收标准。
7.1、工作入口已经迁完，生产力结论还不能下
| 验收问题 | 数据证据 | 判断 |
|---|---|---|
| Codex 是否成为日常主力？ | 占比由 20% 升至 70%，且 7 月 1 日后每日占优 | 已完成 |
| 是否进入真实项目？ | 新线程 46→113，工作目录 11→29 | 已完成 |
| 是否仍被工具学习拖住？ | 工具相关输入 25.5%→7.7% | 基本收敛 |
| 是否保留了稳定的任务处理方式？ | 五组交互指标整体接近，授权方向一致 | 已保留 |
| 是否已经证明效率和质量更高？ | 当前日志缺少工时、缺陷率和返工率 | 尚未证明 |
我的结论很简单：工作入口迁完了，生产力迁移还没有足够证据。
前者回答我主要在哪里工作，后者才回答换过去以后有没有做得更好。把两件事混在一起，很容易用"使用量上涨"冒充"效率提升"。
7.2、工具从主语退回背景，才算真正接班
第二周，我依然会碰到不熟悉的交互和可见性问题，也没有完全恢复过去对多 Agent 的控制感。
但 Codex 已经不再是我每天研究的主语。它开始像终端、编辑器和测试框架一样退到背景，项目本身重新回到前景。
这可能是我从这次迁移里拿到的最实用指标：一个工具真正接班，不是因为界面终于像旧工具，也不是因为我记住了所有配置，而是工作时，我越来越少意识到自己正在"迁移"。
8、总结：我迁移的，其实是一张失败地图
回头看 6 月 28 日那三分钟，我以为自己失去的是 CC，后来才发现，我暂时失去的是对一套工具的预测能力。
15 天数据把这件事拆得很清楚：Codex 的使用占比从 20% 升到 70%，说明入口已经换了；工具相关输入从 25.5% 降到 7.7%，说明信任校准开始收敛；提示词变长，说明我在用更多约束购买确定性；五组交互指标保持接近，则说明我的判断顺序没有被工具带走。
真正留下来的，不是某个快捷键，也不只是某份规则文件，而是我对任务失败方式的敏感：它有没有读到真实上下文？是不是只写得像完成了？有没有运行测试？页面和图片到底能不能看？
下一次再换 Coding Agent，我不会先问"它有没有 CC 的同款命令"。我会先问三个问题：
- 它最容易在哪类任务上跑偏？
- 我能否看到足够的外部证据，而不是只听它汇报？
- 最后由谁定义这件事已经做完？
这三个问题有答案以后，快捷键和界面都只是适应时间的问题。
工具会换，模型会换，账号甚至也可能突然失效。我真正能带走的，是对"什么才算做完"这件事的固执。