数值策划的工作与口径
Category
numerical 树。节点定位：数值策划的职责边界、交付物、与程序协作的四个必答口径项和验证闭环——「手感」到「可计算」的转译者。
Definition
数值策划不是「填表的」，而是玩法体验的量化责任人：设计师口中的「手感」「爽感」「压抑期」，最终都要落到可计算的数字上，并且要在实现前验算、在上线后核对。本页定义这份工作的边界、交付物与协作口径。
Problem
把数值策划当「填表的」会系统性漏掉两个失灵点：设计师口中的手感/爽感/压抑期没人翻译成数字，程序算出来的数没人验算核对。缺了口径对齐与闭环，数值在实现前是错的、上线后是没人知道的。
职责边界
数值策划通常对四类问题负责：定标准（一局打多久、一赛季成长多少、一个 boss 打多少秒——体验目标先于数字）、建模型（属性结构、公式族、曲线族、经济与掉落的结构）、配数字（把模型展开成可实现的表格与参数）、验结果（上线前后用数据核对体验目标是否达成）。不负责的部分同样重要：系统规则结构属于玩法策划，实现正确性属于服务端（教程 02第 1 节的「接数值需求四个技术提问」就是两边交界的对话脚本）。
交付物
三份东西构成数值策划的标准交付：公式文档（符号定义、公式、参数表、边界条件——让人不看代码就能复算）、数值表（按等级/关卡/品阶展开的具体数值，服务端与客户端共同的数据源）、平衡报告（关键指标的推演：TTK、成长曲线对比、经济产出消耗对账、掉落期望）。三份交付物共同的验收标准是可复算：第三方拿公式和参数，不用问人就能算出任意中间值。
口径对齐：与开发协作的四个必答项
数值表交给服务端之前，四件事必须写清楚——这与教程 02 的实现四问一一对应：
- 计算时机：属性是实时重算还是进战斗快照（决定属性重算管线的触发点）
- 合并规则：多来源加成先进加法区还是乘法区（教程 02 第 2 节的加乘区规则）
- 随机口径：每次独立还是伪随机分布，种子归谁管（决定回放与审计能不能做）
- 取整与上限：伤害取整方向、溢出处理、各数值的硬上限（决定极端数值下的表现是否可控）
这四项在任何一次需求评审里都该有明确答案——没答案的数值需求，实现阶段必然返工。
验证闭环
数值工作的闭环是「设计 → 推演 → 实现 → 灰度 → 核对」：上线前用推演（表格、模拟脚本、可控人数的封测）验证模型；上线后用真实数据核对同一口径（通关率、TTK 分布、经济产出消耗账）。核对时最容易翻车的是口径漂移——设计时说的「通关率」和埋点里统计的「通关率」不是同一个分母。数值策划要主动核对口径定义（数据侧口径见教程 12《游戏数据分析》与第 14 章运营与数据分析）。
常见误区
- 先配数字后定标准：「这个 boss 多少血」之前先答「希望打多少秒」，否则所有数字都无从评估
- 公式不留推导：只给结果表不给公式，策划离职或需求变更时无法重推
- 口径单方面定义：数值口径不在评审时和服务端、数据方对齐，上线后各说各话
- 用感受对冲数据：上线后「感觉不对」但拿不出指标——体验目标必须在设计时转成可测指标
Used By
策划-程序协作口径约定；数值案评审；上线后的数值核对流程。
Related
关系链：职责 → 交付物 → 口径四问 → 验证闭环。上游：无（数值侧入口）。下游：numerical/02（战斗数值）、operation/bi/02（线上核对的口径端）。
Reference
本页为工程经验归纳。