AI画马年红包封面到微信小程序：从生成到上线的完整实践

春节前那段时间，我朋友圈里的年味变得越来越抽象。有人晒年会，有人晒抢票，真正让我停下刷手机动作的，是一张用 AI 生成的骏马图。那匹马踏碎祥云，鬃毛被金色风卷起来，虽然脚趾比例有点怪，但气势确实足。我突然意识到，马上就是马年了，与其到处找别人做的红包封面，不如自己画一套，再用一个小程序把这些封面发出去。这个想法听起来很顺，实际操作时却撞了不少墙。这篇文章就记录我从 AI 画马、到提交红包封面审核、再到手写一个微信小程序的全过程，适合两类人：一类是正在用 AI 做素材的创作者，另一类是准备从零开始搞一个小程序但还没下定决心的人。

1. 这个选题不是拍脑袋，是被现实逼出来的

1.1 一个本来只想做祝福图的想法

事情的起点特别朴素。我最初只想在春节前用 AI 生成一张“马年大吉”的祝福图，类似那种发给长辈的静态海报，配上恭喜发财之类的话就完事了。结果图片生成后，自己觉得浪费了，因为一张静态图发到群里，两小时后就沉底，没有人会反复看。

后来我意识到，春节里真正有“流通性”的物料其实是红包封面。平时大家不发红包，但除夕到初七这几天，只要发红包就必须打开微信红包界面，封面就在这个界面上反复出现。一张封面如果做得准，等于在所有发红包的人手里做了一轮循环曝光。这可能比发一条公众号推送还直接，因为它是被用户主动带进社交场景里的。

于是我从“做一张祝福图”改成“做一套马年红包封面”，然后再配套一个小程序来承接封面展示、预览和领取引导。说白了，就是把一次性内容做成一个可复访的产品。

1.2 给生成方案定的三条硬指标

定了方向之后，我没有直接打开 AI 工具乱画，而是先写了一个需求清单。AI 绘画的坑我踩过太多次，越是想当然，最后越容易得到一张“好像什么都有、实际什么都不能用”的图。

我的硬指标只有三条。

第一，主色必须是红和金。红包封面在微信聊天列表里被点开时，缩略图很小，如果颜色不够醒目，很难在第一眼抓住注意力。红底金纹是春节认知里最稳的组合，基本不会出错。

第二，封面中央区域必须留白。这不是审美问题，是功能问题。微信红包封面上会被系统叠加文字、头像、昵称等元素，如果在构图阶段就把画面塞满，之后挂载信息会糊成一团，所以最初生成图时就必须留出“可被破坏”的空白区。

第三，生肖辨识度优先。我不想生成一张“漂亮的马的照片”，而是要一眼能认出“这是马年”的图形表达。水墨马、剪纸马、版画马都可以，但前提是马的轮廓、姿态、鬃毛等关键特征不能被背景装饰吃掉。

这三条指标看起来简单，其实它们决定了后续所有提示词和参数的方向。

1.3 先想清楚封面会在哪里被看见

做设计的人容易犯一个错误，就是拿大屏幕的审美去推小屏幕的体验。红包封面真正被高频看到的场景，其实是聊天记录里一个大约三厘米宽的小卡片。

在这种尺度下，细节根本不重要，重要的是轮廓影响力。我后来生成的很多图，放大看时纹理漂亮、质感丰富，但缩成小图后就是一团模糊的红色，这种图只能淘汰。真正适合做封面的图，往往是大色块、强边界、高对比，元素之间要有足够的间隙，不能糊在一起。

所以我在整个创作过程中，反复做的一个动作是：把候选图缩到手机尺寸再看一眼，而不是盯着大屏幕做判断。这个习惯帮我省了很多审核时间，也让我淘汰了一批“单看很惊艳、放到微信里立刻翻车”的作品。可以把这个过程理解成在设计邮票，不是在画海报，邮票上的每个元素都要为缩小后的辨识度服务。

2. AI 画马时最难的不是词，是盯着马腿看一天

2.1 我的提示词模板与调参习惯

很多人觉得 AI 绘画的提示词越花哨越好，我一开始也这样，后来发现对“红包封面”这种非常具体的用途，提示词反而要克制。我目前的通用模板大概是这样的：

red envelope cover design, Chinese zodiac horse, traditional Chinese ink painting style, gold foil texture, red background, peony and auspicious cloud patterns, composition leaves blank center for text, no text, no watermark, high resolution

负向提示词：

text, letters, watermark, signature, deformed legs, extra legs, malformed hooves, blurry face, duplicate ears, distorted anatomy

参数方面，我会固定宽高比在 3:4 附近，因为最终封面图接近这个比例；采样步数在 28 到 35 之间；CFG 控制在 6 到 7.5。太低了形不准，太高了又容易让画面发干发硬，像塑料质感。这里没有绝对的“正确参数”，我的习惯是先固定一个 seed，然后微调提示词，这样可以在同一构图基础上快速做对比。

2.2 马的“翻车现场”和局部重绘修复

AI 画马有个著名的毛病，就是马腿。我第一批生成了二十多张图，真正能用的不到五张。问题几乎都集中在腿上：前腿交叉得不像关节该有的方向，蹄子分裂成两瓣甚至三瓣，肚子下面多出一条悬空的腿。

遇到这种问题，我一般不会重新生成整套图，因为重新生成会连带着把构图、配色、背景一起打乱。我更习惯用局部重绘功能，把马腿区域框出来，只重新生成那一块。这样背景和主体风格不会变，只需要盯着腿部结构修。如果重绘三四次仍然不对，就把这张图删除，从批次里挑一张“腿没太大问题”的继续改，不要在坏图上硬修。

眼睛也是一个容易翻车的点。AI 生成写实马眼时，常常会出现眼白过多的问题，导致马看起来惊恐或者眼神发愣。我习惯在局部重绘时把眼睛区域单独处理，逼着模型生成深色、圆润、安静的眼睛。毕竟红包封面是喜庆场景，马的眼神太凶或太呆都会让整张封面变得不吉利。

2.3 从“画面好看”到“能当封面”的合成工作

生成图只是第一步，真正能用还得经过两个加工步骤。

第一步是裁切。AI 生成出来的画幅往往不是严谨的 3:4，边缘也可能有多余的装饰元素。我会先用修图工具把边缘裁掉，再往外延展出 300 像素左右的出血位。这个出血位非常重要，因为微信红包封面在不同机型上展示时会做轻微裁切，如果内容紧贴边缘，小屏上可能直接切掉马头或者文字区域。

第二步是统一色感和清晰度。我通常会把所有候选图放进同一个工程，用曲线把暗部压得稍微深一点，把高光调成金色。这样整套封面放出来会有一个很强的系列感，而不是几张风格割裂的图片堆在一起。最后再跑一遍高清放大，保证缩到小图时，马鬃毛和祥云边缘不会出现明显的锯齿或马赛克。

做这一步时，小屏预览的习惯救了我很多次。我把处理完的封面缩成手机截图尺寸丢进聊天窗口，假装自己收到一个红包，然后点开看整体效果。这个过程看似笨，但比在电脑上看十遍都有效。

3. 在红包封面开放平台过审，比画马更磨人

3.1 尺寸、体积和那一纸原创承诺

图片做好之后，真正的关卡来了：微信红包封面开放平台。 我填信息、传设计图、提交审核，流程本身并不复杂，但里面每个字段都藏着坑。

首先是尺寸。我当时按后台提示做的是 957×1279 像素，PNG 或 JPG 格式，单张图片体积不能超过 500KB。如果你现在做，还是以平台最新提示为准，这个参数偶尔会有微调。 我第一次提交时用的是 1024×1365 的生成图原尺寸，结果直接被后台打回，因为图片太大、比例也不对。后来老老实实在 PS 里裁到 957×1279，再导出压缩版，才顺利通过。

其次是原创承诺。红包封面开放平台会让你填写版权说明，尤其是在“原创”一栏里，必须勾选并上传对应的版权文件或承诺书。因为是 AI 生成的内容，我当时特意保留了一整套生成过程的截图，包括提示词、批次参数、中间步骤，避免审核人员问起来我拿不出依据。这里多留一手，后面少很多麻烦。

3.2 审核被驳回的常见原因

我把被驳回和看到别人被驳回的原因整理了一下，很多错误是完全可以提前避开的。

其中最容易犯的是二维码。我之前总想在封面上加一个公众号二维码，如果用户扫了码就能关注我，后来审核直接被驳回。平台对这类引导行为卡得特别严，正确做法是封面图保持干净，二维码和引导信息放到正文或评论区，不要压在封面素材里。

3.3 封面故事：在同一个封面上再讲一个故事

除了封面主体图，开放平台还允许配置一张“封面故事”图或视频，用户在同一条消息里滑动，可以从封面切换到故事页。这个位置非常适合做延展内容。

我没有放商品链接，也没有放下载链接，而是把 AI 生成马匹的创作过程浓缩成了一张小图——从线稿草图到最终成图的对比。这样不会显得广告味很重，反而让封面多了一点人情味。平台上对封面故事的尺寸同样有要求，我当时做的是 750×660 像素左右，静图体积尽量控制在 100KB 以内。

这里有一个容易被忽略的点：封面故事不是必须的，但配置了之后，整个红包封面的“完整体验”感会强很多。用户看到的不再是一张孤零零的图，而是一个有前后语境的作品。

4. 小程序是我权衡了三条路之后的选择

4.1 为什么最后选了小程序，而不是公众号或网盘

封面过审之后，问题来了：要怎么把它发到别人手里？我最初纠结过三条路：公众号推文、网盘链接、小程序。

公众号推文的问题是，阅读完就结束了，用户看完不会留下什么，而且公众号文章跳转红包封面的路径很长，容易在中途流失。网盘链接就更不用说了，在微信里点开体验非常差，下载、解压、找文件，每一步都在消耗用户耐心。

小程序是我最后选的路线。它能在微信内以“用完即走”的方式打开，可以快速展示整套封面，用户看到喜欢的封面还能保存或者分享给朋友。更重要的是，小程序可以自己记录访问数据，我能够知道哪张封面最受欢迎，而不是像公众号文章那样只能看到一个阅读量。

如果你只是临时发一批封面，公众号推文完全够用，不需要上小程序；但如果你想把封面做成一个可持续更新的项目，小程序可以提供更稳定的承载空间。

4.2 原生开发还是跨端框架，我的取舍

选择开发方式的时候，我犹豫过一段时间。热词里很多人提到 uniapp，也有不少人在用 Taro，但最终我选了原生小程序开发。

我这次的项目只服务微信生态，不需要多端发布，而且我会用到订阅消息、canvas 合成、自定义导航栏这类微信差异化能力，原生开发最省心。如果你未来想把同一套内容发到多个平台，跨端框架是更好的选择；但如果你只是想跑通一个微信小程序，原生反而是效率最高的路径。

4.3 页面结构：三屏搞定，不搞花活

我的小程序只有三个核心页面，外加一个“我的”页面。

第一屏是封面列表页，顶部一个简单的轮播 banner，下面按数组渲染封面卡片。这个页面的任务只有一个：让用户在两秒内看到所有封面。我刻意没有加复杂分类，因为内容量不大，分类反而增加选择负担。

第二屏是封面预览页。用户点某张卡片后进入，可以看清晰大图，能保存到相册，也能直接转发给微信好友。保存大图用 canvas 绘制，拼接上祝福语，这样每张分享出去的图都自带我的水印和引导。

第三屏是定制页。用户可以输入自己的昵称或祝福语，小程序用 canvas 把小字合成到封面图中央。这个功能我用前端 canvas 直接做，没有走后端渲染方案，省了一台服务器，也避免了等待时间。整个包体量控制在一兆以内，加载很快，后续要加新封面，只要改接口数据，不需要发版。

5. 写代码时被问最多的四个问题

5.1 登录后拉不到用户信息，AppID 和隐私配置两头堵

这应该是微信小程序里最经典的问题了。很多人在登录阶段就卡住，比如页面报错，提示“小程序获取登录后的微信用户失败”，后面还跟着一串形如 wx1cb4398e1413dce7 的字符串。这串字符其实就是小程序的 AppID。 遇到这类报错，第一反应不是改代码，而是去小程序后台确认三件事：AppID 是否填对了、AppSecret 是否匹配、请求域名是否已经在后台配置成合法域名。

后端拿到 wx.login 返回的 code 后，要用 code 换 openid，这一步如果 AppID 和密钥对不上，会直接抛参数错误。前端代码通常是这样的：

wx.login({ success: (res) => { if (res.code) { wx.request({ url: 'https://api.example.com/wechat/login', method: 'POST', data: { code: res.code }, success: (res) => { const { token, openid } = res.data wx.setStorageSync('token', token) } }) } } })

另外要特别注意，现在获取用户的头像和昵称不再像以前那样自动弹窗了。我最初用 wx.getUserProfile，结果在真机上一片空白。后来改成用户主动点击按钮，按钮上声明“用于头像展示”，配合 input 输入昵称，才在审核时顺利通过。微信平台现在对用户信息授权收得很紧，前台必须让用户主动触发，后台还必须配置好隐私协议，否则调用会被直接拦截。

5.2 自定义导航栏高度到底怎么量

很多小程序为了视觉效果会设置自定义导航栏，把系统那一层黑色标题栏去掉。问题随之而来：顶部高度不同机型不一样，刘海屏、灵动岛、普通屏都不同。我不建议写死高度，我会用公式实时计算：

const windowInfo = wx.getWindowInfo() const menu = wx.getMenuButtonBoundingClientRect() const navHeight = (menu.top - windowInfo.statusBarHeight) * 2 + menu.height

这段代码先拿到右上角胶囊按钮的位置，再用状态栏高度推算出自定义导航栏的高度。原因是，胶囊按钮的位置是系统确定的，只要跟着它走，就不会和微信的 UI 打架。 把这个数值设成整个页面顶部容器的 padding-top，再给标题栏设固定高度，基本就能适配绝大多数机型。

这个坑看着小，但不处理的话，同一个页面在不同手机上会出现标题或者按钮错位，非常掉价。

5.3 用户手里的旧版本迟迟不更新

小程序有个好处是无需安装，但也有个隐性坑：用户长时间不打开，或者微信认为没必要更新，就会一直使用旧版本。如果我在新版里修了一个严重 bug，用户还在旧版里反复踩坑。

我后来在首页加了一段更新检测逻辑，基于微信提供的 updateManager 接口：

const updateManager = wx.getUpdateManager() updateManager.onUpdateReady(() => { wx.showModal({ title: '更新提示', content: '新版本已准备好，是否现在重启？', success: (res) => { if (res.confirm) { updateManager.applyUpdate() } } }) })

这段逻辑对于用户量小的小程序，可能几个月都不触发一次，但一旦触发，就能少很多客服成本。版本更新这个动作，平时没人夸，出问题时用户只会觉得“小程序卡了、坏了”，不会意识到是版本旧了。

5.4 图片资源别塞进包里

小程序主包有 2MB 的大小限制，我把封面图统统塞进了包目录里，结果刚写好主页面，包体就逼近上限。后来我把所有封面大图挪到云存储或 CDN，页面里的 image 组件直接引用远程地址，包体立刻降回安全范围。

还有一个小技巧是图片预加载。封面列表页滑动时，如果每张图都是实时去拉，会在快速滑动时出现白底闪烁。我写了一个简单的预加载逻辑，当页面滚动到下一屏前，提前用 wx.createImage 把下一批图拉进缓存。这里面有个平衡问题：预加载太多会浪费流量，太少又会卡顿，我采用的做法是只预加载屏幕外一屏的数量，差不多 4 到 5 张。

6. 上线一周后的数据与我的判断

6.1 访问量不高，但留存和转发数据让我意外

小程序上线后第一周，总访问量其实很低，毕竟我没做投放，传播只能靠朋友圈和互推。但让我意外的是两个指标：页面平均停留时间接近半分钟，分享次数占访问量的比例比我预期的要高不少。这意味着，从首页看到封面的人，多数会点进预览页仔细看，而且愿意转发给别人。

这种数据在商业产品里不算什么，但放在一个个人原创封面项目里，已经能说明方向是对的。如果更多人愿意转发，说明封面本身有社交价值，而不只是我觉得好看。

我没有用特别复杂的统计工具，就是在前端埋了几个简单的点击事件，把“进入预览页”“保存图片”“点击领取按钮”这几个关键行为上报到自己的服务器。通过这些行为漏斗，我可以判断用户在哪个环节流失，再去优化对应页面。

6.2 用订阅消息做了一次温和的召回

小程序的订阅消息是召回用户的一个好办法，但它有个让人头疼的规则：用户授权的是一次性订阅，也就是推送完一条之后，再想推第二条，必须让用户再次点击授权。

我没有什么高频需求，就没有做“每日推送”这种强度，只设计了一个朴素场景：用户如果保存了封面但没完成领取引导，我会在他们进入页面时请求一次订阅授权，内容写的是“封面上新时提醒”，等下一批封面释放时推送一条通知。

实测下来，订阅消息对用户的打扰感还是很大的，所以我的原则是能不用就不用。如果项目不是特别需要召回，我建议直接把订阅消息砍掉，反而能让小程序显得更轻。

6.3 没有接入支付，是个正确的决定

我最初想过给小程序加一个付费定制功能，用户上传名字或祝福语，我收一点定制费。后来研究微信支付的开发者流程时，发现一个现实问题：微信小程序对虚拟商品交易限制很严格，尤其是在 iOS 端，虚拟内容不允许直接在小程序里售卖。 红包封面定制本质上属于虚拟内容，如果强行接支付，很容易踩到平台规则红线。

所以最终我只保留了免费定制，没有接入支付。如果你想做商业化，我会建议把方向放在实物周边上，比如印制马年明信片、帆布袋等实体商品，这样可以合理使用微信支付。或者用小程序做分发，把流量引导到其他合法合规的成交渠道。至少在目前的生态里，纯虚拟内容在小程序里收费是雷区，能不碰就不碰。

最后说一句个人体会。这次项目最让我意外的不是 AI 画马的技术演进，也不是小程序 API 的复杂，而是从一张生成图到一个人愿意保存、转发、使用的过程，比想象中长得多。AI 可以把制作成本压得很低，但审美判断、平台规则、用户心理这些环节，仍然需要人一点点去补。如果你也想做类似的事，我不建议一上来就规划一个大平台，先把自己手头的封面或者小工具做穿，跑通一个小闭环，你学到的东西会比报十节课都多。