Kimi停售GLM限购，国内用户陷困境

昨天还在疯狂测试 Kimi K3，今天就听说停售了。

K3 确实火了，火遍大江南北，火到直接停售。之前 GLM 5.2 火爆之后也是一直限购状态。国外的抢不到也就算了，现在国内的也抢不到，太难了。稍微好一点的模型，自己人都很难抢到，而且优质模型也越来越贵。

还好有朋友给力，直接送了一个 $199 的 Kimi 账号，GLM 那边也有老 Pro 账号配额充足。想了解这两个模型真实情况的，可以来看看实测结果。

都不知道 Kimi 居然还有这么牛的账号类型，30 倍额度是真的给力，一直吐槽的 Kimi 配额问题完美解决，终于可以测个痛快了。

今天来讲一下 Kimi K3 的代码修改和升级能力。

上一轮测试中，大部分例子表现不错，但有一个例子表现非常拉胯——让 K3 自由发挥生成一个 3D 台球。

生成的效果非常简陋，还有三个致命问题：台球桌的建模有大问题，六个孔都没挖出来；操作问题非常大，鼠标一移到网页，整个镜头就开始疯狂晃动；击球后的镜头比过山车晃得还厉害。总的来说，就是没法玩。

相比之下，Fable 5 的第一个版本就非常稳，建模、质感以及手感都不错。

高下立判。但既然要测，就得测出真实能力，所以准备多轮测试，看看对"自然语言需求"的理解能力和指令遵循能力。在不断对话和修改的过程中，很容易感受到真实能力。

最终被改成了这个样子——整个台球室都建出来了，墙上还挂上了"艺术品"。

这是一个完全 3D 的例子，全部通过"自然语言"实现。从视频可以看出来，整个房间的建模不错，游戏也能玩，能做到这个程度已经很不错了。不过也是花了不少功夫调整的，并不是一次两次就搞定，这很符合实际情况——真实项目就是不停地改改改改。

下面展示完整的开发过程（对话过程），K3 自己做了汇总报告，除了看过程，也可以看看它的汇总报告做得怎么样。

一、对话如何开始

首先提出了一个简单的需求——做一个 3D 台球游戏，先聊聊对这个需求的理解。

经过一轮方案讨论后确定方向：

• 写实风：深色木桌、绿台呢、暖色吊灯，经典台球厅氛围
• 规则：完整 8 球规则（Kimi 建议）
• 物理：自写简化 2D 台球物理（Kimi 建议，不用物理引擎，手感完全可控）
• 联机：需要能联网对战（特别加的需求）

围绕这个需求，总共调整了 12 轮。以下是每轮记录。

二、逐轮修改记录

第 1 轮 — 头脑风暴

用户：做个 3D 台球游戏，聊聊想法。结果：输出技术选型（Three.js + 自写物理）、玩法要素（瞄准预测线、蓄力、8球规则）、视觉风格三选一、四步开发节奏，供用户拍板。

第 2 轮 — 游戏诞生（提交 d2e82c8）

用户：写实风、规则玩法你定、自写物理、要能联网玩，效果和手感按最好的来。实现：

• billiards.html：Three.js 场景（木桌/绿呢/双吊灯/软阴影/ACES）、自写 240Hz 物理（弹性碰撞、库边、摩擦、落袋）、瞄准碰撞预测线（目标球线 + 母球分离线 + 幽灵球）、蓄力出杆、WebAudio 合成音效、完整 8 球规则（开球/定组/犯规/自由球/黑八胜负）、练习/本地双人/在线对战三模式
• server.js：手写 RFC6455 WebSocket 协议的零依赖中继服务器（房间码制），联机采用锁步模拟 + 行动方权威状态纠偏
• test_ws.js：协议集成测试（建房/加入/中继/满员/断连全部通过）

第 3 轮 — 版本管理 + 精细建模（提交 a0db4fc）

用户：创建 git 版本管理并提交；球桌建模粗糙、6 个袋口没表现出来；鼠标瞄准太滑。实现：

• git init + 首次提交，确立"每轮功能改动都提交"的工作方式
• 球桌重建：带 6 个真实开孔的挤出成型台呢、L 形截面库边、整环挤出木边框（内沿带袋口弧形缺口）、钻石点位镶嵌、车木桌腿（Lathe）、围裙、皮袋 + 铜环
• 完整房间：拼木地板、护墙板 + 乳胶漆墙面、踢脚线腰线、天花板横梁、地毯、台球海报、球杆架、吧台高脚凳、壁灯
• 瞄准手感：角度平滑阻尼（过滤鼠标抖动）、6 cm 死区、Shift 精瞄、方向键/A/D 微调
• 引入无头 Chrome 截图验证工作流（--headless --screenshot），截图驱动修复了袋唇"绿刺"等渲染问题

第 4 轮 — 亮度/袋口/交互/镜头/回球（提交 001e8bc）

用户：① 绿色太浅中间偏亮 ② 金属环浮在边框上 ③ 袋口弧度乱 ④ 鼠标进入就疯狂瞄准 ⑤ 击球后镜头疯狂跟球 ⑥ 要落袋特写和球在桌下滚动到固定位置（这一轮需求提得有点猛）。实现：

• 台呢加深、吊灯降功率、曝光下调
• 金属嵌环移到台面平面（嵌进袋口内侧）
• 方块袋唇 → 贴合袋口圆周的弧形立面（圆柱壳扇形）
• 交互重做：不按左键不瞄准；短拖=瞄准、按住不动=蓄力、松开=出杆、轻拖取消
• 滚球镜头改为出杆瞬间计算一次的固定机位，只锁第一次落袋做焦点特写
• 桌下结构：石板 + 开放空腔，6 条支槽 + 纵向主槽 + 集球托盘 + 空腔补光；落袋后球自由落体入袋 → 全场停稳后进入回球特写：镜头钻到桌下跟球滚进托盘依次排好

第 5 轮 — 视角切换（提交 3054c17）

用户：按 V 切换顶视、斜视、第一人称。实现：三视角循环切换（带平滑过渡），瞄准辅助线全视角可用，滚球时顶视同样生效，URL 参数 ?view= 可指定初始视角。

第 6 轮 — 俯仰拖动（提交 30e593b）

用户：按住左右拖动保持瞄准不变，上下拖动要能看上面看下面。实现：camPitch 俯仰偏移（-0.25~+0.9），上下拖动调整相机高度，第一人称/斜视角下生效，蓄力中也可微调。

第 7 轮 — 头像上墙（提交 cc05c3a）

用户：把 docs/1.jpg 转最省空间的 WebP、调整大小、镶框挂上墙。实现：2368×3088/1.35MB → 768px WebP/123KB；四层装裱（深色木框 + 铜饰条 + 米白卡纸 + 画心）挂东墙。

第 8 轮 — "俯仰没生效"排查（提交 1cf82c4）

用户：上下拖动俯仰好像没实现。排查：代码审查 + 页内自检（?selftest=drag 模拟拖拽）证明逻辑正常，实为浏览器启发式缓存旧页面。修复：server.js 响应加 Cache-Control: no-store；留 window.__G 调试句柄。

第 9 轮 — 画面黑色修复（提交 cf08804）

用户：相框有了但画面是黑的。排查：file:// 直开时 Chrome 视本地图片为跨域污染，禁止作 WebGL 纹理（此前验证都走 HTTP 未暴露）。修复：图片转 base64 data URL 内嵌（assets/wall-art.js），HTTP 下回源 webp。

第 10 轮 — 单文件化（中间方案）

用户：不希望引用资源，整个页面要能单独上传直接玩。实现：图片 base64 + three.js 全部内联进 HTML（1.02MB 完全自包含）。

这一步，概括和理解都有错误——本意是只把图片嵌入，而不是把 three.js 也嵌入。所以立马打断了。

第 11 轮 — 方案回调（提交 e38147d）

用户：图片不用压那么小，1024 比例差不多；three.js 不用内嵌，引用一个国内外都能访问的地址即可。实现：图片重转 1024×1335 WebP（170KB）base64 内联；three.js 恢复 jsdelivr CDN 引用。最终 billiards.html 单文件 303KB，已用 file:// 直开验证。

第 12 轮 — 本文档

整理开发总结 + 拍摄代表性截图。

这是它总结的 12 轮对话。想到哪里说哪里，重点是解决一些非常明显的问题。很多细节还没调整。

最终的功能清单如下。

三、最终功能清单

渲染与场景

• Three.js + ACES 色调映射 + PCF 软阴影 + RoomEnvironment 环境反射
• 完整台球厅：球桌（开袋台呢/L形库边/钻石点/弧形袋唇/皮袋铜环/车木腿）、房间（拼木地板/护墙板/横梁/地毯/海报/杆架/吧台/壁灯）、墙上装饰画（用户图片 1024px WebP base64 内嵌）

物理与规则

• 自写 240Hz 子步进物理：等质量弹性碰撞、库边反弹、滚动摩擦、袋口豁口判定
• 完整 8 球规则：开球、首球定组、先碰错球/空杆/无球碰库/母球落袋犯规、自由球摆放、黑八胜负
• 瞄准预测：碰撞点、目标球走向线、母球分离线、幽灵球

操控与镜头

• 按住左键：左右拖=瞄准，上下拖=俯仰，按住不动=蓄力，松开=出杆，轻拖取消；空格蓄力；Shift/方向键精瞄
• V 键三视角（第一人称/斜视/顶视）；右键环视；滚轮缩放
• 滚球固定机位；落袋焦点特写；桌下回球通道动画（球滚入集球托盘）
• WebAudio 合成音效（碰撞/吃库/落袋/入盘，音量随力度）

联机

• server.js 零依赖 WebSocket 中继（房间码 4 位），锁步模拟 + 权威状态纠偏
• 实时同步对方瞄准线；断连通知；再来一局同步
• 服务器同时是静态文件服务器，Cache-Control: no-store

工程

• 每轮功能改动独立 git 提交，历史可追溯
• 调试基建：?auto=practice 直进游戏、?cam=top/side/pocket/under/wall 调试机位、?view= 视角、?selftest=drag 页内自检、window.__G 状态句柄
• 无头 Chrome 截图验证工作流

从清单来看，涉及了不少技术点，有一定的功能量，K3 也有一定的工程水平。

除了让它总结对话，还专门考了考抓重点和截图的能力——要求它对项目中比较有代表性的场景进行截图保存。

四、截图画廊

下面是它自己调整镜头，截取的八张图片，来看看是否精准。

整体来说还是不错的，毕竟是它自主完成的。

对话记录、功能、截图都展示完了，然后来说说如何运行。

五、运行方式

运行其实很简单。大部分功能直接双击静态 HTML 页面即可运行。

联网功能需要启动 Node 服务：

node server.js

启动后访问 http://localhost:3000/（联机必须）。

• 局域网对战：朋友访问启动时打印的局域网地址，一人创建房间、另一人输入 4 位房间码加入
• 外网对战：用 ngrok / frp 暴露 3000 端口
• billiards.html 单文件可直接上传任何静态托管（练习/本地双人免服务器）

如何运行说完了，来说说怎么操作，也就是要怎么玩。

六、操作说明

操作一样很简单，鼠标键盘都可以。

整个结果、过程、文档都看完了。

针对 AI 使用强度不同的人，可能会有不同的感受。

对于长期使用AI编程、国内外顶级模型都在高强度使用的情况，简单说说感受。

整体结果还是不错的，国内一线没跑了。代码修改能力还可以，最终也搞得像模像样。场景建模和环境光控制不错，总结文档写得好，对话记录、交付清单、截图、运行和操作说明，重点都抓到了，没有长篇大论，这一点很讨喜。

接下来说说不足的地方。

首先是首轮结果实在太糟糕，很多问题不应该存在。其次修改过程太漫长，Token 消耗也很猛。中间对话过程中，有些需求理解不到位，有会错意的地方。很多明显的问题不应该由用户提出来，而是应该主动修复才对。

自主规划能力还偏弱，无法自主提供一个扎实和完善的项目底座。就像人一样，需要极其丰富的经验才能把底子打好。

对于专业程序员、清楚各种技术点的开发者，应该可以比较精准地执行任务。但对于 Vibe Coding 的人来说，它能兜底的空间还比较有限。

大概就是这样。每个场景和每次抽卡都会有差异，只有测多了才会有整体的感受。