每个烂尾项目都在用不同的口音重复同一课：你不是写代码失败了，你是范围控制失败了。《灰烬与誓约》做了两年，至少有四次，是靠删掉我自己很喜欢的功能才活下来的。
80% 法则的反面
大家都说功能开发总比预估耗时。反过来更重要：删除是即时的。 砍掉一个机制的瞬间，它未来会有的每一个 bug、需要的每一份素材、牵出的每一个边界情况——全部追溯性地消失。删除是唯一实现成本为零的效率手段。
范围控制是设计能力
游戏里最好的设计决策都是删除。修道院原本有五个区域，最后剩三个。对白原本有分支道德系统，最后变成一条写得更好的直线。玩家夸游戏”聚焦”——他们夸的是我删掉的东西。
客户项目超期时，本能反应是更拼命地干活。专业的做法是重新谈判这个作品的形状：承诺不变，表面积变小。
“完成”的纪律
“完成”是一份有日期的合同。最后六个月的规则：
- 内容锁定后不加新机制。 只允许调参和修复。
- 每次砍功能都写进一个叫
GRAVEYARD.md的文件。它终结了僵尸式讨论（“以后可以加回来”），因为砍掉的理由都有案可查。 - 发布可接受的最差版本。 上线后的打磨有玩家反馈做依据；上线前的打磨只有焦虑。
结论
“做完”是一种只能通过”做完”来学会的技能。现在每个新项目——包括客户项目——开工时都会先建好那个坟墓文件。