从真实问题到评测回路：我如何判断游戏 AI 产品机会

先把四种信息分开

我不会从“游戏加上 AI 能做什么”开始，而是先区分四种容易混在一起的信息：

1. 真实体验记录：我实际遇到了什么任务、阻力或反馈。
2. 产品设计观察：现有系统如何组织角色、内容、进度和反馈。
3. AI 机会假设：哪些环节可能因为理解、生成、归纳或规划能力而改变。
4. 仍需验证的证据：要用什么样本、原型和失败记录判断假设是否成立。

这一步的作用不是把文档写得更完整，而是避免把模型能生成的内容当成用户事实，也避免把想法写成已经发生的结果。

[!NOTE] 本文讨论机会判断方法。没有真实体验范围、样本和运行记录时，不补写游戏时长、成绩、转化率或功能效果。

从用户任务而不是模型能力出发

一个机会是否值得继续，首先取决于用户正在完成什么任务。角色陪伴、内容生产、玩家帮助和增长实验都可能使用大模型，但它们的输入、风险和成功标准完全不同。

我通常先问：

• 用户现在如何完成这件事，最费力的步骤在哪里？
• 这个问题是缺少信息、缺少候选，还是缺少可靠决策？
• 结果需要事实正确、风格一致、操作安全，还是能够激发创意？
• 如果模型完全不可用，产品是否仍有清晰的降级路径？

只有当 AI 的生成、理解或规划能力能直接改变关键步骤，并且错误可以被发现、纠正或回退时，才值得进入原型阶段。

判断 AI 应该进入哪一步

我会把产品流程拆成“输入—处理—人工节点—输出—反馈”，再判断模型进入的位置。

环节	AI 可能承担的工作	人需要保留的判断
输入	归类、补全候选、发现缺失字段	确认事实与业务背景
处理	生成候选、检索信息、规划步骤	检查约束、版权与安全
输出	解释结果、给出多个版本	选择、修改或拒绝
反馈	汇总错误、形成下一轮假设	决定是否改变产品或流程

对于不可逆操作、敏感数据、高风险建议或会影响真实账户的动作，人工确认不是可选装饰，而是产品流程的一部分。

用最小原型验证数据契约

原型阶段优先验证三件事：

1. 用户能否提供模型真正需要的输入。
2. 模型输出能否进入后续产品流程，而不是停在一段流畅文本。
3. 失败时，用户能否理解问题并采取下一步。

因此，我更关注结构化字段、候选版本、来源证据、确认按钮和失败提示，而不是先追求完整界面。原型的作用是暴露产品假设，不是把未来功能包装成已经上线。

建立能回看的评测回路

评测至少需要保留任务、样本、模型、Prompt、运行条件、原始输出、人工判断和失败类型。只看平均分，往往会掩盖某一类关键失败。

我会把问题分成三层：

• 能力失败：模型没有正确理解、生成或检索。
• 工作流失败：输入不完整、人工节点缺失、状态没有传递。
• 产品边界失败：这个任务本身不适合交给 AI，或错误代价不可接受。

分类之后，下一轮迭代才知道应该改 Prompt、补数据、调整交互，还是收紧产品承诺。

记录失败边界，而不是只记录亮点

游戏 AI 产品尤其容易受到设定漂移、记忆误写、内容版权、过度拟人化和事实幻觉影响。每个机会判断都应同时写下：

• 哪些输入不足时必须停止或追问；
• 哪些输出只能作为候选，不能直接执行；
• 用户如何纠正、删除或退出；
• 服务不可用时如何降级；
• 哪些证据出现之前，不能宣称效果成立。

这些边界不是对创意的限制，而是让创意能够进入真实产品讨论的前提。

我最终如何做取舍

一个游戏 AI 机会值得继续，需要同时满足三个条件：它解决了明确的用户任务；AI 在关键步骤中有不可替代或显著增益；产品能通过人工节点、降级路径和评测记录管理失败。

如果其中任何一项还不清楚，我会把它保留为待验证假设，而不是升级成项目结论。这也是我整理项目案例和研究内容时使用的真实性边界。