Grok Build 实测报告：Plan Mode 省了我哪些时间，又在哪里让我踩坑

Grok Build 公测第一天，我刷到了将近二十篇介绍文章。

每一篇都在讲「Plan Mode 革命性地改变了 AI 编程体验」，每一篇都配了官方演示截图，每一篇都在第三段告诉我「未来已」。

没有一篇告诉我，它在第六个文件之后会开始忘事。

我当时的反应是：好，那我自己跑一遍。

---

第一章：为什么要做这个测试，而不是又写一篇发布会解读

市面上不缺 Grok Build 的功能介绍，缺的是一个有 CRUD、有外部 API 调用、有部署步骤的完整小项目实测。

Hello World 太简单，大型工程太复杂，都不是暴露 AI 编程助手真实能力边界的好靶子。

我选的测试项目是一个「待办清单 + 天气 API 接入 + 简单用户登录」的 Node.js 小应用，大概的规模是：

• 后端：Express + SQLite，约 8 个文件
• 前端：原生 HTML/JS，3 个页面
• 外部依赖：OpenWeatherMap API
• 部署目标：本地跑通 + 一键 Docker 启动

这个规模有几个特点，让它成为一个好的测试场：

1. 有顺序依赖：必须先建数据库 schema，再写 API，再写前端调用，跳步就报错

2. 有外部状态：API Key 管理、环境变量、错误处理，都是真实项目里的日常麻烦

3. 文件数量够多：8-10 个文件足以触发上下文管理问题，但不会多到让测试失控

我用同一份 Prompt 分别喂给 Grok Build 和 Claude Code，记录每个环节的实际耗时和输出质量。

---

第二章：Plan Mode 真的省事的三个环节

环节①：需求拆解 → 任务列表生成

我给两个工具的初始 Prompt 是一样的：

帮我构建一个 Node.js 应用，功能包括：
1. 用户注册/登录（JWT 认证）
2. 待办事项 CRUD
3. 首页展示当地天气（接入 OpenWeatherMap API）
使用 Express + SQLite，前端用原生 HTML/JS

Phase 1: Project Setup (预计 5 分钟)
- 初始化 package.json
- 安装依赖：express, better-sqlite3, jsonwebtoken, bcrypt, node-fetch
- 创建 .env 模板

Phase 2: Database Layer (预计 10 分钟)
- 创建 db/schema.sql
- 初始化 users 表（id, username, password_hash, created_at）
- 初始化 todos 表（id, user_id, title, completed, created_at）

Phase 3: Auth Module (预计 15 分钟)
- POST /api/auth/register
- POST /api/auth/login
- JWT middleware

Phase 4: Todo API (预计 10 分钟)
- GET/POST/PUT/DELETE /api/todos

Phase 5: Weather Integration (预计 8 分钟)
- GET /api/weather?city=xxx
- 错误处理：API Key缺失 / 城市不存在

Phase 6: Frontend (预计 20 分钟)
- login.html / register.html / index.html
- fetch 调用封装

Phase 7: Docker & README (预计 10 分钟)

两种方式没有绝对的好坏，但有一个关键差异：Grok Build 的 Plan 逼出了我自己没想清楚的边界条件。

比如，我原来的 Prompt 里没有提「JWT 过期时间」「密码最小长度」「天气 API 的错误处理」。Plan Mode 输出之后，我一眼就看到了这些空白，在动手之前就补上了。

Claude Code 直接开写，这些细节要等到报错或者代码 review 时才会暴露。

💡 结论：需求模糊期，Plan Mode 是一个强制你「想清楚再动手」的工具。这个价值不在于 AI 有多聪明，而在于它给了你一个检查清单。

---

环节②：文件结构初始化

Plan Mode 执行完之后，Grok Build 生成的目录结构是这样的：

todo-weather-app/
├── .env.example
├── .gitignore
├── Dockerfile
├── docker-compose.yml
├── package.json
├── server.js
├── db/
│   ├── database.js
│   └── schema.sql
├── middleware/
│   └── auth.js
├── routes/
│   ├── auth.js
│   ├── todos.js
│   └── weather.js
├── public/
│   ├── index.html├── login.html
│   ├── register.html
│   └── js/
│       └── app.js
└── README.md

Claude Code 生成的结构：

todo-weather-app/
├── package.json
├── server.js
├── database.js
├── auth.js
├── todos.js
├── weather.js
├── public/
│   ├── index.html
│   ├── login.html
│   └── register.html

两个都能跑，但 Grok Build 的结构更接近「你会在 GitHub 上看到的规范项目」——路由分层、中间件独立、数据库层隔离。

Claude Code 的结构更扁平，适合快速原型，但如果你需要向同事解释项目结构，或者这个项目之后要交接，Grok Build 的版本省去了「重构目录」这一步。

---

环节③：跨文件依赖的声明顺序

这是 Plan Mode 最实际的价值所在。

在「先建数据库 schema，再写 API，再写前端调用」这种有顺序依赖的任务链里，Claude Code 有时会跳步——比如在 schema.sql 还没写完的情况下，todos.js 里已经在引用一个还不存在的 user_id 外键。

我在测试中遇到的一个真实报错：

Error: SQLITE_ERROR: table todos has no column named user_id
at Database.prepare (/app/node_modules/better-sqlite3/lib/methods/wrappers.js:5:21)
at Object. (/app/routes/todos.js:12:28)

原因是 Claude Code 在写 todos.js 的时候，schema.sql 里的 todos 表还只有 id 和 title 两列，user_id 是后来才加进去的，但 todos.js 已经假设它存在了。

Grok Build 的 Plan 里明确写了「Phase 2完成后才进入 Phase 3」，执行时严格按顺序来，这个报错没有出现。

---

第三章：还是得自己盯着的地方

坑①：上下文窗口到中期开始「失忆」

项目进行到第五、六个文件之后，我注意到 Grok Build 开始出现变量命名漂移。

早期约定的接口格式是这样的：

// routes/auth.js — 早期约定
res.json({
success: true,
data: { token, user: { id, username } }
})

但到了第七个文件 public/js/app.js，Grok Build 生成的前端代码变成了：

// public/js/app.js —漂移后
const { token, userId } = await res.json()
// 注意：这里假设返回的是 { token, userId }，而不是 { data: { token, user: { id } }

这个漂移不会立刻报错，但会在运行时产生 undefined，而且很难定位——你会先去查网络请求，再去查后端，最后才发现是前端解构的字段名对不上。

---

坑②：错误自愈能力弱于 Claude Code

遇到运行时报错时，两个工具的处理方式有明显差异。

我故意制造了一个错误：把 bcrypt.compare 的回调写成了同步调用。

Phase 5: Weather Integration
- GET /api/weather?city=xxx
- 错误处理：API Key 缺失 / 城市不存在
- 返回格式：{ temp, description, humidity, city }

// routes/weather.js — 实际输出
router.get('/', async (req, res) => {
const { q } = req.query  // 参数名从 city 变成了 q
// ...
res.json({
temperature: data.main.temp,  // 字段名从 temp 变成了 temperature
weather: data.weather[0].description,  // 字段名从 description 变成了 weather
// humidity 和 city 字段消失了
})
})

Plan 说city，代码写 q。Plan 说返回 temp，代码返回 temperature。Plan 里承诺的 humidity 和 city 字段直接消失。

这个反差感是真实存在的，而且不是偶发——在我的测试里出现了两次。

⚠️ 重要提示：Plan Mode 的价值在于帮你规划，不在于保证执行严格遵守规划。把 Plan 当成「合同」是错误的使用预期，把它当成「草图」才是正确的心态。

---

第四章：两个工具的适用场景速查表

• 你是独立开发者，追求速度，项目规模在 10 个文件以内 → 优先 Claude Code
• 你是团队 lead，需要对齐需求，或者项目需要交接 → 优先 Grok Build
• 你两个都想试，不想分别管理两套 API Key → 用同一个平台接入，省去切换成本

---

💡 如果你想自己跑一遍这个对比测试，两个工具都需要 API 接入。目前国内访问最稳定、支持 Grok 和 Claude 同一平台切换的入口是 [api.884819.xyz](https://api.884819.xyz)——我这次测试用的也是这个，省去了分别管理两套 Key 的麻烦。新用户注册即送体验 token，国产模型（Deepseek / 千问等）完全免费，没有月租，按量付费，注册用户名+密码就行，不需要邮箱验证。

---

第五章：结论与明天就能用的 3 步 SOP

理解这个定位，两个工具可以互补而不是互斥。

双工具协作 SOP（3 步，拿回去就能用）

把需求扔给 Grok Build，让 Plan Mode 跑一遍。不要急着执行，先审阅 Plan，补上你发现的空白（边界条件、接口格式、字段命名）。把最终确认的 Plan 保存成一个 PLAN.md 文件，这是后续的「合同」。

把 PLAN.md 的内容作为上下文前缀，让 Claude Code 按步骤执行。遇到报错直接让 Claude Code 处理，它的错误自愈能力在这个阶段更有价值。

不管用哪个工具，上下文漂移是必然的。养成习惯：每完成一个 Phase，把 PLAN.md 重新贴一遍，告诉 AI「我们现在在这里，接下来做这个」。这个操作 30 秒，能省去后面找漂移 bug 的 20 分钟。

---

工具永远在迭代，但判断工具的方法论是你自己的资产。

今天的结论是阶段性的——Grok Build 还在快速更新，Claude Code 也在迭代。但「用真实项目测试，记录具体数据，不说感觉只说日志」这套方法，不会因为工具更新而过时。

---

下一个问题我还没有答案：

当项目规模再大一个量级——比如加上数据库迁移、多环境配置、CI 脚本——Plan Mode 的优势还能撑住吗？

我正在跑第二轮测试，规模是这次的三倍，还加入了 Cursor 作为第三个对比对象。结果可能会推翻今天的结论，也可能会强化它。

---

#AI编程 #GrokBuild #ClaudeCode #AI工具评测 #编程效率 #848AI #开发者工具 #人工智能