企业官网建设流程全解析

TABS 这款游戏，全名 Totally Accurate Battle Simulator，中文一般叫《全面战争模拟器》，它的核心乐趣从来不在于数值平衡做得多精细，而在于那套物理布娃娃加单位 AI 的沙盒系统会“自己长出”一堆设计者没写进说明书的交互。所谓“连携彩蛋”，就是两个本来各自独立的单位，在特定站位、特定时序、特定状态下凑到一起时，出现的额外表现——可能是一段特效、一次数值溢出、一段 AI 行为异常，也可能只是动画层叠出来的视觉错觉。

这次讨论的是新版主教和赫菲斯托斯之间的连携现象。主教属于治疗/增益向单位，赫菲斯托斯属于重型近战定位，这两类单位放在同一战场上是天然的“长窗口观察组合”：一个负责持续回血拉长战斗时间，一个负责吸收伤害维持接触状态，接触时间足够长，隐藏交互才有机会暴露出来。新版主教如果经历过机制调整，那么它与重型单位的交互逻辑很可能是最早出现差异的地方。

需要先说清楚的是，这篇文章不打算给你一个“确认存在/不存在”的结论。TABS 的单位数据随版本波动，不同平台、不同 DLC、不同创意工坊 Mod 环境下表现都可能不同，任何硬写死的数值都是不负责任的。本文提供的是一套可复现的验证方法：怎么锁定版本、怎么搭最小化场景、怎么设计对照实验、怎么用脚本批量录制、怎么排查“彩蛋没触发”的原因。

适合三类读者：想亲自确认彩蛋的普通玩家、需要稳定产出对比素材的内容创作者、以及对 Unity 沙盒游戏单位交互机制感兴趣的开发者。下面从规格、环境、复现、验证、自动化、性能、排错一路走完。

1. 核心能力速览

先把这篇文章涉及的能力边界列清楚。注意表格里的“不确定”不是偷懒，而是 TABS 的单位参数会随更新调整，写死数字反而会误导你去做错误对比。

这里要特别强调一点：TABS 的“批量”指的是同屏放置大量单位，而不是像服务端那样跑任务队列。很多人把这两个概念混淆，结果去找“命令行参数”，那是找不到的。真正的批量能力来自你在游戏外部搭的那条录制流水线，游戏本身只负责呈现。

还有一点值得提前说明：TABS 每次大版本更新，单位的行为树、动画状态机、碰撞体积都可能被微调。所以任何关于“彩蛋”的结论都必须绑定一个版本号。你看到的录像如果没有标注版本，参考价值会打对折。这也是后面第 3 节要专门做版本锁定和基线记录的原因。

2. 这个彩蛋到底在测什么：机制拆解与使用边界

2.1 连携彩蛋的三种常见表现形式

在 TABS 这类沙盒游戏里，“连携”不是一个官方术语，而是玩家对“跨单位额外交互”的统称。从可观察的角度，它大致分三层。

第一层是视觉层。最容易被发现，也最容易被误判。两个单位的粒子特效、光效、材质在空间上叠加时，可能产生新的观感，比如治疗光效打在金属材质单位身上出现异常的反射或颜色混合。这类现象本质是渲染叠加，不涉及游戏逻辑，但玩家截图传播时往往会被当成“官方彩蛋”。

第二层是数值层。治疗量溢出、护盾叠加上限被突破、伤害倍率异常、单位血量在极短时间内跳变。这一层需要你打开血量显示或者用慢放逐帧比对，肉眼在正常速度下几乎看不出来。

第三层是行为层。AI 目标切换异常、动画状态被重置、单位出现短暂停顿、攻击间隔被拉长或缩短。这一层最有意思，因为它通常意味着两个单位的状态机发生了意料之外的互相干扰。

判断你看到的是哪一层，直接决定了验证方法。视觉层用截图对比，数值层用慢放加血量读数，行为层用逐帧分析加多次重复。把三层混在一起讨论，最后一定吵不出结果。

2.2 为什么主教加赫菲斯托斯是值得单独测的组合

从机制上说，这个组合的观察窗口非常理想。治疗型单位的存在会把战斗时长显著拉长，而重型单位的高血量又保证了接触状态能维持足够久。接触时间越长，行为层交互暴露的概率越高。相比之下，如果拿两个脆皮远程单位去测，战斗可能在两三秒内结束，你连慢放都来不及看清。

其次，新版主教如果经历过机制重做，那它大概率在“治疗触发条件”“作用范围判定”“目标选择优先级”这三处有改动。而重型近战单位的受击频率高、受击判定体积大，正好是检验这三处改动最敏感的载体。换句话说，即使最终没有找到所谓的“彩蛋”，这套对照实验也能帮你弄清楚新版主教的实际治疗逻辑。这是稳赚不赔的测试设计。

第三，赫菲斯托斯这类重型单位通常带有明显的受击反馈（击退、硬直、格挡动作），这些反馈和治疗特效在时间轴上对齐时，很容易产生“看起来像彩蛋”的合成画面。你需要有能力区分“真交互”和“恰好的时间对齐”。

2.3 使用边界与合规提醒

必须把话说在前面。验证彩蛋的所有操作都应该在游戏正常功能范围内进行：使用沙盒模式摆位、使用游戏内置的慢放和暂停、使用创意工坊里公开的模组。不要修改游戏本体文件，不要绕过平台验证，不要使用来源不明的第三方补丁。

如果你打算把验证过程做成内容发布，还要注意素材合规。游戏画面的使用范围参考平台的内容政策；背景音乐如果不是游戏原声，需要确认授权；创意工坊的 Mod 作者通常有自己的转载要求，用之前看一眼说明页。

另外，涉及创意工坊 Mod 的实验一定要单独隔离。Mod 修改了单位数据或行为逻辑时，你测出来的“彩蛋”可能只是某个 Mod 的副作用。第 5 节的对照实验里，我会把“纯净环境”和“Mod 环境”作为两个独立分支处理。

3. 复现环境准备：版本、录制链路与目录规划

3.1 版本锁定与基线记录

这一步是整篇文章里最容易被跳过、但影响最大的一步。你需要做的第一件事，是在启动游戏后截图记录当前版本号，把它和你后续所有录像、截图放在同一个目录里。TABS 的更新频率不低，没有版本锚点的实验记录，两周后就没法复盘。

基线记录建议包含四项：游戏版本号截图、平台与客户端信息、是否启用任何创意工坊 Mod 的清单、当前画质与分辨率设置截图。这四项决定了你后续任何一次复现是否在“同等条件”下进行。

如果游戏支持回退到旧版本（部分平台提供版本分支功能），建议在你确认某个版本的彩蛋表现后，把版本号写进实验记录的标题里。这样别人拿着你的记录去复现，失败时至少知道自己版本不对，而不是直接得出“彩蛋是假的”这个结论。

3.2 录制链路的选择

录制链路有两个层级，按需求选。

轻量级方案用系统自带的录制功能，优点是零安装、启动快，缺点是可调参数少、长时间录制容易掉帧、文件管理混乱。适合只想随手截一段的玩家。

专业级方案用 OBS Studio。它的价值不在于画质，而在于可控性：你可以固定编码器、固定码率、固定帧率，还可以通过 WebSocket 接口用脚本控制开始和停止录制。第 6 节的自动化流水线就是建立在 OBS 的远程控制能力上的。

录屏参数上，建议 1080p、60 帧、使用硬件编码器（NVENC 或同等级的 GPU 编码）。60 帧的意义在于慢放时你有足够的中间帧可以看。如果只录 30 帧，放慢到 0.25 倍速时每帧间隔会被拉得很开，行为层的细微停顿就判断不准了。

3.3 目录结构规划

实验做多了以后，文件管理混乱带来的时间浪费会超过实验本身。建议在开始前就把目录结构定死，后面所有东西往里扔就行。

# 在 Windows PowerShell 中创建实验目录结构 $root = "D:\tabs-lab" $dirs = @( "$root\versions", # 版本号截图与环境基线 "$root\scenes", # 每次实验的场景配置说明 "$root\records", # 原始录制文件 "$root\clips", # 切片后的片段 "$root\frames", # 逐帧导出的关键帧 "$root\logs" # 实验记录与观察日志 ) foreach ($d in $dirs) { if (-not (Test-Path $d)) { New-Item -ItemType Directory -Path $d | Out-Null } } Write-Host "目录结构已就绪: $root"

目录命名上，records里的文件建议统一成日期_版本_场景编号_实验编号的格式，例如20250310_v1x_x_s03_e02.mp4。这种命名看起来啰嗦，但当你手上有八十个文件要对比时，它能救命。

3.4 一个容易被忽略的前置条件

沙盒模式的场地选择会显著影响观察结果。开阔平地适合看特效叠加，带高低差的场地适合看击退和碰撞。建议同一个实验至少在两种场地上各跑一次，避免把“地形导致的碰撞异常”误判成“单位连携”。

另外，把游戏内的单位数量上限调到你能承受的最大值以上，但实际测试时只用两三个单位。上限高不代表你要堆满，它只是保证你在做数量梯度实验（第 5.5 节）时不会提前撞到硬限制。

4. 复现步骤：从沙盒搭场景到触发连携

4.1 第零步：记录实验元信息

每次实验开始前，先写一条记录。别嫌麻烦，这一步用不了一分钟，但能省掉后面反复回忆“我那次到底开了几个单位”的痛苦。

{ "experiment_id": "e02", "date": "2025-03-10", "game_version": "以启动界面截图为准", "platform": "PC", "mods_enabled": [], "map": "开阔平地", "units": { "team_a": ["新版主教 x1"], "team_b": ["赫菲斯托斯 x1"] }, "settings": { "time_scale": 1.0, "health_bar_visible": true, "unit_limit": 100 }, "observation_focus": ["治疗特效与受击反馈的时间对齐"], "result": "待填写" }

这份模板的关键是mods_enabled和observation_focus两个字段。前者保证你的结论不会被 Mod 污染，后者强迫你在开始前就想清楚“我要看什么”，而不是录完一堆素材回来发现什么也没看清。

4.2 第一步：搭建最小化场景

最小化场景的原则是：场上只有你要观察的单位，其他一切干扰项全部去掉。具体做法是进沙盒模式，选择开阔平地，红蓝双方各放一个单位，关掉自动开战或者手动控制开战时机。

为什么要手动控制时机？因为自动开战会让两个单位从随机距离开始接近，每次的接触时序都不同。手动控制可以让你固定“接触瞬间”的时间点，方便逐帧对齐比较。

如果游戏提供了“暂停后摆位”的功能，优先用它。暂停状态下摆好位置，再恢复时间流动，你能得到最干净的起始条件。

4.3 第二步：用慢放锁定接触窗口

正常速度下，两个单位的接触可能在两秒内完成，治疗特效只闪一下。你要做的是把时间缩放调到最低档（通常是 0.1 倍或更低），然后观察接触瞬间到接触结束后约一秒的区间。

这个窗口里重点看三件事：治疗特效出现的帧号、赫菲斯托斯受击反馈出现的帧号、两者之间是否存在稳定的时间偏移。如果三次实验中这个偏移量高度一致，那就有可能是逻辑层面的联动，而不是随机的时间对齐。

4.4 第三步：重复与变异

单次观察不足以支撑任何结论。最少重复三次，条件完全一致。如果三次都复现，进入变异测试：改动一个变量，比如交换双方的站位、改变开战距离、增加一个第三方单位。变异测试的目的是找出“触发条件的最小集合”。

这一步的意义在于，如果彩蛋只在特定站位下出现，那它大概率是位置判定相关的交互；如果任何站位都能出现，那可能是全局状态相关的逻辑。这两种情况的性质完全不同，后续的排查方向也不一样。

5. 功能测试与效果验证

下面六组实验，建议按顺序做。每组都要记录实验编号、观察结果和判定结论。

5.1 实验 A：单主教基线

目的是建立新版主教的单独行为基线。场景里只放一个主教，让它自己待着或者攻击一个无威胁目标，观察它的治疗触发条件、特效持续时间、特效影响范围、是否有前置动作。

这组实验的价值在于，后面你看到任何“异常”，都需要先排除“这本来就是主教的正常表现”。很多所谓的彩蛋，其实是观察者不熟悉单个单位的基础行为导致的误判。

判定标准很简单：你能用一句话描述出“新版主教在无外力干扰下，多久触发一次治疗、特效持续多久、覆盖多大范围”。描述不出来，说明基线没建立好，回去重做。

5.2 实验 B：单赫菲斯托斯基线

同样地，单独观察赫菲斯托斯。重点看它的受击反馈类型、硬直时长、攻击前摇、是否有格挡或减伤动作。

这组实验要特别关注受击反馈的“可辨识度”。如果赫菲斯托斯的受击反馈本身就很花哨，那后面和治疗特效叠加时，你很难分清哪个像素属于谁。提前把它的反馈特征记熟，是后面做区分的前提。

5.3 实验 C：同队共存

把主教和赫菲斯托斯放在同一队，对面放一个低威胁单位（比如血量高但输出低的单位），让战斗能持续足够久。

观察重点：主教是否优先治疗赫菲斯托斯、治疗特效打在赫菲斯托斯身上时是否有额外表现、赫菲斯托斯在受到治疗期间的受击反馈是否发生变化。

预期结果分三种情况：一，完全无变化，说明两者之间没有特殊交互；二，仅有视觉叠加，说明是渲染层面的合成；三，出现数值或行为层面的稳定差异，这才是值得继续深挖的方向。

5.4 实验 D：敌对状态

把两个单位放在对立阵营，让赫菲斯托斯攻击主教。

这组实验的目的是排除“同队才触发”的假设。有些交互逻辑是基于阵营判断的，敌对状态下的表现可能是完全另一套。如果你只测了同队，结论就有一半的盲区。

观察重点是主教在被重型单位近身时的行为：是否会中断治疗、是否会改变目标优先级、是否出现位移或闪避。这些表现如果和实验 A 的基线不同，那就说明重型单位的近身压力改变了主教的行为树，这本身就是一个有价值的发现。

5.5 实验 E：数量梯度

固定其他条件，把双方数量从 1v1 逐步加到 2v2、3v3、5v5。

这组实验看的是“规模效应”。有些交互在单个单位时不可见，因为特效太小或者触发概率太低；数量上去之后，统计意义上的差异才会显现。反过来，如果 1v1 能看到明显差异，5v5 时反而看不到了，那说明这个差异是被特效淹没的，不是消失了。

数量梯度的另一个作用是对照性能表现。单位数量上去以后帧率会下降，而帧率下降会影响你对“行为层异常”的判断——你看到的停顿可能只是掉帧，不是游戏逻辑。第 7 节会专门讲这个问题。

5.6 实验 F：加入第三方干扰

最后加一个“搅局者”。可以是一个远程单位，也可以是一个会强制位移的单位。

目的是测试连携现象的稳定性。如果加了第三方以后彩蛋就消失了，说明它依赖一个非常脆弱的条件（比如两个单位必须保持特定距离），这种交互在实际对局中出现的概率极低，传播价值也有限。如果加了第三方依然稳定复现，那它的性质就更接近“设计好的联动”，值得重点记录。

5.7 判定与记录

每组实验的结论建议用三档标记：稳定复现、偶发、未观察到。不要用“有/没有”这种二元判断，因为沙盒游戏的随机性决定了中间状态是常态。

记录时把判定依据写清楚，比如“三次实验中两次出现约 0.2 秒的特效延迟，一次未出现，判定为偶发”。这种记录方式比一句“好像有彩蛋”有用一百倍。

6. 自动化批量验证：脚本、录制与素材流水线

6.1 先明确能力边界

TABS 本体不提供任何对外接口，你不能像调用 AI 模型那样发一个 HTTP 请求就让游戏跑一局。所谓“自动化”，指的是用外部工具替代你的手，去完成重复性的操作：重复摆位、重复开战、重复录制、重复切片。

这条路可行，但你要接受它的脆弱性。桌面自动化依赖固定分辨率和固定窗口位置，游戏一更新界面布局，脚本就得改。所以脚本要写得足够简单，改动成本低，别搞成一堆复杂的状态机。

6.2 用 OBS WebSocket 控制录制

OBS 提供了 WebSocket 接口，可以用 Python 远程控制开始和停止录制。这样你就不用每次手动点按钮，也不会忘记开录。

# 通过 OBS WebSocket 控制录制，需先在 OBS 中启用 WebSocket 服务器 # 依赖: pip install obs-websocket-py import time from obswebsocket import obsws, requests HOST = "127.0.0.1" PORT = 4455 # 以 OBS 设置中的实际端口为准 PASSWORD = "your_password" def record_segment(ws, name, duration_sec): ws.call(requests.SetCurrentScene(scene_name="TABS_Capture")) ws.call(requests.StartRecord()) print(f"[REC] 开始录制: {name}") time.sleep(duration_sec) resp = ws.call(requests.StopRecord()) print(f"[REC] 结束录制: {resp.getOutputPath()}") def main(): ws = obsws(HOST, PORT, PASSWORD) ws.connect() try: for i in range(1, 11): record_segment(ws, f"e02_take{i}", 25) time.sleep(5) # 留出复位场景的时间 finally: ws.disconnect() if __name__ == "__main__": main()

这段脚本只做一件事：循环录十段，每段 25 秒，中间留 5 秒复位。复位动作需要你自己在游戏里完成，或者用下面那套桌面自动化补上。

6.3 用桌面自动化做固定摆位

如果你要做几十次重复摆位，手点会很累。可以用pyautogui做固定坐标点击。注意这套方案对分辨率极其敏感，换显示器就要重录坐标。

# 固定坐标点击示例，仅用于重复性摆位操作 # 依赖: pip install pyautogui # 使用前必须确认游戏窗口位置与分辨率与录坐标时完全一致 import pyautogui import time pyautogui.FAILSAFE = True # 鼠标移到屏幕左上角可紧急停止 # 下列坐标为示例占位，必须替换为你本机实测的坐标 COORDS = { "open_sandbox": (420, 610), "pick_bishop": (250, 300), "pick_hephaestus":(980, 300), "place_spot_a": (700, 500), "place_spot_b": (860, 500), "start_battle": (1180, 660) } def click(key, delay=0.4): x, y = COORDS[key] pyautogui.moveTo(x, y, duration=0.15) pyautogui.click() time.sleep(delay) def reset_and_place(): click("open_sandbox", delay=1.2) click("pick_bishop") click("place_spot_a") click("pick_hephaestus") click("place_spot_b") if __name__ == "__main__": time.sleep(3) # 留出切窗口的时间 for round_idx in range(5): reset_and_place() click("start_battle", delay=1.0) time.sleep(28)

坐标必须你自己量。每个人显示器分辨率、任务栏高度、游戏窗口是否全屏都不一样，直接复制别人的坐标基本一定失败。这是这套方案最常见的坑。

6.4 用 ffmpeg 切片与抽帧

录完的原始素材通常很长，需要切成小段做对比，关键片段还要抽帧做逐帧分析。

# 从 00:01:20 开始，截取 6 秒片段，不做重编码，速度快 ffmpeg -ss 00:01:20 -t 6 -i ./records/raw_take1.mp4 -c copy ./clips/e02_contact.mp4 # 把一段 2 秒的接触窗口按每秒 30 帧导出为图片，用于逐帧比对 ffmpeg -ss 00:01:20 -t 2 -i ./records/raw_take1.mp4 -vf "fps=30" ./frames/e02_%04d.png

抽帧以后把关键几帧并排看，比对治疗特效出现的帧和受击反馈出现的帧，能得到比肉眼观察可靠得多的结论。

6.5 批量任务的目录与队列设计

如果你要做多个单位组合的横向对比，建议用一份清单文件驱动整个流程。

{ "output_root": "./outputs", "jobs": [ { "id": "j01", "team_a": ["bishop"], "team_b": ["hephaestus"], "takings": 3 }, { "id": "j02", "team_a": ["bishop", "bishop"], "team_b": ["hephaestus"], "takings": 3 }, { "id": "j03", "team_a": ["bishop"], "team_b": ["hephaestus", "hephaestus"], "takings": 3 } ], "post_process": { "clip_seconds": 6, "extract_fps": 30 } }

这份清单的好处是：脚本读它就知道要跑哪些组合、每个组合录几遍、后处理参数是什么。失败重试的逻辑也简单，只要记录每个 job 的完成状态，下次从没完成的开始跑。别指望一次跑完，桌面自动化中途出问题的概率不低，能断点续跑比什么都强。

7. 资源占用与性能观察

7.1 单位数量是主要压力来源

TABS 的性能瓶颈主要来自同屏单位数量。每个单位都带独立的 AI 状态机、动画、物理受力计算，单位多了以后，压力会集中到 CPU 侧的模拟计算上。所以你会看到一个很典型的现象：显卡占用不高，但帧率就是上不去。

观察方法很简单，打开任务管理器的性能面板，或者用游戏内的帧率显示（如果有），在单位数量从 1 加到 10 再加到 30 的过程中记录帧率变化。如果帧率在低单位数时就已经不稳，那问题不在单位数量，可能在录制链路或者后台程序。

7.2 录制带来的额外开销

录屏会额外占用编码资源。用 GPU 硬件编码时，压力主要落在显卡的编码单元上，对游戏帧率影响相对小；用 CPU 软件编码时，压力会叠加到本来就被模拟计算占满的 CPU 上，掉帧会更明显。

如果你在实验 E 的数量梯度测试中发现 5v5 时画面明显卡顿，先确认一下是不是录制导致的。方法是关掉录制，用同样的单位配置再跑一次，对比帧率。这一步能帮你区分“游戏性能问题”和“录制开销问题”，避免把掉帧误判成行为异常。

7.3 降低占用的几个手段

第一，降低录制分辨率。1080p 够用，没必要上 2K 或 4K 去录逐帧分析素材，因为你要看的是单位动作，不是材质细节。

第二，用硬件编码并固定码率。固定码率能保证文件大小可控，避免长时间录制把磁盘写满。

第三，实验时关掉不必要的后台程序。浏览器标签页、即时通讯软件、同步盘客户端都会抢资源，尤其是同步盘在后台扫描文件时，磁盘写入会直接影响录制稳定性。

第四，把原始录像和切片分开存放。原始录像体量大，放在机械盘上没问题；切片和抽帧要做频繁读写，放固态盘上体验会好很多。

7.4 时间缩放对观察的影响

慢放本身不影响性能，但它会拉长你的观察时间。0.1 倍速下一个 2 秒的接触窗口会变成 20 秒，连续做十次实验就是两百秒的纯观察时间。所以慢放要用在关键窗口上，不要全程慢放，否则效率会崩。

一个实用的做法是：正常速度跑到接触前一刻，暂停，切慢放，恢复，观察接触窗口，接触结束后立刻恢复正常速度。这样一局实验的实际耗时能压到几十秒。

8. 常见问题与排查方法

排查的核心思路是“变量隔离”。任何一个异常现象，先问自己：上一次表现正常时，哪个条件不一样？把那个条件单独改回去测一次，答案基本就出来了。最怕的是一次改动好几个条件，最后完全不知道该归因到哪里。

另外一个常见误区是过度依赖记忆。做实验的时候觉得“这个我肯定记得”，结果三天后回看素材，完全不记得当时开了几个单位、是不是开了 Mod。所以第 4.1 节的那份 JSON 记录模板，真的建议老老实实填。

9. 最佳实践与使用建议

第一，先小后大。永远从 1v1 的最小场景开始，确认基线行为以后再加变量。跳过基线直接上复杂场景，你会得到一堆无法归因的观察结果。

第二，保留一套最小可运行配置。具体来说就是：一个固定版本、一个固定场地、一套固定画质设置、一份固定的实验记录模板。这套东西不用多，但它保证你任何时候都能回到一个可对比的起点。

第三，输入素材、原始录像、切片、结论记录分目录管理。这不是洁癖，是效率问题。当你有五十个录像文件在一个文件夹里，找某一次特定条件的录像所花的时间，够你重做三次实验了。

第四，批量流程一定要加日志和失败标记。桌面自动化的失败是常态，脚本跑一半卡住、窗口失去焦点、弹窗遮挡，都可能发生。能在日志里看到“第 7 次录制失败”，比跑到最后发现少了三段素材要好得多。

第五，创意工坊 Mod 单独建环境。测 Mod 的时候把游戏恢复到纯净状态再逐个启用，一次只加一个。同时启用五个 Mod 出现问题，你排查的时间成本是线性叠加的。

第六，内容发布前做一次复核。特别是涉及“新发现”“隐藏机制”这类表述时，把录像再看一遍，确认没有把渲染叠加当成逻辑联动。这类误判在传播过程中会被不断放大，最后纠正的成本很高。

第七，注意素材使用的合规边界。游戏画面、创意工坊模组、背景音乐的使用范围都要确认。Mod 作者的授权要求通常写在创意工坊页面，用之前花两分钟读一下，比事后被要求下架要省事。

第八，版本更新后重新验证。TABS 的更新会调整单位行为，你上个月确认的结论，这个月可能就不成立了。养成在实验记录里写版本号的习惯，更新后优先重跑基线实验，而不是直接重跑复杂实验。

10. 总结与下一步

回到最初的问题：新版主教和赫菲斯托斯之间到底有没有连携彩蛋。这篇文章没有替你做结论，但给了一套能让你自己得出结论的方法。这套方法的核心不是某个具体操作，而是三个习惯：锁定版本、建立基线、隔离变量。

最值得先动手的，是第 5.1 和 5.2 两组基线实验。看起来最枯燥，但它们决定了你后面所有观察的可信度。很多人跳过这步直接去测组合，测出来的东西自己都说不清是彩蛋还是正常表现。

最容易踩的坑有三个。一是没记版本号，两周后完全无法复盘；二是把物理随机性导致的视觉巧合当成确定性机制；三是在有 Mod 的环境里做实验，测出来的其实是 Mod 的效果。这三个坑的共同点是：事后很难补救，只能事前预防。

如果这套流程跑顺了，下一步可以往三个方向扩。一是横向扩展，把主教和其他重型单位、把赫菲斯托斯和其他治疗单位都拉进来做组合矩阵，看看交互是否具有特异性。二是纵向深挖，用逐帧分析把某个稳定的时间偏移量精确到帧，这种数据在讨论机制时说服力最强。三是工程化，把摆位、录制、切片、抽帧整条链路串成一条命令跑完，那时候你做对比实验的效率会完全不是一个量级。

最后提醒一句，游戏机制的观察结论天然带有版本时效性。你今天的发现，可能在下一次更新后就不再成立。所以记录里一定要留版本号，这既是给自己留后路，也是给别人复现时的必要信息。