众所周不知，我已经购买了 glm4.6 年付版本，但是体验下来编程能力着实一般。但是我转念一想，呵，实际上可以用来读代码呀。

因此使用 kilocode ask 模式用于读代码，节省了不少时间，速度还很快，也算是另一种回本。

在 ask mode 下，模型无法操作文件（偶尔也会有 bug 导致可以修改），因此不必担心 glm 瞎搞导致仓库出现问题。

基于此，更进一步思考下，如果 claude code 用完了，怎么进一步 vibe coding 呢？

有效利用弱模型的方法 - 在 ask mode 中使用

这就引出了我这两天尝试的一种新思路——效果很好—— ask mode 采用 glm4.6，coding mode 采用 deepseek-chat。

deepseek 能够较为严格的遵从指令，glm4.6 运行速度有保证。因此整个效率提升了。

此外，由于 ask 模式下，glm4.6 可以更好的提取信息，不至于浪费。如果理解错误了，切换成 deepseek-reasoner 也不迟。

一次性达成率 (Once Finished Rate, OFR)

我觉得对于一个 llm+coding agent 组合来说，一次性达成率 (OFR )至关重要。

一次性达成率定义为：

其中，$n_{f}$ 是一次性完成任务的数量，$N_{total}$是提出任务的总数量。在 coding benchmark 中，可以考虑观测 Pass@1 来衡量这个能力。

也就是说，当我们提出问题的时候，coding agent 能够一次性解决问题的比例。

比如 claude code + sonnet 组合，基本上是 OFR 是最高的。OFR 较高意味着用户不需要反复调试代码，只需要生成代码然后就可以投入到下一个 feature 的开发中。这是真正的高效和提效。

相比之下，GLM4.6 的 OFR 可能不到其一半的程度。用户需要不停的针对生成的代码进行优化。如果使用 coding agent 本身进行优化，可能来来回回也解决不了问题。这种现象我称之为 echo（回音壁），或者中文形式“鬼打墙”。绕来绕去，仿佛不具备智能一般。如果是其他的模型，例如 deepseek，在经过几次提示之后，可以走出 echo 状态。但是 glm 不太行。

笔者认为是过量的使用了生成数据造成的，即模型过拟合了。这在视觉模型上较为常见——通过生成数据来拔高在某些评测指标上的性能，但却因为生成数据过多导致在实际问题上无法得到较高的性能。