上周 Google 发了 Gemini 3.5 Flash，我当天晚上就拿 Codex CLI 接上跑了几个项目里的真实任务。原因很简单——我们团队最近 token 开销涨得太快，老板让我找个"又快又便宜还不太拉胯"的模型顶日常编码场景。Claude Sonnet 4.6 质量没话说但贵，GPT-4o 稳定但慢，Flash 系列一直是性价比标杆，3.5 版本到底有没有质变？测完数据我人傻了，直接说结论吧。
先说结论
Gemini 3.5 Flash 在代码生成准确率上已经逼近 Claude Sonnet 4.6 的 90%，推理速度快了将近一倍，价格只有 Sonnet 的 1/5。如果你的场景是中等复杂度的日常编码（CRUD、脚本、单元测试、重构），Flash 3.5 完全够用。但涉及复杂架构设计和多文件联动修改，Sonnet 4.6 依然是王者。
评测维度
这次我设了 5 个维度：
- 代码生成准确率——给同一个 prompt 跑 20 次，人工判断"可直接用 / 需小改 / 完全跑偏"的比例
- 首 token 延迟（TTFT）——从发请求到收到第一个 token
- 总生成速度（tokens/s）——完整输出的吞吐
- 单次请求成本——按 1000 token 输入 + 2000 token 输出算
- 上下文窗口利用率——塞满 32K context 后质量是否明显下降
测试环境：Codex CLI v0.9.3，所有模型走 OpenAI 兼容协议，香港。每个测试跑 3 轮取中位数。
评测结果天梯图
| 维度 | Gemini 3.5 Flash | Claude Sonnet 4.6 | GPT-4o |
|---|---|---|---|
| 代码准确率（可直接用） | 72% | 81% | 68% |
| 代码准确率（需小改） | 18% | 14% | 22% |
| 首 token 延迟 | 180ms | 420ms | 350ms |
| 生成速度 | 148 tokens/s | 82 tokens/s | 95 tokens/s |
| 输入价格（/1M tokens） | $0.15 | $3.00 | $2.50 |
| 输出价格（/1M tokens） | $0.60 | $15.00 | $10.00 |
| 上下文窗口 | 1M | 200K | 128K |
| 32K 填充后质量衰减 | 约 5% | 约 3% | 约 8% |
说实话看到价格那行的时候我反复确认了三遍。Flash 3.5 输出价格是 Sonnet 的1/25，这差距大到离谱。
第一梯队：Claude Sonnet 4.6
质量依然是天花板。我测的 20 个 prompt 里有 3 个是比较刁钻的——重构一个 300 行的 React 组件、给一个没文档的 Go 项目写集成测试、把一段 callback hell 改成 async/await。这三个 Sonnet 全部一次过，Flash 和 GPT-4o 都需要手动改 1-2 处。
代价是：慢，贵。TTFT 420ms 在 Codex CLI 里体感很明显，你按回车之后要等将近半秒才开始出字。一天写代码调个 50 次，算下来光输出就要 ¥5.2 左右（按平均每次 2K output tokens）。一个月下来能差出好几百块。
第二梯队：Gemini 3.5 Flash 和 GPT-4o
这俩放一起是因为综合体验接近，但各有偏科。
Flash 3.5 赢在速度和价格。148 tokens/s 的生成速度意味着一个 200 行的函数 3 秒就出完了，同样 50 次调用一天花费不到 ¥0.3，1M 上下文窗口塞整个项目的代码都没压力。
Flash 3.5 的短板是偶尔会"自信地写错"——生成的代码看着没问题，跑起来有隐蔽 bug。我遇到一次它把 Go 的 slice append 写成了覆盖赋值，编译能过但运行时数据丢失。对复杂类型推断也不如 Sonnet，TypeScript 泛型嵌套超过 3 层就开始乱猜。
GPT-4o 中规中矩，没有特别亮眼也没有明显短板。报了一次429 Too Many Requests让我等了 20 秒，挺烦人的。价格卡在中间不上不下，有点尴尬。
Codex CLI 接入配置
Codex CLI 走 OpenAI 兼容协议，改 base_url 就行。我的~/.codex/config.yaml：
# Gemini 3.5 Flash via 聚合平台 provider: openai-compatible model: gemini-3.5-flash api_key: sk-xxx base_url: https://api.ofox.io/v1切模型就改 model 字段，其他不用动：
# Claude Sonnet 4.6 model: claude-sonnet-4.6 # GPT-4o model: gpt-4o实际调用链路长这样：
graph LR A[Codex CLI] -->|OpenAI 兼容协议| B[API 聚合网关] B -->|官方通道| C[Gemini 3.5 Flash] B -->|官方通道| D[Claude Sonnet 4.6] B -->|官方通道| E[GPT-4o] C --> F[响应返回] D --> F E --> F真实场景对比：重构一个 Express 中间件
我给三个模型同一个 prompt：
把下面这个 Express 错误处理中间件重构成支持自定义错误码映射的版本，要求 TypeScript，支持 async handler
Flash 3.5 的输出（2.1 秒完成）：
// Flash 生成的代码，能直接跑，但类型定义略粗糙 type ErrorMap = Record<string, { status: number; message: string }> export const createErrorHandler = (errorMap: ErrorMap) => { return (err: Error, req: Request, res: Response, next: NextFunction) => { const mapped = errorMap[err.constructor.name] if (mapped) { res.status(mapped.status).json({ error: mapped.message }) } else { res.status(500).json({ error: 'Internal Server Error' }) } } }Sonnet 4.6 的输出（4.8 秒完成）多了泛型约束、JSDoc 注释、还额外加了一个isOperationalError判断。质量确实高一档，但对于"快速迭代先跑通"的场景，Flash 那版够用了。
GPT-4o 用了 3.6 秒，输出质量介于两者之间，但它给了一个我没要求的express-async-errors的 import，导致如果项目里没装这个包会直接报错：
Error: Cannot find module 'express-async-errors'这种"自作主张加依赖"的毛病 GPT-4o 犯得比较频繁。
不同需求怎么选
| 你的场景 | 推荐模型 | 理由 |
|---|---|---|
| 日常 CRUD、脚本、单测 | Gemini 3.5 Flash | 快+便宜，质量够用 |
| 复杂重构、架构设计 | Claude Sonnet 4.6 | 准确率高，理解深 |
| 预算有限但要稳 | Gemini 3.5 Flash | 成本是 Sonnet 的 1/25 |
| 多模态（代码+截图） | GPT-4o | 图片理解还是 OpenAI 强 |
| 超长上下文（整个 repo） | Gemini 3.5 Flash | 1M 窗口碾压 |
我目前的方案是：Codex CLI 默认挂 Flash 3.5 处理日常编码，遇到复杂任务手动切 Sonnet。聚合 API 可以选 OpenRouter、ofox.io 这类——OpenRouter 收 5.5% 手续费，ofox 是 0% 加价对齐官方价格，改个 base_url 就能切，不用每个模型单独管 Key。
踩坑记录
- Codex CLI 的
--model参数如果写错模型名不会报错，会默认 fallback 到 gpt-3.5-turbo，我折腾了半小时才发现输出质量断崖式下降是因为模型名拼错了 - Flash 3.5 的 streaming 响应偶尔会在最后一个 chunk 卡 200-300ms，体感像是"写完了但没结束"，等一下就好
- Flash 3.5 的 1M 上下文在实际编码场景中到底有多大意义我也说不准——毕竟大部分时候我们塞给 Codex 的 context 也就 10-30K
小结
Gemini 3.5 Flash 这波升级确实给了一个很实际的选择：日常编码不需要每次都请"最贵的老师"。148 tokens/s 的速度让 Codex CLI 的交互体验接近即时反馈，而 ¥0.3/天 的成本让我完全不用纠结"这个问题值不值得问 AI"。
如果你做的是需要高准确率的生产级代码生成，Sonnet 4.6 那 81% 的一次通过率还是值回票价的。没有银弹，按需切换就好。
