GD-01 · 数值改动影响面清单

① 场景引入

一、这件事现在是什么样

数值与关卡策划 · 真实业务触发

v3.6「雪原战线」上线前两周，数值组按平衡性评审结论把「冰霜护盾」减伤系数从 5.2 调到 4.1。主策要求周五评审会前给出影响面结论：哪些下游系统受影响、三类玩家分层各自损失多少、v2.8「烈焰增幅器」事故那次是怎么收场的——评审会上制作人第一个问题就是「上一次砍增幅器之后发生了什么，这次会不会重演」。

二、痛点 · 每条都有来源

1. 数值策划 90% 的时间面对 Excel，公式链条复杂到「找错误花一小时发现是打了个分号」——改数值本身很快，搞清改动的全部后果才是真工作量
   依据：界面新闻《素人游戏策划指北》：「90% 的工作时间里，数值策划面对的是

Excel，系统策划面对的是 PPT，文案策划面对的是 Word，主策划面对的是以上全部」——一个 5 分钟的关卡从设计案到完成约一周2中氪玩家（年消费 30 万）的原话：「技能就是卖出去的数值，卖出去的数值要修改需要非常慎重」

——数值直接关联付费玩家资产，改错方向的代价是流水依据 · TapTap 中氪玩家（自述年消费 30 万）：「技能就是卖出去的数值，卖出去的数值要修改需要非常慎重——策划活该被骂，运营活该被冲，程序活该加班，流水活该下滑」3头部 SLG 的 bug 阵容两三个月才被发现——「老系统数值有没有被改坏」的回归验证，中小公司连发现能力都没有，靠玩家上线后替你测依据 · 头部 SLG 上线 bug 阵容「两三个月才被发现和解决」（游戏葡萄 TapTap 动态）——「老系统数值有没有被改坏」的回归验证，中小公司连发现能力都没有4《一念逍遥》一次误发道具事故 = 50 万元道具+ 全服经济破坏 + 点对点回档——数值事故的收场从来不是改回来就完了依据 · 《一念逍遥》误发道具事故：50 万元道具 + 全服经济破坏 + 点对点回档——数值事故的直接代价清单5历史事故复盘散在飞书文档与制作人个人笔记里，没有结构化沉淀——「上次砍增幅器发生了什么」这个问题的答案，只存在于当年经手人的记忆里依据 · 《洛克王国：世界》S2「暗改门」：日活 1300 万的产品，官方发了 3 万字更新日志，却漏了 10 条最影响玩家日常体验的细节改动——TapTap 新版本评分 2.8 分、三天新增超 4000 条差评

三、换个做法之后

变化不在「快」，在「参与的角色」和「覆盖的范围」

✕ 现在的做法

• 数值策划 90% 的时间面对 Excel，公式链条复杂到「找错误花一小时发现是打了个分号」——改数值本身很快，搞清改动的全部后果才是真工作量中氪玩家（年消费 30 万）的原话：「技能就是卖出去的数值，卖出去的数值要修改需要非常慎重」——数值直接关联付费玩家资产，改错方向的代价是流水头部 SLG 的 bug 阵容两三个月才被发现——「老系统数值有没有被改坏」的回归验证，中小公司连发现能力都没有，靠玩家上线后替你测《一念逍遥》一次误发道具事故 = 50 万元道具 + 全服经济破坏 + 点对点回档——数值事故的收场从来不是改回来就完了

✓ 交给 Agent 之后

• 多来源文件一次读入，先做口径与完整性校验，再开始算
• 每条结论绑定来源文件、字段或条号，可以被审
• 产出是企业真会流转的正式件（带签批栏），不是一张展示用的表
• 该拦的地方给出「现在还不能提交」，并给不用干等的替代方案

四、场景闭环

5 步 · 每一步的产出都是下一步的输入

1. 改动解析 · 把一个系数拆成完整变量链从两版数值表 diff 出全部改动项，沿公式链向上追溯每个改动的依赖关系
2. 下游系统扫描 · 找出连着的每一张表技能/装备/刻印/关卡/公会战/PVP 逐系统排查引用，直接与间接影响分列
3. 玩家分层测算 · 谁受伤、伤多重按 PVP / PVE / 付费深度三层测算影响，付费玩家资产损失单独列示第 4步历史案例调取 · 上一次同类改动发生了什么检索公司历史数值事故库，调出 v2.8 增幅器事件完整复盘与收场代价第5 步影响面清单成稿 · 评审会要的那一页六系统影响 + 三层玩家 + 历史案例 + 回归验证范围，一页摆全，决策栏留空要准备什么数值配置表（当前版与上一版）v3.6.7 与 v3.5.4 两版 Excel——系数改动的第一现场，含公式链系统策划案与关联系统清单受影响系统各有一份设计案（Word/飞书），散在各系统策划手上历史事故复盘记录v2.8 烈焰增幅器事件的复盘——评分走势、补偿决策、时间线，散在制作人笔记与飞书文档玩家分层与资产分布数据BI 导出的玩家分层与冰盾相关资产持有分布——谁受伤、伤多重的定量依据

为什么这个场景值得做

优先级评分：痛感 4 × AI 适配 3 ÷ 落地难度 3 = 4.0

最大差异点：不是跑一个模拟器算伤害期望——那类工具算的是「改完强了还是弱了」，本场景回答的是「这个系数还连着谁、谁会因此受伤、上一次同类改动公司付出了什么」。历史事故复盘被结构化成可检索的案例库后，「想起上一次踩过的坑」这件事第一次不依赖当年经手的人还在不在职。

评分口径：痛感看「这事没做好谁会生气、生气到什么程度」；

AI 适配看「输入是否非结构化、是否要跨部门取数、错了能不能当场看出来」；

落地难度是分母 —— 需要客户先做数据治理的场景，分数会被压得很低。

五、会产出什么

判断标准只有一个：这份东西能不能直接进企业的流程

• 正式件本体：数值改动影响面清单.xlsx 正式件 · 6 系统影响 + 3 层玩家 + 历史案例对照 · 含评审签批栏
• 可派发清单：回归验证场景清单.xlsx 可派发 QA · 验证场景 / 期望数值 / 偏差判定标准

这套东西不承诺什么：本场景只做影响面分析与历史案例调取，不给出「改不改」的决策建议——决策栏留空，由主策与制作人在评审会上拍板；数值改动上线的最终决定、补偿方案的金额，一律人工。回归验证清单只列「应验证的场景与期望数值」，实机跑数由 QA 执行。

② Live Demo（演示逐步）

演示模式 · 可视化预演 本页展示的是「应该怎么跑、每一步看什么、交付什么」，用的是真实业务格式的脱敏构造数据， 不宣称已接入客户生产系统，也不承诺任何效率提升百分比。

案例设定：星屿互娱数值组。v3.6「雪原战线」上线前两周，数值表 v3.6.7（8 月 28 日定稿）已把「冰霜护盾」减伤系数从 5.2 调到 4.1；主策要求周五评审会前给出影响面结论——制作人第一个问题会是「上一次砍增幅器之后发生了什么」。

输入文件4 份实际改动9 项 · 高敏 2 项下游系统6 个 · 直接 2 间接 4评审会周五 10:00 · 决策栏留空

输入游戏公司手上能拿到的东西

不需要整理格式、不需要改文件名 · 直接拖进对话框

• 01_数值配置表diff_v3.6.7_vs_v3.5.4.xlsx 数值表两版 diff 出的全部改动项——影响面分析的基准面数值组维护 · v3.6.7 8月 28 日定稿
• 02_系统策划案_关联系统要点.docx 受影响系统的策划案节选——极地远征玩法设计与冰盾技能说明各系统策划维护 · 版本 v3.5.4（8 月 18 日评审稿）
• 03_v2.8烈焰增幅器事故复盘_2026年3月.txt v2.8 削弱事故的制作人复盘笔记——本次评审会要调出的历史案例制作人个人笔记 · 2026 年 3 月事故后归档
• 04_玩家分层与冰盾资产分布_BI导出.xlsx BI 导出的玩家分层与冰盾相关资产持有分布——谁受伤、伤多重的定量依据运营组 BI 平台导出 · 每周刷新

注意标橙色那一份 —— 03_v2.8烈焰增幅器事故复盘_2026年3月.txt。它制作人个人笔记 · 2026 年 3 月事故后归档，平时压根不在核对范围里。这个场景的价值，很大一部分就来自把它读进来。

提示词就说这么几句

没有模板、没有表单 · 专业规则由 Skill 兜底

这是数值表 v3.6.7 和 v3.5.4 两版，冰霜护盾的减伤系数从 5.2 改到了 4.1。这是系统策划案和历史事故复盘。 帮我做三件事：

1. 把这次改动连着的所有系统找出来，直接间接都算，一个都不许漏。
2. 按 PVP、PVE、付费深度三层，测算哪些玩家受伤最重，持有冰盾资产的付费玩家单独算。
3. 把 v2.8 砍烈焰增幅器那次的事故复盘调出来，评分掉了多少、补偿花了多少、多久恢复的，跟这次摆在一起。 要不要改、怎么改，我自己定，决策栏留空。新玩法「极地远征」用冰盾当核心机制这件事，重点看。

专业规则（公式链追溯口径、玩家分层标准、历史案例检索字段）都在能力包里，现场只需要把两版数值表和复盘文档丢进去。

触发一个系数动了一行 · 评审会要的是它连着的六张表

改一个系数一分钟，搞清后果才是这次的工作量

8 月 28 日数值表定稿，冰霜护盾减伤系数 5.2 调到 4.1。主策的评审会问题清单有三问：连着哪些系统、哪类玩家受伤最重、v2.8 那次怎么收场的。

第 1 步 · 改动解析 · 9 项改动里 2 项高敏，都压在付费玩家资产上

以数值表 diff 为基准面，人肉改动清单只作参考

第 2 步 · 下游系统扫描 · 六张表连着同一个系数

公式链逐系统追溯，直接与间接影响分列

第 3 步 · 玩家分层测算 · 3.2 万核心玩家的资产直接受损

按公式链推演三类玩家的实际损失

第 4 步 · 历史案例调取 · v2.8 那一刀的完整账单

制作人第一问的答案，从复盘笔记里结构化调出

第 5 步 · 影响面清单成稿 · 一页摆全，决策栏留空

六系统影响 + 三层玩家 + 历史案例 + 回归验证范围

板块内容评审会待决事项系统影响6 个下游系统，直接 2 间接 4极地远征 3 个关卡是否随版本重标定玩家影响核心层 3.2万人资产受损，坦度 −21.2%是否前置补偿预案历史对照v2.8 同型事故：87 万补偿 + 6 周修复期分步削弱是否采纳回归验证应验证场景清单已单列（QA 可派发）验证窗口排期决策栏留空——改不改、怎么改由主策与制作人拍板—评审会的形态从「主策口头说没大问题」变成「一页影响面清单 + 两个替代方案」。该拦的这次拦在了评审会之前影响面清单的结论是「这份改动方案现在还不能直接上评审会拍板」：极地远征把冰盾设为核心机制，削弱系数等于新玩法难度锚点漂移，而关卡难度表尚未同步调整——方案带着这个矛盾上会，制作人只能在信息不全的情况下拍板。替代方案两套已附在清单末页：分步走（5.2 → 4.6 → 4.1，跨两个版本）或 PVP 环境单独分支。

影响面清单已就绪 · 但这份改动方案还不能直接拍板冰盾系数 5.2 → 4.1 连着六张表，核心层 3.2 万玩家的资产直接受损，且与极地远征的难度锚点存在未解矛盾——现在上会拍板，等于让制作人在信息不全时做决定。方案一：系数分两步走（5.2 → 4.6 → 4.1，跨两个版本），配合极地远征 3 个关卡重标定——影响面收敛，每一步都有观测窗口，代价是新玩法难度校准工作量按 3 个关卡重调计。方案二：本版只动 PVP 环境的系数分支、PVE 保持 5.2——影响面收敛到公会战与竞技场两个系统，关卡重标定整体推迟到下版本，代价是 PVP/PVE 双轨数值的长期维护成本。改不改、怎么改、要不要前置补偿，评审会上由主策与制作人拍板——决策栏留空。

之后这一次跑完，公司多了什么

不讲省了多久：讲少了几个隐患、沉淀了什么

• ✓ 历史事故库多了一个可检索的结构化案例：本次分析本身会在下次同类改动时被调出来
• ✓ 「公式链引用扫描」的口径第一次被固定下来：直接/间接影响两列，后续版本直接复用
• ✓ 一条历史教训被真正用上：v2.8 的收场代价不再只活在制作人记忆里
• ✓ 评审会的形态变了：从「主策口头说没大问题」变成「一页影响面清单 + 两个替代方案」

追问现场可能被问到的

答不上来的问题，比答得漂亮的问题更能决定这场演示的结果

• 能不能直接告诉我这个系数该不该砍？ 不能。决策栏留空——改不改要担责任，这个责任 AI 不能替主策和制作人背。我能给的是六个系统的影响面、三类玩家的损失分布、上一次同类改动的完整收场代价。
• 它看得懂数值表里的公式链吗？ 能读出公式引用关系并沿链追溯，但对不到位的引用会标成「需人工确认」，不会替你猜策划意图。
• 历史事故我们公司没记录过怎么办？ 第一次跑就当建库：把制作人笔记和飞书复盘文档丢进来，本场景会把它结构化成「改动类型/评分影响/补偿代价/恢复周期」四栏，下次才有得查。

③ 能力沉淀（Skill / 提示词 / 预期输出 / 人工边界）

1. Skill 能力包

导入之后，同类任务会自动按这套规则走 —— 提示词才能写得那么短

数值改动影响面清单 —— 砍一个系数之前，把六个系统、三类玩家和上一次事故都摆上桌 · Skill

SKILL.md 主本 + references（输出骨架 / 判据 / 渲染脚本）· 符合 WorkBuddy Skill 规范

版本 v1.0

numeric-change-impact-map.zip

在 WorkBuddy 里直接上传这个 zip 即可导入

包内结构

• SKILL.md 主本 —— YAML 元信息 + 执行流程 + 硬规则 + 人工边界
• references/output_template.md 输出骨架（sheet 名 / 分区顺序 / 列头）+ 可直接运行的渲染脚本
• references/judgement_rules.md 判据与口径 —— 什么情况算异常、什么情况必须拦住

references 不会一次性全读进来 —— Agent 按需取用。所以 Skill 可以写得很细，不会拖慢每次对话。

2. 原始素材

这些就是游戏公司手上真实能拿到的东西 —— 格式不统一是常态，不是问题

📁GD-01 · 演示素材

脱敏构造数据 · 真实业务格式 · 埋点可核验

共 4 份

• 01_数值配置表diff_v3.6.7_vs_v3.5.4.xlsx 数值表两版 diff 出的全部改动项——影响面分析的基准面
• 02_系统策划案_关联系统要点.docx 受影响系统的策划案节选——极地远征玩法设计与冰盾技能说明
• 03_v2.8烈焰增幅器事故复盘_2026年3月.txt v2.8 削弱事故的制作人复盘笔记——本次评审会要调出的历史案例
• 04_玩家分层与冰盾资产分布_BI导出.xlsx BI 导出的玩家分层与冰盾相关资产持有分布——谁受伤、伤多重的定量依据

怎么用

• 把素材全部拖进 WorkBuddy 对话框（不需要整理格式、不需要改文件名）
• 粘贴下方提示词发送
• 拿到正式件初稿 —— 签批栏留空，推荐意见留空，由你填

3. 提示词卡片

这是数值表 v3.6.7 和 v3.5.4 两版，冰霜护盾的减伤系数从 5.2 改到了 4.1。这是系统策划案和历史事故复盘。 帮我做三件事：

1. 把这次改动连着的所有系统找出来，直接间接都算，一个都不许漏。
2. 按 PVP、PVE、付费深度三层，测算哪些玩家受伤最重，持有冰盾资产的付费玩家单独算。
3. 把 v2.8 砍烈焰增幅器那次的事故复盘调出来，评分掉了多少、补偿花了多少、多久恢复的，跟这次摆在一起。 要不要改、怎么改，我自己定，决策栏留空。新玩法「极地远征」用冰盾当核心机制这件事，重点看。

为什么这么短就够了：专业规则（公式链追溯口径、玩家分层标准、历史案例检索字段）都在能力包里，现场只需要把两版数值表和复盘文档丢进去。

换成你自己的业务：把素材换成你手上的真实文件即可。导入 Skill 之后，

该走几步、什么口径、什么情况必须拦住，Agent 自己知道 —— 你只需要说清这是什么事。

自己组织输入的三步法

• 用自然语言说清核心需求 —— 就按平时跟同事交代活的方式说：什么事、什么文件、什么要求。不用讲究格式。
• 调用 Skill 补齐专业规则 —— 导入本页 Skill 后，流程、口径、硬规则 Agent 自己知道。
• 用「增强提示词」补全遗漏 —— 输入框旁边有增强按钮，把随口说的话补成更完整的表述。

分工：自然语言负责「这是什么事」，Skill 负责「该怎么做」，增强提示词负责「别漏了什么」。

4. 预期输出

不方便现场跑的时候可以直接拿这份给客户看 · 与实跑结果同结构

📋正式交付物

带签批栏 / 冻结首行 / 开筛选 —— 判断标准是「能不能直接进企业的流程」

共 2 份

XLSGD-01_数值改动影响面清单.xlsx正式件 · 6 系统影响 + 3 层玩家 + 历史案例对照 · 含评审签批栏下载

• ↓XLSGD-01_回归验证场景清单.xlsx 可派发 QA · 验证场景 / 期望数值 / 偏差判定标准

Skill 里固化了什么：从历史里想起了公司踩过的坑该拦的地方拦住了排除性结论把技术动作翻译成钱

输入清单：数值配置表（当前版与上一版）v3.6.7 与 v3.5.4 两版 Excel——系数改动的第一现场，含公式链系统策划案与关联系统清单受影响系统各有一份设计案（Word/飞书），散在各系统策划手上历史事故复盘记录v2.8 烈焰增幅器事件的复盘——评分走势、补偿决策、时间线，散在制作人笔记与飞书文档玩家分层与资产分布数据BI 导出的玩家分层与冰盾相关资产持有分布——谁受伤、伤多重的定量依据

人工边界：本场景只做影响面分析与历史案例调取，不给出「改不改」的决策建议——决策栏留空，由主策与制作人在评审会上拍板；数值改动上线的最终决定、补偿方案的金额，一律人工。回归验证清单只列「应验证的场景与期望数值」，实机跑数由 QA 执行。

升为客户真实案例还缺什么：客户当前真实输入文件（不要整理过的）岗位现行 SOP 与审批链（金额分档、谁签字）至少一次真实出过问题的案例客户当前正在用的正式输出模板客户确认的阈值口径（多少天算临期、多少金额算大额）

5. 同一角色下的其他场景

数值与关卡策划 · 产出即下一步输入

• GD-02 · 版本文案五处一致性核对：公告 3,847 字不短，漏的那两条最要命

上下游串起来就是完整链路。每一步的产出都是下一步的输入，不用在不同工具之间来回复制粘贴。

场景内容基于 WorkBuddy 产品能力整理，演示中的企业、人物与数据均为虚构，不代表任何客户的实际成效；痛点引用的公开来源已做脱敏处理。网页版由原资料转换，部分演示表格以原文形式展示。