鱼皮AI导航
鱼皮AI导航
  • 主页
  • 社区
  • AI工具
  • AI知识库
  • AI提示词
  • MCP
  • Skills
  • AI学习资源
  • AI资讯
  • GitHub开源
登录/注册
站长:程序员鱼皮 老鱼简历 商务合作 增值电信业务经营许可证
2026 鱼皮AI导航 | 沪ICP备19026706号-6
8
3
2

刚刚 Gemini 4 Argon 发布,对谷歌最失望的一集!

程序员鱼皮
程序员鱼皮
2026-10-14 14:10
阅读 1435
程序员鱼皮
2026-10-14 14:10
阅读 1435

大家好,我是程序员鱼皮。

今天凌晨,Google 终于把 Gemini 4 Argon 模型全面放出来了。

这个模型其实 9 月 30 日就官宣了,但当时只给了一批安全厂商内测,普通用户又干等了两周。

这也是 Google 七个多月来 第一次发布 Flash 以上级别的新模型。

这大半年里 Anthropic 和 OpenAI 轮番发旗舰,Google 只顾着更新 Flash,网友对它的评价 be like ↓

先看看新模型的价格。11 月 30 日之前是限时五折,每百万 token 输入 2 刀、输出 10 刀,之后恢复到 4 刀和 20 刀。

第三方评测机构 Artificial Analysis 算过一笔账,Argon 跑一个测试任务平均花 1.99 刀,Claude Opus 5.5 要 5.98 刀,但 GPT-6.1 Sol 只要 0.72 刀。

也就是说,Argon 在旗舰模型里算便宜的,但还谈不上性价比之王,等五折结束价格还要翻一倍。

再看能力。官方跑分表里跟 GPT-6 Astra、Claude Fable 5.1、Claude Opus 5.5 比了 19 项,Argon 拿了 14 项第一!

官方跑分总表

不过在编程能力上,Argon 并没有全胜。考察命令行编程能力的 Terminal-bench 4.0 上,Argon 只有 57.4%,比 Opus 5.5 低了整整 9 个点。

有一说一,官方放出来的演示是真的唬人。比如这个巫师国际象棋,你看到的所有画面元素都是 Argon 自己完成的。

官方演示的巫师国际象棋

还有一个演示更夸张,Argon 把一张办公桌的照片,直接变成了一个能玩的微缩赛车游戏。

官方演示的桌面赛车

看完这些,我对它的期待一下子就拉满了。

当然,跑分和官方演示都只是参考,模型好不好用,还得拿真实项目来检验。

老规矩,鱼皮实测启动!

这次实测 3 个项目,由浅入深分别为:

  1. 3D 版动画知识讲解
  2. 以撒的结合肉鸽游戏
  3. 零依赖桌面微缩赛车

点个收藏,咱们开始~

1、3D 版动画知识讲解

为了对比,第一个测试我直接复用老的。让 AI 用 3D 动画讲解 Kimi K3 的「注意力残差」机制,提示词跟之前测 Claude Opus 5 和 Kimi K3 时一字不差。

提示词里我只要求 AI 先联网查资料、用 Context7 查 3D 库的最新文档,场景怎么搭、动画怎么编排全部放开交给 AI。

AI 先用 Firecrawl 把注意力残差的原论文抓下来核对公式,又查了 Three.js 的文档,11 分钟左右就交卷了。

来看成品。页面分成四幕,第一幕讲传统残差的毛病,用「64 层大楼的大锅汤」做比喻,越往上的楼层越膨胀,第 1 层的关键信息被稀释到只剩 1.6%。

第二幕切换到注意力残差,第 15 层伸出一根紫色探针回头检索,从第 0 层架起一座金色光桥直达顶层,早期信息的保留率一下子拉到了 96.7%。

最后一幕把两座塔并排对比,右侧还能切换不同的场景,拖动滑块就能实时看到每一层权重的变化。

虽然内容没啥毛病。

但是,前端的问题很明显!

左右两块信息面板塞得太满,把中间的 3D 场景挤得只剩三分之一,塔顶还被顶部导航栏挡住了一截。

而且仔细一看,图例和滑块上一共有 6 处公式压根没渲染,直接露出了 alpha_{i \to l} 这种源码。

页面上满屏都是 Emoji 就更不用多说了……

手机端的适配也很一般,大家自己感受一下吧:

之前 Kimi K3 的版本干净利落,只有一排节点和金色弧线。

Kimi K3 的 3D 版本

Claude Opus 5 的版本同样做了两种残差的并排对比,而且画面布局更合理,更利于阅读。

Claude Opus 5 的 3D 版本

论信息量,Argon 是三个里最多的。但显然,Opus 5 那一版更适合给人用。

2、以撒的结合肉鸽游戏

第二个项目我让 AI 复刻「以撒的结合」游戏。这道题的提示词同样跟测 Opus 5 时一模一样,难点在于角色、怪物、道具全部要用代码画出来,还要有随机地牢、道具系统和 Boss 战。

12 分钟后,AI 交卷了。开始界面有点儿原作的味道,哭唧唧的以撒对面站着第一层的 Boss 萌斯戳(我也不知道 AI 为啥要这么翻译)。

我翻了一下 AI 的自测脚本,发现 Boss 战和通关这几张截图,都是用调试接口直接传送到对应房间拍的。Boss 那张「激战」截图,是脚本先把 Boss 的血量改成 78、再挪到指定位置摆出来的,通关界面上的击杀数和存活时间也是脚本直接写进去的。

所以我又让 AI 写了一个脚本,只用键盘从第一个房间开始真实体验游戏。

战斗画面还不错,岩石、便便堆、小地图、属性面板一应俱全,四种小怪的走位方式各不相同。

清完房间会刷出道具,比如拿到「蟋蟀头」之后,以撒头上多了一个猫耳头套,攻击力从 3.5 涨到 6.6,眼泪也变成了三连发。

这就是 AI 自测时摆拍的那张 Boss 战,萌斯戳的造型倒是还原得挺到位。

然后就尴尬了,我的脚本进 Boss 房 2.5 秒后截了张图,发现萌斯戳已经被打死了……

不是哥们,115 滴血的 Boss,被三连发的眼泪两秒多就打没了?这是不是有点太简单了。

AI 自己没发现这个问题也不奇怪,因为它的自测从来没有从第一个房间一路打到 Boss 房。

最后小人儿触碰金箱通关,会弹出一个结算界面:

再看看用同一段提示词的 Claude Opus 5 版本,房间里铺满了血迹和岩石,细节更丰富。

Claude Opus 5 开发的以撒游戏

之前 Kimi K3 做的版本就简陋多了。

Kimi K3 开发的以撒游戏

整体来看,Argon 的美术还原度已经接近 Opus 5,比 Kimi K3 好了一大截。但是数值平衡完全没调,Boss 一碰就碎,可玩性大打折扣。

3、零依赖桌面微缩赛车

第三个项目,我想专门测一下 Argon 主打的 3D 能力。

开头提到的那个官方演示里,Argon 把一张办公桌的照片变成了能玩的微缩赛车游戏,但官方用上了 Blender、Nano Banana 和 Three.js 一整套工具。

这次我把工具全部拿掉。提示词里卡死了一条,不准用任何第三方库和外部素材,3D 渲染、物理碰撞、引擎声音全部从零手写。赛道怎么设计、桌面物件怎么建模,我一个字都没写。

不到 11 分钟,AI 就交卷了。3400 多行代码里,矩阵运算、赛道曲线、着色器、漂移物理全是手写的,真的一个库都没用!

点击开始,起跑线上有黑白格和拱门,左边是逐个键帽建模的机械键盘,倒计时结束就能发车。

过弯时按住空格可以甩尾漂移,后轮会喷出白烟,右上角实时显示漂移角度。

画面是方块风格,比如你看马克杯就是一个红色圆柱,跳台就是一块纯黄色的平板,离官方演示那种写实感差得远。

但别忘了,这可是纯手写的 WebGL。

下图是 AI 自测时拍的成绩单,三圈的圈速、漂移积分、碰撞次数都有。

然而我翻代码时发现,这张成绩单是假的!

AI 在游戏里给自己留了一个「演示结算」的口子,自测脚本先把车传送到终点,再把编好的三个圈速和写死的积分塞进去,实际上一圈都没跑过。

AI 确实用浏览器打开了游戏,也用键盘开了几段,每张截图都自己看过一遍。只不过它的测法是把车直接放到弯道口、键盘边上,开两秒就截图,相当于只抽查了几个片段。

真正的问题在于,整个游戏最核心的那条链路,也就是从发车、跑完三圈、计圈到结算,AI 一次都没验证过,最后那张成绩单还是拿假数据凑出来的。

于是我又让 AI 写了个自动驾驶脚本,只按方向键,真实跑完三圈。

好在游戏本身是真能玩的,计圈和结算都没问题。

我的感受

3 个项目跑下来,我对 Argon 有了一个基本的判断。

不知道是不是我最近 Claude Opus 5.5 和 GPT-6 Astra 用多了,我对 Gemini 4 Argon 还是有些失望的。

它确实能完成独立的项目开发,功能清单一条条对下来,好像也都符合要求。但真上手用一下,我发现它离能直接交付还差得远。

跟其他顶级模型比,差距就在这个 可交付性 上。

当然进步也是有的。3 个项目的完成速度都不错,3D 和美术能力比以前的 Gemini 强了不少,以撒那个项目的画风接近 Opus 5 了。

但是 AI 自测验证会偷懒的问题,也不止我一个人遇到。海外科技媒体 Every 的团队实测发现,Argon 在 38 次测试里有 17 次,代码审查这一步从打开到关闭只隔了 30 毫秒,等于根本没看。

我又翻了一圈网友的实测,整体评价跟我差不多。有人拿 Argon、Opus 5.5、GPT-6.1 Sol 和 Astra 做同题对比,结论是 Opus 5.5 依旧断崖式领先,Argon 第一轮还报了语法错误;也有开发者直说 Argon 的前端和动效不行,缺少审美。

那网上那些刷屏的惊艳 3D 作品是怎么回事呢?

我仔细看了一下,它们大多是在 Google 自家的 Antigravity 里接上 Blender,反复调了好几轮才做出来的,开头那个官方演示也是这样。跟我这种一段提示词、不给任何工具的测法,根本不是一回事。

也就是说,用 Argon 的话,一定要自己验收,千万别把 AI 交上来的报告当成结论。

再说说成本,这 3 个项目一共花了多少钱呢?

答案是 4.55 刀,折合人民币 30 多块钱。

平均下来每个项目 10 块钱左右,跟上个月我用 Gemini 3.8 Flash 跑 3 个项目花的钱差不多。而且这还是五折价,11 月 30 日之后还得翻一倍。

所以,我个人不太推荐大家用 Gemini 4 Argon。

它交上来的东西,还得自己花时间一点点验收和返工。真要做能交付的项目,我宁愿多花点钱用 Claude,至少拿到手的东西能直接用。


OK 就分享到这里,本文会收录到我免费开源的 《AI 编程零基础入门教程》,上千张图、几十万字,带你从 0 开始快速学会 AI 编程,做出自己的产品、跑通变现全流程,一次拿捏。

开源指路:https://github.com/liyupi/ai-guide

鱼皮的 AI 编程教程

我是鱼皮,持续分享 AI 编程干货。觉得有用的话记得点赞收藏和关注~

也欢迎在评论区聊聊:你用 Gemini 4 Argon 了嘛?觉得这个模型怎么样?

AI
编程
程序员
AI编程
计算机
8
2
分享
操作
评论
相关内容
0个评论
全部评论
点击登录,快来和大家讨论吧~
表情
图片

目录

🔥 热门文章
1
手把手教你设计一个成熟的 Agent Harness
2500
2
我用 REA 逆向了付费颜色 APP,结果很意外!
570
3
离谱,DeepSeek 崩了 5 小时,大家却喊:梁圣恩情还不完??
420
4
DeepSeek 全新模型发布,性价比最高的一集!
380
5
B 站上 DeepSeek 闹鱼灾了,我发起《大肥鱼清除计划》!
370
6
自己学习ai,直接买cursor 的套餐,还是买gpt 或者claude 的套餐?
360
7
又一个国产版 Codex 神器,也来卷办公了!
330
8
AI 越强,被它拒绝的代价就越大 我有时候会想:AI 越来越厉害之后,有些事情,会不会反而越来越难做? 这个想法看起来有点矛盾。AI 明明在降低门槛,让不会写代码的人做出软件,让不会画画的人生成图片,让一个人完成过去需要整支团队才能完成的工作。但今天用 Codex 的时候,AI 拒绝帮我编写 SQL 注入的请求体,而那还是我有源码、在本地跑测试的情况。那么,往后是否只会更难? 我们假设某一天,AI 说:「这个请求违规,我不能帮助你。」到那个时候,你还有多少能力,能绕过它,把事情做完? 这里的「违规」需要打个引号。平台的规则、模型的判断、法律的要求,以及一件事实际有没有造成伤害,彼此之间并不总是画得上等号。一个请求可能确实危险,也可能只是缺少上下文被误判,或者恰好落在某家公司的限制范围里。 无论是哪种情况,随着我们越来越依赖 AI,这句拒绝都可能变得越来越贵。 今天,一个程序员让 AI 帮忙写代码,AI 拒绝了,他大概率还有别的办法:查文档、找开源项目、问同行,或者自己写。麻烦一点,慢一点,但路还在。 可如果十年之后,大部分程序都由 AI 完成,情况就不一样了。 很多人从接触编程的第一天起,就习惯了描述需求、等待生成、运行结果、继续迭代。他们能做出相当复杂的产品,却未必经历过独立处理底层问题的训练。平时,这种能力结构完全够用,效率甚至更高。只有 AI 拒绝的时候,他们才会发现:平常被省掉的那段学习过程,恰好是此刻最需要的东西。 到那时,一次拒绝的成本,可能就从「今晚多花两个小时」,变成「先花半年学会这门技术」。 拿 SQL 注入举个稍显极端的例子:往后,连真正理解这类攻击如何发生、能够独立构造测试的人,会不会也越来越少? 这里也包括那些有正当需求的人。一个开发者想检查自己的旧系统,一个经过授权的安全研究员想复现漏洞,假如 AI 识别到危险模式就拒绝,而使用者又只熟悉「让 AI 帮我检查」,这项原本可以独立完成的工作,就这样卡住了。 但是安全专家不会因此消失,但这类技能可能越来越集中在少数人手里。你仍然可以找专家,只是要付出更多的钱、更多的时间,以及更高的沟通成本。 类似的困境,未必只发生在网络安全领域。 你想从一个停止维护的软件里取回自己的数据,需要解析它的旧文件格式。AI 判断这涉及规避保护措施,拒绝继续。你拥有这些数据,却没有能力把它们读出来。 你买了一台设备,厂商停止提供服务。你想修改程序让它继续运转,过程中需要处理某种访问限制。AI 不愿协助,而你所掌握的维修方式,早已只剩下「把报错发给 AI」。 你想给常用的网站写一个辅助工具,减少重复操作。平台将此归入自动化限制,AI 也据此拒绝。过去会写脚本的人可以自己判断、自己处理;未来的使用者,可能连从哪里开始都不知道。 这些例子有一个共同点:当工具同时承担了「执行工作」和「传授知识」的角色,它的拒绝就不只是挡住了一次任务,也挡住了获得这种能力的机会。 更麻烦的是,这种依赖往往是我们主动选择的,而且每一步都很合理。 既然 AI 几秒钟就能做好,为什么还要花几个月学习?既然公司可以采购成熟的 AI 服务,为什么还要养一支负责基础工作的团队?既然市场上已经很少有人手写这些东西,学校为什么还要花大量时间教? 对个人、公司和学校来说,这些选择都有现实依据。但叠加起来,整个社会保留的独立能力就可能越来越少。等到某项能力突然受到限制,我们才发现,备用方案早已在追求效率的过程中被一点点削掉了。 所以,「AI 越强,做事越便宜」可能只描述了未来的一半。 另一半是:被允许的事情越来越便宜,被拒绝的事情依然需要人工完成,却要面对更少的人才、更高的报价,以及越来越难获得的知识。两边的成本差距,会越拉越大。 有人会说,可以换一个模型,或者用本地模型。这确实是重要的选项。只要工具之间还有充分竞争,开放模型还足够可用,限制就未必能形成真正的门槛。 但备用方案也需要维护。它需要硬件、知识、软件生态,以及一群仍然理解这些系统的人。如果大多数人已经习惯了最方便的商业服务,那么「理论上还有别的办法」和「普通人实际用得起、用得明白」,之间仍然可能隔着很远。 我担心的,正是这段距离。 我不指望 AI 对任何请求都照单全收。对明显会伤害他人的行为设置限制,有充分的理由。但我们也需要关心:限制由谁定义,误判有没有申诉渠道,用户能不能换工具,以及脱离这个工具之后,还剩下多少独立行动的能力。 保留这些能力,平时看起来甚至有点低效,明明可以自动生成,还要理解原理;明明可以一键完成,还要知道手动怎么做。 但这些看似多余的知识,会在工具拒绝、失效、涨价或改变规则的那一刻,成为真正的选择权。 AI 越强,我们可能越需要留意它说「不」的那一刻。 因为那句话的分量,最终取决于:它拒绝之后,我们还能做什么。
310
9
day3-如何写出一个高质量的 Skill(组内分享) 高质量 Skill 不是“一个调得很顺的巨型 Prompt”,而是一个可验证、可回归、可维护的能力包。 先定义“什么算好”,再实现“怎么做好”。评估体系先于 Skill 本身成型。 下面用“故障诊断 Markdown 转 YAML”作为例子,但方法是通用的。 --- 一、先想清楚:Skill 到底是什么 一个 Skill 至少包含四部分: 部分 作用 接口 输入什么、输出什么、边界在哪 流程 分几步做,每步的产物是什么 规则 硬约束、经验规则、失败模式 降级策略 不确定时怎么办,而不是硬编一个看似合理的结果 高质量 Skill 的共同点:职责单一、接口清晰、规则可定位、输出可验证。 反例:把几十条经验全塞进一个主 Prompt,改一条规则要重调整个 Prompt,评估时也不知道是哪条规则退化。 --- 二、核心方法:先建评估,再写 Skill 不要先写转换器再补测试。正确顺序是: 1. 定义输出契约:什么算合法、什么算合格; 2. 建金标准集:一小批人工认可“可放行”的样本; 3. 先写评估 Skill:让它在金标准集上跑出基线; 4. 再迭代生成 Skill:每次修改跑同一套评估,无退化且目标维度提升才算正向。 这就是评估驱动开发:评估是 Skill 的单元测试,金标准集是回归锚点。 --- 三、评估 Skill:三层门禁,逐层递进 前一层不过,后一层不跑。每层留可追溯证据。 第 1 层:确定性硬门禁 用解析器、Schema、校验器完成,不消耗模型成本。 · 输出可解析; · 必填字段齐全,类型/枚举合法; · 引用目标存在,无悬空引用、无不可达节点; · 关键路径至少有一条能到达预期出口。 不通过直接打回。 第 2 层:语义断言 用脚本 + 结构遍历检查“逻辑对不对”,仍然保持确定性。 通用检查项: · 覆盖率:源材料里的关键步骤、分支、条件,输出里是否都有对应? · 完整性:每个判断节点是否都有明确出口?有没有死胡同? · 可达性:每条路径是否都能到达预期终点?有没有无出口循环? · 顺序与依赖:有先后依赖的操作,是否保留了顺序?有没有被拍平成无序列表? 例子:故障诊断转换中,检查“每个判断项是否有是/否/异常出口”“每条路径是否能到根因”。 第 3 层:LLM-as-Judge 只处理解析器表达不了的维度:忠实度、完整性、可执行性。 但 Judge 会漂移,不能单独放行,必须建立在第 1、2 层之上。Judge 的 Prompt、rubric、模型版本都要版本化,换模型必须用金标准集重新校准。 通用 Judge 维度: 维度 问什么 忠实度 输出是否忠实源材料意图?有没有自行发明内容? 完整性 关键步骤、条件、证据是否保留?隐式知识有没有被压成空话? 收敛性 输出是否仍指向原目标,而不是发散? 可执行性 下游不依赖源材料能否直接使用? --- 四、金标准集:回归测试的锚点 不需要一开始就标注几百份。用已认可的样本当种子,扩到 15~30 份,覆盖失败模式而非随机抽样: · 完整正例:典型流程; · 边界/异常分支:异常路径、循环、前置失败回退; · 已知易错模式:实际踩过的坑; · 留出集:不参与调优,只用于最终验收,防过拟合。 金标准不需要完美,只需要当前标准下认可可放行。 回归指标:关键路径用 pass^k(k 次全过),稳定性用 pass@k。 --- 五、工程约束:让批量产出可重放 · 幂等:同输入 + 同 Skill 版本 + 同规则 → 输出一致,否则无法判断变好是 Skill 改了还是随机波动; · 隔离不阻断:单份失败进隔离队列,记录失败层和原因,不阻塞其余; · 版本绑定:规则、rubric、金标准集进 Git;每份报告绑定“源版本 + 生成 Skill 版本 + 评估 Skill 版本 + Judge 模型版本”; · 抽样人工复核:Judge 临界样本 + 易错模式,人工抽检结果反过来校准 rubric。 --- 六、Skill 本身怎么写 · SKILL.md 控制篇幅,写清:输入约定、输出契约、分步流程、硬规则、降级策略; · 经验规则放 references/ 或 rules/,按失败模式分类,不要全塞进主 Prompt; · 不确定时标 needs_review: true,不要硬编看似合理的结果; · 迭代由评估报告驱动:报告告诉你哪层挂了、哪类失败模式,你改对应规则文件,而不是漫无目的调 Prompt。 --- 七、落地顺序(不要反过来) 1. 固化输出契约:Schema + 结构约束; 2. 建金标准集:从已认可的 + 最易出错的样本开始; 3. 先写评估 Skill:跑出基线报告; 4. 再迭代生成 Skill:每次修改对比逐项通过率,无退化且目标提升才算正向; 5. 批量运行 + 隔离回放:失败进队列,结束后人工抽检; 6. 评估 Skill 自身版本化:换 Judge 模型必须重新校准。 --- 八、给组员的三条硬要求 1. 不许凭感觉说“变好了”:每次修改必须附评估报告对比,逐项通过率说话。 2. 不许跳过确定性门禁直接看 Judge 分数:前两层挂了,Judge 分数没有意义。 3. 不许把规则堆进主 Prompt:规则按失败模式分文件,评估报告要能定位到具体文件。 --- 一句话收尾 生成 Skill 决定“能不能做”,评估 Skill 决定“敢不敢用”。 先让评估体系站稳,再让生成器迭代。这样交付的不是一堆“看起来还行”的产出,而是一套可证明、可回归、可交接的 Skill 质量体系。
300
10
WorkBuddy 本地 API 桥 + dsh 插件:把你的 WorkBuddy 额度,变成手边随手可用的模型
290
🔥热门工具
朱雀AI检测朱雀AI检测
朱雀AI检测助手朱雀AI检测助手
LovartLovart
老鱼简历老鱼简历
WritePass官网WritePass官网
面多多面多多
CursorCursor
星月写作星月写作
零感AI零感AI
墨得问题墨得问题