一类缺陷，Epic 的工程师追了整整十年，没有清干净。换成 AI 工具上场，几个月就被扫掉了。
这不是宣传话术。Epic 开发副总裁 Marcus Wassmer 在回应媒体求证时亲口确认，像 Claude 和 Codex 这样的 AI 编程工具，已经把虚幻引擎里一类被称为非确定性烹饪缺陷的顽疾清掉了。这类缺陷在 Epic 内部挂了十年号，人工排查一直没有根治。
一家做了三十多年引擎的公司，把自家最核心的代码库交给了 AI。这件事值得拆开来看，既要看它到底做成了什么，也要看它没说的那部分。
从一条帖子到官方确认
事情的起点在 10 月中旬。10 月 13 日，BBC 报道了 Epic 首席执行官 Tim Sweeney 在社交平台 X 上宣布的一次大转向，他用的原词是 huge pivot。他要求开发者全面换装，原话是 retool for maximum AI acceleration，意思是为最大化的 AI 加速重做工具链。
随后有网友在 X 上追问，Epic 是不是真的在用 AI 写虚幻引擎的代码。Sweeney 没有绕弯子，直接回了那句被大量引用的话，是的，我们现在正在用 AI 工具为虚幻引擎开发代码。PC Gamer 随即刊出报道，标题里带着一点难以置信的味道，说 Epic 确认在 vibe-coding 东西。
10 月 28 日，GameDeveloper 刊出了更扎实的官方口径。Wassmer 在回应求证时说，其实早在芝加哥的 Unreal Fest 舞台上和后来的采访里，他们就讲过这件事，Epic 确实在用 AI 为虚幻引擎开发代码和功能。至此，传闻变成了确认，而且来自负责开发业务的最高层。
AI 在 Epic 到底写什么代码
Wassmer 给出的范围相当具体。Epic 眼下几乎所有开发都挂在三条开发流上，分别是 Fortnite 本体、UEFN 编辑器和下一代 UE6。UEFN 是面向 Fortnite 创作者生态的虚幻编辑器，Epic 这两年把大量资源压在上面。他还透露，不排除再出一个 UE 5.9，如果做，那会是一次针对特定系统的小幅更新，其中也会包含借助 AI 开发的改动。
更激进的案例是 Epic 自己的游戏启动器。Epic 此前宣称，这台启动器是通过 vibe coding 重建的，重建之后运行速度明显提升。Wassmer 确认，这套做法不限于启动器和游戏商城，正在向更多产品扩散。
这里需要解释一个背景。vibe coding 这个词今年被频繁引用，指的是开发者用自然语言描述意图，让 AI 直接产出可运行的代码，人退到描述需求和验收结果的位置。很多公司把它当实验，Epic 把它用在了面向亿万玩家的启动器上，还公开承认。引擎公司对自己的工具链通常是保守的，因为工具链出问题会连带所有下游团队。Epic 敢这么干，要么是内部验证已经足够充分，要么是竞争压力已经大到顾不上保守，更可能两者都有。
有一句话值得单独拎出来。Wassmer 说，工程师已经不再亲手写大部分代码，但 Epic 在控制 AI 的使用范围。前半句让很多人紧张，后半句才是整件事的关键，后面细说。
为什么先倒下的是非确定性烹饪缺陷
烹饪是引擎圈的行话，指把美术和关卡的源资产转换成各平台能直接运行的格式的过程。一次大型游戏的烹饪要处理几十万份资产，走几十条流水线。非确定性烹饪缺陷的意思是，同一份输入，这次烹饪和下次烹饪的结果可能不一样。这类问题通常牵扯多线程时序、缓存状态和文件系统差异，复现靠运气，定位靠体力。
虚幻引擎的代码库规模庞大，年头久远，很多模块的年龄比参与修它的工程师的工龄还长。人工排查这类缺陷，等于在几百万行代码里捞一根不定期出现的针。Epic 追了十年，始终没有追干净，这不是工程师不行，而是这类问题天然克制人类的排查方式。
AI 工具恰好擅长这类活。它能在超大代码库里做穷举式的模式匹配，把散落在各处的可疑写法一次性列出来，再根据症状反推可能的时序窗口。人做这件事靠经验和灵感，AI 做这件事靠覆盖率，而覆盖率恰恰是非确定性缺陷最怕的东西。
这里可以补充一个更具体的画面。烹饪流水线的典型场景是，同一批纹理和模型资产，在不同的机器上、不同的线程调度下，被打包成顺序和内容略有差异的文件。绝大多数时候这种差异无害，但某些资产对加载顺序敏感，差异累积到一定程度就会在玩家端表现为偶发的崩溃或者贴图错乱。这类缺陷提交给工程师的报告里只有一句玩家在某个场景闪退，没有稳定复现路径，没有确定的触发条件。AI 工具介入后做的事情，本质上是把烹饪管线的日志、资产哈希和代码变更历史放在一起做关联分析，用人根本顾不过来的密度去比对每一次差异。
AI 在 Epic 还有一个不太起眼但很实用的用途，自动监控 Fortnite 在 PC 上的稳定性，主动找出导致问题的驱动和硬件组合，并提前告警。这类排查过去完全靠人工比对海量上报数据，费时费力。Wassmer 的原话是，这些工具帮助 Epic 在精简和现代化引擎方面做到了以前做不到的事，因为代码的体量、复杂度和年龄摆在那里。
人工排查和 AI 辅助的直观对比
这张表里的每一行都来自 Epic 自己披露的信息，没有一行是外界推测。这也是这次事件和以往厂商喊口号最大的区别，Epic 把用途、范围和结果都讲明白了，包括哪个工具写了哪部分代码。
争议的另一面
故事不只有光鲜的一面。BBC 的报道把时间线拉长了一些。大约六个月前，Epic 刚刚确认裁员超过一千人，当时 Sweeney 把原因归于 Fortnite 热度下滑，而不是 AI。
彭博社的报道则披露，Epic 与迪士尼合作的一个涉及星球大战和漫威角色的项目出现延期，开发者被要求用 AI 工具赶工。报道引述的说法是，主管告诉团队不要再手写代码，项目的美术也要全部走 AI 工作流生成。
X 上的反应相当激烈。一条指责 Sweeney 读不懂房间气氛的评论拿到了一万四千个赞。Sweeney 的回应很硬，房间里的很多人想回到 2016 年，但现在已经不是 2016 年了。他同时强调，这么做的目的不是用更少的人做同样的事，而是让开发者做出更多更好的东西，他把这称为对创作者的赋能。谈到这场大转向的动机，他的说法是，一个不算宏大的目标，在 AI 革命里活下来。
BBC 的采访里还有一位二十三岁全职游戏设计师 Lisha Howen 的声音。她说自己不完全反对 AI，身边有做游戏开发的朋友已经在用 AI 辅助写代码，但美术圈的朋友基本不用，因为游戏行业的美术对这件事格外抵触，大家看到的是岗位在消失。她还有一句很直观的判断，玩家其实能看出来一个东西是不是 AI 生成的。这几句话没什么立场包装，反而比厂商的表态更接近一线情绪。
Wassmer 对争议的态度更直接，相比对 AI 的怀疑，他们更担心动作太慢的风险。他认为用不了多久，用 AI 做开发会成为几乎所有软件的常态，因为用对了 AI 做出来的软件就是会更好，响应也更快。
普通团队能抄的三条作业
Epic 的做法里，最值得抄的不是买哪个工具，而是它给 AI 划的三条边界。
第一条是限定范围。AI 写代码被约束在明确的开发流和系统里，不是全库随便改。第二条是保留人工评审。工程师不写大部分代码，但工程师控制范围，评审的职责反而更重了，因为要在更短时间里看懂更多改动。第三条是可观测兜底，用自动化监控盯住稳定性，AI 写的代码出了问题能被快速发现和回滚。
落到工程实践上，可以把这三条边界固化成流水线里的硬门。下面是一个可以直接改造的持续集成守门配置：
# ai-gate.yml：AI 参与改动时的流水线硬门
name: ai-change-gate
on:
pull_request:
jobs:
gate:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
with:
fetch-depth: 0
- name: 改动规模守门
run: python tools/diff_guard.py --base origin/main --max-files 20 --max-lines 800
- name: 确定性构建与测试
run: python -m pytest tests -x -q
- name: 人工评审守门
run: python tools/review_guard.py --require-approvals 1
规模守门脚本的逻辑很简单，改动超过阈值直接打回，逼着提交者把大改动拆小：
import subprocess
import sys
def main():
base = sys.argv[sys.argv.index("--base") + 1]
max_files = int(sys.argv[sys.argv.index("--max-files") + 1])
max_lines = int(sys.argv[sys.argv.index("--max-lines") + 1])
out = subprocess.run(
["git", "diff", "--numstat", base],
capture_output=True, text=True, check=True,
).stdout
files, lines = 0, 0
for row in out.strip().splitlines():
add, delete, _name = row.split("\t", 2)
if add.isdigit():
files += 1
lines += int(add) + int(delete)
print("changed files:", files, "changed lines:", lines)
if files > max_files or lines > max_lines:
print("改动过大，请拆小后再提")
sys.exit(1)
main()
这套门背后的思路是，AI 写得越快，单次要消化的改动就必须越小。改动小，评审才看得过来，出了问题也好定位、好回滚。Epic 说的控制范围，落到地面就是这种可以执行、可以度量的闸门，而不是一句口号。
评审守门那条命令对应的脚本也不复杂，核心就是校验合并请求上至少有一条真实的人工批准记录，没有就阻断合并。阈值怎么定可以按团队情况调，但有两个原则最好别动。一个是阈值宁可偏紧不能偏松，AI 产出速度上去之后，人的评审带宽就是整个系统最贵也最稀缺的资源。另一个是闸门必须拦在合并之前，合并之后再发现问题，成本是合并前的很多倍。
风向标已经转了
过去几年，行业里关于 AI 编程的争论停留在能不能上生产。Epic 这次等于公开宣布，争论已经结束，至少在他们那里结束了。引擎厂商是对代码质量最敏感的一类公司，引擎崩了，下游成千上万个游戏团队跟着遭殃。当这样的公司把 AI 写进核心管线，并且愿意点名工具和用途，信号已经再清楚不过。
对普通开发者来说，真正值得紧张的不是 AI 会不会写代码，而是自己的评审流程、测试覆盖和监控体系，配不配得上 AI 的产出速度。工具可以照抄，边界要自己划。Epic 用十年没修干净的缺陷换来一个教训，又用几个月验证了一个方法，剩下的部分，轮到每个团队自己交卷。
本文由 AI图鉴自动抓取并翻译，版权归原作者所有；如需查看原文请点下方链接。