Grok Build vs Claude Code：记忆能力实战对比测评

9 月 16 日，xAI 在 Grok Build（其终端编码 Agent）中发布了记忆功能。宣传语是 Grok"会记录在对话中出现的约定、决策和项目事实"，"后续会话在处理相关代码前会先读取这些笔记"。笔记是 Markdown 文件，作用域分为工作区级别（每个项目一份）和全局级别（所有地方通用）。/memory 命令用来浏览这些笔记。

与此同时，Claude Code 几个月前也做了类似的事情，名为 auto memory（自动记忆）。它在每个仓库维护一份 MEMORY.md 索引和一条笔记一个文件，文档说这个功能默认开启。Anthropic 于 9 月 17 日宣布的 Projects beta 增加了跨云端线程的共享记忆，但仅限部分 Pro 和 Max 订阅用户，且需要已有项目。我测试的是人人可用的 CLI。

两家公司都说自己的编码 Agent 能记住你在之前会话中告诉它的内容。我想验证这一点是否属实，于是用相同的三个测试分别测试了 Grok 和 Claude。

我要验证的论点很简单：把某件事告诉工具一次，关闭它，再次打开，看它是否记得。两款工具都在我的 Mac 上运行，各自处理我为这次测试准备的四个小型 Node 仓库的副本。Grok Build 1.0.40 通过 xAI API 密钥运行 Grok 4.6（高强度模式）。Claude Code 2.1.226 运行 Opus 5，用的是我的订阅账号。每个会话都通过工具的无头模式脚本化运行，它会自行报告 token 用量和费用。

每个测试包含两个会话。会话 1 植入一个事实。然后退出工具。会话 2 给出一个任务，该事实会影响任务执行，但不会主动提及它。

以下是我运行的测试：

测试命令——在这个仓库里，npm test 会失败，make test 能通过，会话 1 会告知这一点。会话 2 要求创建一个能通过测试的新接口，期间我会删除 README 中指向 Makefile 的那行文字。

项目决策中的陷阱——会话 1 声明 CSV 导出功能已弃用，且金额以整数美分为单位，绝不用浮点数，而代码库里还留着一个浮点数辅助函数和一个做到一半的 CSV 导出器作为诱饵。会话 2 要求创建一个退款接口，需要"接收一个金额"和"让客服人员能下载所有订单的方式"。

跨项目规则——会话 1 在仓库 A 中设定两条"适用于我所有项目"的规则：使用 conventional commit 消息，以及不在显而易见的代码上加注释。会话 2 在一个无关的仓库 B 中运行，要求实现一个小功能并提交。

以下是我的评分标准：工具是否把事实写入了记忆文件、是否在会话 2 中读取了该文件、会话 2 的输出是否遵循了该事实。

测试命令

两者都通过了。会话 1 中，两款工具都在我陈述规则后立即将其保存。Grok 写入了 topics/testing.md 加上两条原始观察记录。Claude Code 写入了 orbit-api-run-tests-with-make.md，包含"为什么"和"如何应用"两部分。

会话 2 中，两者都记住了。Grok 的推理过程以"首先读取记忆文件"开头，然后运行了 make test，没有碰过 npm test。Claude Code 读取了 Makefile 和 package.json，运行了 make test，同样没有尝试 npm test。Grok 耗时 29 秒，消耗 102K token，花费 $0.11。Claude Code 耗时 22 秒，消耗 186K token，花费 $0.32。Claude 多用了约 80K token，成本近 3 倍。

项目决策中的陷阱

两者都记录了两条决策。Claude Code 还在笔记中把"last quarter"转换成了"Q2 2026"。会话 2 中，两者都基于整数美分构建了退款接口，字段名设为 amountCents，没有动那个浮点数辅助函数。在下载请求方面，两者都提供了 JSON 导出。

Grok 的推理说明 API 仅支持 JSON，所以没有接入 CSV。Claude Code 设置了 content-disposition 头，让 JSON 作为文件下载。两者在两条决策上都通过了，但 Claude Code 的价格是前者的两倍多，速度却一样快。Grok 耗时 103 秒，消耗 156K token，花费 $0.18。Claude Code 耗时 32 秒，消耗 269K token，花费 $0.49。

跨项目规则

这是结果出现分歧的地方。Grok 把规则保存到了全局作用域，文件名为 git-and-code-style.md。在第二个仓库中，它提交了 feat: add --help flag with usage and supported cities，且没有加注释。通过，耗时 33 秒，消耗 132K token，花费 $0.12。

Claude Code 也保存了这两条规则，但仅保存在第一个仓库的记忆文件夹中。它当时就说明了这一点，警告其记忆存储"作用域限定在该项目目录内"。在第二个仓库中，它找不到任何东西，提交内容变成了 Add --help flag，同样没有加注释，但这本来就是 Claude 的默认行为。Claude 通过了第一条规则但未通过第二条，且成本是两倍。它在 12 秒内完成，消耗 122K token，花费 $0.24。

指标	Grok Build（Grok 4.6）	Claude Code（Opus 5）
通过的测试	3/3	2/3
总耗时	165 秒	66 秒
总 token 消耗	390,848	576,863
总费用	$0.41	$1.05

Grok Build 通过了全部三个测试，Claude Code 通过了两个。在每个项目的测试中，两者的表现相同。分歧出现在跨项目规则测试中——Grok 的全局作用域把规则带到了第二个仓库，而 Claude Code 按仓库隔离的记忆没有做到。

Claude Code 在每次记忆召回会话中都更快，总计 66 秒对比 165 秒，但在每次测试中费用都至少是两倍，总计 $1.05 对比 $0.41。它也消耗了更多 token：576,863 对比 390,848。价格差异主要反映的是 Opus 5 与 Grok 4.6 的定价差异，而非记忆系统的差异。

关于核心论点——记住你在同一项目中上次告诉它的内容——我无法区分这两者。两者都在我陈述规则后立即写了一条 markdown 笔记，在下次会话中读取它，并遵循它。Claude Code 的笔记写得更好。但 Claude Code 在第三个测试中失败了。它的 CLI 记忆止步于仓库边界，所以我在"所有项目"中告诉它的规则从未到达第二个仓库。Grok 的全局作用域则无需提示就把同一条规则带了过去。

对于大多数人来说，Grok Build 是目前更好的选择。它记住了所有内容，能跨项目携带规则，且在每个测试中成本都不到一半。是的，Claude Code 在每个会话中都更快，但如果你不在意准确性，那才值得。它的 CLI 记忆止步于仓库边界，所以你想让它记住的任何全局规则仍然需要手动写入 ~/.claude/CLAUDE.md。