为 AI 放置游戏加入可靠存档和离线进度

从可运行的循环开始，让游戏进度可靠保存

放置游戏需要的不只是页面打开时不断增长的计数器。玩家希望已购买的升级在刷新后仍然存在、返回游戏时获得合理的进度，并且后续更新不会抹去已有成果。应把存档、离线结算和兼容性视为独立行为，分别进行检查。

本工作流延续一个示范性质的温室设计，并非现有的已生成或测试项目。点击获得虚构金币；每名购买的园丁每秒产出一枚金币。下一名园丁的价格为 ceil(10 × 1.15^n)，其中 n 是已拥有的园丁数量。先从一个能够正常赚钱和购买的循环开始。你将定义存档约定、计算设有上限的回访奖励，并在后续修改中保留进度，同时避免把本地存储与云存档混为一谈。

明确游戏需要记住什么

请求代码之前先写好存档约定。最小版本应包含数据结构版本、当前金币余额、园丁数量、已购买升级，以及收益已经结算到的时间。将产出速率规则与升级定义放在一起。应保存构成显示余额的购买记录，而不是保存互相矛盾的派生状态副本。

开发期间可以要求一个易读的存档摘要，以便比较游戏状态和已存储状态。诊断输出中不要暴露私人信息。还要区分本地存档和基于账号的存档：浏览器存储属于某个浏览器配置，也可能被清除。它不能保证跨设备进度、有安全保障的竞技余额，或玩家删除站点数据后的恢复能力。

使用这条范围明确的请求：

为金币、园丁、已购买升级和上次结算时间增加带版本的本地存档。显示可玩画面之前先恢复状态，并验证读取到的值。如果没有存档，则开始新游戏。如果存档无效，应说明恢复方式，而不是悄悄生成不可能出现的余额。保持现有美术和收益规则不变。

重要购买发生后应保存；如果游戏需要，也应定义定期保存。不要只依赖页面关闭事件，因为浏览器或设备可能停止运行，却没有触发你预期的最后事件。

离线奖励只结算一次，并设置清晰上限

离线进度通常指玩家返回时计算一笔奖励，并不要求浏览器关闭后游戏脚本持续运行。一条透明的规则是：

奖励 = 符合条件的已保存产出速率 × min(max(返回时间 − 上次结算时间, 0), 八小时)

实现之前先决定“符合条件的速率”是什么意思。在这个简单设计中，它指离开时存档中的园丁和升级所对应的产出速率。在基础结算正常工作之前，先不要加入复杂模拟。

作为预期值检查，两名园丁各自每秒产出一枚金币，在受控的十分钟时间段内应获得 1,200 枚金币。如果离开十小时，按照示例中的上限只计算八小时。将计算结果作为运行记录中的预期值。

发放进度后，游戏必须更新结算状态，确保刷新不会对同一次离开重复发奖。要求返回时显示采用的时长和发放的奖励。描述计算出的奖励时，不要暗示有持续运行的服务器。

离线奖励计算示例

以下示例假设产出速率固定、金币为虚构资源，并在明确注明的情况下采用两小时上限。这些是预期计算，不是对已测试游戏的实测结果。

分别测试存档和时间结算

首先赚取一个已知余额，购买一名园丁并刷新，确认余额和购买记录都得以保留。接着关闭浏览器，等待一段实测时间后返回。记录起始状态、实际经过时间、观察到的奖励和最终状态。立即再次刷新，检查是否重复发放同一笔奖励。

长时间间隔可使用受控测试时钟；普通路径则应进行一次真实的关闭和返回检查。测试负的经过时间、不合理的大时间间隔、空存档和损坏存档。在查看结果前，先说明每种情况应如何处理。负时间间隔不应扣除已获得的货币；过大的时间间隔不应绕过上限。

玩家可以更改本地设备时间。限制经过时间有助于防止明显错误，但不能让本地经济系统变得防篡改。竞技或付费经济系统需要单独设计权威结算和安全机制。

回访测试表

后续增加升级时，不重置玩家进度

存档功能正常后，请求一次小范围内容修改：

将未来购买园丁的基础价格从十枚金币改为八枚，保持 1.15 的增长系数。保留现有金币、园丁、已拥有升级、美术和离线结算。支持当前的存档数据版本。如果新状态需要额外字段，说明如何迁移旧存档。

提出请求前，保留一份真实的修改前存档和一个可用版本。将该存档加载到修改后的版本，比较余额、购买记录和产出速率。不能因为旧存档缺少新字段，就丢弃整个状态。调整经济系统之前，先决定早期购买是否保留其收益。

如果升级消失，先检查迁移和加载，再添加功能。出现新按钮不等于证明存档兼容。

使用 SEELE 进行范围明确的存档修改

SEELE 提供通过提示创建游戏并请求后续修改的工作流。这里的相关输入是可运行的经济系统和具体的存档约定；期望输出是一个可供检查加载与结算行为的候选修改。在请求迁移或新升级之前，先要求最小范围的持久化修改。

在待评估的修改之外保留一个可用版本和一份基线存档。检查失败时，报告确切的状态差异，包括问题发生在加载、返回还是购买阶段。产品定位本身不能证明云存档、安全时钟、迁移保证，或某个本地存储实现的可靠性。

确认回访体验合理后再继续

可靠的放置游戏应解释数字从何而来：什么产生了奖励、计算了哪段离线时间，以及玩家仍拥有哪些购买。可以借助 AI 对这些规则进行范围明确的修改，再在运行中的游戏里判断每次变化。不要为了更长的功能清单牺牲可用存档。

在现有项目中使用 SEELE 请求一个本地存档和一笔设有上限的回访奖励。再次修改经济系统前保留已知可用版本。下一个里程碑不应是更大的承诺，而是一次经过验证、玩家原有进度仍然完整的回访。

常见问题

离线进度是否意味着浏览器关闭时游戏仍在运行？

不一定。常见做法是保存状态和结算时间，在下次访问时计算奖励。这可以实现离线奖励设计，而无需浏览器进程持续运行。描述该功能前应检查实际实现。服务器端模拟是不同的架构，不应由本地计算奖励暗示出来。

浏览器存档会转移到其他设备吗？

不要这样假定。本地浏览器存储通常与该浏览器配置和站点存储绑定。跨设备存档需要明确的同步或账号系统，以及冲突处理和隐私方面的决定。应告诉读者经过测试的演示实际使用了什么，而不是把本地持久化示例说成云存档功能。

玩家已经玩过后，还能更改升级价格吗？

可以，但修改后的设计必须定义如何处理已有购买和存档状态。保留一份基线存档，决定哪些收益仍由玩家拥有，并在发布修改前测试迁移。直接覆盖价格列表不能证明旧进度仍然有效。如果行为尚未测试，应将其描述为要求，而不是成功更新的结果。