先贴个东西。
<circle cx="50" cy="80" r="15" />
一个车轮。SVG 里的一个圆圈。
前几天有人拿云端大模型去画鹈鹕，等了十一分钟，花掉十七美分。推理过程里，明明白白生成了这段车轮定义，最后拼出来的图里——没轮子。生成了，没放进去。
这事儿最有意思的地方就在这。不是云端慢，不是收费贵。是模型自己算出了正确答案，然后扔了。
有人说这可能不是模型的锅，是中间某个查看器渲染吃掉了。这恰恰说明问题——链路长了，你根本不知道哪一环在作妖。这也是我死扛着不用多层 agent 框架的原因。每一层调度都是黑盒，每一层都可能吞掉一个车轮。
丢车轮，和模型写代码时的默认过度设计，是同一个毛病。
前几天我让模型写一个字节缓冲区拼接函数。它给了我一个带引用计数的、带写时复制的、带自定义分配器接口的"通用缓冲区管理器"。一百二十行。
我要的其实是这个：
void buf_append(buf_t *b, const char *data, size_t len) {
memcpy(b->data + b->len, data, len);
b->len += len;
}
四行。模型不会给你四行。模型给你一百二十行。它训练数据里"看起来对"的代码都长那样。它不知道我是单线程，不知道我不需要 COW，不知道那个分配器接口这辈子只会有一个实现。它把所有可能性全塞进来。
在该收拢的地方漏放，在该精简的地方堆砌。模型对"正确"没有一个笃定的判断，它只有一个平均。
说句题外话。与其等十一分钟看云端转圈圈，不如自己本地跑。三十五 B 的模型在你自己机器上跑，三十 token 一秒，不花钱，数据不出门。出问题你自己 gdb 上去，不用瞎猜是哪个查看器吞了车轮。
本期就这句：凡是模型给你的东西比你要求的多两倍，先砍再读。