国内 App 接入 LLM 的注意事项：从网络可达性到审核合规
给国内的 App 加一个”AI 助手”功能，听起来是接一个 API 的事，真正落地时会撞上一串和纯技术无关的坑：网络能不能连上、密钥怎么放才不会被反编译扒出来、审核会不会因为一句话被打回、用户在地铁里用流式回复会不会卡成马赛克。这篇文章按开发到上架的顺序过一遍工程和流程层面要注意的点，法规层面的数据合规细节已经在 国内 LLM 应用数据合规要点 和 国内业务的数据出境边界 里详细拆解过，这里不重复,只在涉及处给指引。
一、网络可达性:客户端不该直连海外 API
OpenAI、Anthropic 的官方 API 域名在国内网络环境下访问不稳定,直接在 App 客户端里请求 api.openai.com 大概率会遇到超时、连接重置,尤其在弱网或者部分运营商线路下问题更明显。
工程上正确的做法是客户端永远不直连模型厂商的域名,而是走自己的后端服务,后端再通过中转层访问模型 API。好处不只是解决可达性:
- 密钥不暴露在客户端(下一节详细说)
- 后端可以做统一的重试、降级、多供应商切换,不需要每次改都发版
- 便于做用量统计和风控,而不是完全依赖模型厂商的账单
如果自己搭建海外服务器做转发,要处理证书、线路稳定性、IP 被封禁后的切换等一堆运维问题;更常见的做法是用现成的 API 中转服务把这层复杂度外包出去,后端只需要改一个 base_url。
二、密钥安全:客户端硬编码是最常见的低级错误
把 API Key 直接写进 App 代码或者打包进资源文件,是这个场景里出现频率最高的安全问题。App 包可以被反编译,字符串常量、甚至简单混淆过的密钥,用现成工具几分钟就能扒出来。密钥泄露后果不是理论风险——扒出来的 Key 会被拿去跑量,产生的账单算在你头上。
正确的架构:
App 客户端 → 你的后端(鉴权 + 限流) → API 中转 → LLM 供应商客户端只持有你自己业务系统的登录态(比如 JWT),真正调用模型的密钥只存在于后端环境变量里,永远不出现在下发给客户端的任何代码或响应里。如果产品要求”离线也能用”或者极致低延迟希望端上直连,至少要做到:密钥用后端动态签发的临时凭证(短 TTL、限定 scope),而不是长期有效的主 Key。
三、流式响应在移动网络下的体验陷阱
LLM 的流式输出(SSE / chunked transfer)在 Wi-Fi 下体验很顺,但移动网络切换基站、进电梯、进地铁隧道时连接中断是常态。几个容易被忽略的细节:
- 必须做断线重连,而且重连后不能从头重新生成——常见做法是后端保留已生成的部分内容,重连后前端先渲染已收到的部分,再续接后续流,而不是整段丢失重新等待
- 超时阈值要按移动网络特性放宽,弱网环境下 TTFB(首字节时间)波动可能到 5-10 秒,如果客户端超时设得和 Wi-Fi 环境一样短,会造成大量误判失败
- 前后台切换要处理连接生命周期,App 切到后台后系统可能随时挂起网络连接,回到前台时要能判断连接是否还活着,而不是假装还在流式接收
- 弱网降级:检测到网络质量差时,可以自动切换成非流式的一次性请求,虽然体验上少了”打字机效果”,但比流式中途反复卡死更可靠
四、成本控制:按用户维度限流,不能只靠模型厂商的账单报警
App 场景和内部工具最大的区别是用户不可控——你没法保证每个用户都规规矩矩使用,总会有人写脚本刷接口或者疯狂重试。只靠”月底看账单”式的成本监控,发现问题时可能已经产生了大几千的异常消耗。
必须在后端加至少两层限流:
用户维度:每用户每日请求数上限 + token 用量上限
IP/设备维度:防止单个账号在多设备上并发刷量配合按用户分组的用量统计,才能在异常发生的第一时间(而不是账单出来时)发现并封堵。如果 App 有免费额度 + 付费订阅的模式,免费额度的限流阈值要单独设置,通常比付费用户严格一个数量级。
五、内容安全:审核不能完全交给模型厂商
模型厂商自己有内容安全策略,但这不等于你的 App 就不需要自己的审核层。国内应用商店审核时,AI 生成内容如果出现违规输出,责任在 App 方,不在模型供应商。实践中建议:
- 用户输入先过一层敏感词/风控前置过滤,不合规的输入直接拒绝,不发送给模型
- 模型输出增加一层后置审核(可以用专门的内容安全 API,也可以用轻量模型做二次判断),异常内容拦截而不是直接展示给用户
- 保留输入输出日志(注意用户隐私合规要求,日志留存和访问要有权限控制),出现投诉或审核问题时能追溯
这一层看起来是额外成本,但审核环节被打回一次,重新提审的时间成本通常比日常做内容安全高得多。
六、应用商店审核要点
国内主流应用商店(华为、小米、OPPO、vivo 应用市场等)对包含 AI 生成内容功能的 App 审核会额外关注几点,过审前建议自查:
| 审核项 | 常见要求 |
|---|---|
| 生成式 AI 服务标识 | AI 生成的内容需要有明显标注,不能让用户误以为是人工内容 |
| 内容安全 | 需要说明内容安全审核机制,部分商店要求提交相关备案材料 |
| 用户协议 | 隐私政策需明确说明会调用第三方 AI 服务处理用户输入 |
| 未成年人保护 | 涉及生成内容的功能通常需要有青少年模式下的限制或屏蔽 |
如果 App 面向公众提供生成式 AI 服务且规模达到一定门槛,可能涉及生成式人工智能服务备案要求,这部分法规判断建议参考 国内 LLM 应用数据合规要点 里的详细拆解,提前评估比上架后被要求整改成本低得多。
七、iOS 和 Android 上架的差异点
iOS App Store 审核对”AI 生成内容”类应用历来偏严格,几个实际遇到的高频拒绝原因:
- App 描述或截图暗示”无限制”生成内容,但实际有内容安全限制,导致宣传与功能不一致被拒
- 生成内容涉及可能引起争议的话题(政治、色情边缘内容)且没有明确的过滤机制
- 订阅制 AI 功能没有清晰说明用量限制,被判定为诱导消费
Android 侧审核相对宽松,但国内几家应用商店各自的审核标准不完全一致,同一个 App 在不同商店可能一家过审一家被打回,建议先提交审核相对严格的商店(通常是华为)作为基准,过了之后再批量提交其他商店,能省掉不少来回调整的时间。
八、灰度发布与降级预案
AI 功能上线建议走灰度:先对小比例用户开放,观察真实流量下的延迟、错误率和成本,确认稳定后再全量。灰度期间要准备好功能开关——一旦上游 API 出现大范围故障或者成本异常飙升,能够远程一键关闭 AI 功能入口而不需要重新发版,这比等审核通过新版本快得多。