karuo-ai/02_卡人（水）/水桥_平台对接/小程序审核闭环/SKILL.md

name, description

name	description
小程序审核闭环	微信小程序审核闭环。用于提交审核、查询审核状态、查看拒审详情、保存详情截图、关联项目需求、修复代码与配置、验证审核模式、重新上传提审并沉淀审核经验；触发词包括小程序过审、审核不通过、拒审详情、重新提审、上传小程序、审核模式。

小程序审核闭环

把“上传成功”和“审核通过”分开验收。持续执行到微信后台出现真实终态，并把每次拒审转成项目需求和可复用经验。

固定执行链

1. 定位项目：确认项目根目录、AppID、版本号、需求主文档、迭代记录和证据目录。
2. 凭证预检：优先读取项目安全环境文件；缺少 WECHAT_APPSECRET 时，从同项目且 AppID 匹配的本地配置补齐到 Git 忽略、权限 600 的 .env，调用官方 token 接口验证，不输出密钥。
3. 上传代码：优先官方 API/CLI 与 miniprogram-ci；保存回执。上传仅代表开发版本已到后台。
4. 提交审核：官方 API 覆盖时调用 API；遇第三方平台 86000、网页独有表单或状态详情时，默认使用 ATLAS 补齐。
5. 状态回读：在版本管理中记录版本、提交时间、审核状态和审核 ID。仅“审核中”“审核通过”“审核不通过”等后台真实状态可作为结果。
6. 拒审处理：出现审核不通过时立即进入“拒审详情闭环”，不得只记录一句原因。
7. 通过后发布：审核通过后按项目发布要求继续发布，并回读线上版本；用户只要求提审时停在审核终态。

标准主路径（以后默认走这一条）

项目识别 → 拒审详情/历史检查 → 审核模式预检 → 代码与后台双层修复 → 合同测试 → 官方 CLI 上传 → 公众平台开发版本回读 → ATLAS 填表提审 → 审核中回读 → 通过后发布/拒审后再循环

每个节点必须有可核验产物：

节点	必须产物
项目识别	根目录、AppID、目标版本、需求文档路径
拒审检查	原文、审核 ID、截图、时间、命中页面
审核模式	envVersion、appVersion、后台开关、默认兜底策略
修复验证	变更文件、合同测试、语法检查、直接路由检查
上传	官方 CLI/CI 输出、版本号、说明、有效包体大小
开发版回读	微信后台真实开发版本、上传时间、备注
提审	审核说明、隐私项、接口提示处理、提交成功页
状态回读	审核中/通过/不通过、提交时间、证据截图

审核模式硬规则

1. 先关后开（fail-closed）：启动时先按审核态隐藏，只有后台配置成功返回且明确允许后才恢复；网络失败、缓存异常和配置未决时继续隐藏。
2. 不可只认 trial：微信代码审核可能从 release 链路运行。审核判断至少同时考虑 envVersion + appVersion + 后台目标版本，禁止写死“release 永远完整功能”。
3. 版本匹配优先：提审版本使用 version_match/等价作用域，目标版本必须与上传版本完全一致；上传前、提审前各回读一次。
4. 五层隐藏：导航/卡片、组件状态、页面路由、深链直达、接口请求全部关闭。旧页面直接重定向到匿名可浏览首页，不加载敏感数据。
5. 审核员先浏览：首页、目录、文章阅读必须匿名可用；登录弹窗不在冷启动、首页、目录或普通阅读时自动出现。
6. 正式版恢复要显式：开发环境可显式展示完整功能；正式恢复必须由已审核版本、后台配置和回归测试共同控制，不能靠时间、人员或隐蔽手势。

审核前逐项执行 references/审核前检查清单.md。

拒审详情闭环

1. 在 ATLAS 打开审核版本的“详情”，展开全部失败原因、修改指引和平台截图。
2. 对每条原因采集：原文、规则/类目、命中页面、平台截图、提交版本、审核 ID、时间。
3. 将截图复制到项目需求目录，例如： 开发文档/1、需求/修改/images/小程序审核/YYYYMMDD_v版本/。
4. 运行 scripts/追加审核案例.py，把结构化案例追加到需求主文档或独立迭代文档。
5. 拆成“页面表现 → 技术根因 → 代码/后台配置 → 验证项 → 回归风险”，每条设置负责人、状态和证据。
6. 修复前检查 /Users/karuo/Documents/开发/4、模块/ 与项目现有审核模块，优先复用；审核包和正式包使用明确配置作用域，禁止依赖时间、审核员身份或不可复现条件。
7. 执行静态检查、合同测试、真机/体验版路径检查；拒审页面、深链和缓存命中都必须覆盖。
8. 升级版本号，重新上传、提审、回读状态；若再次拒审，新增案例而不是覆盖旧记录。

需求文档最小字段

• 审核版本、AppID、审核 ID、提交/失败时间
• 平台拒审原文和修改指引
• 截图相对路径及图片说明
• 所属项目、需求编号、受影响端和页面路径
• 根因、修复方案、变更文件、后台配置
• 自动化测试、体验版验证、正式版回归
• 重新上传版本、提交回执、审核终态

模板见 assets/审核案例模板.md。既有经验与规则映射见 references/审核经验库.md。

审核模式验收基线

• 首页先展示可浏览的核心内容，不以登录授权作为首屏前置。
• 审核配置隐藏的入口同时覆盖 UI、路由、深链、接口请求和残留弹窗状态。
• 登录协议由用户主动选择；正式登录流程保留协议与隐私政策展示。
• 用户头像、昵称、文本、图片等发布链路接入内容安全检查并记录结果。
• 支付、虚拟商品、AI/深度合成、UGC/社交能力与所选类目、资质及平台能力保持一致。
• 审核包隐藏某能力时，正式版本的恢复条件必须可配置、可测试、可追踪。

ATLAS 与官方接口分工

• 官方 API/CLI：凭证校验、类目预检、上传、可用的审核/发布接口。
• ATLAS：登录后台、填写网页表单、查看拒审详情、下载/截图平台证据、处理 86000 后的网页链路、回读真实状态。
• 验证码、扫码登录、动态口令出现时停在该页面，用户完成后继续后续步骤。

上传与提审操作规范

1. 上传优先顺序：miniprogram-ci + 私钥 → 微信开发者工具 CLI → 微信开发者工具 GUI。
2. CLI 必须明确传入项目根、版本、备注和端口；回执至少校验包体 size.total > 0。
3. CLI/GUI 显示“上传成功”后，还要在公众平台版本管理页确认对应版本、开发者、上传时间和备注；否则仍算上传待核验。
4. 提审表单使用与审核态一致的功能描述；只描述审核员实际可见且完整可运行的能力。
5. 对平台的安全测试、地理位置接口、隐私接口等提示逐项读取并按真实代码选择；选择后重新获取页面状态再点下一步，避免网页重绘造成旧元素失效。
6. 提交成功页出现后点击确定并回到版本管理；只有看到目标版本进入“审核中”且有提交时间，才报告提审完成。

卡若创业派对基准案例

• v1.8.9 拒审暴露四类能力：虚拟产品支付、提现、陌生人/熟人互动交友、播放/观看内容。
• 根因不是单个按钮残留，而是旧逻辑将 release 强制恢复完整功能，审核模式只覆盖 trial。
• v1.8.10 修复为版本匹配审核态，并对支付、提现、找伙伴、动态/UGC、直播/超级个体、登录弹窗、AI 分发做五层隐藏。
• 上传回执包体 1,992,750 bytes；公众平台回读开发版本 1.8.10；2026-07-19 00:50:28 进入“审核中”。
• 该案例的可复用结论：微信审核环境判断以真实后台版本和配置为准，绝不假设审核只走 trial。

完成条件

同时满足才报告闭环完成：需求文档已关联、图片可打开、修复有验证证据、新版本上传回执存在、后台状态已回读。审核通过后还需按用户目标确认是否发布线上。