不少人第一次打开九游会App，习惯性地想先看“今天耗了多少电”。但App里没有一个全局的“我的耗电”页面，图表入口都在某个项目内部。这不是为了增加一步操作，而是因为同样一台服务器，放在哪个区域、服务哪个地区的玩家、跑的是实时对战还是后台批处理，算出来的能耗解释和碳排完全不同。项目就是九游会App给数据划定的系统边界。
项目不是文件夹，而是一份“口径声明”
你可以把游戏运营项目理解成一份写给系统的说明：这款游戏（或这一组游戏服务）由哪些部分构成，跑在哪里，服务谁，什么时间段有额外活动。九游会App的设计取向是，先让人把这份说明写完整，再去连接数据。原因很实际：如果先接数据、后补说明，图表会用默认口径先画出来，之后再改字段，历史曲线的解释就变了，很难判断哪一段数据是按哪个口径算的。
项目里可配置六类信息：游戏平台、服务器区域、玩家地区、游戏模式、云服务、赛事活动。下面逐项说明它们分别影响什么。
游戏平台：决定“终端那一侧”要不要算
游戏平台指玩家用什么设备进入游戏，例如手机、PC、主机或网页/云游戏。它对服务器指标没有直接影响，但对碳足迹的边界有影响。如果项目只关心服务端能耗，平台可以只作为标签；如果项目要做完整的碳足迹，玩家设备使用会被当成活动数据的一部分，此时“平台”决定了用哪一类设备的功率假设。
这里要保持诚实：玩家终端的功率在多数情况下是估算值，而不是九游会App测到的。App做的是把估算方法和假设摆出来，而不是给出一个看起来精确的数字。关于系统边界为什么会让结论翻转，可以参考九游会官网为什么把游戏服务器、碳足迹和电竞赛事放进同一个AI能源系统。
服务器区域：直接决定用哪个电网因子
这是六项里最容易被低估的一项。碳足迹的基本算法是：活动数据（用电量kWh、传输流量GB、设备使用小时等）乘以排放因子。对服务器来说，排放因子通常是所在区域电网的排放因子，单位是gCO2/kWh，可以选平均值，也可以选按时段变化的值。
所以服务器区域填得不对，同样的1000 kWh会被乘上错误的因子。举一个模拟示例：区域甲的电网因子设为每度电较高，区域乙设为较低，那么同一批服务器被误填成乙区域，碳足迹会被系统性低估，而耗电曲线看起来完全正常，没有任何报错。这类错误不会主动暴露，所以建立项目时值得多花一分钟核对。
玩家地区：与服务器区域不是一回事
玩家所在地区和服务器所在区域经常不一致，比如玩家分布在多个地区，而服务器集中在其中一两个区域。九游会App把两者分开记录，因为它们回答不同的问题：服务器区域决定电力和碳排因子，玩家地区决定网络路径、延迟约束，以及玩家终端那一侧使用哪个地区的电网因子。
如果一个项目里玩家分布很分散，后续做区域调度分析时，玩家地区也是判断“实时对战服务器能不能迁移”的依据：实时游戏首先受延迟和体验约束，不能因为某个区域电力更低碳就直接搬走。这一点在九游会App为什么有时显示碳排下降，但耗电没有明显下降里也会再谈到：碳排变化不一定来自用电变化。
游戏模式：区分“不能动”和“可以挪”的负载
游戏模式在项目里用来标记负载的性质：实时对战、匹配大厅、后台批处理、内容生成、日志分析等。它的作用不是装饰，而是让后续的建议有分寸。实时对战的服务器对延迟敏感，App不会建议它为了低碳换时间段运行；日志分析、补丁构建这类非实时任务则可能存在挪到低碳时段的空间。
如果项目里所有负载都标成同一种模式，系统就无法区分，之后的建议要么过于保守，要么不适用。建立时把最主要的两三种模式分开标出来，比追求列得完整更有用。
云服务：读指标的来源，也是权限的起点
云服务一项记录的是数据从哪里读：哪个云账号、哪些实例、哪些监控指标。九游会App通过API或数据接入去读取服务器和云服务的指标，所以这里要有对应的访问权限，并设置读取的时间区间。权限不够或时间区间设错，最常见的现象是图表为空，而不是提示错误。如果后面遇到服务器数据不同步，可以到九游会下载栏目，按API、权限、时间区间的顺序逐层排查。
另外要说明一个边界：App读到的是指标，指标通常是采集值或估算值，不是电表读数。它与电费账单为什么不同，后面的九游会App里的实时能耗为什么和电费账单不完全一样会专门讲。
赛事活动：临时的负载和一次性的排放
赛事活动用来标注那些有明确起止时间的事件，比如一场线上赛事、一次新版本上线活动或一次大型直播。它的作用有两个：一是在能耗曲线上解释为什么某段时间出现尖峰；二是在碳足迹里把活动期间的额外服务器、CDN流量、设备使用单独归类，便于之后复盘。
需要注意，活动标注本身不会让数据变准，它只是给数据加了一个可查的时间标签。如果活动涉及线下场馆和交通，这些排放通常不在服务器指标里，需要另外录入或估算。
一个建议的建立顺序
- 先写项目名称和主要目标：是监控能耗，还是做完整碳足迹，还是准备ESG报告。目标不同，需要的字段完整度也不同。
- 填服务器区域，并核对排放因子来源：这是最影响碳排数字的一项。
- 补充玩家地区和游戏模式：不必一次填全，先覆盖主要地区和主要负载类型。
- 再连接云服务和数据：设置好权限与时间区间，先看能不能读到一小段数据。
- 最后才加赛事活动：等基础数据稳定后，再往上叠加事件。
什么时候应该拆成两个项目
项目越大越容易含糊。下面几种情况，拆开通常比合在一起更清楚：同一个团队运营的两款游戏，服务器区域完全不同；同一款游戏里，正式运营环境与测试环境混用一个项目；一场大型赛事的临时基础设施与日常运营需要分别复盘。合在一起的代价是排放因子和数据源被迫共用，出了偏差很难定位到底是哪一部分。
拆得太细同样有问题：碳足迹本来要覆盖整条链路，拆成十个项目后，需要自己再去汇总。一个可用的判断标准是：同一项目内的数据，应当共享同一套区域、同一套口径和同一个复盘对象。
需要保留的一点谨慎
项目建好，不代表结果就可以直接对外引用。九游会App目前给出的是基于你填写的信息和读取到的数据得出的能耗与碳排视图，这些数值多数含有估算成分，尤其是玩家终端、网络传输和硬件制造相关的部分。生成ESG报告之前，建议把口径说明一起导出，让读者知道哪些是采集值、哪些是估算值。这也符合九游会一贯的做法：宁可把不确定性写在旁边，也不让一个看起来精确的数字替读者做判断。
如果你之后更换设备，项目与报表存于账户云端，本地保留缓存，详细情况见换手机以后九游会App里的能源项目和碳足迹记录会不会丢。
