10 月 10 日，B 站 UP 主基于社区基准「亿模亿样」发布的一期 AI 前端/3D 能力双盲测试结果，把 Kimi K3 推回台前：在这期题库里，DeepSeek V4.1f 与小米 MiMo 等模型已经跑到它前面。 而 7 月刚发布时，K3 正是靠 Three.js 场景生成能力被捧为国模「前端大王」。把两头对上，实测需要先给出的结论是：K3 的 3D 能力没有消失，消失的是「一次成型」的幻觉——它写出的浏览器 3D 场景是真的，它在相机对中、依赖版本、光照材质、移动端适配和长代码截断上的翻车也是真的，想让产出稳定，人得先把一系列设置做对。哔哩哔哩
从「前端之王」到被反超，这一年 7 月到 10 月发生了什么
Kimi K3 于 2026 年 7 月 16 日正式发布，官方公告写明这是月之暗面迄今能力最强的模型：2.8 万亿参数、基于 KDA 混合线性注意力机制与注意力残差技术构建、原生支持视觉理解、100 万 token 上下文，公告也坦承其整体表现仍落后于 Claude Fable 5 与 GPT-5.6 Sol，但稳定超过了其他所有模型。 7 月 27 日「开放日」，权重与技术报告同步开源，支撑训练的三项 Infra 技术一并放出。知乎知乎
前端与 3D 正是 K3 发布首周出圈的切口：海外科技博主实测发现它在前端编码上超越 Claude Fable 5、登顶 FrontendCodeArena 榜单。 但同一时间社区也有清醒声音：K3 在前端、3D、视觉 Agent 三条差异化赛道跑出来了，代价是速度、价格、稳定性都还没追上最头部模型。哔哩哔哩微博
8 月的榜单合盘已经露出裂缝：K3 在三个榜单拿下前端第一、后端第十五，「多花 33 倍只多 5.6 分」。 随后国模节奏加快，小米 MiMo 2.6、DeepSeek V4.1f、GLM 5.3 相继在这个赛道上新，前端/3D 的供给一下变密。回到 10 月 10 日的题库，评论区把结果概括为 DeepSeek 的 V4.1f 与小米的 MiMo 已经全面压过 K3。哔哩哔哩哔哩哔哩
至于「降智」之争，目前没有可核验的官方解释：K3 发布后 Kimi 未再更新旗舰，K3.1 传闻久悬；用户体感也分裂，有人抱怨所有任务都被迫开最高推理档位，也有人坚持 K3 从来被过誉、且慢得难以忍受。能落到记录上的事实是：7 月以来同赛道对手的参照系被不断刷新，而 K3 的绝对能力档位基本没动——问题未必是「K3 变笨了」，而是「只有 K3 没升级」。
实测翻车点：3D 渲染最容易在哪几处倒下
最常见的翻车不是报错，而是「渲染出来了，但画面不对」。10 月 6 日的一期 AI 日晷挑战里，K3 按一轮交付、无返修的设定做完题目，结果是摄像机位置错误、旋转中心和画面中心对不齐，也没能做出日夜环境变化。哔哩哔哩
依赖与版本是第二类高频坑：社区里最典型的控制台报错「Failed to resolve module specifier」，根因常常是 K3 使用了旧版 Three.js 的 CDN 地址，修法是 Prompt 里写死 jsdelivr 的 importmap 引入。知乎
光照与材质同样容易翻车。K3 生成的场景「渲染出来了但地面上没有任何阴影」被列入教程的高频症状清单。 另一位用 K3 辅助搭建纯 Three.js 太空射击游戏的开发者复盘更具体：一组雾参数让行星直接消失，而自定义 ShaderMaterial 默认不吃雾、标准材质默认吃，两者混用行为当场分裂。知乎知乎
还有两类「边界型」翻车。单张图片转 3D 时结构还原度不稳定，一张 2D 图天然缺少深度信息，还原基本靠猜，容易做成一堆方块的堆砌。移动端则是教程总结的高频症状：桌面浏览器一切正常，手机打开黑屏或无法操作。知乎
交付形态上还有硬限制：网页版对话里长代码会被截断，只能回复「继续」续写，不支持自动模式，数千行级场景的迭代效率远低于 CLI。知乎
翻车点不止渲染侧，成本和配额同样吃人。有用户用一份文档换来一个可玩的 3D 座头鲸模拟器，代价是约 5 小时连续生成与 1% 额度。 API 接入侧，切到 K3 后频繁 429 的真正原因是 RPM 与 TPM 是两个独立的限流桶，要分开退避。 老项目迁移则要先对齐参数：kimi-k3 完整 modelID 为 moonshotai/kimi-k3，相比 kimi-k2.7-code 有若干请求参数需要更新。小红书知乎知乎
调优指南：不是和模型较劲，是和设置较劲
第一，手动选定 K3，千万别用「Auto 自动调度」——Auto 会把简单任务分给小模型，3D 代码质量直线下降。 第二，3D 任务把推理力度开到 max：K3 发布时默认思考强度为 max，后续才增加 low 和 high 两档，教程作者在同一个建筑场景的对比测试里结论是，3D 场景复杂度高，推理力度对代码质量的影响远大于普通对话。知乎知乎
第三，依赖与路径写死：在 Prompt 里固定 Three.js 的引入方式与版本，遇到「鼠标拖拽无效」这类问题，多数是版本路径差异，直接把正确的 import 语句贴给 K3 让它修正即可。 第四，先计划再生成：复杂场景先让 K3 输出图片分析、结构规划和代码架构，确认方向后再写代码，避免跑偏；更大的任务可以照社区「跳一跳」小游戏的完整流程执行：先写详细方案、拆成 TODO 逐项做、浏览器试玩后用截图定位遮挡问题，最后补移动端模拟与真机测试。知乎哔哩哔哩
第五，用截图驱动反馈闭环。官方材料特别写明 K3 擅长结合软件工程与视觉推理，能利用截图和视觉反馈优化游戏开发、前端与 CAD 等场景。 教程作者的经验换算是：贴截图比纯文字描述准确 10 倍，K3 能直接看出截图里哪里不对。 太空射击游戏的开发者则把视觉验收固化成流程：固定视口截图、目检、改、再截。知乎知乎知乎
第六，成本可控：K3 会自动缓存 System Prompt 和重复前缀，把长提示词放在消息列表开头即可命中缓存，输入成本能降到十分之一。知乎
边界：K3 是结对编程伙伴，不是一键建模工具
最需要先想清楚的是 K3 到底在「做」什么：它的 3D 产出是 Three.js/Babylon.js 代码，靠浏览器 WebGL 实时渲染，和「上传一张图、直接吐 .glb 资产」的 Meshy、Tripo 类工具完全是两条路。知乎
一位半年深度使用者的判断同样直接：K3 不能替代 Blender 做高精度建模，不能替代 Unity 做游戏开发，也不能替代 Three.js 工程师处理复杂性能优化。 更经济的用法是让它出可交互原型、把需求沟通变成直接看效果，确认方案后再交给专业建模做高精度版本。知乎
合起来说：K3 的前端 3D 能力依然值得用，但要按结对编程伙伴用，不按一键 3D 按钮用。 7 月的登顶证明它写 3D 代码的强度是真的，10 月的被反超也证明「渲染效果确认」这一步人类还省不掉——写死依赖、开满 max、手动选模型、愿意用截图反复迭代，把这四步设置做对的人，才是今天真正用得上 K3 3D 能力的人。
