与 AI 协作的五步工作流

高效沟通不是一次写出最长的提示词，而是每一轮都知道要 AI 产出什么，以及你准备用什么标准评审它。

第一步：澄清问题，先暴露未知

提供需求简报，要求 AI 复述玩家目标，区分事实、假设和缺失信息。

这一步先不要让它追加大量功能。你可以要求：“只指出影响本轮实现的关键缺口，每个问题说明为什么必须先决定。”

产出应是一份你能修正的理解，而不是一段笼统的“我明白了”。检查相邻规则、失败恢复、资源扣除、当前局与新局等关键概念是否一致。

让 AI 针对同一个玩家目标给出两种可比较的方案，例如整屏规则与渐进提示。比较维度可包括理解成本、操作负担、异常复杂度、实现成本和验证方式。

不要同时换目标、玩法和视觉风格，否则难以看清差异。也别把 AI 偏好的方案当成已经证明更好。选择后保留理由与待验证假设。

规则不清时先用文字流程和状态表；信息顺序不清时用低保真结构；误触或反馈问题需要可操作原型。原型的精度应服务当前问题。

例如要判断“玩家知道只收集蓝色吗”，不必先接完整账号、支付和排行榜。一个能完成选择并显示目标变化的原型就能提供初步观察。

同时写明模拟边界：哪些是固定数据，哪些是假网络，哪些还没有真实平台 SDK。否则漂亮的原型容易被误认为完整实现。

实现指令要接上已确认的流程、状态与验收。要求 AI 保持现有工程约定，复用项目能力，说明新增依赖理由，并处理生命周期、重复事件和清理。

按已确认方案 B 实现，不新增本轮范围之外的功能。
先定位现有组件、规则和存档能力，说明准备复用什么。
保证状态转移、反馈和异常路径符合验收表。
完成后给出修改点、验证步骤、模拟部分和未验证边界。

自动测试可以检查计数、幂等、非法转移和存档校验；浏览器或设备测试可以检查真实输入、布局、事件和生命周期；玩家试玩用于判断是否理解和顺畅。

这三类证据各有范围。测试通过不证明玩法有趣，AI 自评“体验良好”也不能说明真实玩家没有障碍。

问题：玩家没有理解只收集蓝色。
证据：匿名试玩记录中出现反复消除橙色并询问计数的行为。
本轮改动：目标加形状与文字，首次操作提供就地提示。
保持不变：关卡规则、步数和奖励。
待验证：下一轮是否仍出现同类误解。

没有真实观察时，把证据栏写成“尚无，当前是假设”，不要让 AI 用顺畅的措辞填补空白。

回看最近一次与 AI 的长对话，找出一次返工。它发生在目标、规则、结构、实现还是验收层？写出如果提前增加哪一项可评审产出，能够更早发现问题。然后使用提示词示例开始下一轮。

本章是原创协作方法，不依赖特定模型、付费工具或引擎。真实观察的组织方式可参考 GOV.UK 的试玩式易用性测试方法。