多模态模型到底会不会照着图写代码？
简单说，就是给它一张图表截图，让它输出一段能把这张图重新画出来的代码。
这两件事以前一直是分开考的。看图一张卷，写代码一张卷，各自分数都挺体面。10 月 7 日挂到 arXiv 上的那篇 From Pixel to Coding，把两张卷子订成了一张。合起来考，成绩立刻不好看。
这期只收这一条。论文编号 arXiv:2610.10066，46 页，18 张图。作者十人，第一作者 Zijian Chen，同时挂在 cs.CV 和 cs.AI 两个类目下。
它做了个评测框架，叫 FigCodeBench
6,194 个样本，7 个功能类别，4 种编程语言。
难度分三层。分层方式是这篇里我觉得最值得学的一点。视觉复杂度和代码复杂度放在一起建模，再定难度。图的繁简和代码的难易是分开看的，两头各自有多难都算进去。
很多评测失败就失败在只看一头。图很花但代码简单，或者图简单但代码约束很死，单维度打分会把这两种平均掉。
三个难度层级，难在三样东西
复杂结构推理、不同宽高比、密集几何约束。
这三样恰好是看着简单、做起来全是坑的典型。宽高比一变，坐标全得重算。约束一密，一处错位，后面全歪。模型在这种地方最藏不住，一眼就能看出它其实是在猜。
24 个模型，一个都没绕过去
Gemini 3.1 Pro、GPT-5.4、Kimi-K2.5 都在名单里，闭源开源一共 24 个。
结论是：不管哪个模型、哪种语言、哪档难度，都存在非线性性能断崖。
“非线性”三个字是全文最值钱的地方。难度加一档、分数掉一点，那是一回事。到了某个位置整段垮掉，是另一回事。前者还能靠调 prompt、加例子、换个写法磨一磨，后者磨不动。
约束硬的语言上，掉得最明显
论文里有一句，在约束严格的声明式语言上，各项指标下降尤其明显。
这条我认为最能说明问题。Python 里写歪一点还能跑，跑出来看着还挺像那么回事。约束硬的语言不给你糊弄的余地，模型到底有没有真看懂那张图，立刻见分晓。
所以“AI 写代码很强”这句话，后面得补一个语言名。
它怎么打分，这条我只懂一半
评测协议两个维度：视觉保真度，语法同构性。作者说这套打分的结果和平均机器意见得分、人类偏好都对得上。
视觉保真度好理解，画出来像不像。语法同构性具体怎么算，我没吃透。先放在这里，等我搞明白再补一句。愿意替我先看懂的，更欢迎。
真正有价值的部分，是那个统一的角度
作者的出发点不复杂。现有基准大多把视觉理解和代码生成分开评，缺一个把两件事放在一起看的考察。已有的视觉代码生成基准，又大多只涉及单一编程环境里的简化布局。撑不起“统一多模态推理”这个说法。
拆开考出来的高分，加起来不等于合起来能用。这个道理放到人身上也成立：会看图的人，和会写前端的人，不一定能一个人把活干完。
补充一句，这篇没回答的问题是：看图的能力和写代码的能力，在模型内部到底是不是同一件事。它只证明了在分数上不是。分数上不是，已经够用了。
普通人不会去跑 FigCodeBench，但会在别的地方撞上同一堵墙
让 AI 照着截图复刻一个页面，或者照着一张表复刻一个组件。头两块砖码得挺齐，第三块开始它自己编。编的时候语气和前面一模一样。
断崖对普通人的实际含义就是这个：它垮的时候不会举手。
验收的办法只有一条，往下再试两档。别停在第一个跑通的例子上，第一个跑通的那个，很可能正好在崖边上。
这类能力对普通人是真机会，值得花时间摸清楚。但机会在于知道它什么时候不行，不在于相信它什么时候都行。
本周就这些。上面有任何一条你试过、或者觉得我讲错了，欢迎告诉我。讲错的我补，没讲清的我改。
下周见。