本文目录
第一屏可玩是一个里程碑。修改后仍然正常、新访客能打开、离开平台后还能维护，又是不同的验收。本专题将本站已有记录串成阅读路径，没有新增生成测试，也不提供产品总排名。
先确定你要拿到什么
| 目标 | 从哪里开始 | 需要取得的证据 |
|---|---|---|
| 在浏览器验证小规则 | 五枚金币，三个流程 | 可操作预览中的输入、计分、结束和重开 |
| 继续编辑项目 | GDevelop 档案 | 可理解的事件逻辑、源码和资源依赖 |
| 发布到自己的网站 | 导出验收指南 | 实际构建在独立主机的新会话中运行 |
| 通过平台寻找玩家 | 作品发现也是工具能力 | 发布条件与发现数据的统计口径 |
| 调查工具选择 | 选择前的问题清单 | 账号资格、套餐条件与带日期的能力依据 |
例如，老师演示收集规则，可能只需要一个能够可靠重开的预览；要把项目交给另一名开发者，就需要可编辑源码与依赖说明；面向公众发布，还要检查新访客的第一局。目标不同，需要的证据也不同。
第一阶段：把需求写成可以验收的行为
从单屏、少量对象和明确结束条件开始。本站五金币需求包含移动、每枚金币只收集一次、计数、胜利后停止移动和两种重开方式。只用简单图形，让素材生成不干扰本轮实验。
生成前先写下预期行为。“做得好玩”难以一致验收；“五枚金币后显示 5/5 并停止移动”可以直接操作检查。同时记录账号套餐与停止预算，让后续结果保留具体条件。
第二阶段：修改后原有循环还在吗？
Rosebud 记录包含 10 月 10 日的一次速度修改，以及修改后的收集、胜利和重开复查；GDevelop 记录则包含一次重开修复。两者都涉及迭代，但不是相同任务。
修改前保留已知正常的版本。降低速度之后，除了速度，还要重新检查碰撞与重开。助手回复“修改成功”能够说明它报告了什么；操作结果才回答要求的行为是否保留。
第三阶段：区分预览、运行构建与可编辑源码
历史 GDevelop 实验中，实际 HTML5 构建在独立主机运行，但另行下载的源码仍有远程引用。Rosebud 当次账号无法导出；游点灵尝试则在主动停止前没有取得可操作预览。
这些结果回答不同问题。导出指南介绍入口文件、资源路径、外部请求和新访客会话的检查方法。如果另一个人要继续开发，还应在干净环境打开可编辑项目。拿到 ZIP 是取得初始产物，不能直接证明所有服务与许可都可迁移。
第四阶段：发布与被发现分别检查
公开链接能够正常运行，支持的是特定检查条件下的可访问性，不能证明推荐流量、持续游玩或收益。分发观察解释了为什么作品去向会影响工具选择。
TapTap 制造记录公开网页与本地 MCP 方向，Google Playground记录官方分享与导出说明。本站尚未通过这两款工具完成生成或发布验收。依赖这些路径之前，应调查资格与实际发布条件。
现有证据能支持到哪一步
| 产品 | 带日期的依据 | 边界 |
|---|---|---|
| Rosebud | 10 月 10 日小型桌面生成与修改 | 当次账号未取得导出包 |
| GDevelop | 10 月 10 日生成、重开修正与独立网页构建 | 另行可编辑源码仍有远程资源 |
| 游点灵 | 10 月 12 日中断的创作者会话 | 未验收可操作预览 |
| TapTap 制造 | 公开资料档案与工作流观察 | 未验收本地 MCP 与发布 |
| Google Playground | 官方公告与帮助文档核查 | 未验收编辑器及实际 ZIP |
来源与账号细节见各档案。这些是历史记录，不是现行套餐承诺。带日期的时间线将产品公告与本站检查分开。
一次小项目怎样留下可复查的结果
下面是一份建议执行的验收单，不是本站又完成了一轮测试。可以沿用五金币规则，每次只改一个参数，并把“看到按钮”和“按下后生效”分别记录。
| 操作 | 预期结果 | 不符合时怎样处理 |
|---|---|---|
| 移动并连续接触同一枚金币 | 只增加一次计数，金币消失 | 保留画面与输入步骤，先修碰撞或重复计分 |
| 收齐五枚，再持续按方向键 | 显示 5/5 和胜利，角色不再移动 | 先修结束状态，不扩充关卡 |
| 分别在进行中、胜利后使用按钮与 R | 玩家、五枚金币和计数全部恢复 | 分开记录四种组合，不能用一个按钮通过概括全部重开 |
| 只降低速度，再重复上述检查 | 速度改变，收集和重开不受影响 | 比较前后版本，撤回无关改动 |
| 用新会话打开分享或独立构建 | 无创作者登录也能加载并接收输入 | 区分可见性、权限、资源路径和服务依赖 |
| 把源码交给另一个干净环境 | 按说明能打开、修改并重建 | 列出缺失资源、依赖版本和平台专属服务 |
GDevelop 的历史例子说明了第三行为什么要拆开：首轮按钮重开通过，胜利后的 R 键却没有恢复游戏。Rosebud 修改后重新收集到胜利，才支持“原有循环仍在”的结论。游点灵停止前没有可操作预览，因此不能用助手自检文字填入这些通过项。
怎样记录预算，避免把一次余额当作单价
建议每次请求记一行：日期、套餐、模型、任务、请求前余额、请求后余额、实际等待、编辑器报告耗时、取得的产物以及未通过项。余额尚未结算时标为待确认，不提前计算成功游戏成本。
以历史 Rosebud 会话为例，8,000 到 6,200 对应首轮 1,800 credits，随后速度修改 400，合计 2,200。这个合计只覆盖当次生成与修改，不含导出、素材或长期制作。GDevelop 只有整体额度从 100% 到 20% 的记录，没有两次请求之间的余额，不能拆成生成和修复各花多少。游点灵的 113 积分差对应主动停止后的显示余额，不能作为成功产物价格，也未确认后续结算。
这些单位、账号与任务不同，不适合直接换算性价比。若独立托管是硬条件，预览已经通过但没有取得交付包时，应先解决导出门槛；若目标只是验证规则，就先记录已达到的阶段，再决定是否投入下一轮。成本问题与产物问题需要一起判断。
下一次怎样比较才更有意义
下一轮应统一需求、一个共同修改任务、账号条件记录与停止预算。记录每次请求余额及实际等待时间，编辑器报告时间单列。修改后重新验收核心循环，再在创作者会话之外检查分享或导出。
在可比会话积累之前，更有用的编辑结论是各流程停在哪里、下一步还需验证什么。有新记录支持下一交付阶段时，本专题再扩展，同时保留原实验日期与限制。