一个中型手游项目组，经济系统跑了3年，Excel表格攒到47个。主策划离职那天，交接文档里写着一句话：「第38号表的数据可能不准，但我不确定是哪一行。」
这不是段子。这是游戏行业每天都在发生的事。
游戏经济设计的工作流，全球团队用得都差不多：Google Sheets管数值平衡，Miro画系统流程图，Notion记设计文档。三个工具各干各的，拼成一套「缝合怪」系统。问题就从这里开始。
表格的灵活性是双刃剑。新手策划觉得爽——改个数字，全局联动，瞬间看到结果。但复杂经济系统像滚雪球，简单表格会变成：嵌套VLOOKUP的产出表、跨Sheet引用的消耗表、手动维护的版本控制表、注释比公式还多的「遗产表」。某个时刻，工具不再是工具，成了需要被管理的对象。
更隐蔽的问题是：表格只展示数据，不展示系统。
游戏经济是活的网络——产出、消耗、库存、交易，节点之间互相咬合。但Excel里你只能看到静态数字。于是团队在Miro里另画一套流程图，试图「看见」系统。两套描述同一经济的工具，时间一长必然脱节。策划改表格忘更新流程图，程序按流程图写逻辑没对齐表格，玩家在游戏里发现漏洞时，团队还在争论「设计意图到底是什么」。
模拟能力也在退化。用表格跑经济模拟，本质是手动调参、观察输出。系统简单时可行，节点超过20个后，每次全量模拟要半小时。策划开始偷懒：只测核心循环，边缘系统靠「感觉」。上线后玩家行为偏离预期，才发现某个边缘道具的产出公式里，一个单元格引错了Sheet。
知识碎片化是最后一击。数值在表格里，逻辑在文档里，关系在流程图里，讨论记录在Slack里。没有单一真相源。新人入职，要同时打开7个窗口才能理解「为什么这把武器的掉率是这么设计的」。老策划离职，带走的是脑子里的隐性知识，留下的是一堆互相矛盾的电子遗产。
临界点：从「设计」变成「管理设计的设计」
这些问题什么时候爆发？通常是游戏到达某个规模：
日活过50万，经济节点超过100个，或者系统迭代到第4个大版本。不同团队应对方式各异：有的招专职「表格管理员」，有的开发内部工具把部分流程自动化，有的直接上商业解决方案。这些补丁能缓解症状，但没触及病根。
病根在于：通用工具被用来管理系统级复杂度。
表格是绝佳的起点——灵活、快速、零门槛。但随着系统生长，维护灵活性的成本指数级上升。团队的核心挑战，从「怎么设计这个经济」滑向「怎么管理我们已经搞出来的复杂度」。这才是游戏经济设计的真正难点，却很少被公开讨论。
作者提到最近接触到Itembase.dev这类工具，尝试把经济设计当作「系统」而非「表格集合」来处理。不评价这是否终极答案，但至少让人意识到：工作流里的大量摩擦，根源在工具错配，而非设计本身。
如果你也在做游戏经济，好奇一件事——你的表格架构是在哪个节点开始崩的？是第15个Sheet，还是第一次多人同时编辑引发的冲突？
热门跟贴