小程序 AI 开发：先把云函数、审核约束和异步链路串起来
小程序 AI 开发最容易被写成“前端 + 云函数 + 模型 API”的三层架构，但真正决定产品能否跑稳的，是审核约束、上传链路、会话状态、异步任务和内容回退是否设计清楚。
01.小程序 AI 最容易被误写成“云函数帮你调一下模型”
很多关于小程序集成 AI 的文章，常见写法是：
- •小程序前端
- •云函数
- •模型 API
这个架构图没有错，但它漏掉了真正更重要的事情：
- •小程序容器的交互和性能限制
- •文件上传和大结果返回是否稳定
- •审核和内容风控如何前置
- •用户一次会话是否能跨页面、跨任务恢复
所以小程序 AI 更适合被理解成“受限容器里的产品编排问题”，而不是一段云函数示例代码。
02.先从链路与审核约束开始，而不是一上来做大而全功能
小程序里的 AI 能力，最常见的几个高频任务是：
- •问答与客服
- •表单或文档辅助填写
- •图片理解
- •内容生成
但如果第一版同时追求：
- •多轮对话
- •文件上传
- •图像生成
- •实时语音
- •多页面复杂状态
项目很快就会在审核、延迟和容器约束上失控。
更现实的做法通常是先固定一条主链路，再把上传、异步和回退一点点加进去。
03.一条稳定的小程序 AI 链路，通常由四层组成
1. 小程序前端交互层
这一层至少要回答：
- •当前用户在做哪类任务
- •输入是文本、图片还是表单
- •前端是否只做轻状态，还是要承接长会话
- •结果展示是否能在容器限制下保持清晰
2. 云函数 / BFF 层
这一层更像小程序 AI 的真正入口：
- •负责鉴权
- •负责配额
- •负责会话状态和幂等
- •负责把高风险请求转到后端服务
如果直接让前端自由拼接模型请求，后面很难做治理。
3. 异步任务与上传层
小程序里很多 AI 任务并不适合同步完成：
- •大图上传
- •文档解析
- •图像生成
- •长文本总结
这类任务更适合：
- •先上传
- •返回任务 ID
- •轮询或订阅结果
而不是在页面里一直 loading。
4. 审核与风控层
小程序场景的一个关键现实是，产品链路天然更依赖：
- •内容审核
- •文本和图片风控
- •用户行为限制
- •发布规范与申诉处理
也就是说，AI 结果不只是“能不能生成”，还要考虑“能不能展示和发布”。
04.模型能力只是后端服务的一部分，小程序真正复杂的是容器约束
在小程序场景里，一个更稳的职责拆分通常是：
更适合后端或模型服务处理的部分
- •推理
- •检索
- •图片理解或生成
- •长任务执行
更适合小程序前端和 BFF 处理的部分
- •轻量交互
- •上传与轮询
- •会话缓存
- •审核提示与回退
- •页面切换后的状态恢复
如果把这些差异忽略掉，小程序产品通常会很快出现“本地看起来能跑，真实用户一用就断”的问题。
05.先让小程序请求结构化，再决定走同步还是异步
更稳的方式，是在入口先把请求类型做显式分流。
from typing import Literal
from pydantic import BaseModel, Field
class MiniProgramTask(BaseModel):
scene: Literal["qa", "form_assist", "image_understanding", "generation"]
attachment_ids: list[str] = Field(default_factory=list)
requires_review: bool = False
async_only: bool = False
def select_miniprogram_flow(task: MiniProgramTask):
if task.async_only or task.scene == "generation":
return {"flow": "async_task"}
return {"flow": "interactive"}这个模式的价值在于：
- •同步问答和异步生成不会混成一条链
- •审核要求可以单独挂到任务类型上
- •页面状态恢复更容易设计
06.容器内体验要克制，重活尽量放到后端
小程序环境很适合做：
- •输入采集
- •轻量展示
- •快速查询
- •任务触发
但不适合把所有重活都塞在容器里做。更现实的做法通常是：
- •复杂上传走对象存储
- •推理和长任务走后端服务
- •结果回传走轮询、消息或缓存读取
这样才能让产品在实际网络和容器条件下更稳。
07.评估不要只看能否调通 API，还要看审核和回退
小程序 AI 的评估，更应该围绕这些问题：
- •用户能否顺利完成一次核心任务
- •审核和风控是否拦住了高风险结果
- •页面切换或中断后状态是否能恢复
- •长任务是否有清晰反馈
- •失败后是否有回退路径或人工兜底
这些指标比“云函数调用成功了”更能说明产品成熟度。
08.三个常见误区
1. 把小程序当成普通 Web 应用来做 AI
容器、审核和状态限制会让很多 Web 经验直接失效。
2. 所有任务都走同步云函数
一旦涉及上传、生成或长文本处理，这条链很快就会超出用户可接受范围。
3. 忽略审核与风控链路
小程序场景里，结果是否能安全展示，本来就是产品的一部分。
09.总结
小程序 AI 开发真正可交付的价值，不是调通一段云函数，而是把前端交互、后端服务、异步任务和审核风控组织成一条稳定的容器内产品链路：
- •先把同步与异步任务分开
- •让重计算和重上传留在后端
- •把审核和回退纳入默认设计
- •用容器内稳定性而不是示例代码长短来评估产品
只要这些边界理顺，小程序 AI 才更有机会在真实业务里稳定运行。