做UE5插件的人不少，但很少有人把“AI到底能干多少活”这件事量化出来。ue-cortex的作者在Fab上卖这款插件，他给出的答案有点扫兴：一个带计划、带检查的AI助手，能覆盖新项目工程脚手架的大约50%到65%。

打开网易新闻 查看精彩图片

ue-cortex本身不调用模型。用的人自己带助手，Claude Code、Cursor或Codex都行。插件给助手配了11份专家手册和83份参考文件，覆盖系统C++/GAS、多人、世界构建、蓝图、DevOps/构建、UI、音频、过场、性能、技术美术和AI，同时负责检查编辑器里实际发生了什么。

流程从一份游戏设计文档开始。运行以cortex_start起步，助手先起草GDD，插件负责验证：每个功能都必须有可测试的验收标准和指定的执行代理。作者举了个小例子，“用ue-cortex做一个消耗耐力的冲刺技能”，会被拆成“按Shift让玩家移动6米”“消耗25点耐力”“冷却1.5秒”这样的验收条目。GDD会写进项目的Docs/UECortex/GDD.json和GDD.md，动手之前就能读、能改。

计划批准之后，cortex_approve_plan会生成一张按依赖排序的任务图，GDD用到的每个代理对应一步。这套设计的关键在于顺序：先有可验收的目标，再有分工，最后才动编辑器。

作者把边界写得很直白：

  • 它覆盖新项目工程脚手架的大约一半到三分之二（50%到65%）。
  • 美术、关卡设计、调参和打磨，都是人的活。
  • 助手不能玩游戏，也不能从零造一个新关卡。
  • 生成的项目是能编译、能运行的起步框架，不是成品游戏。
  • 只在UE 5.8上测试过并可用；UE 5.6-5.7属于“以后可能支持”，不是承诺。
  • 编译验证仅限Windows，因为它依赖Live Coding。

这套方法值得看的地方，不是AI能写多少代码，而是它把“检查”变成了流程的一部分。验收标准写在文档里，任务图按依赖排好，编辑器里的结果由插件核对——助手不再只是聊天，而是被一套可读、可改的规则推着走。

至于工程脚手架之外的部分，作者没有给出任何自动化方案。美术、关卡、手感这些事，仍然留在人手里。