上周 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 个维度：

1. 代码生成准确率——给同一个 prompt 跑 20 次，人工判断"可直接用 / 需小改 / 完全跑偏"的比例
2. 首 token 延迟（TTFT）——从发请求到收到第一个 token
3. 总生成速度（tokens/s）——完整输出的吞吐
4. 单次请求成本——按 1000 token 输入 + 2000 token 输出算
5. 上下文窗口利用率——塞满 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。

踩坑记录

1. Codex CLI 的 --model 参数如果写错模型名不会报错，会默认 fallback 到 gpt-3.5-turbo，我折腾了半小时才发现输出质量断崖式下降是因为模型名拼错了
2. Flash 3.5 的 streaming 响应偶尔会在最后一个 chunk 卡 200-300ms，体感像是"写完了但没结束"，等一下就好
3. Flash 3.5 的 1M 上下文在实际编码场景中到底有多大意义我也说不准——毕竟大部分时候我们塞给 Codex 的 context 也就 10-30K

小结

Gemini 3.5 Flash 这波升级确实给了一个很实际的选择：日常编码不需要每次都请"最贵的老师"。148 tokens/s 的速度让 Codex CLI 的交互体验接近即时反馈，而 ¥0.3/天 的成本让我完全不用纠结"这个问题值不值得问 AI"。

如果你做的是需要高准确率的生产级代码生成，Sonnet 4.6 那 81% 的一次通过率还是值回票价的。没有银弹，按需切换就好。