先搭好推演场景与准备材料
这篇教程讲的是怎样把“爱游戏内容更新”这件事放进一个可推演的场景里，而不是凭感觉拍板。场景是通用的：一个内容小组要在有限的人力和时间内，决定这一轮更新做什么、不做什么。不涉及任何具体团队或客户。
开始之前先准备三样东西：一份当前内容的现状清单、一份可用资源清单（人、时间、可复用的素材）、一份待验证的假设清单。三样都写下来，不要只放在脑子里，否则推演会滑回“我觉得”。
准备清单怎么列
- 现状清单：现在有哪些内容、各自维护成本大概多少。
- 资源清单：这轮能投入多少人、多少天、哪些素材能直接复用。
- 假设清单：你认为“更新后会变好”的那些判断，逐条写出来。
把约束条件摆到桌面上
推演卡住，多半是因为约束没写清楚。先把硬约束和软约束分开：硬约束是不能碰的，软约束是可以谈的。这一步的目标不是解决约束，而是让所有人看到同一张约束表。 爱游戏实用指南
常见的约束有四类：时间窗口、人力上限、素材可用性、以及内容之间的依赖关系。把每一条写成一句话，并标注它是硬还是软。
约束表的写法
- 时间：本轮必须在某个节点前完成，属于硬约束。
- 人力：只有固定几个人能参与，属于硬约束。
- 素材：部分素材需要重新整理，属于软约束，可以降级使用。
- 依赖：某条内容必须等另一条先定稿，属于硬约束。
按步骤走一遍决策推演
约束摆好之后，按下面的顺序走一遍。每一步都要求产出一个可以写下来的结论，而不是停留在讨论。
- 第一步：从假设清单里挑出这轮最想验证的那一条，只挑一条。
- 第二步：对照约束表，判断这条假设在当前资源下能不能被验证。
- 第三步：如果能，写出最小可执行的更新动作；如果不能，回到第一步换一条。
- 第四步：为这个动作设定一个观察口径，说明更新后看什么、看多久。
- 第五步：把动作、口径、负责人写进一页纸的推演结论里。
走完这五步，你得到的不是一份宏大方案，而是一个能在本轮做完的动作加一个可核对的观察口径。推演的价值就在这里：它把“要不要更新”变成“先验证哪一条”。
边界情况的分支处理
推演过程中会遇到几种典型分支，提前想好怎么处理，能少走弯路。
分支一：假设无法被验证
如果当前资源根本不足以验证这条假设，不要硬上。把它标记为“待条件成熟”，换一条能被验证的假设，保持本轮有产出。
分支二：约束中途变化
如果时间或人力突然收紧，先砍动作范围，不要砍观察口径。口径没了，这轮更新就变成纯消耗。
分支三：多条假设互相冲突
冲突时按“验证成本低、影响面小”的顺序排，先做便宜的那条。不要一次验证多条，否则观察口径会互相污染。
收尾：把推演结论变成行动
推演结束前，做一次简短复核：约束表是否还准确、假设是否只有一条、动作是否最小、口径是否可观察。四项都过，就可以把结论交给执行环节。
如果有一项没过，回到对应的步骤重走，而不是在结论上打补丁。推演的意义是让决策过程可以被复查，而不是让结论看起来更漂亮。把这一页纸留下来，下一轮更新时可以直接复用这套流程。