uni ai绘画进小程序：一张AI贺卡功能的两周开发账
开门见山：uni ai绘画功能做进小程序，技术上没有坎，坎全在体验和审核。花店AI贺卡两周上线，首周日均一百三十次调用，完成率从六成一拉到八成九。架构怎么搭、八秒怎么熬，这篇全说。
九月下旬，厦门一个开花店的老同学找我：想给店里的小程序加个「AI手绘贺卡」——顾客下单时输入一句话，出一张配图贺卡随花送出。她那套小程序是别人用uni-app写的，一套代码编译到微信端，接个新功能顺理成章，我接了。两周开发加首周运营的账，今天整个摊开。
先说清我的底子：写前端七年，uni-app做过三个项目，但AI生图接口是头一回接。所以这篇既是开发实录，也是新手的踩坑账，质量比纯炫技帖实在。
接口放后端转发，别把生图塞进小程序
生图API的密钥和小程序端彻底隔离，走自家云函数转发，前端只收图址。主包两兆的红线靠远程图床解决，一个字节都不用占。这是整件事里最没有争议的一条架构决定。
具体链路：用户在小程序输入贺卡句子，请求先打到我的云函数，云函数带密钥调第三方生图接口，图生成后转存到对象存储，小程序端拿一个 https 图址加载渲染。密钥永远不落前端，生图耗时也不占小程序的请求超时。成本方面我比较过三家按张计费的服务，单价从两毛到八毛不等，最终选了中档那家，理由是它支持传风格参考图——花店要的「水彩感」靠参考图锁，比纯文字提示词稳太多。选服务商时的比价心得，跟那篇ai绘画fe版哪家免费额度实在里逐家试成本的路数一样：别信宣传页，跑十张试单再定。
主包体积是另一个隐形关卡：小程序主包上限两兆，生成图一律远程加载，只在包里留了个占位图。花店原来的包就一兆六，我全程没敢往里塞任何图片资源，这点从立项就定了纪律。
提示词模板也值得一提。用户只输入一句话，直接喂模型出的图十次有四次跑偏，比如有人写「送妈妈」，出来的是贺卡上印着两个妈妈。我在云函数里加了模板拼接：用户的句子只作为「画面元素」嵌进固定框架，画风、构图、留白位置全由模板锁死，跑偏率降到基本为零。这个模板前后调了五版，第一版只留白没构图，文字压在花上，返回给前端的图没法叠字。给模型立的规矩越死，前端活得越轻松，做这个功能前我没想到，规则感在这里比创造力值钱。
等八秒的体验，是我最花心思的地方
生图平均耗时八秒，裸等待的首周流失率四成；改成进度动效加文案轮换加生成历史缓存后，完成率干到八成九。功能上线只是及格线，等待体验才是留人线。
九月三十号内测版上线，数据很难看：用户点「生成」后看着转圈，八秒里有四成直接退出。十月一号我做了三件事：等待页换成画笔涂色的动效，底下文案每两秒轮一句，从「正在挑选花瓣的颜色」到「贺卡快画好了」；生成结果全部缓存，二次进入秒开历史图；失败自动重试一次，重试成功的提示单独做了一版。十月八号正式上线首周，日均调用一百三十次，完成率从六一干到八九。老同学的反馈更直白：有顾客为了多生成两张贺卡，特意多买了一束花。这个副作用我没预料到。
审核是最后一只拦路虎。十月二号第一次提审被拒，理由是生成内容需要用户协议里加授权与内容规范声明。我把条款补进用户协议，生成页加了一行小字说明，四号二提过了。提醒一句：别在生成页默认输出任何真人写实头像方向的内容，小程序对这类内容的尺子比网页紧得多，我们直接把人像类提示词在云函数里做了过滤。
费用再算细一点：日均一百三十次调用，按每张三毛八的中档价，一个月光生图成本一千四百多。老同学拿这个数跟印刷厂的定制贺卡报价对了一下——后者一张一块五还不敢保证当天出——她看完账就说了四个字：这个便宜。小生意算AI的账，别看单次调用贵不贵，看它替下了哪道工序。
回款那天老同学请我吃了顿砂锅粥，席间她说了一句我到现在还常想起的话：顾客不在乎背后是什么模型，只在乎贺卡像不像「特意为她画的」。技术两周就写完了，把这个「特意感」调出来，才是我那两周真正的活。
常见问题
生图耗时不稳定，最长等多久合适？
我在云函数里设了二十五秒熔断，超过就返回失败并触发重试。实测百分之九十五的请求落在十二秒以内，等超过二十秒的用户流失率接近全部，与其吊着不如干脆失败重来，体验反而更好。
小程序里能直接跑AI绘画模型吗？
想都别想。小程序环境没有本地算力的口子，包体积也装不下任何模型文件，所有生图都只能走服务端。所谓「端上生成」的方案，要么是营销话术，要么是把图存在了别人服务器上。
用户输入的句子，怎么避免生成违规图？
三层过滤：云函数先做敏感词拦截，提示词模板把用户输入限定在「花、植物、祝福语」的场景框架里，生成后再接一道机审接口。三层下来两周内没出过一次内容事故，成本每千次多花三块钱。
uni-app一套代码，别的端也能上这个功能吗？
架构上可以，生图逻辑全在服务端，H5和App端只是换个壳调接口。但每个端的审核尺子和等待页交互要单独过一遍，我们H5版十月十号上线，就没遇到小程序那条协议声明的要求，各端各判，别想一套过全网。