不少人对我使用AI辅助创作持保留态度，觉得生成的内容AI痕迹太重，可读性不佳。但实际上，AI辅助并不等于一键生成成品。哪怕有AI帮忙，我完成一篇完整的文章通常也需要大半天到一整天的时间，长篇内容甚至需要数周的打磨。真正耗费精力的环节始终是信息的收集、整理、交叉验证，以及对所有事实和结论的反复核对确认。

AI直接生成的内容不能直接等同于可靠知识，只有经过严谨验证的信息才具备可信度。现阶段的AI还很难独立完成跨较长时间线、复杂事件脉络的深度整合，也无法从中提炼出具备解释力的趋势判断——这类工作最终还是需要依靠人的经验和专业判断来完成。

在我看来，所谓的“AI味”并不是评判内容的核心标准，真正重要的是信息是否准确可靠、观点是否有足够依据，以及结论能否经得起反复验证。我在几年前就形成过一些关于行业发展的判断，相关内容曾发表在早期的技术文章中，回头来看，后续的行业发展确实走过了一些本可以避免的弯路。

判断一项技术是否适配AI辅助编程，关键并不只是看AI能否生成代码，更要看生成代码后能否快速完成检查、验证和修正。AI并不擅长一次写出完美无缺的代码，但在明确的反馈机制下，它非常适合进行持续的迭代优化。

Rust的优势恰恰体现在这一点上。它兼顾了性能、安全性与底层系统控制力，严格的类型系统和编译器检查可以提前暴露大量潜在问题，为AI提供清晰且稳定的反馈循环。越是靠近文件操作、进程管理、网络通信和系统调用这类底层能力，出错的代价就越高，Rust的价值也就越凸显。与其说它适合AI生成代码，不如说它特别适配AI在“生成-编译-修正”的循环中快速收敛到可用代码的开发模式。

到了应用开发层面，TypeScript延续了类似的思路。虽然它和Rust的定位不同，但同样可以借助静态类型系统将大量错误前置到开发阶段。TypeScript最终会编译为JavaScript，而JavaScript仍是Web生态中最基础的语言之一，背后依托着极其庞大的npm包生态。哪怕Node.js的开发者后来推出了Deno，也没能替代这套成熟的生态，最终还是选择了兼容Node.js和npm的生态体系，这也充分说明了成熟生态形成的网络效应远比想象中强大。

TypeScript 7版本对原生编译器和编译性能的进一步优化，补上了反馈速度这块短板。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时代，这些曾经的缺点反而转化为优势——Agent恰好需要一个完整、可编程且跨平台的行动运行环境。Chromium为Agent提供了Web渲染、页面观察和自动化操作能力，比如内置的浏览器功能；Node.js则负责连接本地文件系统、进程管理、网络通信和各类工具，也可以承载Agent的服务逻辑。如果再结合Rust编写的高性能系统能力，就能形成一条完整的技术链路：React和Tailwind CSS负责界面渲染，TypeScript负责应用逻辑，Node.js负责系统编排，Rust负责性能敏感型的底层任务。如果将Chromium看作Agent观察和操作Web世界的窗口，将Node.js看作连接本地系统与工具的执行层，那么Electron就是承载所有这些能力的容器，它不再只是一个跨平台桌面开发框架，更成为了天然的Agent行动载体。

关于Token消耗的误区

这里先说明一下，标题其实带有一点调侃的意味。我了解到不少开发者会用Token消耗量来衡量开发的投入程度，比如所谓的“10亿俱乐部”，门槛要求是单日Token消耗至少达到10亿。说实话，排除掉纯浪费的Token或者Agent陷入死循环的情况，想要达到10亿的日消耗门槛还是需要一定的开发工作量的。但在我看来，单日10亿Token消耗并不是一个合理的编码效率衡量指标，这就像有些公司用代码行数来衡量个人产出一样，并不科学。

下面是我使用Codex小号的Token消耗数据：80天累计消耗约441亿Token，单日最高消耗达到30亿。Codex近期的重置机制确实让人不得不高频投入，不抓紧用的话感觉会亏。如果再算上使用Claude Code的消耗，总量会更高。因此在Token使用方面，我自认为还是有一定发言权的。

两款模型的实际体验对比

最近网上经常能看到关于“Fable碾压Sol，国产模型吊打Fable”的讨论，我想结合自己的实际使用体验来聊聊这个话题。由于我没有使用过国产模型，暂时不做相关评价，只谈谈Fable和Sol的使用感受。我的结论和之前的判断一致：Fable并没有传说中那么神，Sol也没有那么弱，Codex的Computer-Use功能才是真正好用的核心能力。

Fable非常擅长提供创造性的解决方案，哪怕你只给出一个模糊的方向，它也能快速启动开发并返回一个可运行的初步结果。但代码的细节问题往往需要深入排查才能发现，我每次让Fable写完代码后，都能通过Sol找出不少逻辑上的缺陷。我正在开发的Noi是一个Electron项目，让Fable设计UI时，它常常会自行启动localhost服务进行页面调试，这种方式会割裂开发流程，因为涉及到Electron相关的API和应用级别的调试，我总感觉使用起来不够顺畅，或许是我的使用姿势不对。

反观Sol，得益于Computer-Use功能的加持，Electron的调试流程变得格外顺畅。在单日Token消耗最高的前一天，我消耗了21亿Token，两天时间累计消耗了50亿Token，可能有朋友好奇我在做什么，这个我们后面会展开细说。简单来说，Sol的长任务推理能力很强，Computer-Use非常适合UI调试和复杂问题排查，是解决高复杂度开发任务的利器。当然，GPT系列的多模态能力应该是处于断层式领先的位置，它的编程能力不一定是最强的，但跨能力的组合能力却非常出色。

实战项目经验分享

接下来我会介绍两个实际开发的项目，它们的复杂度远高于网上常见的各类测试Demo，比如单页应用、3D效果这类简单示例，都是真正的实战开发经验。在开始之前，我先推荐一下我整理的编程技能工具集，这两个项目都在高频使用，仅在Codex的统计中就产生了数千次调用：

• keel：这是一套面向系统架构、边界定义、契约设计、代码迁移以及长期代码库健康管理的架构设计与治理协议。它可以让系统中真正承载核心业务的骨架始终保持简洁清晰：拥有明确的归属、可被自动化检查，并且随着时间推移可以被安全地修改或删除。
• coding-protocol：这是一套面向编码任务的环境式执行协议，会根据任务的风险等级调整执行方式。最初的版本参考了Andrej Karpathy的公开技术观察。

这个技能工具集在我的Vibe Coding社群中已经有不少开发者使用，反馈都不错。keel相关的技能是从一篇关于架构腐朽和循环工程的文章中抽象提炼出来的，想要了解背景的朋友可以查阅相关的早期技术文章。

最近几个月，我已经记不清自己推翻过多少次系统架构了，在开发过程中总会不断发现新的问题。好在AI时代下，推翻重写的成本已经大大降低，强行兼容历史包袱反而会成为技术债务。每个程序员都应该构建属于自己的架构工程框架，伴随大模型技术一起迭代进化。在累计消耗的几百亿Token中，大部分都用于优化和重写系统架构了。以Noi项目为例，仅架构文档就有近百个Markdown文件，早期的重构工作非常痛苦，几乎是完全重写，随着基础架构逐渐稳定，后续需要推翻重写的部分也在逐步减少。项目本身的功能开发消耗的Token其实并不算多，但有一个例外，下面我们会重点聊聊这个项目。

Noi项目：Chrome插件兼容的挑战

Noi是我正在开发的一个Agent项目，很早之前就已经发布过初始版本，但早期版本缺少完整的Agent能力，目前正在进行全面重写。如果要给这个项目做一个定位，我更愿意称它为“AgentOS”，因为它需要统一各类协议、协调调度任务、治理数据，并且提供Agent运行所需的大部分环境能力，比如浏览器、文件系统、终端等。

这个项目最大的难点包括：如何统一复杂的功能资源协议、如何组装进入Agent的上下文信息、如何设计Agent的记忆模块，以及最核心的Chrome插件系统兼容问题。

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

因此，在Electron中运行真正的Chrome插件，难度远不只是调用一次loadExtension()方法那么简单。你需要补全原本由Chrome浏览器负责的一整套运行时环境，包括插件身份验证、权限管理、Service Worker、事件唤醒与派发、Tab与Frame管理、Popup与Toolbar、存储管理、网络拦截，以及插件的安装、更新、重载、禁用、重启恢复和卸载等完整生命周期。

这个兼容的覆盖范围非常广。仅Noi当前生成的基础代码就包含了57个MV3 API命名空间、一个MV2 browserAction的兼容层、401条可调用方法路由和108个具名事件；除此之外，还需要处理Manifest字段、属性Getter、权限规则、URL匹配模式、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同样不可能通过一次生成就把整条链路推到闭环状态，但它确实在一些关键路径上取得了明显的进展。部分真实的Chrome插件已经跨过了“可以加载，但无法正常工作”的阶段，能够在当前的验证路径上运行核心功能，比如Google Translate、Tampermonkey、AdBlock和Dark Reader。这里需要强调的是：真实插件能够跑通关键路径，并不等于已经实现了完整的Chrome兼容性；它们更像是探针，用来暴露运行时中尚未闭合的浏览器语义细节。

Sol能够取得这些进展，并不是因为模型单独掌握了整套Chrome的内部实现，而是因为多种工具共同组成了一条可以反复收敛的证据链。正是这个闭环链路消耗了大量的Token，两天时间就用掉了50亿Token——因为Codex处于高频重置阶段，我并没有刻意节约使用，算是大力出奇迹了。这条链路的流程如下：

官方文档 -> 上游源码查阅 -> 本地代码实现 -> 自动化测试 -> 真实Electron环境运行 -> 视觉回放验证 -> 发现偏差 -> 回到文档和源码修正
注：模型重要，工具很重，多模态能力也很重要，尤其是长链路任务，特别依赖这些能力协作运行。

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

这里还要特别提到gh命令行工具，它在这类工作中非常重要，因为公开的官方文档通常只会描述API的外部契约，却不会解释具体的绑定方式、错误处理和事件派发时序。通过gh search code命令和GitHub API，我们可以直接检索Chromium、Electron的实现代码和测试用例，并将源码定位到精确的文件和提交记录上。这样才能回答诸如“为什么已经读取过runtime.lastError仍然会出现未检查的诊断错误”、“为什么Schema存在但Service Worker中没有绑定”、“这个行为在Electron的release分支和main分支中是否一致”这类细节问题。

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

Opsail项目：Agent底层工具集

Opsail是一套专为Agent开发设计的底层工具集。这个项目是由Sol从空仓库开始搭建的，我几乎没有写过一行代码，主要负责提出需求、确定开发方向、补充约束条件和验收最终结果，偶尔在关键节点做出技术判断。

Sol完成了Rust工作区的设计、模块拆分、CLI和Node.js API开发、跨平台实现、测试体系搭建、GitHub Actions配置，以及crates.io、npm、GitHub Release的发布流程。到项目后期，Opsail已经不只是一个简单的命令行工具，它同时涉及浏览器控制、内容提取、Electron渲染器、操作系统API、进程管理和多平台软件分发等多个复杂模块。

Opsail的开发初期看起来非常简单：输入一个网页地址，返回整理后的正文内容。但继续深入开发后，很快就遇到了很多无法敷衍的细节问题。

输入源既可以是URL地址，也可以来自本地文件、标准输入、已经打开的Chrome浏览器，或者调用方提供的CDP端点。输出除了供人类阅读的Markdown格式外，还需要提供稳定的机器可读协议，方便Agent直接消费。超时处理、任务取消、输入输出大小限制、错误阶段划分、恢复建议都需要有明确的规则定义。日志信息只能输出到stderr，最终的JSON结果必须留在stdout，否则上层程序很容易因为一条普通的警告信息导致解析失败。

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

到了opsail-refit-codex模块，项目的复杂度又上了一个台阶。它需要发现正确的Electron渲染器进程，利用桌面应用已有的本地bridge注入功能，同时保持应用包和签名的完整性。Codex的页面会发生路由切换、DOM重建、主题变化和语言变化，注入的内容需要能够跟随页面状态恢复，并且不能干扰聊天列表、设置页面和原有交互逻辑。

这个模块后来形成了一套完整的生命周期管理机制，包括enable、disable、status、doctor、update等命令，并且支持once、persistent和foreground三种运行模式。重复执行命令需要保持幂等性，更新过程需要校验版本和资源哈希，文件写入需要保证原子性，禁用功能后还要移除注入的脚本、状态信息和后台进程。

Windows ARM64真机验证环节

我的主力开发机是macOS，本地安装了Parallels Windows 11 ARM64虚拟机。在开发opsail-refit-codex模块时，因为需要支持Windows平台，我随口提了一句：“我已经安装了Parallels虚拟机，你可以在里面运行测试”。

正是这句话直接拉高了整个项目的难度。当时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和链接器的架构相互匹配。对人类开发者来说，这通常意味着反复切换宿主机和虚拟机，手动安装依赖、复制命令、检查日志，再判断问题来自代码本身、环境配置还是跨进程调用。

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

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

最终实现效果

前面啰嗦了这么多，其实最终要实现的功能很简单：在Codex左侧栏的账号旁边显示剩余的Token额度，我还顺便添加了重置卡详情的展示功能。

你可以通过以下方式安装使用Opsail：

# 已安装Rust环境
cargo install opsail
# 已安装Node.js环境
npm 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读取并理解之前的工作记录。这样即使切换工具或会话，也不必从头开始解释整个项目的背景和进展。

参考资料

[1] OpenCode: https://github.com/anomalyco/opencode

[2] keel: https://github.com/lencx/skills/tree/main/skills/keel

[3] coding-protocol: https://github.com/lencx/skills/tree/main/skills/coding-protocol

[4] Noi: https://github.com/lencx/Noi

[5] Chromium: https://www.chromium.org/chromium-projects/

[6] gh: https://cli.github.com

[7] Opsail: https://github.com/lencx/opsail