规格卡写法

何时触发

• 一个系统/一批效果要交给程序实现，需要一份「实现唯一依据」的文档
• 需求在群里来回改，需要收敛成一份可对照的规格

结构

1. 头部：文档名 + 版本 + 状态（已定稿 / 待拍板）+ 一句话说明它是谁的唯一依据。
2. 总则铁律表：编号（C1、C2…）+ 铁律内容。写「不能怎么做」比写「要怎么做」更能防歧义。
3. 逐条规格：每条效果一栏，效果 + 演出双写——只写数值会出现「数字对了但玩家看不见」。
4. 边界与异常：目标不存在、结算中途死亡、连续触发、叠加规则。
5. 验收：每条规格对应一条可执行的验收用例（能自动化就标自动化）。
6. 变更记录：日期 + 谁拍板 + 改了什么，方便回溯「为什么是这个数」。

写的时候

• 用「当…则…」句式，避免「尽量」「适当」。
• 一切「看起来/感觉上」的要求都要翻译成可观察行为（颜色、时长、位置、文案）。
• 数值给区间与容差，不给「大概」。
• 演出需求写清时机：触发前 / 结算中 / 结算后。

验收

• 每条规格都能对应一条验收用例
• 没有「见上」「同上」这类指向不明的表述
• 演出与数值分栏写清
• 边界情况至少覆盖 3 种
• 变更记录可追溯到拍板人

坑

• 规格里混着「讨论过程」——决策写进变更记录，正文只留结论。
• 只写效果不写演出，程序按最小实现交差，玩家看不到反馈。
• 数值改动不更新规格卡，两周后没人知道当前值是多少。