大家好，我是孟健。
在独立评测机构 AA 的测试中，Flash High 综合任务均价比 3.7 贵约 40%，不过官方 API 牌价并未调整：每百万输入 token 依然为 0.75 美元，输出包含思考 token 为 3.75 美元，该优惠期将持续至 2026 年 12 月 31 日。
01 厘清官方基准与计费机制
Google 在 2026 年 9 月 2 日发布了普通版 Gemini 3.8 Flash，重点面向长程编码与自主 agent 场景。在官方公布的软件工程基准 DeepSWE v1.1 同设置评测中，3.8 Flash 拿到了 73.7%，高出 3.7 的 65.3%。
官方文档写得很直白：当面对复杂任务时，模型会主动扩充思维链与工具调用步骤，设置高 effort 档位可能消耗更多 token。如果开发者更看重算力效率，官方建议使用低 effort 档位或者沿用 3.7。
现行标准API属于限时优惠，2026年底结束后每百万输入调整为1.50美元、输出7.50美元。**最终账单由输入与含思考的输出各自用量及单价共同决定。**模型扩充步骤会改变结构用量。
官方基准针对的是软件工程修复任务，不能直接等同于全部编码场景，更不能当成本地开发账单的换算系数。
02 查验独立评测的成本分布
关于任务均价上涨 40% 的表述，出自 Artificial Analysis 9 月 2 日发布的评测快照。在包含 agent 调用的特定 Intelligence Index 综合任务集内，3.8 Flash High 档位每任务平均花费 0.58 美元，而前代 3.7 为 0.40 美元。
同一份快照记录显示，High 档位的平均输出 token 数量比 3.7 多出 30%，agent 交互轮次也有所拉长。同场测试中的 Low 档位平均单任务支出为 0.24 美元，展现出完全不同的 token 消耗规模。
Low档位支出更低并不等同于它具备与High档位相同的解决能力。AA当时的分析认为，High档位在提升能力的同时依然兼具成本竞争力。**选档位必须看具体任务能否顺利完成。**如果团队只盯API单位报价，容易漏掉不同模型解决实际问题时的真实用量差异，因此绝不能将AA给出的均价直接套用为自己的最终账单。
AA 于 9 月 4 日更新了 v4.2 榜单，9 月 2 日快照记录的是特定环境样本。AA 综合任务包含 agent 等复杂链路，不等于纯编码场景，本地运行开销更不对应 AA 账单，不能将 40% 的涨幅外推到所有工程。每 token 单价与完成单项任务的实际支出具有不同含义，且 Low 档位的 0.24 美元亦不能直接代表同等交付能力，两者无法简单等同。
03 验证真实模块的交付表现
为了检验代码落地情况，我在本机通过 CLI 调用云端模型接口，在 Docker 隔离环境中运行真实测试。代码仓库使用 Git 冻结源码，所有外部依赖均做 mock 处理，全程不涉及生产改动与全站构建。
测试选用了两个具备代表性的独立模块。第一个是网站生成器 ShipSite 的截图恢复链，要求最多 3 页并发并设定了总预算，难点在于超时触发后创建中的浏览器页面可能延迟返回，由于 Promise.race 无法取消延迟的异步操作，后续链路需要接管未完成资源，并在超时清理时设置等待上限。
第二个模块是 AI 编程出海领航计划 ShipSolo 的后台统计缓存，要求支持上游凭据与查询隔离、同 key 并发合并、失败后下次可重新回源、返回对象独立防污染、120 项 LRU 结果缓存以及 5 分钟 TTL，同时兼容真实的公历处理与 owner 和 admin 接口。
每种配置对每个任务仅保留一个初始样本，Flash Low 是观察 High 结果后追加的探索，对既有代码重复验收并不算作新生成。Astra High 与 Flash Low 的首稿均分别跑通了 ShipSite 的 15 项和 ShipSolo 的 36 项行为测试，且各自独立通过了真实工程的 TypeScript 检查。
Flash High 在 ShipSite 任务中遭遇了交付波动，第一轮因渠道工具拒绝返回空响应，第二轮遇到输出上限截断。我们从未经人工修改的留存完整片段中提取补丁，该补丁通过了全部 15 项行为测试，但提取本身脱离了原生完整交付；在工程 TypeScript 检查中，同一处可选 close 在回调内丢失类型收窄，引发了两条诊断。
在 ShipSolo 任务中，Flash High 第二轮交付恢复正常，顺利通过全部 36 项行为测试与 TypeScript 检查。行为验证与类型检查必须分开独立验收。 这两次交付结果仅代表特定样本的表现。
04 追加防御复验定位隐形盲区
拿到 ShipSolo 模块通过验收的代码后，我没有重新调用模型生成补丁，而是将 Astra High 首稿、Flash Low 首稿与 Flash High 第二稿直接作为候选对象，连同原工程基线和人工参考实现，追加了四种边界场景复验，每个场景重复运行两次。
这几项防御复验属于事后补充的要求，原有的 36 项测试结果保持不变。由于并未让模型依据新约束重新修复，该项测试衡量的是既有生成代码的防御底线，而非模型能力的绝对上限。
在正向防御场景中，测试模拟了上游返回 HTTP 200 但响应体为非法 JSON 格式。三份模型候选方案表现一致，均成功拒绝了 4 个并发调用者，并且在上游恢复后下一次同 key 查询能重新发起回源。
但在另外三种非预期场景中，现有方案暴露了共性缺口：
当模拟上游返回 HTTP 200、JSON 语法合法但内容只有 error 字段而缺失 results 时，三份候选方案都直接将这个错误响应作为有效数据存入缓存。当模拟上游恢复正常后，下一次发起的同 key 查询依然直接读取缓存中的错误对象，没有触发回源。
在模拟上游挂起时，200毫秒本地观察窗内两个相同key调用均未完成，底层仅触发了1次模拟fetch。未完成状态受限于当前观察窗，框架或调用方可能另设超时机制，这并不代表调用永远不返回。
在150个不同query key并发进入的场景中，系统在释放模拟上游之前一次性发起了150次模拟fetch。120项结果缓存容量只负责约束最终存储规模，无法限制同时进行的请求数量。
原工程保留的人工参考解在面对这些场景时同样出现了相同的未拦截情况。单元测试全绿只证明通过了已明确写出的规格说明，没有被测试覆盖的业务防御依然需要人工介入定义。
05 结合确定性合理规划预算
编码升级主要参考 Google 官方在同等 DeepSWE 设置下 3.8 对 3.7 的基准，任务额外支出依据 AA 数据，本地测试仅针对现有模块候选方案，不可直接把全部收益归结于推理深度。
评测工具链的上下文差异同样存在，Astra 在 Hermes 环境下首轮读取了通用评测 skill，而 Flash 接入的是 agy 工具壳。环境与上下文的不同意味着我们无法直接给模型排出一个裸模型胜负榜，开发者应当把精力放在预算与产出的匹配上。
面对规则清晰且配备自动化验收的日常修复，建议先尝试 Low 档位。AA 给出的 Low 任务成本提示其具备性价比尝试空间，但并不意味着其消耗绝对最低或能推广至全部任务。
当面对探索性强、步骤繁琐的复杂场景时，再考虑开启 High 档位，并通过团队自身的实际难题来权衡更高的 token 消耗是否换来了对应的业务价值。
返回业务结构校验、主动超时及在途并发限制均应显式纳入工程验收环节。单价更高的调用并不能免除校验步骤，团队应结合自动化验证带来的具体收益来理性分配模型预算。
👋 我是孟健，前腾讯 T11 / 前字节技术 Leader，现在全职做 AI 编程。
🔥 更多 AI 编程实战：
- GitHub：@mengjian-github
- 专栏：AI编程实战
觉得有用？点赞+收藏 就是最大支持 🙏