最近被问得最多的一句是，AI 看图写页面，现在到底行不行。
凭感觉答不了。10 月 7 日 arXiv 上挂了一篇 TaoD2C-Bench，专治这个问题。它干的事，是给“从设计稿生成 UI 代码”造一把尺子。
简单说，D2C 就是设计稿到代码。这一步的门槛，从来不在画得像。
这期只收这一条。
先说清楚它在测什么
模型看图，认出这是个按钮、那是个输入框，这步它早就会了。
这篇要测的是下一步。认出之后，还得知道这个按钮在你这个项目里必须怎么写。
作者把这步叫“具备约束意识的跨模态推理”。白话版是，光看见不够，还得在一堆规矩里挑出对的那一种写法。
2861 份设计稿，全是从生产环境里捞的
来自 17 个商业平台，2861 份，配了 97652 条专家标注。
最值得看的是“生产环境”这四个字。网上挑几个漂亮页面做演示谁都会。真实项目里的图层是乱的，命名是随手起的，嵌套是没有道理的。这层脏东西，才是门槛本身。
标注分了四类：Component、Group、Alignment、Position
四类合起来干一件事，把“必须这么写”和“怎么写都行”分开。
哪几类算硬约束，论文里应该有说法。那张表我没细看，先不瞎猜。
但这个拆法是对的。不拆，模型答对答错都不知道为什么。
任务是三个，不是一个
端到端生成、需求推断、需求实现，分开测。
一步到位最省事，也最看不出问题。拆成三段，才知道它具体卡在哪一段。
八个模型，视觉都能打，一到“实现要求”就掉
作者自己的结论更硬：视觉还原强，不代表能生成符合实现要求的代码。
这条是全文最该记住的。
这个偏差在真实项目里会被放大
设计稿在真实项目里不是一张图。
它背后压着图层元数据和现成的组件库。间距走变量还是写死，项目里早就有规矩。模型把图看懂了，它不知道你项目里那个按钮叫什么名字，不知道这里该引一个 token 还是硬写个 12px。
像素对上，实现全错。绝对定位堆出来的页面，截图能和设计稿分毫不差，改一个字的宽度就全塌。
设计稿是要改的。第一版做完，产品说要加一栏，间距要统一。硬写的代码改一次塌一次，符合实现要求的代码改起来是改配置。这是“实现要求”四个字的实际含义，不是什么洁癖。
截图对比这种演示方式，我一向不太当回事。它好卖，因为一眼就懂。它没用，因为错误的实现方式有一百种都能让截图对上。
普通人能抄走什么
一件事就够了：别只看页面像不像。
把代码打开，看它是不是一堆绝对定位堆出来的，看间距是写死的数字还是引用的变量。两分钟的事。
这个动作比换工具管用。工具之间的差距，之前也提过一次，远小于“你有没有坚持用下去”的差距。
数据集公开了，这条我留着
作者把 TaoD2C 放出来了，支持后续研究。
这类基准的价值不在榜单排名，在于它定义了什么算对。定义一旦被同行接过去，后面所有工具的改进方向都会跟着它走。等它被引用几次，我再回来看一眼。
最后补两句
这篇 26 页，我只细读了方法和结论那几节，实验部分是跳着看的。八个模型之间的细分差异，我其实没吃透。
另外，这个基准把问题拆得很干净，干净得有点像实验室。真实项目里，人是一边改一边骂的。这中间的差距有多大，我说不好，先放在这里。
本周就这些。
上面有任何一条你试过、或者觉得我讲错了，欢迎告诉我。讲错的我补，没讲清的我改。
下周见。