本来想体验一把'vibe coding 省时间'，结果变成'vibe coding 省不了、还很贵'：折腾将近一小时，GLM 额度直接打满，Bug 还在。
起因：一次意外的尝试
最近遇到一个前端 Bug，属于那种看起来不大、但很烦的类型：页面运行时报错，提示动态导入某个模块失败（报错里能看到类似 Failed to fetch dynamically imported module .../router/index.ts 这种信息）。
我想着正好试试工具链：Claude Code + GLM4.7。理想情况是：它读代码、跑命令、给修改方案，我负责点确认就行。
现实是另一回事。
结果：额度耗尽，问题依旧
简单总结一下这次的'账单'：
- 时间：差不多 1 小时
- token：累计 3000 万+
- GLM 套餐：5 小时使用限额直接用光
- 结果：依然没解决
过程中 Claude Code 做了很多事：读路由文件、尝试修改、清缓存、重启 dev server、反复验证……看起来很努力，但就是一直不收敛。
最让我难受的点其实不是'没修好'，而是：它是在持续消耗资源的前提下没修好。这跟我自己手动 debug 不一样——我自己卡住了，最多是浪费时间；它卡住了，是时间 + 额度一起烧。
为什么 Claude Code 这么吃 token？（我的体感原因）
我这次感觉 token 高，并不是我问了多少问题，而是它的工作方式决定的。
1）它不是'聊天'，更像一个一直在跑的 Agent
它会不断做这套循环：
- 读文件（读一堆）
- 给判断（往往还挺像那么回事）
- 改代码/跑命令
- 把新日志再丢回去继续推理
这套链路一旦跑起来，就很容易停不下来。
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 行报错、最小能复现的路由/页面、确定能跑通的验证命令。 如果这些东西不稳定（比如命令都跑不起来），模型就算再强，也只能在雾里摸。
