이미지: AI 생성 — METAL LAB
摘要
- Grok Bot以早期测试版形式开放两天后,X平台上已积累了大量实际使用记录。
- 一名游戏开发者两小时内制作了74张卡牌美术图并接入游戏,另一名用户则边走路边用语音完成了预约。
- 与此相反,也有用户反馈文件只留在了机器人的电脑里、根本拿不到,马斯克则表示会先修复一些基础性问题。
两天内积累的使用记录
Grok Bot以早期测试版形式开放已经过去两天。官方介绍很简短:该机器人是代替用户完成实际工作的AI同事,会直接登录用户使用的工具,带着完成的成果回来。
话说得很漂亮,但光看介绍文字很难有具体感觉。幸运的是,X平台上已经开始积累实际使用记录。这里整理的都是排除宣传性内容、真正上手体验过的用户留下的反馈。
先说说结构。每个机器人各自拥有一台云端电脑。只要让它观察一次用户的工作过程,它就会把这个流程保存为routine(常规任务),并在设定的时间自动重复执行。多个机器人可以同时运行,在群聊中互相发消息、传递任务。
这一切的起点并不宏大。Cursor工程师Loren提到了公司内部的Slack机器人"Benny"的故事。"我算是挺懒的一个人,但Cursor收到的bug报告太多了。我想把这些全部修复掉。"最初的想法只是琢磨怎么让agent在自己睡觉的时候自动修bug,而随之而来的"你怎么做出来的、我也能做吗"之类的提问,最终催生了Grok Bot。
一名游戏开发者的两小时,74张美术图
最具体的记录来自游戏开发者Danny Lima Santa。这是他通过提前获得的访问权限使用一周左右后得出的结果。
他最先让机器人做的事,是把游戏里的图像占位符全部替换成真正的美术图。机器人在进入他的美术生成工具网页之前,先读取了代码库。它先弄清楚每个素材分别是什么,然后为每个素材单独撰写提示词生成图片,再进行裁剪、去除背景处理成透明PNG,重新接入游戏中。
两小时内完成了74张卡牌美术图。此前这些都是一张一张手工完成的。他写道,此后所有跟美术相关的工作都交给了这个机器人。
其他用例也是类似风格。他让机器人实现了每次向GitHub提交build时自动上传到itch.io;把PRD文档丢给它后,它接入Figma MCP,连UX流程和线框图都画出来了。它还翻查邮箱找出了被遗忘的付费订阅,并代为取消了新闻邮件订阅。不过他也补充说,有几项还是被漏掉了。
也有进展缓慢的情况。游戏playtest一开始比较迟钝,后来让机器人单独制作一个了解游戏规则的专用skill后,速度才提升上来。
"以为会崩,结果就那么跑起来了"
比其他人提前两周测试的Matt Shumer的反馈角度有所不同。他分别创建了一个researcher机器人和一个writer机器人,然后让"Chief of Staff"机器人把这两个连接起来,负责一个项目。
他本以为一定会出问题,结果去查看的时候发现它就那样正常运转着。他的总结是:"这不是只针对代码的agent,而是能挂接到任何工作上的agent。"他认为其优点在于:界面看起来就像聊天软件的对话框,每个机器人各有分工,而且用得越多越能学会用户的做事方式。
他也明确留下了一点不满,那就是模型路由器。用户无法自行选择使用哪个模型,后台会自动分配。
如果分配得好,对普通用户来说这是最佳设计;但如果分配不好,对高级用户来说就会很憋屈。他补充说,听说自从他测试之后这方面已经有了不少改善。
在停车场里用语音完成的预约
传播最广的一条反馈来自Yuanta Chai。浏览量超过350万,经埃隆·马斯克转发后进一步扩散。
在从停车场走到车边的这段时间里,他用中英文夹杂的方式跟机器人对话。机器人翻查日历,找出需要提前预约的事项,判断出最佳预约时间,然后进入网站完成了预约。他留下的话很简短:"我很惊叹。"
也有完全不同风格的用法。AI YouTuber Wes Roth正在让机器人代管一场宝可梦游戏直播。他在Chief of Staff机器人之下设置了coach、host、player、avatar、safety等多个机器人进行指挥,并将初始宝可梦定为妙蛙种子。不过由于尚未进行首次dry run,目前还无法确认直播是否已经真正开始运行。
另一面的反馈
并非全是赞美之词。一位使用中文的用户为了拿到一个文件费尽周折。三个agent各自只把自己电脑里的文件路径发了过来,而这些路径在他自己的电脑上一个都打不开。据他所说,不管重复说多少次都是同样的结果。
每个机器人各自拥有独立电脑的设计,在这里直接变成了摩擦点。这就好比同事回答说"那个文件在我桌子第二个抽屉里"——如果抽屉各自锁着,即便对方把位置说得再精确,自己也打不开。
马斯克也承认了这一点。他写道,会先修复早期测试版中存在的一些基础性问题,推出Grok 4.6之后再扩大测试版范围。目前Grok Bot仍处于早期测试阶段,已包含在Grok Heavy和Cursor Ultra订阅中。
编辑视角
把这两天的反馈摆在一起看,可以发现成功案例有一个共同点——它们的成果都是以文件形式留存下来的。74张美术图、上传完成的build、整理好的订阅列表、确定的预约。这些结果是否完成,人一秒钟就能确认。
相反,出现摩擦的案例,往往是成果只留在了机器人自己的电脑里。给每个agent配一台独立电脑的设计,好处是不会占用用户自己的电脑,但坏处是成果不会直接送到用户手上。轮流使用多种agent工具的话,总会在同一个环节卡住——这不是能力问题,而是交接问题。
因此,如果现在有团队想要试用这个工具,顺序最好是这样安排:第一周只让它做那些结果会以文件或链接形式产出的工作,比如生成报告、转换素材、整理清单、自动上传等。至于那些需要登录账户发送内容的工作——比如发邮件、付款、确认预约——则应该加入一道人工确认环节。
Shumer指出的模型路由器问题,也可以从同一个角度理解。无法选择模型,意味着当结果不理想时,没有一个明确的切入点去追查原因。对普通用户而言这是减轻了负担,但对想把它用于实际业务的团队来说,这恰恰是排查问题时会卡住的地方。
最后,Benny的故事也留下了一点启示。这款产品的起点并不是宏大的愿景,而是一个非常具体的困扰——bug报告太多,想在睡觉的时候把它们处理掉。国内团队在引入agent时,顺序其实也应该一样:不是先决定要让机器人做什么,而是先找出那件每周都要重复、却没人愿意做的具体工作。
