vertical-slice

!bash "${CLAUDE_SKILL_DIR}/../../hooks/yaml-helper.sh" resolve_config --keys review_mode,automation,workflow

已在上方解析——按原样使用；--review 会覆盖本次运行的 review_mode。未被阻止 → 使用 .claude/docs/config-resolution.md 中的默认值。

垂直切片

目的

垂直切片要回答一个与概念原型不同的问题： “我们能否按计划以生产级质量构建完整的游戏循环？”

默认用法——在预制作阶段后期运行，此时 GDD、架构和 UX 规格均已完成。这是一个接近生产级质量的构建，用来展示一个完整的[开始 → 挑战 → 解决]循环。

经历过转向之后？ 如果先前垂直切片的 PIVOT 结论让你回去修订 GDD 和架构，请在修订后再次运行，以重新验证。可按需多次运行，直到得出 PROCEED 或 KILL 结论。

它会验证：

1. 流程管线（团队是否真的能产出这种质量的内容？）
2. 执行可行性（架构决策是否适用于这款游戏？）
3. 趣味性是否留存（概念原型中的乐趣在完整设计后是否依然存在？）
4. 速度（耗时多久？这才是你真实的生产速度估算。）

项目处于更早阶段？ 如果你还没编写 GDD，只想验证核心创意是否值得设计，请改为运行 /prototype（概念原型）。

---

阶段 1：确定评审模式并加载上下文

完整的检查模式请参阅 .claude/docs/director-gates.md。各项关卡的定义位于 .claude/docs/director-gates/[gate-id].md——被启动的 Agent 会读取自己的关卡文件；不要在父会话中读取。

每次调用 AskUserQuestion 都遵循 .claude/docs/automation-modes.md （协作模式始终提问 · 引导模式仅对重大事项提问 · 自主模式记录并继续； automation_always_ask 类别始终会提示）。

请阅读以下文件，以了解完整的设计意图。按章节阅读各个 GDD、ADR 和控制清单：使用 Grep 工具查找所需标题（模式 ^#，内容模式），再使用 Read 工具通过 offset 和 limit 读取相应范围。

• CLAUDE.md — 技术栈和引擎
• design/gdd/game-concept.md — 核心幻想和游戏支柱（或者 design/game-brief.md，在 rigor: minimal 时取代前者的一页式简报——包含卖点、核心循环和“玩家感受”描述；不包含游戏支柱）
• design/gdd/systems-index.md — MVP 系统及其优先级
• docs/architecture/architecture.md — 分层结构
• docs/architecture/control-manifest.md — 实现的技术规则
• 切片涉及系统的关键 GDD

---

阶段 2：定义切片范围和验证问题

开始构建之前，先定义可证伪的验证问题：

“玩家从零开始，在 [N] 分钟内，是否能体验到 [game-concept.md 或 game-brief.md 中的核心幻想]，且无需开发者指导？我们能否在 [X] 天内，以具有代表性的质量构建出这样一个循环？”

这两个方面都很重要：玩家体验和构建可行性。

范围纪律：

• 至少包含所有核心循环系统。如果完成一个 [开始 → 挑战 → 解决] 循环需要某个系统，那么该系统就必须包含在切片中。
• 目标范围：3–5 分钟打磨完善、连贯的游戏体验。 这是业内垂直切片的标准时长——足以展示机制和基调，又足够短，能以具有代表性的质量完成构建。如果你的切片需要超过 5 分钟才能体验完，就删减内容，而不是降低质量。
• 先缩减范围，再降低质量。 低质量的切片如果看起来与预期游戏毫无相似之处，就无法验证制作可行性。
• 如果范围大到需要超过 1–3 周才能构建，说明切片范围不合理——不是游戏太大而无法构建，而是切片试图一次证明太多内容。

范围蔓延警告： 在预制作阶段，垂直切片是范围蔓延风险最高的时刻。功能看起来“差不多完成了”，很容易让人想再“加一个系统”。请克制这种冲动。应该删减，而不是扩展。

开始构建前，先向用户说明范围并获得确认。

---

阶段 3：规划构建

用项目符号列出：

• 已实现的系统（涉及哪些 GDD 章节）
• 完整的游戏循环（严格按照 [开始] → [挑战] → [解决]）
• 美术和音频质量等级（可使用占位内容，优先采用具有代表性的内容）
• 针对验证问题的具体、可衡量的成功标准
• 明确的时间上限：[X] 天。如果超出，就说明范围不合理——停止并重新评估。

开始构建前，请用户确认范围。在确认中注明检查点文件：“我可以将此计划记录到 production/session-state/active.md 吗？”

确认后，将会话检查点写入 production/session-state/active.md（如果 production/session-state/ 不存在，则创建该目录）。写入以下内容：概念名称、验证问题、范围内的系统、美术质量等级以及当前阶段（“Phase 4 — Implement”）。每个构建日结束时，更新此文件，记录已完成的内容。如果会话在切片完成前结束，这就是主要的恢复机制——为期数周的 Engine 构建会跨越多个会话。

---

阶段 4：实现

询问：“我可以创建垂直切片目录 prototypes/[concept-name]-vertical-slice/ 并开始实现吗？”

如果可以，就创建该目录。每个文件都必须以以下内容开头：

[comment] VERTICAL SLICE - NOT FOR PRODUCTION
[comment] Validation Question: [What this build is proving]
[comment] Date: [Current date]

在每个文件中使用其自身注释语法编写 [comment]：GDScript（.gd）和 Python 使用 #，C#、C++ 和 JavaScript 使用 //，Lua 使用 --，HTML 和 Markdown 使用 ``。使用其他语言语法编写头部会导致解析错误，而不是标签。 无法包含注释的文件（JSON、引擎生成的场景和项目文件）不受此要求限制。

质量标准——高于概念原型，但未达到正式生产级别：

• 遵循 docs/architecture/control-manifest.md 中的架构分层
• 命名规范——project.yaml 中的 naming.*；对于缺失或为空的任何键（包括 project.yaml 中没有 naming 块的情况），使用 .claude/docs/technical-preferences.md 中的规范
• 不要硬编码游戏玩法数值——使用常量或配置文件
• 在关键路径上进行基本错误处理
• 可以使用占位美术资源；优先使用能体现实际效果的美术资源

**多轮循环：**写入初始文件后，请用户运行构建并报告观察结果。反复迭代，直到能够演示完整的游戏循环。每轮：

1. 用户运行 → 报告错误或观察结果
2. Agent 修复错误或调整系统
3. 重复以上步骤，直到完整的 [开始 → 挑战 → 解决] 循环可以游玩

**沉没成本检查点（计划时间线的第 3 天）：**如果还无法演示完整的游戏循环，就停下来重新评估。要么是范围太大，要么是架构假设有误。明确指出阻碍，而不是继续迭代。

游戏循环可以演示后，至少进行 1 次试玩。

**试玩提示：**如果能找到没玩过这款游戏的人试玩——朋友、家人或线上社区成员——请默默观察，不要做任何解释。不要引导他们。他们的困惑会揭示游戏本身没有传达清楚的内容。这比自测能提供好得多的反馈。

**没有外部测试者？**在团队内轮换：开发者 A 构建了系统 X，因此开发者 A 可以作为不了解系统 Y 的测试者。即使是两人团队，也可以有效轮换。只有你一个人？离开 2-3 天后，再以新玩家的身份完整体验一遍——你不会获得完美的第一印象反馈，但能发现关键阻碍。还可以尝试“静默体验”：一口气试玩自己的切片，不停下来修复任何问题，并记录每一次犹豫的时刻。

想要更丰富的观察数据？请测试者在游玩时边玩边说——实时讲述他们在做什么以及原因。“我在想怎么攻击……我按了 E……没反应……是点击吗？”这样可以在困惑发生时立即发现，而不是事后回忆。最适合验证新手引导和 UI 清晰度。静默观察仍更适合体验感测试；边玩边说会稍微改变体验，但能产生细致得多的 UX 数据。

**异步远程选项：**录制 Loom 或 OBS 视频——把构建版本交给对方，请他们录制屏幕和音频，然后把视频发给你。这样无需同步安排时间，也能获得真实的第一印象数据。适用于不同时区。

**要在 AI、NPC 或复杂系统行为完全实现前进行测试？**使用 Wizard of Oz 技巧：一个人正常游玩，另一个人则在幕后实时控制 NPC 或系统行为。玩家会以为这些行为是自动化的。这样可以在 AI 或经济系统实现完成前验证其设计意图，并准确揭示系统必须产生哪些行为，才能让体验符合预期。特别适用于 AI 系统在范围内、但尚未打磨到可以无引导测试的垂直切片。

---

阶段 5：试玩复盘

循环已经可以演示。在撰写报告之前，先通过实际游玩收集结构化观察结果。切勿跳过这一步直接生成报告——报告的质量取决于你在此收集的观察结果。

请原样说出：

“从头开始完整体验一次 [开始 → 挑战 → 解决] 循环，假设你是一名不了解其构建过程的新玩家。不要跳过内容，也不要使用开发者捷径。完成整个循环后再回来——或者遇到阻碍你继续的情况时回来。”

用户回来后，逐个提问：

1. 循环完成情况：

   “你是否独立完成了整个 [开始 → 挑战 → 解决] 循环，没有得到我的任何指导，也不需要事先了解构建过程？”

2. 时间检查：

   “你花了多长时间才完成第一个有意义的操作——也就是你感觉自己真正开始玩游戏的第一个时刻？”

3. 核心幻想：

   “这款游戏应该让你感受到 [game-concept.md 或 game-brief.md 中的核心幻想]。你有这种感受吗？请如实回答——不要只说‘有点’，而要具体说出你的感受以及它发生的时间。”

4. 阻碍因素：

   “有什么事情阻碍了你、让你困惑，或让你脱离了体验？有没有哪一刻你不确定该做什么，或者遇到了故障？”

5. 开发流程检查：

   “作为开发者——而不是玩家——你觉得以这种质量完成整款游戏是否可行？构建过程中，有什么耗时情况让你感到意外？”

6. 结论：

   “继续、转向，还是终止——具体原因是什么？”

如果任何回答含糊不清，请追问：“能告诉我当时具体发生了什么吗？” 准确的观察结果会填充报告。含糊的回答只会产出毫无用处的报告。

只要有一项验证结果为“否”，就不能选择“继续”。 /gate-check production 会判定已构建的切片未通过，只要其纵向切片验证中有任何一项为“否”：玩家无需开发者指导即可完成循环（问题 1）；玩家在前 2 分钟内了解该做什么（问题 2——超过 2 分钟即为“否”）；核心机制体验良好（问题 3）；没有阻碍乐趣的重大错误（问题 4）。如果其中任何一项答案为“否”，结论必须是“转向”或“终止”——由用户选择——报告中也会标明该项为“否”。

“尚未评估”是第四种结论。 如果还没有人从头开始体验完整循环——例如用户本次无法游玩，或在结束前就停止了——那么验证尚未进行，结论应为尚未评估，并注明原因。其优先级高于“继续”，但低于“转向”和“终止”：未体验过的切片还不够格获得“继续”，而已知未通过的切片比无人体验过的切片更便于采取行动。绝不能将其记录为“继续”。

---

第 6 阶段：生成垂直切片报告

在构建过程中持续记录进度。记录：

• 第 1 天：构建了什么
• 第 2 天：构建了什么
• 依此类推

这是你能获得的关于实际生产速度最真实的数据。不要跳过。这些数据会直接用于冲刺规划（在 workflow: minimal 模式下没有冲刺，则用于概要中的构建顺序）。

阅读 .claude/docs/templates/vertical-slice-report.md，了解报告结构。 如果找不到模板文件，请使用以下备用结构：

• ## 垂直切片报告 — [Game Title] — [Date]
• ### 执行摘要（PROCEED / PIVOT / KILL / NOT ASSESSED 判定 + 2 句话说明理由）
• ### 核心循环验证（测试了什么、哪些通过、哪些失败）
• ### 手感评估（动画、操控、反馈——主观记录）
• ### 技术发现（性能、引擎问题、架构风险）
• ### 进度日志（按天记录实际进度——不要跳过）
• ### 经验教训（构建到接近量产品质后被打破的假设；关于流水线或架构的意外发现；下次会如何调整切片范围）
• ### 后续建议

根据本次会话中观察到和构建的内容，填写每个部分。 进度日志必须反映逐日实际进度，而不是估算值——这是你能获得的关于生产速度最真实的数据。将所有占位文本替换为实际观察结果。建议部分应沿用第 5 阶段的判定，包括 NOT ASSESSED 及其理由。

询问：“我可以将此报告写入 prototypes/[concept-name]-vertical-slice/REPORT.md 并在 prototypes/index.md 中添加对应条目吗？”

如果可以，就写入文件。然后更新 prototypes/index.md（如果不存在则创建）——在垂直切片表格中追加一行，包含概念名称、日期、判定结果和指向 REPORT.md 的链接。注明这是首次运行切片，还是 PIVOT 后重新运行。此报告中的进度日志是项目中最有价值的数据之一——请将其与冲刺估算交叉对照。

---

阶段 7：创意总监评审

评审模式检查：

• solo → 跳过。备注：“CD-PLAYTEST 已跳过 — Solo 模式。”
• lean → 跳过（不是阶段关卡）。备注：“CD-PLAYTEST 已跳过 — Lean 模式。”
• full → 使用关卡 CD-PLAYTEST（.claude/docs/director-gates/cd-playtest.md），通过 Agent 启动 creative-director，除非该切片的评估结果为 NOT ASSESSED：尚未进行试玩，因此无内容可供评审；备注：“CD-PLAYTEST 已跳过 — 尚未试玩该切片。”

提供完整的 REPORT.md 内容、验证问题，以及 design/gdd/game-concept.md 中的游戏支柱和核心幻想（或在 rigor: minimal 时提供 design/game-brief.md 中的简述和“玩家感受”一行）。

创意总监根据游戏的创意愿景和支柱评估垂直切片结果，并返回关卡给出的其中一种评估结果 — APPROVE、CONCERNS 或 REJECT。将其应用于建议：

• APPROVE → 建议维持不变。
• CONCERNS → 在建议旁展示相关顾虑，然后使用 AskUserQuestion：修改建议 / 接受并注明顾虑 / 进一步讨论。由用户决定；创意总监不做决定。
• REJECT（核心幻想未体现）→ PROCEED 建议不能成立。使用 AskUserQuestion 请用户选择 PIVOT 或 KILL，并针对该选择运行阶段 8。PIVOT 或 KILL 建议维持不变。
• NOT ASSESSED [缺少输入] → 创意总监未做出判断，因此既不支持也不推翻该建议（.claude/docs/director-gates.md）：说明缺少什么，然后补充该内容并重新运行关卡，或在报告中记录 CD-PLAYTEST: NOT ASSESSED — [input]。

当创意总监返回 CONCERNS、REJECT 或 NOT ASSESSED 时，询问“我可以更新 prototypes/[concept-name]-vertical-slice/REPORT.md 及其中的 prototypes/index.md 行吗？”，然后在 REPORT.md 中记录创意总监的评估结果及原因；如果最终建议有所变化，则在两处都记录。

阶段 8：总结和后续步骤

输出总结：验证问题、速度数据和最终建议。 链接到 prototypes/[concept-name]-vertical-slice/REPORT.md。

如果是 PROCEED： 你的垂直切片已验证完整的游戏循环。项目已准备好进入 Production 阶段。

在 workflow: minimal 下：运行 /create-stories（基于简报），然后对第一条故事运行 /dev-story——此列表其余部分适用于 standard/full 路径。

建议的后续步骤（standard/full）：

• /create-epics layer:foundation — 规划 Foundation 层史诗
• /create-epics layer:core — 规划 Core 层史诗
• /create-stories [epic-slug] — 将每个史诗拆分为可实现的故事
• /sprint-plan — 使用切片的速度数据规划第一个冲刺
• /gate-check production — 正式将阶段推进到 Production

试玩说明：/gate-check 会检查是否有记录在案的试玩证据。 至少需要 1 次有记录的试玩，并提供显示 PROCEED 的 REPORT.md，才能通过关卡。 更多试玩能提供更可靠的信号——在让整个团队投入 Production 之前，建议进行 3 次或更多试玩，但这不是硬性关卡要求。

如果是 PIVOT：

在转回 GDD 修订之前，先记录后续备注。依次提出以下两个问题（纯文本，一次一个）：

1. “在当前质量水平下，哪些系统或机制表现良好，应该在修订后的设计中保留？”
2. “具体来说，哪些方面失败了——核心循环、架构、流程，还是乐趣？”

询问：“我可以将这些内容写入 prototypes/[concept-name]-vertical-slice/PIVOT-NOTE.md 吗？”

如果可以，写入文件，内容包括：哪些方面表现良好、哪些方面失败、需要修订的具体系统或架构决策，以及下一次切片需要证明哪些不同之处。当 PIVOT 后再次运行 /vertical-slice 时，检查 prototypes/ 目录中是否有 PIVOT-NOTE.md——用它来构建新的验证问题，并为范围决策提供参考。

• 使用 /design-system [mechanic] 修订受影响的 GDD
• 通过 /architecture-decision 解决架构问题
• 然后重新运行 /vertical-slice，验证修订后的方向

如果是 KILL：

在放弃该概念之前，先确认这一结论是否合理：

• 即使是经验丰富的玩家，完整游戏循环也需要超过 5 分钟？
• 任何一次试玩中都没有观察到情感高潮（愉悦、惊喜、满足感）？
• 经过 2 次或更多切片尝试后，仍有 50% 以上的测试者在同一处感到困惑或卡住？
• 架构问题是否需要重建已完成内容的 50% 以上？
• 这是同一概念的第 3 次垂直切片尝试？

如果有 2 项或更多适用 → KILL 结论合理。如果有 0–1 项适用 → 针对性 PIVOT 一次或许能挽救该概念。

在 prototypes/GRAVEYARD.md 中记录放弃决定（如果文件不存在，则创建该文件）。 询问：“我可以将此条目追加到 prototypes/GRAVEYARD.md 吗？”如果可以，添加一条记录：

## [Concept Name] Vertical Slice — YYYY-MM-DD
- **Kill reason:** [what specifically prevented the player from experiencing the core fantasy]
- **What worked at slice quality:** [systems or mechanics that held up]
- **What failed:** [core loop issue, architecture decision, or pipeline blocker]
- **Next time:** [one specific change for the next time a similar concept is attempted]

• 带着你的收获返回 /brainstorm
• 或运行 /prototype [new-concept]，先低成本测试一个新方向

如果是 NOT ASSESSED：

切片已构建，但尚未验证。说明适用的原因，然后完成阶段 5 的试玩和复盘——从 production/session-state/active.md 检查点继续——并在询问后，更新 REPORT.md 及其在 prototypes/index.md 中对应的行，写入评定结果。不要把切片当作已通过而提交到 /gate-check production：NOT ASSESSED 不等于 PROCEED。

---

重要限制

• 纵向切片代码绝不能重构为生产代码——它仅供参考
• 生产代码绝不能从 prototypes/ 导入
• 如果建议为 PROCEED，生产实现必须从头编写， 仅将切片作为设计参考
• 可以缩减范围，但不能降低质量——低质量的切片无法证明任何东西
• 总投入：1–3 周。如果需要更久，说明范围过大——应缩减切片，而不是降低质量。
• 第 3 天沉没成本规则：如果届时还无法演示完整的游戏循环流程， 就停止并说明阻碍因素
• **联网／多人游戏：**本地纵向切片无法验证联网机制的实际体验。延迟会从根本上改变战斗、移动和预测的体验——在 0ms 延迟下本地测试，与 80ms 网络延迟下的体验截然不同。切片可以验证游戏循环是否有趣且完整；但无法验证联网机制在真实条件下的体验是否良好。要验证联网体验，需要真实玩家对战或模拟延迟。