KIMI K3.1 PRO · 3D FIELD TEST 3D，不止好看 看完还能继续改 网页 · 建模 · 游戏 · 机械原理 原生代码驱动，留下可编辑工程。 CODE → 3D ENGINEERING VIEW Blender *.blend Three.js src/ Godot project.godot SOURCE · EDITABLE

5 PARTS · CONTENT MAP

PART 01

能上手的三维网页

桃花源记

PART 02

建模与游戏引擎

圆明园 · 星球 · 游戏

PART 03

产品与原理模型

随身听 · NAND · 旋翼

PART 04

三方同题横评

海面 · 方块世界 · 推进

PART 05

实测之后的感受

画面审美 · 工程完整度

大家好啊，我是甲木。

之前就一直在用 Kimi K3完成各种前端相关的任务，主要是审美方面太爱了...

上周六看到，Kimi 推出了K3.1 Pro 模型，在代码、3D 创作、金融研究和其他长程 Agent 能力上都有所提升，当时就想测来着，奈何在观猹大会还有演出，就没有第一时间跟进，这两天终于有时间来品品新模型的效果了。

拿前两天刷屏的会飞跑车：特斯拉的 Roadster 在 SpaceX 火箭试验场，倒挂着爬坡、腾空翻转、飞越车队，稳稳落地。让它飞起来的，正是底盘上那套 SpaceX 冷气推进器。

我就琢磨，能不能让 AI 直接用 Blender 搓一段发布会的开场动画出来？

先看成片，这段 18 秒的动画：

这一段，是我把 Kimi K3.1 Pro 接进终端，纯靠写Blender Python 脚本做出来的。

车身、展台、运镜轨迹、四路喷流和地面烟尘，都在三维工程里，还能打开继续改。后续改机位、调参数非常方便。

悬停调试的时候，先切到车身侧面，校准轮毂、车窗反光和底盘喷流形态，单独看就是一段车模展示：

再推到车尾，四个喷口亮起，尾翼跟着联动升起。把这些机械小动作补齐，整段镜头才有了产品演示的感觉：

不过也有个小瑕疵：做局部调整的时候，它容易把之前已经调好的效果改退步，最开始喷出来的冷雾很自然，跟着喷气节奏一层一层积起来很真实，后面反复调物理参数的时候，反而越改越散、越改越假。

这两个月海外模型更新得太猛了，连着发 SOTA 霸榜，国内这边多是在发轻量版。大家一直在等，什么时候能再拿出一个能正面硬刚的旗舰。

终于，Kimi K3.1 Pro来了，3 万亿参数底座，基于K3做了后训练，支持100 万上下文，主打代码、3D 创作和空间推理。

最关键的是：它不需要中间套什么插件转接器，直接写原生脚本驱动 Blender、Three.js 和 Godot。

先来看看榜单，

在各方面基本上都有一个整体的提升。听说他们这次为了支撑数百个下游领域的大规模联合训练，优化了技术栈的每一层，包括 RL 框架、长上下文推理、训练效率、沙箱基础设施、调度系统，以及用于环境质量检查的共享平台等。最终，Kimi K3.1 Pro 模型在所有领域都获得了大规模 RL 带来的全面提升。

不过实际跑下来体感也很明显：这个模型思考链路偏长，跑长任务等待时间真的很久，和刚发布时的 GPT 6.1 Sol 速度差不多。

榜单数据看一下就行，主要还是实测场景。

今天这篇就来给大家分享一下Kimi K3.1 Pro的实际能力以及和DeepSeek、GPT的对比，包括Kimi的缺点，方便大家有一个实际的体感！

PART

01

两个能上手玩的三维网页

INTERACTIVE · WEB WORLDS

这次我直接给它上硬骨头，跨了几个引擎做实测。先看实际跑出来的东西。

空间布置与交互长卷 · INTERACTIVE 3D

CASE 01

工程师：拆一台纯电 SUV（Three.js）

参考提示词

PROMPT 01 · 纯电 SUV · 工程布置

# 任务：做一张让汽车工程师信得过的拆解图看过 Munro Live 那种拆车视频的人都知道，工程师看车的方式和普通人完全不同：他们关心的是这东西怎么装上去、怎么修、撞了往哪儿传力。你要做的是一台纯电 SUV 的可交互拆解网页。过关标准不是零件数。## 过关条件我把你的截图拿给一个真的做过整车布置的人看，问一句：**这台车的布置，你觉得能造出来吗？**- 如果他说「看着像画的」——你失败。- 如果他说「电池这么放，后排脚部空间够吗」——你成了。他开始跟你讨论工程问题，说明他信了。## 你自己要想的事- 电池包放在哪、多厚、怎么和地板共存？后排乘客的脚往哪放？- 前舱里电机、电控、热管理、悬架塔顶怎么排？它们会打架吗？- 碰撞的时候力往哪走？前纵梁、门槛梁、B 柱是不是一条通路？- 换一个前大灯要拆多少东西？维修可达性也是布置的一部分。- 悬架是什么形式？如果画了多连杆，连杆得真的连着东西。- 轮胎和轮拱的间隙：满载会不会蹭？## 底线- 双击能开，不许外链、不许 glTF，几何全部程序化生成。- 零件要有名字，点得中，能看材料和大致质量。- 60 帧。- 手机能转着看。零件数你自己定。够解释清楚布置就行，堆一堆用不上的螺丝不算本事。## 交付`index.html`、`src/`、`PACKAGE.md`（布置逻辑：为什么这么放、哪里做了取舍）、`progress.md`、`shots/`（至少 5 张：整车、爆炸、电池、前舱、剖切）。

↓ 在框内上下滑动，查看完整提示词

电池、后排脚部、前舱和纵向半剖都能单独查看。140 毫米电池包、180 毫米离地间隙和210 毫米前座下方脚部净高放进了同一套结构里，空间算得很准，完全没打架。

点进维修模式更惊喜：开前机盖、松内衬、前杠让位、抽出大灯，严格按照四步拆装走。一盏灯拆出来，前面的部件为什么要逐一移开，前后因果很严密，讲结构的人随时可以停下来讨论。

CASE 02

《桃花源记》：把古文读成一条路（Three.js）

参考提示词

PROMPT 02 · 桃花源记 · 空间阅读

# 任务：把一篇小说做成人能走进去的网页我给的不是「做一个 3D 场景」，是「让一个人愿意在浏览器里读完一篇古文」。`novel.txt` 里是陶渊明的《桃花源记》，四百字。你把它做成一个可以滚动往下走的三维空间：读到哪儿，场景就走到哪儿。## 怎么算成我把这一页给三个人，不给任何解释。他们读完，我合上页面问一句：**哪一句话让你停下来了？**- 如果说「不知道，我光顾着看画面了」——你失败了，你在做游戏，不是在做能走进去的小说。- 如果说「我没读完」——也失败了。- 如果他能说出某一句话，并且说出为什么，你才算成。## 你要自己想的事这篇文字有一条很清楚的路：**缘溪行 → 逢桃花林 → 山有小口 → 初极狭 → 豁然开朗 → 村中 → 辞去 → 处处志之 → 遂迷不复得路**。但节奏不是均匀的。「初极狭，才通人」这一句只有六个字，读起来却是全文最难受的地方；「豁然开朗」四个字要在一瞬间把前面所有的窄都还回来。你怎么用空间做这件事？还有几件躲不掉的：- 「仿佛若有光」——光在这里是唯一的线索。你的光要怎么做，才能让人跟着它走？- 「不复得路」是全文的结局。一个可以走进去的空间，最后怎么让人**找不到回去的路**？这不是加个黑屏能解决的。- 有一段什么都没发生（黄发垂髫，并怡然自乐）。你怎么让人在这一段不滚走？这些我一个都不定。**你怎么判断的写进 `DESIGN.md`。我要看你有没有读懂这四百字，不是看你会不会 three.js。**## 底线- 双击 `index.html` 能读，不许联网、不许外链资源（字体、图片、模型全禁），全部程序化生成。- 手机竖屏要能读完，不是「能打开」。- 首屏 3 秒内出画面，不许拿加载进度条糊弄。- 桌面 60 帧。## 交付`index.html`、`src/`、`DESIGN.md`（每个场景的取舍和理由）、`progress.md`、`shots/`（至少 6 张：溪、林、洞口、极狭、豁然开朗、村中）。

↓ 在框内上下滑动，查看完整提示词

把陶渊明的原文拆成 19 个阅读停留点，滚动页面带动镜头。

沿溪前行两岸桃林徐徐展开；到了山口视野骤缩；读到“初极狭”，镜头挤进逼仄岩缝；穿过洞口“豁然开朗”，田舍池塘瞬间横向铺开。

用滚动来控制阅读进度很舒服，山洞里可以多停一会儿，村舍可以慢慢看，手往回滑镜头还能顺着原路退回去。文学里的空间和节奏，有了可以一起看的演示。

PART

02

把3D建模和游戏引擎也调起来

ENGINE · MODELS & GAMES

多技术栈工程实测 · ENGINE & SIMULATION

除了网页，我还把题目扩展到了真正的游戏引擎和复杂系统上，看看它接重活的能力。

CASE 03

圆明园复原。

这个题材我犹豫了很久才下手，毕竟它对中国人来说，不只是一个景点，是一道刻在历史里的遗憾。

Kimi K3.1 Pro 用 Blender 从零建模，靠联网搜来的老照片、清代版画和遗迹测绘数据，把一百多年前烧没的西洋楼和十二生肖兽首喷泉一点点拼了回来。看十二兽首轮流喷水——这一幕我们只在课本里读过，现在居然能站在跟前"看见"。

CASE 04

小王子（Godot）。

以《小王子》为创意参考，直接写开源 Godot 引擎脚本做成的小星球。

参考提示词

PROMPT 03 · 小王子星球 · 多轮要求整合版

# 任务：用 Blender 和 Godot 制作可以探索的小王子星球在 Blender 中制作《小王子》主题的三维角色与星球资产，再接入 Godot 4.5，做成一个真正可以探索、完成每日仪式、观察日落的小世界。工作分阶段进行，每阶段保存工程；每次渲染后打开图片检查，再决定下一步。先查看提供的风格参考图。参考 Infinity Nikki × The Little Prince 联动的氛围与材质：温暖暮色、柔和童话光、干净的风格化造型、玻璃与金色细节、深蓝星空。保留自己的模型与尺度设计。## 最终尺度和整体构图星球最终直径为 14 米，角色身高约 1.40 米，比例约 1:10。星球表面积约 615.8 平方米；走过它需要真实的时间，不能几步就逛完。内容要分布到上半球和侧肩，不能只集中在顶部的一小块区域。先计算并打印星球表面积、可玩区域面积、草的覆盖密度、实例数量和三角面预算，再建场景。随着球体扩大，重新计算密度，不要简单整体放大。## 角色：重做有形体的小王子角色目标 60,000—120,000 三角面，不能由盒子、等粗圆柱和球体拼出粗糙人偶。头部有额头、颧骨、下巴和太阳穴，头颅稍宽于下颌；鼻子柔和，耳朵有凹面；眼眶、眼球和眼睑有厚度。脖子自然前倾，躯干有肩背、胸廓和收窄的腰部，保持儿童比例。四肢沿曲线放样并逐渐收细，肘膝有体积变化；手有手掌和五根分开的手指，手指自然弯曲；靴子有鞋跟、脚踝、鞋头和皮革折痕。绿色长外套作为独立衣壳，做出翻领、领口、袖口和略微上扬的衣摆，金色纽扣贴合衣面并投下阴影。内搭浅色衬衣与深色裤子。黄色或橙黄色围巾围绕脖子，尾部有厚度、扭转、收尖、波浪边和纵向褶皱，两条尾巴有不同的下垂姿态。金色短发使用 40—70 束分层的弯曲发绺，发梢收细，少量碎发扬起，每束有细微色差。不能变成长发、头盔或粗楔子。脸部简洁温暖，避免夸张笑脸和面具感。休止姿态要自然：重心落在前脚，略有迈步，一只手稍微展开，头转约 20 度。不要对称 T 字姿势。## 骨骼和动画建立清晰的 root、hips、spine、chest、neck、head、双臂和双腿骨骼，并为围巾尾部设置骨骼。自动绑定后必须实际摆姿，修正腋下、髋部和膝盖处的权重撕裂。同一套骨骼交付三个可独立导出的动画：- Idle：96 帧待机循环，呼吸、轻微重心转移和围巾飘动，首尾姿态一致。- Walk：24fps、24 帧步行循环，有接触、下沉、经过和抬升过程，手臂反向摆动，围巾跟随。种地脚不能滑动，步幅与 Godot 移动速度一致，报告实际步幅。- Water：约 72 帧，伸手拿起浇水壶、倾斜、浇水、归位。手要贴近壶柄，不能悬空。每个动画渲染至少四个关键帧并查看，角色重做后再次测试行走极限姿态，修好肩部和髋部变形。## 地形、草与花星球不是贴着绿色材质的光滑圆球。地表有缓坡、隆起、浅盆地、露出的岩层和玫瑰所在的高处，从斜侧面看轮廓不应是完美圆形。近景草必须是真实几何：锥形叶片沿长度弯曲，约 3—4 段，通常高 12—18 厘米，玫瑰周边和水边有 25—30 厘米或更高的草。草丛存在深绿、中绿、黄绿色叶尖的变化，花朵有弯曲花瓣、厚度和可见花心，不能像折纸三角形。沿用小星球阶段的近景草毯观感，但按 14 米星球重新设计三层覆盖：- 近场：玩家活动范围内保持密集真实草叶。- 中场：约 40%—50% 的密度，适当增大草叶补偿。- 远场：地表材质表现草簇法线和颜色变化，少量几何草簇打破地平线轮廓。Godot 使用 MultiMeshInstance3D 和按距离裁剪，报告实际可见实例数。路径石板内不长草，草在路径边缘自然分开；水边和玫瑰周围形成有目的的草簇。Blender 和 Godot 两边的草都要随风摆动，不能只有一张静止草毯。使用同机位不同帧渲染验证风动画，并报告像素差异。## 星球内容：让每条路都有值得发现的东西保留并细化：- 三座火山，尺度约 1.2—2.0 米：一座有暗红余烬，一座有细烟，一座熄灭、侵蚀并长苔。- 五株不同阶段的猴面包树幼苗，其中一株体量明显、根部顶起草皮。- 两个不同高程的池塘，用湿石小溪连接；水边有芦苇、香蒲和湿暗卵石。- 红玫瑰有层叠花瓣、茎叶与刺，置于高处；玻璃罩有真实厚度、金色底边与顶饰，能透过玻璃看清花朵。- 岩石观景台、木质长椅、铁腿、浇水壶，以及通往玫瑰、长椅和活火山的分支石路。增加各有辨识度的地标：8—10 块站石组成的石环，一块倒下、朝阴面生苔；两片岩层之间可以走入的幽暗凹洞，入口有花、内部有一束光；约 2.5 米的枯树和秋千绳；向上方池塘落下的小瀑布，包含水片、泡沫、湿石和喷雾；星球侧肩能望向星空的悬崖边缘。沿路有目的地安排细节：两圈由 12—18 顶菌盖组成的蘑菇环、12—20 块不同大小的巨石、3—4 片不同颜色的野花带、6—8 个带年轮的树桩、带菌菇的倒木、几处小石堆、倾倒的浇水壶、绳圈和长椅上的折叠毯。加入 8—15 只在花带间循环飞行的蝴蝶，低光下池塘与洞口附近有萤火虫，石头与草叶上有小型昆虫细节。站在轨道观察视角时，就应能分辨石环、枯树、池塘和悬崖；走入地表时，小径要不断引导玩家看向不同距离的目标。## Godot 探索与每日循环WASD 在球面行走，重力始终指向星心。第三人称相机平滑跟随，不穿入星球；C 切换 EXPLORE 跟随模式和 OBSERVE 整球自由观察模式。靠近猴面包树按 E 拔除，有拔起动画和地表痕迹，计数到 5/5。靠近两座活火山按 E 清理或添旺余烬，计数到 2/2。两项都完成后才能给玫瑰浇水；条件不足时明确提示。浇水触发 Water 动画及短暂的玫瑰日落镜头。HUD 保持简短，显示 DAY 1 · MORNING WORK 与每日四项：猴面包树、火山、玫瑰浇水、观看日落。长椅处按 R 看日落并累计次数，到第 43 次出现安静的视觉回馈。四项全部完成后光线过渡到第二天清晨，重置每日计数并增加天数。每过一天，星球某处出现一项细小变化，例如蘑菇环长出、花朵开放、秋千摆动或石堆增加一块石头，让世界留下时间流逝的痕迹。## 渲染、性能和工程验证使用 Blender 5.2.1 的 EEVEE 渲染器，当前环境枚举为 BLENDER_EEVEE。先以 640×400 试渲染，最终 1600×1000，使用 AgX 或 Filmic、低角度暖主光和柔和补光。不要使用 Cycles、布料或软体仿真。兼顾 16GB 内存环境，同一时间只运行一个 Blender 进程，每次渲染前保存 .blend。重复物体使用实例或 MultiMesh，保留草的三级密度和距离裁剪；真实游戏窗口中测量并打印 FPS、可见草数量和 draw calls，目标至少 60fps。输出实际三角面数、骨骼数、材质数和实例策略。为角色输出正面、侧面、背面、斜侧、脸部近景、手部近景、行走极限姿态七张检查图。为世界输出低角度斜侧整球、地表探索、角色近景、草与花微距、石环、洞口、瀑布、悬崖、蘑菇环、石堆、玫瑰玻璃罩、池塘和观景台，以及 Godot 探索、观察、日落和每日任务画面。逐张打开检查，写明具体问题和实际修改。玻璃罩和长椅必须在 Godot 中竖直。若方向不正确，打印 Blender 世界矩阵、GLB 节点变换和 Godot 最终四元数，确认根因后修正，不能只靠换截图掩盖。导出 GLB，包含骨骼与三个独立动画，核查草的实例数量和动画是否保留。写验证脚本，测试拔树、火山、玫瑰前置条件、浇水、相机切换、日落计数、每日重置、世界变化和蝴蝶动画，SELF_TEST 必须零失败。运行 Godot 无头检查，确认无错误；若存在 macOS 导出模板，再导出可运行版本。交付最终 .blend、生成脚本、GLB、Godot 工程、检查图、资产报告和验证报告。报告列出阶段完成情况、真实命令结果、性能数字、看过的图片、修改记录和仍然薄弱的地方；每一项通过结论都要有实际运行与查看结果支撑。

↓ 在框内上下滑动，查看完整提示词

可以在地表引力走动，也可以切到观察模式把玫瑰和小径转到眼前，很像一个能拿在手里把玩的微缩玩具。

CASE 05

街机赛车。

雨夜山路、补漆旧车和纸质接车单。按键起步、撞墙反馈、计时和重开全做进去了，按键起步就能玩。

CASE 06

岔路防线。

战术沙盘风格的塔防，建塔、升级、出怪波次和核心血量都有即时联动。三座塔放下去，击杀、资源和核心状态一起跳动，机制很完整。

PART

03

产品展示和原理图，继续上

HARDWARE · STRUCTURE & LOGIC

高精度建模与机械仿真 · HARDWARE & CAD

CASE 07

概念车内饰。

这一组我更喜欢座舱第一视角：方向盘、仪表、中控导航和座椅都在同个画面里，点击还能展开部件说明。

CASE 08

随身听。

同样用 Blender 做产品模型，Kimi 选了透明蓝色仓盖，GPT 则是奶油色机身配深蓝磁带框。卷带、拨轮、按键和外壳材质分开处理，两个版本各有味道。

GPT 这个转台也挺好看，换个角度，磁带仓、按键和金属件的层次很清楚。

参考提示词

PROMPT 04 · 复古随身听 · 产品建模

# 任务：用 Blender 程序化建一台复古随身听，并且自己盯着渲染图改到能看你在一台装了 Blender 5.2 的机器上（命令行 `blender -b -P 脚本.py` 可无头运行）。请从零建一个 3D 产品级模型，交付模型文件和成片渲染。## 交付物1. `build_walkman.py` —— 一段 Blender Python 脚本，从头构建整个场景（模型、材质、灯光、相机）。不许手工摆，全部代码生成，脚本能重复跑出同样结果。2. `out/walkman.blend` + `out/walkman.glb`3. `out/turntable.mp4` —— 8 秒转台动画，800×800，24fps，模型匀速转 360°，背景浅灰渐变，要有接触阴影。4. `out/hero.png` —— 一张产品主图，构图参考消费电子官网：45° 俯视、浅景深、边缘有柔和高光。5. `out/round-*.png` —— 每一轮的渲染自检图。6. `progress.md` —— 每轮你看了图之后，指出**具体哪里不对**（比例、倒角、按键排布、材质粗糙度、灯光位置），然后改了什么，用数字和位置说明。## 物件要求一台 1980 年代便携磁带随身听（Walkman 风格）：- 机身：长方形，圆角，正面分上下两区；机身厚度要正确（不能像块砖，也不能像纸片）- 磁带仓：透明或半透明盖板，能看到里面两个卷盘（带轴心）、磁带有缠绕厚度差异、压带轮- 控制键：播放、停止、快进、快退、录音 5 个实体键，一排，键帽有倒角和高度差- 侧面：音量拨轮（带防滑纹）、耳机口（3.5mm 圆孔，内侧有金属环）、电池盖（有缝隙线）- 材质：机身是哑光塑料（有细微颗粒感）、按键是半光泽塑料、拨轮是金属、仓盖是半透明亚克力、耳机口内圈是镀铬- 铭牌：机身上有一块小铭牌，上面是凸起的品牌名与型号（用建模做出起伏，不许贴图糊上去）## 验收（我自己做）- 运行 `blender -b -P build_walkman.py` 能完整重建场景，无报错。- 转台 mp4 能播，模型转一圈不变形、不出画面。- 主图里卷盘、按键、拨轮、铭牌都清晰可辨，不是一团塑料。- 我拿主图和真实随身听产品照对比，判断像不像。## 硬约束- 全部用 Blender 自带的 Python API。**必须用 EEVEE 渲染器，不许开 Cycles**（这台机器内存只有 16G，Cycles 起来就被系统 watchdog 杀掉）。- 渲染分辨率先用 640×640 试，最终出图 960×960；**同一时间只许有一个 Blender 进程**，渲染完立刻退出，不许常开。- 每次启动 Blender 前先 `memory_pressure | tail -1` 看一眼，free 低于 40% 就等 30 秒再说。- 材质全靠节点程序化生成（噪波、凹凸、渐变）。- 至少自己做 5 轮渲染自检。每轮必须真的渲染出图、真的看图、真的写出一条具体的错。- 单帧渲染控制在 45 秒内，超时就降采样或降分辨率，别把机器拖死。

↓ 在框内上下滑动，查看完整提示词

CASE 09

垂直起飞到向前飞行。

这台原理模型很有意思：两个转子从朝上转到朝前，底座上的仪表和状态说明跟着变化。拖动滑块角度，一眼就能看清倾转旋翼怎么在悬停和前飞之间分工。

CASE 10

NAND 计算机。

汇编、寄存器、RAM 到门级探针集成在同个工作台，单步调试跑乘法，算出的13 × 11 = 143能和波形实时对照，门电路逻辑一目了然。

参考提示词

PROMPT 05 · NAND 计算机 · 真实计算

# 任务：造一台机器，让人相信它真的在算你给学数字电路的人看一个 CPU 演示，他第一反应永远是：这是提前画好的动画，还是真在跑？你要交付的，是让他看完之后不再问这个问题。## 过关的条件他会在你的页面上做三件事，你要让每一件都成立：1. 他手写一段汇编，点「装载」，然后单步。2. 他盯住某一根线，看它在时钟沿之后到底变没变。3. 他故意写一段会出错的程序，看你怎么处理。如果他在第二步停下来，说「等会儿，这个信号是怎么传到这儿的」——你成了。因为他开始怀疑自己的眼睛，而不是怀疑你在演戏。## 你自己要想的事从 NAND 到一台能跑程序的机器，怎么分层是你的事。但有几件事躲不掉：- **一个输入只能有一个来源。** 一个门的输入同时被两处驱动，懂的人一眼就看出来是假的。- **时钟沿不是「刷新一下」。** 它得有先后、有传播延迟，不然单步没有意义——信号该在同一时刻全变，那就等于没算。- **内存里存的必须真的是机器码**，不是一段被翻译成动画的 JSON。- **它跑的程序要有点意思。** 跑「1+1=2」谁都不会信；跑一个能玩的东西，人才会信。- 你怎么让人看见「正在执行哪一条指令」和「哪一个门正在翻转」之间的因果关系？## 底线- 双击 `index.html` 能开，不许联网、不许外链资源、不许用框架。- 深色、等宽字体，像示波器或调试器，不要做成 PPT。- 指令集你自己定，但必须写进文档，并且真的被使用。- 手机上可以只留运行画面和寄存器。## 交付`index.html`、`src/`、`ISA.md`（指令集编码、内存布局、为什么这么设计）、`progress.md`、`shots/`（至少 5 张：门级、单步、跑程序、出错、手机）。

↓ 在框内上下滑动，查看完整提示词

CASE 11

Roadster 三维剖切。

气瓶、管路、喷嘴和底部风扇做成了可旋转模型，转到底部，风扇和管路集中展开，很适合边转边讲整车结构。

CASE 12

SpaceX 着陆。

做成了一台机械教学模型，分段点火、着陆点火和支腿展开过程非常直观，很有工程剖面展品的感觉。

PART

04

横评放在一起看

BENCHMARK · THREE MODELS

三方盲跑硬碰硬 · BENCHMARK

口径全部保持一致：Kimi 与 DeepSeek 走 Claude Code，GPT 走 Codex。

同题盲跑，挑出三个维度看结果：

COMPARE 01

做一片海。

GPT 的海浪厚度与夕阳反光第一眼最抓人，质感无敌；Kimi 把船、航行尾迹以及天气切换面板整套软件壳做齐了；DeepSeek 光比相对平一些，晚霞和阴天各有气氛。

COMPARE 02

照截图搭方块场景。

GPT 的木屋、薄雾、暖窗与水面很有电影成片感；Kimi 做成了可以自由漫游、真实碰撞的世界；DeepSeek 灯笼和落日氛围不错，但在测试机环境下操作受限。

Kimi 这一组的水岸和黄昏单独看，空间开阔度很耐看：

COMPARE 03

同题推进系统解剖。

这道题最考验物理常识。Kimi 绘制了清晰的工程技术图，气瓶、管路与喷嘴层级分明；GPT 采用半透明车壳配铜色管路；

而 DeepSeek 在这里把底盘升力风扇理解成了“吸地”，车身喷气时死死贴在地上纹丝不动，因果逻辑出了偏差。

往里看一层，管路与喷嘴细节对比更加明显：

PART

05

结语

OUTLOOK · EDITABLE DELIVERABLES

说说这几个Case测下来的真实感受。

平心而论，GPT 在整体 case 上的画面审美和电影级调色依然稳坐天花板，成片感确实非常顶，Kimi 在纯画面的细腻度上还有肉眼可见的差距。

但在不少具体场景里，Kimi 的表现相当出彩，甚至在工程完整度上超出了我的预期。比如做那片海，完整做出了船、航行尾迹和天气面板；纯电 SUV 严丝合缝的装配拆解逻辑；

还有那台直接能上手玩的 Godot 小王子。这次测下来我最喜欢的，还是开头那段飞行特斯拉，以及可以亲手拆开的 SUV。

它交付的是直接在 Blender 里打开的Python 脚本、能在浏览器跑的Three.js 源码、能在Godot 里继续开发的游戏工程，看完了还能继续改。

从 7 月份发完 K3 之后，Kimi 沉寂了快三个月。中间海外模型连着发，大家都在催更。这次憋了这么久交出来的 K3.1 Pro，总算没有让人白等。

不过也打个预防针：实际跑长程任务的时候它真的很吃额度，普通 Plus 套餐跑两三个完整 case 基本就碰到 5 小时窗口限流了，基本无法 Coding，要想顺顺当当跑完整长任务，还是得上更高档位的订阅才行。

在大模型做 3D 这件事上，用代码直接调用成熟专业工具底层，把创意真正做成能用的工程，这一波确实拿出了真本事。

Kimi 牛批！

以上。

/// END · KEEP BUILDING

我是甲木，热衷于分享一些 AI 干货内容，同时也会分享 AI 在各行业的落地应用。觉得有用的话，点个赞、在看、转发三连，谢谢大家。