背景：发布前的一次"事实核对"
最近给「宝可猜谜挑战」小程序（微信原生 + 云开发）做宣传准备。按我的习惯，对外讲的每一句话在发布前都要和代码对一遍——这不是多此一举，而是把"我以为"变成"我确认"的过程。这一遍翻下来，避开了好几个会公开翻车的坑，也沉淀了两条可复用的工程经验。
素材管线：一行 sips 解决头像体积限制
公众号和小程序头像都要求素材 ≤2MB。我手里的 logo 原图是 2048×2048 的 JPEG，足足 2.57MB，直接超限。我不想把素材交给在线压缩服务（要留本地、不转手第三方），于是用 macOS 自带的 sips 在终端里处理：
sips -Z 2048 -s format jpeg -s formatOptions 85 in.jpg --out logo_2048.jpg
sips -Z 512 -s format jpeg -s formatOptions 80 in.jpg --out logo_512.jpg
一行命令出三个尺寸，无裁切、无色彩改动。这里踩到一个坑：如果原图是透明底 PNG，转 JPEG 会把透明区填成白底，需要透明或圆角的场景得改用 PNG 重出。这条命令已经记成可复用模板，下次换素材直接套。
代码审计：把宣传口径和真实实现对齐
我逐个读了首页和各题型的实现：miniprogram/pages/*、cloudfunctions/submitResult/index.js、cloudfunctions/dailySilhouette/core.js、sprint.js、silhouette.js。核对下来，几处和我原本的设想不一致：
- 每日机制：每种题型各自每天出一道（首页 9 张题型卡 + 冲刺横条），而不是"整体一天只能玩一次"，一天最多可玩 9 道。
- 剪影玩法：镜头
2.0x→1.0x渐进揭示，每猜错缩 0.2x，错到后段才揭颜色（先主色后副色）。 - 冲刺玩法：30 题 / 180s / 8 种题型混排，跳过 -5s，每题 6 次机会。
- 连胜逻辑：在
submitResult里是streak = score===5 ? 昨日+1 : 0，要 5/5 全对才 +1，错一题清零，和"打卡天数"是两回事。
如果当时没审计，宣传稿就会把不存在的机制写出来，发出去就是公开事实错误。对一个独立开发者，代码是唯一事实来源，文档和记忆都会漂。
平台合规：绕不开的几个硬约束
小程序上线不只是把代码跑起来，还要过平台规则这一关，这是我摸索出来的几条：
- 流量主：累计独立访客达标（常见口径 1000 UV），不能刷，主力靠分享 / 好友对战把量做起来。
- 虚拟支付：微信已于 2026-08-31 面向个人主体开放（不必注册公司），但硬约束是类目必须含"工具"、全终端月支付限额 10 万元、iOS 端走 Apple IAP（费率 12%，开发者不能主动退款）。
- 生死线：玩法别被判定为"游戏"。答题类要做好非游戏化表述和类目选择，否则游戏类目需要版号，个人主体根本办不了。
方法论沉淀
这一趟下来，三件事串成了"能交付"的标准动作：素材管线（sips 本地压缩、注意底色）、机制对齐（读代码而非读文档）、合规边界（类目 / 支付 / 流量主）。发布前的代码审计成本低、回报高，它把对外陈述从"我相信"变成"我验证过"。对一个想做作品集、也正在看机会的前端 / 全栈开发者来说，这种工程纪律比功能本身更能说明问题。
更多工程复盘见 blog.alleria.cn。