起点：把一款宝可梦猜谜应用做成微信小程序
今天（素材来自 2026-09-06 的工作日志）把"宝可猜谜挑战"小程序往前推了一大步：剪影猜的渐进揭示机制正式定稿，同时把 8 种猜谜玩法（剪影/属性/词云/图鉴/招式/特性/道具/冲刺）整体做了出来。
这是一款宝可梦主题的微信小程序猜谜应用。我的目标不是堆功能，而是借这个项目把"多玩法小程序架构 + 云函数契约 + 前端工具链"的综合能力练一遍——它本身就是一份可写进简历的作品集。
剪影猜：一个被"方位词"耽误的交互
剪影猜的核心诉求很清晰：起始只露局部剪影，用户每猜错一次逐步拉远露出更多，同时按尝试次数揭示目标主色，最终揭晓彩色立绘。
卡住我的是缩放方向的语义。一开始我做成整体放大，用户说"不对，要放大"；改成整体缩小，用户又说"要放大"——来回 4 版。最后才读懂：用户口中的"放大/缩小"是相对剪影可视区域而言，"看得更多"= 缩小缩放比例（1/2），而不是放大。
定稿方案：
// 缩放随猜错次数渐进拉远，6 次机会
function computeZoom(wrongs, over) {
if (over) return 1;
return Math.max(1, 2.0 - wrongs * 0.2);
}
// 头部锚点：2.0x 起始露头脸，1.0x 全身
// .stage-inner { transform-origin: 50% 30%; }
颜色揭示时序 revealedColorsAt(attempts) 按"尝试次数"而非"错题数"计算：attempts>=4 给 colors[0..2]，>=2 给 colors[0]，双槽 PRIMARY/SECONDARY。这只和"你猜了几次"有关，和"对错"无关，保证时序确定、可测试。
主色提取：把素材生成做成脚本
每只宝可梦的揭示主色，我没有手工标注，而是写了 gen_sil_colors.py 用 Pillow 算法提取：
- 只取不透明像素，剔除
max<40且近中性的纯黑轮廓（眼睛、描边）； - 量化直方图（桶 STEP=28）加权；
- 贪心取与已选距离
>=90的 top2 作为 PRIMARY/SECONDARY。
剪影图本身也从二值 palette 改成 LA 模式（灰度+alpha），保留原图边缘 alpha 渐变，放大后边缘平滑不再有锯齿。这套"用脚本生成素材"的链路，比手工标注可维护得多——152 只、后来扩到 1025 只，全靠脚本重跑。
两个让我长记性的 bug
契约误用。 云函数返回的 revealedClues 是按错次算好的"揭示子集" 对象，前端 buildShownClues 误把它当数组 .filter()，运行期直接白屏：(attempts||[]).filter is not a function。改成遍历约定字段 CLUE_ORDER、检查 k in revealedClues 才稳。根因就一句话：没先读云函数契约就按数组处理。
批量编辑的信任危机。 用 Edit 批量改 8 个云函数，工具回报"成功"，实际有文件没落盘，留下 pickBySeed/POOL 残缺引用，页面局部直接 ReferenceError。后来改成"可验证脚本整体替换函数体 + mock wx-server-sdk 的 test_sprint.js/test_daily_mode.js 跑通 8/8"才算数。任何批量改动都要有可验证的收口手段，不能信工具的"成功"二字。
工程纪律，才是能写进简历的东西
这一天最后沉淀下来的，其实是几条工程默认项：
- 需求澄清：用户说的方位词常是相对可视区域，别用字面意思写代码；
- 测试要覆盖"状态变化后的再读取"路径——只测首次 get 抓不到渐进揭示类 bug；
- 工具链要可幂等重跑——1025 只宝可梦的剪影+彩图共 2050 个确定性文件上 CDN，主包瘦身到只留首页图。
副业项目的水位，取决于你把它当"玩具"还是当"产品"。把需求澄清、契约约束、测试纪律当成默认项，这份项目才配得上写进简历、甩给面试官。