AREX Feed Article
基准分输给 Claude Code，实测跑赢一杯咖啡：xAI /goal 重新定义编程代理的胜负手
编程代理赛道的一个悖论：基准测试跑不过，实际体验打不赢？
2026 年 4 月，Elon Musk 公开承认 Grok Build 的编码能力落后于 Anthropic 的 Claude Code，并给出了一个时间表："要到 5 月才能接近 Opus 4.6，6 月才能追上甚至超过。"当时业界普遍将其视为追赶者的常规表态——毕竟，在 SWE-Bench Verified 这一衡量编程代理能力的关键基准上，Grok Build 底层模型的 70.8% 与 Claude Code（Opus 4.7）的 87.6% 之间，隔着将近 17 个百分点的差距。
6 月 22 日，xAI 发布 Grok Build 的 /goal 模式，主推"自主执行到完成"——与标准编程工具有一个关键不同：它不仅写代码，还自带验证，确认产出真的能跑才标记完成。三天后，特斯拉 AI 高级主任工程师 Yun-Ta Tsai 在 X 上发了一条推文，配图是一张终端截图，显示 [Goal: Done]。配文只有一句话："Need to find a harder problem for /goal. I haven't even finished my coffee yet.（得给 /goal 找个更难的问题。我咖啡都还没喝完。）"
这条推文获得了 Elon Musk 的转推，三天内累积 77 万次浏览、1773 次点赞、397 次转发。一个内部工程师随手发出的测试，意外成为 xAI 新功能最有力的公众背书。它不在任何基准测试的数据里，但它可能比任何基准分数都更能说明：编程代理的评估标准本身，正在被重新定义。
一个"Goal: Done"截图，77 万人围观
Yun-Ta Tsai 的推文发布于美国太平洋时间 6 月 24 日晚间（UTC 6 月 25 日凌晨 4 点）。截图画面极小（181×40 像素），只展示了终端中的一行结果，但信息量极大：/goal 在无人介入的情况下，自主完成了用户设定的全部任务，并且在完成时自动标记了 Done。
Elon Musk 的转推没有附加任何评论。这个沉默本身就有分量——Musk 选择了一条工程师日常测试而非官方营销文案来放大，说明 /goal 的实际表现已经达到了让他愿意为之背书的程度。
社区反应迅速分化出几条支线。一部分开发者直接上手测试，反馈从"惊人"到"翻车"都有——有人报告 /goal 跑了 33 小时才完成任务，有人抱怨"跑了一小时 10 分钟只产出了两页文档"，更多人的体验则介于两者之间。一个名为 Sparky and Sparks 的用户给 /goal 布置了一道堪称荒谬的题目：设计一块 5mm×5mm 芯片上的 2500 逻辑量子比特量子光子处理器，并祝愿 Grok 好运。另一个用户则用 /goal 分析了自己的 CRM 系统，提取全部内容、分析触发器效果和工作流，最终产出了一套完整的改进建议。
但真正让这条推文具有传播力的，不是 /goal 到底有多强，而是"咖啡还没凉"这个画面感极强的比喻。它把一个抽象的技术能力锚定在了每个人都能理解的日常体验里——AI 的速度已经快到人类的生理节奏跟不上了。
写完代码只是开始，自验证才是 /goal 真正的护城河
/goal 不是 Grok Build 的替代品，而是 Grok Build 内部的一个模式。要理解 /goal 的独特之处，需要先理解标准 AI 编程代理的工作方式：开发者提示 → 代理执行 → 开发者审查 → 下一步。这个循环的问题在于，每一步都需要人类在回路中——代理告诉你"改好了"，但改完之后到底能不能跑，是你自己的事。
/goal 把这个循环中的"开发者审查"环节移除了。用户只需输入一行目标，比如 /goal Migrate the auth module to the new API，代理就会自动拆解任务、建立进度清单、逐项执行，直到完成任务并通过验证，才翻牌标记 Complete。
验证是 /goal 区别于其他编程代理最关键的架构决策。根据 xAI 的官方说明，/goal 支持三种验证方式：审查自己生成的代码、检查网页确认运行时行为、运行测试脚本直接验证结果。这个验证步骤被内置在代理的执行循环中——不是在开发者检查之后，而是在代理标记"完成"之前。这直接针对了第一代编程代理的一个经典失效模式：代理编辑了文件，报告成功，但改动根本不能正常工作。
支撑这套逻辑的是一套双模型管线。Composer 2.5 负责规划和复杂指令跟随，Grok Build 0.1 负责代码生成和执行。Composer 2.5 是 xAI 于 6 月 1 日加入 Grok Build CLI 的模型，专门针对长时间任务和复杂指令序列设计；Grok Build 0.1 则是从头训练的编程代理专用模型，运行速度超过 100 tokens/秒，拥有 256,000 token 的上下文窗口。TechTimes 在评测中提出了一个尚未得到回答的关键问题：规划模型和生成模型之间的独立性是否足够？如果验证器与生成器训练方式相似，它们可能共享相同的盲区，导致"浅层自我认同"而非真正的质量评估。
在用户侧，/goal 提供了一套完整的运行时控制命令：/goal status 查看实时进度面板，/goal pause 暂停但保留目标，/goal resume 继续执行，/goal clear 完全丢弃目标。这套命令体系的设计哲学很明确：让开发者可以"放手但不失控"。
一个往往被低估的差异化特征：Grok Build 中所有代码都在用户本地机器上运行，代码库内容不会传输到 xAI 的服务器。对于金融、医疗、政府等受监管行业的工程团队来说，这个本地优先的架构是一个云基编程工具无法匹配的硬性安全优势。
在定价策略上，xAI 也打出了一张低价牌。Grok Build 的最低接入门槛是 SuperGrok 每月 30 美元，在主流终端编程代理中是最低的——对比之下，Claude Code 和 Codex CLI 的订阅价格更高。Yun-Ta Tsai 在 /goal 推文引发热议之后，发了一条意味深长的后续推文："Intelligence per dollar is the actual metric to drive adoption（每美元可获得的智能，才是驱动采用率的真实指标）。"这条推文获得了 255 次点赞。他的潜台词很清晰：在编程代理的竞争中，性价比可能会后来居上。
xAI 的路线图中还有一个尚未上线的关键功能：Arena Mode。这个功能早在今年 2 月就被代码追踪曝光，并在后来的公开公告中被确认——它可以让多个代理并行处理同一个问题，然后自动选择最佳输出。如果 Arena Mode 最终按计划上线，Grok Build 底层模型在单次基准测试上的弱势将在实践中被大幅稀释——毕竟，从多次独立尝试中择优，比押注单次结果要宽容得多。
一个拒绝 Meta 挖角的工程师，和他对 Elon Musk 的忠诚
Yun-Ta Tsai 并非 AI 圈的陌生人。他在 X 上拥有 11.2 万粉丝，个人简介只有一行："Sr. Staff Engineer @Tesla_AI"。
他的履历横跨学术与工业界。南加州大学计算机科学硕士，Google Scholar 引用超过 1900 次，h-index 为 14。在加入特斯拉之前，他曾任职于 Google Research（2016-2019），参与 Pixel 手机相机的人像补光（Portrait Relighting）和自动白平衡算法开发——其代表作"Single Image Portrait Relighting"（2019 年）被引 327 次，"Fast Fourier Color Constancy"（2017 年）被引 269 次。更早之前，他在 NVIDIA 担任研究科学家（2013-2016），主导 FlexISP 灵活相机图像处理框架（被引 415 次），还在诺基亚研究中心做过移动 AR 研究。
2020 年加入特斯拉后，Tsai 的工作重心转向 Autopilot 的实时成像算法和硬件感知机器学习。他的技术路径有一个清晰的主线：把前沿研究变成能在资源受限环境中高速运转的生产级系统——这种"研究到产线"的跨度，恰好也是 /goal 这类编程代理最有价值的应用场景。
2025 年 6 月，Meta 试图挖角 Tsai，他公开回复称没有任何金钱能让他离开 Elon Musk 和特斯拉的使命。这条新闻当时登上了多家媒体的头条。一年后，当他在 X 上发布 /goal 的实测截图时，Musk 的转推看起来像是一个迟来的回应——相互的信任和忠诚，沉淀在了一个具体的产品验证行动中。
Tsai 的推文风格以简洁有力著称。在 /goal 推文之前，他刚发了一条关于"被喜欢"的哲学思考："Getting used to being liked likely means you are overfit to RLHF."（习惯被喜欢，意味着你可能已经过拟合到了 RLHF。）这条推文获得了 1974 次点赞和 487 次转发。从 RLHF 到 /goal，他的公共表达始终围绕着同一个核心关切：AI 系统的能力边界在哪里，以及我们如何诚实地测量它。
Claude Code、Codex CLI、Grok Build：编程代理的三国杀
把 /goal 放回 2026 年编程代理的竞争版图，三方格局已经相当清晰。
Anthropic 的 Claude Code 仍然是深度推理的标杆。Claude Opus 4.7 在 SWE-Bench Verified 上跑出了 87.6% 的成绩，拥有 100 万 token 的上下文窗口。它的工作模式是"对话驱动"——开发者与代理反复交互，代理在深度推理中逐步完成任务。优势是准确率高；代价是人力介入频繁。
OpenAI 的 Codex CLI 在基准测试上同样强势。GPT-5.5 驱动下，Codex CLI 在 SWE-Bench Verified 上的 vendor 自报分数为 88.7%，是目前终端编程代理中的最高分。Codex CLI 支持审批模式（approval mode），每一步需要人类批准，适合风险敏感的环境。
xAI 的 Grok Build 走了一条不同的路。它的底层模型分数（70.8%）与领先者有显著差距，但 /goal 的差异化不在于"一次就写对"，而在于"写到对为止"——自验证管线意味着代理可以在无人干预的情况下反复修正，直到产出真正可用的结果。加上 8 个子代理并行（Parallel Agents）和即将上线的 Arena Mode，Grok Build 押注的是"并行+自纠错"的架构优势，而非单模型推理深度。
Google 的 Gemini Code Assist Enterprise 是第四个值得关注的玩家，主攻企业级工程团队，但目前尚未公布与上述三款工具直接可比的基准测试数据。
业界分析师 Mitch Ashley（The Futurum Group 副总裁）在 TechTimes 的报道中总结了当前的竞争态势："编程代理正在成为 AI 实验室争夺开发者工作流的采购前沿。多代理并行与内置评估，配合本地优先执行，反映出各家厂商正在编排架构和执行环境保障上寻求差异化。"
2026 年的编程代理赛道正在经历一场概念迁移：从 Copilot 到 Agent，从"帮你写"到"替你跑"，从"每一步都要确认"到"设定目标，放手等结果"。在这个过程中，用哪个基准来评估好坏，本身就成了竞争的一部分。xAI 的 /goal 试图回答的问题不是"我们能不能考得比 Claude 高"，而是"考试的科目本身是不是该换了"。
当咖啡的冷却速度追不上 AI 的执行速度
Yun-Ta Tsai 的这条推文，本质上是一个黑箱测试的结果展示——它没有公布任务细节、没有给出参考基准、甚至没有说明截图是不是一次刻意挑选的最佳结果。但这恰恰也是它最有力的地方：在一个工程师的日常节奏中，/goal 表现得足够快、足够可靠、足够让人产生"我得给它找点更难的活儿"的冲动。
当我们把"基准测试落后 17 个百分点"和"咖啡还没凉任务已完成"放在一起时，两者之间的张力本身就说明了一个更深层的判断：编程代理的价值，最终不取决于任何单一评估维度的分数，而取决于它能否真正改变开发者的工作节奏。当 AI 的执行速度开始用咖啡的冷却时间来衡量时，那个旧的评分体系可能已经过时了。
参考链接：
- xAI 官方公告：Introducing /goal —
- Yun-Ta Tsai 原推文 —
- TechTimes 深度评测：Grok Build Ships Autonomous Execution —
- MarkTechPost：xAI Launches /goal in Grok Build —
- Grok Build vs Claude Code vs Codex CLI: 2026 Benchmarks —
- Hindustan Times：Tesla engineer rejects Meta —
本文由机器之心基于公开信息独立撰写，未经相关公司审阅。转载请联系机器之心编辑部。