Grok 新出 /goal：一句话甩给它自己跑到完成，我天天跑长任务太懂这有多难
哈喽，我是飞飞。
这两天我刷推，老看到一个词在转：Grok 的 /goal。xAI 在自家终端工具 Grok Build 里加了这么个模式，官方的说法是，你敲一行命令把目标甩给它，它自己规划方案、把活拆成一张进度清单、一项一项往下跑，跑到目标完成、还自己验证过了为止。完事那一刻，清单上每一项都打上勾。
一句话设目标，agent 自主跑到完成。听着就让人手痒。
我先把话放这：这功能我没真上手过。Grok Build 现在锁在 SuperGrok Heavy 那档订阅里，一个月三百美金，我没充。说实话，下面这些都不是我试 Grok 试出来的。我天天用 Claude Code 跑长链路自主任务，攒了一肚子体感，拿来对照着看这类功能而已。哪些是官方说的、哪些是我亲身踩过的，我会分清楚。
「自己跑到完成」这件事，我太想要了
这股向往我懂。每个用 AI 干活的人脑子里都有那个画面：把一件烦活扔给它，自己去喝杯咖啡，回来它已经收尾了。
我自己的流水线就是这么搭的。光写文章这一条链路，我挂着十几个 skill，拉资讯的、查重的、配图的、发公众号的，全长在 Claude Code 上，外加一份越喂越厚的配置文件和一摞记忆。有时候我让它跑一个大任务，自己起身去厨房热个饭，回来它正盯着最后一个测试。那种感觉确实爽。
但每个月给 Anthropic 的钱不算少。让它干一件正经活之前，我都会下意识在心里过一遍秤，掂量这活值不值得动用最贵的那个模型。我越是绷着这根弦，越说明我有多希望它能少出岔子、一次跑对。
所以 /goal 主打的那条线，我打心眼里是欢迎的。能少盯一点是一点。
但越是天天干这个，我越知道这事的甜和苦是分开的。规划一张漂亮清单，不难。难的在后面那一长串「执行」里头。
跑两百步不翻车，比画清单难太多
官方把 /goal 拆成几块说：规划、拆清单、逐项执行、自己验证。验证还给了三种花样，自己 review 代码、去看网页确认行为、跑脚本测结果。一整套听下来很完整。
我的体感是，前面那几步都好说。真正决定这玩意儿能不能用的，是中间那段没人盯着的长跑里，它跑偏了能不能自己爬回来。
给你讲个我真撞过的。前阵子我用 Claude Code 把一个 SpringBoot 老项目迁成 Kotlin，一个工作日七千行换血。中途有个叫 isLiability 的字段，在某个分支里凭空就没了。这种东西最阴险，编译能过、跑也能跑，你盯着满屏 diff 根本看不出来少了它。
我能把它捞回来，靠的不是模型一遍就写对。我在流水线里架了一道对抗校验的关卡，专门挑刺、专门怀疑前一步的产出。就是它报出那行错的时候，我对着屏幕愣了两秒，才反应过来是哪儿漏了。那个字段藏在一个不起眼的转换函数里，迁移的时候被并到另一个 data class 上，名字都没了，编译器一声不吭。
你看，这一长串活里，最值钱的不是「规划得多周全」，是「错了之后那道兜底」。两百步的任务，前一百九十步都对，第一百九十一步偷偷写坏一个字段，后面照样全勾完、面板照样翻成绿色的 Complete。这种「假装跑完了」才是长程自主最要命的坑。
我亲眼看过一次「自己抓自己 bug」长啥样
光说会跑偏，不公平。说真的，自主任务里也有让我服气的时候。那种自救的闭环真出现的时候，是真顶。
我前不久真装真跑过国产的 MiMo Code。装的时候它一键把我四十多个 Claude Code 配置导了进去，跑全程大概五六分钟，全自主。我让它写一个零依赖的 Node 小工具，解析 Markdown 文件头、输出 JSON，还得自带测试。第一轮五个用例挂了俩。挂在哪呢？它的标量正则抢先匹配了一个空值，把本该是数组的字段赋成了 null，正好是我点名要它处理的那种形态。
骚的是后面这一下。它自己写的那套测试，把它自己的 bug 抓出来了。它读着 TAP 报错自己诊断，原话说的是「标量正则在列表项处理之前就把这个字段设成 null 了」，跟我手扒代码看到的一字不差。然后它一次 Edit 把正则收紧，重跑，五过零败。我不信，自己又拿真实样例独立复核了一遍，也全过。
这条「写测试 → 测试抓出自己的 bug → 读报错自诊断 → 改 → 再验」的链路真能收敛、诊断准、改得干净，比任何一张跑分表都更能说明一个 agent 的成色。这才是「自己跑到完成」里最硬的那块肉。
顺带说一句，MiMo Code 自己也有个叫 Goal 的东西，放了个独立裁判防止它乐观地提前停手，跟 Claude Code 的 /goal 是一个路数。这类长程设计，大家其实在抄同一份答案。
连「验证」这一关，自己也会翻车
/goal 最让我想多看几眼的，是「自己验证」这一段。因为我太知道，验证关卡本身也是会崩的。
这里插一条旁证，得先把边界说清楚。这条不算 /goal 的实测，是有人评测 Grok Build 通用的「写完自己验证」回路时撞上的。
一个含糊的小任务，agent 渲了一张 16 像素的图，然后想用 xAI 自家的视觉接口去验它对不对。结果那个接口嫌这图才两百多个像素、低于五百一十二的下限，直接拒了。活干完了，它回头检查自己的成果，检查这一步反倒把自己干崩了，卡死了十三分钟。后来换了个版本，验证改走 XML 语法检查这种轻办法，一分多钟就过了，不崩了。
我拿这条出来不是要黑 Grok。我想说的是一个普遍的事：验证不是免费的保险。说白了，那道验证关卡本身也是一段会出错的代码。一个号称「跑到验证通过为止」的 agent，万一验证那关自己挂了，它到底是判成功还是判失败、要不要重来，这才是真正考验设计的地方。/goal 在这块怎么处理，得有人真用半年才说得清。
别看 demo 那张清单多顺
绕回来。/goal 这类功能我会一直盯着，但我判断它值不值，标准只有一个：把它扔进一个会跑偏的真实开放任务里，它撑不撑得住。
demo 里那张进度清单一项项打勾，看着特别治愈。可那是被精心挑过的活，路是顺的。
真实项目里不一样。某个字段会在你看不见的地方消失，验证接口会因为一个边界条件自己崩掉，它前面跑得越顺，后面那个隐藏的坑越难被发现。
我现在的态度，不是「Grok 这功能一定行」，也不是「不就是个 PPT 嘛」。这两句都太轻飘了。我更想看的是，等独立实测多起来之后，它在真会出错的活里，那道自救闭环到底有多稳。能像我看 MiMo Code 那次一样，自己抓自己的 bug 再爬回来，那它就是真东西。
所以我留个问题给你：你愿意把一个跑两百步的任务，一句话甩给 agent，然后真的起身走开吗？还是说，你跟我一样，嘴上说着自主，手其实一直没离开过键盘？评论区聊聊你最不敢撒手的是哪类活。