编程心得：Vibe 上百亿 Token 后，我收获了什么?

原创 lencx 2026-07-23 15:25 上海

Codex 重置机制，让我变成了“老蹬”...

先回答标题：烧完上百亿 Token，我最大的感受是，大模型榜单看看就好，真干起活来是什么水平，只有把坑踩一遍才知道。模型强不强是一回事，能不能把它带到正确方向是另一回事。说到底，驾驭 AI 拼的还是人的认知和判断力。

Codex 重置机制，让我变成了“老蹬”。Token 是别人的，命是自己的，不建议大家熬夜拼命...

有些人不太能接受我用 AI 辅助创作，觉得文字 “AI 味”太重，难以下咽。但 AI 的参与并不意味着内容可以一键生成。即使有 AI 辅助，我完成一篇文章通常也需要大半天甚至一整天，长篇内容更可能持续数日。真正耗时的，始终是信息的搜集、整理、交叉验证，以及对事实和结论的反复确认。

AI 直接生成的内容不能被简单视为知识，只有经过验证的信息才具有可信度。现阶段，AI 仍然很难独立跨越较长的时间线和复杂的事件脉络，完成深度整合，并从中提炼出具有解释力的趋势判断——这些工作最终仍依赖人的经验与判断。

在我看来，所谓的 “AI 味”不是关键。真正重要的是信息是否可靠、观点是否有依据，以及结论能否经得起验证。下面截图中的判断，我在几年前就已经形成了（浅谈产品、流量、编程...、深度思考：聊聊 AI 发展趋势、浅谈 AI 超级应用）。回头再看，OpenCode[1]后来的发展仍走了一些本可避免的弯路…

!Image 2

📌 技术趋势判断

我目前比较看好的技术栈是 Rust、TypeScript、React + Tailwind CSS，以及 Electron。类似的判断，我在往期文章中也多次提到过。它们看似分属不同领域，实际上刚好覆盖了 Agent 应用的几个核心层次：Rust 负责性能与底层能力，TypeScript、React 和 Tailwind CSS 负责业务逻辑与界面表达，Electron 则把 Web、本地系统和 Agent 服务整合进同一个运行环境。

判断一项技术是否适合 AI 编程，关键不只是 AI 能不能生成代码，更要看生成之后能否快速检查、验证和修正。AI 并不擅长“一次写对”，但非常擅长在反馈足够明确的情况下持续迭代。

Rust 的优势正体现在这里。它兼顾性能、安全性与底层控制力，严格的类型系统和编译器检查可以提前暴露大量问题，为 AI 提供明确而稳定的反馈。越接近文件、进程、网络和系统调用等底层能力，错误的代价通常越高，Rust 的价值也就越明显。与其说它适合 AI 生成代码，不如说它特别适合 AI 在“生成—编译—修正”的循环中快速收敛。

到了应用层，TypeScript 延续了类似的思路。它与 Rust 的定位虽然不同，但同样可以借助静态类型将许多错误前置。TypeScript 最终编译为 JavaScript，而 JavaScript 依然是 Web 世界最重要的基础语言之一，背后还有极其庞大的 npm 生态。即使 Node.js 的创造者后来开发了 Deno，也没能取代这套生态，最终仍然选择兼容 Node.js 和 npm。这恰恰说明，成熟生态形成的网络效应远比想象中强大。

TypeScript 7（TS 7：AI 生成式代码的拐点）对原生编译器和编译性能的进一步投入，又补上了反馈速度这一环。Agent 会频繁执行代码生成、类型检查、编译和验证，工具链每快一点，整个迭代闭环都会被成倍放大。

在 TypeScript 之上，React + Tailwind CSS 几乎已经成为 Agent 构建界面的默认组合。React 通过组件化和声明式模型，把界面拆分成边界清晰的结构、状态与交互；丰富的生态和公开代码，又让 AI 对它拥有更充分的理解。

Tailwind CSS 则把样式收敛为一套可组合、可预测的工具类语言。Agent 不必反复在组件、样式文件和命名体系之间切换，就能围绕界面结构直接调整视觉效果。对 AI 来说，清晰的约束、统一的规则和更少的上下文跳转，往往比无限自由更重要。

TypeScript、React 和 Tailwind CSS 组合起来，Agent 可以在相对集中的上下文中同时修改结构、逻辑与样式，再通过类型检查和视觉反馈迅速验证结果。它们成为主流，不只是因为开发效率高，也因为这套组合天然适合 AI 高频生成、修改和验证代码的工作方式。

最后是 Electron，它把前面的能力真正装进了一个完整的运行环境。Electron 由 Chromium 和 Node.js 组成。过去，人们经常吐槽它体积大、资源占用高，认为为了开发桌面应用而打包一整套浏览器内核过于笨重。但到了 AI 时代，这些曾经的缺点反而开始转化为优势，因为 Agent 恰好需要一个完整、可编程且跨平台的行动环境。

Chromium 为 Agent 提供 Web 渲染、页面观察和自动化操作能力，例如 Codex App 的内置浏览器；Node.js 则负责连接本地文件、进程、网络与各种工具，也可以承载 Agent 服务。如果再把 Rust 编写的高性能系统能力接入其中，就形成了一条完整链路：React 和 Tailwind CSS 负责界面，TypeScript 负责应用逻辑，Node.js 负责系统编排，Rust 负责性能敏感和底层任务。

如果把 Chromium 看作 Agent 观察和操作 Web 世界的窗口，把 Node.js 看作连接本地系统与工具的执行层，那么 Electron 就是承载这一切的容器。它不再只是一个跨平台桌面开发框架，更像是一个天然的 Agent 行动载体。

背景

标题党了一下，据我所知，很多人喜欢拿 Token 消耗量来界定你是不是足够 Vibe，比如 10 亿俱乐部啥的（门槛要求：最低日消耗达 10 亿 Token）。说实话，排除掉纯浪费或 Agent 死循环，你要没点想法，还挺难到达 10 亿门槛的。日耗 10 亿在我看来并不是一个好的 coding 指标，有点像根据代码行数衡量个人产出的那种公司，有点让人无语...

下面是我的 Codex 小号 Token 消耗量，差不多 80 天 44.1B，也就是 440 亿 Token，单日最高 30 亿（Codex 近期的重置确实让人上头，不努力蹬总感觉自己亏了）。再算上 Claude Code 的消耗，只会更多。所以在 Token 使用这块，我认为自己还是有点发言权的。

!Image 3

注：440 亿 Token 并不等于 440 亿 Token 的代码。Agent 工作流中，绝大多数 Token 都消耗在上下文、推理、读文件、Skills、Tools、MCP、Computer Use、测试日志和反复重写上。按实际进入代码的 Token 占 1%–3%、每行代码 8–12 Token，再考虑最终留存率，441 亿 Token 大致对应千万行级的有效代码沉淀，以及亿行级的累计代码生成过程。所以，Token 更像“计算与探索消耗”，而不是代码产量；它能证明工作负载极大，但不能直接证明交付价值。其实很少有人能产出千万行级别的项目，也包括我，大量 Token 基本都在无效或者垃圾上下文中白白浪费掉了。用 Token 消耗来衡量一个人的 Vibe 程度，或许是大模型公司最开心的事（vibe 的产品还没赚钱，每个月几十上百刀的订阅费就先出去了）。

Fable 还是 Sol？

最近网上经常刷到 Vibe 党的犀利点评 “Fable 碾压 Sol，国产吊打 Fable”，就此我也想聊点自己的真实体感。因为我没有使用国产模型，暂时就不做评价了。Fable 和 Sol 都在使用，可以具体聊聊。先说结论：和之前的评价差不多，Fable 没那么神，Sol 也没那么弱，Codex 的 Computer-Use 是真好用。

Fable 很擅长给出创造性解决方案，也就是你什么都不懂，给 Fable 一个模糊的方向，它就开始哼哧哼哧的给你干活了，最终返回一个能跑的结果。至于代码细节只有深入才知道，反正每次 Fable 写完代码，我总能用 Sol review 出不少逻辑缺陷。在开发的 Noi 是一个 Electron 项目，让 Fable 设计 UI，它很喜欢自己跑一个 localhost 服务进行页面调试，让人感觉割裂，因为这里会牵扯到 Electron 相关 API 以及应用级别 debug，也可能是我姿势不对，总感觉不太顺畅。

!Image 4

反观 Sol，因为有 Computer-Use 的加持，会让 Electron 调试格外顺利。在单日 Token 消耗最高的前一天，我也消耗了 21 亿 Token。两天时间消耗了 50 亿 Token，不知是否有朋友好奇我在做什么，这个稍后展开。这里我先给个结论：Sol 的长任务推理能力很强，Computer-Use 很适合 UI/Debug 类任务处理，是解决复杂任务的神器（GPT 的多模态能力应该是断层式领先，编程能力不一定最强，但组合能力却十分能打）。

实战分享

这里我会介绍两个项目，它们的复杂度远高于网上的各种测试 Demo（比如各种单页应用、3D 效果），是真正的实战经验。在开始前先推荐一下我写的编程 Skills（https://github.com/lencx/skills），这两个项目都在高频使用，仅 Codex 中的统计就产生了大几千次调用：

* keel[2]：一种面向系统结构、边界、契约、迁移以及长期代码库健康的架构设计与治理协议。它会让系统中真正“承重”的核心骨架始终保持小而清晰：有明确归属、可被检查，并且随着时间推移仍然可以被安全删除。 * coding-protocol[3]：一种面向编码任务的环境式执行协议，会根据风险等级调整执行方式。最初版参考了 Andrej Karpathy 的公开观察。

在我的 Vibe Coding 群里，已经有不少朋友使用，评价挺高的。keel skills 是从深度思考：架构腐朽 & Loop Engineering文中抽象出来的，想了解背景的朋友可以读读。

最近几个月，我已经数不清自己推翻多少次架构了，在做的过程中，总会发现一些问题，好在 AI 时代推翻重写的成本已大大降低，兼容历史包袱只会是负债。每个程序员都应该构建自己的 harness 架构工程，随大模型一起迭代进化（Loop 不是 Agent 架构，Harness 才是、深度解析：Harness Engineering）。

在消耗的几百亿 Token 中，大部分都用来优化重写架构了（Noi 架构文档就有近百个 markdown 文件，早期比较痛苦，推翻近似完全重写，随着底座越来越硬，推翻的部分也在逐步减少），项目本身的功能消耗 Token 不算恐怖，但有例外，下面重点聊它。

Vibe 一个插件运行时

Noi[4]是我正在开发的一个 Agent 项目，很早之前就发布过了。老版本缺少 Agent 能力，目前正在重写中，非要进行定位的话，我会说它有点像 AgentOS，因为它要统一协议，协调调度，治理数据，以及提供 agent 行动的大部分环境（比如：浏览器、文件系统、terminal 等）。这部分其实之前也写过Noi 编程实战：Fable 没那么强，GPT 也没那么弱。

下面两张截图是部分正在开发的功能展示，并非最终效果：

!Image 5

!Image 6

该项目最大的难点主要有：复杂的功能资源协议如何统一，进入 Agent 的上下文应该如何组装，Agent Memory 如何设计（Agent Memory 架构本质），Chrome 插件系统兼容等。

📌 更多背景

支持 Chrome 插件，正是我要讲的核心内容。Electron 看起来很像 Chrome，但它从来不是 Chrome。两者底层都基于 Chromium[5]，但 Electron 的目标是为桌面应用提供渲染与运行环境，而不是实现一套完整的浏览器产品。从浏览器能力的角度看，它实际上是一个经过大幅裁剪的 Chromium 宿主：保留了部分 Chrome Extensions API，但官方明确表示只支持其中一个子集，完整兼容 Chrome 也不是 Electron 的设计目标。

因此，在 Electron 中运行真正的 Chrome 插件，困难的从来不只是调用一次loadExtension()。你需要补回原本由 Chrome 浏览器负责的整套运行时：插件身份、权限系统、Service Worker、事件唤醒与派发、Tab 与 Frame、Popup 与 Toolbar、存储、网络拦截，以及安装、更新、重载、禁用、重启恢复和卸载等生命周期。

这个兼容面非常大。仅 Noi 当前生成的基线就包含 57 个 MV3 API namespace、一个 MV2browserAction兼容面、401 条可调用方法路由和 108 个具名事件；除此之外，还有 Manifest 字段、属性 getter、权限规则、URL pattern、DNR schema、Port 协议以及不同执行上下文之间的差异。这些数字还不代表完整的 Chrome API，更不代表功能已经闭环。

当然，这并不意味着所有 API 都必须从零重写。对于每项能力，都需要先判断 Electron/Chromium 的原生实现是否真的可用：能够完整保留的就保留；主体可用但语义不完整的就包装；确实缺失的由 Noi 补齐；无法诚实实现的则明确拒绝。最危险的状态不是 API 不存在，而是方法存在、调用也不报错，但只实现了一半语义——插件会继续运行，最终在更长的依赖链中，以一种很难定位的方式失败。

或许有人会问：既然 Electron 只提供 Chrome Extensions API 的一个子集，为什么不直接基于完整 Chromium 构建自己的浏览器内核？

这个方案我确实评估过，但它并不是“换一个依赖包”那么简单。Chromium 的源码与依赖下载本身就有数十 GB，叠加工具链、Git 历史和构建产物后，官方构建文档通常要求至少预留 100GB 磁盘空间。首次全量构建的耗时又高度依赖 CPU、内存、磁盘、构建参数和缓存，从几十分钟到数小时甚至更久。若还要覆盖 macOS、Windows 和 Linux，就必须分别维护工具链、平台补丁、打包、签名、自动更新、安全补丁和回归测试。

更重要的是，自行编译 Chromium 只能拿回更多底层能力，并不会自动得到一个完整的 Chrome，也不会自动解决 Chrome Web Store、账号服务、策略系统、插件生命周期、权限治理、UI 投影和兼容验证。最终，你维护的不再只是一个应用，而是一条接近浏览器厂商级别的内核与发行链路。

几百个 API 的对齐，也绝不是把同名方法挂到chrome对象上、保证调用时不报错就结束了。真正需要对齐的是 Chrome 的可观察语义：参数校验、Callback 与 Promise、runtime.lastError的作用域、事件过滤与投递、Service Worker 的休眠和唤醒、不同执行上下文的权限，以及插件更新或退休后旧回调能否继续写入。

所以，Chrome 插件兼容不是一张 API 名称清单，而是一个由 API、执行上下文、权限、身份、事件、生命周期和平台版本共同组成的兼容矩阵。方法存在，只是最外层的形状；插件能够在安装、重启、更新、禁用和卸载之后仍然保持正确，才算真正建立了运行时。

理解这些背景后，你大概也能感受到：仅靠 Vibe Coding 重建这样一套运行时，难度有多高。

我也用 Fable 尝试推进这项工作，它并不能直接完成。问题不在于某个函数不会写，而在于整个链路太长（我开的便宜套餐，额度也有点吃紧）：需要覆盖的 API 太多，API 之间又共享权限、身份、事件、Worker、Frame 和生命周期状态。任何一个局部实现不准确，都可能在很远的下游才暴露问题。

Sol 同样不可能通过一次生成就把整条链路推到闭环，但它确实在一些关键路径上取得了明显进展。部分真实插件已经跨过“可以加载，但无法正常工作”的阶段，并能在当前验证路径上运行核心功能，例如 Google Translate、Tampermonkey、AdBlock 和 Dark Reader。这里仍然需要强调：真实插件能够跑通关键路径，不等于已经实现完整的 Chrome parity；它们更像探针，用来暴露运行时中尚未闭合的浏览器语义。

Sol 能够取得这些进展，并不是因为模型单独掌握了整套 Chrome 内部实现，而是因为多种工具共同组成了一条可以反复收敛的证据链（正是这个闭环链路消耗了大量 Token，两天干了 50 亿，因为 Codex 在高频重置，也就没有特别节约使用，属于大力出奇迹了）： 官方文档 -> 上游源码 -> 本地实现 -> 自动化测试 -> 真实 Electron 运行 -> 视觉回放 -> 发现偏差 -> 回到文档和源码注：模型重要，工具很重，多模态能力也很重要，尤其是长链路任务，特别依赖这些能力协作运行。 !Image 7

!Image 8

Web Search 主要用于查阅 Chrome Extensions、Chromium 和 Electron 的官方文档，确认 API 形状、权限要求和生命周期契约；bash用来搜索本地代码、执行构建与测试、启动隔离 Profile、运行 Electron smoke，以及分析日志和运行产物；Computer Use 则提供接近人眼的运行时观察，可以真实操作 Extensions 页面、Toolbar、Popup 和 Options Page，检查焦点、遮挡、尺寸、加载状态与最终 UI 投影。

这里还要特别提到 gh[6]。它在这类工作中非常重要，因为公开文档经常只描述 API 的外部契约，却不会解释具体的绑定、错误和事件派发时序。通过gh search code和 GitHub API，可以直接检索 Chromium、Electron 的实现与测试，并把源码钉在精确的文件和 commit 上。这样才能继续回答诸如“为什么读取过runtime.lastError仍然出现 unchecked diagnostic”、“为什么 schema 存在但 Service Worker 中没有 binding”、“这个行为在 Electron release branch 和 main 中是否一致”等问题。

当然，工具协同并不意味着整个过程可以脱离人。开发期间仍然需要持续介入：纠正 Sol 对问题边界的误判，阻止局部补丁掩盖结构性缺陷，补充它无法从仓库中获得的上下文，并在多条可行路径之间做出取舍。模型擅长沿着证据链高速搜索、实现和验证，但问题应该如何定义、哪些结果可以被接受，以及什么时候还不能宣称闭环，最终仍然需要人的判断。

Opsail 项目

Opsail[7]是一套给 Agent 使用的底层工具。项目由 Sol 从空仓库开始搭建，我一行代码都没写，主要负责提需求、定方向、补充约束和验收结果，偶尔在关键节点做技术判断。

Sol 完成了 Rust workspace 设计、模块拆分、CLI 和 Node.js API、跨平台实现、测试体系、GitHub Actions，以及 crates.io、npm、GitHub Release 的发布。做到后面，Opsail 已经不只是一个命令行工具，里面同时涉及浏览器控制、内容提取、Electron renderer、操作系统 API、进程管理和多平台软件分发。

📌 Opsail 简介

Opsail 目前包含opsail-chrome、opsail-read、opsail-refit-codex和统一 CLIopsail。

它可以抓取网页或浏览器渲染后的 DOM，输出 Markdown、HTML 和结构化 JSON；也可以为 Codex/ChatGPT 桌面应用安装可逆的 renderer refit。

项目主体使用 Rust，实现了 macOS、Linux、Windows 的 x64 和 ARM64 二进制。Node.js 版本通过optionalDependencies自动选择当前平台对应的@opsail/*carrier，无需在安装阶段临时下载二进制。

Opsail 最早看起来很简单：给它一个网页地址，返回整理后的正文。继续往下做，很快就出现了很多不能糊弄的细节。

输入既可能是 URL，也可能来自文件、stdin、已经打开的 Chrome，或者调用方提供的 CDP 端点。输出除了给人看的 Markdown，还要提供稳定的机器协议，方便 Agent 直接消费。超时、取消、输入大小、输出大小、错误阶段、恢复建议都要有明确规则。日志只能进入stderr，最终 JSON 必须留在stdout，否则上层程序很容易因为一条普通 warning 解析失败。

Chrome 也有资源归属问题。由 Opsail 启动的浏览器需要使用隔离 profile，命令结束后还要清理进程树和临时目录。外部传入的 CDP 连接属于调用方，Opsail 只能使用，不能擅自关闭。连接前还要核对监听地址、WebSocket、page target 和进程归属，避免连到一个碰巧占用了相同端口的其他程序。

到了refit-codex，复杂度又上了一个台阶。它需要发现正确的 Electron renderer，利用桌面应用已有的本地 bridge 注入功能，同时保持应用包和签名原样。Codex 的页面会发生路由切换、DOM 重建、主题变化和语言变化，注入的内容需要跟着恢复，还不能干扰聊天列表、设置页面和原有交互。

这个模块后来形成了一套完整生命周期：enable、disable、status、doctor、update，并支持 once、persistent 和 foreground 模式。重复执行要保持幂等，更新过程要校验版本和资源哈希，文件写入要保证原子性，禁用后还要移除脚本、状态和后台进程。

Windows ARM64 实机验证

我的开发机是 macOS，本地装了 Parallels Windows 11 ARM64 虚拟机。开发refit-codex时，因为要支持 Windows，我随口说了一句：

我已经安装了 Parallels，你可以在里面跑测试。

!Image 9

正是这句话，直接把项目难度拉起来了。当时 Parallels 虚拟机里只有 Windows 和已登录的 Codex，Node.js、Rust、MSVC 构建工具链都没有准备。源码和任务调度仍在 macOS，Sol 通过 Parallels Tools 提供的prlctl exec把命令投递到虚拟机：探测系统架构、安装对应工具链、刷新非交互式 PowerShell 的环境变量、同步代码，然后在 Windows 内执行cargo test、Clippy、原生编译和 CLI canary。命令产生的 stdout、stderr 与退出码会回传到 macOS，Windows 上的失败结果可以直接进入下一轮代码修改。

这条链路横跨 zsh、prlctl、PowerShell 和最终执行程序，参数需要连续通过四层解析。引号、反斜杠、Unicode、CRLF、共享目录路径都可能改变命令含义；安装程序写入注册表后，已经启动的非交互式会话也未必能立即拿到新 PATH。Windows ARM64 还要求 Rust target、MSVC 编译器、Windows SDK 和 linker 架构相互匹配。对人来说，这通常意味着反复切换宿主机和虚拟机，手动安装依赖、复制命令、检查日志，再判断问题来自代码、环境还是跨进程调用。

Codex 又是 Microsoft Store 应用，普通桌面程序的处理方式并不适用。WindowsApps\OpenAI.Codex_*属于带版本号和架构信息的包路径，升级后会变化，也不适合直接执行其中的ChatGPT.exe。Opsail 通过 WinRTPackageManager按固定的 Package Family Name 查找当前用户注册的包，继续校验 Store 签名、开发模式和包状态，再读取签名AppxManifest.xml，解析 AUMID 与实际入口app\ChatGPT.exe。解析出的路径还要经过相对路径、文件类型和 package root 边界检查，防止 manifest 路径逃逸。启动阶段调用 Windows Application Activation API，由系统按 AUMID 激活应用。

📌 Codex 安装包

Codex 属于 MSIX/Store 打包应用。它的 PFN OpenAI.Codex_2p2nqsd0c76g0 通常保持稳定，但 Package Full Name 包含版本和架构，例如 OpenAI.Codex_26.715.10079.0_arm64__2p2nqsd0c76g0。Windows 默认以 Package Full Name 组织 WindowsApps 下的安装目录，因此应用升级后，绝对路径可能改变，更新期间还可能同时存在多个版本。Opsail 没有硬编码或扫描这个目录，而是查询当前用户注册的有效包，再从签名 manifest 中解析实际入口。

应用成功启动只完成了链路的一半。Opsail 会记录 PID 与进程创建时间，防止 PID 复用造成误判，并再次核对进程的 Package Family、AUMID、可执行文件身份和用户 SID；随后读取 Windows TCP listener table，把本地 CDP 端口追溯到对应进程，再从 CDP targets 中确认 renderer 归属，完成 bridge 注入、状态读取和恢复。Persistent 模式的数据写入%LOCALAPPDATA%\opsail\refit\codex，目录继承权限会被替换为受保护的 DACL，仅允许当前用户和 SYSTEM 访问。整套流程最终在 Parallels 里的真实 Windows 11 ARM64、真实 Store 版 Codex 上跑通了包发现、系统激活、端口归属、renderer 定位、注入、持久化与清理。

!Image 10

最终效果

前面啰嗦了一大堆，其实就是要实现这样一个功能，在左侧栏账号旁边显示剩余额度，我还顺带做了重置卡详情展示。效果图如下：

!Image 11

你可以通过以下方式安装使用： # 已安装 Rustcargo install opsail# 已安装 Node.jsnpm install -g opsail# 启动 Codex 并启用额度展示（推荐）opsail refit codex enable usage --launch# 仅对本次启动生效# CDP 服务不会常驻，刷新页面或侧栏重新渲染后可能丢失状态，稳定性较弱opsail refit codex enable usage --launch --once 剩余额度展示只是 refit 的一个具体应用。借助 CDP，我们可以在运行时调整 Codex 的界面与交互，因此还能拓展出许多有意思的玩法，例如主题换肤、布局调整、状态信息增强、快捷操作入口，甚至是更贴合个人工作流的辅助功能。换句话说，refit 提供的不只是一个额度组件，而是一个可继续探索的客户端改造入口。

不过，这类能力注入依赖 Codex 客户端的内部实现，版本更新后可能需要重新适配，更适合作为实验性增强能力使用。

结语

文中提到的两个项目，只是整个开发过程中的一小部分。写这篇文章，我真正想表达的是：AI 的确很强，但当它陷入循环和误区时，最终仍需要人来判断方向、打破僵局。否则，所谓的智能协作很容易退化成一场无意义的 Token 消耗游戏。

这篇文章很难完整呈现，人究竟在哪些关键节点做出了重要决策。是因为纠正 AI 并不是简单地补充一句提示词，而是一个不断讨论、实现、验证，再根据结果调整方向的过程，很难用几句话概括（Computer-Use 还让 AI 多了一个观察功能，在解决某些复杂任务时可能会有奇效）。

最后分享一个使用 Codex 的小技巧：当某个会话积累了超长上下文时，可以先让 Codex 总结当前进展，新开一个会话继续工作。也可以把已有会话的链接或 ID 发给 Codex，让不同会话之间完成上下文交接。再拓展一步，如果你还在使用 Claude Code，也可以把它生成的 JSONL 会话文件路径交给 Codex，让 Codex 读取并理解之前的工作记录。这样即使切换工具或会话，也不必从头解释整个项目。

!Image 12

!Image 13