游戲策劃用表格管經濟：3年攢了47個Sheet后，團隊崩潰了

一個中型手游項目組，經濟系統跑了3年，Excel表格攢到47個。主策劃離職那天，交接文檔里寫著一句話：「第38號表的數據可能不準，但我不確定是哪一行。」

這不是段子。這是游戲行業每天都在發生的事。

游戲經濟設計的工作流，全球團隊用得都差不多：Google Sheets管數值平衡，Miro畫系統流程圖，Notion記設計文檔。三個工具各干各的，拼成一套「縫合怪」系統。問題就從這里開始。

表格的靈活性是雙刃劍。新手策劃覺得爽——改個數字，全局聯動，瞬間看到結果。但復雜經濟系統像滾雪球，簡單表格會變成：嵌套VLOOKUP的產出表、跨Sheet引用的消耗表、手動維護的版本控制表、注釋比公式還多的「遺產表」。某個時刻，工具不再是工具，成了需要被管理的對象。

更隱蔽的問題是：表格只展示數據，不展示系統。

游戲經濟是活的網絡——產出、消耗、庫存、交易，節點之間互相咬合。但Excel里你只能看到靜態數字。于是團隊在Miro里另畫一套流程圖，試圖「看見」系統。兩套描述同一經濟的工具，時間一長必然脫節。策劃改表格忘更新流程圖，程序按流程圖寫邏輯沒對齊表格，玩家在游戲里發現漏洞時，團隊還在爭論「設計意圖到底是什么」。

模擬能力也在退化。用表格跑經濟模擬，本質是手動調參、觀察輸出。系統簡單時可行，節點超過20個后，每次全量模擬要半小時。策劃開始偷懶：只測核心循環，邊緣系統靠「感覺」。上線后玩家行為偏離預期，才發現某個邊緣道具的產出公式里，一個單元格引錯了Sheet。

知識碎片化是最后一擊。數值在表格里，邏輯在文檔里，關系在流程圖里，討論記錄在Slack里。沒有單一真相源。新人入職，要同時打開7個窗口才能理解「為什么這把武器的掉率是這么設計的」。老策劃離職，帶走的是腦子里的隱性知識，留下的是一堆互相矛盾的電子遺產。

臨界點：從「設計」變成「管理設計的設計」

這些問題什么時候爆發？通常是游戲到達某個規模：

日活過50萬，經濟節點超過100個，或者系統迭代到第4個大版本。不同團隊應對方式各異：有的招專職「表格管理員」，有的開發內部工具把部分流程自動化，有的直接上商業解決方案。這些補丁能緩解癥狀，但沒觸及病根。

病根在于：通用工具被用來管理系統級復雜度。

表格是絕佳的起點——靈活、快速、零門檻。但隨著系統生長，維護靈活性的成本指數級上升。團隊的核心挑戰，從「怎么設計這個經濟」滑向「怎么管理我們已經搞出來的復雜度」。這才是游戲經濟設計的真正難點，卻很少被公開討論。

作者提到最近接觸到Itembase.dev這類工具，嘗試把經濟設計當作「系統」而非「表格集合」來處理。不評價這是否終極答案，但至少讓人意識到：工作流里的大量摩擦，根源在工具錯配，而非設計本身。

如果你也在做游戲經濟，好奇一件事——你的表格架構是在哪個節點開始崩的？是第15個Sheet，還是第一次多人同時編輯引發的沖突？