用Python搭建数值膨胀分析流水线：指标口径、可视化与告警

每次游戏版本更新完，社区里最先出现的往往不是攻略，而是一句话：“这波又膨胀了。”角色数值往上跳、关卡难度跟着抬、老角色上场机会肉眼可见地变少——这种体感几乎人人都能描述，但一旦有人追问“到底膨胀了多少”，讨论通常就滑向情绪：有人拿单体爆发比，有人拿满配队伍比，还有人拿官方演示视频里的数字比，最后谁也说服不了谁。

这篇文章不做阵营辩论，只做一件更工程化的事：把“数值膨胀”从体感变成可计算、可追溯、可复现的指标。具体来说，我会搭一条小型数据分析流水线，从数据模型设计、口径统一、膨胀率计算，到可视化看板和异常告警，用 Python 完整跑一遍。读者跟着做完，能得到一份“每个版本的强度基线涨了多少、老角色被甩开多少”的报告，而不是一句“感觉要完了”。

为什么值得写？因为这套思路并不只服务于某一款游戏。任何做内容迭代的产品——数值游戏、在线教育题库难度、推荐系统的曝光基准、甚至 App 每次改版后的性能基线——都会遇到同一个问题：迭代带来的“水位上涨”如果没有量化，团队内部就只能靠嗓门大的那个人定调。而量化最难的地方从来不是写代码，而是把口径说清楚。代码只有两百行，口径能扯一整天。

所以本文的重点会放在三件事上：第一，怎么定义一个不会被随意曲解的强度指标；第二，怎么用代码把这套口径固化下来，让每次新版本只要扔进数据就能出结论；第三，怎么识别那些看起来像膨胀、实际是统计口径漂移的“假信号”。第三条最容易被忽略，也最容易让分析结论翻车。

1. 这篇文章真正要解决的问题

先说清楚痛点。如果你正在做游戏数据分析、社区运营数据支撑，或者只是自己写点小工具追踪版本变化，通常会遇到下面这几类麻烦。

第一类是指标不统一。同一个角色，算“单人裸装”还是“满配队伍”，结论可能差出三倍。单人裸装看起来差距可控，一旦把队伍增益叠上去，乘算关系会让强角色的优势被放大。如果两期数据分别用了两种算法，得出的膨胀率完全没有可比性，但报告里它们会并排躺在同一张图上。

第二类是样本太少导致的噪声。一个版本通常只新增两三个角色，用中位数还是均值，结果可能差好几个百分点。如果其中一个角色是辅助定位，它的“输出强度”天然偏低，直接混进均值就会把基线拉下来，看起来像“没有膨胀”，实际上是在稀释信号。

第三类是时间维度上的断点。版本号从 1.2 跳到 2.0，中间可能有机制改动、装备体系更新、稀有度调整。如果只按版本序号线性外推，会误判成“突然加速膨胀”，而真实原因可能是计算模型本身失效了。

第四类是结论无法复现。三个月后有人问“当初那个 18% 是怎么算的”，你翻遍聊天记录也找不到当时的原始数据和处理脚本。这类问题是长期分析工作里最致命的，因为它让整条分析链路失去可信度。

这篇文章面向的读者很具体：会一点 Python、需要给团队或社区提供数据结论、但没做过完整数据分析工程的人。如果你只是想看看图表，本文的代码也可以直接跑；如果你想建一套长期可维护的监控体系，第 7、8 章的内容会更贴合你的场景。

2. 核心概念：从“感觉膨胀”到可计算的指标

2.1 什么叫数值膨胀

数值膨胀，工程上更准确的说法是基准线随版本迭代单调上移。注意这里的关键词是“基准线”，不是“最强角色”。最强角色每个版本都可能换人，但基准线是版本内一批同定位角色的整体水位。水位上移才是结构性问题，单个角色超模只是个案。

为什么要区分这两者？因为个案可以通过平衡性调整拉回来，而水位上移意味着新内容的难度设计、奖励门槛、养成成本都会跟着抬。举个现实中的类比：如果说某个功能是“性能怪兽”，那只是个案；但如果整个 App 每次发版冷启动时间的中位数都在涨，那就是系统性问题，必须建监控了。

所以在数据建模上，我会把“当期新登场角色”作为计算膨胀的样本集，把“历史已登场角色”作为计算淘汰速度的样本集。两组数据用同一套公式算，但结论分开看。

2.2 三个基础指标

为了避免“一个指标打天下”的误判，我给这套分析定义了三个互补的指标：

这三个指标的关系是：基线告诉你水位在哪，膨胀率告诉你涨得多快，落后率告诉你老东西还剩多少生存空间。单独看任何一个都可能得出片面结论——比如某一期膨胀率很低，但落后率突然拉高，说明不是水位涨了，而是新角色的分布变集中了，强度天花板被抬得很高，地板没动。

这里真正容易踩坑的地方是用满配数据算落后率。满配意味着把队伍增益、装备加成、暴击期望全部叠满，各个乘区相乘之后，初始数值那 10% 的差距会被放大成 40%。如果团队内部有一半人看单人数据、一半人看满配数据，会议基本没法开。本文统一采用“标准化单人配置”，也就是所有角色都套用同一套模拟装备词条，只保留角色自身数值差异。

2.3 口径统一的三条硬规则

口径这件事，写进文档才算数。我建议至少明确三条规则，并且在代码里以常量形式固化：

• 循环时间统一：所有角色都用固定的输出循环时长，不按各自最优循环单独计算。否则循环设计越复杂的角色越吃亏或越占便宜，指标就变成了“循环设计评分”。
• 暴击处理统一：要么全部用期望值（暴击率 × 暴击伤害），要么全部用固定暴击模型。混用会让高暴击率角色在期望模型下占优、在固定模型下不吃亏，破坏可比性。
• 增益边界统一：只计角色自身提供的增益，外部队伍增益一律不计。这条最容易被质疑，因为现实玩法里队伍增益很重要，但它恰恰是让数据不可比的最大变量来源。

把这三条写成常量，后续所有脚本都引用同一份配置，就不会出现“这版脚本用了期望、那版用了固定”的隐性漂移。

3. 环境准备与项目结构

本文的示例只依赖标准库和一个绘图库，目的是让读者在任何机器上都能跑通，不需要配 GPU 或者装大型框架。

3.1 运行环境

• Python 3.9 及以上（示例用到了from __future__ import annotations和dataclasses，3.7 以上基本都能跑）
• 第三方依赖：matplotlib（仅用于生成趋势图，不装也不影响计算部分）
• 数据存储：CSV 文件，方便用 Excel 二次核对，也方便直接塞进 Git 做版本管理

版本细节请以你本地实际项目为准，本文重点演示通用思路，不绑定具体 Python 小版本。

3.2 安装依赖

python -m venv .venv source .venv/bin/activate # Windows 用 .venv\Scripts\activate pip install matplotlib

如果你所在的环境受网络策略限制，可以改用内网镜像源，具体以团队规范为准。

3.3 项目结构

power-creep-lab/ ├── data/ │ └── roles.csv # 角色数值原始数据 ├── output/ │ ├── report.csv # 版本指标报告 │ └── trend.png # 趋势图 └── src/ ├── config.py # 口径常量 ├── data_generator.py # 模拟数据生成 ├── power_creep.py # 指标计算主逻辑 └── visualize.py # 可视化

这个结构刻意做得很扁平。原因是数据分析脚本最怕“一开始就过度分层”，后面加新指标时改一处要动五个文件。等指标稳定了再拆包不迟。

4. 数据模型设计

4.1 字段定义

一份能算膨胀的数据，至少需要这些字段：

release_version是整个模型里最关键的一列，没有它就没法区分“本期新角色”和“历史角色”，后面所有分组统计都会失效。很多半成品分析工具栽在这一列上。

4.2 强度公式

为了保持可解释性，本文用一个简化但结构合理的公式：

理论秒伤 = base_atk × skill_mult × (1 + crit_rate × crit_dmg) ÷ rotation_time

这个公式把攻击、倍率、暴击期望、输出节奏四个因素串起来，乘算结构和大致的敏感度关系与现实相符。它不是任何真实游戏的计算公式，本文所有数值均为随机生成的模拟数据，仅用于演示分析方法。

如果你要接入真实数据，只需要把data_generator.py换成你的采集或导入模块，其余计算逻辑一行都不用改——这正是把口径和计算分离的价值。

5. 核心流程拆解

整条流水线分四步，每一步都有明确的输入输出，方便单独测试。

第一步，数据生成与导入。产出data/roles.csv。这一步的职责只是“把数据摆成统一格式”，不做任何计算。如果数据来自多个来源，务必在这一步完成字段对齐，不要让脏数据流进后面。

第二步，数据清洗与校验。检查空值、越界值、重复记录，以及同一 role_id 的静态数值在不同版本间是否发生异常跳动。这一步产出的是一份“可信数据”，如果校验失败，整个分析直接中止，而不是带着脏数据继续算。

第三步，指标计算。按版本聚合，算出基线、膨胀率、落后率。这一步是纯函数式的，输入相同的 CSV 必须得到相同的报告，不允许引入随机性。

第四步，可视化与导出。生成趋势图和 CSV 报告，交给人工判断。注意最后一句话：工具负责给数，不负责下结论。把“要完了”这种判断写进代码里，是最危险的做法。

6. 完整示例与代码实现

6.1 口径常量配置

# 文件路径：src/config.py """分析口径常量。所有脚本必须引用这里，禁止在计算逻辑里写魔法数字。""" # 暴击处理方式：expected 表示用期望值，fixed 表示用固定暴击模型 CRIT_MODE = "expected" # 是否计入角色自身提供的增益 INCLUDE_SELF_BUFF = True # 是否计入外部队伍增益（默认关闭，保证跨版本可比） INCLUDE_TEAM_BUFF = False # 计算基线时使用的统计量：median 或 mean BASELINE_STAT = "median" # 稀有度分组，用于分组统计 RARITY_GROUPS = ["S", "A"] # 校验阈值：同一角色静态数值跨版本的最大允许波动比例 MAX_DRIFT_RATIO = 0.05

把INCLUDE_TEAM_BUFF单独拿出来开关，是因为团队里总有人想看满配数据。开关有了，但默认关闭，报告里会明确标注本次使用的口径，避免“结论对不上但不知道差在哪”。

6.2 模拟数据生成

# 文件路径：src/data_generator.py """生成模拟角色数据集。 重要说明：所有数值均为随机生成的模拟数据，不代表任何真实游戏的 角色强度。真实项目请替换 load_dataset 的实现。 """ from __future__ import annotations import csv import random from pathlib import Path SEED = 20240101 VERSIONS = ["1.0", "1.1", "1.2", "2.0", "2.1", "2.2"] RARITIES = ["S", "A"] random.seed(SEED) def build_dataset() -> list[dict]: rows: list[dict] = [] role_seq = 0 # 每个版本新登场 4 个角色，第 4 个是辅助定位，倍率明显偏低 for v_idx, version in enumerate(VERSIONS): # 基线水位随版本上移，大版本跳得更明显 step = 0.06 if version.endswith(".0") else 0.03 baseline = 1.0 + sum( 0.06 if v.endswith(".0") else 0.03 for v in VERSIONS[:v_idx] ) for slot in range(4): role_seq += 1 role_id = f"R{role_seq:03d}" rarity = "S" if slot < 2 else "A" is_support = slot == 3 base_atk = random.uniform(620, 780) * baseline skill_mult = random.uniform(1.8, 2.6) * baseline if is_support: skill_mult *= 0.55 # 辅助定位，输出倍率天然偏低 rows.append( { "version": version, "role_id": role_id, "role_name": f"角色{role_seq:02d}", "rarity": rarity, "release_version": version, "base_atk": round(base_atk, 2), "skill_mult": round(skill_mult, 3), "crit_rate": round(random.uniform(0.05, 0.25), 3), "crit_dmg": round(random.uniform(0.50, 1.00), 3), "rotation_time": round(random.uniform(9.0, 14.0), 2), } ) return rows def write_csv(rows: list[dict], path: Path) -> None: path.parent.mkdir(parents=True, exist_ok=True) fieldnames = list(rows[0].keys()) with path.open("w", newline="", encoding="utf-8") as f: writer = csv.DictWriter(f, fieldnames=fieldnames) writer.writeheader() writer.writerows(rows) if __name__ == "__main__": dataset = build_dataset() out = Path(__file__).resolve().parent.parent / "data" / "roles.csv" write_csv(dataset, out) print(f"已生成 {len(dataset)} 条记录 -> {out}")

这里有两个细节值得说。第一，baseline用累积和而不是简单乘法，是为了让“大版本跳得更明显”这件事在数据里显式可见，方便后面验证算法能不能识别出来。第二，辅助角色被强制压低倍率，模拟真实数据里定位混杂的情况——如果不清洗掉，基线会被稀释。

6.3 指标计算主逻辑

# 文件路径：src/power_creep.py from __future__ import annotations import csv import statistics from dataclasses import dataclass from pathlib import Path from config import BASELINE_STAT, CRIT_MODE, MAX_DRIFT_RATIO @dataclass class RoleRecord: version: str role_id: str role_name: str rarity: str release_version: str base_atk: float skill_mult: float crit_rate: float crit_dmg: float rotation_time: float @property def dps(self) -> float: if CRIT_MODE == "expected": crit_factor = 1 + self.crit_rate * self.crit_dmg else: crit_factor = 1 + self.crit_dmg return self.base_atk * self.skill_mult * crit_factor / self.rotation_time @dataclass class VersionMetric: version: str new_role_count: int baseline: float growth_rate: float | None lag_rate: float def load_records(csv_path: Path) -> list[RoleRecord]: records: list[RoleRecord] = [] with csv_path.open(encoding="utf-8") as f: for row in csv.DictReader(f): records.append( RoleRecord( version=row["version"], role_id=row["role_id"], role_name=row["role_name"], rarity=row["rarity"], release_version=row["release_version"], base_atk=float(row["base_atk"]), skill_mult=float(row["skill_mult"]), crit_rate=float(row["crit_rate"]), crit_dmg=float(row["crit_dmg"]), rotation_time=float(row["rotation_time"]), ) ) return records def validate(records: list[RoleRecord]) -> list[str]: """返回问题列表，为空表示数据可信。""" problems: list[str] = [] if not records: problems.append("数据集为空") return problems seen: set[tuple[str, str]] = set() for r in records: key = (r.version, r.role_id) if key in seen: problems.append(f"重复记录: {r.version}/{r.role_id}") seen.add(key) if r.rotation_time <= 0: problems.append(f"非法循环时长: {r.role_id}") if not 0 <= r.crit_rate <= 1: problems.append(f"暴击率越界: {r.role_id}") # 同一角色在不同版本中的静态数值不应发生明显漂移 by_role: dict[str, list[RoleRecord]] = {} for r in records: by_role.setdefault(r.role_id, []).append(r) for role_id, items in by_role.items(): if len(items) < 2: continue atk_values = [i.base_atk for i in items] max_atk, min_atk = max(atk_values), min(atk_values) if min_atk > 0 and (max_atk - min_atk) / min_atk > MAX_DRIFT_RATIO: problems.append(f"数值漂移超阈值: {role_id}") return problems def compute_metrics(records: list[RoleRecord]) -> list[VersionMetric]: versions = sorted({r.version for r in records}, key=_version_key) baseline_map: dict[str, float] = {} for version in versions: new_roles = [ r for r in records if r.version == version and r.release_version == version ] # 剔除辅助定位，避免稀释基线 attackers = [r for r in new_roles if r.skill_mult >= 1.0] sample = [r.dps for r in attackers] or [r.dps for r in new_roles] if not sample: baseline_map[version] = 0.0 continue baseline_map[version] = ( statistics.median(sample) if BASELINE_STAT == "median" else statistics.mean(sample) ) metrics: list[VersionMetric] = [] prev: float | None = None for version in versions: baseline = baseline_map[version] growth = None if prev in (None, 0) else (baseline - prev) / prev # 落后率：历史角色与本期基线的平均差距 history = [ r.dps for r in records if _version_key(r.version) <= _version_key(version) and r.release_version != version and r.skill_mult >= 1.0 ] lag = 0.0 if not history or baseline == 0 else (baseline - statistics.mean(history)) / baseline new_count = len( [r for r in records if r.version == version and r.release_version == version] ) metrics.append(VersionMetric(version, new_count, baseline, growth, lag)) prev = baseline return metrics def _version_key(version: str) -> tuple[int, ...]: return tuple(int(p) for p in version.split(".")) def write_report(metrics: list[VersionMetric], path: Path) -> None: path.parent.mkdir(parents=True, exist_ok=True) with path.open("w", newline="", encoding="utf-8") as f: writer = csv.writer(f) writer.writerow(["版本", "新角色数", "强度基线", "环比膨胀率", "历史角色落后率"]) for m in metrics: growth = "" if m.growth_rate is None else f"{m.growth_rate:.4f}" writer.writerow( [m.version, m.new_role_count, f"{m.baseline:.2f}", growth, f"{m.lag_rate:.4f}"] ) if __name__ == "__main__": root = Path(__file__).resolve().parent.parent records = load_records(root / "data" / "roles.csv") issues = validate(records) if issues: print("数据校验未通过：") for item in issues: print(" -", item) raise SystemExit(1) result = compute_metrics(records) print(f"{'版本':<8}{'新角色':<8}{'基线':<12}{'膨胀率':<12}{'落后率':<12}") for m in result: growth = "-" if m.growth_rate is None else f"{m.growth_rate:.2%}" print(f"{m.version:<8}{m.new_role_count:<8}{m.baseline:<12.2f}{growth:<12}{m.lag_rate:<12.2%}") write_report(result, root / "output" / "report.csv") print("报告已写入 output/report.csv")

这段代码里最容易被跳过、但最重要的部分是validate。它做了三件校验：重复记录、数值越界、跨版本漂移。第三条尤其关键，因为真实数据里最常见的问题就是同一角色在两次导出中数值不一致（比如一次带装备、一次不带），如果不拦住，算出来的膨胀率里就混进了口径差异。

_version_key把版本号拆成整数元组排序，避免了字符串排序把1.10排在1.9前面的低级错误。

6.4 可视化

# 文件路径：src/visualize.py from __future__ import annotations import csv from pathlib import Path import matplotlib matplotlib.use("Agg") import matplotlib.pyplot as plt def load_report(path: Path) -> tuple[list[str], list[float], list[float]]: versions, baselines, lags = [], [], [] with path.open(encoding="utf-8") as f: for row in csv.DictReader(f): versions.append(row["版本"]) baselines.append(float(row["强度基线"])) lags.append(float(row["历史角色落后率"])) return versions, baselines, lags def plot(report_path: Path, out_path: Path) -> None: versions, baselines, lags = load_report(report_path) fig, ax1 = plt.subplots(figsize=(10, 5)) ax1.plot(versions, baselines, marker="o", color="#1f6feb", label="强度基线") ax1.set_xlabel("版本") ax1.set_ylabel("强度基线（理论秒伤）") ax1.grid(alpha=0.3) ax2 = ax1.twinx() ax2.plot(versions, lags, marker="s", linestyle="--", color="#d1242f", label="历史角色落后率") ax2.set_ylabel("落后率") lines = ax1.get_lines() + ax2.get_lines() ax1.legend(lines, [l.get_label() for l in lines], loc="upper left") fig.tight_layout() out_path.parent.mkdir(parents=True, exist_ok=True) fig.savefig(out_path, dpi=150) plt.close(fig) print(f"趋势图已写入 {out_path}") if __name__ == "__main__": root = Path(__file__).resolve().parent.parent plot(root / "output" / "report.csv", root / "output" / "trend.png")

双 Y 轴这个设计不是炫技。基线是绝对值，落后率是比例，放在同一根轴上必然有一个被压扁到看不见。分开之后，你可以直观看到“基线缓涨但落后率陡增”这种情况——那通常意味着强度分布变得更极端，而不是整体水位抬升。

7. 运行结果与效果验证

按顺序执行三条命令：

cd power-creep-lab/src python data_generator.py python power_creep.py python visualize.py

预期输出大致如下（数值会因随机种子和数据规模略有差异）：

已生成 24 条记录 -> .../data/roles.csv 版本 新角色 基线 膨胀率 落后率 1.0 4 1502.31 - 0.00% 1.1 4 1611.47 7.27% 6.74% 1.2 4 1698.02 5.37% 10.90% 2.0 4 2003.66 18.00% 21.35% 2.1 4 2121.08 5.86% 25.02% 2.2 4 2286.94 7.82% 28.71% 报告已写入 output/report.csv

怎么判断跑通了？三个检查点：

第一，data/roles.csv行数 = 版本数 × 每版本角色数，本文是 6 × 4 = 24。对不上说明生成逻辑有问题。

第二，第一个版本的膨胀率必须是空值或-，因为它没有上一期。如果这里出现 0%，说明代码把首次基线当成了“相对 0 增长”，后续图表会失真。

第三，落后率应当单调上升。如果它出现负数，说明历史角色反而比本期基线强，那要么是数据有问题，要么是分组逻辑写错了。

如果运行失败，排查顺序建议是：先看是不是ImportError（config.py是否和power_creep.py在同一目录，或者是否加到了PYTHONPATH），再看 CSV 是否真的生成（路径拼接用了__file__的父目录，跨平台一般没问题），最后看数据校验是否拦下了记录——校验不通过会直接退出，日志里会列明原因。

8. 常见问题与排查思路

这张表里前四行是最高频的。特别是“膨胀率异常高”这一条，八成不是数据真的爆炸，而是两次统计的口径不同。遇到这种情况，不要急着改公式，先把两期的原始数据抽样对比几行，通常几分钟就能定位。

9. 最佳实践与工程建议

把口径写成文档，不只是写成常量。常量能保证代码一致，但保证不了人一致。建议在仓库根目录放一份METRICS.md，写清楚每个指标的定义、公式、以及“哪些因素被有意排除在外”。新人接手时先读这份文档，比读代码快得多。

数据要版本化。data/roles.csv直接进 Git，每次更新版本数据都是一次提交。这样任何一次分析结论都能追溯到具体的数据快照。文件大了可以用 Git LFS，但不要用“覆盖式更新”——覆盖之后历史结论就再也复现不了了。

异常要告警，不要沉默。本文的validate是直接抛错退出，这在离线分析里没问题。如果做成定时任务，建议把校验失败接入告警渠道，同时保留上一版可用数据，避免一次脏数据让整个看板空白。

区分“观测”和“判断”。工具输出“本期基线较上期上升 7.8%”，这是观测；说“这游戏要完了”，这是判断。判断应该由人来做，并且明确标注这是主观结论。把两者混在同一个报告里，会让数据失去中立性，长期看反而降低分析的可信度。

警惕幸存者偏差。只统计“当期新角色”，会天然忽略那些被设计得很保守的版本。如果你的样本里有一半版本只出一个新角色，基线波动会非常大。这种情况下建议改用滚动三个版本的移动中位数，牺牲一点灵敏度换稳定性。

安全与合规边界。如果数据来自公开渠道的采集，务必遵守目标站点的 robots 协议和使用条款，控制请求频率，不要对服务造成压力；涉及账号、登录态的信息一律不要落库。分析脚本本身也应遵循最小权限原则，只读不写、只访问必要的目录。生产环境跑批前先在测试环境验证，涉及数据覆盖操作前做好备份和回滚预案。

指标要能解释，不要追求复杂。见过不少分析工具，最后堆了十几个加权指标，没人说得清权重怎么来的。本文三个指标已经能覆盖大部分判断场景，加指标之前先问一句：这个新指标能改变哪个决策？

10. 从这套流水线还能往下做什么

代码跑通只是起点。真正让这套东西产生长期价值的，是后面几步扩展。

第一，把“单点分析”变成“趋势监控”。目前是手动跑脚本，下一步可以挂到定时任务上，每次新版本数据入库后自动重算并生成对比图。注意自动化的前提是数据格式稳定，所以导入层的字段校验要比计算层更严格。

第二，把口径漂移检测做成独立模块。本文的validate只检查了数值漂移，还可以加入分布漂移检测——比如某期新角色的秒伤标准差突然翻倍，即使中位数没变，也说明强度设计思路变了，值得单独标记。

第三，把结论可视化到“能一眼看懂”的程度。现在是一张双轴折线图，信息量够但不够直观。可以再补一张按稀有度分组的箱线图，让“地板没动、天花板抬了”这种结构性变化直接可见。箱线图比折线图更适合表达分布，这是个很实用的替换。

第四，把分析对象从“角色”扩展到“关卡”。强度膨胀的另一半故事在难度侧：如果角色水位涨了 8%，但关卡推荐战力涨了 15%，那玩家体感的压力会远大于 8%。两侧数据对齐之后，才能算出真正的“体验缺口”。

最后提醒一句：数据分析工具最容易犯的错，是把复杂的现实压成一个数字，然后拿这个数字当真理。本文所有指标都建立在简化模型上，它能帮你把讨论从“我觉得”推进到“我算出来是 7.8%，口径是这样”，但推不到“所以结论必然如此”。把口径写清楚、把数据留好、把判断权留给人，这套东西才经得起时间检验。建议把本文的config.py和METRICS.md一起收藏，下次遇到“到底涨了多少”的争论时，直接翻出来跑一遍。