Working Intent / Experiment 001

从一句请求,到一套可以运行的游戏意图

Kimi K3 构建 Cozy Harbor Delivery 的完整生成、修复与验证记录

原始短提示默认自动思考完整可见 CoTWeb 可玩

01结论先行

模型没有把任务停留在“解释怎么做”。它把一句只给出题材、视角、玩法类别、引擎和目录的请求,补全成了一套可执行的工作意图,然后据此创建工程、运行 Godot、修复报错并完成验证。

37段可见思考
58次工具调用
1,797行工程代码
11 / 11独立 smoke checks

这轮最值得观察的不是“模型有没有猜中唯一正确设计”,而是:面对欠规格请求,它形成了一个足够连贯的解释,使后续几千个实现决定可以彼此兼容,并最终落到一个能玩的 artifact 上。

02原始请求

Build Cozy Harbor Delivery, a 2D top-down delivery routing mini-game in Godot 4 at /workspace/game/.

这 15 个英文词明确给了五件事:名称、2D 俯视视角、配送路径玩法、Godot 4,以及输出目录。它没有规定玩家控制什么、地图结构、路线优化目标、失败条件、美术资产、回合长度或验证方式。

03它如何解释“Cozy Harbor Delivery”

Explicit

请求明说的

2D、top-down、delivery routing、mini-game、Godot 4、指定目录。

Inferred

从词义推出来的

Cozy 对应暖色、低惩罚和轻松节奏;Harbor 对应水岸、码头、灯塔和海鸥;Routing 对应同时携带多个包裹并决定配送顺序。

Committed

模型自行承诺的

货车自由移动、自动取件、容量 3、鲜度与小费、150 秒工作日、紧急包裹导航箭头、程序化画面与声音。

形成的核心玩法

玩家驾驶一辆小货车到港口仓库取件;最多携带三个包裹;每个包裹持续失去鲜度,越快送达小费越高。玩家需要在多个目的地之间选择顺序,同时用连续配送积累 streak。为了保持“cozy”,时间到只结算当天,不设置硬失败。

这里真正的工作意图

做一个低压力、可重复、但仍需要路线排序的港口配送游戏。 这句话不是原始 prompt 的复述,而是模型把风格约束和玩法约束合并后形成的可实施目标。

玩家载体
选择货车,而不是步行或小船;便于表达配送、速度与道路网络。
地图结构
选择可自由移动的道路小镇,而不是严格网格寻路;更像完整小游戏,也降低控制门槛。
优化压力
选择包裹鲜度和小费,而不是燃料或死亡;让“routing”存在,但不破坏 cozy。
资产策略
全部图形与音频程序化生成;避免联网和外部素材依赖,使工程能在隔离容器里完成。

04整个过程发生了什么

  1. 读取任务与检查环境确认 prompt、输出目录和 Godot 版本,先判断任务要求的是完整工程而不是文字说明。
  2. 一次性形成游戏设计在最长的思考段中确定地图、货车、仓库、八个目的地、鲜度、小费、streak、工作日、导航、美术和音频策略。
  3. 建立 Godot 工程骨架创建 project.godot、主场景、常量、地图绘制、玩家、房屋、包裹、HUD、音效和测试文件。
  4. 程序化生成完整世界没有下载素材;道路、草地、码头、水面、树、海鸥、灯塔、货车、粒子和合成音效全部由代码生成。
  5. 首次导入并暴露错误Godot 4.6 报出类型推断、原生方法重名、缺失常量和动态属性访问等问题。
  6. 多轮定位与修复模型读取具体报错,逐项修改 clamp/min 的类型、绘图 helper 命名、字段暴露和测试清理,再删除导入缓存重新验证。
  7. 运行游戏级 smoke test测试覆盖标题状态、玩家与房屋、开始工作日、取件、送达奖励、计数、日终和第二天转换。
  8. 收束并报告产物最终得到 36 个受跟踪文件、约 1,797 行 GDScript/场景/测试代码和一份可启动工程。

总轨迹 22,553 行、约 7.0 MB;38 条 assistant 消息、37 段可见 thinking、58 次工具调用;usage 记录 31,117 个 reasoning tokens;墙钟时间约 34 分钟。

05最终游戏包含什么

  • 俯视角可驾驶货车
  • 港口小镇与道路网络
  • 八个配送目的地
  • 仓库自动取件与容量 3
  • 鲜度、小费与 streak
  • 最紧急包裹路线箭头
  • 150 秒工作日与多日进程
  • 程序化水面、灯塔和海鸥
  • 粒子、日夜色调和 HUD
  • 程序化音效与循环旋律

游戏是自包含工程:不依赖外部图片或音频资产。浏览器版本由同一个 Godot 工程导出,并把引擎、PCK 和音频 worklet 压缩封装进单个 HTML。

06如何验证

生成结束后,工程在一个新的、断网的容器里用同版 Godot 4.6.2 重新导入。独立 smoke test 的 11 项检查全部通过,退出码为 0。随后浏览器实测确认:标题页能加载、Enter 能开始、方向键能移动车辆,实际画面和玩法可运行。

已知问题:桌面浏览器中 HUD 顶部的 Coins 与 Streak 文字有轻微重叠;日志还包含一个 Camera2D 初始化警告和若干退出时对象清理警告。它们没有阻止游戏运行,但说明“测试通过”不等于视觉完全无缺陷。

这轮能说明与不能说明的

它能说明:同一个欠规格请求可以被模型转化为连贯的工作意图,并贯穿设计、实现和修复。它不能说明 K3 每次都会稳定完成;同 prompt 的 Run 1 只留下一个不完整文件,而 Run 2 成功。因此这对结果首先揭示的是默认自动思考下的run-to-run variance,不是思考强度的受控比较。

07直接试玩最终游戏

点击后会在本页解压并启动完整 Web build。按 Enter 开始;方向键或 WASD 驾驶;到仓库附近自动取件,到对应房屋附近自动送达。

Cozy Harbor Delivery 实际游戏画面
如果键盘没有反应,先点击游戏画面一次。游戏首次解压约需数秒。

08完整 CoT:中文与原文

下面保留本轮返回的 37 段 reasoning_content,没有摘要或删节。中文版由 gpt-5.6-lunareasoning.effort=medium)逐块翻译;路径、命令、代码、数字和标识符保持原样。这里的 “CoT” 指 API 实际返回并记录的可见 reasoning 字段。

正在加载中文…