本来想体验一把“vibe coding 省时间”，结果变成“vibe coding 省不了、还很贵”：折腾将近一小时，GLM 额度直接打满，Bug 还在。

---

背景：事情是怎么开始的

最近遇到一个前端 Bug，属于那种看起来不大、但很烦的类型：页面运行时报错，提示动态导入某个模块失败（报错里能看到类似 Failed to fetch dynamically imported module .../router/index.ts 这种信息）。

我想着正好试试工具链：Claude Code + GLM4.7。理想情况是：它读代码、跑命令、给修改方案，我负责点确认就行。

现实是另一回事。

---

结果：时间花了，额度没了，Bug 还没修好

简单总结一下这次的“账单”：

• 时间：差不多 1 小时
• token：累计 3000 万+
• GLM 套餐：5 小时使用限额直接用光
• 结果：依然没解决

过程中 Claude Code 做了很多事：读路由文件、尝试修改、清缓存、重启 dev server、反复验证……看起来很努力，但就是一直不收敛。

最让我难受的点其实不是“没修好”，而是：它是在持续消耗资源的前提下没修好。这跟我自己手动 debug 不一样——我自己卡住了，最多是浪费时间；它卡住了，是时间 + 额度一起烧。

---

为什么 Claude Code 这么吃 token？（我的体感原因）

我这次感觉 token 高，并不是我问了多少问题，而是它的工作方式决定的。

1）它不是“聊天”，更像一个一直在跑的 Agent

它会不断做这套循环：

1. 读文件（读一堆）
2. 给判断（往往还挺像那么回事）
3. 改代码/跑命令
4. 把新日志再丢回去继续推理

这套链路一旦跑起来，就很容易停不下来。

2）前端日志太长了，而且会反复进上下文

前端工具链输出本来就长：Vite/Webpack、HMR、各种 warning、stack trace……
你以为“就一段报错”，实际上它每次重启都会多出一坨新内容。

更关键的是：这些日志会被反复引用。上一轮的 log、下一轮的 log、它自己的总结、它提过的假设……都在累积。

3）“尝试式修复”很费钱

这类工具经常是这样的节奏：猜一个原因 → 改一下 → 跑一下 → 不行再换一个猜法。

如果方向一开始就偏了，那后面就是持续的“试错”，而试错在 Agent 模式下特别贵。

4）工具链/环境一旦不稳，token 会被“空转”吃掉

截图里还能看到一些类似 exit code 127/137 的失败信息。
这种问题往往跟脚本、权限、端口、内存、依赖环境有关。

我自己的经验是：只要验证环节不可靠，后面就很难收敛。因为它得不到稳定反馈，只能继续猜、继续换方案、继续跑，然后继续烧。

---

GLM4.7 是不是“能力不行”？

这个问题我纠结了一下。最后我更倾向于：不完全是模型能力问题，而是前端 Bug 本身太“现场”了。

1）很多前端 Bug，不是“知道答案就行”

动态 import 失败这种，根因可能在很多地方：

• 构建配置（Vite / Webpack）
• base 路径、publicPath、路由 history 模式
• tsconfig alias
• 依赖冲突、缓存、HMR
• 本地环境和启动方式差异

它不像一道算法题：你给足信息，模型就能直接解。
它更像“带着项目在现场排雷”，需要不断缩小范围、做最小复现、做二分定位。

2）模型想解决它，前提是你得给它“能定位”的素材

比如：最关键的 100 行报错、最小能复现的路由/页面、确定能跑通的验证命令。
如果这些东西不稳定（比如命令都跑不起来），模型就算再强，也只能在雾里摸。

所以我对 GLM4.7 的评价是：
它能做很多辅助工作，但在这种工程化、链路长、变量多的问题上，很容易卡住。

---

这次之后我对 vibe coding 的真实看法

我不想“唱衰”，因为它确实有爽点，但它也确实没到“全自动写代码”的程度。

优势：它能帮你把脏活累活干得很快

• 快速扫代码、总结目录结构
• 帮你写小 patch、补类型、补测试
• 写脚本、写文档、写配置模板都很顺
• 常见坑（比如 lint、ts 类型、简单构建问题）命中率不低

缺点：一旦进入死胡同，会比人手更贵

• token 消耗不可控（尤其是带日志的多轮迭代）
• 容易“修一个问题，改一堆地方”，最后你还得自己收拾
• 对环境依赖很重：只要跑命令不稳定，它就容易乱
• 它的“自信总结”有时候会让你误以为快到终点了，其实方向早偏了

目前我觉得还很难搞定的场景

• 复杂工程化问题（monorepo、pnpm workspace、各种 bundler 插件链）
• 偶发问题、竞态、缓存相关问题
• 需要非常强业务上下文的 bug（表面报错，根因在业务状态）
• 工具链本身就不稳定（127/137 这种都没解决前，后面基本白跑）

---

我现在会怎么用它（避免再烧一次）

这次翻车之后，我给自己立了几个“止损规则”，挺管用：

1. 先让它做定位计划，不要直接开修
   让它先输出：最可能的 3 个根因 + 各自最小验证方式。
2. 日志只给关键部分
   我现在会手动裁剪：只给首次报错点 + stack + 关键配置，不把整屏日志塞进去。
3. 验证命令必须先跑通
   dev 起不来、脚本报 127/137，这种不先解决，后面全是空转。
4. 每次改动小步提交
   一旦它开始“越改越多”，我能立刻回滚，不跟它一起沉没成本。
5. 设预算上限
   比如 10 轮没有明显收敛，就暂停，换人类二分定位。

---

总结

这次体验给我的感觉很明确：

• vibe coding 能加速，但它加速的是“尝试”，不是“必然解决”
• 在前端工程这种复杂环境里，一旦方向错了，Agent 会把错误路线跑得非常完整——顺便把额度也跑完
• 想让它真的变成生产力，关键不是“多问”，而是：控制输入、保证验证、让问题可收敛

---

都看到这了，欢迎大家一起讨论分享你们优秀的vibe coding经验，或是向我一样的翻车现场