现在拿到一份网站源码已经不需要自己从零敲了。跟 AI 描述一遍需求，整站的前后端代码几分钟就出来了，表单、列表、详情页一样不少，本地跑起来也挺像回事。问题一般出现在下一步：有人把这份代码直接传服务器，收了半年一点动静没有；也有人改了两行就发现改不动，结构乱成一团，最后整套推倒重做。同样的 AI，产出的码能不能用，差别不在工具，在交付之前有没有过三关。
三关是这三关：语义结构对不对，抓取端能不能看懂；资源加载重不重，首屏速度撑不撑得住；二次修改贵不贵，明天想改个栏目要不要重来。
这三关不是技术洁癖，每一关都对着具体的损失：第一关不过，页面在搜索结果里拿不到像样的呈现；第二关不过，访客等三秒就走了；第三关不过，团队每次改动都要找当初生成它的那个人。下面就按这三关展开，最后给一份完整的上线前审查清单。
一、先分清手里的源码是哪一种来路
同样是"AI 生成的网站源码"，来路不同，质量基线和要补的功课相差很远。常见的有三种：在对话里直接生成整站 HTML 的项目，让 AI 编辑器按需求写代码，以及在现成 CMS 上让 AI 生成主题模板。前两种拼的是生成时的提示质量，第三种拼的是对模板规范的熟悉度，混在一起讨论容易得出"AI 生成的代码没法用"这种一刀切的结论。
| 来路 | 产出形态 | 适合的场景 | 上手前要注意的 |
|---|---|---|---|
| 对话生成整站 | 一套可导出的 HTML/CSS/JS 文件，页面齐全、能直接部署 | 单页站、展示型小站、活动页，需求简单明确的场合 | 内容大多写死在页面里，后期批量更新要靠人挨个改 |
| AI 编辑器写代码 | 按模块产出的组件与页面代码，带目录结构，可迭代改造 | 需要持续迭代的业务站、有开发力量、想长期维护的项目 | 不指定规则时，同一类组件会被反复重写，越攒越乱 |
| CMS 上生成主题 | 符合模板规范的主题文件，数据与展示分离，后台可管内容 | 内容量会持续增长的企业站、资讯站、多站管理场景 | 需要给出明确的模板结构与命名要求，否则生成物对不上规范 |
三种来路在开工前有共同的准备工作，做与不做，产出质量差别很大：
- 先把站点要什么说清楚：页面清单、每页必备模块、数据从哪来，越具体生成物越接近成品
- 先定设计变量：主色、字号阶梯、间距刻度，让 AI 引用变量而不是随手写数值
- 明确技术约束：要不要结构化数据、要不要服务端渲染、图片和字体怎么处理
- 约定命名与目录：组件放哪、样式放哪、公共部分怎么抽，避免生成出一坨散文件
这四条看着像要求 AI，其实是逼自己先把需求想清楚。生成质量的上限由需求描述的清晰度决定，AI 只是把这个上限快速实现出来。需求描述里含糊的部分，生成物里都会变成需要返工的地方。
二、第一关：语义结构，抓取端看懂了多少
AI 生成代码有一个高度一致的毛病：视觉上挑不出错，结构上一塌糊涂。按钮是 div 加点击事件，列表是 div 套 div，标题层级按字号随手给，全页可能找不出一个 h1，或者一屏里冒出四个 h1。浏览器渲染出来没差别，搜索引擎和读屏工具拿到的是一份没有骨架的文档，看不出哪句是标题、哪块是正文、哪个是导航。
修正的方向不是把页面重写一遍，而是给 AI 明确一次结构规范，让它按规范重新生成组件层。下面这两段对比很典型，把要求写进提示词之后，产出就是两个样子：
<!-- AI 默认产出：视觉能跑，结构为空 --><div class="top"><div class="logo">公司名</div><div class="nav"><div onclick="go('/a')">产品</div></div></div><div class="main"><div class="title-big">工业泵选型要点</div><div class="text">正文段落……</div><div class="img-box"><img src="a.png"></div></div><!-- 加上结构要求之后：语义完整，机器可解析 --><header><a href="/" class="logo" aria-label="返回首页">公司名</a><nav aria-label="主导航"><ul><li><a href="/products/">产品</a></li></ul></nav></header><main><article><h1>工业泵选型要点</h1><p>正文段落……</p><figure><img src="a.webp" width="960" height="540" alt="工业泵安装示意图"></figure></article></main>除了标签本身，结构化数据也是最容易被漏掉的一块。企业站加一段组织信息与产品信息，资讯类页面加文章标记，这些在 AI 的默认产出里几乎不会主动出现，但它对搜索结果的呈现形式影响直接。让 AI 按页面类型补上对应的 JSON-LD，比上线之后回头补救省事得多。
还有一个隐蔽的问题：不少 AI 生成的站把正文放进客户端渲染的组件里，源码里只有一个空容器，内容靠脚本加载后才出现。人在浏览器里看得到，抓取端拿到的却是空白。生成时明确要求服务端直出或静态输出，正文以 HTML 形式存在页面里，这一条比任何优化都靠前。
三、第二关：资源加载，AI 生成的站为什么更容易慢
生成一份漂亮的页面时，AI 的思路是先保证"一定好看"：图标直接引整套图标库，样式引完整的框架文件，字体把家族里所有字重都写进引入语句，配图用占位站的大图。单看每一处都有理由，叠起来就成了负担，首屏加载时间被这些"以防万一"的依赖拖长。
整包依赖
按需换整包
图标与样式改按需引入，只带上真正用到的部分
图片尺寸
原图直传是常态
按实际展示尺寸输出，统一转新一代格式，补上宽高属性
字体引入
整族字重全收
只保留实际用到的字重，正文优先用系统字体兜底
这几项的处理方式都很成熟，关键是在生成阶段就写进约束，别等上线后再回头压缩。"接受生成物默认状态"是很多站慢下来的起点：AI 没有成本概念，它不会主动帮你省请求，省请求是使用者的活。
生成物里常带着对公共 CDN 和第三方字体服务的引用，这些地址在部分网络环境下加载缓慢甚至失败，页面会出现样式缺失或长时间空白。上线前把所有外部资源地址过一遍，能落到自己服务器上的就落下来，是稳定性上性价比最高的一步。
四、第三关：明天想改一处，要动几个文件
前两关决定站点上线后的样子，第三关决定上线之后的日子好不好过。AI 生成代码最典型的特征是把一切写死：公司名散在二十个页面里，主色以十六进制裸值出现在上百处，导航链接每个页面各写一份，改一次联系电话要全局搜索替换。刚上线时看不出问题，改动一多，维护成本就露出来了。
改不动的样子
同一段页头代码复制在每个页面里；主色、字号、圆角都是裸值；新增一个栏目要新建一整套页面再从旧页面复制改动；改完一处忘了另一处，页面上出现两种版本。
改得动的样子
公共部分抽成模板或组件，一处改处处生效；颜色、字号、间距写成变量；新增栏目复用既有版式模块，只补内容；改一个数值，全站风格同步更新。
判断一份源码落在哪一边，有三个随手就能做的测试，拿去问生成它的 AI 也行，自己改一遍也行：把主色换掉，看要在多少个文件里动手；新增一个内容相同的页面，看要复制粘贴多少次；把全站的公司名换一遍，看是不是一次全局修改就能完成。三个测试里有任意一个答案超过"一处"，第三关就没过，需要先做结构整理再谈上线。
整理的成本通常比想象中低。让 AI 把公共部分抽出来、把裸值换成变量、把重复页面模板化，是它最擅长的重构任务，前提是你先做一轮如上所述的测试，把要改的地方找全，一次交代给它，而不是让它自觉。改完之后再测一遍，三个问题的答案都会变成一处。
"源码值不值钱，看的不是它跑得多顺，是它下次被改动时有多便宜。"
五、上线前把这份清单过一遍，七项都不用花太久
三关拆开讲了各自的判断方法，落到执行层面，下面这七项就是一份可以照着走的审查清单。每项对应一个具体的检查动作和常见的不合格表现，全部过完通常用不了一两个小时，比上线之后发现问题回头修便宜太多。
| 检查项 | 怎么查 | 不合格的典型表现 |
|---|---|---|
| 标题层级 | 看每个页面 h1 是否唯一、h2 是否按内容分段 | 整页没有 h1，或一屏出现四个 h1；标题按字号随手写 |
| 正文可见性 | 禁用脚本后打开页面，看正文是否还在 | 源码里只有空容器，正文全靠脚本填充 |
| 结构化数据 | 按页面类型核对是否补了对应的标记 | 资讯页没有文章标记，企业站没有组织信息 |
| 图片处理 | 抽查首屏图片的实际体积与输出尺寸 | 展示宽 800 像素却传了 4000 像素的原图 |
| 依赖与字体 | 统计引入的库是否整套加载，字重是否全量 | 为几个图标引入整套图标库，字体引入五个字重 |
| 外部资源 | 把第三方地址列出来逐个访问一遍 | 依赖公共 CDN 和外部字体服务，加载失败页面缺样式 |
| 可修改性 | 做换主色、加页面、改站名三个测试 | 改动散落在多个文件，靠全局搜索替换硬撑 |
这七项要不要每次都人工过？
第一次完整过一遍，之后把其中的机器可查项写成脚本或交给 AI 定期扫：标题层级、正文可见性、图片体积、依赖大小这几项都可以自动出报告，人工只需要关注结构化数据和可修改性这类需要判断的项目。站点数量多的时候，这一步不做，后面每一次改动都在还债。
六、一套审核规则，管住几十个站
单份源码按前面的方法过三关不算难，麻烦的是站点多起来之后。二十个站，每个站的源码都要审结构、查资源、测改动成本，人工逐个过一遍要按周计；更麻烦的是每次 AI 重新生成或大改之后，之前审过的结论就作废了，又要重来。可行的办法是把审查本身也变成流水线，规则定一次，机器执行，人只看报告和例外。
标题层级、正文可见性、图片尺寸上限、依赖白名单，逐条写成明文标准
新站上线前、老站大改后各扫一轮，按站列出不合格项与位置
把同类问题汇总成一批重构任务交给 AI 执行，改完复扫确认闭合
每次生成、改版之后自动触发检查，防止新代码把老问题带回来
用 UC 建站系统搭这类批量站点，这几步的衔接是现成的：站点基于统一的内容中台生成，模板层与内容层分开，检查规则在模板层配置一次、对名下所有站生效；各站保持独立部署、独立模板，一个站的重构不会牵连其他站；页面 HTML 直出，审查脚本检查的正文可见性、标题层级这些项，扫出来的结果就是抓取端看到的结果，不用额外模拟；发现的问题在多站看板里按站、按类型汇总，改完一处能在同一屏里确认所有站的复扫结果。系统负责的是让规则稳定地跑在每个站上，规则本身写什么、判断例外怎么处理，仍然由人决定。
这套流水线还有一层隐性收益：规则写得越明确，后续交给 AI 的生成任务越省心。生成、审查、重构三段用的是同一份标准，AI 每次拿到的约束一致，产出就不会一代比一代走样。很多批量站的问题不是某次生成失败，而是每轮生成的标准都在变，攒到后面没法收拾。
七、许可和安全，AI 生成代码里最少被看的两页
三关之外还有两件事容易被跳过，而且跳过之后的问题比前几关更麻烦。一件是依赖的许可：AI 生成代码时习惯引入外部库和素材，这些资源的授权范围各不相同，有的要求保留署名，有的不允许商用，站点对外经营之前需要把清单理一遍。理的动作不复杂，把所有依赖和素材来源列出来，逐项确认授权即可，难的是很多人根本没意识到清单存在。
另一件是安全。生成物里的表单处理、后台入口、文件上传、接口调用这几处，AI 往往给出"能跑通"的最低版本：接口没有频率限制、表单没有校验、示例用的默认密钥没改、上传没有类型检查。这些在演示环境无人在意，公开访问之后就是敞开的门。上线前的固定动作是逐个过一遍这几处，把默认值换掉、把校验补上、把不必要的入口关掉。
批量站点在这两件事上的风险是放大的：一份带默认密钥的代码被复制到几十个站，等于同一把钥匙开了几十扇门；一套许可存疑的素材铺满全部站点，涉及的范围也会跟着站点数量翻倍。生成阶段就把依赖清单和安全检查加进规则，比事后逐站排查便宜得多。
站点规模上来之后，这两件事更适合交给系统盯着：用 UC 建站系统管理多站时，各站独立部署、独立备案，模板与后台相互隔离，一个站出问题不会横向波及；依赖清单和检查项挂在模板层，新站生成时自动带上；多站看板把各站的异常与改动集中呈现，哪一站的模板版本旧了、哪一站的检查项没闭合，不用逐站登录确认。系统解决的是"盯得住"的问题，许可判断和安全决策仍然需要人来拍板，这两件事没有工具能替你负责。
速记五条：
· 生成前先定需求、设计变量、技术约束与命名规范，产出质量的天花板在这一步就定了
· 第一关查语义结构：标题层级、语义标签、结构化数据、正文直出，四项过不了不上线
· 第二关查资源加载：依赖按需、图片按实际尺寸输出、字体只留用到的字重
· 第三关做三个测试：换主色、加页面、改站名，答案散在多处就先重构再上线
· 上线前补两件事：依赖许可清单过一遍，默认密钥与表单校验挨个换掉
用 AI 生成网站源码，眼下最大的误区是把"生成得快"当成"可以少做事"。生成省下的是敲代码的时间，结构设计、约束定义、上线审查这几步一步都省不掉，只是从写代码变成了写规则和做判断。想明白这一点，AI 生成的源码和团队手写的源码在使用上没有本质区别。
真要把这套流程用起来，从下一份生成物开始就行：先要需求、再定约束、生成后过三关、上线前过清单。第一次做完可能需要半天，第二次会快很多，等到规则和方法熟了，生成一份能直接上线的源码，就是一件按部就班的事。三关和清单都在上面了，剩下的交给手上的项目去验证。
"AI 把代码写出来的速度不稀缺，稀缺的是让这份代码值得被长期使用的判断。"
