AI生成的网页上线前，错位、字体、表单、手机端、收录这五处挨个过一遍

网页上线之后出问题的概率，和生成速度没什么关系。真正自己踩过一遍的人都清楚，那些让你半夜爬起来改的东西，几乎都不是什么高深的技术故障：一张图在手机上横着溢出去，一个表单点下去没反应，一行标题压在深色底上看不清。这些毛病全在你眼皮底下，只是你只看了自己那块屏幕，就一个个溜过去了。

把该看的地方挨个过一遍，多数情况用不到一个小时，省下来的却是上线后反复返工的好几天。而且检查这件事本身有顺序，乱着来的话，改完一处牵动另一处，越改越乱，最后连原来正常的地方也跟着出问题。顺序该是从肉眼能看到的，往只有机器才看得见的走。

一、机器漏掉的细节，其实分三层

AI 生成的页面出问题，很少是"代码写错了"这么简单，更多时候是"没人替它确认过"。把细节分层之后，处理起来就不容易乱：哪些是你必须亲自拍板的，哪些是丢回给工具批量处理的。

内容层归你。文案写得漂不漂亮是次要的，能不能对上你的真实业务才是关键。有些页面会把公司名、服务片区、营业时间写得似是而非，甚至凭空生成一段案例。这类问题 AI 帮不上忙，它不知道你的真实情况，只有你逐字读一遍才拦得住。

结构层也归你。先讲什么、详情往后放还是往前放、行动按钮出现在几处、导航要不要留，这些是策略判断，跟技术无关。同一个页面，顺序换一次，转化结果可能完全不同，而 AI 只会按它理解的平均值来排，排出来的东西永远挑不出错，也永远不疼不痒。

工程层可以还给机器。标签有没有闭合、图片尺寸给没给、表单接收地址是不是空的、页面里的链接还有没有能打开的、meta 信息有没有重复，这类活儿交给工具去核，比人盯得准，也比人快。人眼在三百行代码里找一个多出来的闭合标签，基本等于大海捞针。

跑完这三层，你会得到一个清单。清单的长短不重要，重要的是每一项都有明确的责任人：要么是你，要么是机器，没有第三种叫"以后再说"。

二、错位和溢出，换个屏宽就现原形

在一台 1440 宽的显示器上看，页面正不正常，其实说明不了什么。生成工具惯用的固定宽度容器、绝对定位、写死的图片尺寸，在大屏上服服帖帖，缩到 375 宽的手机屏就原形毕露：文字被挤成竖排，图片撑着页面横向滚，按钮跑到屏幕外面点不到。

见得最多的是三类。一类是长英文单词或者一条没换行的链接把容器撑破；一类是图片只给了宽度、没给最大宽度，原图比屏幕还宽；一类是绝对定位的浮层，在窄屏上越过了边界。这三种改起来都不难，难的是发现，靠坐在电脑前看一眼是发现不了的。

靠谱的做法是拿浏览器的设备模拟功能，从 320 宽一直拉到 1920 宽，中间在 375、414、768、1024 这几个常见节点停一下，看完再往下拉。重点看四处：首屏、宽表格、代码块、长段落。首屏是访客第一眼看到的地方，宽表格和代码块是最容易横向溢出的地方，长段落则是行宽失控的高发区。

三、字体和层级，一屏里有没有一条主线

排版出问题的方式很安静：它不是错，是乱。字号用了七八档、颜色四五种、行距忽宽忽窄、间距全凭感觉，读者说不出哪里不对劲，只觉得不想往下看。这类问题最难自查，因为页面在技术上完全正常，每一个元素都能显示，只是没有主次。

给自己定几条硬线，改起来就有依据。一页里的字号控制在三级以内：标题、正文、辅助说明，再多就会显得杂。正文行高落在 1.7 到 1.9 之间，中文比英文更需要行距，1.5 以下读起来会挤。正文和底色的对比度不低于 4.5:1，这是 WCAG 2.2 对普通文字的 AA 要求，浅灰字配浅灰底看着高级，读三行眼睛就累。

比数字更重要的是主线。一屏里只能有一个主角：首屏上最重的那行字应该是什么，其余元素都得往后退一步。生成工具的通病是平均用力，每块内容都想强调，结果每块都不突出，读者扫两眼就滑走了。改这一处的办法很土但有效，把页面缩到 30% 看一眼，哪个色块最扎眼、哪行字最先跳出来，那大概就是读者看到的第一眼。

排版不是装饰，它是读者用来判断"这一页值不值得读"的第一道门槛。门槛太高，内容再好也没人走到门口。

还有一个细节容易被漏掉：中文和英文混排时的间距、标点在行首行尾的位置、数字与单位之间要不要留空。这些小地方单看无所谓，凑在一屏里就会显得不干净。如果页面主要面向中文读者，把字体栈里的中文字体往前排，能省掉不少渲染上的意外。

四、表单和按钮，转化路上最贵的一段

页面做得再好看，表单提交不成功，前面所有工作都是零。这一段是上线前最该亲手走一遍、也最容易被"看起来没问题"骗过去的地方。生成出来的表单，外观通常挑不出毛病，毛病出在看不见的那一端：提交地址还留着示例值，或者干脆是个空壳。

试的时候别偷懒，把整条链路走完：填一遍真实信息提交，看有没有跳转回执页、邮箱有没有收到、后台有没有记录。反过来也要试：只填一半就提交，看校验提示是不是清楚；故意填错格式，看有没有拦住；连续点两下提交按钮，看会不会重复入库。这几下来一遍，能挡掉后面一大堆麻烦。

按钮的坑和表单是一回事。颜色再漂亮，点了没反应也是一场空：跳转按钮要真跳，提交按钮要能按，移动端还得看点得着点不着。手指和鼠标不一样，按钮小于 44 像素见方，误触率一下就上来了，尤其是并列排布的两个按钮，间距不够就会互相抢点击。顺手再看一眼按钮文案，写"提交"和写"获取报价单"，点的人心情是不一样的。

五、手机端那几秒，决定访客留不留得住

手机访客的耐心是以秒计的。行业里普遍把首屏加载 2.5 秒当作合格线，超过这个数，跳出率就会明显抬头，而这个数字是 Google 在 Core Web Vitals 里明确定义的 LCP 阈值。生成出来的页面，常带着几个拖后腿的习惯：图片没压缩、装饰动画一大堆、字体从外部站点加载。

有几件事当天就能做完。图片换成 WebP 格式，体积通常能砍掉一半还不掉画质；首屏那张主图加一句预加载，让它先到；首屏用不到的脚本挪到后面去加载；把外链字体换成系统字体栈。这四件事做完，加载时间常常能压下来一大截，效果比换服务器明显得多。

还有一件常被忽略的事：手机上的首屏高度。一个很高的头部导航加上一张大 banner，首屏基本就被吃光了，访客得滑一下才知道你在做什么。小屏上的首屏，把这句说清楚就够了：做什么、给谁、下一步点哪里。剩下的内容，往下滑是读者的选择，不是你推给他的负担。

速度这件事还有个反直觉的地方：不是所有优化都值得做。给一个只有一屏内容的展示页做代码分割、做懒加载、做骨架屏，收益几乎为零；反过来，一个图文很重的页面如果连图片都没压缩，其他优化再讲究也救不回来。先做收益最大的那两件，剩下的等有流量了再说。

六、上线前的技术底子，robots、canonical、sitemap

前面几处是给访客看的，这一处是给机器看的。做单个站点的时候，这层配置常年吃灰也没人发现；做站群的时候，它最容易出事，因为配置常常是从测试环境打包直接搬过去的，一行都没改。

三个高频事故，几乎每次批量上线都会撞上一个。robots.txt 里留着测试期的全站禁止抓取，蜘蛛来了被挡在门口，页面再多也白搭；canonical 还指向测试域名，等于明确告诉搜索引擎"正主在别处"；sitemap 里混进了参数链接和不可索引的页面，把本来就不多的抓取预算浪费在没用的地址上。这三个问题在浏览器里完全看不出来，只有用命令行或者抓取工具去取一次才知道。

页面数量一多，这套配置靠人一个个核，出错只是早晚的事。用 UC 建站系统做多站管理的时候，这些底子是跟着站点走的：新站部署出去，robots、canonical、sitemap 按模板一次配好，不用再登服务器翻文件；提交这一环走的是双通道推送，百度 API 与 IndexNow 同时发，省掉手动提交的来回；后台的多站看板把各站的索引量、收录趋势和异常提示放进同一张表，哪个站的收录卡住了，扫一眼就能看出来。

这套方式和手工的区别，不在功能多少，在"有没有人记得"。手工做，靠的是流程里某个人当天没忘，换个人接手就得重讲一遍；系统做，配置是随站点生成的一部分，站点在，配置就在。同样是上一批新页面，一边是逐台登录、逐个文件改、挨个平台提交，另一边是发布出去就带着配置和推送走完，一天下来差出来的不是几分钟，是能不能持续做的问题。

（参照数据：Core Web Vitals 官方阈值文档、WCAG 2.2 AA 对比度标准、各搜索引擎站长平台公开说明）

七、五处过完之后，哪些交给系统，哪些留给人

这五处检查有一个共同点：它们都不难，难的是每次都做。做一个人一个站，靠自觉能撑住；站一多，靠自觉就等于靠运气。所以真正该想清楚的，是哪几件事必须人做，哪几件事从此不用人管。

把该交出去的都交出去之后，人剩下的工作就只有两件：把内容看准，把顺序排对。这两件事没法外包，也不该外包。至于那些机械的核对，今天做一遍明天还得做一遍，真正值得投入的从来不是这种重复。

回头看这五处检查，它考验的不是技术功底，是一种纪律：在按下发布之前，愿意多花四十分钟，把屏幕拉窄、把表单填一遍、把配置文件取出来看一眼。这点耐心换回来的，是上线后不用半夜爬起来改的那份踏实。

从下一个页面开始，把这五处列成一张固定的清单，每次上线照着走一遍。走三次之后它就变成肌肉记忆了，而你手里那些页面能不能用，从此不再取决于运气。