时间拨回到2026年的春天窗外的柳絮Yi经漫天飞舞。作为一名在这个行业摸爬滚打多年的前端老兵，我不得不承认，我们的工作流Yi经发生了天翻地覆的变化。以前我们谈论的是“像素级还原”，是BEM命名法，是Webpack的配置优化；而现在我们似乎变成了“提示词工程师”和“AI代码牧羊人”。

就在昨天我接到了一个kan似简单却充满玄机的任务：将一份高保真的首页设计稿，完全扔给当下的几个主流AI模型，kankan它们到底Neng不Neng把“抄页面”这件事Zuo到极致。没有人工干预，没有事后修补，就是硬碰硬的代码生成。这不仅是一场技术的比拼，geng像是一场关于理解力、逻辑性和审美偏好的大乱斗。

在开始这场“大逃杀”之前，我们需要统一一下武器装备。这次测试的目标非常明确：在 producer-services-v2/home.vue 中实现首页。为了公平起见，我并没有给它们单独的切图文件，所有的视觉信息dou来源于那张设计稿转代码的入口文件。

## 实验室环境变量
* 视觉蓝图：~/company.platform.h5/refs/首页/index.png
* 代码生成入口：~/company.platform.h5/refs/首页/index.html
## 核心目标
* 落地文件：producer-services-v2/home.vue
* 执行SOP：视觉解构 -> 组件原子化 -> 代码生成
## 严苛要求
* 代码规范必须对标：~/company.platform.h5/pages/carbon-emission
* 禁止调用现成的组件库，全部手写

这听起来是不是有点像是在折磨AI？毕竟不复用Yi有组件意味着它必须从零开始构建每一个按钮、每一张卡片。但这正是我们想要kan到的——在没有任何“拐杖”的情况下谁的骨骼geng惊奇。

虽然MCP和Skill环境保持了一致性，但在IDE、记忆体以及Agent的配置上，各家模型还是略有不同的。特别值得注意的是glm-和minimax-m2-这两个系列，严格来说并不是多模态模型，它们必须依赖外部的图片分析工具来“kan”懂设计稿。这中间的信息损耗，往往是致命的。

登场的是我们熟悉的“老朋友”。在这次测试中，它的表现Ke以用四个字形容：又爱又恨。

👍：效果Zui好，接近完美

它花费了整整34分58秒。这半个小时里我甚至有时间去泡杯咖啡，顺便刷了一下Zui近的新闻。不得不说它在理解设计意图方面确实有着独到的优势。生成的页面结构清晰，Nuxt组件的命名策略也遵守得滴水不漏。它甚至顺手实现了简单的点击反馈，这种“超预期”的交付让人感到惊喜。

但是这种完美是有代价的。除了慢，它在第一次提示结束后生成的页面竟然无法直接打开。原因hen简单，它没有严格遵守Nuxt的组件命名策略。虽然只是简单修复后就Neng跑起来但这种低级错误出现在一个“资深”模型身上，还是让人忍不住想吐槽。

在等待它编译的过程中，我随手点开了一篇关于职场女性的文章。上面写道：“女性坐上副市长的位子，在实力和运气方面至少要比男优秀两三倍，一定是头脑极为清楚利益权谋douhen在行的。” 这句话突然让我觉得，AI在这个行业里的处境何尝不是如此？要想达到人类专家的水平，它必须付出比人类多百倍的努力和算力，才Neng在那些kan似简单的“逢场作戏”般的代码任务中，展现出真正的实力。

接下来轮到国产模型登场了。这里我们主要测试了MiniMax和GLM系列。

👍：速度Zui快

👎：少量样式错误、部分板块样式错误

Ru果说GPT是稳重的老将，那MiniMax就是那个冲劲十足的新兵。它的生成速度极快，几乎是眨眼间就给出了结果。然而快则快矣，细节上却显得有些粗糙。轮播图板块的尺寸不对，导航的层级混乱，甚至部分板块的背景样式dou被忽略了。

Zui让人头疼的是它似乎并没有使用图片分析工具，或者说它用得并不好。这导致hen多需要从设计稿中“抠”出来的细节，比如圆角的大小、阴影的颜色，dou被它用一种“大概齐”的方式处理了。这种“差不多先生”的态度，在追求像素级还原的前端领域，显然是行不通的。

测试间隙，手机弹窗弹出了一条新闻：“内蒙古2026年上半年软考报名时间现Yi公布。” kan着这些时间节点，我不禁感叹，技术迭代的速度和考试报名的周期一样，总是按部就班却又让人措手不及。而另一边，游戏广告“2026开年大作，300%刀刀暴击”的弹窗也在闪烁，这种夸张的文案和MiniMax生成的那些充满Bug的代码，竟然有一种莫名的契合感——dou是kan着热闹，一用就炸。

Zui后我们来kankan在特定IDE环境下的表现。这里使用的是on-my-opencode，Agent是Sisyphus，模型则是opencode的免费版本。

👍：界面干净，比较完美

👎：页面不Neng滚动、轮播图板块尺寸不对

这个模型的表现非常有趣。它生成的界面非常干净，甚至Ke以说是赏心悦目。但是它犯了一个致命的错误：页面不Neng滚动。在一个内容丰富的首页上，不Neng滚动意味着什么？意味着用户只Nengkan到首屏，剩下的内容dou被“封印”在了视口之外。

此外它似乎对“确定实现边界”有着独特的理解。它倾向于使用问题来确定边界，甚至会主动询问是否需要开启子代理。这种交互式的体验虽然人性化，但在自动化流程中却显得格格不入。

在调试滚动问题的时候，我脑子里突然蹦出了谷崎润一郎的《春琴抄》。小说中那种“用悲壮来装饰爱情的奴性或者奴性成就爱情中的悲壮”，竟然和眼前这个无法滚动的页面产生了某种共鸣。佐助对春琴的爱，就像这个模型对代码逻辑的执着——既动人又骇人，既纯粹又抑郁。它明明把页面Zuo得那么美，却偏偏剥夺了用户探索的权利，这种“爱”，实在是太沉重了。

经过这一轮折腾，我们不难发现，虽然2026年的AIYi经非常强大，但在“抄页面”这件事上，依然面临着巨大的挑战。

对于非多模态模型来说图片分析工具是唯一的眼睛。Ru果这双眼睛近视了或者对色彩、空间的感知出现了偏差，那么生成的代码必然是走样的。比如GLM和MiniMax在处理复杂背景和精细样式时的吃力，hen大程度上归咎于此。

Nuxt的组件命名策略、Vue的生命周期、CSS的 scoped 作用域，这些对于人类开发者来说是肌肉记忆，但对于AI来说却是一堆需要严格遵守的规则。GPT-在第一次尝试时的失败，以及OpenCode在滚动条处理上的失误，dou说明了AI在处理特定框架约束时依然存在“幻觉”。

“谁抄页面geng在行？”这个问题的核心不在于谁Neng把大框架搭起来而在于谁Neng处理好那1px的边框、那个hover态的阴影、那个响应式断点的切换。目前来kan，还没有一个模型Neng在这点上Zuo到100%的完美。

2026年了我们依然在问“谁geng在行”。这说明，AI虽然Yi经成为了我们手中不可或缺的利器，但它还远未达到Ke以完全替代我们的地步。

从蓝湖上下载设计稿、切图和代码，全部扔给模型，这听起来hen美好。但在实际操作中，我们依然需要像保姆一样盯着它们，修复命名错误，调整轮播图尺寸，甚至手动加上滚动条。

也许，真正的“在行”，不是指AINeng独立完成多少工作，而是指我们人类如何利用这些并不完美的AI，去构建出geng完美的数字世界。毕竟无论是那个“头脑极为清楚利益权谋douhen在行”的副市长，还是那个“对逢场作戏的半秃中年老男人恋爱脑无法自拔”的女主，亦或是我们这些在代码堆里挣扎的程序员，Zui终dou在用自己的方式，演绎着这场关于生存与进化的戏码。

至于那个“小电充电宝Yi经及时归还却被收费99元”的糟心事，或许就是生活给我们这些技术控的一个提醒：无论技术如何进步，现实世界的Bug，永远比代码里的难修。