夜雨聆风把已有 App 迁移成微信小游戏，真正需要迁移的不是页面，而是一条完整的状态链路。
用户输入问题，选择牌阵，完成洗牌和抽牌；客户端把任务交给云函数，等待 AI 生成，再把结果安全地取回来。任何一环中断，前面的界面做得再完整，产品也只是一个不能闭环的演示。
这次迁移先只保留了最小流程：问题输入、牌阵选择、洗牌、抽牌、AI 解读和结果展示。功能数量被主动压缩，但每一步都必须真的能走到下一步。
先迁移状态，再迁移界面
最容易低估的是，原 App 里的页面逻辑不能直接照搬。
输入问题时，要处理键盘打开、关闭和重复调用；洗牌和抽牌时，要记录当前选中了什么；请求 AI 后，还要区分等待、成功、失败和重试。返回上一页时，哪些数据应该保留，哪些应该清空，也必须提前决定。
因此，迁移时先画出的不是页面，而是一条状态线：
输入问题 → 选择牌阵 → 抽牌 → 创建任务 → 查询进度 → 领取结果。
界面只负责展示当前状态。这样即使视觉效果暂时简单，也能先确认产品逻辑是否成立。
为了让这条线可以检查，每个节点都必须有明确的成功和失败出口。问题没有填写就不能继续，请求失败要能重新发起，结果没有完整取回也不能提前进入完成页。流程清楚以后，异常不再是一句笼统的“没反应”，而是能定位到具体一步。
当前版本接入了完整的 78 张塔罗牌和正逆位，但只开放 3 个牌阵。减少牌阵不是功能缩水，而是避免同时验证太多分支。先让三条路径稳定，再扩展剩余能力，排错范围会小很多。
每增加一个牌阵，都会带来新的抽牌数量、位置关系和解读结构。先控制变量，比一开始追求功能齐全更容易得到可运行成果。
AI 请求不能只等一个返回
一次 AI 解读可能需要十几秒。如果客户端发出请求后一直停在同一个页面，用户无法判断它是在生成、失败，还是网络已经断开。
这里采用的是异步任务：云函数先创建任务，小游戏定期查询进度；任务成功后领取完整结果，失败则保留已经抽出的牌，允许重新请求。
结果也没有被压成一小段文字，而是分页展示摘要、每张牌、牌间关系、行动建议和必要说明。生成内容较长时，展示方式本身就是产品逻辑的一部分。
真正的验收也不该停在“云函数部署成功”。这次使用真实小游戏身份跑了一次完整任务：大约 13 秒后状态变为成功，进度到 100%；结果被领取后，任务记录自动删除。小游戏确实拿到了 AI 返回，而不是只在测试代码里假装成功。
目前 24 项小游戏测试已经通过，开发者工具也能正常预览。但它仍然只是可运行的内测版本：还没有上传体验版或正式发布，画布上的完整点击流程也需要继续手动真机检查。
迁移一个 AI 产品时，可以先问一句：最小闭环到底由哪些状态组成？
先把这条线跑通，再补动画、音效和更多功能，项目会清楚很多。觉得这套迁移顺序有用，可以先收藏。
