我是一名经验丰富的Unity游戏程序员，但在这个项目中我几乎没有手动写代码。

大约在6月18日我开始构建一个类似PUBG的游戏模式，并于九月初上线——大约两个半月后。在此期间，我完成了500多次提交。

这可不是小型游戏创作马拉松的原型。该项目包括：

  • 第三人称移动与射击
  • 跳伞与着陆
  • 多武器、换弹、瞄准、近战攻击和手雷
  • 物品栏、装备、战利品和自动拾取
  • 治疗、护甲、击倒、复活与死亡
  • 队伍与队友标记
  • AI控制的玩家
  • 一个日益缩小的安全区
  • 小地图和全屏地图
  • 移动操作与战斗界面
  • 多人游戏状态同步
  • 真实服务器与假服务器后端
  • 运行时调试与性能工具
  • 针对远程玩家、战利品和大型环境的优化

几乎所有的实现都是由人工智能生成的。我负责决定要构建什么、定义架构、审查关键边界、测试结果并修正方向。

我并不完全理解代码的每一行

如果让我把自己归类到以下几类之一：

  1. 我理解每一个功能和系列。
  2. 我了解整体结构和职责。
  3. 我完全不知道代码具体做什么。

我完全属于第2类。

我知道玩家状态存储在哪里。我知道角色状态机的工作原理，武器和技能的组织方式，UI如何与游戏数据分离，消息如何在客户端和服务器之间流通，以及哪个系统负责各项责任。

但我记不清每个功能或每一句话。

我认为对于如此规模的项目来说，这并不是一个有价值的目标。即使程序员手动编写所有内容，他们通常也不会把整个实现都记在脑子里。重要的是要足够了解架构、合同、所有权和不变量，以便在必要时定位并调查问题。

我与人工智能的关系类似于领导开发团队。我定义了结构和要求，审查了重要决策，并核实了结果。区别在于，AI通常比人类开发者更能一致地遵循约定的计划。

生成第一个版本是最简单的部分

人们常常用AI编程快速生成原型来评判它。我觉得这并不能证明太多。

真正的考验开始于：

  • 需求变化
  • 旧系统必须重构
  • 修复会破坏另一个功能
  • 网络消息的到达顺序出乎意料
  • 资源异步加载
  • 假服务器的行为与真实服务器不同
  • 移动端输入会暴露编辑器中从未出现的问题
  • 游戏必须被打包、集成并发布

项目经历了所有这些阶段。

例如，我用多个负责身份、库存、装备和战斗的管理者取代了一个大型玩家数据结构。我把真服务器和假服务器分开在一个通用的后端接口后面。我把战斗界面重新整理成独立的模块。我还为远程玩家和战利品引入了代表性等级，让客户端可以选择无代表、代理、简化版本或完整对象。

那不是一次性的几代。这些都是对现有互联系统的变化，同时项目还在继续推进。

这就是为什么我认为这个项目是人工智能编码的有意义证据。它不仅生成了演示。它经历了数百次后续的改动。

我最可靠的工作流程是：

  1. 讨论AI的问题。
  2. 让它检查现有代码。
  3. 在原因、架构和风险上达成一致。
  4. 做一个小改动。
  5. 运行游戏，观察实际行为。
  6. 记录有用的运行时信息。
  7. 根据证据进行修正或重构。

当AI反复误解系统时，我停止无限期地试图改进提示。相反，我改变了架构，使责任更加明确。

如果两个系统都能修改同一个状态，我就引入单一所有者。如果调试依赖于读取大量日志，我就添加结构化的运行时记录。如果真实服务器阻碍了开发，我就搭建一个假服务器路径。如果对象创建导致帧尖峰，我会将逻辑存在与视觉表现分离，之后创建模型。

换句话说，我不仅仅是要求人工智能解决问题。我试图重塑项目，让人类和人工智能都更少误解它。

可观察性比阅读所有内容更重要

因为我没有手动写每一行，运行时的可见性变得极其重要。

对于复杂的同步问题，我记录了如下事实：

  • 事件名称
  • 时间和帧
  • 玩家标识符
  • 网络路径
  • 当前武器和弹药
  • 服务器数据是否已到达
  • 角色身体是否存在
  • 当前初始化阶段

这往往比阅读许多文件并猜测更有用。

我可以问：“为什么玩家在服务器上有正确的弹药，但HUD仍显示为零？”此时AI可以追踪记录的序列，而不是从静态代码中编造解释。

对于AI辅助开发，良好的诊断不是可选的。它们是架构的一部分。

结果稳定，但这并不意味着完美

游戏上线后，前三天内未收到任何错误报告。

这并不证明没有任何错误。玩家数量、游玩时长和报告行为都会影响。但它表明，由AI编写的复杂游戏模块可以达到商业可接受的稳定性，而非在发布后立即崩溃。

该项目也存在弱点。

有一位同事觉得射击手感很差。这批评可能是公正的。

AI帮助我非常快速地实现系统，但良好的游戏手感仍需要品味、反复试玩、强动画和音频、精细调节以及明确的参考。完成一个技术上复杂的游戏模式并不等同于让每个部分都感觉出色。

这也是一个重要教训：AI 大幅降低了实现成本，但并未消除对游戏设计的需求。

我认为人类需要负责的部分

在这套流程中，人类仍需决定：

  • 需要构建什么
  • 哪些责任应由谁负责
  • 哪些权衡是可接受的
  • 当前行为是否真正感觉正确
  • 何时补丁、何时重构
  • 在称 something 为已修复前需要什么证据
  • 当一个功能足够完整可以发布时

AI 可以比我打字快得多地生成代码。但速度也带来新的问题：它可能生成功能的速度快于我思考其设计的速度。

瓶颈从编码转移到了判断。

我的结论

这个项目让我确信，复杂的商业游戏模块几乎可以完全由 AI 实现，并且能够经受住变更需求、调试、集成和发布的考验。

但 “AI 写了代码” 不等于 “AI 自己做了整个游戏”。

我的角色向上提升。与其亲自实现每个功能，我专注于意图、架构、约束、验证和产品决策。

最有价值的技能不再是打字写代码，而是让问题足够清晰、架构足够稳固、反馈循环足够强大，使 AI 能够在不破坏项目的前提下继续贡献。

生成代码很容易。

保持 AI 编写的项目在 500 之后的提交中保持可理解、可变更和可发布，才是真正的挑战。