故乡故乡如果说这几年有什么事情让我对“AI 编程工具到底能改变什么”有了更具体的体感，那就是用 Claude Opus 5 去做 Minecraft 风格的小项目。很多人想象中的场景是：输入一句“帮我做一个《我的世界》”，回车，几十秒后得到一个完整游戏。实际体验完全不是这样，但它并没有因此变得无趣，反而更有意思。
真实的情况是：Claude Opus 5 可以在 1 分钟内给你一个能打开的网页版体素世界骨架，一片绿色方块构成的地面，一个可以转动的视角；用 1 小时持续迭代，它能拥有移动、跳跃、放置方块、破坏方块这些基础玩法；再给它 1 天时间，你会得到一套可以保存进度、部署到线上、让朋友打开链接一起体验的小作品。
所以我更愿意给出这样一个判断：用 Claude Opus 5 做 Minecraft，核心价值不是“一句话生成完整游戏”，而是把“做游戏”这件事拆成了三种完全不同节奏的创作方式。1 分钟、1 小时、1 天，对应的分别是想法提案、玩法原型、可分享作品。三个档位背后，是三种验收标准，也是三种和 AI 协作的工作法。
这篇文章就以“用 Claude Opus 5 做出 Minecraft 我的世界”为例，讲清楚每个时间档位你能得到什么、应该怎么验收、最容易在哪里翻车，以及如何把一次 AI 生成变成一套可持续迭代的工作流。
1. 先想清楚：用 AI 做 Minecraft，做的是哪一层（What You Are Actually Building）
1.1 你不可能在 1 分钟里做出真正的 Minecraft
真正的 Minecraft 是一个高度工程化的作品。它不是一个“3D 方块世界”那么简单，还包括程序化地形生成、区块加载与卸载、生物行为、合成系统、红石电路、光照计算、服务器同步、存档管理、模组生态……就算只是复刻其中一小块，也够一个团队做很长时间。
用 Claude Opus 5 在 1 分钟里做出来的，通常是一个网页版体素世界 Demo，最常见的技术路线是用一个 HTML 文件 + JavaScript + three.js，在浏览器里渲染出由方块构成的地形。
这个产物当然不是真正的 Minecraft。它没有无限地图，没有合成系统，没有生物，也没有红石。它甚至不一定是一个“游戏”，更像是一个可以走进去看的 3D 场景。
但这并不意味着它没有价值。它的价值在于：把“我想做一个方块世界”这个模糊想法，在 60 秒内变成一个肉眼可见、可以交互的起点。这个起点在过去不容易获得，因为传统的开发流程至少要经历“搭环境 -> 建项目 -> 写渲染 -> 写交互”这一整条链路，最快也要几个小时。
1.2 用 AI 做游戏更像一种快速提案工作流
当你在和 Claude Opus 5 协作做游戏时，真正发生的工作流不是“让它替你写代码”，而是：
- 你用自然语言描述需求。
- 它生成一段可运行的代码。
- 你运行并观察效果。
- 你反馈问题或提出新需求。
- 它修改代码。
- 重复以上循环。
这个过程很像一个产品经理和一个程序员在封闭环境里快速迭代。只不过“程序员”换成了 AI，迭代速度提升到了分钟级。
理解这一点很重要。因为很多人第一次使用这类工具时，会把它当成搜索引擎或者文档生成器，提完需求之后坐在那里等一个完美答案。实际用过就会明白：AI 生成的第一版代码通常能跑，但不会完全符合你脑子里的画面。它更像一个执行力很强、但需要你不断校准方向的新人程序员。
1.3 时间档位就是验收标准
“1 分钟做出 Minecraft”这个标题容易误导人。它听起来像是一个时间竞赛，但实际上是在说三层不同的目标：
- 1 分钟：验证想法。你能不能在 1 分钟内让一个 3D 方块世界出现在屏幕上？
- 1 小时：验证玩法。你能不能在 1 小时内让它从一个“能看的场景”变成一个“能玩的原型”？
- 1 天：验证作品。你能不能在 1 天内让它成为一个别人可以打开、保存、认可的东西？
这套逻辑不只在 Minecraft 项目里成立。你写任何小工具、做任何小应用，都可以用“一小时能做到什么，一天能做到什么”来作为验收坐标。它比“让 AI 一次性搞一个完美成品”要实际得多，因为一版代码永远无法承载完整的产品定义。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 准备一个能反复迭代的生成环境（Set Up an Iteration-Ready Environment）
2.1 浏览器三件套就够了
用 Claude Opus 5 做 Minecraft，最大的外部优势是你的运行环境非常轻：一个浏览器，一个文本编辑器，一个静态文件服务。
不需要下载 Java 版启动器，不需要处理“启动器卡在正在开始安装”这类经典问题，也不需要去找服务器地图、切换版本、装模组。你可能从来没想到，做“我的世界”还能绕开这一整套本地环境维护工作，但 Web 版体素世界就是有这种好处。
建议准备下面三样东西：
- 一个项目目录，用来存放每次生成的 HTML 文件。
- 一个本地静态服务，推荐在项目目录运行
python3 -m http.server 8080，然后访问http://localhost:8080。 - 一个浏览器控制台，用来查看报错信息。
如果你不想开本地服务，直接把 HTML 文件拖进浏览器大多数情况下也能跑。但如果代码里用了 ES Module 或者需要加载外部资源，最好还是用本地服务，避免浏览器安全策略把脚本拦截掉。
bash复制cd your-voxel-world
python3 -m http.server 8080
启动后，浏览器打开 http://localhost:8080/你的文件名.html。这个流程极其稳定，也方便反复验证每次生成的代码。
2.2 三份必备输入：需求描述、依赖说明、验收清单
很多人在让 AI 写游戏时只丢一句话：“帮我用 Minecraft 风格做个游戏”。这句话的信息量太低。模型只能凭猜测行事，生成出来的代码往往偏演示化，或者加入一大堆你根本不需要的功能。
我的建议是在每个迭代轮次都准备三份输入：
- 需求描述：这个版本要做什么，不要做什么。
- 依赖说明：技术栈和运行方式，避免 AI 默认生成复杂工程。
- 验收清单：怎样算做到，怎样算没做到。
| 输入类型 | 示例 |
|---|---|
| 需求描述 | “生成一个 3D 体素世界，地面由绿色方块组成，支持鼠标视角旋转” |
| 依赖说明 | “用单个 HTML 文件实现，使用 three.js 的 CDN 版本，不需要构建工具” |
| 验收清单 | “页面打开后 3 秒内出现地面；WASD 可移动；鼠标拖动能旋转视角；控制台无报错” |
三份输入不一定要很复杂，但它决定了 AI 生成的代码会以什么形式落入你的项目目录。需求边界越清晰，后续迭代越省时间。
2.3 给 Claude Opus 5 一个清晰的角色和约束
Claude Opus 5 这类对话式 AI 编程工具，在你给足上下文的时候表现最好。你可以直接给它一个英文 Prompt，也可以让它先输出方案再输出代码。下面这个模板可以直接复制，英文发给模型，中文是给你看的说明：
code复制You are a senior front-end game developer.
Create a single-page voxel world demo inspired by Minecraft.
Technical stack:
- one HTML file
- use three.js from a CDN
- no build tools, no import maps
Acceptance criteria:
1. The page shows a flat ground made of green voxel blocks.
2. The user can move forward/backward/left/right with WASD.
3. The user can look around with mouse drag or pointer lock.
4. The camera starts above the ground.
5. Keep the code under 300 lines and add comments.
翻译成人话就是：你是一名资深前端游戏开发者，请创建一个受 Minecraft 启发的单页体素世界 Demo，技术要求是单 HTML 文件、使用 three.js CDN、不需要构建工具，验收标准是地面可见、WASD 可移动、鼠标可视角旋转、初始摄像头在地面上方，代码控制在 300 行以内并添加注释。
这段 Prompt 的精髓不是“要什么”，而是“不要什么”：不要复杂工程结构、不要构建工具、不要功能堆砌。它直接决定第一版代码的形态。如果你想控制代码复杂度，还可以在 Prompt 末尾加一句：Don't add features beyond the acceptance criteria。
3. 1 分钟档：先让一个 3D 世界出现在屏幕上（The 1-Minute Demo）
3.1 最小目标：一屏方块 + 能移动的视角
“1 分钟档”验收目标要放得很低。你不需要地形起伏，不需要挖掘，不需要放置方块，甚至不需要很漂亮。只需要三件事：
- 页面打开后能看到一个绿意盎然的方块地面。
- 鼠标或 WASD 能改变视角位置。
- 浏览器控制台没有红色报错。
把这三个条件写进 Prompt。运行之后，如果屏幕上是蓝天白云加一片方块草地，视角能自由移动，这轮就算通关。
不要急着提出“我要更多功能”。因为 1 分钟档的产物有它自己的使命：验证“想法能不能变成一个可运行的东西”。它证明的是思路可行，不是代码可维护。
3.2 用验收清单代替代码审查
很多开发者在拿到 AI 生成代码后会习惯性地逐行阅读。这没有错，但在 1 分钟档，我更建议你先运行，再判断，最后才看代码。
为什么要这样？因为 AI 生成的代码风格可能和你平时写的不一样。你盯着看不出来问题，跑一下立刻见分晓。如果页面是黑屏，再去控制台看报错；如果方块太小、位置不对，再让 AI 调整参数。
判断要点也很简单：它是不是一个可运行的单文件？运行后的视觉结果是否符合“方块世界”的基本预期？如果是，这分钟就花得很值。
3.3 1 分钟的产物适合做什么
这版产物适合做三件事：
- 用来验证你和你选择的 AI 工具之间能不能顺畅协作。
- 用来确认技术路线是否可行：浏览器渲染 3D 方块的方案是否满足你想做的方向。
- 用来给自己一个正反馈：原来 60 秒真的能让一个世界从无到有。
它不适合直接作为后续功能的建筑地基。因为第一版代码里，初始化、渲染、输入控制往往耦合在一起，在这个基础上不断加功能，加不了几轮代码就会变得混乱。
更合适的做法是：如果 1 分钟档跑通后你确定要继续做，就重新开一个会话，把“完整的需求”重新描述一遍，让模型基于更清晰的要求重新生成结构化更高的一版代码，然后再开始加功能。
4. 1 小时档：从“能看”到“能玩”（The 1-Hour Playable Prototype）
4.1 拆成三个迭代循环：地形、交互、状态
真正把一个方形世界变成“能玩”，通常需要三个方向的迭代：
- 地形：从纯平面变成起伏地形，从单一草方块变成泥土、石头、木头等多种方块。
- 交互：从只能看，变成可以选中方块、放置方块、破坏方块。
- 状态：从无重力自由飞行，变成有下落、有碰撞、有移动速度控制的角色。
这三个方向会相互纠缠。地形起伏会影响角色碰撞；放置方块需要射线检测；破坏方块需要能识别玩家看向的方块位置。所以我不建议并行推进，而是建议按顺序做三个循环。
4.2 每一轮只加一个能力
在 1 小时迭代里，最忌讳的是把下面这些需求一次性丢给模型：
“请加入地形生成、不同方块、放置、破坏、背包、重力、合成系统、红石电路。”
模型的上下文窗口再大，也不代表它能在一个版本里同时处理好所有系统。真实的工程里，功能之间有依赖，代码会互相干扰。AI 一次性生成的“大杂烩”往往看起来功能很多，但每一个都半残。
正确的节奏是每一轮只加一个能力，类似这样：
- 第 1 轮：在现有地面上加入草地、泥土、石头三种方块，随机分布。
- 第 2 轮：加入角色重力，玩家会站在方块表面而不是直接跌落。
- 第 3 轮：加入准星和射线检测，玩家可以观看到目标方块。
- 第 4 轮：加入方块破坏功能，击中后方块消失。
- 第 5 轮：加入方块放置功能，在目标位置生成新方块。
- 第 6 轮：加入一个简单工具栏，可以切换方块类型。
每一轮的 Prompt 都可以保持同一结构：说明现状 -> 提出新能力 -> 给出验收标准。例如：
code复制Keep the current voxel world and movement system unchanged.
Add block-breaking:
- Aim at a block with the crosshair.
- Left-click to destroy the targeted block.
- Remove only the targeted block, not blocks in a radius.
Do not add new features beyond this one.
中文意思是：保持当前体素世界和移动系统不变，加入破坏方块功能，用准星瞄准，鼠标左键摧毁目标方块，只移除被瞄准的那一个，不要添加额外功能。
这种“每轮只加一个能力”的写法，能让每个改动都可控。一旦某一轮出错，你能精确知道是这一轮的改动引起的，而不是在一堆新功能里大海捞针。
4.3 这个阶段真正的难点：需求边界
到了 1 小时档，你会发现自己遇到的最大阻力不是“AI 不会写”，而是“你到底想让它写什么”。
“像 Minecraft”是一个永远没有终点的需求。如果你不对边界做定义，Claude Opus 5 会在每一轮都开一个更大的口子。你可以选择做创造模式、生存模式、合成系统、多人联机、昼夜循环、生物生成……但 1 小时装不下这些。
我的建议是在开始前先写一句话定义边界。比如：
- “这是创造模式，没有生命值，没有合成。”
- “世界是有限的：边长 64 格，边缘用基岩围住。”
- “方块类型限定 5 种：草方块、泥土、石头、原木、树叶。”
把这个边界写进每轮 Prompt 的开头。它会让模型每次迭代都守在一个明确框架里，不容易跑偏。这个技巧在 1 小时档里比任何代码优化都重要。
注意：不要在一轮里同时加三个新系统。一次只改一个变量，你才能真正判断效果来自哪里，错误出在哪一层。
5. 1 天档：把原型变成可以分享的“作品”（The 1-Day Polished Build）
5.1 持久化：存档不是加分项，是必要性
如果你在 1 小时档结束时已经能建造和破坏方块了，那 1 天档的核心任务就是把“会动的 Demo”变成一个“玩过之后能留点东西下来的小世界”。
第一个要解决的是存档。没有存档的世界，玩家关掉浏览器后一切归零。这会让所有建造行为失去意义。
Web 端最简单的方案是 localStorage 或 IndexedDB。方块世界的地图数据通常是嵌套数组或者坐标映射，用 JSON 序列化后存下来，在页面加载时读取，如果有存档就恢复，没有存档就生成新世界。
这个步骤在代码上并不难，但它要求你把“数据结构和渲染逻辑”分开：地图数据是一层，渲染显示是另一层，存档只是把地图数据序列化下来。如果早期代码把地形生成、渲染、存档全部耦合在一起，后面这步会非常痛苦。如果前期每轮迭代都花了点时间做结构，存档就是水到渠成的事。
5.2 性能、加载和资源管理
一个网页版的体素世界，性能问题会在地图变大之后立刻暴露。
如果地图只有 32 x 32 个方块，直接渲染方块列表没问题。但你想要更大的地图，就不能再一帧渲染几万个方块。常见做法有：
- 批量合并：把相同类型的方块合并成一个大几何体，减少渲染调用。
- 视线裁剪：只渲染玩家附近和视线范围内的区块。
- 固定世界边界：给世界限定一个范围，不要无限生成。
这些技术名词听上去很吓人，但在 Claude Opus 5 的帮助下，你可以一步一步让它实现。比如先给它一个 64 格见方的世界，让方块数量从几千变成几万，再观察页面是否卡顿。如果卡顿，把问题描述给它：“页面在 64x64 方块世界下帧率下降到 20，请用合并块几何体或视锥裁剪优化”，它通常会给出可行的改造方向。
不过要提醒一句：AI 优化性能时可能会引入新的 bug。每一轮优化之后都要重新走一遍最基础的操作流程，确认移动、放置、破坏、存档都正常。
5.3 让其他人能打开你的世界
“1 天档”最重要的验收标准是分享。如果这个世界的产物只能静静地躺在你本地的项目目录里，那它还没有成为一个作品。
最简单的部署方式是使用静态托管平台，比如 GitHub Pages 这类服务：把你的 HTML 文件推到仓库里，开启 Pages，几分钟后就能得到一个公开链接。把链接发给朋友，对方打开网页就能进入你建造的世界。
在这个阶段，“Minecraft 下载服务器的地图”这类传统问题几乎不会出现。因为你不需要搭建 Minecraft 服务器，不需要让所有人安装相同版本，不需要处理内网穿透，不需要下载几十 GB 的地图文件。唯一的代价是：它是一个 Web 版世界，不是 Java 版，功能也远没有正规服务器那么完整。
如果你打算把部署和存档都放在线上，注意一点：本地浏览器里跑的存档属于玩家本地，换一台电脑就看不到自己的东西。如果想让存档跟着账号走，就需要接入后端数据库服务。普通练习项目不建议一上来就上后端，先用本地存档把流程打通，等确认产品有价值，再加入账号体系。
6. 三个档位的产物对照与选择建议（Which Milestone Fits Your Goal）
6.1 一分钟、一小时、一天的产物对比表
| 维度 | 1 分钟 | 1 小时 | 1 天 |
|---|---|---|---|
| 核心目标 | 验证想法 | 验证玩法 | 验证作品 |
| 典型产物 | 可打开的 3D 方块场景 | 可自由建造和挖掘的原型 | 可部署分享、带存档的小作品 |
| 代码结构 | 高度耦合 | 已经拆分模块 | 具备基础可维护性 |
| 验收标准 | 页面能开、能走、能看 | 能挖、能放、不崩溃 | 别人能打开、能存档、体验流畅 |
| 适合场景 | 好奇心、灵感验证 | 快速做玩法验证 | 交付给朋友、作品集、小范围测试 |
| 风险 | 代码像一次性草稿 | 功能边界容易失控 | 性能和兼容性问题开始出现 |
这张表的核心思路是：不要在 1 分钟档追求 1 小时档的玩法，也不要用 1 小时档的心态去做 1 天档的事。不同的时间预算，配不同的目标，正是和 AI 协作最需要的分寸感。
6.2 根据目的选择档位
如果你是初学者，第一次和 Claude Opus 5 协作，别直接挑战 1 天档。先花 1 分钟跑通一个世界，找到“AI 生成 -> 本地运行 -> 反馈问题”的感觉，然后再逐步加功能。
如果你是想快速验证一个游戏想法，比如“方块世界的建造手感好不好”，那 1 小时档最合适。你不需要打磨分享链接，不需要收藏存档，只需要在本地把这一种玩法跑到“感觉差不多了”。
如果你是要给朋友展示、放进作品集、或者给一个小圈子试玩，那至少需要 1 天档。因为只有到了这个档位，你才会开始思考“别人用得顺不顺”“刷新后是否还在”“打开链接会不会太慢”这类的真实使用问题。
6.3 一个通用流程：先跑通、再优化、再工程化
这三个档位并置在一起时，会自然浮现出一个可以复用的工作流：
- 先跑通：用最小需求做出可运行版本，不管代码质量。
- 再优化：在可运行基础上，一轮一个能力地增加玩法。
- 最后工程化：拆结构、加存档、做优化、部署上线。
很多没有经验的开发者会跳步。有人从第一分钟就要求“优化很棒的代码”，结果还没看到一个能跑的世界；有人直接想花一天做“最终成品”，结果迷失在无尽的需求里。
“先跑通、再优化、最后工程化”是我在大量 AI 辅助开发里验证过的路径。它尤其适合生成式工具，因为 AI 生成的结果质量不稳定，过早优化或者过度规划都会浪费它最有价值的部分——快速产生可运行结果。
7. 用 Claude Opus 5 做 Minecraft 的常见问题排查（Troubleshooting the AI-Generated World）
7.1 从现象到原因，按三层排查
和 AI 生成的代码打交道，遇到问题时要有一个稳定的排查顺序。不要一上来就改代码，先判断问题出在哪一层。
- 第一层：现象层。是页面打不开？黑屏？白屏？卡顿？没有反应？方块消失？还是角色掉出世界？
- 第二层：输入与依赖层。Prompt 是否缺少技术约束？CDN 是否加载失败？本地服务是否启动？浏览器是否拦截了脚本？
- 第三层：代码逻辑层。模型是否把方块坐标写死？射线检测的方向对不对？存档读取和写入是否用了同一个数据结构？
以“页面全白”为例：如果页面是纯白，通常是脚本报错导致没有渲染。打开浏览器控制台看第一条错误，把错误信息完整复制给 Claude Opus 5，问它根据报错修复代码。
以“方块放上去第二天没了”为例：这通常不是渲染问题，而是存档问题。先检查是否有存储操作被触发，再检查加载时是否优先读取了存档，最后检查方块数据和存档数据结构是否一致。
7.2 最容易翻车的位置：输入、环境、保存
从经验来看，AI 辅助做一个 Web 版 Minecraft，翻车集中在这几处：
- 输入描述含糊。比如不说明“使用 three.js CDN”，模型可能生成一个依赖本地 Node 包的项目结构，导致你本地根本跑不起来。
- 环境问题。比如文件没通过本地服务打开，模块被浏览器拦截。这种报错和代码本身无关。
- 存档数据格式不一致。比如生成世界用的是二维数组，存档恢复时用了三维数组，加载后地图错乱或空白。
处理思路很简单：把报错信息、生成代码中的关键函数、和你的运行方式一起发给模型，让它做一次回归分析。不要只甩一句“还没看到画面”，那样模型只能猜。
7.3 当 AI 生成的代码出现问题时，如何继续
如果某一次生成的结果错误非常严重，不要一直在这份代码上修。选更高效的做法：
- 保留代码文件和 Prompt 记录。
- 开一个新会话，把之前的完整需求描述和新发现的问题一起告诉模型。
- 让模型基于新需求重新生成，而不是在混乱代码上打补丁。
AI 生成代码的特点是一次性重新生成成本很低，反复修补成本反而高。你用十分钟在一个旧文件上缝缝补补，不如让它重新生成一份结构更清晰的版本。这个决策在一些人看来很浪费，但实际是避险。
7.4 不要把所有希望寄托在一次生成上：版本管理
AI 编程人的真正风险不是能力不足，而是“这版明明刚才是好的，改了三个需求之后突然不行了”。如果没有版本管理，你只能面对一份越改越乱的文件束手无策。
真正的解决方案是把每次生成结果都保存一个新文件。比如：
world_v1.htmlworld_v2.htmlworld_v3.html
不需要一开始就用 Git，简单保存文件名就能解决 90% 的回退需求。当你做了一整天之后，你会庆幸自己留下了每一次的可运行版本。这个习惯比任何代码技巧都重要。
注意：每次让 AI 改代码之前，先把当前可运行版本另存一份。这样即使改坏了，也能立刻退回到上一个正常状态，而不需要重新让模型生成一份不确定能不能跑的代码。
8. 真正值得长期沉淀的，不是代码，而是工作流（The Real Takeaway Is the Workflow）
8.1 1 分钟、1 小时、1 天的背后是三种工作方式
用 Claude Opus 5 做 Minecraft，最有趣的不是最终那个 HTML 文件，而是三个时间档位背后的工作方式差异。
1 分钟档教会你的是“快速提问”。你到底想要什么，你能不能把模糊想法压缩成一句话，并让 AI 朝着有效方向生成。
1 小时档教会你的是“逐步逼近”。你不再追求一次性正确，而是接受“每轮改进一点、坏一点、修一点”的迭代现实。你学会了控制一次只改一个变量，学会了用验收清单判断是否完成。
1 天档教会你的是“工程边界”。你会开始思考结构、存档、性能、部署，会开始理解一个 toy demo 到可分享作品之间到底隔了什么。
这三层体验，超出“做游戏”本身。它是在训练一种和生成式工具协作的基础能力：把你脑中模糊的意图，转化成可执行、可验证、可迭代的任务。未来无论你是想用 AI 写一个网页、做一个小工具、生成一份数据分析报告，这一套工作方式都能复用。
8.2 什么人适合用这种方式做游戏
这种方式并不适合所有想“做游戏”的人。
如果你学的是游戏开发，想要真正理解渲染管线、物理引擎、游戏循环这些底层机制，那 AI 辅助生成代码不能替代系统学习。你需要的是自己一行行写代码、调 bug、理解每一个系统背后的设计动机。
但如果你脑子里已经有一个玩法想法，你想快速看到它能不能成立；或者你做了多年的游戏方向，想快速对某个创意做原型验证；又或者你只是想在周末做一个可以发给朋友玩的小世界——那么“1 分钟档起步，1 小时档迭代，1 天档打磨”的路径非常实际。
8.3 最后给新手的一句话
看到这篇文章的任何一个读者，下一周如果你也准备尝试一次，我的建议极简：先打开一个空白 HTML 文件，让 Claude Opus 5 在 1 分钟内给你一片绿色方块世界。先不要想所谓的“完整游戏”，先看到它出现在浏览器里，再决定下一步要把这个世界变成什么样。
模型负责生成代码，你负责判断什么是重要的，什么应该坚持，什么可以砍掉。这几个判断加在一起，就是创作本身。做到这一步，“1 分钟做 Minecraft”这个标题的灵魂才算真正被抓住了。