AI 生成的游戏完成后，还能继续开发吗？

游戏能在浏览器里打开，并不代表这个项目可以持续开发。接下来更有价值的问题是：其他人能否复现项目、解释规则，并在不破坏原有游戏流程的情况下增加一项功能？检验方法是保留基线并设计范围明确的扩展，而不是只看截图或相信“代码可编辑”的说法。本文为一款小型星星收集游戏定义了可复现的后续开发测试，但并非已完成的实操报告：撰写本文时没有可用的源项目、基线运行记录或扩展补丁，因此真实结果仍待取得。请用这套方法收集缺失证据，不要把验收条件当作对 SEELE 或任何生成项目的实测结论。

1. 确认项目及原有规则

采用范围明确的测试样例：桌面浏览器游戏，使用方向键移动，有五颗可收集星星、30 秒回合、集齐获胜、超时失败和完整的重新开始流程。这是计划中的测试样例，并非现有成品。取得实际可编辑项目、素材、依赖声明和启动说明。记录可见的生成器或工具版本、项目版本、运行环境、浏览器和操作系统。

区分源文件、在线预览和编译后的产物。缺失素材、未说明的依赖或无法取得源文件，都应作为发现记录，而不是悄悄补齐。如果提供的项目与样例不同，先记录它原有的规则，再选择范围相当的扩展。保留一份未修改的副本和一份独立工作副本，避免后续修改抹去原始证据。

2. 修复之前先复现基线

在干净目录中按照提供的说明配置项目。保存确切命令、安装输出、启动日志和浏览器控制台信息。不要因为项目看起来像熟悉的框架，就自行猜测命令。配置失败时保留错误，并单独记录任何人工干预。由评估者修复后才运行的基线，应标注为已修复，而不是把原项目记作无条件成功。

运行四种情境：收集一颗星星并停在原处；集齐五颗；等待计时器归零；在每种结局后重新开始。检查每颗星星只计数一次、结局出现后移动被冻结，以及回合状态全部恢复。逐项记录操作、预期结果、实际结果和项目版本。失败记录应与成功记录同样妥善保存。

3. 追踪准备修改的规则

找到实际代码或可编辑逻辑，追踪移动、接触检测、收集状态、显示计数和获胜判断之间的关系。在记录中使用真实文件名或事件标识，并说明计时器由哪部分负责、哪个重置操作会恢复它。看起来合理的 AI 解释还不够，必须对照项目验证。

留意重复计数器或分散在无关系统中的重置逻辑。这些是需要审查的问题，不自动证明架构不好。实际目标是确定奖励拾取物应该放在哪里，以及哪些现有行为必须保持不变。请求补丁前先记录不确定点。

4. 在同一项目中加入一颗蓝色奖励星

保存基线版本，然后只请求这一项修改。示例有意将新增的时间奖励与原有收集计数分开：

在现有游戏中增加一颗蓝色奖励星。有效回合中首次接触它时，移除该星星并将剩余时间增加三秒。它不得增加普通星星计数，也不得改变集齐五颗星星的获胜门槛。重新开始时恢复奖励星。已经结束的回合不能被重新激活。保留移动、普通星星、超时以及所有原有结局规则。提出最小补丁之前，先确认实际受影响的项目文件或事件。不要替换游戏或无关素材。

执行前审查拟议修改，记录变更的文件或事件、新增依赖及任何结构调整。如果无关子系统发生变化，应询问原因。即使预览相似，一个全新制作、带蓝色物体的独立游戏也不能证明原基线得到了继续开发。将补丁与解释一起保存，让其他审查者能检查同一版本。

5. 复测旧行为、新边界和回滚

重复所有基线情境。然后收集一次奖励星并停在原处：时间应只增加一次，普通星星计数不应变化。重新开始后再次收集，验证重置。检查临近超时以及回合结束后的接触；新拾取物不能让已结束的回合恢复运行。如果同时发生的事件可能影响结果，应记录帧处理顺序的假设。

检查失败时，先保存失败版本和简短复现步骤，再请求修复。回滚到保留的基线，并重新运行一项基线情境；只有通过这一步，才能报告已复现回滚。本文尚未证明补丁成功、没有回归、修复所需时间或回滚结果。

SEELE 可以参与什么，哪些内容仍须验证

SEELE 介绍了一种使用自然语言创建游戏、涉及场景、素材和玩法代码的工作流，因此可以把小型生成游戏作为这项测试的起点。先提供简短游戏需求，再核实当前流程实际交付的是可玩结果、可编辑项目、源文件还是其他产物。这些交付物不能相互替代。

进入后续开发阶段时，提供现有项目上下文和唯一的奖励星要求。检查实际修改，而不要假定自然语言修改一定能正确保持状态。项目访问权限、引擎兼容性和导出细节都需要在实际账号及输出中确认。产品介绍支持尝试该流程，但不能证明此项目的可复现性、架构或可维护性。

形成真实结论需要哪些证据

• 原始源文件或可编辑项目归档、所需素材和稳定的基线版本。
• 实际配置说明、环境信息、命令输出，以及启动错误或修复记录。
• 基线情境记录，以及获胜、失败和重新开始的连续运行证据。
• 与真实代码或事件对应的解释、确切扩展请求和可检查的补丁。
• 修改前后版本、回归与边界检查记录，以及已经复现的回滚。
• 仅针对该项目和该扩展的结论，并列出尚未解决的问题。

目前所有承载结果的材料都仍然缺失。即使奖励星修改成功，也只能支持范围有限的后续开发结论，不能据此承诺网络功能、存档迁移或生产规模开发能力。交接不完整时，应在报告中明确保留这一情况，而不是用笼统的“AI 代码可编辑”结论代替。

结语：先收集下一次修改所需的证据

用能经受审查和回归测试的修改来判断项目是否能够继续开发。从可复现的项目材料开始，保留原始规则，并将扩展控制在意外修改容易被发现的范围内。本文提供的是方法，不是缺失的测试结果：在项目、补丁和运行证据齐备之前，实操可维护性结论仍无法得出。下一步可在 SEELE 使用小型星星收集游戏需求，并在请求奖励星之前保留实际交付物。如果缺少源文件或配置失败，就停下来记录障碍，不要把精美预览当成能够继续开发的证明。

常见问题

在线预览能证明游戏具有可维护性吗？

不能。在线预览可以展示看得见的游戏行为，但不能证明源文件完整、配置可复现，或代码修改会产生什么后果。它只是证据的一部分。要支持后续开发的结论，还需要可编辑材料、保留的基线、可检查的修改，以及目标运行环境中的回归检查。

进行这项测试需要程序员吗？

不懂编程也可以记录面向玩家的测试情境，但可靠的源文件和依赖审查需要熟悉项目语言或编辑器的人参与。应区分这些职责。请合格的审查者验证实际修改，不要把 AI 自信的解释或一个能打开的画面当作架构审查。

扩展功能可用，但配置仍没有文档，怎么办？

应报告为部分成功，而不是完整交接。扩展可能在已经配置好的环境中可用，新开发者却仍然无法复现。保留成功的版本，写下实际使用的配置步骤，并从交付材料重新执行这些步骤，再称该项目可以独立复现。