模板 02 · 系统规格单(TDD-lite)
模板 02 · 系统规格单(TDD-lite)
用法:每个系统开工前填一份,给程序/美术/音频做交接。 原则:一句话意图 + 规则 + 边界 + 反例。写不清就别开工。
系统:______________
负责人 ____ · 状态 提案 / 原型 / 实现中 / 已验证 · 更新日期 ____
1. 意图一句话(必填,限 30 字)
这个系统存在的理由是:______________
服务支柱:第 ____ 条 进入核心循环的方式:______________(在 30s–3min 内如何被用到)
准入五问(任一"否"则停工):
- 服务某条支柱?
- 不撞反目标?
- 进入核心循环?
- 垂直切片验证过?(否 → 降级为实验)
- 会出现在 trailer/demo 里?
2. 玩家视角(先写这个)
| 项 | 内容 |
|---|---|
| 玩家怎么知道它存在? | |
| 玩家怎么知道它现在可用? | |
| 玩家做了什么? | |
| 玩家怎么知道生效了?(反馈) | |
| 玩家怎么知道自己错了? | |
| 玩家怎么查详细信息? | |
| 熟练玩家怎么跳过/加速? | |
| HUD 常驻成本 | 占用 ___ 个区块(预算 ≤ 7) |
3. 规则(Mechanics)
| # | 规则 | 数值 | 参数名(外置) |
|---|---|---|---|
| 1 | sys.x.base |
||
| 2 | |||
| 3 |
公式:______________(引用 systems/08 的公式族)
4. 边界条件(必填,这是 bug 的主要来源)
| 情况 | 行为 |
|---|---|
| 数值为 0 / 负数 | |
| 溢出 / 达上限 | |
| 同时触发多个 | |
| 与其他系统冲突 | |
| 存档/读档时 | |
| 断线/超时(若联网) |
5. 反例(必填,最重要的一栏)
程序最容易做出"能跑但不对味"的东西。写清楚什么是错的。
| 反例 | 为什么错 |
|---|---|
6. 数据格式
{
"system_id": "",
"params": { },
"state": { },
"events": [ ]
}
7. 失败模式与降级
| 风险 | 概率 | 影响 | 降级方案 |
|---|---|---|---|
8. 交接清单
| 对象 | 交付物 | 状态 |
|---|---|---|
| 程序 | 本规格单 + 参数表 + debug 开关 | ☐ |
| 美术 | 可读性优先级清单(玩家必须看清的三件事) | ☐ |
| 音频 | 声音优先级矩阵(哪些时刻必须有反馈) | ☐ |
| UX | HUD 占位 + 教学层级(L0–L4) | ☐ |
| 测试 | 验收标准("什么算做完") | ☐ |
9. 验收标准(DoD)
- 意图一句话成立
- 所有数值参数外置,改数值不编译
- 带 debug 开关与可视化调试层
- 边界条件全部有明确行为
- 反例全部不成立
- 玩家视角 7 问全部有答案
- 设计亲自玩过构建并确认"对味"
附:孤儿系统排查(每周 15 分钟)
| 系统 | 进核心循环? | 服务支柱? | 有耦合边? | 玩家 10s 内能说清? | 处置 |
|---|---|---|---|---|---|