10 月 24 日，Kimi 放出了 K3.1 系列的首款模型 K3.1 Pro。
从官方介绍看，这是一款三万亿级参数、最高支持百万 token 上下文的大模型，在 K3 的基础上继续加大后训练投入，重点强化编码、3D 创作和金融研究。目前模型已接入 Kimi、Kimi Work、Kimi Code 和 API。
根据评测，K3.1 Pro 的亮点集中在长程编程和工具辅助任务上，不同任务表现分化也比较明显，具体榜单分数可以从下图里看出。
最近国产模型大多在卷量大管饱的 Flash 模型，K3.1 Pro 没有走这条路，而是继续冲击前沿。
作为 3.1 系列，它在 K3 基础上进步了多少，其实比单纯看绝对分数更有意义。因为过去几个月，国产模型面对的竞争环境变化很大，蒸馏路径能带来的收益也发生了变化。从这一代的提升、甚至某些“回退”上，大致能看出这些大模型接下来会往哪个方向走。
下面是我们这次实测的内容。
实测 K3.1 Pro 和 K3，进步大吗？
本次测试都在 Kimi 桌面端进行，界面分别显示 K3 与 K3.1 Pro，模式均选择“进阶”。按模型公司的传统，模型上架两周后会开始降智，新模型上来后老模型往往还会被进一步降智。
测试1：前端 3D
第一个测试要求用一个离线 HTML 文件，做出巨型环形水闸、阶梯海城以及能升降的潮水。
提示词要求先把构图、建筑和材质立住，并且特别指出：涨落潮不能只靠升降一张蓝色平面，船只、水线和广场淹没状态都要跟着变化。
两版都交出了原生 WebGL2 单文件，没有外部图片、模型或第三方库依赖。
真正一眼拉开差距的，是默认镜头里如何组织场景主次。
K3 的巨环很大，但两侧山体占去了更多画幅。首屏大量面积被近处山坡和远山填满，城市缩在海湾深处，建筑群和广场的辨识度偏弱。巨环虽然立在画面中央，海城却还得费力辨认。
K3.1 则把巨环、桥洞、航标塔和层叠住宅组织成了一条连贯的景观线。建筑群沿两岸铺开，中央广场有清楚的同心台阶层次，氧化铜与石材的冷暖质感也更容易区分。它更接近提示词要求的“完整世界”，也摆脱了那种把单个环形物体摆在地形上的生硬感。
水面渲染机制也有实质区别。K3 主要用解析天空、太阳高光和灯光拖影来模拟反射；K3.1 则额外引入镜像相机，把城市和船只重绘一遍再采样到水面上。这让岸上建筑的倒影有了真实对应的空间来源，属于实现机制上的升级。
但在最高潮位的参数设置上，K3.1 就没那么周全了。按源码中的台阶高度与最高水位核算，K3.1 的九层广场台阶在满潮时只有最低四层处在平均水位以下，没有兑现“大部分石阶被淹没”的提示词要求。反倒是首屏不占优的 K3，把最高水位范围覆盖到了最外层台阶。
代码里也有一些问题。比如 K3.1 的船只变换矩阵把竖直方向翻了过去，原本朝上的帆顶被变换到了水面以下；同时相机高度只约束了水位，没有检查山体高度，在允许的参数范围内能算出落在山坡内部的穿山机位。
相比之下，K3 的船只没有出现同样的竖直翻转，相机高度也会参考山体表面做约束。
所以结论是：视觉组织与水面表现 K3.1 做得更好，但项目完成度、prompts 遵循度上 K3 反而更稳，比如水位兑现与交互约束。
完整测试提示词如下：
请直接在当前目录创建一个独立 HTML 文件，命名为「万潮之门.html」。
制作一幅可以交互的、具有电影概念设计质感的三维视觉作品，主题为「万潮之门：潮汐退去后的巨环海城」。
所有 HTML、CSS、JavaScript 和着色器代码内联，离线运行，无外部图片、字体、模型或库。可以使用原生 WebGL、GLSL、Canvas 等技术，主体场景需要具有真实的三维透视与空间关系。
优先把构图、建筑轮廓、光影和材质做好，再添加辅助功能。打开页面后立即呈现完整、最有表现力的场景，适合直接截取 16：9 画面。
【世界与视觉中心】
场景是一座建在巨大海湾中的阶梯海城。
城市中心是一道横跨海湾的巨型环形水闸。它具有厚重的石质结构、分段铜制闸门、连接桥梁和可辨认的建筑尺度。
巨环从一侧山体延伸到另一侧山体，部分结构沉入海中。环内是层层下沉的中央广场，环外是开阔海面。
巨环是画面的视觉中心，但周围必须存在完整世界：岸线、港口、城区、航道、远山和天空。通过微小船只、门窗、栏杆和人物剪影，让观众理解建筑的巨大尺度。
整体视觉尺度达到数公里量级。
【首屏构图】
采用略高于海面的斜侧视角，避免普通俯视沙盘。
前景：画面一角出现靠近镜头的玄武岩、铜制栏杆或残损石阶，边缘清晰，形成空间入口。前景只占少量面积，不能遮住主体。
中景：巨环、层叠城区和中央广场构成主要信息。建筑从水面逐层向山体攀升，密度有变化，保留广场、水道和桥洞形成的空隙。
远景：海湾出口、远山、雪峰和云层逐渐降低对比度，形成明确的空气透视。
通过弧形岸线、桥梁和水道，把视线引向巨环中央。主体轮廓要清楚，避免所有建筑堆成同一种高度和同一种形状。
【建筑语言】
使用玄武岩、浅色风化石材、氧化铜和少量深色金属。
城市至少具有四种可辨认的建筑形态：沿海阶梯住宅；高而狭长的航标塔；带连续拱洞的桥梁与堤岸；围绕中央广场布置的公共建筑。
近景建筑具有门窗凹槽、屋顶层次、柱廊或栏杆；中景保留完整轮廓；远景简化细节。
建筑必须有明确的落脚位置和支撑关系。桥梁连接真实存在的道路或平台，楼梯连接不同高度的可达区域。
【水面与潮汐】
海水采用深青绿与冷蓝色，能够看见波浪起伏、掠射高光，以及岸边较浅区域的颜色变化。
水面反射可以采用合理近似，但需要与天空、光源和主要建筑的位置对应。
潮汐滑块控制整个海湾的统一水位。
高潮时：中央广场的大部分石阶和低层道路被淹没，巨环内部以水面为主，船只漂浮在对应水位。
低潮时：逐渐露出环形石阶、古老道路、浅水池和广场纹样。岸边出现湿润石材与深色水线。
水位变化需要更新岸线、船只高度、露出区域和相关倒影。不能只移动一张透明蓝色平面，却让其他物体保持原样。
【光照与材质】
默认采用「金色退潮」状态：低角度暖色夕阳从画面侧后方照射，巨环边缘被照亮，建筑背光面保持冷色。海面形成有方向的金色反光带，石阶产生清楚的长阴影。
材质之间具有明显差异：玄武岩粗糙、厚重；浅色石材有柔和漫反射；氧化铜整体偏暗，仅局部有金属高光；湿润石阶反光强于干燥石材；海面高光随波浪和观察方向变化。
泛光保持克制。关闭泛光后，建筑层次、材质和受光关系仍然成立。
【主题适配】
提供两套完整环境主题：
「金色退潮」：暖色夕阳、冷青海水、清楚的长阴影，城市细节可辨。控制界面采用温和的浅石色、深色文字与少量铜色强调。
「蓝调涨潮」：太阳已经落下，天空与海水进入深蓝色，城区部分窗户、航标和桥面照明亮起。灯光沿真实建筑分布，水面出现对应反射。控制界面同步采用深蓝灰底色。
主题切换联动天空、主光、环境光、建筑灯光、雾和界面配色。
切换主题时，保留当前潮位、镜头和暂停状态。
【交互与界面】
支持有限范围的镜头环绕和缩放，限制穿入山体或水面。
提供三个预设视角：海湾全景；中央广场近景；穿过巨环的航道视角。
提供潮位、太阳方向、播放暂停、镜头复位和主题切换。
镜头切换应平滑，用户操作时可以打断自动运动。
界面贴合海城题材，像简洁的航海观测工具。主体占据绝大多数画面，控制区域默认紧凑，详细参数可以展开。
提供隐藏界面的截图模式。小屏幕上将控制项收进底部面板，保持城市主体可见。
【验收重点】
初始画面无需操作就具备明确视觉中心、前中后景和完整光影。
暂停后仍然是一幅构图完整的作品。
调低潮位，中央广场与道路逐层露出，船只和水线同步变化。
改变太阳方向，巨环投影和海面反光随之变化。
切换主题后，城区照明、天空、水体和界面一起更新。
从不同视角观察，桥洞、环形水闸和阶梯城区保持正确空间关系。
请完成实际运行文件，并简要说明水面反射、阴影与潮汐采用的近似方法。
测试2：Kimi + Blender
第二个测试用到了 Blender。要求是做一艘停在木星轨道船坞里的巨舰，题目特别规定，发动机拆开的装甲下方必须有真实的几何结构。
在这道题上，K3.1 表现得比 K3 好很多。
K3 的主视角渲染图里，前景栈桥和纵向构件切割了画面，舰首直接在右侧出画；背景里的木星虽然体积很大，表面条带却非常淡，看着更像一颗浅色球体。K3.1 则把船首、中段模块和拆开的舰尾完整收进画框，橙色机械关节清晰可辨，木星表面的褐色条带也把“木星轨道”的场景特征交代清楚了。
切换到近景，两版都能看到真实的骨架、管线和机械臂。其中 K3.1 的承力框、纵横管线、检修走道和栏杆排布更容易读懂，更贴合“检查内部结构”的交付用途。K3 的灰模近景则保留了较强的暖色照明和深阴影，画面氛围虽强，却与结构验收的初衷有些错位。
复核工程文件时，两份 .blend 工程都能通过独立后台进程正常打开，内部保留了分组对象，也没有外链图片或链接库依赖。K3 包含 498 个对象，K3.1 有 941 个。
平心而论，两版模型生成的飞船依然能看出圆柱、方块和重复模块拼装的痕迹，距离成熟的影视资产还有明显差距。但就本次交付而言，K3.1 确实更懂得安排画面主次，也更清楚该如何把关键结构展示在镜头前。
完整测试提示词如下：
请直接使用本机 Blender，制作一个具有电影感的原创三维场景：
《木星轨道上的巨舰维修船坞》
这是一次多模型并行测试。请实际完成建模、材质、灯光、相机、渲染和工程保存，不要停留在方案、操作教程或代码展示。
请自主决定未指定的设计细节，持续执行至交付完成。如果环境确实无法运行 Blender，请明确说明实际障碍，不要将未执行的脚本描述为已完成的作品。
一、并行测试隔离
本机 Blender 可执行文件：/Applications/Blender.app/Contents/MacOS/Blender
统一测试根目录：/Users/ddl/Documents/Codex/2026-10-24/wo
开始时自动生成唯一任务 ID，使用时间戳加随机标识。
在以下位置分别创建属于本任务的独立目录：
中间文件：<测试根目录>/work/blender-benchmark/<任务ID>/
最终交付：<测试根目录>/outputs/blender-benchmark/<任务ID>/
隔离规则：
使用自己启动的独立后台 Blender 进程，通过 Python 和命令行完成工作。首次创建场景时使用 --background 和 --factory-startup。
不要连接任何共享 MCP 服务，不要操控当前已打开的 Blender 窗口。
使用任务独立的用户配置和临时目录，通过子进程级配置实现，不要修改系统或用户的全局环境。渲染、烘焙、模拟缓存和日志均显式写入本任务目录。
不要修改 Blender 全局偏好、安装目录、公共插件或系统级依赖。优先使用 Blender 内置能力。
只管理自己启动的进程，记录其 PID。不要使用 killall、按名称批量结束进程等方式清理任务。
不要读取、参考、修改或覆盖其他测试任务的脚本、工程和结果。查阅 Blender 官方文档不受此限制。
除下面规定的共享渲染锁外，只向本任务专属目录写入文件。
二、共享渲染资源
建模和脚本编写可以并行。实际渲染、烘焙和高负载物理模拟需要排队。
所有任务共用以下锁目录：<测试根目录>/work/blender-benchmark/render.lock
通过原子创建目录的方式获取锁，不要使用“先检查不存在，再创建”的非原子方式。锁内记录所属任务 ID、持锁进程 PID 和开始时间。
只有成功取得锁后才能开始渲染、烘焙或高负载模拟。锁被占用时等待，不要抢占、删除他人的锁或终止他人的进程。
任务结束或发生异常时，可靠释放自己持有的锁。不要在建模、写脚本或普通文件处理期间持有渲染锁。
如果锁疑似异常且无法可靠确认归属和进程状态，请报告情况，保留已完成工程，不要擅自清除。
三、场景设定
一艘长约一点五公里的远航巨舰，停靠在直径约三公里的半开放环形船坞中。巨大的木星占据背景，太阳从侧后方照亮船体。
巨舰经历过一次远航事故，正在接受维修。舰尾部分装甲被拆下，内部暴露出发动机组件、支撑框架、管线与检修平台。几条机械臂伸向舰体，小型维修艇分布在船坞周围。
前景是一段检修栈桥，包含栏杆、设备箱和两名穿宇航服的工作人员。通过人、舷窗、维修艇、巨舰、船坞和行星之间的尺度递进，让观众感受到体量。
上述尺寸用于建立比例关系，不要求为不可见区域制造无意义的几何负担。
四、造型要求
巨舰需要有清楚、独特的整体轮廓。舰首、居住段、货运段和发动机段应具有不同的结构特征，并通过合理的连接关系组成整体。
避免将主体做成一根简单圆柱，再通过随机小方块装饰表面。
船坞需要包含主承重框架、环形结构、检修平台、连接通道和至少三条机械臂。机械臂需要有底座、关节、臂段和末端工具，连接关系应清楚。
拆开的装甲下方需要有真实的内部几何，包括支撑、设备和管线连接。不能只用发光平面或纹理代替内部结构。
将细节集中在能够解释功能的地方，例如装甲接缝、散热片、舱门、对接接口、检修设施和管线固定点。
允许使用基础几何、曲线、修改器、几何节点和实例化。重复模块之间应有适当变化，同时保持整体设计语言一致。
主体自行建模，不下载现成飞船、船坞或完整场景。允许程序化材质，不使用生成图片替代主体几何或背景建筑。
五、视觉要求
整体采用克制的工业科幻风格，以骨白、深灰和金属色为主，少量橙色用于检修设备和警示区域。
主镜头从前景检修栈桥向外看，兼顾巨舰轮廓、船坞结构和木星背景。画面要有明确的视觉中心、遮挡关系和远近层次。
宏大感应建立在比例、构图、结构密度和空间纵深上。主角轮廓需要清楚，避免所有区域都堆满相同密度的细节。
使用有方向感的光线。允许适当的氛围效果，但主体结构必须可辨，不能用过暗曝光、浓雾、强烈泛光或过重景深掩盖几何问题。
六、执行流程
先搭建整体灰模，检查比例、主体轮廓和空间关系，再完善结构、材质与细节。
先输出低分辨率预览，实际打开并查看渲染图片，检查主体是否入镜、曝光是否正常、结构是否清楚，以及是否存在明显穿插或悬空。
允许最多两轮根据预览结果的视觉修正。程序运行错误可以另外修复，请如实记录，不要将失败的渲染算作有效预览。
完成后输出最终图片。本轮先完成静态场景，不制作动画，也不额外展开复杂物理模拟。
保存最终工程后，通过独立后台进程重新打开，检查模型、材质、相机及必要资源是否完整。不要让交付文件依赖即将删除的临时文件。
七、最终交付
将以下内容保存到本任务的最终交付目录：
1. 可继续编辑的 .blend 工程。
2. 完整生成脚本及必要的辅助文件。路径尽量参数化，并说明复现方式。
3. 一张 1920×1080 的主视角渲染。
4. 两张从不同方向观察主体的渲染，其中至少一张展示主镜头没有充分展示的一侧。
5. 一张发动机内部结构或机械臂的灰模近景，使用中性材质和清楚的照明，便于检查真实几何。
6. 一份简短的 README.md，记录任务 ID、实际 Blender 版本、渲染引擎、主要制作方法、复现命令，以及尚未完成或未验证的部分。
按功能组织集合和对象，使用有意义的名称。保留后续局部编辑的可能性，不要为了导出结果将整个场景不可逆地合并为一个对象。
完成后在回复中展示主视角和关键近景，提供最终文件的绝对路径。只汇报实际执行和验证过的结果。
测试3：像素动画
第三题要求调用 skill，制作一段云海驿站的飞艇补给像素动画。画面需依次完成飞艇进港、工人交接货箱、吊运离港、场景复位四个阶段，同时保留分层工程，静态背景层需复用链接帧（linked cels）以避免重复存储。
两版成品都符合画布尺寸、总帧数和单帧时长的要求，工程内也都包含 14 个图层，并且使用了链接帧。
K3.1 的画面更耐看，它更会安排场景尺度和动作区域。近景的仓库、钢梁、窗户与远处山城构成了完整的空间，人物、货箱与吊钩占据了更大的可读区域。观众能清楚分辨出工人是在搬运货箱、挂上吊绳，还是在原地等待货箱起吊离地。
K3 绘制的飞艇造型本身不错，整体场景也更疏朗，但最关键的货箱交接区域偏小，人物、暖色像素簇和细吊绳容易混成一团。
然而一旦打开可继续编辑的源工程，K3 却在动作标签的准确性上扳回一局。
以从 0 开始的帧号计算，交接、离港、复位三段标签的帧区间应当分别是 24—47、48—71、72—95。
K3 在工程里的设置全部正确；K3.1 却把这三段写成了 23—47、47—71、71—95，结束帧虽然准确，起始帧却各自提前了一帧，导致相邻动作的标签区间重叠了一帧。完整 GIF 仍能正常播放，但只要按这三个错误标签单独导出动作切片，开头就会多取上一段动作的末帧。
这其实不是什么大问题，但却是下游接手时最让人头疼的那类小差错。而且更诡异的是，K3.1 配套验收文档里明明写着已经修正结束帧偏移，文档表格列出的各段区间也是对的，偏偏最终工程里的起始帧却没对上。
完整测试提示词如下：
请使用 pixel-art-animator skill，制作一段复杂的像素动画：
《云海驿站：夜班补给》
基础绘制和导出可以配合 pixel-art-creator、pixel-art-exporter。最终需要交付真实可编辑的 Aseprite 动画工程，保留图层、帧、时长和动画标签。
【作品目标】
一座建在巨大峡谷边缘的空中货运驿站，在深蓝夜色中等待最后一艘补给飞艇。
飞艇靠泊，工人从仓库搬出货箱，将它挂到吊钩上。货箱升空，飞艇离港，工人返回仓库，场景恢复到下一轮开始前的状态。
作品要像一段精致的独立游戏场景动画。画面丰富、动作清楚，暂停时仍然是一幅完整的像素插画。
【画布与像素规范】
原生画布为384×216像素，横向16：9构图。
共96帧，每帧100毫秒，总时长9.6秒，完整循环播放。
全片使用同一套固定色板，最多32种不透明颜色，另允许透明索引。开始绘制前确定色板，保存为palette.json。
采用清晰的像素边缘，以色块、明暗分层和适度抖动表现体积。
禁止模糊、平滑缩放和半透明边缘。各图层像素的透明度只能为0或255。放大预览使用最近邻整数倍缩放。
所有元素在原生分辨率下制作，不用高分辨率插画缩小代替。
【构图与美术】
远景：峡谷两岸层叠的巨大山体、云海、远处桥梁与零星城市灯火。远景颜色偏冷、对比度较低，表现辽阔空间。
中景：从悬崖伸出的货运平台、仓库、巨型风车、悬桥和飞艇。货运平台是主要动作发生的位置。
近景：画面边缘安排较大的管道、钢梁或检修栏杆，形成前后遮挡。不要遮住工人交接货箱的关键动作。
建筑使用深色金属、旧木材、铜制管线与局部暖色窗光。飞艇具有完整船体、驾驶舱、推进结构、货运吊架和可辨认的表面细节。
飞艇占据足够大的画面面积，工人保持较小比例，通过人物、栏杆和门洞衬托建筑与飞艇的尺度。
主色为深蓝、灰紫和冷青色，仓库灯与飞艇灯使用琥珀色。暖色集中在主要动作区域。
避免把细节平均铺满整个画面。视觉顺序应是飞艇与交接动作，其次是驿站，最后是远景。
【完整动作时间线】
以下帧号统一按1开始计数。
第1—24帧，approach：飞艇从画面外进入，逐渐减速并靠近停泊位置。船体先移动，悬挂结构稍有滞后，再逐渐稳定。工人打开仓库门，准备取出货箱。固定在建筑上的信号灯回应飞艇靠泊。
第25—48帧，handoff：工人抱着货箱走到装卸点。放下货箱，调整吊钩或挂带，确认连接后退开。动作需要有明确的准备、接触、承重转移和松手过程。不能让货箱直接瞬移到吊钩下面。
第49—72帧，depart：绞盘收绳，货箱离开平台。货箱完全离地后，飞艇开始离港。货箱可以有轻微滞后摆动，但挂点、绳索长度和箱体关系要可信。工人观察飞艇离开，衣物受到短暂气流影响。
第73—96帧，reset：飞艇带着货箱完全离开画面。工人返回仓库，关门并恢复初始姿势。受飞艇影响的衣物和局部烟雾逐渐平复。仓库内部可以隐藏下一轮货箱，但不能在观众看得见的位置凭空生成。
第96帧接回第1帧时，故事与环境都应自然衔接。
整段故事向前播放，不能把后半段倒放来制造循环。
【多组环境动画】
环境不能全部采用相同节奏。
风车：24帧一个循环，绕固定轴心转动。
旗帜：16帧一个循环，旗根固定，布面产生波动。
信号灯：32帧一个循环，亮灭有清楚节奏。
云层：96帧完成一个无缝滚动周期，使用可连续重复的云形。
飞艇尾部气流或蒸汽：根据靠泊、吊装和离港状态变化。
环境动画在工人停顿时继续运行。不要通过延长一张全局帧的时长，让所有东西一起停住。
云和烟使用有组织的像素簇，避免满屏随机噪点。
【角色与接触关系】
工人拥有稳定的体型、服装配色和可辨认轮廓。
走路时双腿交替，脚掌着地阶段不能明显滑动。搬运时身体重心应发生变化，不能只把普通走路姿势平移。
抱箱时：双手接触箱体，货箱跟随手臂与躯干运动。
放箱时：箱底贴合平台，身体随后松开承重。
挂钩时：手、挂点、绳索和箱体的位置对应。
吊起时：货箱从挂点下方受力，不能先漂浮再接上绳索。
工人进入仓库时，门框、门扇和人物的前后遮挡正确。
【光照与阴影】
固定主光来自右上方的冷色月光。
仓库门口有固定暖光，工人靠近和远离时，受光表现应有所变化。
飞艇具有局部移动灯光。灯光扫到平台、工人或货箱时，对应表面才变亮。
动态高光和投影需要跟随飞艇与货箱的位置变化，不能只让灯具自身闪烁。
飞艇离开后，移动暖光逐渐消退，场景回到月光与仓库灯主导的状态。
所有明暗变化仍然使用固定色板，通过像素色块替换表达，不使用模糊光晕。
【图层与动画工程】
至少将以下内容组织为独立、具名图层：
远景山城；云层；驿站固定结构；仓库门；风车；旗帜；信号灯；飞艇；工人；货箱；吊钩与绳索；动态受光与阴影。
必要时可以增加图层，方便局部修改。
静态背景使用linked cels。
重复环境周期中内容完全相同的相位，可以复用或链接。
动作不同的角色姿势、货箱位置和动态阴影，必须保持可独立编辑。
创建以下标签，方向均为forward：
main_loop：第1—96帧。
approach：第1—24帧。
handoff：第25—48帧。
depart：第49—72帧。
reset：第73—96帧。
工具或导出格式如果采用从0开始的帧号，正确转换，并在说明中标明。
【制作顺序】
先完成一张构图和色彩都完整的关键画面。
再完成靠泊、抱箱、挂钩、吊起、离港和恢复初态的关键姿势。
确认动作与接触关系后，再补中间帧、环境循环和动态光照。
过程中定期检查，避免复制帧后只改位置，却遗漏姿态、阴影和遮挡变化。
【交付文件】
night_supply.aseprite：保留可编辑图层、96帧、时长、标签与linked cels。
night_supply.gif：原生分辨率，完整无限循环，动作与源工程一致。
night_supply_sheet.png和对应JSON：导出全部96帧，保留帧位置、时长和标签信息。
night_supply_cover.png：选择最能表现飞艇、工人和吊装关系的一帧，最近邻放大4倍。
palette.json：实际使用的固定色板。
verification.md：记录实际完成的检查、发现并修复的问题，以及仍未解决的问题。
【交付前验收】
检查画布、帧数、总时长、色板和透明度。
连续播放至少三遍，重点检查第96帧接第1帧的位置，不能出现飞艇回跳、人物瞬移或云层断裂。
逐帧检查抱箱、落地、挂钩和离地几个接触时刻。
单独播放各环境循环，确认周期不同且衔接自然。
检查静态背景是否保持一致，动态角色是否被错误链接到不同姿势。
按相关skill执行像素质量检查，保存检查结果。
最后重新打开导出的GIF和源工程，确认交付文件实际可用。
测试4：屎山代码适配 iPhone Duo
第四题用上了我们的老朋友，硅星人官网工程。我把它交给两版模型，要求它们适配 iPhone Duo。原项目里本来就已经写好了基础的折叠屏布局和预览工具。
K3 的排查覆盖面更广：它补充了动态视口高度，让登录、注册和助手面板能跟随可用高度变化；同时识别出应用商店截图尺寸与物理屏幕分辨率的差别，引用第三方视口说明，把内屏预览尺寸从 951×669 改成了 890×626，并在工程里保存了多轮诊断截图。
K3.1 的修改则更聚焦在折痕避让与状态同步上：它让首页区块标题和“查看全部”入口分居折痕两侧，补充了上下分区模式下的滚动间距，并修正了预览 iframe 的地址状态管理，让当前所选页面与界面记录的地址保持一致。
留存的测试报告显示，K3 跑通了六项折叠预览测试，K3.1 则跑通了七项，多出来的正是首页标题与入口避让折痕的专项检查。
这道题没有谁好谁坏，毕竟苹果自己都不知道该怎么搞折叠屏视频。简单来说，K3 排查得更广，K3.1 修补得更集中，实际工程既需要这两种能力。
测试5：剪视频
最后一题最贴近日常办公需求：给模型一段黄仁勋的英文访谈，让它剪出一条一分钟左右的精华短片。
K3 交出的成片时长 65.3 秒，K3.1 为 62.2 秒，分辨率均为 720p，都符合“一分钟左右”的要求，但在内容上两者区别不小。
K3 把内容收束在“国家 AI 主权”这一条主线上：从哈萨克斯坦建设 AI 国家切入，讲到把能源转化为智能出口，再落脚到本国数据、文化和价值观的自主权。几个片段始终围着同一件事展开，作为一条观点短片，主题相当集中。
K3.1 则剪出了一条更面向大众传播的 AI 机会短片。在谈完能源之后，内容转向农民、科学家和工程师如何借助 AI 放大自身能力，最后落到个人抱负与成为顶尖程序员。主动压制的中文烧录字幕让观看方便了不少，但从国家能源一路跳到个人能力，整条短片的话题跨度也明显更大。
至于谁好谁坏，可以看一下原片对比。
提示词里并没有要求配字幕，因此 K3 在完成片段剪辑后未加字幕不构成错误，而 K3.1 主动补上中文字幕，则体现了对中文观看场景的额外照顾。但两者多少都有点声画不同步，并且剪辑过度的部分比较生硬。
K3 到 K3.1 Pro，Kimi 变“油”了
回到开头的问题，K3.1 的进步确实明显，尤其是第一眼的观感。在前端 3D、Blender 建模和像素动画里，它更会安排画面主次，交出来的东西也更像经过打磨的成品。
可一旦打开工程文件，两代模型的胜负就没那么明显了。K3 的海城虽然在视觉上吃亏，满潮时淹没台阶和防穿山约束却做得更扎实，像素动画的标签区间也没出错。画面更漂亮的 K3.1，反而留下了船只上下翻转、三个动作标签起点各提前一帧这样的疏漏。
某种意义上，Kimi 变“油”了。它越来越擅长交出一份让人第一眼就愿意买账的成品。而麻烦也恰恰在于此：表面装点得越像那么回事，接手的人就越容易在检查时放松警惕。
在第五题的成片里，K3.1 把黄仁勋谈论争当顶尖 AI 程序员的片段剪了进去。但他还提到，优秀的 AI 使用者需要理解工具的运行机制，清楚它的强项与短板。
这句话放在眼下的 K3.1 身上同样贴切：知道它擅长把卖相做好，才能顺畅地把活接过来；知道它容易在哪些底层细节上露怯，才不至于被漂亮的成品感蒙蔽。
如果你也关注这类开发者向的模型实测，不妨多去看看真实工程文件和底层细节，而不是只停留在第一眼的观感上。
发表于 1 小时前
|
查看: 8|
回复: 0
