Kimi K3 停售与 GLM 限购：大模型代码修改能力全解析与 3D 台球开发实录

近期，Kimi K3 的停售成为热议话题，此前 GLM 5.2 的火爆也导致长期限购。优质模型不仅一卡难求，整体费用也呈现上涨趋势。目前，使用一个 GLM 老 Pro 账号仍可获得充足配额，而一位朋友赠送的 $199 Kimi 账号彻底解决了配额限制，使得持续测试成为可能。

该账号高达 30 倍的额度彻底化解了 Kimi 配额不足的困扰，使深入测试成为现实。本次将重点考察 Kimi K3 的代码修改与升级能力。

在上一轮测试中，K3 多数案例表现尚可，但有一个案例严重翻车：要求它自由发挥生成一个 3D 台球游戏。

初次生成的效果极为简陋，且存在三个致命缺陷：一是台球桌建模问题严重，六个袋口均未挖出；二是操作异常，鼠标一移入网页，镜头便开始疯狂晃动；三是击球后的镜头晃动甚至超过过山车体验。整体而言，这个版本完全不具备可玩性。

相比之下，Fable 5 的初版表现稳定：

其建模、质感以及手感均相当出色，初期差距明显。但这仅仅是开始，为进一步探究模型对自然语言需求的理解与指令遵循能力，后续通过多轮对话不断调整，最终完成了整个台球室的构建，甚至包括墙上悬挂的“艺术品”。

这是一个完全通过自然语言实现的 3D 场景。以下视频直观展示了最终效果：

从视频可以看出，房间建模整体可观，游戏也已达到可玩状态。不过，达到这一效果经历了大量调整，并非一次性完成，这完全符合真实项目中反复修改的常态。下面完整展示从对话到成品的开发过程。

对话起点

首先提出一个简单需求——“制作一个 3D 台球游戏”，并先讨论了模型对此需求的理解。经过方案轮讨论确认方向：

• 写实风格：深色木桌、绿台呢、暖色吊灯，营造经典台球厅氛围；
• 规则：采纳 Kimi 建议的完整 8 球规则；
• 物理：采用 Kimi 推荐的自行编写简化 2D 台球物理，不依赖物理引擎，确保手感完全可控；
• 联机：增加联网对战需求。

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

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

用户指出台呢绿色过浅、金属环浮于边框、袋口弧度异常、鼠标进入即疯狂瞄准、击球后镜头失控、需要落袋特写与球在桌下滚动的固定位置。本轮调整密集，实现：

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

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

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

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

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

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

用户上传图片 docs/1.jpg，要求转换为最省空间的 WebP、调整尺寸、镶框挂墙。结果：2368×3088px、1.35MB → 768px WebP、123KB；四层装裱（深色木框 + 铜饰条 + 米白卡纸 + 画心）悬挂东墙。

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

用户反馈上下拖动俯仰未生效。代码审查与页内自检（?selftest=drag 模拟拖拽）证明逻辑正常，实际是浏览器启发式缓存旧页面所致。修复方法为 server.js 响应增加 Cache-Control: no-store，并保留 window.__G 调试句柄。

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

相框已添加但画面全黑。排查发现，以 file:// 直接打开时，Chrome 将本地图片视为跨域污染，禁止用作 WebGL 纹理。修复方式：图片转为 base64 data URL 内嵌（assets/wall-art.js），HTTP 下仍回源 webp。

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

用户希望整个页面不依赖外部资源，能单独上传直接游玩。模型将图片 base64 与 three.js 全部内联进 HTML（1.02MB 完全自包含）。但用户本意仅为嵌入图片，而非嵌入 three.js，因此立即叫停。

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

用户明确：图片无需过度压缩，1024 比例即可；three.js 不内嵌，引用国内外可访问的 CDN。实现图片重转 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 编程的用户而言，K3 的整体表现达到了国内一线水平。其代码修改能力可用，最终成品有模有样，场景建模与环境光控制尤为突出；总结文档质量较高，对话记录、交付清单、截图和操作说明均抓住重点，简洁实用。

但仍有明显不足：首次生成的结果过于糟糕，许多问题不应出现；修改过程漫长，Token 消耗巨大（得益于高额度套餐仅烧掉几个百分点）；中途对某些需求理解不到位，出现过会错意的情况，一些容易察觉的问题需要用户提出而非主动修复。此外，自主规划能力偏弱，难以提供扎实完善的项目底座，这要求像人一样积累丰富经验才能打好地基。

对于专业开发者而言，K3 可较精准地执行明确技术点的任务；但对于 Vibe Coding 用户，它能提供的兜底空间仍然有限。每次场景和每次生成都存在差异，只有经过大量测试才能形成整体判断。

目前 Token 充足，甚至考虑让它从零开始编写“红色警戒”，但该项目复杂度过高，Fable 5 和 GPT 5.6 均已在此泥潭中挣扎两周。下一篇将分享 Fable 5 在同样开局下的整体效果与开发过程，同样经过约 10 轮调整，可对比两位选手的最终结果。该测试项目的 V1 版本已上传至个人网站：https://topai.jarvisuni.com/ ，V2 版本也于同日更新。