企业官网建设流程全解析

1. 三句话生成3D游戏，这件事到底靠不靠谱

第一次看到“0代码，0建模，3句话开发一个3D游戏”这个说法，我的反应和大多数人一样：又是标题党。毕竟在传统游戏开发流程里，哪怕做一个最简陋的3D demo，你至少得装引擎、配环境、写角色控制器、调摄像机跟随、处理碰撞检测，一套下来没个两三天根本跑不起来。但最近一段时间我深度使用了 Claude Code 配合 Opus 模型，实际跑了几轮之后，我收回之前的判断——这件事在特定条件下确实成立，而且效果比我预期的好得多。

先把结论说清楚：所谓“3句话开发3D游戏”，本质是用自然语言提示词驱动一个具备文件读写、命令执行、依赖安装能力的 AI 编程智能体，让它在本地自动完成项目脚手架搭建、代码编写、依赖安装和运行调试。你负责描述需求，它负责落地实现。整个链路里，Claude Code 是执行终端，Opus 是大脑，提示词是你和大脑之间的接口。三者缺一不可。

这篇文章适合三类人看：一是完全没碰过游戏开发但想快速验证创意的产品型选手；二是有编程基础但没做过3D游戏、想用 AI 提效的开发者；三是已经在用 Claude Code 但还没试过用它做图形类项目的朋友。我会把整个流程拆开讲透，包括提示词怎么写、环境怎么配、踩过哪些坑、哪些环节 AI 会翻车需要人工兜底。不吹不黑，全是实测记录。

需要提前说明的是，这套方法目前最适合做原型验证和小型 demo，比如第一人称漫游、简单的收集类玩法、物理沙盒这类场景。如果你要做商业级完整游戏，AI 能帮你省掉大量重复劳动，但架构设计和性能优化仍然需要人来把关。下面进入正题。

2. 整体思路拆解：为什么三句话能跑通一个3D游戏

2.1 传统3D游戏开发的门槛到底在哪

要理解 AI 为什么能压缩这个流程，得先搞清楚传统路径的时间都花在哪了。一个最小可运行的3D场景，通常包含以下工作：

• 引擎选型与安装：Unity、Unreal、Godot 各有各的安装包和配置流程，光下载安装就可能花掉半小时
• 项目初始化：创建项目、配置渲染管线、设置输入系统
• 场景搭建：创建地面、光源、摄像机，摆放基础几何体
• 角色控制：写移动逻辑、跳跃逻辑、摄像机跟随
• 物理系统：碰撞体、刚体、重力参数
• 调试运行：反复修改参数、处理报错

这里面真正体现“创意”的部分其实很少，大量时间消耗在样板代码和环境配置上。而 AI 编程智能体最擅长的恰恰就是这类有明确模式、有大量公开示例的样板工作。

2.2 Claude Code + Opus 这个组合的特殊之处

市面上 AI 编程工具不少，但能真正做到“三句话出游戏”的，需要满足几个硬条件。我把关键能力对比整理成表格，方便你判断自己手上的工具能不能干这事：

Claude Code 的核心价值在于它是一个agent（智能体），不是单纯的聊天窗口。你给它一句话，它会自己决定：先创建哪个文件、装什么依赖、跑什么命令验证、报错了怎么改。这个“自主循环”能力才是三句话出游戏的技术底座。

Opus 模型在这里的作用是提供足够强的代码生成质量和长程规划能力。实测下来，同样一句“做一个第一人称漫游的3D场景”，Opus 生成的代码结构明显更合理，会主动拆分模块、加注释、处理边界情况，而小模型往往写成一坨能跑但没法维护的代码。

2.3 三句话的分工逻辑

所谓“3句话”，不是随便说三句就行，这三句话有明确的功能分工：

1. 第一句定方向：说清楚做什么类型的3D游戏、用什么技术栈、核心玩法是什么
2. 第二句补细节：描述具体的交互方式、视觉风格、关键参数
3. 第三句提要求：说明运行环境、性能预期、代码组织方式

这个结构和提示词工程里经典的“角色-任务-约束”框架是一致的。第一句给角色和任务，第二句给具体需求，第三句给约束条件。三句话覆盖了 AI 完成任务所需的全部关键信息，剩下的细节它会基于训练数据里的常见实践自动补全。

提示：不要真的只发三句话就完事。三句话是核心指令，实际使用中你还需要在 AI 执行过程中根据它的输出做追加反馈。三句话是起点，不是终点。

3. 环境准备：从零把 Claude Code 跑起来

3.1 安装 Claude Code 的完整步骤

Claude Code 目前提供多种安装方式，我实测下来最稳的是通过 npm 全局安装。前提是你机器上已经有 Node.js 环境，建议版本 18 以上。

# 检查 node 版本 node -v # 全局安装 claude code npm install -g @anthropic-ai/claude-code # 验证安装 claude --version

如果你在 Ubuntu 环境下，npm 全局安装可能遇到权限问题，两个解决方案：一是用 nvm 管理 node 版本，避免 sudo；二是配置 npm 的全局目录到用户目录下。我推荐前者，干净且不容易出幺蛾子。

# 用 nvm 安装 node（推荐） curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.0/install.sh | bash source ~/.bashrc nvm install 20 nvm use 20 npm install -g @anthropic-ai/claude-code

Windows 用户建议在 WSL2 里操作，原生 Windows 环境下路径处理和命令执行经常出问题，WSL2 的 Linux 环境兼容性好很多。

3.2 VSCode 配置与 Claude Code 联动

虽然 Claude Code 是命令行工具，但配合 VSCode 使用体验会好很多。核心思路是在 VSCode 的集成终端里运行 Claude Code，这样 AI 改完代码你能立刻在编辑器里看到 diff。

配置要点：

• 在 VSCode 里打开项目文件夹，用 `Ctrl+`` 调出集成终端
• 在终端里直接运行claude启动
• 建议安装 Claude Code 的 VSCode 扩展，能获得更好的 diff 展示和快捷键支持
• 把终端字体调大一点，AI 输出的内容比较多，小字体看着累

3.3 项目目录的初始化策略

这里有个很多人忽略的细节：在哪个目录启动 Claude Code，决定了它能操作哪些文件。我建议专门建一个空目录来做游戏项目，不要在家目录或者已有项目根目录直接启动。

mkdir my-3d-game cd my-3d-game claude

启动后 Claude Code 会扫描当前目录，如果目录是空的，它就知道要从零开始搭建。如果目录里已经有一堆无关文件，它的上下文会被干扰，生成的代码可能莫名其妙地引用不存在的文件。

注意：Claude Code 默认会请求文件读写和命令执行权限。第一次使用时它会逐个询问，你可以选择“允许本次”或“始终允许”。建议前期选择逐次确认，观察它的操作是否符合预期，建立信任后再放开权限。

4. 三句提示词的具体写法与原理

4.1 第一句：定方向的关键要素

第一句话要解决“做什么”的问题。我实测下来，有效的第一句必须包含三个要素：游戏类型 + 技术栈 + 核心玩法。

反面例子：“帮我做个3D游戏”——太模糊，AI 只能瞎猜，大概率给你一个旋转立方体。

正面例子：“用 Three.js 做一个第一人称视角的3D迷宫漫游游戏，玩家用 WASD 移动、鼠标转视角，目标是在迷宫里找到出口。”

这句话里：

• 技术栈：Three.js（决定了 AI 生成什么代码）
• 游戏类型：第一人称迷宫漫游
• 核心玩法：WASD 移动 + 鼠标视角 + 找出口

为什么技术栈要放在第一句？因为不同的技术栈对应的代码结构完全不同。Three.js 是 Web 端的，Babylon.js 也是 Web 端但 API 不同，Godot 是独立引擎。你不在第一句说清楚，AI 可能选一个你根本不熟悉的技术栈，后面想改都难。

4.2 第二句：补细节的四个维度

第二句话负责把第一句的框架填充成具体可执行的需求。我总结出四个需要覆盖的维度：

1. 视觉风格：低多边形、写实、卡通、像素风
2. 交互细节：移动速度、跳跃高度、鼠标灵敏度
3. 场景元素：地面材质、墙壁样式、光照类型
4. 反馈机制：碰撞音效、UI 提示、得分显示

示例第二句：“视觉上用低多边形风格，地面是深灰色网格，墙壁用随机颜色的方块，加一个方向光和环境光；移动速度适中，鼠标灵敏度可调；碰到墙壁有轻微震动反馈，找到出口弹出提示。”

这句话给 AI 提供了大量可执行的细节。注意我没有指定具体数值，因为 AI 会根据常见实践给出合理默认值，你后面觉得不合适再调就行。如果一上来就写死“移动速度 5.0”，反而可能因为单位不匹配导致手感奇怪。

4.3 第三句：提要求的约束条件

第三句话是很多人会漏掉的，但它直接影响生成代码的质量。约束条件主要包括：

• 运行方式：本地打开 HTML 文件就能跑，还是需要起本地服务器
• 依赖管理：用 CDN 引入还是 npm 安装
• 代码组织：单文件还是多文件拆分
• 兼容性：支持哪些浏览器、是否需要移动端适配

示例第三句：“用单个 HTML 文件实现，Three.js 通过 CDN 引入，不需要构建工具，双击就能在浏览器打开；代码加上清晰注释，方便我后续修改。”

为什么强调单文件和 CDN？因为对于原型验证来说，减少依赖链就是减少出错概率。npm 安装可能遇到网络问题、版本冲突，CDN 引入虽然不适合生产环境，但做 demo 足够快。

4.4 三句话背后的提示词工程原理

这三句话的结构不是拍脑袋定的，它对应了提示词工程里的几个核心原则：

原则一：具体优于抽象。“做一个好玩的游戏”是抽象需求，“WASD 移动找出口”是具体需求。AI 对具体需求的执行准确率远高于抽象需求。

原则二：约束缩小搜索空间。不加约束时，AI 会在所有可能的实现方案里随机选一个。加上“单文件、CDN、无构建工具”的约束后，搜索空间大幅缩小，生成结果的可预测性显著提升。

原则三：分层递进降低认知负荷。三句话从宏观到微观逐层细化，符合人类描述需求的自然顺序，也给了 AI 逐步聚焦的机会。如果三句话揉成一段，AI 可能抓不住重点。

实操心得：第一轮生成后，不要急着说“不对，重做”。先看 AI 生成了什么，然后针对具体问题追加指令。比如“移动速度太快了，调慢一半”“墙壁颜色太花，改成统一的深蓝色”。这种增量式反馈比推倒重来效率高得多。

5. 完整实操过程：从空目录到可玩 demo

5.1 启动 Claude Code 并输入第一句

打开终端，进入空目录，运行claude。等它初始化完成后，直接输入第一句话。我实际测试时用的是这个：

用 Three.js 做一个第一人称视角的3D迷宫漫游游戏，玩家用 WASD 移动、鼠标转视角，目标是在迷宫里找到出口。

Claude Code 收到后会开始规划。你会看到它先输出一段思考过程，然后开始创建文件。这个阶段它会做几件事：

1. 创建index.html作为入口
2. 在 HTML 里通过 CDN 引入 Three.js
3. 写 JavaScript 代码实现场景、相机、渲染器
4. 实现迷宫生成逻辑
5. 实现第一人称控制器
6. 实现碰撞检测和出口判定

整个过程大概持续 1-3 分钟，取决于模型响应速度和任务复杂度。期间它会自动执行一些命令来验证，比如用ls查看文件是否创建成功。

5.2 输入第二句补充视觉和交互细节

第一轮生成完成后，我接着输入第二句：

视觉上用低多边形风格，地面是深灰色网格，墙壁用随机颜色的方块，加一个方向光和环境光；移动速度适中，鼠标灵敏度可调；碰到墙壁有轻微震动反馈，找到出口弹出提示。

这时候 Claude Code 会读取已有的index.html，在原有代码基础上做修改。它会：

• 修改材质定义，把地面改成网格纹理
• 给墙壁方块随机分配颜色
• 添加DirectionalLight和AmbientLight
• 调整移动速度参数
• 添加碰撞时的相机震动效果
• 添加出口触发的弹窗提示

这个阶段的关键是AI 会保留第一轮已经正确的部分，只改需要改的地方。这也是 Claude Code 相比从零重新生成的优势——它有文件上下文，知道当前代码长什么样。

5.3 输入第三句确定运行方式和代码组织

第三句我输入的是：

用单个 HTML 文件实现，Three.js 通过 CDN 引入，不需要构建工具，双击就能在浏览器打开；代码加上清晰注释，方便我后续修改。

如果前两轮已经基本满足这个要求，第三轮主要是让 AI 检查并补全。实测中 Claude Code 会做这些事：

• 确认 Three.js 确实是通过 CDN 引入的
• 检查是否有遗漏的依赖
• 补充代码注释
• 可能还会加一个简单的操作说明浮层

到这里，三句话输入完毕，一个可玩的3D迷宫 demo 就成型了。整个过程我没有写一行代码，没有打开任何建模软件，没有配置任何构建工具。

5.4 运行验证与效果确认

在浏览器里打开index.html，你应该能看到：

• 一个由彩色方块墙壁构成的迷宫
• 深灰色网格地面
• 第一人称视角，WASD 可以移动
• 鼠标拖动可以转视角
• 撞墙时有轻微的画面震动
• 走到出口位置弹出提示

如果某个效果没出现，大概率是浏览器缓存或者 CDN 加载问题。按 F12 打开控制台看报错，把报错信息直接贴给 Claude Code，它会自己修。

5.5 关键参数的计算与调整逻辑

虽然 AI 会给出默认参数，但理解这些参数的含义能帮你更精准地调整。以第一人称控制器为例，几个核心参数：

这些数值不是随便定的。移动速度 5.0 单位/秒意味着每秒移动5个场景单位，如果迷宫通道宽度是3个单位，这个速度刚好不会让人晕。相机高度 1.7 是模拟成年人眼高，低于1.5会显得矮，高于2.0会显得飘。

注意：调整参数时一次只改一个，改完立刻测试。同时改多个参数会导致你分不清是哪个改动产生了效果，排查问题时会很痛苦。

6. 常见问题与排查技巧实录

6.1 AI 生成代码跑不起来怎么办

这是最常见的问题。排查顺序建议如下：

第一步：看浏览器控制台报错。F12 打开 Console，红色报错信息直接复制给 Claude Code，90% 的问题它能自己修。

第二步：检查 CDN 是否加载成功。Network 面板看 Three.js 的请求状态，如果是 404 或超时，换个 CDN 地址。我常用的是cdn.jsdelivr.net和unpkg.com，两个互为备份。

第三步：检查文件是否完整生成。有时候 AI 写到一半停了，index.html内容不完整。让 Claude Code 重新读取文件并补全。

第四步：检查浏览器兼容性。Three.js 新版本对旧浏览器支持不好，建议用 Chrome 或 Edge 最新版。

6.2 提示词说了但 AI 没执行

这种情况通常是提示词里的需求太模糊，或者和已有代码冲突。解决方法：

• 把模糊需求拆成具体指令。比如“好看一点”改成“墙壁颜色改成深蓝色和深灰色交替”
• 明确指出要修改的文件和位置。比如“修改 index.html 里控制移动速度的那个变量”
• 如果 AI 说“已经实现了”但你没看到效果，让它把相关代码片段打印出来确认

6.3 性能问题：帧率低、卡顿

3D 场景卡顿通常有几个原因：

让 Claude Code 优化性能时，直接说“帧率低，帮我优化渲染性能”，它会分析代码并给出优化方案。实测中它常做的优化包括：用InstancedMesh批量渲染相同几何体、减少光照数量、降低阴影分辨率。

6.4 常见问题速查表

6.5 独家避坑技巧

技巧一：让 AI 先写注释再写代码。在提示词里加一句“先写清楚每个模块的注释，再写实现”，生成的代码可读性会好很多，后续你自己改也方便。

技巧二：分阶段验证，不要一次性提太多需求。三句话是核心指令，但每句话执行完后都应该验证一下。第一句跑通了再发第二句，避免错误累积。

技巧三：保留一个可回退的版本。在让 AI 做大改动之前，先手动复制一份index.html备份。AI 有时候会把能跑的代码改坏，有备份就不慌。

技巧四：用 git 管理版本。如果熟悉 git，在项目目录初始化一个仓库，每次 AI 改完提交一次。这样任何改动都可以回退，比手动备份优雅得多。

技巧五：提示词里加“不要做什么”。比如“不要用 npm”“不要引入额外的库”“不要改我的 HTML 结构”。负面约束有时候比正面需求更能控制 AI 的行为。

7. 从 demo 到可玩：后续扩展方向

三句话做出来的 demo 是个起点，不是终点。如果你想把它扩展成一个真正能玩一会儿的小游戏，有几个方向可以继续推进。

方向一：增加游戏机制。比如加入收集品、计时器、敌人巡逻、关卡递进。这些都可以用追加提示词让 AI 实现，比如“加一个收集钥匙才能开门的机制，钥匙随机分布在迷宫角落”。

方向二：替换视觉资源。demo 用的是基础几何体，你可以让 AI 接入 glTF 模型加载器，然后自己找一些免费的低多边形模型替换方块。这一步需要你提供模型文件，AI 负责写加载代码。

方向三：加入音效。用 Web Audio API 或者简单的Audio对象，给移动、碰撞、通关加上音效。提示词可以写“用 Web Audio API 生成简单的碰撞音效，不要引入外部音频文件”。

方向四：移动端适配。加虚拟摇杆和触摸转视角，让手机也能玩。这个改动比较大，建议单独开一轮对话专门做。

方向五：多人联机。这个就超出 demo 范畴了，需要后端支持。AI 能帮你写 WebSocket 通信代码，但服务器部署和状态同步逻辑需要你自己把控。

我个人在实际操作中的体会是，AI 最擅长的是把想法快速变成可运行的原型，让你在几分钟内看到效果、验证方向。但原型到产品之间的那段路，仍然需要人的判断力。参数调优、手感打磨、性能优化这些事，AI 能辅助但替代不了你的审美和经验。

最后分享一个我常用的提示词模板，你可以直接抄：

用 [技术栈] 做一个 [游戏类型]，核心玩法是 [一句话描述]。 视觉风格 [风格描述]，交互上 [关键交互细节]，反馈上 [反馈机制]。 用 [运行方式] 实现，[依赖管理方式]，代码 [组织要求]。

把方括号里的内容替换成你的需求，就是一套完整的三句话提示词。实测下来，这个模板对 Three.js、Babylon.js、甚至 Godot 的 GDScript 都适用。关键是把技术栈、玩法、约束这三样说清楚，剩下的交给 AI。