把一版 AI 生成的小程序提交审核，被驳回的理由通常不是"代码写错了"。更常见的两种是：审核员在页面上找不到入口，能走到你在服务类目里申报的那项服务；或者构建产物已经贴着 2M 主包上限，为了塞进去被迫裁掉了功能。前者读的是规则，后者算的是字节。
这两件事都不会因为模型变强而消失。它们是平台层面的固定约束，所以更该被当成生成阶段的输入条件，而不是提交之后的返工项。
一、两个不随模型进化的硬约束
先确认口径。这两条都写在微信官方文档里，改版频率远低于模型能力的迭代速度。
主包 2M。 官方《分包加载》文档写得很直接：
整个小程序所有分包大小不超过 30M（服务商代开发的小程序不超过 20M）；单个分包/主包大小不能超过 2M。
同一页还说，分包的价值除了控制体积，还包括"优化小程序首次启动的下载时间，以及在多团队共同开发时可以更好的解耦协作"。换句话说，分包不是超限之后的补救手段，它本来就是构建结构的一部分。
审核看的是"用户能不能走到服务"。 《常见拒绝情形》里对类目与页面关系的描述是硬要求，不是建议：
小程序所提供的所有服务类目功能，必须在小程序首页得到体现，即在小程序首页必须能直达或者经过 2 次点击到达所有本文档 2（服务类目审核）中提交的服务类目页面。
把这两条并排放，能看出一个常被忽略的事实：体积约束在构建期生效，审核约束在功能结构期生效，两者都早于"写代码"这一步。AI 在写代码环节的能力再强，也补不上前面两步的空缺。
| 约束 | 官方口径 | 决策发生在 | AI 能否自行感知 |
|---|---|---|---|
| 主包 / 单分包体积 | 不超过 2M，全部分包合计 ≤ 30M（服务商代开发 ≤ 20M） | 构建配置与目录结构 | 不能，模型看不到构建产物 |
| 类目功能首页可达 | 首页直达或 ≤ 2 次点击到达所有已申报类目页面 | 页面地图与信息架构 | 不能，除非你把页面地图贴给它 |
| 功能具备使用价值 | 不得过于简单，如只有一个页面、只有一个按钮 | 需求边界定义 | 不能，模型倾向交付最小可跑样例 |
二、包体积：AI 生成代码为什么系统性超预算
模型看不到你的构建产物。它看到的是被贴进上下文的那几个文件，于是会判断"这个方案能跑通"，但不会去算这条 import 链最终打进主包多少字节。
结果是超预算的方式高度重复。下面五种我们在 code review 里反复见到的形态，基本可以当成检查表用：
| AI 的常见产物 | 体积后果 | 处置方式 |
|---|---|---|
| 一次性 import 整个 UI 组件库 | 全量样式与脚本进主包 | 按需引入；组件演示页放独立分包 |
| 图片转 base64 内联在 WXML/JS 里 | 字节直接计入代码包 | 上传 CDN，只保留 URL 与尺寸 |
| 工具库整包引入（lodash、i18n 全量 locale） | 体积随依赖树一起放大 | 单函数引入；locale 按需加载 |
| 所有新建页面默认落主包 | 主包随迭代线性增长 | 先建分包骨架，新页面默认进分包 |
| 图表 / 富文本 / 编辑器类重依赖 | 几百 KB 级，一次就吃掉大半预算 | 独立分包 + 分包预下载 |
关于余量，这里给的是工程建议而非官方数字：不要把主包做到 2M 再想下一步。主包预算是会涨的——埋点、分享卡片、登录态、审核期间临时加的说明页，都要占位。留出余量的目的不是怕超限，而是避免在下一次小需求时被迫重构目录。
三、审核：三类高频驳回，条款其实都可读
审核规则常被当成"玄学"，但真正卡住项目的条款并不多，而且写得相当具体。以下三类在 AI 主导生成的代码里出现频率最高。
1. 申报了类目，首页却走不到
这是第一条约束的直接后果。典型场景是 AI 按"页面清单"逐个生成页面，却没有生成入口聚合——详情页、下单页、客服页都做好了，首页只剩一个 Banner 和一个按钮。
审核员打开首页，两次点击内找不到"在线问诊"或"预约到店"的入口，就判定类目功能未体现。代码质量没问题，结构不合格。这类结构返工的处理方式，我们在小程序 AIcoding 工程落地数据里按指标拆解过。
2. 功能过于简单
官方条款举的例子很短：「只有一个页面，只有一个按钮」。AI 在需求描述含糊时，天然倾向交付能跑通的最小版本，而最小版本恰好落在这条线上。
应对方式不是"多加几个页面"，而是在需求阶段就把可验收的功能点写死。页面数量不解决问题，功能闭环才解决。
3. 诱导分享与诱导关注
官方对诱导类行为的定义覆盖很宽：要求用户分享、添加、关注后才可操作，或用利益诱惑、夸张言语引导分享，都会被拒绝。AI 生成的增长模块很容易踩这条——"分享给 3 位好友解锁完整报告"是它很喜欢的写法。
| 驳回类型 | 对应条款口径 | 生成期该加的约束 | 提交前检查动作 |
|---|---|---|---|
| 类目功能不可达 | 首页直达或 ≤ 2 次点击到达所有已申报类目页面 | 先出页面地图，再生成页面 | 按类目逐条数点击层级 |
| 功能过于简单 | 不得只有一个页面、一个按钮 | 需求里写清功能闭环与角色 | 走一遍完整业务闭环 |
| 诱导分享 / 关注 | 分享、关注后方可操作即被拒 | 禁止生成"分享解锁"类门禁 | 搜文案关键词与按钮条件 |
四、三条闸门：把约束前置到生成阶段
顺序比工具重要。把上面三件事按时间排开，就是一条可以固定下来的流水线。
- 闸门一 · 定类目再动页面。 先确认服务类目与所需资质，再画页面地图，标出每个类目页面在首页的点击层级。这一步做完之前不生成任何页面。
- 闸门二 · 先建包结构再写功能。 建项目时就把主包只留启动页、TabBar 和公共资源，其余按业务域划成子包。新页面的默认归位规则写进项目约定，交给 AI 的上下文里带上这份约定。
- 闸门三 · 提交前跑双清单。 一份体积清单（主包实际大小、最大的三个依赖、图片是否走 CDN），一份审核清单（类目页面可达性、功能闭环、诱导文案）。两份都过再点提交。
值得单独提一句：AI 生成代码进入工程体系这件事，本身就有共识做法——按外部 PR 同等对待，走同一套 review、测试与 owner 审批，不设免检通道。小程序的特殊之处只在于，它的"外部 PR"多了两道机器无法自动判定的关卡：平台规则和构建体积。
五、什么情况下别让 AIcoding 主导
有明确的边界，说出来比藏着有用。
强监管类目。 医疗、金融、教育等类目涉及资质前置审批，类目选错或资质缺失，代码写得再对也过不了审。这类项目的第一个决策点在人，不在模型。
重度内容安全的场景。 用户生成内容、社区、直播互动，需要内容安全策略与人工处置流程。规则条款分散且会更新，依赖模型凭记忆生成策略并不可靠。
已有历史包袱的老项目。 主包早已贴线、目录结构混乱，此时让 AI 继续往里加页面，是在放大既有债务。先做包结构治理，再谈提速。
反过来，业务闭环清晰、类目无前置审批、页面结构可以重新规划的项目，AIcoding 的收益最直接——因为约束能被明确写成生成条件，而不是靠事后补救。
六、常见问题
AI 写的小程序是不是更容易被驳回？
驳回条款本身和 AI 无关，但 AI 生成的默认结构与高频驳回点高度重合：页面清单式生成导致入口缺失，最小可跑版本导致功能过简，增长模块偏好诱导分享。把这三条写进生成约束，驳回率会明显下降。
主包 2M 到底够不够用？
对结构合理的小程序够用。启动页、TabBar 与公共资源通常不需要吃满 2M，真正的压力来自把重依赖和所有页面都堆进主包。先分包，再评估够不够。
拆了分包会不会影响审核？
不会，分包是官方支持的构建方式，文档明确它用于优化首次启动下载时间与多团队解耦。跨端项目在包结构与审核差异上的对照，可以看鸿蒙端 AIcoding 落地那一篇。需要注意的不是"要不要分包"，而是分包之后每个类目页面仍要满足首页可达性要求。
已经超了 2M 怎么办？
按收益排序处理：图片与静态资源先挪到 CDN，这是最大的一块；其次是重依赖改独立分包并配预下载；最后才是拆页面。直接删功能是最后手段，因为删掉的往往正是审核要看的功能闭环。
需要一份可执行的落地检查表
约束写清楚之后，剩下的是谁在什么节点检查、检查完留下什么证据。优码云在做小程序与 AIcoding 落地时，会把类目页面地图、分包结构与提交前双清单作为交付物的一部分固定下来，而不是留在某个人的经验里。如果你的项目正卡在审核或体积上，可以看看我们已交付的案例，或直接联系我们聊具体卡点。
参考
- 微信开放文档 · 分包加载（含使用分包、独立分包、分包预下载，最后编辑于 2026-06-16）
- 微信开放文档 · 分包预下载
- 微信小程序平台常见拒绝情形（最后编辑于 2026-03-25）