设计文档没写的地方，才是真正的工期

日期：2026-10-24

标签：#骰子弹珠 #开发 #设计

骰子弹珠的设计文档写得很细，核心循环八步是闭环的，看起来可以直接写代码。真正动手才发现：能被写下来的规则都已写好，缺的是没被想到的那些缝隙。

缺口长什么样

举几个当场卡住的：

• 投掷是同时还是逐颗？文档只说「选 5 颗投出」，又说「每颗可以撞台上一颗骰子」——只有逐颗投，后投的才可能撞到先投的。
• 组合用哪些骰子判？各判各的，还是混在一起判？如果混判，撞对方的骰子才有意义。
• 怪物先掷的骰子被撞掉之后，它亮出的「意图」还算不算数？

最后一条我们定成：意图是预测，不是承诺。玩家投完、所有骰子落定之后，怪物按最终骰面重算候选。否则「撞击能改变对方招式」这个验证目标直接失效。

处理办法

统一按三条走：

1. 选一个最合理的默认值
2. 写进 tuning.json，随时可调
3. 在开发记录里留一行「文档没写，此处取 X，理由是 Y」

统计下来一共 17 处。也就是说，文档的完成度是 80%，剩下 20% 是真正要花时间的部分，而这 20% 恰恰决定手感。

学到的事

设计文档的完整度不看篇幅，看它有没有把「边界情况」当一等公民。凡是「双方都无组合时怎么办」「倒计时为 0 时还要不要完成这次重掷」这类问题，写的时候觉得琐碎，做的时候就是一个个小决策。

写文档时多花十分钟列边界，写代码时能省两小时。