game-retrospective

AlterLab GameForge——游戏开发复盘

游戏行业拥有软件领域最优秀的复盘传统。Gamasutra 的经典复盘系列——《Diablo II》《Baldur's Gate》《Black & White》《Thief》——之所以教会整整一代开发者比任何教科书都更多的东西，是因为它们毫不留情地坦诚相待。五件进展顺利的事。五件出了问题的事。没有粉饰，没有企业式的净化措辞，也没有“经验与机遇”。只有团队尝试发布一款游戏时发生的真实情况。

这个工作流延续了这一传统。不是 Scrum 回顾，也不是敏捷仪式，而是游戏开发复盘——Supergiant 用这种形式将《Hades》从一款还不错的 Roguelike 打磨成定义整个类型的杰作；ConcernedApe 用它熬过了《Stardew Valley》长达五年的独立开发，没有失去理智；《Dwarf Fortress》的兄弟开发者则用它支撑了长达二十年的开发周期，既没有精疲力竭，也没有迷失方向。

企业回顾与游戏复盘的区别在于：企业回顾会问“我们可以在哪些方面改进？”，游戏复盘会问“我们打造的是正确的游戏吗？我们打造它的方式对吗？”前者优化流程，后者审视那些决定游戏能否发布、以及是否值得发布的创意与技术决策。

目的与触发条件

在以下情况下运行此工作流：

• 一个冲刺结束，而下一个冲刺尚未开始
• 达成一个里程碑（垂直切片、Alpha、Beta、正式版）
• 项目发布或取消
• 开发陷入停滞，却没人能说清原因
• 游戏“还行，但不好玩”，团队需要找出差距所在
• 刚刚发生重大转向或范围削减，而且事态已经平息
• 开始新项目之前，从上一个项目中总结经验

此工作流解决的问题：

• 没有人记录某项功能为何失败，导致重复犯下相同的设计错误
• 范围压力凌驾于设计判断之上，导致删错功能
• 技术债务在不知不觉中不断累积，直到阻碍进展
• 团队会进行试玩测试，却从不分析测试数据中的规律
• 独立开发者跳过复盘，纳闷为什么自己的第三个原型会和前两个一样夭折
• “感觉不太对，但我们还是发布了”带来的遗憾循环

关键规则

1. 采用 GDC 格式，而非敏捷格式。 结构应为“做得好的方面 / 做得不好的方面 / 经验教训”，而不是“进展顺利 / 进展不顺 / 行动项”。这种区别很重要：GDC 格式会迫使你做出判断。一件事要么做得好，要么做得不好，不允许骑墙。

2. 采用游戏特定的视角，而非通用的流程问题。 每次复盘都要从六个游戏开发视角展开（详见下文）。“我们的沟通是否顺畅？”是流程问题。“核心循环是否带来了预期体验？”才是游戏开发问题。本工作流关注的是第二类问题。

3. “砍掉清单”是必需的。 每次复盘都要回顾被砍掉的内容。懂得砍减，才能懂得交付。“砍掉清单”会促使你评估做出的删减是否正确、是否过早，或是否太晚。

4. “最重要的一点”是必需的。 完成所有分析后，将一切提炼成一句话。一条经验教训，一条能改变你下次工作方式的经验。如果你选不出一条，说明你还没有想得足够深入。

5. 证据胜过感受。 “战斗感觉不对劲”不是结论。“测试玩家在超过 45 秒的战斗遭遇中失去投入，说明相对于遭遇规模，伤害循环太慢”才是结论。所有结论都要有数据、试玩观察记录或具体事件作为依据。

6. 先读上一篇复盘。 开始之前，先回顾上一次复盘。那些经验教训真的带来了改变吗？如果同样的问题出现了两次，问题不在于缺乏认知，而在于执行。这一区别会彻底改变行动计划。

7. 独立开发者也要做复盘。 ConcernedApe 独自开发了《Stardew Valley》，历时五年。他曾公开谈及倦怠、范围蔓延，以及几乎放弃的那些时期。独立开发者没有外部反馈循环。本工作流就是你的外部反馈循环。把它写下来，不要只是在心里想想。

六个游戏开发视角

这些视角取代了通用的复盘问题。每次复盘——无论是冲刺、里程碑还是项目复盘——都要涵盖全部六个视角。并非每次都能从每个视角中得出结论，这没关系。但你必须逐一审视。

---

视角 1：验证核心循环

核心循环是否带来了预期体验？在叠加内容、叙事和进度系统之前，单独体验时是否有趣？

《Celeste》的核心循环——冲刺、跳跃、攀爬——在只有白色矩形的空白房间里也很有趣。甚至在出现任何一颗草莓、B 面关卡或剧情节点之前，Madeline 的移动手感就已经很好。如果你的核心循环在空白房间里都不好玩，再多内容也救不了它。这是最重要的视角，因为其他一切都建立在它之上。

需要回答的问题：

• 去掉所有内容、进度系统和叙事后，核心动作组合本身是否令人满足？你能在测试房间里玩这个循环 10 分钟，并且还想继续吗？
• 在循环的哪些环节，玩家会感受到自主性？又在哪些环节感到受限？这些位置合理吗？
• 循环的节奏是什么？这是你设计的节奏，还是在实现过程中发生了偏移？
• 循环的一轮需要多长时间？对于你的游戏类型和目标游玩时长，这个长度合适吗？
• 参考案例：《Hades》的核心循环（进入房间、战斗、选择恩赐、重复）在抢先体验期间迭代了一年多。Supergiant 先交付了循环，再在经过验证的基础上叠加内容。你也这样做了吗？还是在未经验证的循环上构建了内容？

---

视角 2：设计支柱的完整性

设计支柱在实现过程中是否得以坚守，还是发生了偏移？如果发生了偏移，这种偏移是有意的演进，还是无意识的侵蚀？ 只有在经受住上线考验后，支柱才有意义。如果某条支柱在 GDD 中读起来很漂亮，却在实现遇到困难时被悄然放弃，那它从来就不是真正的支柱——它只是一种愿望。本视角用于发现既定支柱与实际交付成果之间的差距。

需要回答的问题：

• 对每条支柱：指出三个具体的实现决策，说明这条支柱如何引导了选择。如果说不出三个，这条支柱就没有真正发挥作用。
• 对每条支柱：指出一个它遭到违背或妥协的时刻。原因是什么？进度压力？技术限制？还是有更好的想法取代了这条支柱？
• 开发过程中是否出现了新的隐性支柱？团队一直优先考虑某件事，却从未正式将其命名？现在把它指出来。
• 这些支柱仍然是正确的支柱吗？还是说你们实际打造的游戏表明，需要的是另一组支柱？
• 参考案例：Hollow Knight 的“氛围探索”支柱贯穿了每一次扩展。Team Cherry 削减了所有不服务于这一支柱的内容，包括他们自己也喜爱的内容。你们的支柱拥有这样的决策权吗，还是它们只是一种建议？

---

视角 3：范围优先级审查

Must/Should/Could 的优先级划分是否保护了正确的功能？开发过程中，哪些功能在不同层级之间变动？这些调整是否正确？

范围管理不是削减功能，而是在有纪律地放弃其他一切的同时，保护那些让你的游戏成为“你的游戏”的功能。

需要回答的问题：

• 列出本阶段开始时所有列在“Must”层级的功能。有多少已交付？有多少被降级或砍掉？
• 对每个被降级的“Must”功能：降级是否正确？如果基于当前认知重新做出这个决定，你还会这样做吗？
• 哪些“Should”或“Could”功能消耗的资源超出计划？这些超支值得吗？
• 计划范围与实际交付范围的比例是多少？差异是否可以接受，还是说明存在系统性的估算问题？
• 参考案例：Stardew Valley 的范围连续扩展了五年，因为 ConcernedApe 没有外部截止日期，也没有任何人能决定范围，除了他自己。这款游戏堪称杰作，但开发过程几乎将他压垮。严格控制范围也是自我关怀。

---

视角 4：心流状态分析

玩家测试者在哪些地方进入了心流？又在哪些地方失去了兴趣？将观察到的投入程度与预期的体验曲线进行对照。

心流——Csikszentmihalyi 所描述的挑战与技能完美匹配的状态——并非偶然，而是经过设计的。本视角将预期的心流曲线与玩家的实际体验进行比较。

需要回答的问题：

• 绘制一场游戏会话的预期体验曲线：挑战应该在哪里提升？在哪里应该放缓？峰值在哪里？
• 将玩家测试数据叠加到曲线上：玩家实际上在哪里投入最深（长时间游玩、反复尝试、发出可听见的反应）？又在哪里失去投入（放下控制器、查看手机、退出游戏）？
• 心流在哪些地方被打断？战斗中途管理物品栏？无法跳过的对话？在紧张感达到顶点时出现的加载画面？打断节奏的教程？
• 难度曲线是一条曲线，还是一道峭壁？玩家会在哪些地方碰壁？这些阻碍是有意设置的门槛，还是无意造成的阻力？
• 参考案例：Dark Souls 的心流设计堪称有意制造挫败感的典范。难度本身就是游戏的核心——但游戏从不让你的死亡白白发生。每次失败都会教会你一些东西。如果玩家既感到挫败又没有学到东西，那你的难度就不是 Dark Souls 式的难度，而是糟糕的难度。

---

视角 5：技术债务审计

为了提速而采取的哪些捷径如今阻碍了进展？哪些捷径是值得的？哪些本应更早偿还？ 每款游戏都会积累技术债。问题不在于“我们有没有技术债？”，而在于“我们的技术债是否欠在了合适的地方？”即将重写的原型系统中的技术债不费分毫。所有系统都依赖的核心系统中的技术债，则会不断累积利息。

需要回答的问题：

• 列出代码库中目前排名前 5 的技术捷径。逐一说明：修复它们要花多少成本？在下一个里程碑期间不修复的代价是什么？
• 哪些捷径帮助你们赶上了重要的截止日期？这些是好的技术债。请列出并承认其中的取舍。
• 哪些捷径如今阻碍了新功能的开发或导致了 Bug？这些是不该拖到现在才偿还的坏债。为什么当时没有修复？
• 技术债的积累是否有规律？如果它总是出现在同一个系统中，那这个系统需要重新审视架构，而不是打补丁。
• 对于最关键的技术债，团队的“巴士系数”是多少？如果唯一了解这套粗糙存档系统的人离开了，会造成多大损失？
• 参考案例：Dwarf Fortress 已开发二十多年。Adams 兄弟会刻意记录技术决策，明确哪些地方采用权宜之计、哪些地方认真构建——因为他们知道未来几十年都要维护这个代码库。 你们的时间线更短，但原则不变：弄清楚欠了什么，以及为什么会欠下这些债。

---

视角 6：玩法与叙事审视

玩法机制与叙事在哪些地方相互强化？又在哪些地方相互矛盾？游戏是否在故事中表达一种主张，却在系统中表达另一种？

“玩法与叙事不协调”一词由 Clint Hocking 在评论 BioShock 时提出，指的是故事让你关心角色，玩法却让你去搜刮他们的尸体。它指的是叙事所表达的游戏主题与机制实际奖励的行为之间的落差。

需要回答的问题：

• 找出三个玩法机制与叙事完美契合的时刻。它们成功的原因是什么？你们能否创造更多这样的时刻？
• 找出玩法机制与叙事相互矛盾的时刻。例如，故事说“时间所剩无几”，玩法却让你花上几个小时刷支线任务。叙事说“暴力会带来后果”，战斗系统却奖励连杀。
• 进度系统是否强化了叙事弧线？玩家的成长是否符合角色的历程？
• 不考虑任何对话或过场动画，游戏机制本身传达了什么主题？这个信息是有意传达的吗？
• 参考案例：Disco Elysium 堪称黄金标准。每项技能都是一个叙事声音。每次属性检定都是一个故事时刻。机制不是在支持叙事——机制本身就是叙事。Outer Wilds 也实现了同样的统一：每个“故事”时刻实际上都是一道物理谜题。你们不必达到这种程度，但必须知道玩法机制与叙事在哪些地方背道而驰。

---

待删除清单

本节是每次回顾都必须包含的内容。它专门审视这段时间内砍掉的每项功能、系统或内容。

Team Cherry 曾砍掉 Hollow Knight 中多个已部分完成的生物群系——地形已铺设，敌人已设计，部分美术也已完成。砍掉半成品比砍掉想法更难，因为你看得见已经付出的沉没成本。待删除清单会迫使你们诚实地面对自己的删减决定。

KILL LIST: [Sprint/Milestone/Project Name]
Date: [date]

+------------------------------------------------------------------+
| Feature Cut       | Stage When Cut  | Reason      | Correct Call?|
+-------------------+-----------------+-------------+--------------+
| [Feature name]    | [Idea/Design/   | [Why it was | [Yes/No +    |
|                   |  In-Progress/   |  cut]       |  reasoning]  |
|                   |  Nearly-Done]   |             |              |
+-------------------+-----------------+-------------+--------------+
| [Feature name]    | [stage]         | [reason]    | [assessment] |
+-------------------+-----------------+-------------+--------------+

CUTS THAT WERE CORRECT:
- [Feature]: Right call because [specific reason it was the right cut].

CUTS THAT WERE TOO LATE:
- [Feature]: Should have been cut at [earlier stage] instead of [when it was
  actually cut]. Cost of delay: [wasted effort in hours/days/sprints].

CUTS THAT WERE PREMATURE:
- [Feature]: In hindsight, this should have survived. Evidence: [why you now
  believe it was worth keeping].

FEATURES THAT SHOULD HAVE BEEN CUT BUT SURVIVED:
- [Feature]: This shipped but should not have. It [diluted the experience /
  consumed resources better spent elsewhere / violated a pillar]. Why it
  survived: [inertia / sunk cost fallacy / stakeholder attachment].

THE EARLIER CUT:
If you could go back to the start of this period, what would you cut on day
one that you did not cut until [later]?
- [Feature]: Cut immediately because [reason].

THE FIERCER PROTECTION:
What would you protect more fiercely against scope pressure?
- [Feature]: Protect because [reason it was more important than recognized].

“最重要的一点”

完成全部六个视角和“剔除清单”后，将所有内容提炼成一句话。 这是最难的部分，也是最有价值的部分。

我们学到的最重要的一点是：____________________

“最重要的一点”规则：

• 必须具体。“沟通得更好”不是洞见。“在此基础上构建内容之前，先单独试玩核心循环”才是洞见。
• 必须可执行。它应当改变下一次冲刺、里程碑或项目中的某项具体行为或决策。
• 必须诚实。让人舒服的教训和真实的教训很少相同。
• 应当是这样一点：如果你一开始就知道它，这段时期的进展就会有最大程度的不同。

“最重要的一点”示例：

• “我们本该在第二周就砍掉制作系统——它既不服务于任何支柱，又耗掉了 30% 的实现时间。”
• “直到加入受击停顿和屏幕震动，核心循环才变得有趣；这意味着我们花了两个月评估一个不完整的循环，并基于错误的数据做设计决策。”
• “我们的里程碑估算比实际时间少了 40%，因为我们估算了功能范围，却没算集成时间，而每个 Bug 都出在集成环节。”
• “叙事分支增加了复杂性，导致 QA 无法全面覆盖；由于有些路径从未测试，我们发布时带着三个会破坏进度的 Bug。”

糟糕的“最重要的一点”示例：

• “我们需要做得更好地规划。”（太笼统。规划什么？怎么规划？）
• “沟通很重要。”（显而易见。具体是哪种沟通失误？发生在谁之间？造成了什么损害？）
• “我们本该有更多时间。”（不可执行。你永远不会拥有更多时间。）

输出模板

三种格式，适用于不同范围。全部遵循 GDC 复盘结构，而非敏捷回顾结构。

---

格式 1：冲刺复盘（15 分钟）

SPRINT POST-MORTEM: [Sprint Name/Number]
Date: [date]
Sprint goal: [the single-sentence sprint goal]
Goal met: [Yes / No / Partially -- one sentence on why]

PREVIOUS POST-MORTEM REVIEW:
- [Action from last time] | [Done/Not Done] | [If not: why?]

--- SIX LENSES (hit only those with findings this sprint) ---

Core Loop:     [Finding or "No change this sprint"]
Pillars:       [Finding or "Held / Drifted -- specify"]
Scope:         [What moved between tiers and why]
Flow:          [Playtest observation or "No new data"]
Tech Debt:     [New debt taken on / Old debt paid down]
Ludonarrative: [Alignment finding or "N/A this sprint"]

--- WHAT WENT RIGHT (max 3) ---
1. [Specific positive] -- Why: [root cause of success]
2.
3.

--- WHAT WENT WRONG (max 3) ---
1. [Specific problem] -- Root cause: [system failure, not person]
2.
3.

--- KILL LIST ---
[Features cut this sprint, evaluated per Kill List format above]

--- THE ONE THING ---
The single most important thing we learned is:
[one sentence]

--- ACTIONS ---
| Action          | Owner   | Deadline | How We Will Know It Worked |
|-----------------|---------|----------|----------------------------|
| [specific act]  | [name]  | [date]   | [measurable outcome]       |
| [max 3 actions] |         |          |                            |

---

格式 2：里程碑复盘（45 分钟）

MILESTONE POST-MORTEM: [Milestone Name]
Date range: [start] to [end]
Sprints covered: [N]

HEADLINE: [One sentence — the story of this milestone]

--- GOALS VS. REALITY ---
| Goal                | Target              | Actual              | Verdict   |
|---------------------|---------------------|---------------------|-----------|
| [milestone goal]    | [what success was]  | [what happened]     | [Met/Miss]|

--- SIX LENSES (full analysis) ---

CORE LOOP VALIDATION:
[Detailed findings. Is the loop proven? Where is it weak?]

PILLAR INTEGRITY:
[Per-pillar assessment. Which held? Which drifted? Why?]

SCOPE TIER REVIEW:
| Feature         | Starting Tier | Ending Tier | Move Justified? |
|-----------------|---------------|-------------|-----------------|
| [feature]       | Must          | Cut         | [Yes/No + why]  |

FLOW STATE ANALYSIS:
[Map intended experience curve vs. observed player behavior.
 Identify flow breakers and flow peaks.]

TECHNICAL DEBT AUDIT:
| Debt Item       | Cost to Fix | Cost of Ignoring | Priority    |
|-----------------|-------------|------------------|-------------|
| [shortcut]      | [effort]    | [consequence]    | [Fix/Defer] |

LUDONARRATIVE CHECK:
[Where do mechanics and story align? Where do they fight?]

--- WHAT WENT RIGHT (5 items, GDC format) ---
1. [Title]: [2-3 sentences. What went right and WHY it went right.
   Be specific enough that another team could replicate the success.]
2.
3.
4.
5.

--- WHAT WENT WRONG (5 items, GDC format) ---
1. [Title]: [2-3 sentences. What went wrong and WHY it went wrong.
   Trace to a system or decision, not a person.]
2.
3.
4.
5.

--- KILL LIST ---
[Full Kill List format from above]

--- THE ONE THING ---
The single most important thing we learned is:
[one sentence]

--- ACTIONS ---
| Priority | Action              | Owner  | Deadline | Success Metric  |
|----------|---------------------|--------|----------|-----------------|
| P1       | [urgent]            | [name] | [date]   | [measurable]    |
| P2       | [important]         | [name] | [date]   | [measurable]    |
| P3       | [improvement]       | [name] | [date]   | [measurable]    |

PROCESS CHANGES (effective immediately):
- [Change]: [Rationale]

CARRY FORWARD:
- [Systemic issue requiring ongoing attention across next milestone]

---

格式 3：项目复盘（90 分钟）

完整的 GDC 风格复盘。这是一份历史文档。请诚实地撰写，让它值得公开发表。完整模板请参考 @templates/post-mortem.md。

PROJECT POST-MORTEM: [Project Name]
Duration: [start] to [end] ([total months])
Team size: [headcount or "solo"]
Final scope: [features shipped] / [features originally planned] ([percentage])

ELEVATOR PITCH (as designed):
[What was this game supposed to be?]

ELEVATOR PITCH (as shipped):
[What did this game actually become?]
[If these two pitches are different, that delta IS the post-mortem.]

--- PROJECT TIMELINE ---
| Phase          | Planned     | Actual      | Delta       | Key Event     |
|----------------|-------------|-------------|-------------|---------------|
| Concept        | [dates]     | [dates]     | [+/- weeks] | [what happened]|
| Pre-production | [dates]     | [dates]     | [+/- weeks] |               |
| Production     | [dates]     | [dates]     | [+/- weeks] |               |
| Alpha          | [dates]     | [dates]     | [+/- weeks] |               |
| Beta           | [dates]     | [dates]     | [+/- weeks] |               |
| Polish         | [dates]     | [dates]     | [+/- weeks] |               |
| Launch         | [dates]     | [dates]     | [+/- weeks] |               |
Total delta: [how far from original schedule]

--- SIX LENSES (definitive assessment) ---

CORE LOOP VALIDATION:
[Final verdict on the core loop. Was it proven before production began?
 What would you change about when and how you validated it?]

PILLAR INTEGRITY:
[For each pillar: did it survive from GDD to gold master? Where did it
 bend? Where did it break? Grade each pillar A through F.]

SCOPE TIER REVIEW:
[Full audit. Original scope vs. shipped scope. Every feature that moved
 between tiers, with justification assessment.]

FLOW STATE ANALYSIS:
[Aggregate playtest data across the full project. Where does the shipped
 game achieve flow? Where does it lose players?]

TECHNICAL DEBT AUDIT:
[What debt shipped? What debt was paid down during polish? What debt
 will haunt a sequel or DLC?]

LUDONARRATIVE CHECK:
[Final assessment of mechanics-narrative alignment in the shipped product.]

--- WHAT WENT RIGHT (5 items, GDC format) ---
1. [Title]
   [Full paragraph. What went right, why, what conditions enabled it,
    and what other teams can learn from this success.]
2.
3.
4.
5.

--- WHAT WENT WRONG (5 items, GDC format) ---
1. [Title]
   [Full paragraph. What went wrong, the root cause, the impact, when
    the team recognized it, and what should have been done differently.]
2.
3.
4.
5.

--- COMPLETE KILL LIST ---
[Every feature cut across the entire project, evaluated with full
 hindsight. This is the most valuable section for future projects.]

--- THE ONE THING ---
The single most important thing we learned is:
[one sentence]

[Then: 2-3 sentences expanding on why this is THE lesson, and how it
 will specifically change your approach on the next project.]

--- KEY LEARNINGS (5-7 maximum) ---
| Lesson                        | Evidence                   | Applies To     |
|-------------------------------|----------------------------|----------------|
| [transferable principle]      | [specific project example] | [future scope] |

Each lesson must be backed by specific evidence from this project. "Planning
matters" is not a lesson. "Our estimates were 40% under actual because we did
not account for integration time between the dialogue system and the save
system, which added 6 weeks" is a lesson.

--- PUBLISH ASSESSMENT ---
Audience:      [internal only / team blog / GDC talk / public post-mortem]
Redactions:    [anything not for public consumption]
Value to others: [what would another team learn from reading this?]

引导指南

个人开发者：

你既是参与者，也是引导者。没有人能质疑你的假设，因此这项练习更重要，而不是没那么重要。

使用这些提示，并把答案写下来。ConcernedApe 在开发 Stardew Valley 期间写过日志。这也是他坚持下来的方式之一。

SOLO DEV POST-MORTEM PROMPTS
1. What did I spend the most time on? Was it the RIGHT thing to spend
   time on, or was it the comfortable thing?
2. What task took 3x longer than expected? Why was my estimate wrong?
   (Not "it was harder than I thought" — WHY was it harder?)
3. What am I avoiding? What part of the project do I open last? That
   avoidance is data.
4. Run the six lenses solo. Even two-sentence answers per lens are
   valuable.
5. Fill out the Kill List. What did I cut? Was each cut right?
6. Am I still excited about this project? Scale of 1-10. Track this
   number over time. A downward trend that hits 3 means you need to
   change something fundamental — scope, direction, or schedule — not
   just push through.
7. The One Thing. Force yourself to pick one.

团队（2 人及以上）：

引导者的职责是维护坦诚。人们在群体环境中会自我审查。引导者要避免这种情况。

FACILITATION PROTOCOL
Before:
  [ ] Review previous post-mortem and its actions
  [ ] Collect playtest data, velocity metrics, bug counts
  [ ] Send the six lenses to the team 24 hours in advance so they
      arrive with findings, not blank stares
  [ ] Book the room. Set a timer. Enforce the timebox.

During:
  [ ] Start with previous action review. Accountability first.
  [ ] Run each lens in order. 5-7 minutes per lens for sprints,
      10-15 for milestones.
  [ ] The Kill List gets its own dedicated block. Do not skip it.
  [ ] One person talks at a time. No defending, no explaining away.
  [ ] When someone says "it's fine" about something that clearly is
      not fine, the facilitator pushes: "What would you change about
      it if you could?"
  [ ] Capture The One Thing individually first (everyone writes it
      down silently), then share. Consensus is not required — divergent
      "One Things" are informative.

After:
  [ ] Distribute the document within 1 hour
  [ ] Actions go into the sprint backlog immediately, not "later"
  [ ] File the post-mortem in the project archive
  [ ] Schedule mid-sprint check on actions

反模式

以下做法会比跳过复盘更快地毁掉它：

• **Gamasutra 式粉饰版本：**所有事情都被表述为正面的。“我们有机会学习范围管理”其实是“我们砍掉了半款游戏，过程很痛苦”。别再粉饰了。诚实的版本才有用。

• 甩锅式事后分析：“John 把构建弄坏了三次。”这不是分析。“我们的 CI 流水线没有合并前验证，因此损坏的构建进入了 main。失败的是系统，不是 John。”把每一次指责都转化为关于系统的问题。

• **行动坟场：**上次复盘你们列出了 12 项行动。完成了多少？如果答案不到一半，这次就少列几项，然后真正去做。完成三项行动胜过放弃十二项。

• 缺失的删减清单：“我们什么都没删。”你们要么删了功能，要么范围定得过大。两者都值得审视。如果你们确实什么都没删，就要看看范围是否定得过于保守——你们做的是一款求稳的游戏，而不是有雄心的游戏吗？

• 令人安心的「一件事」：“我们学到了很多。”这不算经验教训。再深入一点。真正的「一件事」通常是那个说出口时会让人稍微有些不自在的内容。

• 跳过事后分析：“我们太忙了。”这最清楚地表明你们需要做一次复盘。冲刺事后分析只需 15 分钟。如果你们连 15 分钟都抽不出来，那你们的冲刺存在比这次复盘能解决的问题更深层的问题。

交叉引用

• @docs/collaboration-protocol.md -- 事后分析讨论的沟通规范
• @docs/coordination-rules.md -- 复盘中发现系统性问题时的升级路径
• @docs/game-design-theory.md -- 用于视角分析的心流理论、MDA 框架、SDT
• @templates/post-mortem.md -- 扩展版项目事后分析模板
• 工作流交接：在任何冲刺或里程碑之后进行，为下一周期的 game-sprint-plan 提供输入；如果发现范围问题，则为 game-scope-check 提供输入

属于 AlterLab GameForge——独立游戏开发技能套件。