Vibe Coding 实战 — 用 Kimi K3 一条提示词生成可玩的 HTML 游戏

1. 人们对一条提示词 HTML 游戏的常见误解

大多数「AI 做了个游戏」的视频追求的是惊喜感，而不是一个能发给客户的文件。提示词要的是俄罗斯方块或 Flappy Bird——GitHub 上已有成千上万份代码的游戏——模型照着一个熟悉的模式复述一遍。这只能证明自动补全可用，不能证明你可以委托 AI 构建一个独一无二的、可探索的世界，还能在不搭进第二个下午修补时间的前提下拿到可玩的东西。

第二个误解是把「单 HTML 文件」当成派对把戏，而不是交付约束。单文件交付物意味着没有打包工具、没有 node_modules、不用和托管团队争论部署管线。它也意味着模型必须把渲染、输入、音频（如果有）和状态全部装进一个文档。当这个约束成立时，产出物的可分享性就和 PDF 一样：发文件、打开、玩。

第三个误解是把 vibe coding 等同于放弃判断。Andrej Karpathy 对 vibe coding 的定义——用自然语言描述结果，让模型产出代码——依然把通过/不通过的标准留给你。对浏览器游戏，这条标准很具体：能走动吗？NPC 会动吗？光照会变吗？有东西可发现吗？如果一条提示词之后答案都是「是」，你有一个演示；如果答案是「差不多，等我修一下摄像机」，你有一份作业。

装饰艺术小镇演示之所以重要，是因为它通不过「轻松复述」这道测试。带昼夜光照、体积云阴影与可收集火花的等距可漫步城市，不是编码基准里的默认课后题。看着 K3 在 Floatboat 里把这一整套东西以单个 HTML 文件输出，会刷新你对一次 vibe coding game 会话能交付什么的预期，见 Floatboat 演示视频。

2. 一条提示词游戏流水线：四个阶段

一个可交付的一条提示词 HTML 游戏，不是「打一句话然后祈祷」。它是一条短流水线，每个阶段都为拦截某种特定的失败模式而存在。跳过任何一个阶段，你得到的就是浏览器里活不过三秒的惊艳截图。

2.1 阶段一——先约束世界，再约束技术栈

提示词应该先写玩家动词：走、收集、对话、防守。然后是世界类型：等距、俯视、横版。然后是美学风格：装饰艺术，而不是「漂亮的城市」。最后才提交付：单个 HTML 文件、无外部资源、Chrome 可运行。前端能力再强的模型——Kimi K3 以 1,679 分位居 Arena.AI Frontend Code Arena 第一——也需要这个顺序，因为一个没有边界的「做个酷炫小镇」提示词，只会招来没有输入循环的装饰性场景，据 VentureBeat 报道。

这个阶段为什么重要：每个缺失的动词，都会变成你日后要手写补上的功能。装饰艺术小镇演示的动词是「走」和「发现」；各个系统（市民、云、火花、昼夜）都挂在这两个动词上，而不是漂浮在电影背景板里。

2.2 阶段二——要可玩的系统，不要场景描写

「漂亮的光照」不是系统，带投影体积云的昼夜循环才是。「热闹的街道」不是系统，14 位沿路径漫游的市民才是。当你 vibe code 一个浏览器游戏时，要逼着提示词列出可数的系统：N 个 NPC、N 个可收集物、具名的循环、具名的摄像机。可数项就是文件落地后你用 60 秒就能验收的东西。

这个阶段为什么重要：生成式模型热爱氛围感，独立创业者需要的是验收标准。可数项把 vibe 变成清单，而且不杀死 vibe。

2.3 阶段三——在一个能直接打开文件的工位里生成

AI 游戏演示的历史性失败模式是复制粘贴表演：模型把代码打印进聊天，你粘进编辑器，路径报错，模块拒绝从 file:// 加载，演示当场去世。在 Floatboat 里、选中 Kimi K3 之后直接生成，就把这个循环折叠掉了——指令落地的位置、HTML 产出的位置、你打开结果的位置是同一个 agent 工作区，不用申请 Moonshot API key，也不用另开一个编码 IDE，参见 Kimi K3 in Floatboat。

这个阶段为什么重要：只有「提示词」到「玩起来」之间的人工步骤接近于零，「一条提示词」才算数。工具链摩擦正是「一条提示词」悄悄变成十二条的地方。

2.4 阶段四——对着可数项试玩，再决定迭代还是交付

打开 HTML。走一走。等到黄昏。看一眼云影。找一枚火花。如果四个系统里三个能跑，交付演示、排期打磨。如果是摄像机坏了，不要从零重写提示词——发一条外科手术式的补充指令：「保留小镇，修好北侧广场楼梯的碰撞。」这仍然是 vibe coding，只是带回归底线的 vibe coding。

这个阶段为什么重要：「一次成型」的迷思只会造出假演示或烂尾项目。真实的流水线都假定有一个简短的验证步骤。

这张表就是全部方法论。其余的一切——模型选择、装饰艺术细节、体积云——都是这四道闸门里的载荷。

3. 日历驱动配置对 Vibe Coding 改变了什么

聊天式 vibe coding 从你想起打开聊天窗口那一刻开始；日历驱动的工作从事件到达那一刻开始。当「做个原型」不再是周末爱好、而是周二下午两点对客户的承诺时，这个差别就有了分量。

在 agentic calendar 上，「原型截止」或「设计评审」事件可以触发与构建装饰艺术小镇相同的 K3 视觉推理路径：生成或重新生成 HTML、打开它、截一帧、对照需求简报，并在你进入会议之前把备注留在事件工作区里。你不是在让模型帮你管日历，而是让日历决定昂贵的视觉模型什么时候跑。

成本纪律也体现在这里。K3 的常开最大推理适合一次性生成带光照与 agent 的世界，不适合改按钮文案。让 K3 负责生成爆发、让更便宜的编码档位负责后续修补，就像给一个小工作室配人：主美出首个可玩版本，初级美工做打磨——只不过两个档位都在同一个模型选择器里。

关于日常会议工作中什么时候用 K3、什么时候用 K2.7 Code 的更细映射，参见 Kimi K3 模型详解。游戏演示是压力测试；日历路由才是日常习惯。

4. 在你自己的工作流里搭起来

如果你已经在用 Floatboat，在 agent 工作区的模型选择器里选中 Kimi K3 即可。无需 API key、无需绕道 OpenRouter、没有单独的「游戏模式」。按第 2 节的阶段顺序写提示词：动词、世界、美学、可数系统、单文件交付。示例结构（自由改编）：

用一个自包含的 HTML 文件构建可漫步的等距装饰艺术风小镇。玩家可以在街道上行走。完整的昼夜循环。14 位漫游市民。投射实时阴影的体积云。隐藏 10 枚可收集的金色火花。无外部资源。必须在浏览器中打开文件即可运行。

然后按可数清单试玩。如果你是在为客户准备这一切，把 HTML 挂到负责评审的日历事件上，让下一次 agent 运行在会议开始前——而不是会议进行中——打开文件。

如果你是 Floatboat 新用户：下载桌面应用，连接你已经在用的日历，为「交互式原型」创建一条 agent 管线，并把 K3 设为该管线的模型。其他事务保持 Auto Mode 开启，避免把最大推理 token 烧在琐事分诊上。把第一周当作校准期：用不同美学跑两条短提示词，沿用同一份可数清单，记录哪些失败是提示词问题、哪些是模型噪声。这份记录会成为你日后接客户活的个人验收套件。

什么时候不该走这条路：交付多人在线生产级游戏、Unity/Unreal 项目，或任何需要鉴权后端与资产管线的东西。一条提示词 HTML 游戏适合可探索的演示、可演示给客户的玩具、教学工具和面向客户的原型。把它当成完整工作室生产的替代品，正是 vibe coding 背上那份本不该有的坏名声的原因。

5. 从演示小镇到可复用的原型习惯

装饰艺术小镇能上头条，是因为它视觉密度高。真正持久的资产是习惯：一条带约束的提示词、一个文件、一次试玩、一个拥有下次评审的日历档期。内化了这个循环的独立创业者，不再把交互原型当「也许下季度再说」，而是像对待幻灯片一样对待它——只要需求清晰，开会前就能产出一个。

三种常见场景套用同一习惯即可，不必假装每个需求都需要一个完整游戏。销售原型让潜在客户直接体验交互，而不是在幻灯片里听你描述——可漫步的产品空间、店铺布局或新手引导流程，打包成 HTML。设计评审产物让相关方在意见固化到静态设计稿之前，先有点可点的东西。教学演示让工作坊听众打开一个文件，立刻感受到你正在讲解的机制。每种情况的成功指标都一样：一个不在你脑子里的人，能在一分钟内玩到这个点子。

搜索需求围绕 vibe coding、one prompt game、single file HTML game 这类词聚集，因为人们想证明这个循环足够短。装饰艺术的短片是证明；挂上日历的 HTML 才是操作系统。如果你只追短片，你会永远在重新生成小镇；如果你把文件挂到拥有决策权的事件上，演示就变成了工作产物。

这就是爆款短片之下安静发生的变化。短片证明 K3 能 vibe code 出一个世界；工作流证明你能把「给我看点能玩的」变成可复现的交付物，而不是一年一遇的奇迹。保住可数项。保住单文件。让模型待在那个已经承载你整周工作的工位里。

6. 结语

一条提示词 HTML 游戏在三件事同时对齐时才是真的：一条编码了动词与可数系统的提示词、一个原生具备视觉与前端实力的模型、一个无须寻宝就能打开文件的工位。Floatboat 内置的 Kimi K3 在一个带昼夜光照、漫游市民、云影与隐藏火花的等距装饰艺术小镇上越过了这条线——不是幻灯片，而是一个浏览器可玩的 HTML 文件。抄走这条流水线，而不只是美学。下一条提示词，应该是你自己的。