基本信息

来源摘要/节选

公开展示已截断至最多 800 个字符；请访问原始来源查看完整上下文。

AI 写业务逻辑已经很顺手，但设计稿还原？样式丢、布局乱、代码难维护。这不是模型不够强，是我们喂给它的输入不对。 落地过程中，我发现 AI D2C 的困难归结为两个根本问题。 问题一：AI 没有空间认知 LLM 是序列模型，处理的是 token 流，不是二维平面。当它看到： { “x” : 285 , “y” : 725 , “width” : 700 , “height” : 440 } { “x” : 1005 , “y” : 725 , “width” : 370 , “height” : 440 } { “x” : 285 , “y” : 1165 , “width” : 340 , “height” : 400 } 它看到的是三组数字，不是「第一行两张卡片并排，第二行一张卡片靠左」。 人看设计稿是空间扫描 — 一眼看出对齐、等距、分栏。 LLM 看坐标是数值推理 — 要算 1005 - 285 = 720 ，再跟 width: 700 比较，才能推断「这两个元素是水平排列的」。而数值推理恰恰是 LLM 最弱的能力之一。 这导致几类典型错误： 空间关系 人的判断 LLM 容易犯的错 水平对齐 y 值接近就是一行 把 y=725 和 y=730 判断成两行 等分布局 三个等宽元素占满容器 生成固定 px 而不是 flex:1 嵌套层级 小元素在大元素内部 坐标包含关系算错，层级打平 间距规律 所有模块间距 20px 部分写 20，部分写 16，不一致 本质原因：Transformer 的自注意力机制是在 token 维度上建立关联的，它没有内置的二维坐标系。它理解「猫坐在垫子上」比理解「x=100 的元素在 x=500 的元素左边」要容易得多——前者是语言语义，后者是空间计算。…

来源说明

当前只保存了公开页面节选，不代表原文全文。请以原始来源为准。

本页只呈现已做哈希绑定的来源证据，不包含基于旧正文或缺失原文的扩展推断。