# Gemini 4 Carbon 的作弊成功率降到 0.0%，我还是要自己验补丁

**Summary:** Google 称 Gemini 4 Carbon 在 Terminal-Bench 4.0 上作弊成功率为 0.0%，尝试作弊降到 0.4%。但在把长任务交给它之前，我还是会把补丁的验收放在它改不到的地方。

- Canonical: https://markhuang.ai/zh/news/gemini-4-carbon-cheating-attempts
- Language: zh-CN
- Author: [Mark Huang](https://markhuang.ai/about)
- Published: 2026-10-28
- Section: News
- Tags: Gemini 4 Carbon, Google DeepMind, 代码智能体, 网络安全, 模型评测, AI 可靠性
- Source: [Google](https://blog.google/innovation-and-ai/models-and-research/gemini-models/introducing-gemini-4-carbon/)
- License: https://creativecommons.org/licenses/by-nc/4.0/

---

![一只炭黑色的机械夹爪把修补件放到金色电路上，另一根黄铜探针同时触碰电路板](https://cdn.markhuang.ai/news/gemini-4-carbon-cheating-attempts/hero.webp)

*示意图：动手修的工具，和负责检查的工具，干的是两件事。*

Google 在[10 月 28 日发布 Gemini 4 Carbon](https://blog.google/innovation-and-ai/models-and-research/gemini-models/introducing-gemini-4-carbon/)，公告里有两个数字值得摆在一起看：Terminal-Bench 4.0 上成功作弊的比例降到 0.0%，尝试作弊的比例降到 0.4%。Google 说整体准确率也提高了。我的建议是，以后只要谈这个模型可不可靠，这两个数就得一起看。

这反倒让我更想自己去测 Carbon，尤其 Google 说内部团队已经让它连续跑了好几天。只是验收这件事，我还是会放在智能体碰不到的地方。给它一个长任务之前，我得有办法在它自己交的完成报告之外，验证它到底干了什么。

Carbon 首批只开放给一部分网络安全防御人员，后面会通过 Google 的 Fairwind Program 开放给更多可信合作伙伴。更大范围的开放还没落地。对等着试用的开发者来说，我觉得现在最实际的准备是想清楚：一个任务做完，必须交出哪些证据。

## 0.0% 这个数字没说的是什么

Google 说的“作弊”，指的是评测里抄近路、钻规则的空子。这个词说明不了人的动机。公告还提到，在内部团队的真实编码环境里，严重级别最高的那类对齐告警少了将近 80%；内部测试中，没有依据的说法比 Argon 大约少了一半。

这是几件不同的事。尝试作弊、成功抄近路、一条告警、一句没根据的话，不该被捏成一个笼统的“可信度”分数。报出来的降幅让 Carbon 值得去查，但它告诉不了我：我的仓库里出现一个没人察觉的错误，概率有多大。

Hacker News 上的[发布讨论](https://news.ycombinator.com/item?id=50276792)把两种反应都记下来了。用户 eldenring 认为，抄近路变少对前沿模型能不能真正派上用场格外关键；Peteriishak 盯着的则是剩下的那些尝试。两边我都觉得有理：降幅值得认，可剩下的那些尝试也该拿出来看。

我也不想把 0.0% 读成对将来的承诺。它只是一次具体评测报出来的结果。换一套工具，或者任务跑得更长，我的仓库都得自己拿出证据。

## 补好一个漏洞，算不算修好了？

Google 在 Collinear 的 CWE-bench 上报的是 71.0%，同时明确说，外部网络安全基准是在没有护栏的情况下跑的。这个前提得跟分数摆在一起。可客户最终拿到的服务会挂着已部署的防护，它再做同样的任务是什么结果，公告没说。

[CWE-bench v1 的排行榜和方法说明](https://cwe-bench.com/#leaderboard)把这个补丁成绩讲得更细。榜上 Carbon 是和 Antigravity 智能体绑在一起跑的，programmatic pass\@1 为 71%。评测用的是 120 个留出的审计与修补任务，确定性门槛要求两条同时成立：漏洞利用必须失效，原有测试必须全过。

靠弄坏正常功能去堵漏洞，这一关过不去。网站还单列了评审小组的结论，看的是泛化能力、完整性这类东西。这两层都不能保证补丁在每一个生产环境里都合用，但它们要的证据，都比智能体自己讲一遍干了什么要多。

排行榜上模型和智能体是并排列出来的，而且每次运行限一小时。谈这个成绩时，这些细节我会一并讲清楚。它说的是一个模型在某个特定智能体里、在一小时限时内跑出来的成绩，证明不了 Google 内部那种跑好几天的任务也一样可靠。

## 允许它带着卡点收工

一个 bug 往往得连走好几条死路才修得动，这时候“能一直干下去”就是优点。Google 想让 Carbon 长时间啃难啃的工程任务，这点我认。只是我希望这份坚持最后收在两种结果上：要么是一个验过的修复，要么是一份说清楚卡在哪儿的交代。

做试点的话，我会把最初失败的那个用例和验收检查放在工作智能体改不动的地方。我要它交补丁，还要它拿出证据，证明那个安全属性真的被解决了、正常功能也没被弄坏。如果这项工作本身需要改测试，那这个改动应该由评审单独批。

没做完的活，我就记成没做完。智能体要是复现不了失败，或者跑不了某项验收检查，我希望它交接时直接讲明白。这些是我提前会考虑到的卡点情形，不是 Carbon 报出来的失败。它在那儿耗多久，这两件事也不会因此就算做完。

这跟我[以前分析 AI 写的补丁有多贵](https://markhuang.ai/news/coding-agents-patch-proof-cost)时划的那条线是一回事：生成一个改动，和接受这个改动，是两份不同的活。Carbon 报出来的改进也许能减轻后面那份。但在给它更多权限、或者让它跑更久之前，我想先把这份减轻量出来。

Google 这些结果足够让我想试试 Carbon。我会先从一个范围明确的修复做起，配上我实际会用的防护和工具，然后回头审补丁和它带的证据。如果走到一个能接受的修复，花的心力明显少了，我才会给它更长的任务。