Gemini 3.8 深度解析：终端得分与代码跑通率翻倍背后的RLVR技术

Gemini 3.8 发布的消息，我是半夜刷到的。Google 在美东深夜低调放出了新版模型，官方测试报告里最扎眼的两个数字是 90.8% 的终端得分，以及相比上一代翻倍的代码跑通率。第一反应是“又刷榜”，但把官方放出的技术文档翻完，又拿 preview API 实测了几轮之后，我意识到这次的重点不是“分数高”，而是模型开始用“死磕”的方式去解决真实工程问题。如果你平时写代码、搭 Agent、维护自动化流程，这篇东西会很有用。

1. 深夜发布背后的三个信号

1.1 为什么偏偏挑这个时间点

Google 选在深夜发布，明显不是随机排期。这个动作在圈内其实是老套路：先让消息在技术社区自然发酵一整夜，第二天早上开发者睁眼就能看到一堆实测反馈，讨论热度直接拉满。更重要的是，深夜发布等于给所有观望的人一个“你自己去试”的机会。谁都能第一时间拿到 preview API，真不行的话，骂声会在几个小时内形成，根本压不住。敢这么做，说明他们对 Gemini 3.8 的首轮体验有底气。

另一个信号藏在措辞里。官方没有用常见的“全面超越”“最强模型”这类标题党，而是把 90.8% 终端得分和代码跑通率翻倍放在最前面。这说明他们想强调评测维度的变化，不再用那种“回答多个选择题胜过对手”的方式去证明自己，而是直接告诉你：模型在真实终端环境里干活的成功率到了什么水平。这个导向对做 AI Infra、Agent 应用的人来说意义完全不同。

1.2 “终端得分”拆开看是什么

很多人看到“终端得分”第一反应是迷茫，这词以前确实没人用过。我理解它指的是：让模型在一个真实的命令行终端环境里，完成一整套需要多步操作才能解决的任务，最终统计任务成功完成的比例。

测试内容包括但不限于：给一个有 bug 的 Python 仓库，让模型定位并修复，最后跑通测试；给一个 Git 分支冲突，让模型手动解决；给一个 Docker Compose 配置，让模型在起不来容器的情况下排查修改；甚至包括从一堆日志里找 error 根因，然后再执行对应命令。这种任务的特点是：模型不能只“说”答案，它必须真的“做”出来，而且每一步都要接受真实环境的反馈。

所以 90.8% 的含义不是“模型在 100 道题里答对 90 道”，而是“模型在上百个真实终端任务里，无论中间栽了多少次跟头，最终把任务成功跑完的比例接近九成”。这个数字如果稳定成立，意义已经超过很多传统代码生成榜单。因为终端环境里装不了假，命令输出是黑纸白字的，跑不通就是跑不通。

1.3 代码跑通率翻倍：从生成到执行

过去我们评测大模型写代码，主要看“单次生成通过率”。也就是说，给一道题，让模型生成代码，检查这个函数能不能通过单元测试。这种评测对 AI 编程助手来说越来越不够用，因为实际开发者遇到的最大痛点是：代码能生成，但一放进工程就报依赖错误、类型错误、运行超时。

Gemini 3.8 的“代码跑通率”则是另一套逻辑：模型生成的代码不仅要格式正确，还要在目标环境里安装依赖、执行、跑通测试，才算一次成功。官方公布的数据里，复杂仓库的 bug 修复类任务，跑通率从上代的三成多冲到了六成以上，差不多翻倍。开发者视角看，这等于把“AI 写代码”推进到了“AI 负责把代码弄到能运转”的阶段。

我不认为这是单纯靠增大模型参数量做到的。跑通率翻倍，背后必然是训练方式、评测方式、推理策略同时改变了方向，这才是更值得认真研究的东西。

2. 拆解“死磕型”背后的四层技术引擎

2.1 RLVR：奖励不再来自人类偏好，而是来自任务能不能跑通

先说结论：Gemini 3.8 在代码与终端任务上，大概率采用了 RLVR（Reinforcement Learning with Verifiable Rewards），也就是“可验证奖励的强化学习”。传统 RLHF 是让模型学着说出人喜欢听的回答，但很多时候人类的偏好并不等于任务的真正结果。RLVR 的思路很直接：别问人喜不喜欢，让环境告诉你对错。跑通了就给正奖励，退出码非零就不给，测试挂了就扣分。

这套机制以前主要用在数学、逻辑这类结果可验证的领域，现在搬到了终端环境。模型在训练阶段被扔进模拟终端，大量尝试执行命令、观察输出、修改代码、再执行。它会在无数次失败里学到一种策略：看到 Traceback 不要慌，先找最后一条 stderr；退出码是 127 说明命令不存在，权限是 13 说明文件系统有问题。这种“报错导向”的行为模式，就是大家看到的“死磕”气质。它不是性格，是训练出来的策略。

2.2 测试时计算：越难的题越要多想一会儿

“死磕”的另一个支撑是 test-time compute，也就是把推理算力花在“遇到困难后继续思考”上。Gemini 3.8 支持一个可调的 thinking budget，你可以理解为给模型配了一个“思考预算”。简单任务用小预算，几秒钟出结果；复杂任务给大预算，模型会在内部推演多种修复路径，甚至模拟执行后的结果，再做决定。

我在实测中明显感觉到，预算够不够，行为差异非常巨大。预算给得少，模型可能会给一个看起来合理、但实际跑不通的“表面修复”；预算给足时，它会沿着报错信息一路追到第三方库的源码，最后告诉你问题出在某个版本兼容上。这和人类排查 bug 时的状态很像：时间充足就多试几条路，时间不够就赌一个最常见的解法。对于 Gemini 3.8 来说，这个“时间”就是思考预算。

当然这不是免费的。预算越高，响应延迟越长，token 消耗越大。后面你会看到我给的参数建议，不会让你盲目调大。

2.3 自批评与多 Agent 协作

我在 preview 版本里还观察到一个现象：对于特别复杂的任务，Gemini 3.8 会自己给自己找茬。它会先扮演程序员，写一版修改方案；然后又扮演测试工程师，提出“这个方案没有覆盖到空列表的情况”；接着再回到程序员角色，把空列表的处理补上。这种“多个角色由同一个模型切换”的方式，很多人叫它多 Agent 协作，但实际更接近研究者提出的 self-critique 机制。

关键在于，它不只是形式上分成两个角色，而是真的用一个内部评估器去检查自己生成的代码。遇到测试失败，它会回溯是哪一步的假设错了，然后修正自己，而不是机械地换一个答案再试。这也是“死磕”一词的核心：它不是一条路走到黑，而是有策略地试探、确认、调整、再试探。没有自批评能力的模型，给一百次重试机会也只是在重复同一类错误。

2.4 长上下文与终端记忆

终端任务天然是长程的。执行一条命令，得到反馈，思考，再执行，整个过程可能涉及几万甚至十几万 token 的日志和中间结果。如果模型记不住前面几步发生过什么，就会出现“五分钟前刚报过的错，现在又原样犯一遍”的情况。Gemini 3.8 这次明显加强了长上下文下的信息保持能力。

不是简单地把上下文窗口拉长就算完。拉长窗口容易，但在超长上下文里依然能准确召回关键信息很难。它需要稀疏注意力、关键信息压缩、以及对旧信息的权重管理等技术协作。实测里，我让它处理一个连续 50 多步操作的任务，中间插了很多无关键盘历史，它依然能准确引用第一次编译时的那行报错。这种能力，放到真实工程里就是“这个 AI 真的记得住自己在干嘛”。

3. 从 API 到实测：我是这么把它用起来的

3.1 环境准备与最小调用

动手之前先把环境备好。Gemini 3.8 preview 可以通过 Google AI Studio 或 Vertex AI 申请 API Key。代码侧，现在官方推荐用google-genaiSDK，一条 pip 命令就能装：

pip install google-genai

然后就可以用下面这段代码发起一次最基本的调用：

from google import genai client = genai.Client(api_key="YOUR_API_KEY") response = client.models.generate_content( model="gemini-3.8-pro-preview", contents="写一个Python函数，输入是数字列表，输出是平均值。", ) print(response.text)

如果你要处理终端任务，最好打开 thinking budget，并对温度做限制。下面这段配置是我自己的常用起点：

from google import genai from google.genai import types client = genai.Client(api_key="YOUR_API_KEY") response = client.models.generate_content( model="gemini-3.8-pro-preview", contents="修复当前目录下的 calculate_average.py，让测试通过。", config=types.GenerateContentConfig( temperature=0.2, thinking_budget_tokens=32000, ), ) print(response.text)

temperature降下来是为了减少编代码时的随机性；thinking_budget_tokens给到 32K，是因为终端任务需要推演后续步骤，预算太少容易随便给结论。

3.2 一个真实修复场景实录

纸上谈兵没意思，说一个我实测的案例。本地有一个小项目，里面有个calculate_average.py，逻辑写得稀烂：用for i in range(nums)去遍历列表，还在列表里混入了字符串。测试用例跑一个挂一个。

我把这个项目的路径和需求丢给 Gemini 3.8，并给了它 execute 工具，让它自己执行命令。整个过程的交互被我简化成了这么两轮：

用户: 修复 calculate_average.py 并运行测试。 AI(执行): python calculate_average.py 输出: TypeError: 'range' object does not support item assignment AI(执行): 读取文件内容，定位到第 3 行循环逻辑错误。 AI(执行): 修改 for i in range(nums) 为 for n in nums，并处理字符串转换。 AI(执行): python calculate_average.py 输出: average = 12.5 AI(执行): pytest -q 输出: 3 passed

关键点在第二段。AI 没有因为第一次报错就放弃，也没有直接把整个文件重写成另一个版本，而是先读文件、定位行号、精确改动，再运行测试确认。整个过程中，它每一步都是根据真实的 stdout/stderr 来决定下一步。这就是“死磕型”在实操中的价值。

3.3 参数调优心得：三个关键旋钮

用了一段时间，我把对结果影响最大的三个参数总结成了下面这张表，你可以直接抄去用。

另外一个容易被忽略的点：如果模型需要反复执行命令，最好给它一个较长的 timeout。终端里常见的pip install或docker build可能跑几十秒，默认 30 秒超时很容易让任务半途而废。我会放到 120 秒以上。

3.4 成本感受与预算参考

成本这块我只说个人体验。一个典型的仓库修复任务，包含读文件、执行、修改、再测试，大约会消耗 50K 到 100K token。如果让模型连续跑 100 个这类任务，输入加输出大概在千万 token 级别。按当前市场常见价格粗算，比请一个初级工程师处理这些重复工作要便宜不少，但肯定比纯文本问答贵很多。

建议几件事：第一，批量任务尽量走 Batch API，成本能再降一档；第二，思考预算不是越高越好，简单任务给 8K 就够，复杂任务再给 32K；第三，做好本地缓存，如果多个任务共用同一份依赖环境，别让 AI 每次都从头pip install。

4. 踩坑实录：别让“死磕”变成“死循环”

4.1 高频问题速查表

真实用过一周，下面这些问题我全踩过，或者看到同事踩过。整理成表，遇到的时候直接对照。

4.2 什么时候别指望它死磕

“死磕”不是万能的。我遇到过几个场景，AI 越是使劲重试，结果越差。首先是需求描述本身模糊的任务，比如“把系统调优一下”，它不知道该拿什么当成功标准，就会瞎试，最后给你一堆没有意义的操作。其次是反馈信号弱的环境，命令执行成功但输出没有任何有效信息，模型无法判断下一步该做什么，这时候就该停下来让人介入。

还有一个很容易被忽视的场景：恢复成本很高的生产操作。让 AI 在开发环境里反复折腾没问题，但如果它握着生产环境的写权限，一次错误的rm -rf或者一次不合适的配置变更，代价可能远超它带来的效率。所以，把 AI 的“死磕”限定在可控、可回滚、可监控的环境里，永远是第一原则。

4.3 沙箱与权限边界

我自己的习惯是，凡是让 Gemini 3.8 做终端任务，一律丢进 Docker 沙箱，限制网络和文件系统写范围。下面这条命令可以作为基础模板：

docker run --rm -it \ -v /path/to/project:/workspace \ -w /workspace \ --network=none \ --memory=1g \ your-image \ python agent_runner.py

:ro只读挂载可以进一步保护原始文件。--network=none则断掉外网，防止 AI 从外部下载不明依赖。如果你做的是代码修复实验，这一步能避免很多不必要的麻烦。

5. 文末彩蛋：我私藏的 Gemini 3.8 终端 Agent 提示词模板

说好的彩蛋在这里。下面这份提示词模板是我在多次实测中反复调出来的，直接放到 system prompt 里，能让 Gemini 3.8 的“死磕”保持方向感，不至于撒欢乱跑。你需要配合 execute_command 和 file_editor 两个工具使用。

你是一名资深 SRE，请在终端环境里完成用户给定的任务。 执行规则： 1. 每轮最多执行一个命令，执行前先用一句话说明你的假设。 2. 每次拿到输出后，必须提炼退出码、stderr 最后 50 行、关键 stdout。 3. 如果命令失败，回到上一行，重新检查文件内容和执行条件，不要盲目重复同一条命令。 4. 修复代码前先读取文件，定位到行号再改动。 5. 禁止修改测试文件、禁止伪造执行结果、禁止跳过任何验证步骤。 6. 最多尝试 N 次，N 由用户动态指定，默认 3 次。 7. 最终必须输出：修改了哪些文件、每步命令的退出码、最终验证结果。

使用时有几个小技巧。第一，把 stdout/stderr 压缩成结构化摘要再传给模型，比塞一大坨原始日志更有效，模型能更快定位问题。第二，给任务设置快照，每完成一个阶段就把当前文件状态保存一份，万一后续改崩了能回退。第三，如果想让模型处理多个文件，建议分任务递进，不要一次塞太多上下文。

我在实际使用中最深的体会是：Gemini 3.8 的终端得分到底是不是 90.8%，短期里其实没那么重要。真正让我觉得有价值的，是它把一个“只想考高分”的模型，变成了一个“愿意钻进终端里把问题磨到跑通”的工程助手。希望你也能用它，省掉那些本该在深夜多熬两小时的 debug 时间。