1. 实际得到什么？
比较工具前先定义结果：可玩的浏览器链接、可编辑项目、可下载代码，还是视觉实验？这些输出不能相互替代。应要求查看符合所需输出的真实例子。
2. 能否修改具体行为？
首次结果只是起点。尝试修改一条规则、修复一个错误、恢复旧版本，并记录局部修改是否破坏无关行为。我们尚未对列出的产品执行这些测试。
3. 发布需要什么？
以新访问者身份打开分享结果，检查登录、设备与付费要求。确定能否离开工具生态发布，以及订阅结束后会发生什么。
4. 适用哪些权限？
检查生成内容、上传素材、第三方材料和商业使用的当前条款。产品能在技术上生成内容，并不解决是否有权发布的问题。
5. 谁维护结果？
考虑持续托管、编辑、依赖更新与失效资源。最快的首次制作流程，未必是最容易维护的流程。
如何使用清单
选择一个小而可重复的游戏创意，对每款工具使用相同条件。记录日期、套餐、耗时，以及失败和成功。这是建议的评估方法，不是对比测试结果，也不是对关联产品的排名。
一项可以重复的首次实验
使用原创且范围明确的小需求：单屏收集游戏、30 秒倒计时、可见分数、一种危险和重开按钮。生成前先说明输入方式与目标设备。具体题材不是重点，关键是拥有可以反复检查的完整循环。
| 阶段 | 验收条件 | 记录内容 |
|---|---|---|
| 首次可玩结果 | 移动、收集、危险、计时与结束能共同工作 | 缺失行为与尝试次数 |
| 定向修改 | 倒计时改为 45 秒，同时保留移动与计分 | 预期修改及其他功能退化 |
| 恢复 | 不重建整个游戏，恢复原倒计时 | 能否找回早期版本 |
| 发布 | 新访客能在目标设备进入并重开 | 登录、加载、输入和分享门槛 |
| 交接 | 获得需求中指定的链接、构建或项目 | 实际文件与持续依赖 |
这些数字是实验参数，不是产品性能结果。不要要求素材生成器完成整款游戏任务；应评估它的资源导入已有项目的过程。
先决定必要条件，再看额外效果
把要求分成必须满足、后续可改进和本次不做。例如手机可玩的链接是必要条件，自定义音乐可选，在线多人超出范围。如果必需产物不支持、访问资格未解决，或时间与额度预算用尽，就应停止。继续生成不一定能消除结构性限制。
将需求、初始结果、定向修改和发布链接保存在一起，后续对比才有依据。单一综合评分会掩盖真正失败的是哪项要求。