一家做汽车转向节的零部件厂，车间里三百二十台设备，每月报修单在两百一十到两百六十条之间。他们的设备报修小程序在提审环节连着栽了两次：第一次等了三天被驳回，改完重提又等两天，第二次的驳回理由和第一次毫无关系。项目组当时的状态是每次补上一个洞，补完不知道还有几个。

第二次驳回之后，承接这个项目的APP开发公司把送审动作从提审当天临时凑材料，改成了一份固定清单，共十一项，每一项都对应一个真实发生过的驳回理由。此后同类工业系统的五个项目里，四个一次通过，剩下一个卡在类目变更上多花了两天。下面按提审当天的核对顺序把这十一条摊开。

主体与类目：这三条填错，整轮重新排队

第一条，主体微信认证的状态截图。工厂注册小程序时常常只完成主体注册就急着开发，认证被当成以后再说的事。问题是设备报修的两个基础能力都挂在认证上：获取手机号接口只对已认证的非个人主体开放，客服消息和订阅消息同样如此。未认证状态下这些接口调用直接返回无权限，审核员点到一键获取手机号联系维修工那一步就走不下去，判定为功能不可用。认证每年三百元，流程通常一到三个工作日，把它办在开发启动前的第一周，比压在提审前一晚安全得多。

第二条，服务类目与实际功能的逐项对照表。设备报修本身属于企业内部管理，落在商业服务或者 IT 科技下的软件开发类目，这一层大多数人不会选错。真正翻车的是附带功能：小程序里加了备件申领，只要备件走在线支付，哪怕扣的是内部账，也可能被认定具备交易属性；接入外部维修服务商的派单与结算，又会碰到服务预约类目。类目在一个自然月内只允许修改三次，改完重新排队，第一次选错的代价是整轮时间作废。可行的办法是把小程序里每个可点击的功能入口列成一张表，逐行标注归属类目，表里出现两个以上类目就提前补齐资质。

第三条，名称与简称的预检结果。名称审核和版本审核是两条独立队列。名称里出现设备管理、报修中心这类通用词，极易与已有小程序重名而被驳回；带企业全称的名称要求提供与营业执照一致的证明，用商标简称则要附商标注册证。名称审核的官方口径是一到七个工作日，实测多数在二十四小时内出结果，可它一旦不通过，版本提审只能跟着往后顺延。把名称在开发进行到中段时就定下并提交，是这份清单里成本最小的一项。

审核员必须走得通的三条路

第四条，覆盖三种角色的测试账号，外加免验证码的登录兜底。设备报修的权限模型通常是操作工报修、维修工接单、工段长审批三层，只给一个操作工账号，审核员看到的就是一个能提交、看不到后续流转的半截系统。更常见的卡点在登录方式：工号加短信验证码，审核员那台测试机收不到短信，流程停在验证码输入框。清单要求三个角色各一组账号密码，保留一条固定验证码或者白名单免验证的通道，并标注有效期至少覆盖提审后十五天。这份账号表由APP开发公司准备、客户逐个试登确认，缺一项不提交。

第五条，扫码入口的手动兜底方案。这类系统的主流程起点是扫设备铭牌上的二维码，扫完带出设备编号、所属产线和历史维修记录。审核员手边没有真实设备，这条主流程在他那里等于不存在。清单要求提审备注里附一张能直接从屏幕上扫描的测试二维码图片，同时在测试账号下预置两到三台虚拟设备，允许手动输入编号进入报修表单。这不是代码问题，是材料完整度问题，却结结实实换来过一次无法完整体验小程序功能的驳回。

第六条，服务器域名的合法性核查。制造企业的设备台账和产线数据大多放在厂内服务器上，项目组顺手就把内网地址写进了接口配置。微信要求 request 合法域名必须是已备案的公网域名并支持 HTTPS，IP 地址和内网地址一律不被接受，配置条数上限两百个。与之配套的是审核环境的降级策略：内网接口在公网侧取不到数据时不能白屏，要在三秒超时后返回一套只读演示数据，保证审核员看到的每个页面都是完整的。设备实时运行状态、传感器读数这类依赖厂内系统的模块，最容易在这一步露出空白页。

隐私与内容安全这三条，机器扫描不讲情面

第七条，隐私保护指引与代码包接口调用的逐项对齐。这一关是静态扫描，代码里出现敏感接口而指引中没有对应声明，几乎必然被拦。设备报修容易漏的往往不是摄像头和相册，而是中期加进来的小功能：自动带出所在车间区域用到了定位，联系维修工用到了手机号，语音描述故障用到了录音。同样容易漏的是第三方 SDK，消息推送、崩溃统计、地图组件都会收集设备标识，必须在指引里单独列出名称与收集目的。执行方式是让APP开发公司从代码包里搜出全部敏感接口调用点，与指引条目一条条画勾，数量对不上就不提交。

第八条，用户上传内容的安全校验证据。工人报修要拍故障部位、填故障描述，这两处都属于用户生成内容，凡是有内容上传的小程序都需要具备审核机制，实现方式是调用内容安全接口对文本和图片做前置校验。接口对图片有硬性限制，单张一兆以内、长宽不超过七百五十乘一千三百三十四，车间里随手拍的照片动辄三到五兆，必须在前端压缩后再送检。清单里要附上校验代码的位置说明和一张拦截生效的截图，缺这一项会被判为没有内容审核机制，与代码写得好不好没有关系。

第九条，分享与消息推送的使用边界说明。报修单转发到班组群是车间里的刚需，但只要在转发上挂了任何激励，比如转发得积分、转发后优先派单，就落进诱导分享的判定范围。订阅消息同样有边界，维修进度提醒必须由用户主动订阅触发，不能用后台批量下发的方式绕开。清单要求把每一处调用分享和消息接口的页面截图列出来，注明触发条件和用户授权的入口位置，让审核员不必自己去猜。

提交这个动作本身也会被扣分

第十条，版本描述与代码包实际内容的差集核对。项目上线常用后台开关控制功能可见性，把没做完的备件商城、外部服务商结算先关掉。开关只影响界面，代码仍然躺在包里，静态扫描照样扫得出对应的接口调用和页面路径。版本描述里没提这些功能，扫描结果里却有，就会被判定实际功能与描述不符。稳妥的处理是提审前把未启用模块的代码从分包中彻底剔除，或者在版本描述中如实写明其存在状态与开放计划，两者选一，不要留着让审核员发现。

第十一条，审核窗口期的版本管理约定。多数版本审核在十二到四十八小时内出结果，这段时间里任何一次新的代码提交都会覆盖当前送审版本并把排队位置清零，而项目组在等待期继续改缺陷是再自然不过的习惯。清单末条写的是三句话：审核期间锁定发布分支，后续开发只允许走独立分支；真发现严重缺陷宁可主动撤回重提，也不要用覆盖提交的方式蒙混过去；提交时点避开每周五下午和法定假期前一天，把出结果的时间压在自己上班的时段里。这一条与技术毫无关系，把它写进和APP开发公司的交付约定，比写进任何一份技术文档都管用。