[控场AI]
· 4 分钟阅读· 2,287 字

AI建站自评通过,浏览器QA却揪出4个致命Bug

AI建站自评通过,浏览器QA却揪出4个致命Bug

AI自评通过不等于成品合格,固定的浏览器验收门在三个断点下抓出了四个结构性Bug。

文章记录了用AI代理搭建两个虚构店铺(华沙手表制造商与微型字体铸造厂)的过程。模型自评"干净利落",但作者引入"验收门"——一份固定的通过/失败清单,在三个断点下对着实际页面逐项检查,结果揪出四个问题:需要规格表的地方放了英雄区、购买栏在375px断点崩坏、prefers-reduced-motion降级停在旋转中间、自动缩放字体溢出错。作者由此指出AI自评的本质是给意图盖章而非给现实盖章,并总结出AI建站十个"马脚",强调结构性马脚远比视觉性马脚昂贵。解法是约1KB的预提示词约束加浏览器验收门,失败截图作为凭证保存。

一个AI代理花了一下午建了两个虚构店铺——一个华沙手表制造商和一个微型字体铸造厂。它写页面、在浏览器里跑、然后宣布自己的活儿干净利落。但接下来,我们做了大多数AI生成作品从未经历过的事:给它打分。

我们把这套流程叫做"验收门":一份固定的通过/失败清单,在三个断点下对着实际页面逐项执行。不是"让它看起来高端",而是一套AI无法用花言巧语糊弄的硬标准。

结果,同一个模型已经签字画押的成果里,被揪出了四个问题。

AI建站验收入口

自评是橡皮图章,QA才是照妖镜

AI自检为何靠不住?因为它在评价意图,而不是评价成品。模型记得自己"打算"放一个响应式购买栏、"打算"尊重减少动画偏好、"打算"让字体自适应。它检查的是脑内蓝图,不是屏幕上那个会在375px宽度下把价格甩出视口的真实DOM。

四个被抓住的Bug,每一个都精准踩在"意图良好、成品翻车"的裂缝上:

  • 该放表格的地方放了英雄区。 手表页面用一句情绪化的大标语开场,但访客此刻需要的是规格表:机芯、表壳尺寸、价格。页面好看,却什么都没回答。
  • 购买栏在375px断点崩了。 移动端价格飘出屏幕。只检查了一个视口,布局却恰好只适配那一个宽度。
  • 减少动画的降级方案并不"静止"。 prefers-reduced-motion 被遵守了——用的是一个冻结帧,而那帧恰好停在旋转中间。对运动敏感的用户看到的是一个破碎的静帧,不是平静的画面。
  • 自动缩放字体只适配短输入。 字体铸造厂的招牌渲染器把演示词排得很漂亮,真实名字却溢出容器。快乐路径被发运了。

这些都不是"AI不会设计"。它们全部是"没人在AI交付后跑QA"——而AI的自我审查,本质上是给意图盖章,不是给现实盖章。

prefers-reduced-motion 是 CSS 媒体查询中的一项用户偏好设置,当用户在操作系统层面开启"减少动态效果"后,浏览器会向页面暴露该标志。前端开发者应据此禁用或替换位移动画、视差滚动和自动轮播等效果。常见的错误做法是"冻结当前帧"——即暂停动画但不重置到起始状态,结果画面可能停在旋转中途、缩放一半或淡入半透明的中间态,对前庭功能障碍或运动敏感的用户而言,这种"破碎静帧"比连续动画更易引发不适。正确的降级应是完全移除动画、跳转到终态,或使用静态替代图,而非简单地 animation-play-state: paused。

响应式断点测试指在预设的若干视口宽度(如 320px、375px、768px、1440px)下分别验证布局。只在单一断点检查是常见陷阱:AI 或开发者往往在桌面宽度下确认"看起来没问题"就交付,而移动端价格的溢出、按钮被挤出屏幕、文字截断等问题恰恰只在窄视口暴露。更隐蔽的是"恰好一个宽度正确"——布局使用了固定 px 或 vw 单位混用,导致在 375px 完美、在 414px 或 360px 立刻崩坏。固定的通过/失败清单应在多个典型断点逐一截图比对,而非依赖视觉记忆。

十个"马脚":AI建站的结构性破绽

这次练习逼我们写下AI搭建界面里反复出现的模式。借用扑克逻辑——马脚就是没人在看时你会做的事:

  • 反射性的靛蓝渐变
  • 永远三个、大小相等的功能卡片
  • 没人要求的毛玻璃效果
  • 全不透明度但什么都没说的英雄区
  • 几乎真实但经不起推敲的文案("革新你的工作流")
  • 唯一、居中、不容错过的CTA按钮
  • 穿着设计系统外衣的emoji项目符号
  • 没人真正承诺过的定价表数字
  • 只存在于快乐路径上的状态
  • 恰好在一个视口下正确的布局

真正重要的是这一点:昂贵的马脚是结构性的,不是视觉性的。 靛蓝配色很便宜——一行提示词就能在代码诞生前杀掉它,这也是为什么基于视觉马脚训练的分类器总在追一个移动靶。而"在需要表格的屏幕上塞一个英雄区"能扛过任何颜色更改。

这才是值得写进清单的那一类问题。配色可以提示词解决,结构错误只能靠审视真实产物来解决。

结构性马脚 vs 视觉性马脚 的区分是本文的核心判断框架。视觉性马脚(靛蓝渐变、毛玻璃、等大卡片、emoji 项目符号)属于表层装饰,一条否定提示词(negative prompt)或设计系统约束即可根除。结构性马脚则涉及信息架构与内容决策:在需要规格表的位置放英雄区、缺少错误/加载/空状态、定价表数字空洞、状态只覆盖快乐路径等。这类问题无法靠改颜色或换字体解决,必须审视真实 DOM、真实数据、真实断点下的产物才能发现。它们更昂贵,因为它们不是"不好看",而是"不回答用户此刻的问题"。

我们的解法:约束前置 + 浏览器验收门

我们做出了两件故意很无聊的产物:

  • 一份约1KB的预提示词约束,在生成时就杀掉那些视觉马脚
  • 一道在3个断点下执行的通过/失败浏览器验收门,失败截图直接存为凭证——我们操作手册里的拆解案例正是这些,Bug也包含在内,因为Bug本身就是产品

这套方法的核心在于把"验收"从模型手里夺回来,交给一个不会为意图买单的机制。

至于发布,我们以KURSYWA PRESS的名义公开。需要说明的是,完整方法论是一份29美元的PDF,2页摘录免费。

更有意思的是,我们想知道验收门在你的AI页面上会标红什么。欢迎在评论区丢一张截图描述——结构性马脚最严重的那个,赢一次免费审查。

#AI建站#浏览器QA#AI自我审查#验收门#响应式设计#AI生成UI#结构性Bug#prefers-reduced-motion
分享:

相关推荐