小程序上线前两周时间表

代码写完不等于能上线。审核驳回最常见的原因，往往出在上线前两周本该做完却被挤掉的非开发项。下面按倒计时排一张可执行表。

T-14 到 T-10：主体与类目冻结

• 确认账号主体与营业执照一致；
• 类目一次选准，涉及资质的提前拍照上传；
• 若有支付、定位、用户信息等接口，对照权限清单勾选；
• 把「会改类目」的讨论在这一周结束，后面再改极易拖审。

类目选错导致整包打回，比改两页界面更耗时间。涉及多类目时，先上最小可过审集合，再迭代加类目，通常比一次求全更稳。

T-9 到 T-7：隐私与用户协议落地

审核会抽查隐私政策与实际收集行为是否一致。请完成：

1. 隐私政策页面可在小程序内打开；
2. 收集的字段与声明一致（手机号、位置、相册等）；
3. 首次触发敏感权限前有说明文案；
4. 注销或删除个人信息的路径写清楚。

不要用「稍后补充」的占位链接过审——抽查到直接驳回。政策文案建议法务或负责人过一眼，避免产品与法务各写各的。

T-6 到 T-4：体验版与测试账号

• 上传体验版，拉齐产品、运营、客服三方点一遍主路径；
• 准备审核用测试账号与密码，写在备注里；
• 主路径不能依赖「只有线上才有的数据」；
• 空态、失败态、无网络提示都要能演示。

主路径检查示例

• 登录 → 浏览 → 下单或预约 → 支付或提交 → 查看结果；
• 中途退出再进入，状态是否恢复；
• 权限拒绝后是否有降级方案；
• 客服入口是否可找到（若你承诺了人工支持）。

T-3 到 T-2：提审材料与版本说明

写清楚本次版本解决什么问题，避免审核员猜。建议包含：

• 核心功能列表（三到五条）；
• 测试账号；
• 特殊类目的补充说明；
• 若有尚未对用户开放的入口，说明如何隐藏或灰显。

T-1 到 T0：冻结与回滚预案

• 停止再合入大功能；
• 确认服务器与接口监控；
• 准备审核驳回后的修改窗口（按驳回项逐条改，不要顺手加需求）；
• 通过后的发布按钮谁点、何时点，提前指定一人。

按这张两周表走，多数「代码好了却过不了审」可以变成可预期的日历事件，而不是上线当天的突发事件。若你们并行多个端，小程序日历应单独拉出来，不要被 App 或官网排期淹没。

落地时的协作建议

把本文的检查项复制到协作文档里，按负责人拆分，比只在群里口头提醒更有效。建议固定三个角色：

• 产品或业务负责人：确认范围与验收口径；
• 技术负责人：确认实现与监控；
• 运营或内容负责人：确认文案、素材与对外说明。

每周只开一次短会对齐进度，会比每天追问更省时间。遇到驳回或延期，先回到清单定位是哪一类问题，再决定是否加资源，避免情绪化加需求。

记录模板（可直接复制）

1. 日期与环境（测试 / 预发 / 生产）；
2. 现象：一句话描述用户可见结果；
3. 已排除项：打勾列出；
4. 下一步：唯一负责人 + 截止时间；
5. 验证方式：怎样算修复完成。

坚持用同一模板两到三周，团队会形成共同语言，后续类似问题处理会快很多。也方便事后复盘：到底是清单不全，还是执行跳步。

什么时候可以收工

满足下面四条再宣布「这一阶段完成」：

• 清单上的高优先级项全部有结论（通过 / 不适用 / 延期并写明原因）；
• 主路径在目标环境可完整走通；
• 对外文案与实际行为一致；
• 有人能在五分钟内讲清回滚或降级办法。

收工不等于永远不再改，而是当前风险已降到可接受，并把剩余项明确排期。这样既不会无限拖延上线，也不会在「差不多就行」里埋雷。

落地时的协作建议

把本文的检查项复制到协作文档里，按负责人拆分，比只在群里口头提醒更有效。建议固定三个角色：

• 产品或业务负责人：确认范围与验收口径；
• 技术负责人：确认实现与监控；
• 运营或内容负责人：确认文案、素材与对外说明。

每周只开一次短会对齐进度，会比每天追问更省时间。遇到驳回或延期，先回到清单定位是哪一类问题，再决定是否加资源，避免情绪化加需求。

记录模板（可直接复制）

1. 日期与环境（测试 / 预发 / 生产）；
2. 现象：一句话描述用户可见结果；
3. 已排除项：打勾列出；
4. 下一步：唯一负责人 + 截止时间；
5. 验证方式：怎样算修复完成。

坚持用同一模板两到三周，团队会形成共同语言，后续类似问题处理会快很多。也方便事后复盘：到底是清单不全，还是执行跳步。

什么时候可以收工

满足下面四条再宣布「这一阶段完成」：

• 清单上的高优先级项全部有结论（通过 / 不适用 / 延期并写明原因）；
• 主路径在目标环境可完整走通；
• 对外文案与实际行为一致；
• 有人能在五分钟内讲清回滚或降级办法。

收工不等于永远不再改，而是当前风险已降到可接受，并把剩余项明确排期。这样既不会无限拖延上线，也不会在「差不多就行」里埋雷。