用 AI 生成小程序页面这件事，现在的水平大致是：你把需求说清楚，它几分钟就能给你一套能跑的页面，列表、详情、表单、个人中心这些常见结构，出来得像模像样。但真把生成的页面塞进开发者工具、提交审核、发到用户手里，麻烦才开始显形：真机上排版错位、点按钮没反应、数据是假的、审核因为“功能过于简单”被驳回。
所以真正值得讨论的，不是“AI 能不能写小程序”，答案早就是能，而是它写出来的东西怎么变成能上线的页面：哪些部分放手让它做、哪些部分它做完你还得接手、接手的顺序是什么。四条省钱省时的路线，加上从生成到上线之间的几道坎，逐一摊开来看。
AI 生成页面解决的是“从 0 到能跑”，上线要求的是“从能跑到可靠”，中间隔着的那一段，才是真正花时间的地方。
一、先看清小程序页面的构成，再决定哪段交给 AI
一个小程序页面拆开是四样东西，AI 在这四样上的表现差距很大。搞混了，就会出现“生成速度飞快、上线遥遥无期”的落差感：
WXML 结构：页面的骨架，列表、卡片、表单怎么排。AI 最擅长的部分，常见结构的准确率高，改起来也直观。
WXSS 样式：尺寸、颜色、间距。AI 能快速写出七成像的版本，但细节（圆角、阴影、小屏折行）常有偏差，要靠真机调。
JS 逻辑：交互和数据。基础交互（切换、计数、表单校验）没问题；涉及接口对接、登录态、支付这类业务逻辑，它写的代码通常“看起来对，接上真数据就露馅”。
JSON 配置：导航栏、标题、页面路径。量小但最容易漏，AI 生成时经常忘了配套的配置项，导致页面跳转报错。
按这个分布，适合先交给 AI 的页面类型就很清楚了：内容展示页、列表页、详情页、简单表单页，这些页面的共性是“内容在动、结构稳定”。反过来，支付流程、多步骤业务表单、强交互的功能页，不建议让 AI 主导，因为这类页面的坑不在代码结构上，而在业务规则和边界情况里，而边界情况恰恰是 AI 最不熟悉的部分。
一个简单的判断标准：页面越接近“内容的容器”，AI 越能帮上忙；越接近“业务系统的一部分”，越需要人先想清楚逻辑再让它写。拿不准的时候，先让 AI 写展示页试水，跑通了再逐步扩大范围，比一上来啃硬骨头稳妥得多。
二、眼下有三条路线，门槛和可控性差别不小
“用 AI 做小程序页面”不是一个动作，按工具形态拆开，目前主流是三条路线：对话式生成、设计稿转页面、低代码平台加 AI 辅助。三条路线的生成速度都很快，真正的差别在生成之后：代码在谁手里、能改到什么程度、适不适合长期维护。
| 路线 | 上手门槛 | 生成之后的状态 | 更适合谁 |
|---|---|---|---|
| 对话式生成 | 会用微信开发者工具即可，不需要写代码，但要能看懂目录结构 | 代码存在本地项目里，随便改、随便加，长期可控性最高 | 打算长期迭代、后续要接自己数据源的团队 |
| 设计稿转页面 | 需要一份规范的设计稿，工具操作本身简单 | 还原度不错，但生成的样式文件常有冗余和重复，要收拾一遍 | 设计先行、对页面还原度要求高的团队 |
| 低代码加 AI | 最低，拖拽为主，AI 负责补样式和文案 | 页面跑在平台里，改得快但受平台能力限制，迁出成本高 | 快速验证想法、功能轻、不打算深度定制的场景 |
三条路线有一个共同规律：生成页面本身已经不是瓶颈，瓶颈全部集中在后半段。选路线的时候盯着“哪个生成得快”意义不大，要问的是“生成完之后，接真实数据、调真机效果、走审核流程，分别要花多少工夫”。按这个问题去评价，对话式生成和设计稿转页面的天花板更高，低代码适合先跑通验证，后期再决定要不要迁到自有代码上。
还有种务实的混合打法：用低代码平台两小时搭出页面结构给业务方看效果，确认方向没问题了，再把同一套需求交给对话式工具生成正式代码。验证用的是快，落地用的是稳，两段各取所长，比纠结“到底选哪条路线”实际得多。
三、让 AI 一次写对的前提，是把需求写成它能执行的说明书
很多人生成出来的页面“跑偏”，原因不是 AI 能力不行，而是输入太粗：一句“帮我做个门店页面”，AI 只能靠猜。它会猜你想要的模块、猜字段、猜样式，猜错的每一处，后面都要花时间改。而一份写清楚的需求说明书，能让第一次生成就接近可用，省下的恰恰是反复描述的时间。
合格的说明书不用很长，但要把这几类信息说全：页面给谁用、核心模块按什么顺序排、每个模块有哪些字段和交互、数据从哪里来、样式规范是什么、异常情况怎么处理。写成这种样子，AI 的执行准确率会明显不一样：
页面需求：门店列表页目标用户：到店消费的顾客模块顺序：搜索栏 → 城市筛选 → 门店卡片列表 → 空状态门店卡片字段：门店名 / 地址 / 距离 / 营业时间 / 拨号按钮交互规则：点卡片进详情页；点拨号调起系统电话数据来源：接口 /api/shops?city=，字段名严格按接口文档样式规范：主色 #1f6feb，圆角 16rpx，正文字号 28rpx边界情况：无数据显示空状态；加载中显示骨架屏；失败可重试技术约束：基础库 3.x；单位统一 rpx；不引入未安装的组件库输出要求：同时生成页面 JSON 配置，导航栏标题为“附近门店”这份说明书里有几处是专门给 AI 添的“约束件”，少了它们最容易出问题：单位统一写 rpx 而不是 px，避免真机上尺寸不对；明确基础库版本，避免它用你环境不支持的写法；声明不引入未安装的组件库，避免生成完一堆报错；要求连 JSON 配置一起输出，避免页面能写但跳不过去。这些约束不是技术细节的堆砌，每一条都对应一个真实的返工场景。
页面生成之后的修改也要换个方式。有人习惯说“这页重新写一遍”，结果是修好的地方又改回去了。更稳的做法是按模块提要求：只说“把第三个卡片的距离字段改成右上角显示”，改动范围小，验证也快，出问题一眼就知道是哪儿引起的。
四、生成完到能上线，中间还隔着三件人工活儿
页面在开发者工具里跑通的那一刻，进度条大概到六成。剩下的四成里，有三件事 AI 能打下手，但没法替你做决定，每一件都要在真实环境里过一遍才算数：
模拟器是理想屏，真机是千奇百怪的屏。大屏小屏、刘海屏、折叠屏挨个过：固定高度的容器改成弹性布局，底部按钮留出安全区，长标题的折行和小字号的可读性逐个调。这一轮只能在真机上做，预览和模拟器都不算数。
假数据换成真接口以后，四种状态必须全部补齐：正常、加载中、空数据、请求失败。字段对齐要显式做，接口返回的字段名和页面用的对不上的地方，在代码里写明映射关系，不要让 AI“顺手统一”，它改的时候不会告诉你动了哪里。
主包体积有硬性上限，超出就要拆包，这是个绕不过去的约束。AI 生成的页面常带一堆没用到的样式和冗余结构，图片默认不压缩，字体文件动辄几百 KB，上线前通盘清一遍，比上一版多出来几十 KB 都能感觉到加载差异。
AI 生成的图片、图标和文案不能拿来就用：图片素材的版权来源要核实或换成自有素材；文案里的“最便宜”“第一”“百分百”这类绝对化表述要清掉，这类词既有广告合规风险，也过不了平台的内容检查。素材这一关花的是核对时间，省不得。
这三件事有个共同点：全都要在真实环境里验证。开发者工具里排版完美的页面，真机上可能按钮被键盘顶飞；假数据下顺畅的列表，接上接口可能整页空白。把这三件事提前排进计划，跟页面生成放在同一周做，比“先批量生成二十个页面再统一收拾”轻得多，问题在记忆还新鲜的时候解决，返工成本最低。
五、审核这一关，AI 基本帮不了你
提审是 AI 生成页面之后的第一次真正考验。理解审核的一个好角度是：它本质上是把用户之后会遇到的体验问题提前筛一遍，功能能不能用、内容合不合规、信息收得明不明白。AI 生成的页面恰恰在这几类问题上容易中招，因为它的产出瞄准的是“结构像样”，而审核盯的是“功能完整”。驳回原因按经验可以归成四组：
类目与资质
类目选择和实际功能对不上，或者功能超出了所选类目的范围；需要资质的类目没有上传相应证件。这一组和代码无关，动手前就该确认好。
功能完整性
功能过于简单、按钮点了没反应、分享打不开、页面大部分是空壳。AI 生成的展示页如果没接数据也没绑事件，最容易撞上这一组，这也是它最典型的驳回原因。
内容与隐私
文案里有绝对化用语或误导性表述；收集用户信息但没有隐私政策说明，或声明内容和实际收集行为对不上。这两年里这一组的审查在持续收紧。
提交细节
测试账号没提供或给错了；版本说明写得含糊，审核员不知道重点看哪里；需要特定条件才能进入的页面没写清楚如何触达。信息给足，能减少很多往返。
对着这四组逐项过一遍，是提审前最值得花的半小时：类目和资质在提交前核对，功能完整性用真机全流程点一遍（包括每个按钮、每次分享、每个跳转），隐私政策补齐，测试账号和说明写清楚。审核结果没有“保证通过”这回事，但准备充分能把来回的次数压到最少，第一次就过的页面，基本都是这些问题提前处理干净的。
六、页面文案别写死，不然改一句话就要等一次审核
小程序和网站最大的运营差异在发布机制：网站改个文案刷新即生效，小程序要发新版本就得走审核，时间不完全由自己说了算。如果活动文案、价格说明、门店列表这些内容全都硬编码在页面里，等于每一次运营调整都绑上了一次版本发布，改得越勤，被流程拖得越狠。
绕开这个循环的答案是内容与结构分离：页面代码只负责取数和展示，做成稳定的模板；文案、图文、列表、配置项这些经常变的东西放进内容源，通过接口读取。这样页面结构提交一次就够了，日常的内容调整在后台完成，不涉及代码包的变更，自然不用反复走审核流程。判断标准很直接：问自己“这处内容下个月会不会变”，会变的就不该写进代码里。
这套思路在很多团队的官网运营里已经跑熟了。用 UC 建站系统管理内容的团队，文案、图文、列表本来就以结构化形式放在内容中台里，人定策略、系统执行；小程序页面直接读同一份内容源，改一次两边同步，不用在“网站后台”和“小程序后台”之间来回抄内容，也避免了两个渠道的表述对不上。
内容化配置也有它的边界：结构稳定的页面（首页、列表、详情、公告）适合模板化，改动成本几乎为零；而交互流程复杂的页面（支付、预约、多步表单），逻辑和界面咬得紧，该定制就定制，硬套模板反而会把简单的事情做复杂。分辨方法还是那句话：看这个页面的变数在内容里还是在逻辑里，变数在内容里的模板化，变数在逻辑里的保持定制。
顺着这个思路再往前一步，内容源还能解决“测试内容和正式内容混在一起”的老问题：正式发布前，先用内容源里的测试数据把页面全流程走一遍，确认无误再切换正式内容，页面的质量验证和内容的上线节奏就分开管理了，谁也不用等谁。
七、提交前把这张清单过完，能省掉大半返工
从生成第一个页面到提交审核，所有踩过的坑其实能收拢成一张清单。它的作用不是增加流程，而是把“我觉得没问题”变成“逐项验证过”，提交那一刻心里有底：
- 真机至少过两台不同尺寸的机型，小屏重点看底部按钮和折行
- 四种数据状态（正常、加载中、空、失败）在真机上都有对应页面
- 每个按钮、每个跳转、每条分享路径实际点一遍，不留死链
- 隐私政策与实际的用户信息收集行为逐条对得上
- 类目、资质和实际功能相互匹配，不含超出范围的功能
- 测试账号可正常登录，版本说明写清审核员该重点看什么
- 主包体积在限制之内，图片已压缩，无用样式和文件已清理
- 文案清掉了绝对化用语和误导表述，图片素材来源明确
一句话结论：AI 把页面从零拉到能跑很快，从能跑到用户手里这后半段，考验的还是那几件笨功夫：真机、真数据、真内容、真审核。
把两段时间放在一起对比会很有意思：生成页面用掉的通常是半个下午，而适配、接数据、清素材、过审核用掉的是一个下午加若干个晚上。前者让你兴奋，后者让你踏实，小程序能不能留住用户，取决于后者的完成度，而不是前者的速度。
如果准备动手，建议从最小的闭环开始：先做首页、列表、详情三个页面，把生成、适配、接数据、提审的完整流程走通一遍，再回头批量做其余页面。走过一遍之后你会发现，后面每个页面的活儿都轻了，因为真正难的部分从来不是页面本身，而是这套跑顺了的工序。
