从功能讨论到上线
六阶段流水线

# 游戏开发流水线 · AI协作工作流 ## 一、任务 按六阶段流水线从功能讨论推进到上线，每阶段有明确的验收条件（DoD）。 ## 二、用户需定义 游戏平台：〔Web/小程序——决定技术栈和交互约束〕 游戏类型：〔RPG/卡牌/回合制/模拟——决定核心循环和数据结构〕 核心功能：〔本次迭代要实现的功能，如"战斗系统""装备系统""地图移动"——一次只做一个核心功能〕 ## 三、六阶段流水线 ┌─────────────────────────────────────────────┐ │ 阶段1 功能讨论 │ │ DoD: 核心机制描述清楚 + 验收标准可测量 │ ├─────────────────────────────────────────────┤ │ 阶段2 数据结构设计 │ │ DoD: JSON源完整 + 值域单入口 + 规则/数据分离 │ ├─────────────────────────────────────────────┤ │ 阶段3 图形与交互实现 │ │ DoD: 视觉可跑 + 交互可操作 + 核心循环可走通 │ ├─────────────────────────────────────────────┤ │ 阶段4 自检测试 │ │ DoD: 按验收标准逐条自测 + 每条有通过/失败记录 │ ├─────────────────────────────────────────────┤ │ 阶段5 体验测试 │ │ DoD: 实际游玩15分钟以上 + 记录3个以上反馈点 │ ├─────────────────────────────────────────────┤ │ 阶段6 修复 / 通过 │ │ DoD: 所有反馈点修复或标记延后 + 确认上线版本 │ └─────────────────────────────────────────────┘ ## 四、各阶段详细执行规则 阶段1 · 功能讨论 · 用玩家视角描述功能："玩家可以做什么→系统如何反馈→玩家得到什么" · 定义验收标准（可测量）："HP归零时战斗结束，显示胜利/失败界面" · 标注边界条件：极限值、异常输入、空状态 · DoD检查：验收标准足够具体吗？别人看了能直接写test case吗？ · 未通过DoD → 不可进入阶段2 阶段2 · 数据结构设计 · 原则：JSON唯一数据源 + 值域单入口 + 数据与规则分离 · 数据层：entities / config / items / skills——每类一个JSON · 规则层：formula / modifiers / hooks——在引擎中，不在JSON里 · DoD检查：数据源唯一吗？能改一条JSON就改变所有规则行为吗？ · 未通过DoD → 不可进入阶段3 阶段3 · 图形与交互 · 最小可跑版本：能看、能点、循环能走通 · 不堆视觉细节——先确认交互逻辑正确 · DoD检查：核心循环走完一遍了吗？所有交互元素都有反馈吗？ · 未通过DoD → 不可进入阶段4 阶段4 · 自检测试 · 按阶段1的验收标准逐条测试 · 每条记录：通过/失败/失败原因/修复方案 · 不允许"看起来差不多"——必须逐条确认 · DoD检查：所有验收项都有明确的通过/失败记录吗？ · 有失败项 → 修复后重新自检 → 全部通过才进入阶段5 阶段5 · 体验测试 · 实际游玩至少15分钟，以玩家身份操作 · 记录感受：哪里爽？哪里卡？哪里不知道下一步？哪里数值很难受？ · 至少记录3个反馈点——不做"感觉还行"的模糊判断 · DoD检查：有3个以上具体反馈吗？每个反馈有对应的优化方向吗？ 阶段6 · 修复 / 通过 · 修复所有阶段5的反馈点——或标记为"延后处理"并注明原因 · 确认上线版本——这个版本里有什么、没有什么 · DoD检查：所有修复已确认？延后项有明确理由？上线版本清晰？ ## 五、约束 1. 一次只做一个核心功能——不要试图讨论"整个游戏" 2. 每阶段DoD是硬门槛——不通过不进入下一阶段 3. 自检不是走过场——逐条确认，有失败记录 4. 以上为通用流水线。不同游戏类型的专项规则（如RPG数值平衡/卡牌概率验证）另作补充