使用 Amazon Quick 以对话方式构建游戏原型并发布为团队应用的实践

摘要：本文介绍了在 Amazon Quick 中通过自然语言对话，依次构建益智游戏、抽卡概率工具、横版闯关与 Three.js 第一人称射击原型，并借助 apps in Amazon Quick 将其发布为带团队排行榜的应用的完整过程，同时总结了该方式在游戏行业原型验证中的适用场景与边界。

一、背景与需求

在游戏研发的真实场景中，一个玩法或数值方案从想法到可以上手试玩，往往需要经过需求评审、研发排期、开发与联调多个环节，而大量想法在验证之后会被放弃，这使得前期试错的成本居高不下。策划和运营人员通常非常清楚自己想验证什么，例如“软保底从第几抽开始更合理”“大保底对重度付费玩家的影响有多大”，但他们往往不写代码，只能依赖研发人员临时编写脚本或搭建内部工具。

与此同时，解决方案架构师在向游戏客户介绍生成式 AI 能力时，也常常面临另一类挑战：静态的幻灯片和概念讲解难以让客户直观感受到“从需求到可用产物”的速度，而客户真正关心的是这项能力能否在自己的业务流程中落地。

基于以上背景，本文希望验证一种工作方式，它需要满足以下要求：

• 使用自然语言描述需求，不要求使用者编写代码
• 每一次修改都能立即预览和试玩，支持多轮迭代
• 原型验证完成后，可以直接发布给团队使用，而不必另行部署
• 支持团队共享的数据，例如多人参与的排行榜
• 对产物的能力边界有清晰认识，避免把原型误当作正式产品

二、为什么选择 Amazon Quick

Amazon Quick 是一项由 AI 驱动的服务，用户通过自然语言对话即可完成任务自动化、数据分析、研究以及 Web 应用构建等工作。对于本文的场景，选择 Amazon Quick 主要基于以下三方面的考虑。

能力匹配：apps in Amazon Quick 支持通过对话描述需求，由 Amazon Quick 实时生成可运行的应用，并提供实时预览，用户可以在后续对话中持续修改。这与“边玩边改”的原型验证方式高度契合。

内置数据与身份能力：每个应用都可以使用内置的键值存储，分为仅本人可见的私有存储和所有访问者可见的共享存储，无需额外配置数据库；应用还可以通过用户身份接口获取当前登录用户信息。这两项能力正好构成团队排行榜所需的基础。

安全与分发：应用继承 Amazon Quick 的安全模型并支持单点登录，原型验证完成后可以一键发布并分享给团队，省去了自行搭建托管环境、配置身份认证的工作。

截图 1 展示了本次实践所使用的 Amazon Quick 桌面应用工作界面。

[截图 1：Amazon Quick 桌面应用工作界面 — 生成 Three.js 射击原型后截取]

截图说明：界面自左向右分为四个区域。左侧为导航栏，提供对话、动态、资料库、应用与空间等入口；中部为与 Amazon Quick 的对话面板，作者在这里以自然语言提出需求，Amazon Quick 的回复中包含文件结构说明与可点选的后续操作选项；右侧为会话标签页，生成的原型在这里直接渲染并可交互试玩，图中正在运行的是方块突击射击原型的开始界面，顶部标签栏中还保留着横版闯关等其他原型；最右侧为工作区面板，列出了本地文件夹与已安装的技能等资源。截图中的历史会话列表已做模糊处理。

三、整体功能亮点

本次实践在一次连续对话中完成。作者只负责提出需求、试玩和做选择，原型、应用代码与测试脚本均由 Amazon Quick 生成，共产出 5 个交互式原型和 2 个 Amazon Quick 应用，主要亮点如下：

• 以益智游戏 2048 作为起点，在后续对话中追加了 3×3 至 6×6 的棋盘尺寸切换
• 构建抽卡概率模拟器，支持软保底、硬保底、UP 概率与大保底等规则，并输出 P50、P90、P99 等分位指标
• 在模拟器基础上扩展出卡池 A/B 对比工具，自动生成两套规则的差异结论
• 构建横版闯关原型，采用原创角色与美术，规避第三方知识产权风险
• 基于 Three.js 构建第一人称射击原型，包含波次生存、两类敌人行为和命中判定
• Amazon Quick 主动编写无头自动化测试脚本驱动机器人试玩，并依据测试结果调整关卡与难度
• 将射击原型转换为 Amazon Quick 应用，增加基于共享存储的团队排行榜
• 生成独立的英文版应用，便于面向海外团队演示

从首个原型开始生成（20:19）到英文版应用构建并保存（21:59），整个过程约 100 分钟。需要说明的是，这一时间为实际经过的时间，包含了作者试玩、讨论和决策的时间，并非单纯的生成耗时。

四、总体架构

整体架构如架构图 1 所示。

[架构图 1：使用 Amazon Quick 从对话原型到团队应用的总体架构]

图示说明：图中自左向右分为四个区域。左侧为作者（解决方案架构师或游戏策划），通过自然语言向 Amazon Quick 对话提出需求，并与对话内生成的交互式原型（2048、抽卡概率模拟器、卡池 A/B 对比、横版闯关、Three.js FPS）往返试玩与反馈；原型下方的无头自动化测试负责批量跑局，将发现的问题与调参建议回写到原型。原型定稿后进入 apps in Amazon Quick，依次完成构建、预览、发布与分享。已发布的应用运行于右侧的应用沙箱中，沙箱内的 React 界面、Three.js 游戏引擎与排行榜组件连接内置应用存储（共享）与用户身份；最右侧的团队成员（策划、美术、研发、运营）访问已发布的应用。图中橙色表示 Amazon Quick 提供的能力，灰色表示应用自身的代码组件（同样由 Amazon Quick 生成），蓝色表示团队成员。

该架构的一个关键设计取舍在于，没有一开始就直接构建应用，而是先在对话中生成轻量的交互式 HTML 原型。原型阶段迭代成本最低，适合快速试错和调整玩法；只有当玩法得到确认、并且出现了“多人共享数据”或“团队长期使用”的需求时，才将其转换为 Amazon Quick 应用。这种两阶段方式既保留了探索阶段的速度，又让最终产物具备身份认证、持久化存储和分发能力。另一个取舍是将游戏引擎与排行榜拆分为独立模块：引擎只负责对局逻辑，在一局结束时通过回调输出成绩；排行榜模块负责身份识别、成绩比较与读写存储，两者互不依赖，便于后续替换为其他游戏。

五、核心功能模块与效果演示

本章按照构建顺序介绍各个模块，重点说明每个模块解决的问题、实现要点以及在迭代中发现的问题。各模块的运行截图附在对应小节中，Amazon Quick 的整体工作界面可参考第二章的截图 1。

5.1 益智游戏原型：2048

2048 作为第一个原型，用于验证“一句话需求生成可玩游戏”这一基础能力。初版包含键盘与触屏操作、计分、最高分记录、最近 20 步撤销以及合并动画。随后作者通过一次追加需求，增加了 3×3、4×4、5×5、6×6 四种棋盘尺寸，数字字号和格子间距会随棋盘自动调整，每种尺寸的最高分分别记录。这一步验证了对话式迭代的另一项关键能力：在已有产物上做增量修改，而不是每次重新生成。

5.2 数值工具：抽卡概率模拟器与卡池 A/B 对比

抽卡概率模拟器是本次实践中与游戏行业业务关联最紧密的模块。模拟器将单抽概率建模为：第 n 抽概率等于基础概率加上软保底起始后的线性提升值，并在硬保底处取 100%。首个五星出现位置的分布通过解析方式精确计算，而“获得 N 个 UP 角色所需总抽数”的分布由于叠加了 UP 概率与大保底规则，采用 20,000 次蒙特卡洛模拟得到。

模拟器提供 4 个预设卡池（标准限定池、渐进保底池、纯概率无保底、良心池），输出综合出率、平均每个五星所需抽数、P50 中位数、P90 与 P99 分位以及预算内达成概率。在此基础上，A/B 对比工具将两套规则的累计概率曲线与总抽数分布叠加在同一张图中，并以表格逐项标出对玩家更友好的一方，同时自动生成一句话结论。

这一工具揭示了一个对运营决策很有价值的现象：两套规则的平均出率可能接近，但分布尾部差异显著。保底机制的主要作用在于截断运气最差玩家的花费上限，而不是提高平均值。策划和运营人员可以直接拖动滑块验证不同方案，无需等待研发编写脚本。

截图 2 展示了卡池 A/B 对比工具中“累计出第一个 5★ 的概率”曲线，其中卡池 A 为标准限定池，卡池 B 为纯概率无保底。

[截图 2：卡池 A/B 对比 — 累计出第一个 5★ 的概率]

截图说明：实线为卡池 A（基础概率 0.6%，第 74 抽起软保底，第 90 抽硬保底），虚线为卡池 B（固定 1%，无保底）。在前 70 余抽中，A 的累计概率反而低于 B；进入软保底区间后，A 的曲线陡然拉升，并在第 90 抽达到 100%，而 B 的曲线平缓上升，需要数百抽才接近 100%。

5.3 横版闯关原型与自动化测试

横版闯关原型包含一个约 200 格长的完整关卡，提供问号方块、道具、可踩踏敌人、连踩加分、可变高度跳跃、冲刺、存档点、倒计时与终点旗杆等经典机制，代码约 500 行。作者最初的需求是参照一款经典横版闯关游戏制作 Demo，Amazon Quick 主动指出该游戏的角色、名称与美术属于第三方知识产权，并在生成时只保留了横版闯关这一通用玩法，角色与美术全部采用原创设计，以降低对外演示时的合规风险。

由于 Amazon Quick 无法直接查看原型渲染出的画面，它在交付前主动编写了无头测试脚本，用一个简单的规则机器人自动试玩。测试中，机器人在关卡中段一处敌人密集区域反复阵亡；Amazon Quick 据此删减了该区域的两个敌人，调整后机器人在 1,562 帧内通关且没有阵亡。这说明自动化测试可以帮助发现关卡难度问题，但机器人的行为与真实玩家存在差异，最终的手感仍需人工确认。

5.4 Three.js 第一人称射击原型

射击原型基于 Three.js 构建，场景为带围墙的竞技场，包含实时阴影、雾效以及柱子、矮墙、木箱等掩体，中央高台可以逐级跳上。武器系统包含 30 发弹匣、换弹动画、枪口火光、弹道线与后坐力，移动和跳跃会扩大散布，准星会随之张开；爆头一击致命，命中身体需要 3 次。

敌人分为两类：红色远程机器人会检测视线、横向移动并在开火前闪烁面罩作为提示，子弹可见且可以躲避；橙色冲锋机器人从第 2 波开始出现，会贴近玩家进行近战攻击。武器模型使用独立场景渲染在最上层，避免贴近墙体时出现穿模。

Amazon Quick 同样编写了无头测试，在模拟环境中跑通了开局、刷怪、敌人开火、玩家受伤与阵亡、击杀、换弹和拾取血包的完整流程。测试中一个不还击的机器人在第 1 波第 820 帧即阵亡，Amazon Quick 据此下调了敌人子弹伤害并延长了开火间隔，在调整后的一次复测中，同一机器人坚持到了第 1,011 帧。由于敌人的刷新位置带有随机性，单次测试结果只用于判断难度调整的方向。

截图 3 展示了 Three.js 射击原型在对话中的对局画面。

[截图 3：方块突击 Three.js 射击原型 — 第 1 波对局画面]

截图说明：画面上方显示波次与剩余敌人数量、分数与击杀数，下方显示生命值与弹匣余量；画面中央的红色弧形为受击方向提示，四周的红色晕影表示刚刚受到伤害。顶部提示条显示当前环境无法锁定鼠标，原型已自动切换为拖动转视角。

5.5 从原型到应用：团队排行榜

当作者提出“部署成应用”的需求后，Amazon Quick 先说明了两种部署方式（发布为 Amazon Quick 应用，或导出为独立网页自行托管）的取舍，在作者选择“Quick 应用 + 团队排行榜”后，将射击原型转换为 Amazon Quick 应用，主要完成了以下工作：

• 将游戏逻辑封装为独立的引擎模块，暴露创建与销毁接口，并在一局结束时回调成绩数据
• 将 Three.js 从外部加载改为随应用本地打包，构建产物为单个约 1,086 KB 的文件（gzip 压缩后约 302 KB）
• 由于应用运行在沙箱 iframe 中，鼠标指针锁定可能不可用，因此实现了自动回退：无法锁定时改为按住鼠标拖动转视角，方向键同样可以转向
• 基于内置共享存储实现团队排行榜，以用户邮箱作为键，只保存个人最高分
• 通过用户身份接口获取当前用户姓名，玩家无需手动输入昵称

成绩提交的核心逻辑如下，只有当本局成绩超过个人历史最高分时才会写入共享存储：

export async function submitScore(me: Me, s: RunStats): Promise<boolean> {
    const prev = await getSharedItem({ tableName: TABLE, key: me.key });
    const old = parse(me.key, prev?.item?.value);
    if (old && old.score >= s.score) return false;
    const value = { name: me.name, score: s.score, wave: s.wave,
                    kills: s.kills, acc: s.acc, ts: Date.now() };
    await putSharedItem({ tableName: TABLE, key: me.key,
                          value: JSON.stringify(value) });
    return true;
}

排行榜组件展示前 15 名并为前三名标注奖牌，当前用户所在行会高亮显示；若当前用户未进入前 15 名，会在列表下方单独显示其排名。

截图 4 展示了英文版应用 Block Assault FPS 的团队排行榜。

[截图 4：Block Assault FPS 团队排行榜 — 团队成员试玩后截取]

截图说明：排行榜共记录 5 名玩家，前三名均坚持到第 2 波，最高分为 1,350 分；当前用户所在行以橙色高亮并带有 YOU 标记，玩家姓名由用户身份接口自动获取。为保护个人信息，截图中其他成员的姓名已做模糊处理。

5.6 多语言版本

在中文版应用完成后，作者要求生成英文版本。Amazon Quick 提取了游戏中所有面向用户的文字，包括开局说明、界面信息、波次提示、击杀提示、暂停与结算界面以及排行榜文案，逐项翻译后生成了一个独立的英文应用。中文版应用保持不变，两个应用的排行榜相互独立。

从以上各模块可以看出，同一套对话流程既能产出面向策划与运营的数值分析工具，也能产出可直接在团队内部传播的互动应用。对于解决方案架构师而言，可以在客户交流中现场追加一个需求，例如“增加二段跳”或“再做一关”，让客户直观看到迭代速度。

六、关键提示词与交互设计

本次实践中，作者没有编写任何代码，也没有一次性给出完整需求，而是采用逐步追加的方式推进。以下为作者在对话中的实际输入（节选）：

• “你能给我做一个 2048 游戏么”
• 选择追加“棋盘大小切换”
• 选择构建“抽卡概率模拟器”，随后选择“两个卡池并排对比”
• “能否用 Quick 写一个经典横版闯关游戏的 Demo”（原话中点名了一款知名游戏，此处做了泛化处理）
• “能否利用 threejs 做一个简单的 fps 游戏”
• “我可以将它部署成为一个 app 么”，随后选择“Quick 应用 + 团队排行榜”
• “给我翻译成英文版本，然后做成 Quick 应用 + 团队排行榜”

从这一过程中可以总结出三条实践经验。第一，增量式需求比一次性的长需求更可控，每一步都能获得可试玩的产物，方便及时纠偏。第二，在关键节点由 Amazon Quick 给出选项供作者选择，例如后续功能、部署方式，可以减少需求表达上的歧义。第三，在本次实践中，Amazon Quick 主动说明了产物的边界，例如第三方知识产权风险、沙箱中的指针锁定限制以及排行榜缺少防作弊机制，并在交付前对产物进行了自动化验证；读者在复用该方式时，也可以在需求中明确提出这两项要求，而不是只要求交付代码。

七、部署与接入

与传统方式相比，本方案不需要准备代码仓库、构建流水线、托管环境或身份认证配置，应用的构建产物、内置存储和访问控制都由 Amazon Quick 统一管理，作者只需在对话中提出需求并完成预览、发布与分享三个动作。将对话中的原型发布为团队可用的应用，按下列步骤进行：

• 生成并试玩原型：在 Amazon Quick 对话中描述需求，生成交互式原型，试玩并通过追加需求完成迭代
• 转换为应用：在对话中提出转换为应用的需求，并说明需要的数据能力，例如“团队排行榜”，Amazon Quick 会创建应用并完成构建
• 预览与测试：在应用预览中试玩至少一局，确认操作手感和排行榜写入正常
• 发布：将保存的版本发布，发布前该版本仅对应用作者可见
• 分享：将已发布的应用分享给账户内所有用户；如需分享给指定人员，可以在应用的分享设置中添加

在实际验证中，英文版应用发布并分享后，团队成员通过各自的 Amazon Quick 账号访问应用并完成对局，排行榜自动识别玩家姓名，共记录了 5 名玩家的个人最高分，其中最高分为 1,350 分（坚持到第 2 波），如截图 4 所示。

八、成本与限制

在成本方面，本方案没有引入额外的 AWS 基础设施，应用的构建、存储与分发均在 Amazon Quick 内完成，费用由 Amazon Quick 的订阅费用构成。根据 Amazon Quick 定价页面（截至 2026 年 10 月）的说明，各订阅计划都包含构建 Web 应用的能力，主要计划如下：

• Free：0 美元/用户/月，限 1 名用户，适合个人体验与原型验证
• Plus：按年付费 20 美元/用户/月（按月付费 25 美元），最多 300 名用户，提供团队共享空间与用户管理，适合本文这类团队内部共享的场景
• Max：按年付费 100 美元/用户/月（按月付费 125 美元），在 Plus 的基础上提供 5 倍的使用量与索引存储
• Professional / Enterprise：分别为 20 美元/用户/月和 40 美元/用户/月，另加每个账户每月 250 美元的基础设施费，提供 RBAC、单点登录、数据主权控制与 24/7 AWS Support 等企业级治理能力

Amazon Quick 以 agent 小时计量 AI 功能的使用量，涵盖对话、研究、产物生成以及用户创建的 AI 应用等，按秒计量，并且只在 Amazon Quick 实际处理请求时计入。使用量与任务复杂度以及所选的推理模式（Fast、Balanced、Smart）相关：本文这类多轮生成代码、构建应用并运行自动化测试的任务属于较复杂的任务，消耗速度通常高于简单问答。以 Professional 与 Enterprise 计划为例，每用户每月分别包含 8 小时和 18 小时的 agent 小时额度；Professional 计划目前不支持超额使用，Enterprise 计划超出部分按每 agent 小时 3 美元计费，管理员可以通过限额策略控制超额。用户可以在 Mission Control 的 Activity 页面查看自己的使用量。对于希望先行验证本文方案的团队，Amazon Quick 为新客户提供 Enterprise 计划 30 天免费试用，每个账户最多覆盖 25 名用户，试用期内免收订阅费与基础设施费。实际费用以定价页面的最新说明为准。

在使用该方式时，需要注意以下限制：

• 产物定位：生成的是单页原型和轻量应用，适合玩法验证、数值分析和演示，不能替代 Unity 或 Unreal Engine 等正式游戏引擎，也不支持多人实时联机
• 交互限制：应用运行在沙箱 iframe 中，鼠标指针锁定可能不可用，第一人称射击的操作手感会弱于独立网页
• 数据可信度：排行榜成绩由客户端写入共享存储，缺少服务端校验与防作弊机制，适合团队内部娱乐，不适合有奖竞赛
• 验证方式：自动化测试只能验证逻辑正确性，画面效果与操作手感仍需人工试玩确认
• 知识产权：生成游戏类原型时应避免使用第三方角色、名称和美术资源，尤其是在对外演示场景中

九、总结

本文介绍了如何在 Amazon Quick 中通过自然语言对话，依次构建 2048、抽卡概率模拟器、卡池 A/B 对比、横版闯关与 Three.js 第一人称射击原型，并将射击原型发布为基于内置共享存储与用户身份的团队排行榜应用，同时生成了独立的英文版本。

这种方式让不写代码的策划和运营人员能够自行完成玩法与数值的初步验证，把从想法到可试玩原型的过程从研发排期缩短到一次对话之内；对于解决方案架构师，它提供了一种可现场交互、可当场修改的客户演示方式。读者可以基于本方案进一步扩展，例如将抽卡模拟器发布为团队共享的数值工具，或结合 Amazon Quick Sight 可视化嵌入真实运营数据，构建面向游戏运营的内部工具。

➡️ 下一步行动：

相关产品：

• Amazon Quick — 人工智能助手，用于研究、业务洞察、自动化和无代码应用程序构建

相关文章：

• 基于Amazon Quick与Amazon Bedrock AgentCore打造对话式 FinOps助手
• 项目经理的 AI 提效实践——Amazon Quick × 飞书：打通碎片化工具链，构建 AI 整合入口
• 零代码快速体验 Amazon Quick 操作飞书/Lark
• 基于 Amazon Bedrock AgentCore Runtime 部署 Apache Doris MCP Server为 Quick Suite 等 AI 客户端提供原生数据分析能力
• 自己的工具自己控：MCP Server、Amazon Bedrock AgentCore、Quick Suite集成指南

十、相关链接

• What is Amazon Quick?
• Build web applications with apps in Amazon Quick
• What you can build with apps in Quick
• Getting started with apps in Quick
• Amazon Quick 定价
• Introducing Amazon Quick Suite（What’s New）
• Three.js 官方文档

*前述特定亚马逊云科技生成式人工智能相关的服务目前在亚马逊云科技海外区域可用。亚马逊云科技中国区域相关云服务由西云数据和光环新网运营，具体信息以中国区域官网为准。

本篇作者

AWS 架构师中心：云端创新的引领者 探索 AWS 架构师中心，获取经实战验证的最佳实践与架构指南，助您高效构建安全、可靠的云上应用