1. 那组 GPT 与 Gemini 的横评我为什么想自己重测一遍原帖把 GPT-5.4 和 Gemini 3.1 Pro 同时丢进 HumanEval、MBPP、SWE-Bench Pro 里做对比结论也很干脆GPT-5.4 在基础语法容错、多语言适配、真实工程问题解决率上领先Gemini 3.1 Pro 只在上下文窗口容量上有优势。让我更在意的是那组长文档衰减数据——64K~128K 上下文里Gemini 的关键信息召回率只有 70%~78%代码逻辑幻觉率到 11.5%。这个结论直接影响选型但我的习惯是跑分可以看别人的落地前一定要自己用同样的用例再复现一轮。于是我开始准备复现环境第一道坎不是模型能力而是账号同时对比两家模型意味着要开两套 API 控制台、维护两把 Key、还要处理两套 Base URL。后来我改用 TaoToken 做统一接入在 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 创建一把 Key把 Codex 的 Base URL 指到同一个接口再在配置里切换模型整套横评就能在同一环境里持续跑下去。1.1 复现前先明确我要复现的不是跑分而是稳定性差异原文最值得复现的地方不是那两个模型谁分高而是“Gemini 装得多、记得少”这个行为是否真实存在。HumanEval 89.2% 对 85.5%SWE-Bench Pro 57.7% 对 54.2%这种百分位差距换一个提示词版本就可能被抹平但长上下文里关键信息召回率掉到 70% 以下、修复 300 行代码时漏掉内存泄漏这类深层问题才是开发中真正会咬人的差异。所以我的复现计划很简单先跑基准类题目确认两个模型的代码风格再做长文档检索测试最后用原文那个 Python 异步爬虫用例做一次实战对照。整个过程不搭正式评测环境让 Codex 分别以两个模型身份输出然后我在本地执行和验证。1.2 为什么不直接开两套官方控制台同时开 OpenAI 和 Google 的 API 控制台意味着两套支付方式、两套额度体系、两套文档还要在 Codex 里切换 provider 时改来改去。复现横评这种一次性任务最怕时间花在环境配置而不是模型验证上。TaoToken 这里承担的角色是统一的 API 接入通道它帮我承载两个模型的 Key 与请求路由Codex 只需要认识一个 Base URL模型切换时只改配置里的模型 ID。这样省去的是反复注册、切换支付方式和适配不同接口格式的成本而不是绕过模型本身的限制模型能力是什么样重测结果就是什么样。2. 把 Codex 指到 TaoTokenconfig.toml 里的一次性配置2.1 先到官网创建 Key在开始配置前需要先去 TaoToken 注册账号并创建 API Key。创建完成后把返回的 Key 复制出来本文统一用YOUR_API_KEY代替你的真实 Key。任何教程里看到 YOUR_API_KEY都把它替换成你自己创建的那个字符串。Key 只显示一次复制时不要带多余空格保存到本机环境变量里最稳妥。2.2 Codex 的模型供应商配置Codex 读取~/.codex/config.toml。这里定义一个名为taotoken的 providerbase_url填接口地址env_key指向存放 Key 的环境变量名。注意 Base URL 是https://taotoken.net/api末尾不要加/v1也不要加任何 UTM 参数。# ~/.codex/config.toml model_providers [ { name taotoken, base_url https://taotoken.net/api, env_key TAOTOKEN_API_KEY } ] model gpt-5.4 model_provider taotoken设置环境变量export TAOTOKEN_API_KEYYOUR_API_KEY配置完成后Codex 的所有模型请求都会走https://taotoken.net/api这个地址鉴权通过TAOTOKEN_API_KEY自动完成。2.3 模型切换同一把 Key只改 model 和 model_provider横评要跑两个模型所以配置里要把切换方法留好。Codex 的model字段控制具体模型model_provider控制在哪个 provider 下找模型。因为两个模型都挂在同一个 provider 上切换时只调整model那一行即可# 复现 Gemini 3.1 Pro 时注释掉 GPT 那两行 # model gpt-5.4 # model_provider taotoken model gemini-3.1-pro model_provider taotoken这里的gpt-5.4和gemini-3.1-pro是我按原文模型名写的示例 ID。真实模型 ID 要以 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 模型广场当时显示的列表为准不同时间点上架版本和命名可能有差异不要凭记忆填。3. HumanEval 与 SWE-Bench Pro先看基准跑分能不能复现出原文趋势3.1 不搭评测环境用 Codex 直接跑提示词正式复现 HumanEval 需要拉测试集和评测脚本对只想验证稳定性的开发者来说太重。轻量做法是把原文描述的任务转成提示词让 Codex 分别以 GPT-5.4 和 Gemini 3.1 Pro 身份生成代码再由我在本地跑测试。比如基础代码生成复测的提示词结构是抽 20 道带边界条件的 Python 题目要求模型逐题给实现注明“不生成解释只输出代码”。然后我把代码放进本地单元测试跑一遍统计首次通过率。这种做法不能百分百复现论文级跑分但足以观察两个模型的语法容错率差异——这一项恰好是原文对比里差距最大的地方。3.2 两个模型在基准题上的直观差异对照原文数据把基准跑分整理成一张简表评测维度GPT-5.4Gemini 3.1 ProHumanEval 基础正确率89.2%85.5%MBPP 多语言通过率82.5%80.1%SWE-Bench Pro 工程解决率57.7%54.2%代码逻辑幻觉率7.3%11.5%我复测时最明显的体感差异在代码逻辑幻觉率上GPT 生成的代码即使第一遍没跑通报错信息也指向真实的边界条件或语法问题Gemini 更容易产出运行正常但逻辑有漏洞的代码比如空列表处理、并发计数器错位、异常路径里变量未定义等。这类问题恰恰是单测覆盖率低时最容易漏进生产环境的隐性 Bug。所以基准题复测的重点不是把 89.2% 和 85.5% 完整重跑一遍而是确认“Gemini 语法正确但逻辑失效”这个行为模式是否还会出现。4. Needle-in-Haystack长上下文衰减到底衰减在哪4.1 构造一个可以复用的长文档检索用例原文用 Needle-in-Haystack 方法统计不同上下文长度下的关键信息召回率。我复现时用一段 Python 脚本生成测试语料把关键信息藏在文档中间或末尾然后让模型回答指定区间的内容。脚本如下import random random.seed(42) chunks [] for i in range(500): chunks.append( fCHUNK-{i:04d} | 关键参数: retry_timeout_{i} {random.randint(100, 900)} ) with open(haystack.txt, w, encodingutf-8) as f: f.write(\n.join(chunks)) print(chars:, len(\n.join(chunks)))生成的长文本用 Codex 的haystack.txt方式引入对话然后提问“第 200 段的retry_timeout_200是多少”分别在两个模型下跑同一问题。为了模拟 64K~128K 上下文可以调整生成段数或重复多次文本把文档撑到目标长度。4.2 复测时重点观察三个位置原文指出 Gemini 存在明显的位置衰减特性128K 上下文下开头内容召回率超 90%中间降到 70%尾部关键内容不足 55%。复测时我重点看三个位置文档前 10% 的信息、中间 50% 的信息、尾部 10% 的信息。实测下来Gemini 对尾部信息的漏检率明显高于 GPT而且漏掉时不会主动说“我没找到”反而会结合上下文编一个看起来合理的值。这就解释了为什么长上下文场景下 Gemini 的隐性 Bug 率会上升——它不是记不住而是把记错的内容当正确信息输出了。对照原文的衰减表64K~128K 区间召回率 70%~78% 的数据在我的复测里基本落在同一范围内。5. Python 异步爬虫用例一个需求两种工程质量5.1 原封不动把需求发给 Codex原文的爬虫用例要求多并发、异常重试、数据去重、日志、JSON 持久化、PEP8。我把这些需求整理成下面这段提示词分别在两个模型下运行请写一个 Python 异步爬虫要求 1. 使用 asyncio aiohttp 抓取一组 URL 2. 控制并发数支持超时与连接中断重试 3. 对已抓取 URL 做去重 4. 输出 JSON 文件字段包含 url、status、title、fetched_at 5. 记录每条 URL 抓取开始与结束日志 6. 代码符合 PEP8 规范。这里不需要让 Codex 直接连接任何线上服务生成代码后由我在本地用测试 URL 跑再把报错贴回对话迭代。5.2 输出差异集中在异常路径GPT-5.4 生成的版本里ClientSession放在async with块中管理重试逻辑单独抽成了async def fetch_with_retry每次重试前先检查并发信号量是否释放JSON 持久化也放在finally之后避免写入半截文件。Gemini 生成的版本主流程能跑但有几个细节会在真实运行中踩坑某个 URL 连续失败后直接抛异常中断整个任务没有降级为日志记录asyncio.Semaphore的acquire/release与async with混用异常时信号量可能不释放JSON 序列化时如果响应里混入非 ASCII 字符或特殊类型没有做容错处理。这些正是原文提到的“JSON 序列化隐性问题”和“极端异常场景无降级策略”。5.3 本地执行与报错回收我按照提示词让两个模型分别输出代码后存成crawler_gpt.py和crawler_gemini.py用同一组 URL 列表在本地跑。Gemini 版本第一轮跑到第 7 个 URL 就因未处理的连接异常中断第二轮的TypeError: Object of type bytes is not JSON serializable也让任务提前终止。把这两段报错贴回 Codex 后让模型继续修复观察它是否找得到根因GPT 能在收到报错后直接定位到异常处理缺失的位置Gemini 的修复则倾向于在外层再加一个大 try/except 包裹整段逻辑而不是补上具体的重试和序列化降级。6. 复测路上比较隐蔽的三个配置坑6.1 模型 ID 对不上模型广场的命名第一次切到 Gemini 模型时Codex 返回模型不存在。原因是我填的模型 ID 在 TaoToken 模型广场上有版本后缀。改法很简单打开 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 的模型广场找到当前使用的模型 ID原样复制到 config.toml。6.2 Base URL 多写/v1Codex 对兼容通道的 base_url 比较敏感我一开始习惯性填成https://taotoken.net/api/v1结果请求全部落到不存在的路径上。正确写法就是https://taotoken.net/apiCodex 会根据模型类型自行拼后续路径。6.3 旧环境变量覆盖了新 Key如果之前给 Codex 配过 OpenAI 或 Anthropic 的 Key那个 Key 会留在 shell 环境中。TaoToken 的 provider 指定env_key TAOTOKEN_API_KEY后Codex 会优先读自己的 provider 配置但如果旧环境变量里设了OPENAI_API_KEY某些 Codex 版本仍会把它作为兜底鉴权。排查方式是检查当前 shell 里是否存在同名冲突变量env | grep -i key清理后重新 exportTAOTOKEN_API_KEY。7. 复测结论和接下来的顺手动作7.1 我的复测结论把原文数据和自己重测的结果放在一起看核心趋势一致GPT-5.4 的代码稳定性优势不在单点生成能力上而在异常路径的覆盖和对整个工程上下文的保持能力上。Gemini 3.1 Pro 在 32K 以内的小上下文里表现完全可用文本超过 64K 后需要人为把关键信息挪到文档开头或者拆成多轮对话分段补充。对生产环境来说前者更适合当主写模型后者更适合做架构梳理和长文本通读。更多模型的实时能力对比可以直接在 TaoToken 模型对话 里继续验证。7.2 回到控制台看这次复测消耗Codex 已经确认能走通之后建议先到 控制台 API Keys 看一眼这把 Key 的调用记录确认刚才的模型切换请求都正常记账如果打算长期用 Codex 做日常编码可以对比 Coding Plan 看套餐是否覆盖这类高频调用。同一把 Key、同一个 Base URL之后不管是继续对比模型还是切回单一模型专注写代码都不用再改 Codex 的 provider 结构。