AI写前端，差的那一口气究竟在哪？

周三下午三点，你终于画完了那版堪称完美的Figma界面。圆角、阴影、间距全都调过三轮，每一个像素都长在你审美上。你深呼吸，打开AI编程助手，把那套设计截图抛进去，又补了一行字：“帮我把首页完整写出来，要跟图里一模一样。”

几分钟后，浏览器里渲染出来的页面让你血压直接拉满。按钮的红色怎么偏品？两个卡片之间的间距肉眼可见地宽了一丢丢。布局确实能用，但你总觉得缺了点什么，那种让你反复盯着设计稿和实现页面来回切换的别扭，怎么都挥之不去。

你犯的第一个嘀咕是：“是不是模型不够聪明？”于是你开始折腾。从Claude换到GPT，再换到最新刷榜那款模型，顺便还把号称前端最强的Fable也试了。结果呢？好了一点点，但离你心里那个“像素级完美”依然隔着一层雾。一样的间距问题，一样的色彩出入，一样的“乍看像那么回事，细看全不是那么回事”。折腾了一整个下午，你帮模型花掉的时间，比你自己手写代码还多。

这是过去大半年，我带着各种AI代理写完几十个前端界面之后，反复撞到的那堵墙。墙不在模型那头，在我们自己身上——这一件件做得别扭的UI，几乎都是由我们亲手搭建的工作流制造出来的。你以为跟设计稿之间的距离，是一点点模型智能差距；可等你真正把意图和交付放在一起对照，才会发现，那条沟比肉眼看上去深得多。

问题出在一个我们绝大多数人都习以为常的操作上：我们是在“描述”UI，而不是“展示”UI。

你回想一下，每一次让AI帮忙写前端，心里那条流水线是怎么跑的。你盯着一份设计稿——可能是Figma文件，也可能是一张截图，一个参考网站。然后你开始把眼睛里看到的东西翻译成语言：“左上角有一个卡片容器，里面有个红色按钮，标题加粗居中，底下是两行正文。”你满意地把这串描述敲进对话框，发给模型或代理，笃定它一定能还你一个漂亮界面。

这听起来没毛病。平时你带刚入行的新同事，不也是这么交代任务吗？可你要是换个场景思考，马上就能体会到其中的荒诞感。假设你现在真的在带一个人类前端开发，而且你就是那种表达能力特别好的产品负责人，对着设计稿逐元素描述，精确到每一个字号的像素值——但，有一条死规矩：你永远不能把设计稿本身给他看。他能依赖的，只有从你嘴里吐出来的那串句子。

哪怕你的描述已经精准到像设计规范文档，两个问题依然会像连锁反应那样瞬间浮现。第一个，你说的再多、再细，也永远不可能覆盖全部视觉信息。间距的微差、不同元素之间的视觉重力平衡、那种微妙得难以命名的阴影梯度、整套设计里靠直觉而非参数搭建起来的层级秩序——总有那么十几项气质性的信息，会在你翻译成自然语言的瞬间蒸发掉。自然语言处理视觉信息，本身就是有损压缩。而且这种压缩，压缩掉的恰恰是那些让一个界面“有感觉”的频段。

第二个问题更致命。即使你的描述真的奇迹般零信息损耗，也没有任何办法保证，读到这些文字的人——或者说，读到这些token的模型——会按照你心里设定好的那一套视觉坐标系来做解压。你说“红色按钮”，它调出来的是#FF4D4F还是#E63946；你说“加粗”，它给的font-weight是600、700还是800；你说“卡片间距16像素”，但实际设计稿里那个16像素，是从按钮底部算到下一段文字基线，还是从卡片边缘算到下一张卡片的外边距？每一个理解上的分叉，都会在渲染结果里累积成你一眼就能捕捉到的不对劲。

这就是那道沟。它不是AI聪明不聪明的问题，而是一道彻头彻尾的信息丢失沟。你把一份视觉上富得流油的设计原件，塞进一段只靠文字串起来的窄口瓶里，然后期待另一端魔法般地还原出原件的全部肌理。可从一开始，整个传输链路就把决定成败的那部分细节给过滤掉了。

这里有另一个特别容易让人掉进去的坑——也许你已经踩过，甚至现在还在用力往里踩。AI编程圈子最近有个非常流行的模式，叫作“先写计划，再执行”。遇到大多数工程任务，这个路子确实稳健：把一个复杂需求在动手前想清楚、拆干净，再交给模型一步步实现，产出的代码往往比直接一头扎进代码里靠谱得多。

可这套公式一旦落到UI工作里，就会在极短的时间内以一种极其隐秘的方式崩掉。搞崩它的元凶，叫“上下文衰减”。

还原一遍你熟悉的流程，你就能看见它藏在每一轮的哪一步。你看着设计，打开一个AI对话窗口，开始噼里啪啦写一份详细的实现计划。这个页面分三大区块，顶部导航栏包含logo和四个链接，链接hover态有下滑线……中间主区域，左右分栏，左边是侧边筛选面板，右边是卡片网格，每张卡片结构分别是缩略图、标题、一行摘要……底部footer，背景色#F5F5F5，三列文案加版权信息。写得越细，占用的上下文长度就越长。几百上千个token堆进去，这份计划成了你交给模型的唯一任务书。

等到模型真开始写代码，几轮对话下来，你再回头看当时那份计划。它已经不在模型眼前了，至少不在它活跃注意力的核心窗口里。当初被你用文字精确拆解过的那些设计，连同你自己对视觉效果的原始记忆，早已沉到上下文队列的深处，被后续的输出响应、追问、每一次自我修正和补丁代码一层层盖了过去。模型现在能看见的，是一个被压缩过的文本片段，可能还带着几处截断，而你当初塞进去的那些像素级的讲究，早就衰减成一段模糊的背景噪音。

更要命的是，UI任务天然就需要大量回合：生成一看，不对；改样式；改完再看，布局又偏了；再改布局；颜色调过，间距修改；改完这一处，上一处又因为整段代码重写而悄悄移位。每一轮把修正指令塞回上下文，都在把最初那份设计计划往更远的地方推。你越是努力把UI调得仔细，每一次调整就越是在稀释原始的设计灵感。最后出来的结果，只不过是你最早那个设计稿在无数次传话游戏之后留下来的一个影子。

所以说，“先写计划再执行”在UI上失效，不是因为计划本身不好，而是因为计划在这个场景里充当了那个不可避免会衰减的中间译员。而你想交付的那份设计，压根就不该经过任何文字译员的转述。它应该自己站到幕前的光里。

这个发现让我对一句话有了格外深的感触：我们与AI协作写UI的痛苦，常常被误读成模型还不够强、架构还不够新。可真正卡住脖子的，是很多人一直没有意识到，视觉意图在以“描述”为接口的工作流里，注定是不保真的。你每一条文字描述，都是对原始视觉信息的一次压缩；而当压缩后的信息再塞进一个延迟反馈的长链条里，经过上下文衰减的连续摧折，那个本该一眼定情的界面，注定只能成为一次次将就之后的产物。

这并不是一篇要告诉你“所以别用AI写前端了”的劝退文。恰恰相反，正因为这整套现象背后，被放大的不是智能的局限，而是信息架构的缺口，我才觉得这件事格外值得被剖开来看。搞清楚你丢掉的不是模型的几分能力，而是自己亲手埋葬的那部分视觉确定性，或许才是你真正开始掌控AI前端交付的第一步。