1. 事件回顾为什么“手搓3A”能引爆社区最近游戏开发圈和 AI 编程圈被同一条消息刷屏了有人用 AI 编程工具在一个会话里“手搓”出了一款看起来很像样的 3D 游戏画面有角色、场景、碰撞、收集品运行起来也有模有样。许多人把它称为“AI 手搓 3A 级游戏”播放量很快就上来了。于是评论区出现了两种极端声音一种是“程序员要失业了以后游戏我一个人就能做”另一种是“这也能叫 3A你在侮辱 3A”。这两种声音其实都没说到点上。先说一个基本判断这类演示的爆火有道理但大家兴奋的对象搞错了。它真正证明的不是“AI 已经能做 3A 游戏”而是“AI 已经能把一个游戏原型的代码部分写得又快又好”。卡帕西Andrej Karpathy的回应之所以被很多人形容为“泼了一盆冷水”恰恰是因为他提醒了所有人游戏开发从来不只是写代码。这篇文章不会去争论“它算不算 3A”而是想借这个热点把 AI 编程工具在真实游戏开发里的能力边界拆开讲清楚AI 到底擅长什么、做不了什么、为什么 Demo 和产品之间隔着一整条生产管线。同时我会给出一个可以用 Claude Opus 系列模型复现的最小游戏 Demo 流程以及几套工程化使用 AI 编程工具的方法。不管你最后是否认可“手搓 3A”这个说法读完这篇文章你至少能回答一个问题AI 编程工具现在到底能帮我做到哪一步。2. 游戏开发的真实成本一张概念图到可玩版本要理解卡帕西的“冷水”得先还原一款游戏从想法到上线到底要经过哪些环节。很多人对游戏开发的印象停留在“写代码”上这是最大的误区。2.1 一款游戏由哪些部分组成拆开来看一款标准商业游戏至少包含六块组成部分具体内容传统上由谁完成玩法逻辑角色控制、碰撞、得分、关卡流程程序员美术资产模型、贴图、骨骼动画、特效、UI美术、TA音频背景音乐、音效、语音音频设计师叙事与关卡设计剧情、任务、地图节奏、难度曲线策划、关卡设计师工程架构资源管理、状态同步、热更新、打包技术负责人性能与兼容帧率优化、内存、平台适配引擎程序员代码只是六块里的一块。而且即便是代码也不是只有“让角色往前跑”这一种难度。2.2 AI 编程解决的是哪一部分目前主流的 AI 编程工具比如 Claude Code、Cursor、GitHub Copilot核心能力集中在“玩法逻辑”的编码环节。你可以给它一个需求描述让它生成一个可以运行的 HTML5 游戏页面也可以让它给现有引擎工程增加一个背包系统。这些任务是 AI 的舒适区。但美术资产不行。AI 虽然能生成 2D 插画也能辅助生成部分 3D 素材但离“可进入商业游戏管线”的标准还有距离。更重要的是一个完整游戏的资产量是巨大的而且这些资产之间必须风格统一、命名规范、格式正确、能接入引擎——这不是“生成十张图”那么简单。音频、剧情、数值平衡、平台适配同样需要大量人工介入。2.3 Demo 和完整游戏的差距不是 10 倍是 100 倍一个 Demo 只需要做到“能跑起来、能展示核心玩法”。而一个完整游戏还要做到任何玩家在任何设备上不崩溃美术风格全程统一音频不穿帮、不刺耳操作手感经过大量调优存档、设置、多语言、无障碍等系统齐全从 App Store、Steam、TapTap 到海外渠道全部过审合规。所以卡帕西的冷水本质上是把“演示”和“生产力”分开。演示的价值在于激发想象但如果你把演示当成“游戏已经可以这样做了”就会在真实项目里栽大跟头。3. 基于 Claude Opus 系列模型实现一个最小可玩 Demo好现在我们来点实操。先不说 3A我们先把一个“能从浏览器里跑起来的小游戏 Demo”做出来。这个流程可以用 Claude Opus 系列模型配合 Claude Code 工具完成。3.1 环境准备我这里按最通用的方案来准备环境具体的安装步骤各平台大同小异。操作系统Windows / macOS / Linux 均可Node.js建议使用 LTS 版本用于启动本地静态服务器Claude CodeAnthropic 官方 CLI 工具需要安装并完成登录认证模型版本以你当前订阅可用的 Opus 系列模型为准本文重点演示通用用法不绑定具体版本号。如果你还没有安装 Claude Code终端里执行npm install -g anthropic-ai/claude-code安装完成后在项目目录里运行claude进入交互式对话界面就可以开始写需求了。3.2 写一份高质量的游戏提示词AI 生成游戏提示词的质量直接决定结果。很多人写“帮我做一个跑酷游戏”得到的往往是一个极其简陋的方块跳跃页面。这不是 AI 不行而是需求描述得太模糊。我们用一个更完整的提示词来演示请用纯 HTML CSS JavaScript 实现一个单文件网页跑酷游戏文件名为 index.html。 功能需求 1. 玩家角色持续向右自动奔跑场景持续滚动 2. 按空格键或点击屏幕时角色跳跃落地前可以再次跳跃实现二段跳 3. 地面上会随机生成障碍物角色碰到障碍物则游戏结束 4. 场景中随机生成金币角色碰到金币后得分加 1 5. 角色有简单的跑步和跳跃动画状态切换 6. 页面顶部实时显示得分、最高分使用 localStorage 保存 7. 游戏结束后显示“重新开始”按钮 8. 适配手机竖屏支持触屏点击跳跃 9. 代码保持单文件不做任何外部依赖 10. 视觉风格采用简洁的扁平化卡通风格色彩明快不要出现任何文字以外的装饰性内容。 生成后请说明文件保存在哪个路径、如何启动、如何验证核心功能。这段提示词里有几个关键点明确“单文件、无外部依赖”避免 AI 引入 CDN 或框架明确交互方式空格和触屏都要支持明确保存最高分这会产生 localStorage 相关的代码逻辑明确验证方式方便你检查它有没有完成。将提示词粘贴到 Claude Code 中它会自动生成index.html。然后启动一个本地静态服务器python3 -m http.server 8080浏览器打开http://localhost:8080/index.html就能看到游戏页面。3.3 验证 Demo 的四个核心点运行起来之后不要只看画面好不好看先验证逻辑角色是否能持续向右移动按空格是否触发跳跃落地后是否还能二段跳碰到障碍物是否弹出游戏结束界面金币碰到角色后得分是否加 1刷新页面后最高分是否还在。这四个点能让你快速判断AI 是否真的理解了你的需求还是只是在视觉上“看着像游戏”。3.4 通过追问迭代功能Demo 跑通之后你可以在同一个会话里继续追加需求请增加以下功能 1. 随得分提升逐步增加障碍物生成频率让游戏越玩越难 2. 新增“无敌冲刺”道具角色吃到后 3 秒内可以撞碎障碍物 3. 人物在界面上方显示血条碰到障碍物时扣血血量为 0 时游戏结束 4. 为跳跃和得分分别添加简单的 WebAudio 音效但要提供静音开关。要求它“保留原有功能只做增量修改”然后把新的index.html完整输出。这时候你会发现AI 在同一个会话里维护上下文的能力很强——它知道角色已经能跑了知道金币系统已经存在了所以会以增量方式修改代码。这就是“AI 手搓游戏”最吸引人的地方从零到可玩 Demo 的时间被压缩到了几分钟。4. 从 Demo 到可交付游戏冷水集中在四个环节Demo 跑通之后我们冷静一下看看从“能玩”到“能卖”之间哪些环节是 AI 目前帮不上忙的。4.1 资产管线最大瓶颈卡帕西的观点里最值得重视的一点是做游戏的真正瓶颈不是代码而是资产。一个 3D 动作游戏角色模型、动作、场景、特效、UI、音频每一项都是需要专业工具和大量人力生产的。AI 能生成贴图、能生成蓝图、能生成参考图但商业游戏要求的是统一的艺术风格、合理的拓扑结构、规范的资源命名、以及能在目标引擎里正确渲染的格式。这些不是“生成一张图丢进项目”能解决的。更不用说动画、物理骨骼、表情、布料模拟这些环节目前 AI 工具链距离一键生产还非常远。4.2 工程架构与代码规模Demo 通常只有几百行代码。真实游戏呢中等体量的独立游戏代码量至少是几万行大型项目可以达到百万行级别。代码量增长后问题不再是“能不能跑”而是模块之间如何解耦状态管理如何统一资源如何异步加载内存如何避免泄漏多人联机时如何同步状态。AI 擅长在一个相对独立的任务里写出高质量代码但面对跨模块、跨文件、涉及历史坑位的项目改造它的表现会明显下降。这不是模型能力不够而是上下文窗口有限它看不到整个项目的全貌。4.3 测试与回归Demo 阶段人工玩两分钟就能验证完。产品阶段一个功能改动可能影响十几个模块。AI 改完 A 模块可能导致 B 模块的某个函数失效——这种情况在多次迭代里非常常见。所以AI 生成代码跑得越快回归测试就越重要。没有自动化测试保护的项目AI 迭代越多隐藏 bug 越多。4.4 合规与平台适配上架游戏平台要过版号、隐私政策、内容审核、平台规范。3A 游戏还要面对主机平台认证TRC、Lotcheck、多语言本地化、无障碍辅助功能。这些环节完全不在 AI 编程范围内需要专业团队和流程去完成。所以“手搓 3A”最合理的理解是它指的是用 AI 辅助把 Demo 阶段的核心玩法快速开发出来。真正的 3A 生产仍然是一个需要长周期、大团队、高投入的工业化过程。5. 用工程化方式使用 AI 编程不只是多聊几句如果你看完上面的分析仍然决定把 AI 编程工具接入真实项目那接下来的内容就很重要。很多人用 AI 编程是直接在主干分支上反复对话让 AI 覆盖文件结果越改越乱。下面这套流程是我认为比较稳妥的工程化用法。5.1 用 git worktree 隔离 AI 工作区不要让 AI 直接改你的主干代码。每次给 AI 分配任务前先拉一个独立的 worktree这样 AI 改坏了也不会影响主分支。# 在项目目录下创建一个 ai-feature 工作区 git worktree add ../my-game-ai-feature -b feature/ai-backpack # 进入该目录再启动 Claude Code cd ../my-game-ai-feature claudeAI 在这个目录里改代码改完之后你在主分支上 code review确认没有破坏性变更后再合并。这个习惯能极大的减少 AI 改坏代码造成的损失。5.2 把大型需求拆成小型任务AI 在单文件、单模块的场景下表现最好所以要让 AI 写代码应该先做任务拆分。举个例子不要对 AI 说“帮我做一个完整的背包系统”。这个需求太大了AI 生成的代码会非常表面化。更好的方式是拆成几个任务任务一在 character.ts 中新增 Inventory 类包含 addItem、removeItem、hasItem 三个方法并编写单元测试。 任务二为 Inventory 类新增 UI 面板在按下 B 键时打开和关闭。 任务三新增物品掉落逻辑怪物被击败后有 20% 概率掉落随机物品并自动加入背包。每个任务对应的文件、函数、预期输出都描述清楚。AI 生成的代码质量和可维护性会显著提升。5.3 强制自动化测试AI 生成代码之后一定要跑一遍测试。如果项目之前没有测试基础设施建议先让 AI 补一份。给 AI 的指令示例请为 src/player.ts 中的 Player 类生成单元测试使用 vitest 框架。 覆盖以下场景 1. 初始 HP 为 100 2. takeDamage(20) 后 HP 变为 80 3. HP 降为 0 时 isAlive 返回 false 4. heal(50) 后 HP 不超过最大生命值。测试写好了AI 每次改完代码你都可以立刻验证避免“越改越崩”。5.4 建立版本回滚策略AI 生成或修改代码后最稳妥的做法是每次让 AI 完成一个任务就单独提交一次。不要连续改十几个功能之后再提交否则出了问题根本没法定位。git add . git commit -m feat: add inventory system如果发现某个提交引入问题直接回滚git revert HEAD --no-edit这套习惯虽然基础但在 AI 编程时代变得更加重要因为 AI 生成的代码你不一定每一行都看懂但通过小步提交你可以快速定位到出问题的范围。5.5 管理上下文给 AI 一个“项目说明书”AI 对话上下文越大越容易遗忘前面的需求。对长期项目来说建议在项目根目录放置一个AI_CONTEXT.md文件里面写清楚项目结构、技术栈、代码规范、常用命令。每次新开会话时让 AI 先读这个文件再开始写代码。请先阅读项目根目录下的 AI_CONTEXT.md再根据文档中的技术栈和编码规范完成任务。这比每次对话开头重新解释一遍项目背景高效得多。6. 判断 AI 编程工具能力的五个维度不是所有 AI 编程工具都一样也不是所有任务都适合交给 AI。判断一个 AI 编程工具的真实能力可以从五个维度来看。维度判断标准当前 AI 水平单文件代码生成能否按需求生成完整可运行的单个文件很强复杂需求仍可能出错多文件一致性修改 A 文件时是否会同步更新 B 文件的相关引用中等需人工 review长上下文维护连续对话 2 小时后是否还能记住早期需求中等建议拆任务架构理解是否理解项目的分层、依赖关系、目录约定偏弱需 AI_CONTEXT 辅助资产与体验是否擅长美术、音频、数值手感很弱基本需要人工我们这次做的跑酷 Demo属于“单文件代码生成”维度所以 AI 表现特别好。一旦进入到第 5.2 节说的“多文件一致性”场景就需要人工介入更多了。理解了这五个维度你就能对类似的热点视频做出自己的判断视频里的演示到底证明了 AI 在哪个维度上的能力这个维度对你当前的项目有多重要7. 常见误区与排查思路7.1 AI 写出的游戏页面打不开现象生成index.html后浏览器打开是空白页。原因最常见的是文件路径不对或者启动服务器的端口被占用。排查方式先用命令行确认端口是否被占用再看浏览器控制台有没有报 JavaScript 错误。解决方法# 查看端口占用 lsof -i :8080 # 换一个端口重新启动 python3 -m http.server 80907.2 角色跳跃手感很怪现象跳跃高度过高、落地后无法二段跳、按键没有响应。原因AI 对“手感”没有概念默认参数往往不符合你的预期。解决方法不要让它“优化手感”而是给出明确参数。例如将跳跃改为二段跳第一次跳跃速度为 -12第二次为 -8重力加速度为 0.6角色速度保持 5。给出数值AI 的修改结果会更可控。7.3 迭代多次后代码越来越乱现象同一文件被 AI 修改十几次后出现大量重复逻辑或无法理解的变量。原因AI 在同一个对话里不断增删功能容易产生冗余代码。解决方法新建一个会话把需求写清楚让 AI 重写该文件或者把通过的版本先提交,再让 AI 基于已提交版本继续修改。7.4 提示词没问题但 AI 输出不符合预期现象按照本文方式写提示词AI 仍然只生成一个简陋页面。原因模型版本不同、上下文被清空或者项目目录中存在多个同名文件导致 AI 混淆。排查方式先确认当前会话用的模型再确认项目目录是否干净最后检查生成文件的完整路径。7.5 问题排查速查表问题现象可能原因排查方式解决方案页面空白路径或端口问题检查浏览器控制台更换端口并确认文件路径跳跃异常默认参数不符合预期提供明确数值参数用数值描述代替“手感好”代码越改越乱单会话迭代过多检查代码重复逻辑新开会话基于版本提交重写AI 完全没按需求做提示词歧义拆分任务和验收标准按 5.2 节方式拆任务运行后报错依赖或语法问题查看终端和浏览器日志让 AI 打印报错信息再修8. 团队落地的工程建议如果你是一个小团队或者独立开发者想真正把 AI 编程接入游戏开发流程我建议从这几条开始。8.1 先建立工具链AI 编程工具不是装个插件就行。建议先做三件事统一团队使用的 AI 编程工具和模型版本建立项目级的AI_CONTEXT.md让 AI 理解项目规范把 AI 生成的代码纳入 code review 和 CI 流程。没有工具链的团队AI 更多只是“花样写代码”有了工具链AI 才能真正成为生产力。8.2 明确 AI 边界不是所有代码都适合让 AI 写。下面这几类任务就不建议交给 AI涉及线上数据迁移的代码涉及支付、账号、隐私的模块你自己也不完全理解的遗留代码刚上线正在试运行的核心链路。AI 可以作为初稿生成器但关键模块必须有人工 review 和完整测试。8.3 质量门禁团队里引入 AI 编程之后最怕的不是 AI 写错代码而是团队成员把 AI 生成的代码直接合入主干。建议强制三条规则AI 产生的每个 PR 都要有自动化测试超过 200 行改动的 PR 必须人工逐行 review涉及引擎升级、依赖升级的改动不能用 AI 自动完成。8.4 人机分工一个比较合理的分工方式是AI 负责原型验证、工具脚本、单元测试、重构局部模块、生成配置模板开发负责架构设计、资产管线的技术方案、性能优化方案、生产环境问题定位、评估 AI 生成结果是否符合产品意图。长期看“会用 AI 的开发者”比“不用 AI 的开发者”效率更高但前提是你知道 AI 的边界在哪里。9. 总结与后续学习方向回到开头那个问题Opus 5 手搓 3A 游戏爆火卡帕西为什么泼冷水因为它提醒我们游戏开发是一个完整的工业系统写代码只是入口。AI 编程工具的进步确实让“从 0 到 1 做出 Demo”这件事变得极其容易这在几年前还难以想象。但同时Demo 和产品之间隔着资产管线、工程架构、测试体系、平台合规这些硬骨头。对开发者来说最好的策略不是跟风喊“AI 取代游戏开发”也不是无视 AI 编程工具而是把它当作一个“原型加速器”用 AI 快速验证玩法、搭建系统骨架、生成测试代码把省下来的时间投入到 AI 不擅长的资产、体验和架构设计上去。如果你对这篇文章的内容感兴趣下一步可以试着做三件事用 Claude Opus 系列模型做一个更复杂的玩法 Demo比如俯视角射击或解谜游戏测试它在多系统设计上的能力边界把一个开源小游戏项目克隆到本地用 git worktree 隔离 AI 修改做一个完整的新功能提交体验工程化流程学习一点游戏设计基础了解数值、关卡和手感为什么无法靠提示词解决。AI 编程工具会继续进化但游戏开发的本质不会变玩家体验到的是一个完整世界的整体质量。代码只是这个世界的一部分。