Gemini CLI 和 Codex 怎么选？一个额度写在明面上，一个文档是空白

2026-08-08

比较两个 AI 编程工具时，大家通常比模型能力、比价格、比功能。

本文想加一个很少被比、但用起来影响很大的维度：出问题的时候，你能不能自救。

在这个维度上，Gemini CLI 和 Codex 的差距相当明显。

一、先把额度机制摆清楚

Gemini CLI：额度写在明面上。

按官方额度与定价页：

授权方式	每日请求上限	每分钟请求上限
Google 登录	1000	60
Gemini API Key（未付费）	250	10
Code Assist 标准版	1500	120
Code Assist 企业版	2000	120

另有 Vertex AI Express Mode 90 天，以及按 token 付费的路线。

Codex：本文不提供任何额度或价格数字。 原因见下一节——我在核实过程中，没有在其官方仓库里找到可引用的排错与额度文档，因此不写。需要的话请查官方定价页。

二、文档完备度：一个被低估的选型维度

这是本文的核心。核实过程中的一个发现：

Gemini CLI 的仓库里有完整的 troubleshooting 文档，覆盖：

认证与登录错误（四条，每条都有成因和解法）
常见运行时错误（EADDRINUSE、command not found、MODULE_NOT_FOUND、权限/沙箱、CI 环境、DEBUG 不生效、npm 弃用警告）
一张退出码表（41 认证 / 42 输入 / 44 沙箱 / 52 配置 / 53 轮数上限）
调试手段（--debug 标志、交互模式按 F12 开调试控制台）

Codex 的仓库里没有 troubleshooting 文档。 这一点我用两种方式确认过：按文件名做代码搜索、遍历仓库目录，结果都是没有。

这个差别的实际含义是：

	Gemini CLI	Codex
遇到报错	查官方文档，多数有明确解法	只能翻 GitHub issue
写自动化脚本	有退出码表可以分流	得自己摸索
判断某个做法对不对	有官方口径	只有社区经验，可信度参差

三、「只能翻 issue」意味着什么

对 Codex 来说，遇到问题的实际流程是去 GitHub issue 区找。这条路能走通，但有几个具体的困难：

第一，issue 里的解法未必可靠。 我在核实过程中见过排版精美、带小标题和 emoji 的「根因分析」长文——读起来很权威，但没有任何可核实的依据。这类内容对排查是有害的，因为它会把你引向错误的方向而你还很有信心。

第二，你得自己判断哪条评论值得试。 一个判断标准是：这条建议能不能在五分钟内验证真假？ 比如「换成 codex -m o3-mini 试试」——几秒钟就知道；而「这是因为某某机制的问题」——没法验证。

第三，issue 关闭不等于解决。 有的是修好了，有的是陈旧自动关闭的。

但也要说公道话：issue 区确实能找到有价值的东西。核实过程中找到过几条实打实可用的：

VS Code 里 Codex Diff 报 Oops, an error has occurred，社区办法是降级扩展到 26.715.61943 并关掉自动更新
登录后第一条消息就报 stream disconnected，有条评论指出可能需要完成组织验证才能用默认模型，并给了可验证的路径（换 -m o3-mini 试、去平台 Logs 页面点进失败请求滚到底看原因）
/compact 相关的远程压缩失败，issue 里有 OpenAI 方面的回应，且后期有「现在好了」的反馈——说明已被修复

这些都是真实可用的信息，只是获取成本高，而且需要你自己甄别。

四、按场景选

选 Gemini CLI 的情况

你要写自动化 / CI 集成。 退出码表（41/42/44/52/53）意味着你的脚本能可靠分流：41 去查凭证、52 去查配置，处置完全不同。没有这张表，你只能解析报错文本，那是很脆的做法。

你在企业网或者复杂环境里。 官方文档覆盖了企业 TLS 拦截（先试 NODE_USE_SYSTEM_CA=1，不行再 NODE_EXTRA_CA_CERTS）、沙箱、CI 环境检测（任何 CI_ 前缀变量都会触发）这些坑，有文档就不用自己踩。

你需要零成本长期使用。 1000 次/天的免费档是个能干活的量级。

你不想在排查上花时间。 有文档 = 有确定答案。

选 Codex 的情况

你已经在 OpenAI 的体系里。 账号、订阅、平台后台都是现成的。

你主要在 VS Code 里用。 它有专门的 VS Code 扩展（虽然扩展本身也出过问题）。

你能接受自己甄别社区信息。 如果你习惯翻 issue、能判断哪条评论靠谱，那文档缺失对你的影响会小很多。

你需要的功能它有而对方没有。 功能层面的比较不在本文范围内——本文只比机制和文档。

五、几条实用建议

如果你选了 Codex，建议提前做这几件事：

收藏它的 GitHub issue 区，遇到报错先搜报错原文
记下你的完整环境：版本、平台、模型、订阅类型。报问题和搜 issue 时都要用
建立「五分钟可验证」的甄别习惯：先试那些能快速验证的建议
优先怀疑版本：核实中发现的几条问题，要么有明确的降级版本号，要么已被后续版本修复。升级或降级的成功率，比逐条排查高

如果你选了 Gemini CLI，建议：

先把退出码表存下来，写脚本时直接用
遇到问题先查官方 troubleshooting，而不是先搜网页
注意那条 CI 陷阱：任何 CI_ 开头的环境变量都会让它不进交互模式，用 env -u 绕开

六、这个维度值得推广

最后说一句方法论：「官方文档完备度」值得成为你评估任何工具的固定维度。

评估时花五分钟做三件事：

有没有 troubleshooting / 错误参考文档？
常见报错能不能在里面搜到？
有没有退出码、错误码之类可供自动化使用的规范？

这三条的答案，会在你用了三个月之后显著影响你的体验——而它们在试用阶段完全体现不出来。

七、一个反面参照：文档完备不代表没问题

为了公道，也要说清楚：有文档不等于不出问题。

Gemini CLI 的 issue 区里同样有一批没有公认解法的报错，比如：

Model stream ended with an invalid chunk or missing finish reason.
Model stream ended with empty response text.
Premature close
Cannot read properties of undefined (reading 'candidates')

这几条在它自带的 troubleshooting 文档里都没有收录——文档覆盖的是认证、安装、沙箱、CI 这些类别，流式响应这块是空白。

所以更准确的说法是：文档完备度决定的是**「有多大比例的问题你能自己查到答案」**，而不是「会不会出问题」。

这个比例的差别仍然很重要。 登录报错、安装问题、CI 环境、沙箱权限、企业证书——这些是高频、且解法确定的问题。有文档的话，这一大类你几分钟就能解决；没文档的话，每一条都要去 issue 区淘。

而那些真正没有定论的问题（比如上面几条流中断），有没有文档区别不大——两边你都得靠判断和减损。

给评估者的结论：文档完备度影响的是你的「日常摩擦」，不是「疑难杂症」。 而日常摩擦累积起来，通常比偶尔一次的疑难杂症更消耗人。

八、总结

Gemini CLI 的额度写在明面上（1000/60、250/10、1500/120、2000/120，单位是模型请求次数），Codex 的数字本文不提供（未找到可引用的官方来源）。
核心差别在文档完备度：Gemini CLI 有完整的官方 troubleshooting（含退出码表），Codex 仓库里没有 troubleshooting 文档（代码搜索 + 目录遍历确认）。
文档缺失的代价是：遇到报错只能翻 issue，而 issue 里的信息可信度参差，需要你自己甄别。
甄别标准：这条建议能不能在五分钟内验证真假？能就试，不能就先放一边。
选 Gemini CLI：要写自动化（退出码表）、在企业网/复杂环境、想零成本长期用、不想在排查上花时间。
选 Codex：已在 OpenAI 体系里、主要在 VS Code 用、能接受自己甄别社区信息。
「官方文档完备度」值得成为固定的评估维度——它在试用阶段体现不出来，但用了三个月之后影响很大。

本文中 Gemini CLI 的数字与文档内容来自其官方额度页与仓库自带的 troubleshooting 文档；Codex 部分的判断基于对 openai/codex 仓库的代码搜索与目录遍历（未找到 troubleshooting 文档），引用的社区信息来自该仓库公开 issue，核对日 2026-08-08。本文未提供 Codex 的额度与价格数字，请查官方。