这个案例戳中了AI编程的深层痛点——代码直觉比参数更重要，做复杂逻辑开发的团队看完会重新评估模型选择。
一位开发者分享体感：模型编程能力的强弱，极度体现在代码直觉上，而这部分最难训练，需要海量开发经验堆砌。他以一个路网生成bug为例，GPT-5.5-pro-xhigh反复修不好，因为模型固有直觉认为每条边只需一个tile，而实际需要两个。即使多模态截图打脸也无用，最终开发者自己下场，让模型给tile编号并追问，才暴露问题。修复过程很简单：告诉模型每个tile对应单位长度，计算填充即可。不同模型在类似bug上表现差异巨大：有的上来就不犯错，有的迭代几次修好，有的怎么都修不好。
我现在的体感是，模型能力到底强不强(仅讨论编程)，会极度体现在代码直觉上，而这部分是最难训练的。这是…
我现在的体感是，模型能力到底强不强(仅讨论编程)，会极度体现在代码直觉上，而这部分是最难训练的。这是海量的开发经验堆出来的。
比如我这个bug, 生成的路网是断裂的, GPT-5.5-pro-xhigh都修不好. 但其实问题很简单, 我跟他说路网断裂, 他就觉得, 你矩形地块就是4条边, 对应4个tile, 然后4个角再来4个tile, 完事了, 怎么会断裂呢?
而实际上每条边需要用2个tile才能填充完毕, 这种"每条边一个tile"的固有直觉, 直到你发现之前, 你让它修, 是怎么都修不好的, 多模态模型截图打他脸也没用(强烈怀疑向量空间映射到一起了). 只能靠你自己发现问题的根源, 并反推模型在哪里出现了问题.
我这个case断断续续修了4小时了, 直到我意识到了, 我得自己下场了, 于是让它给每个tile编上ID，然后直接问他, 你觉得这两个tile之间可以容纳几个tile. 立刻露馅了, 他就觉得填充一个tile就ok了...
修复过程立刻就变得极其弱智, 告诉它应用规则, 每个tile对应几个单位长度. 然后计算填充就完事了...
而现在有一个模型, 上来就不会犯这个错误. 然后又有一个模型, 虽然会犯错误, 但是迭代几次修好了, 最后就是怎么都修不好. 大家会觉得哪个模型能力强?