给合成游戏加存档、奖励与排行
玩法能运行之后，再加入存档、广告奖励和排行榜。此时应保持一条原则：平台返回结果，由明确的业务入口解释；平台回调不随意修改场景。
本地存档怎样连接
规则提交成功后标记棋盘需要保存。存档内容包括格式版本、格子等级、分数、必要进度，不包括临时拖拽物体或特效。
启动时先读并验证存档，再生成棋盘视图。读取失败时恢复默认局或备份，并提示适当信息。不要先生成一局，再被晚到的存档读取消掉玩家刚完成的操作。
广告奖励是一段状态流程
具体回调和奖励条件必须依据当前微信官方 SDK。不同广告类型的事件含义不能混用。客户端防重复点击只是第一层；涉及永久资产时，还要有服务端请求标识、可信校验和可查询的结算状态。
奖励物品放到哪里
“看广告送物品”还缺几个产品决定：棋盘满了怎么办、给哪个等级、放哪一格、用户中途退出是否还能领取、重复回调如何处理。
本案例建议先采用明确的“待领取奖励”记录：结算成功后保存奖励权益，真正放置时再检查棋盘空间。这样不会因为广告刚结束时棋盘已满，就悄悄丢失奖励。是否采用取决于你的产品规则，代码示例不能替你自动决定。
排行榜不是直接上传最高分
纯本地游戏可以显示本地记录。公开排行若要求可信，就需要服务端校验可接受的行为、进度或结算结果。只把客户端分数写进数据库很容易被修改。
验证强度应匹配产品价值。简单休闲游戏也不必从第一天建立完整战斗回放系统，但需要知道当前方案能防什么、不能防什么。
编辑器替身与真实平台
在编辑器里可以用明确标注的模拟广告与登录返回值，方便开发失败路径。真实微信实现则通过适配层接入。不要让模拟成功分支混入生产，或者把浏览器演示当成平台能力验证。
一张接入验收表
| 场景 | 预期 |
|---|---|
| 广告展示失败 | 不发奖，恢复按钮，可重试 |
| 重复完成回调 | 同一奖励只结算一次 |
| 服务端已发奖但响应丢失 | 可查询恢复，不盲目再次发奖 |
| 棋盘已满 | 奖励按产品规则保留或明确拒绝 |
| 无网启动 | 能继续允许的本地玩法，显示联网能力状态 |
| 切换账号 | 不混用前一个账号的云数据 |
给 AI 接入任务时同时提供服务端协议、身份流程和平台版本。没有这些上下文，先设计接口与模拟，不要编造一个“真实可用”的广告或登录 API。