简报只是点子。计划是待办列表。
Producer agent 读简报后写计划。每一行都必须 可测试 — 意思是之后能验证游戏是否做到了计划上写的事。
这一步约 30 分钟。是整个项目最重要的 30 分钟。
烂计划 vs 好计划
✗ 烂计划
"玩家会因为操作熟练而
感到被奖励。"
# "感到被奖励"是什么意思？
怎么测试？
✓ 好计划 "在峰值 100ms 内点击 → 连击 +1。 在窗口外点击 → 连击重置为 0。"
# 现在能测试了。
/规则
不能测试就不在计划里。
"感觉好"是营销。"100ms 内点击"才是计划。
模糊的计划变成模糊的游戏。每一行必须是数字、是/否、或具体行为。
计划长什么样
Producer agent 写 15-25 个编号项。每项一条规则。一起描述整个游戏。
# BOP — 计划
- 点击 = 球弹起
- 不点 → 球失去能量
- 碰刺 → 游戏结束
- 炸弹定时 = 3 秒
- 弹簧 = 双倍弹高
- 顶点点击 (±100ms) = 连击 +1
- 错过 → 连击重置
- 分数 = 高度 × 连击
- 4 个 boss 战 在 25/50/75/100
- 每个 boss 不同
- 最高分本地保存
- 不需要联网
- 音乐 80 bpm
- 每次弹起有音效
- iPhone SE 上 60fps ... 还有 8 项
✓ 23 项，全部可测试
/输出
23 条编号规则。这就是计划。
之后所有步骤（设计、编码、测试）都映射回这些编号。功能不在计划里 = 不会被做。
如果游戏后来失败在第 6 项，我们立刻知道哪行坏了。
4 列规则
每条规则都有 4 列。Producer agent 必须填全。漏列 = 规则没准备好。
# 每条规则 4 个部分
编号： 06 描述： 顶点点击得连击 触发： 玩家在球到达 峰值 ±100ms 内点击 验证： 顶点点击 → 连击 +1 窗口外 → 连击 = 0
# 4 列填不满， # 规则就还没可测试。
/结构
编号 + 描述 + 触发 + 验证。
Producer 写不出触发或验证不清的规则。表格强迫具体化。
这也是为什么之后能有 Tester agent — 每条规则自带测试方案。
常见陷阱
✗ 用"应该"、"尝试"、"感觉"
✗ 一条规则混合多个机制
✗ 让模糊规则混入交付
✗ 跳过 sanity check 因为兴奋
你能照搬的
拿你的一页简报。试着用 4 列格式写 20 条编号规则。
如果规则有"好"、"有趣"、"流畅"这类模糊词，换成数字或具体行为。
每条规则：
编号： (数字)
描述： (一行)
触发： (什么时候发生？)
验证： (怎么检查？)
如果每条规则都能填全 4 列，你就有真正的计划。