图片由 lovart 生成。
众所周不知，我已经购买了 glm4.6 年付版本，但是体验下来编程能力着实一般。但是转念一想，呵，实际上可以用来读代码呀。
因此使用 kilocode ask 模式用于读代码，节省了不少时间，速度还很快，也算是另一种回本。
在 ask mode 下，模型无法操作文件（偶尔也会有 kilocode 会有 bug, bug 可能导致 LLM 可以修改文件。但是近期未出现），因此不必担心 glm 瞎搞导致仓库出现问题。
基于此，更进一步思考下，如果 claude code 用完了，怎么进一步 vibe coding 呢？
有效利用弱模型的方法 - 在 ask mode 中使用
这就引出了我这两天尝试的一种新思路——效果很好—— ask mode 采用 glm4.6，coding mode 采用 deepseek-chat。
deepseek 能够较为严格的遵从指令，glm4.6 运行速度有保证。因此整个效率提升了。
此外，由于 ask 模式下，glm4.6 可以更好的提取信息，不至于浪费。如果理解错误了，切换成 deepseek-reasoner 也不迟。
关于 Ask Mode
Ask mode 限制了大模型对文件的操作。也就是说大模型只能 read file 但是不能 write file。
通过并行读取，kilocode 可以一次性将多个文件提供给 LLM 进行代码阅读，从而加速开发者对代码进行理解。
这些 ask 的内容可以作为 context 给模型。也就是说，如果你希望让模型更加了解代码，通过几次 ask，然后切换到 coding mode 来修改代码，可能会得到更好的结果。
一次性达成率 (Once Finished Rate, OFR)
我觉得对于一个 llm+coding agent 组合来说，一次性达成率 (OFR )至关重要。
一次性达成率定义为：
$$ OFR = \frac{n_{f}}{N_{total}} $$其中，$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 不太行。
为什么 glm 不行？
浅见：该问题是 glm 4.6 过量的使用了生成数据造成的，即模型过拟合了。这在视觉模型上较为常见——通过生成数据来拔高在某些评测指标上的性能，但却因为生成数据过多导致在实际问题上无法得到较高的性能。