当“做出来”不再稀缺：AI 时代，游戏开发者的价值正在转移

过去，一个复杂产品之所以昂贵，很大程度上不是因为人类缺少想法，而是因为把想法变成现实很贵。

想做一个网站，需要有人懂前端、后端、数据库和部署；想写一个游戏，需要程序、美术、策划、动画、音频、测试共同工作；想研究一个数学问题，则可能需要十几年教育和数年专业训练，才有资格真正进入问题本身。

AI 正在改变的，首先就是这件事。

代码、文案、图片、3D 资产、测试、资料检索，乃至越来越复杂的软件任务，都开始能够由模型在分钟甚至秒级时间内完成。过去需要几天搭出的原型，现在可能只需要一句自然语言描述。

于是一个令人不安的问题出现了：

如果“会做”本身越来越廉价，那么一个专业人士还凭什么有价值？

对于游戏开发者，这个问题尤其尖锐。

因为游戏恰好处在软件工程、实时系统、视觉艺术、交互设计和产品体验的交界处。它既能让我们看到 AI 惊人的生产能力，也能让我们看到“生成代码”和“完成产品”之间仍然存在的巨大距离。

这篇文章不试图预测“几年后还有多少程序员”，也不试图证明 AI 最终能或不能取代某个职业。

更值得讨论的是一个相对稳定的问题：

当执行成本不断下降，整个生产系统的瓶颈会转移到哪里？

理解这个问题，也许比预测下一代模型究竟有多强更重要。

1当“做出来”突然变得廉价

过去的软件生产大致遵循这样一条路径：

这条链路中，每一步都很昂贵。

一个开发者之所以拥有市场价值，不仅因为他能够判断应该做什么，也因为存在大量别人根本做不出来的事情。

不会 C++，就很难修改底层引擎。

不懂图形学，就很难实现复杂 Shader。

不了解网络同步，就很难写多人游戏。

于是知识本身形成门槛，工具形成门槛，熟练度形成门槛，执行时间同样形成门槛。

AI 正在逐渐压缩中间这一大段：

知识没有消失，工程也没有消失。

发生变化的是：

越来越多知识不再必须先完整地存在于执行者的大脑里，才能被转化成结果。

这与搜索引擎带来的变化还不太一样。

搜索引擎降低的是找到知识的成本；生成式 AI 进一步降低了把知识转换成行动的成本。

你不再只是搜索“Unity 怎么实现对象池”，然后阅读文章、理解 API、复制代码、修改报错。

Agent 可以直接进入项目：

读取代码、理解上下文、修改文件、运行测试、观察错误，再继续修改。

它开始进入过去属于“工作本身”的部分。

早在 2023 年，一项针对 758 名 BCG 顾问的随机实验就发现，在落入当时 GPT-4 能力边界之内的知识工作任务上，使用 AI 的参与者完成任务更快、完成率更高，输出质量也更高；但研究同时提出了一个后来非常重要的概念：Jagged Technological Frontier，锯齿状技术前沿。¹

AI 并不是均匀地向所有能力推进。

有些过去需要多年训练的任务，它突然做得极好；另一些看起来简单得多的问题，它却可能犯下令人难以理解的错误。

因此真正发生的，并不是：

所有专业知识一夜之间失去价值。

而是：

“我会做，而别人不会”这层稀缺性正在迅速变薄。

2AI 到底强到了什么程度

讨论 AI 很容易落入两个极端。

一个极端是：

它不过是在预测下一个 Token，本质上只是统计，因此不可能真正完成复杂工作。

另一个极端则是：

AI 已经可以做所有事情，人类专业能力马上就没有意义了。

这两种说法都很难准确描述今天的现实。

2.1从回答问题到执行任务

早期语言模型最显眼的能力是“回答”。

现在越来越重要的能力却是：

在一个环境中持续采取行动。

这也是 Agent 与单纯 Chatbot 的核心区别之一。

Agent 不再只生成一段建议，而可能执行这样的循环：

METR 用“Task-Completion Time Horizon”尝试衡量这类能力：如果一个任务通常需要人类专家工作若干时间，那么模型在多长的人类任务时长上仍能保持一定成功概率？截至 2026 年，其测试已经显示前沿 Agent 可以完成一部分原本需要专业人员数小时甚至数天的软件任务，在某些软件重新实现任务中还观察到了对应人类数周工作的成功案例。^{2 3}

但这个结论非常容易被误读。

METR 自己特别强调，它们的大部分测试是：

自包含、目标明确、上下文较少、可以自动评分的软件工程、机器学习和安全任务。

这并不等于：

“一个拥有两天 Time Horizon 的模型，可以直接替代一个工程师两天真实工作。”

真实工作通常有更多隐含背景、模糊需求、组织沟通和难以量化的成功标准。METR 也发现，当任务变得更“messy”时，模型的能力会明显下降。⁴

所以真正值得关注的不是某个具体的“小时数”。

而是一个方向：

AI 能够独立闭环完成的任务范围正在迅速扩大。

2.2“只是统计”并不能回答能力问题

语言模型当然建立在统计学习之上。

但“它由统计方法训练得到”描述的是机制来源，并不能直接推出它能够或不能够完成哪些功能。

类似地，说：

CPU 只是晶体管状态变化。

并不能说明 Photoshop 能不能处理照片。

说：

人脑只是神经元的电化学活动。

也不能直接回答人能不能证明定理。

对于工程实践而言，更有意义的问题并不是：

AI 的内部过程到底算不算与人类相同意义上的“思考”？

而是：

它能否可靠地完成推理、规划、纠错和工具调用？在什么条件下能？什么时候会失败？

意识、主观体验和机器是否具有与人相同意义的“思想”，仍然属于更深的哲学与科学问题。

但从功能层面看，今天的模型已经能够表现出相当复杂的推理行为。

这就足以改变生产方式。

2.3AI 的能力是一条锯齿状边界

真正危险的误解，是把 AI 能力想象成一条整齐推进的水平线：

简单任务 ──────────────── 复杂任务
██████████████████░░░░░░░

现实更像：

任务 A  ████████████████████
任务 B  ██████████
任务 C  █████████████████
任务 D  ███
任务 E  ███████████████████

高度相似的两个任务，模型可能一个表现超越大多数普通人，另一个突然失败。

因此：

知道 AI 很强，并不足以使用好 AI。

还必须知道它的能力边界在哪里，以及如何设计流程，让错误能够尽快暴露出来。

2.4一个值得校准的数学案例

2026 年 9 月，OpenAI 公布了一份由内部 AI 系统生成的 Navier–Stokes 存在性与光滑性问题解法，并同时公开论文和 Lean 形式化证明。Clay Mathematics Institute 随后表示，这一问题“apparently been settled”，即看来已经得到解决。^{5 6}

这确实是一个极其重要的信号：AI 已经开始进入过去只有最顶尖专业研究者才能真正参与的数学前沿。

但它并不等于“AI 已经拿到了千禧年大奖”。

OpenAI 明确表示无意凭借这一成果申领奖项；而按照 Clay Mathematics Institute 的正式规则，一个候选解答需要在合格渠道发表、至少经过两年，并获得全球数学界普遍接受，之后才进入进一步的奖项评估流程。⁷

3一句话生成游戏，究竟意味着什么

游戏开发是观察 AI 能力非常有意思的领域。

一方面，它很适合展示 AI。

一个模型只要生成：

角色、地形、敌人、射击、UI、粒子、音效和基础循环，

几分钟后就可以出现一个“看起来已经像游戏”的东西。

而十年前，这些内容足以占据一个独立开发者数月时间。

于是“一句话生成游戏”第一次变成了一件字面意义上可以发生的事情。

但另一方面，游戏也非常适合暴露 AI 的局限。

因为游戏并不是一组静态文件。

它是一个持续运行的世界。

3.1Demo、功能和产品不是同一种东西

一个游戏可以从三个层级理解：

生成一个可以奔跑、射击和击杀敌人的 FPS，和维护一个存在两年、经历二十次版本更新、支持多平台并拥有真实玩家存档的 FPS，并不是同一个问题。

最容易被 AI 压缩的，往往恰好是最容易被展示出来的部分。

一个几十秒视频可以展示：

漂亮的水面、爆炸效果、敌人 AI 和跑酷。

但很难展示：

玩家在低帧率下抓住物体会不会抖动；

载具重新加载存档后 Joint 是否仍然正确；

旧版本存档是否能够迁移；

NPC 使用同一把武器时是否会破坏状态机；

VR 左右手交换之后输入是否仍然一致；

多人游戏发生丢包时状态是否最终收敛。

这些东西不会出现在“一句话生成游戏”的宣传视频里。

但它们恰恰构成了真实游戏开发的大量工作。

3.2游戏开发基准开始暴露这条边界

2026 年的 GameDevBench 专门把游戏开发作为 Agent Benchmark。它并不只测试代码，而要求 Agent 处理 Godot 项目中的 Shader、Sprite、Animation、Gameplay、UI 和 3D 场景。其公开榜单截至 2026 年 9 月已经扩展到 333 个真实任务，最强配置的 pass@1 达到 68.8%。同时，研究发现加入截图和运行时视频反馈可以显著提高 Agent 的成功率。⁸

这同时说明两件事。

第一：

AI 已经能够完成相当比例的真实游戏开发任务。

第二：

即便是最强系统，仍然会在大约三分之一的测试上失败，而让它真正看到游戏运行结果会显著改善表现。

换句话说，游戏开发并没有因为代码能力提高而退化成纯文本问题。

GameEngineBench 更进一步，把 Agent 放进九个真实 Unreal Engine 5 C++ 项目中，测试 Gameplay、多人行为、AI、移动、UI、存档、序列化、XR 和渲染插件等任务。其论文报告的最强配置 pass@1 为 55.5%，110 个任务中有 31 个没有任何被测试的配置成功解决。⁹

而 GameXpert-Bench 给出的结论可能更加重要。

它把游戏 Agent 的工作分成三类：

从零生成游戏、修复缺陷、持续多轮优化。

研究发现，当前 Agent 相对擅长的是：

生成一个可玩的基础，以及按照明确指令加入功能。

明显更困难的是：

主动发现 Bug、验证真实运行行为，以及在连续修改中保持已有功能不被破坏。

¹⁰

这正是 Demo 与工程之间那条最关键的分界线。

3.3“代码能运行”甚至仍然不等于“功能正确”

2026 年 9 月发布的 CraftBench-UE 又展示了一个很有意思的问题。

研究者让 Agent 在 Unreal Engine 环境中提交 C++、Blueprint 和 Editor Script，并使用确定性的构建、资源与 Runtime Test 检查结果。

在其中一组 Blueprint 测试里，有相当一部分提交能够通过资产结构检查，却仍然无法通过明确的运行时 Gameplay Assertion。¹¹

也就是说：

项目存在
≠
可以编译

可以编译
≠
可以运行

可以运行
≠
行为正确

行为正确
≠
没有破坏其他功能

没有回归
≠
游戏好玩

代码生成只是这条链路最前面的一部分。

4为什么 AI 仍然需要人来掌舵

如果一个 Agent 足够快，我们能不能让它晚上自动工作八个小时，第二天早上直接验收几十个功能？

答案并不是简单的“能”或“不能”。

更重要的问题是：

这个任务到底有多容易被验证？

4.1自动化真正需要的不是生成器，而是评价函数

假设要求 AI：

实现一个函数，把对象序列化为二进制，再正确反序列化回来。

这个任务非常适合高度自动化。

因为我们可以建立明确测试：

Deserialize(Serialize(x)) == x

Agent 写十种方案都没关系。

只要测试足够完整，就可以迅速淘汰错误结果。

再例如：

优化某个算法，同时不能改变输出。

同样可以建立：

正确性测试 + Benchmark。

如果 AI 生成的版本：

结果一致，而且性能更高，

就可以接受。

但现在换一个目标：

让这个游戏更好玩。

评价函数是什么？

没有一个：

fun(game) = 0.873

可以直接告诉系统答案。

它甚至不是因为技术还不够成熟才没有。

“好玩”本身就是一个包含受众、情境、审美、节奏、文化和个人偏好的开放性判断。

因此可以得到一个非常重要的工程原则：

其中：

• $A_{\text{safe}}$ 表示适合交给 AI 的自主程度；
• $V$ 表示结果的可验证性（Verifiability）。

这不是一条严格的科学定律，而是一条很实用的工程启发：

任务越容易验证，就越适合提高 Agent 的自主程度。

4.2没有评价函数，高速执行可能只是高速随机游走

这也是为什么复杂 Agent Workflow 并不天然意味着更高生产力。

假设十个 Agent 每晚可以生成：

20 个系统、

50 个页面、

100 个功能、

20 万行代码。

这听起来拥有惊人的产能。

但如果没有可靠的评价函数，那么第二天面对的可能不是成果，而是：

需要重新理解、筛选、运行、调试和删除的二十万行未知代码。

生产速度越高，错误也可以被生产得越快。

所以自动化系统真正的瓶颈往往会从：

如何生成更多？

转移成：

如何判断哪些值得保留？

这是一种非常重要的“瓶颈迁移”。

5当执行不再稀缺，什么开始变得稀缺

如果执行成本持续下降，一个系统的价值不会消失。

它只会重新集中到其他位置。

过去，执行 经常占据绝大部分人力。

因此我们习惯把“开发能力”与“实现能力”混在一起。

但当执行越来越便宜，其他步骤的相对价值就会上升。

5.1定义问题

工程里大量浪费并不是因为代码写得太慢。

而是因为：

一开始就在解决错误的问题。

一个开发者可以花两周实现极其复杂的载具系统，最后玩家根本不愿意驾驶。

AI 可以把两周压缩成两小时。

但如果问题本身不值得解决，那么它只是把浪费从“两周”压缩成了“两小时”。

这当然是一种进步。

但并没有解决最重要的问题：

为什么要做这个？

因此“能够产生需求”和“能够理解需求”之间也存在巨大区别。

5.2系统设计与约束

生成一个功能和把功能放进一个长期运行的系统同样不是一回事。

例如实现“一把枪”，局部目标非常简单。

但进入真实项目后，它可能必须同时满足：

问题从：

怎么写射击代码？

变成：

这个对象应该拥有哪些状态？谁拥有状态？谁可以修改状态？哪些状态需要保存？哪些需要同步？不同系统发生冲突时谁优先？

这些不是单个函数的问题。

而是系统边界的问题。

AI 可以参与设计，但必须有人维持整个系统的概念一致性。

5.3验证

当生成变快以后，验证的重要性会不降反升。

可以用一个简单的工程直觉表达：

其中：

• $Q$ 是修改吞吐量；
• $p_{\text{escape}}$ 是错误没有被及时发现的概率；
• $C_{\text{late}}$ 是错误延迟发现后的平均修复成本。

这同样不是严格的预测模型，而是为了说明一个现象：

如果 AI 让 $Q$ 增长十倍，即使单次修改的错误率降低，验证系统如果没有同步增强，未被发现的问题仍可能快速积累。

所以未来重要的工程能力可能不仅是：

写代码。

还包括：

把系统设计成容易观察、容易测试、容易回归、容易证明哪里出错。

5.4整合与取舍

AI 最大的能力之一，是快速产生候选方案。

但候选方案越多，选择问题越重要。

过去：

“我们能不能实现这个？”

可能直接决定需求。

未来：

“这十种方案都能实现，到底应该留下哪一个？”

会越来越常见。

删除甚至可能比生产更加重要。

5.5品味与方向

对于游戏而言，还有一个无法忽略的问题：

技术正确，不意味着作品成立。

Minecraft 的价值并不是由“体素系统能够正常运行”推出的。

一套战斗系统拥有：

连击、

处决、

格挡、

部位伤害、

元素反应、

技能树，

也不能自动推出它比一套只有攻击和闪避的系统更好。

游戏设计不是不断增加功能，而是在大量可能性中建立一种有方向的一致性。

所以当 AI 能够生成越来越多功能时，真正稀缺的反而可能是：

知道什么东西不应该生成。

6游戏开发者的角色正在发生什么变化

这并不意味着 Programmer 会突然消失。

更可能发生的，是角色的重心移动。

以前，一个开发者的大量时间可能处于：

收到需求
↓
研究实现
↓
写代码
↓
修编译错误
↓
调接口
↓
提交功能

AI 正在猛烈压缩中间部分。

于是价值开始向流程两边迁移。

C → D 是当前 AI 最快速推进的区域。

于是开发者越来越值得向两个方向移动：

向左：问题定义。

为什么有这个需求？

真正的问题是什么？

有没有更简单的解法？

这个功能与整个系统是什么关系？

向右：结果判断。

运行起来了吗？

边界条件正确吗？

性能可以接受吗？

真的改善体验了吗？

玩家是否理解？

它值得继续维护吗？

可以把它概括成一句话：

向 Ticket 的左边和右边移动。

如果一个人的全部职业价值只是：

给我一个描述清楚的任务，我把它翻译成代码。

那么这个区域确实正在越来越直接地受到 AI 冲击。

而如果一个人能够：

找到正确的问题，设计解决问题的系统，并判断结果到底是否解决了问题，

AI 反而会放大他的能力。

6.1从 Programmer 到 System Designer

未来的开发者并不一定每天写更多代码。

可能恰恰相反。

一个人的工作逐渐变成：

他仍然是工程师。

只是“敲代码”在工程中的占比下降了。

真正的核心变成：

维护系统的正确方向。

这与导演很像。

导演并不会亲自拍摄每一个镜头、制作每一个道具、混音每一轨声音。

但这并不意味着导演只是“提出一个 Prompt”。

他的价值来自于：

知道作品要表达什么；

知道哪些东西应该出现；

知道哪里不成立；

知道什么时候应该重拍；

知道应该删掉什么；

能够让数百人的工作最终指向同一个作品。

AI 越来越像是在降低“制作一个镜头”的价格。

它并没有自动回答：

这个镜头为什么应该存在。

7基础知识还值得学吗

这里很容易推导出另一个极端：

既然 AI 能写 Shader、算法、物理和网络代码，那还学习这些基础知识干什么？

答案不是“因为 AI 永远做不到”。

这种安慰并不可靠。

更好的理由恰恰相反：

正因为 AI 越来越能做，理解基础才越来越从“生产工具”变成“判断工具”。

7.1过去：知识主要用于生产

学习 Quaternion，是因为以后要亲自写旋转代码。

学习网络同步，是因为以后要亲自实现 Replication。

学习渲染管线，是因为以后需要亲自写 Shader 和 Render Pass。

因此“会不会实现”成为学习的重要结果。

7.2未来：知识越来越用于判断

现在 AI 可以十几秒生成一份实现。

于是问题变成：

为什么这个 Joint 会爆炸？

这个 PID Controller 为什么振荡？

这个 Shader 为什么在移动 GPU 上突然变得极贵？

这段代码到底应该放在 Update、FixedUpdate 还是一个独立 Simulation Tick？

这里应该保存 Transform，还是保存系统的逻辑状态再重建？

这个所谓“线程安全”的方案实际上在哪个地方产生 Race Condition？

如果完全没有基础知识，面对 AI 输出，人甚至不知道应该怀疑哪里。

于是形成一个看似矛盾的现象：

AI 让实现知识变得更容易获得，同时让判断知识变得更加重要。

以前，一个不会某项技术的人可能根本无法生成复杂方案。

以后，他可以轻松生成。

这意味着：

错误方案也第一次可以被大规模、低成本、极其专业地生成。

因此“能得到答案”不再足够。

真正重要的是：

能不能判断答案。

8应该怎样准备接下来的几年

面对一个能力边界每几个月都可能发生明显变化的技术，最危险的策略之一，是试图一次性预测终局。

比如：

2028 年 AI 一定会怎样。

游戏程序员一定还会存在。

两年后一定已经不需要程序员。

这些预测都高度依赖尚未发生的技术突破、产品形态、成本、法规和组织方式。

更稳健的方法是建立一套持续适应能力变化的系统。

8.1把 AI 变成默认工作方式

不要把 AI 理解成：

遇到不会的问题才打开的高级搜索引擎。

更好的问题是：

在每一种工作中，人和 AI 应该怎样分工？

设计一个系统之前，可以让模型找反例和架构风险。

实现过程中，可以让 Agent 编写第一版代码和测试。

完成以后，可以让另一个 Agent Review。

遇到 Bug 时，可以让 AI 分析日志、调用栈和相关代码。

准备重构时，可以让 AI 先建立依赖地图。

目标不是“任何事情都让 AI 做”。

而是逐渐积累：

什么任务适合交出去，什么任务必须自己抓住。

这本身会成为一种新的专业经验。

8.2建立自己的 AI 能力雷达

不要只靠新闻判断 AI。

新闻天然倾向展示最惊人的成功案例。

更有价值的方法，是建立一组来自自己真实工作的固定任务。

例如：

每隔一段时间，重新用最新 Agent 完成同样任务。

不要只问：

新模型 Benchmark 高了多少？

而是观察：

那些以前必须自己解决的问题，现在有多少已经能够可靠交给 AI？

真正与职业有关的，是自己的能力边界变化图。

8.3把“可验证性”当成一等工程能力

如果 AI 的自主程度取决于可验证性，那么未来优秀的软件架构应该不仅追求：

可维护、

可扩展、

高性能，

还应该追求：

可被机器验证。

这意味着更多关注：

Unit Test、

Integration Test、

PlayMode Test、

Runtime Assertion、

Replay、

Screenshot / Video Regression、

Performance Benchmark、

Telemetry、

Deterministic Simulation。

GameDevBench 中视觉反馈能够显著改善 Agent 表现，本质上也说明了这一点：如果 Agent 看不到真实结果，它只能根据文本和代码推测世界发生了什么。⁸

未来非常强大的 AI 工作流，未必是：

Prompt 写得特别复杂。

而可能是：

项目本身为 Agent 提供了极其优秀的反馈环境。

8.4保留真实系统里的深度

越是输入输出清晰的问题，越容易高度自动化。

而实时游戏世界恰恰充满：

连续状态、

异步事件、

用户输入、

物理模拟、

动画、

网络、

GPU、

不同帧率、

不同平台、

不可预测的玩家行为。

因此，对实时系统的深度理解仍然非常值得投资。

原因不是：

AI 永远学不会这些。

而是：

即使 AI 能生成实现，这些系统仍然需要复杂的验证和整合。

而能够理解整个运行世界的人，可以让 AI 发挥远大于单个“Prompt Engineer”的价值。

8.5持续发布，而不是只持续生成

生成能力越强，Demo 会越廉价。

因此真正发布产品的重要性反而会上升。

AI 可以模拟用户反馈。

但真实玩家是否：

看懂系统、

愿意继续玩、

愿意第二天回来、

愿意推荐给朋友、

在完全意外的地方卡住，

最终仍需要进入真实世界才能知道。

这形成一个非常重要的区别：

生成是在扩张可能性，发布是在收缩不确定性。

未来真正稀缺的，可能并不是“拥有最多 Demo 的人”。

而是：

能够最快地把假设送入现实，并根据现实修正方向的人。

8.6不要预测未来，持续校准未来

今天最危险的两种心态分别是：

AI 不可能真正影响我的领域。

以及：

AI 马上什么都能做，所以今天学什么都没有意义。

两者都试图找到一个永久答案。

但对于快速移动的技术，更好的方法是：

不用提前知道 2030 年的答案。

只需要确保：

当能力边界移动时，自己能够足够早地看到。

9不要和 AI 比谁做得更快

如果把人的价值定义为：

比 AI 更快地写出代码。

这场比赛大概没有什么值得期待的未来。

机器在复制、搜索、生成和并行执行上的经济性，本来就不会停留在人类的速度附近。

真正值得问的是另一个问题：

如果执行能力突然变得极其廉价，一个人可以用它创造什么以前根本没有能力创造的东西？

过去，一个独立开发者可能因为时间有限，只能放弃：

复杂 AI、

大量内容、

精细工具、

完整自动测试、

多语言、

持续运营。

未来，一个人可能拥有过去一个小团队级别的执行能力。

这既是一种威胁，也是一种巨大的杠杆。

关键区别在于：

谁只是被更快的执行速度替代，

以及：

谁能够把这种执行速度组织成更大的创造能力。

当“能不能做出来”逐渐不再是主要问题之后，新的问题会越来越清晰：

为什么做？

做什么？

什么不做？

做到什么程度？

如何知道它真的成立？

什么值得长期维护？

什么值得存在？

AI 会越来越擅长回答：

How？

甚至可以参与回答：

What？

但一个作品最终为什么值得被创造，仍然不是单纯增加推理 Token 就能够得到唯一答案的问题。

因为世界不存在一个统一的目标函数，能够证明：

某一种游戏一定应该存在；

某一种艺术风格一定更好；

某一种人生选择拥有最高 Reward。

当生成一种可能性的成本趋近于零时，

可能性本身就不再稀缺。

真正稀缺的是：

从无数可以被实现的可能性中，知道哪一个值得变成现实。

这或许就是 AI 时代“创造”这个词正在发生的变化。

以前，创造首先意味着：

我能把它做出来。

以后，它可能越来越意味着：

世界上有一百万种东西都可以被做出来，而我选择了这一种。