用 claude code 开发游戏逻辑时的帧同步代码生成挑战

这是一件很吊诡的事：我用 Claude Code 生成过完整的匹配系统、战斗结算、排行榜逻辑，甚至一套带权重抽奖的箱子系统，代码审下来基本不需要大改。但一到帧同步，同一个工具、同样的交互习惯，产出的代码却像换了一个模型，骨架是对的，填充物却塞满了不确定性炸弹。

这篇文章不是评测，也不是“AI vs 人类程序员”的立场站队。这是我在三个实际项目中用 Claude Code 辅助帧同步开发后，积累的一套判断框架和避坑清单。我会把那些“看起来对、跑起来崩、查起来难”的生成模式拆开，也会讲清楚哪些环节可以让 AI 高效代劳，哪些环节你应该亲自上手、一行一行写。

一、先把结论放在前面：AI 生成的帧同步代码，问题不在“写不出来”，而在“坏得不像 bug”

很多开发者对 AI 代码有一个直觉预期：如果生成出来的东西跑不通、编译不过、有明显语法错误，那就是翻车了。反过来，如果一次生成就能编译通过、逻辑跑通、单机表现正常，就认为“AI 搞定了”。

在帧同步这个领域，这个判断标准完全失效。

帧同步代码的核心要求不是“能跑”，而是“在所有客户端上，以完全相同的方式、在完全相同的逻辑帧内、产出完全一致的状态序列”。这意味着代码的正确性不取决于它在单机上的表现，而取决于它在多客户端回放时的 确定性、可重现性 和 边界一致性。

AI 生成的帧同步代码最常见的状态是：编译通过、单机流畅、多客户端表现随机。你看到的现象可能是“另一个玩家瞬移了一下”、“某次回放战斗结果不一样”、“断线重连后状态偏离”，这些问题的根因，往往不是逻辑错误，而是隐藏在代码深处的 非确定性依赖。

这就导致一个特别糟糕的调试局面：bug 的表象在不同的客户端上表现不一致，复现条件依赖网络波动或帧序列，而你的第一反应永远是“是不是我 Prompt 写得不够好”。不是。问题出在你让 AI 做了一件它本质上不擅长的事，在没有人类显式约束的情况下，生成一个完全确定性的时序逻辑系统。

二、我之前误判了什么：一次真实的 Claude Code 帧同步生成复盘

为了避免泛泛而谈，我先还原一个真实的工作片段。

2024 年底我在做一个俯视角的多人对战原型，客户端用 Unity，帧同步逻辑放在一个独立 C# 项目中编译成 dll 供服务端和客户端共享。战斗逻辑不算复杂：玩家移动、技能释放、碰撞检测、状态机。我打算先把帧同步骨架搭出来，于是开了 Claude Code，给了这样一个 Prompt：

“用 C# 实现一个确定性的帧同步系统，支持最多 4 个玩家，逻辑帧固定 66ms，每个逻辑帧处理输入队列、执行帧更新、输出状态快照。要求代码可在 Unity 中复用。”

Claude Code 的第一次输出让我很受用。它生成了一个 FrameSyncKernel 类，包含帧号管理、输入队列、AdvanceFrame() 方法，甚至贴心地加了帧超时判断和空帧填充逻辑。我对这份代码做了三次审查：

1. 结构审查：类职责划分清晰，接口抽象合理。
2. 逻辑审查：帧推进流程符合我预期。
3. 边界审查：输入队列为空时有默认行为，帧号溢出有处理。

三审通过后我把它接入 Unity 做多客户端联调。问题在第十三分钟出现了：两个客户端在第二回合的怪物 AI 走位上出现了分歧。一个客户端怪物向左移动，另一个向右。我回放帧日志，发现两个客户端在第 347 帧使用了不同的随机数。

返查代码，我发现 Claude Code 在怪物 AI 逻辑中生成了这样一行：

var random = new System.Random();
var wanderAngle = random.NextDouble() * 360;

这行代码在单机测试时看起来毫无问题。但 Random 的无参构造函数会使用 Environment.TickCount 作为种子，这是一个依赖于系统时钟的非确定性源。在多客户端场景下，不同设备在构造 Random 实例时的 TickCount 毫秒值天然不同，导致随机数序列分叉。

这个 bug 的特别之处在于：它不像 bug。 它没有抛出异常，编译阶段没有任何警告，单机测试一切正常。它只是一个在帧同步语境下“不存在正确性”的设计选择。

这不是 Claude Code 的“错误”，而是它没有帧同步的“语境意识”。它的训练数据中充满了 new Random() 的用法，这些用法在 99% 的程序中都是合理的。但帧同步恰好属于那 1% 的领域，在这里，每一行代码都必须显式地保证确定性。

三、帧同步这个领域，难在哪里，又为什么刚好打中 AI 的软肋

要理解为什么 Claude Code 在帧同步上会反复犯错，需要先理解帧同步的核心技术特征。

帧同步（Lockstep）是一种网络同步架构，核心思想是所有客户端在相同的逻辑帧内执行完全相同的指令序列，通过输入同步而非状态同步来保证一致性。它与状态同步的本质区别在于：状态同步传输的是“结果”（位置、血量、状态），帧同步传输的是“原因”（操作指令），然后让每个客户端自行计算结果。

这个架构有三个硬性的技术约束：

第一，确定性。 同样的初始状态 + 同样的输入序列 = 完全相同的最终状态。这要求整个逻辑链路中不存在任何非确定性源，包括但不限于：随机数生成必须使用可复现的种子算法、浮点运算必须考虑精度一致性、集合类型的遍历顺序必须稳定。

第二，逻辑帧与渲染帧的严格分离。 帧同步的逻辑帧是固定间隔的离散时间片，与渲染帧的垂直同步无关。所有游戏逻辑只发生在逻辑帧切面，渲染层只是对逻辑状态的插值展示。

第三，全量输入记录与可回放性。 帧同步天然要求能够回放整局对战的任意片段，因为“观战”和“断线重连”本质上就是从初始状态重放所有帧指令直到当前帧。

这三个约束恰好对应了 AI 代码生成的三个系统性弱项：

1. AI 生成代码时倾向于使用“默认行为”，而帧同步要求“显式行为”。Random() 的无参构造是默认行为，使用传入种子的 Random(seed) 是显式行为。AI 在概率上更愿意选择前者。
2. AI 很难理解“时间”在帧同步中的特殊语义。帧同步中的“时间”不是墙上的钟，而是一个单调递增的离散序列。AI 生成的代码中经常出现 DateTime.Now、Time.realtimeSinceStartup 这类真实时间引用。
3. AI 对“可序列化”和“确定性迭代”缺乏天然敏感度。当它生成一个 Dictionary 时，不会主动考虑遍历顺序在不同运行时环境中的差异。

更底层地讲，大型语言模型的核心能力是统计模式补全，而帧同步要求的是绝对逻辑一致性。两者在数学上就是相悖的。 模型在处理“常见代码模式”时表现优异，帧同步恰好要求在很多地方背离常见模式。

四、AI 在帧同步生成中最常见的五类错误，以及它们的结构化解法

我在多轮实践中系统性地梳理了 Claude Code 在帧同步代码生成中的错误模式。以下是五类最高频的陷阱，每个都附上实际案例和经过验证的修正策略。

4.1 非确定性随机数生成

这是最高发的问题，没有之一。

典型生成代码：

var rng = new System.Random();
var damage = rng.Next(minDamage, maxDamage);

问题分析： 如上文所述，Random 的无参构造使用系统时钟作为种子。在多客户端场景中，不同设备在同一逻辑帧构造 Random 实例时，TickCount 差异会导致不同步。更隐蔽的版本是使用 UnityEngine.Random，它同样依赖内部不可控的种子状态。

修正策略： 所有随机数生成必须通过一个全局的确定性随机生成器，该生成器在逻辑帧开始时接受外部传入的种子，并在帧内所有逻辑中共享。

// 修正版：确定性随机数接口
public interface IDeterministicRandom
{
    void Seed(int seed);
    int Next(int min, int max);
    float NextFloat();
}

关键原则： 帧同步系统中的任何代码都不应该创建自己的随机数生成器实例。随机性必须是“注入”的，而不是“本地构造”的。这一原则在你用 AI 生成帧同步逻辑时至关重要，你需要在 Prompt 中明确要求“所有随机数通过传入的 IDeterministicRandom 接口获取”，或者事后人工做接口隔离重构。

4.2 真实时间引用

典型生成代码：

var deltaTime = Time.deltaTime;
position += velocity * deltaTime;

问题分析： 帧同步中的逻辑帧是固定间隔的离散事件，不存在“这一帧比上一帧多用了 3ms”这种概念。逻辑更新应该使用固定的帧间隔常量，而不是从真实时间中读取的动态值。Time.deltaTime 在不同客户端、不同帧率下会产生不同的浮点值，进而导致位置计算产生微小但累积的差异。

修正策略： 逻辑帧间隔必须是一个在系统启动时确定的常量，所有时间相关的计算都基于这个常量。

// 修正版：固定帧间隔
private const float FIXED_FRAME_DELTA = 1f / 15f; // 15 帧每秒
position += velocity * FIXED_FRAME_DELTA;

深层问题： 即使你修正了帧间隔常量，浮点乘法在不同平台（x86 vs ARM、32 位 vs 64 位、不同编译优化级别）下仍可能产生极微小的精度差异。对于非竞技类的休闲对战，这种差异通常可以接受；但如果你做的是格斗游戏或帧级判定的动作游戏，就需要引入定点数计算来代替浮点数。这是另一个 AI 目前几乎无法自主完成的话题，后面会详细展开。

4.3 非确定性容器遍历

典型生成代码：

var players = new Dictionary<int, PlayerState>();
foreach (var kvp in players)
{
    // 处理玩家逻辑
}

问题分析： Dictionary 的遍历顺序在 C# 中是不保证的，它取决于内部哈希桶的分布，而哈希桶分布又受到插入顺序、键的哈希码、运行时内存状态等因素影响。在不同客户端上，如果玩家加入的顺序存在微妙差异，或者某些运行时状态影响了哈希码计算，Dictionary 的遍历顺序就可能不同。如果循环体内有任何依赖处理顺序的逻辑（例如“先处理先受益”的规则），就会导致分歧。

修正策略： 对需要遍历的集合，要么使用保证顺序的数据结构（如 SortedDictionary、List 排序后遍历），要么显式地按某个确定性键排序。

// 修正版：确定顺序遍历
var orderedPlayers = players.Values.OrderBy(p => p.PlayerId).ToList();
foreach (var player in orderedPlayers)
{
    // 处理玩家逻辑
}

这个问题的排查难度极大，因为它的表现在不同客户端之间可能是间歇性的。 有时候多客户端测试 50 次不出问题，第 51 次突然出现分歧。如果你看到“偶尔不同步、且不同步的表现与玩家加入顺序有关”的现象，优先检查集合遍历的确定性。

4.4 浮点精度分歧

典型生成代码：

float newX = position.x + speed * Mathf.Cos(angle);
float newY = position.y + speed * Mathf.Sin(angle);

问题分析： 浮点运算在不同平台、不同编译器优化级别下可能产生不同精度的中间结果。这个问题在 PC 和移动端联调时尤为突出。即使代码逻辑完全一致，Mathf.Cos 在 Intel CPU 和 ARM 芯片上的实现也可能有细微差异，这些差异经过累计后会逐帧放大。

修正策略： 对于精度要求极高的场景（帧级判定、格斗游戏），引入定点数（Fixed-point）运算替代浮点。

// 修正版：定点数运算（以 1000 为精度单位的简化示例）
public struct FixedPoint
{
    private long rawValue; // 精度单位：1/1000
    public static FixedPoint FromFloat(float f) => new FixedPoint { rawValue = (long)(f * 1000) };
    public float ToFloat() => rawValue / 1000f;
    // 实现加减乘除运算...
}

需要权衡的决策点： 定点数运算会显著增加代码复杂度，同时也降低了性能。对于网络延迟容忍度较高的游戏类型（如回合制策略、休闲对战），浮点精度差异不一定会导致可感知的不同步。你应该根据游戏类型来决定是否引入定点数，而不是一刀切地套用。

4.5 外部状态依赖与隐式上下文

典型生成代码：

var config = ConfigManager.Instance.GetWeaponConfig(weaponId);

问题分析： 这行代码假设当前运行时中存在一个可访问的 ConfigManager 单例。在帧同步的上下文中，配置数据应该作为逻辑帧输入的一部分显式传入，而不是从外部状态中隐式获取。原因是不同客户端的配置数据可能在热更新时机上存在细微差异，单例的初始化时机也可能不同。

修正策略： 所有外部数据依赖应通过帧上下文的参数或接口显式注入。

// 修正版：显式依赖注入
public class FrameContext
{
    public IWeaponConfigProvider WeaponConfig { get; init; }
    public IRandomProvider Random { get; init; }
    public int CurrentFrameId { get; init; }
    public float FixedDeltaTime { get; init; }
}

这个问题的深层教训是：帧同步逻辑应该是“纯函数”，输入决定输出，不依赖任何外部可变状态。 AI 生成的代码天然带有“状态无处不在”的假设，因为它见过的绝大多数代码都是在非确定性的真实时间环境中运行的。

五、哪些环节可以放心交给 Claude Code，哪些必须亲手写

基于以上分析，我建立了一套实践中的准则，用来判断在帧同步开发中哪些任务适合 AI 辅助，哪些不适合。

5.1 适合交给 AI 的环节

1. 帧同步骨架代码的生成

帧同步系统的整体架构，帧循环、输入队列管理、帧号推进、状态快照的序列化框架，这些“骨架”代码 Pattern 明确，AI 对这类结构性代码的生成质量很高。你需要做的是在生成后对接口层做显式的依赖注入改造，确保所有不确定性的入口被显式化。

实践数据： 我在三个项目中让 Claude Code 生成帧同步骨架，每次生成的代码在结构层面的可用率超过 80%。核心改动集中在：替换所有 new Random() 为注入的随机数接口、替换 Time.deltaTime 为固定帧间隔常量、为所有集合遍历强制添加确定性排序。

2. 输入序列化与反序列化

帧同步中输入指令的打包、解包、帧序列的存储和回放读取，是模式性非常强的工作。只要你在 Prompt 中明确了数据结构的定义，Claude Code 生成的序列化代码准确率很高。

3. 单元测试与帧回放测试的生成

这是我最意外也最惊喜的发现：让 AI 生成测试代码来测试 AI 生成的业务代码，效果出奇地好。特别是帧回放测试，你给定一段输入帧序列和预期状态，AI 可以很快生成一个在 NUnit 或 xUnit 中运行的确定性验证用例。关于这一点，第五部分会详细展开。

5.2 必须亲手写的环节

1. 确定性随机数生成器的具体实现

你当然可以让 AI 生成一个随机数算法的实现（如 Xorshift、Mersenne Twister），但这个生成器的“确定性”声明，如何管理状态、如何序列化/反序列化种子、如何在帧回滚时恢复状态，必须由你设计。AI 不理解“帧回滚时随机数状态应该回到第 N 帧时的状态”这个语境。

2. 定点数数学库

如果你决定引入定点数来消除浮点分歧，请手写定点数的核心运算实现，或者使用经过验证的第三方定点数库。AI 生成的定点数代码可能在基础运算上正确，但在边界情况（溢出处理、舍入策略、除法精度保留）上容易出现隐蔽缺陷。

3. 与具体玩法高度耦合的逻辑路径

例如格斗游戏的连招判定、MOBA 的技能弹道碰撞。这些逻辑的“正确性”标准不是语法正确，而是“感觉对”。AI 无法感受“这个技能的前摇应该更长一点才平衡”或“这个碰撞盒在视觉上会让玩家觉得不公平”。游戏感（Game Feel）是当前 AI 完全无法替代人类判断的领域。

4. 断线重连与帧追赶策略

帧同步的断线重连本质上是一个“追赶”问题：断线客户端需要尽快从当前帧追上服务端（或主机）所在的帧。追赶策略，是逐帧执行还是跳过渲染、是牺牲流畅度还是牺牲同步精度，取决于游戏类型、网络环境和用户体验目标。这是一个高度工程权衡的决策，不是一个代码生成问题。

六、一种经过验证的“AI + 人工介入”帧同步工作流

避免理论化的最佳方式，是直接给出一个可操作的工作流。下面是我在目前项目中使用的一套流程，其中的具体 Prompt 模式经过多轮迭代。

6.1 第一步：用 Claude Code 生成骨架，但带上“确定性约束”

不要只是说“写一个帧同步系统”。你需要把帧同步的确定性要求明确写进 Prompt。

我目前使用的基础 Prompt 模板：

实现一个 C# 帧同步核心系统，满足以下约束：

1. 所有随机数通过 IDeterministicRandom 接口获取，该接口的实例在帧上下文中注入。
2. 逻辑帧间隔使用常量 FIXED_FRAME_DELTA，禁止引用任何真实时间 API。
3. 所有集合遍历必须显式排序（以确定性键排序）。
4. 所有外部数据（配置、规则表）通过 IFrameContext 接口注入。
5. 不使用任何静态变量或单例模式持有可变状态。
6. 生成代码需要包含帧状态快照的序列化方法，支持回放。

这个 Prompt 的价值不在于让 AI 完美执行每一条约束，而在于它限制了 AI 的“默认行为空间”。 你告诉它“不准用 Random()”，它就会在生成时被约束在更小的选择范围内，从而降低后期重构成本。

6.2 第二步：人工做接口隔离审查，建立“确定性防火墙”

AI 生成的代码交到你手上之后，第一件要做的事不是测试，而是审查。审查的重点不是代码风格或业务逻辑，而是 “是否存在任何非确定性依赖”。

我建立了一个审查清单，每次都逐项检查：

• [ ] 是否直接或间接使用了 System.Random() 无参构造？
• [ ] 是否直接或间接使用了 UnityEngine.Random？
• [ ] 是否引用了 Time.deltaTime、Time.time、DateTime.Now？
• [ ] 是否使用了 Dictionary 遍历且遍历顺序会影响逻辑结果？
• [ ] 是否使用了 foreach 遍历非排序集合？
• [ ] 是否访问了任何静态变量或单例？
• [ ] 是否依赖了外部文件系统或网络状态？
• [ ] 所有事件处理顺序是否显式定义？

这条清单的价值在于：它把“检查帧同步确定性”这个模糊的工作，变成了一个可以逐项打勾的操作。 你不需要依赖直觉或经验来判断代码是否确定，而是有一条明确的外在标准。这项工作 Claude Code 帮不了你，它无法区分“确定性 Random 用法”和“非确定性 Random 用法”，因为对它来说两者都是合法的代码。

6.3 第三步：让 Claude Code 写测试来验证确定性，用 AI 测试 AI

这是整个流程中最有意思的一环。

帧同步的确定性有一个天然的可测试性特征：如果你保存了某一局对战的所有输入帧序列，那么在任何时间、任何设备上“回放”这些输入，都应该得到完全相同的结果。

基于这个特征，我设计了一个测试生成模式：

给 Claude Code 的测试生成 Prompt：

基于已有的帧同步系统，生成一个 NUnit 测试类 DeterministicReplayTests。

要求：

1. 预设一段包含 1000 帧的 InputFrame 序列，模拟 2 个玩家的操作。
2. 执行两次完整的帧回放，分别记录两个玩家在第 100/500/1000 帧的状态快照。
3. 断言两次回放中同一帧的玩家状态完全一致。
4. 记录每次回放的总耗时，输出到测试日志。
5. 如果断言失败，输出不一致帧的具体状态差异。

Claude Code 生成这类测试代码的质量相当高，因为测试代码的逻辑模式非常清晰：准备数据、执行操作、记录结果、断言一致性。这正是 AI 擅长的模式化工作。

这套“AI 写测试、测试 AI 写的代码”的闭环，让帧同步的确定性验证从“不知道怎么测”变成了“测一次就知道”。 你不需要在不同设备上手动联调才能发现问题。单元测试层面就能拦截 80% 以上的非确定性问题。

6.4 第四步：建立“帧日志比对”基础设施

单元测试能覆盖的是你预设的场景。真实对战中会出现各种你没预料到的边界情况。因此你需要一个运行时帧日志比对系统，用来在联调测试和线上灰度阶段持续监控同步状态。

这个系统的工作原理很简单：每个客户端在每一帧结束时，对当前帧的状态做一次哈希（如对整个状态对象做二进制序列化后计算 MD5 或 xxHash），然后把“帧号 + 哈希值”发送给一个对账服务。对账服务汇总所有客户端的哈希，如果发现某一帧的哈希值不一致，立即告警并保存该帧前后共 50 帧的完整输入序列。

关于哈希算法的选择： 不要使用 GetHashCode()，它在不同 .NET 运行时版本中可能产生不同的结果。使用确定的哈希算法如 xxHash64 或 SHA256，并确保序列化过程也是确定的（例如 JSON 序列化时对字典键排序）。

这个基础设施的搭建，Claude Code 可以提供很好的辅助。 序列化 + 哈希 + 网络上报这种组合是非常标准的工程模式，AI 生成代码的质量很高。你真正需要手工设计的部分是：对账服务的告警策略（何时判定为严重不同步、何时只是日志记录）、以及发现问题后的帧数据归档流程。

七、浮点与定点：一个必须单独讨论的决策

这一节单独讲讲浮点数 vs 定点数的选择。因为在帧同步开发中，这个决策会影响你后续大量的技术选型和开发成本，也直接决定了 AI 辅助的上限。

7.1 问题的本质

IEEE 754 浮点数规范保证了同一指令在同一架构、同一编译器、同一优化级别下产生相同的结果。但帧同步场景下，你可能面对的是：

• 不同 CPU 架构（Intel x86-64 vs Apple Silicon ARM vs 骁龙 ARM）
• 不同编译器（Mono vs IL2CPP vs .NET Native）
• 不同优化级别（Debug vs Release）
• 不同运行时（.NET Framework vs .NET Core vs Unity IL2CPP）

这些变量的排列组合会产生微小的浮点运算差异。例如，某些 ARM 芯片在处理 Mathf.Sin 时内部使用了不同的查表精度，而 IL2CPP 的 Release 构建可能启用了某些激进的重排序优化。

7.2 什么情况下必须用定点数

• 格斗游戏： 帧级判定直接影响连招是否成立、受击判定是否生效。
• 高精度物理模拟： 赛车游戏的真实感物理、射击游戏的弹道模拟。
• 跨平台竞技： PC 和移动端同服对战，且对战结果影响排位分。
• 电竞级公平性要求： 游戏有正式电竞赛事，任何“因为设备不同而导致判定差异”都是不可接受的。

7.3 什么情况下可以接受浮点

• 休闲派对游戏： 同步精度要求宽松，玩家不会因为 0.0001 的位置偏差感受到不公平。
• 回合制策略游戏： 逻辑帧间隔长，累积误差几乎为零。
• 服务器端是唯一权威源的混合同步架构： 虽然采用了帧同步思想，但有服务端作为状态纠正的后盾。
• 纯 PC 或纯移动端的封闭生态： 平台和架构统一，浮点一致性可控。

7.4 如果你选择定点数，Claude Code 能帮多少

实事求是地说，帮助有限。

定点数本质上是用整数模拟小数，这意味着你需要重新定义加减乘除的舍入行为、考虑溢出保护、处理除法时的精度损失、以及实现三角函数和平方根的数值近似。这是一门“定义数学行为的工程”，而不是“实现已知算法的工程”。AI 训练数据中定点数实现的代码占比极低，且质量参差不齐。

我的建议是：如果决定用定点数，使用成熟的第三方库（如 Unity 的 FixedMath 或自定义的确定性数学库），然后让 Claude Code 辅助做数据结构的适配和单元测试生成，而不是让它直接生成定点数核心实现。

八、回放、重连、观战：三个被 AI 严重低估的工程模块

大多数用 Claude Code 生成帧同步代码的开发者，在 Prompt 中只关注“帧循环 + 输入处理”，而忽视了帧同步架构中三个实际决定工程可行性的模块：回放、重连、观战。

8.1 回放（Replay）

帧同步的回放逻辑上是简单的：从第 0 帧开始，逐帧喂入记录好的输入序列，执行到目标帧即可。但工程上的坑在于：

• 回放时的帧推进策略： 你是逐帧慢速推进还是全速跳过渲染？前者适合精彩镜头回放，后者适合断线重连的快速追赶。
• 回放时的视角管理： 回放时玩家可能切换观战视角，这要求渲染层和逻辑层完全解耦。
• 回放文件的存储和校验： 输入序列文件可能很大（一局 30 分钟、每秒 15 帧、4 个玩家的输入），压缩和增量存储是必要的。

Claude Code 在生成回放功能时，容易把回放和正常的游戏循环混在一起，导致回放状态下某些逻辑分支走错。你需要明确要求它将“回放模式”作为一个独立的帧推进模式来设计，与“正常游戏模式”在入口处就分叉。

8.2 断线重连

断线重连的难度在于“追赶”。断线 N 秒的玩家重连后，可能落后了 N × 帧率 个逻辑帧。如果逐帧慢慢追，玩家要等很久；如果全速追赶，服务端瞬间下发 N 个帧的输入让客户端快速执行，又可能导致客户端卡顿。

AI 几乎不会主动考虑“追赶策略”的用户体验影响。 它生成的代码往往是“全速追赶”的实现，逻辑上是正确的，但体验可能是灾难性的。你需要手工设计追赶策略：例如前 100 帧全速追赶 + 跳过渲染，之后的帧以 2 倍速正常渲染追赶，同时在追赶到差距小于 10 帧时恢复 1 倍速。

8.3 观战

观战本质上是一个“只读的帧同步客户端”。它接收所有玩家的输入序列，但不产生任何输入，只在本地计算逻辑状态并渲染给观众。观战系统的挑战在于：

• 延迟容忍： 观战端可以比实际对局延迟 5-10 秒，这个延迟为网络抖动提供了 buffer。
• 视角切换： 观战端需要在不同玩家视角之间平滑切换，这是纯渲染层的工作，不能干扰逻辑层。
• 精彩时刻回溯： 允许观众在观战过程中跳转到某个历史时刻。

Claude Code 在生成观战功能时，容易忽略观战端的“延迟 buffer”设计，直接把观战端当作普通客户端来同步帧输入。你需要明确要求它为观战端设计独立的帧缓冲策略。

九、结论：AI 是你的帧同步“焊工”，但决定“这是什么建筑”的人是你

回到一开始的那个判断：AI 生成的帧同步代码问题不在“写不出来”，而在“坏得不像 bug”。

这个发现改变了我使用 Claude Code 的方式。我不再期望它一次性生成可商用的帧同步系统，而是把它当作一个高效率的 “代码骨架生成器” 和 “测试用例工厂” 。它的价值在于帮你快速跨过“从零到一”的阶段，你不需要从空文件开始手写帧循环、序列化协议、基础测试结构。但它不负责“从一到一百”，确定性保障、边界条件处理、用户体验权衡，这些是你在帧同步这个领域作为开发者的核心价值。

具体的行动建议，我整理为三种场景下的不同策略：

如果你在做原型验证（Prototype）：

• 让 Claude Code 生成整个帧同步骨架，尽快让多人对战跑起来。
• 接受浮点方案，不引入定点数，优先验证玩法可行性。
• 确定性只需满足“大多数情况下同步”即可，不做严格的帧对账。
• 这一步的目标是快速，不是完美。

如果你在做垂直品类项目（MOBA/射击/动作）：

• 使用本文第六部分的“AI + 人工介入”工作流。
• 投入时间建立确定性审查清单和帧回放测试。
• 根据跨平台需求决定是否引入定点数。
• 建立帧日志比对基础设施，在联调阶段持续监控。
• 这一步的目标是用 AI 提效，但人工守住质量底线。

如果你在做竞技级产品（格斗/电竞/大型赛事）：

• 帧同步核心逻辑以手写为主，AI 辅助只限于测试生成和序列化工具。
• 必须引入定点数或使用经过充分验证的确定性数学库。
• 建立完整的帧回放与对账系统，所有线上对局帧数据归档可追溯。
• 这一步的目标是零容忍非确定性，AI 在这里退居为辅助工具。

最后一个观点：帧同步开发中的真正挑战从来不是“怎么写代码”，而是“怎么确定这段代码在所有情况下都是确定的”。 这个问题 AI 目前无法替你回答，因为它缺乏对“语境”的理解，它不知道你的游戏是什么类型、你的目标平台是什么、你的玩家对公平性的期望有多高。

这些判断需要你这个人的经验、权衡和责任感。Claude Code 可以帮你写出帧循环的 for 语句，但它不能帮你决定当对账系统报警时，是回滚这一帧还是接受这次不同步。

而那个决定，恰好定义了你作为帧同步开发者的专业价值。