用了grok build之后才发现之前都受的什么罪

清清 2026-07-17 06:44 1

之前拿着fable/opus或者gpt总是不情愿尝试其他的,还一定要xhigh,想着这两个才是SOTA模型,而做科研是有必要用这个的。

经常一个小问题等好几分钟,一个task能浪费一天,忍着恶心听它们说稀奇古怪的话,然后还要看两家吹自己模型如何如何领先,max/pro的号用两下子就又到上限了,天天紧巴巴地过日子。

前几天看站里风评,终于下决心跨过“顶尖模型”的心理障碍,甚至是自费不是报销开了supergrok——我终于可以用一个正常的速度工作了,效率显著增加,模型也听得懂话了。甚至还省去我单独再开一个grok api用来搜索的麻烦。

现在想起来,所谓的“顶尖模型”也无非就是70%的内容需要我纠正修改,就算grok稍微差一点,大概也就是75%。科研工作不像码代码,现在这些模型的水平,指望它one-shot自主做出的内容是永远用不了的,与其忍着龟速为了一点边际能力提升,不如要一个快速模型。

事实上体感也并没有觉得比claude/gpt差,反而因为速度快可能还更好。哪怕真有什么复杂的任务非要fable这样的模型验证一下,那就叫它验证一次就好了,甚至换成chat都行,如果文件少的话。

而且,我相信grok能力比肩另两家也指日可待,再维持这个速度,就会很适配工作。

最新回复 (6)
  • 浩然 孟 07-17 06:47
    1

    这个build不只是一个工具吗?区别有着这么大吗?

  • 清清 楼主 07-17 06:51
    2

    意思是grok底模加+grok build,语境对比claude+cc和gpt+codex。

    当然grok build本身也挺不错的,很多设置比较人性化,比claude code bug少一些,只是没那么成熟,比codex先进。

  • OiCkilL 07-17 06:53
    3

    我也有这种感受,一些不是十分复杂的活,grok build完成得十分出色。


    我让codex和grok帮我在远程服务器部署个项目,codex做了一小时都没搞定,grok几分钟就帮我搞定,我都不知道codex磨叽这么久干嘛。

  • wugeng 07-17 06:54
    4

    把grok接到codex里也很好用,就是上下文受codex限制短了点

  • event 07-17 07:00
    5

    ild,语境对比claude+cc和gpt+codex。

    当然grok build本身也挺不错的,很多设置比较人性化,比claude code bug少一些,只是没那么成熟,比codex先进。



    确实,反复实测,Grok接入Claudedesktop后,体验远远比不上GrokBuild,

  • 南箕子 07-17 07:13
    6

    每次70%的内容需要纠正修改,我感觉这工作流程不太适配这两个模型的 xhigh. 不知道佬的具体工作是拿 AI 做什么,感觉需要的可能更多是 agent 能力

* 帖子来源Linux.do
返回