本文来自微信公众号： 硅星人Pro ，作者：董道力


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训练的过去这几个月，国产模型面对的大的环境发生了很大改变，蒸馏带来的收益程度发生改变后，从这一代的提升，甚至“回退”表现上，可以大概看到这些模型接下来的发展方向。


以下为我们的实测。


1


实测K3.1 Pro和K3，进步大吗？


本次测试均在Kimi桌面端进行，界面分别显示K3与K3.1 Pro，模式均为“进阶”。按模型公司传统，模型上架2个礼拜后会开始降智，新模型上架后老模型又会降智。


测试1：前端3D


第一个测试，要求用一个离线HTML文件，做出巨型环形水闸、阶梯海城和能升降的潮水。


提示词要求先把构图、建筑与材质立住，并明确提出：涨落潮不能只靠升降一张蓝色平面，船只、水线和广场淹没状态都要跟着变化。


两版都交出了原生WebGL2单文件，没有外部图片、模型或第三方库依赖。


真正一眼拉开观感差距的，是默认镜头里如何组织场景主次。


K3的巨环很大，但两侧山体占去了更多画幅。首屏大量面积被近处山坡和远山填满，城市缩在海湾深处，建筑群和广场的辨识度偏弱。巨环立在了画面中央，海城却还得费力辨认。


K3.1则把巨环、桥洞、航标塔和层叠住宅组织成了连贯的景观。建筑群沿两岸铺开，中央广场有清楚的同心台阶层次，氧化铜与石材的冷暖质感也更容易区分。它更接近提示词所要求的“完整世界”，脱离了把单个环形物体摆在地形上的生硬感。



水面渲染机制也有实质区别。K3主要用解析天空、太阳高光和灯光拖影来模拟反射；K3.1则额外引入镜像相机，把城市和船只重绘一遍再采样到水面上。这让岸上建筑的倒影有了真实对应的空间来源，属于实现机制上的升级。


但到了最高潮位的参数设置上，K3.1就没那么周全了。按源码中的台阶高度与最高水位核算，K3.1的九层广场台阶在满潮时只有最低四层处在平均水位以下，没有兑现“大部分石阶被淹没”的提示词要求；反倒是首屏不占优的K3，将最高水位范围覆盖到了最外层台阶。


代码里也有一些问题，比如K3.1的船只变换矩阵把竖直方向翻了过去，原本朝上的帆顶被变换到了水面以下；同时相机高度只约束了水位，没有检查山体高度，在允许的参数范围内能算出落在山坡内部的穿山机位。


相比之下，K3的船只没有出现同样的竖直翻转，相机高度也会参考山体表面做约束。


视觉组织与水面表现K3.1做的更好，但项目的完成度、Prompts遵循上K3反而做的更好，比如水位兑现与交互约束。


prompts


请直接在当前目录创建一个独立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确实更懂得安排画面主次，也更清楚该如何把关键结构展示在镜头前。


prompts


请直接使用本机Blender，制作一个具有电影感的原创三维场景：


《木星轨道上的巨舰维修船坞》


这是一次多模型并行测试。请实际完成建模、材质、灯光、相机、渲染和工程保存，不要停留在方案、操作教程或代码展示。


请自主决定未指定的设计细节，持续执行至交付完成。如果环境确实无法运行Blender，请明确说明实际障碍，不要将未执行的脚本描述为已完成的作品。


一、并行测试隔离


本机Blender可执行文件：


/Applications/Blender.app/Contents/MacOS/Blender


统一测试根目录：


/Users/ddl/Documents/Codex/2026-10-24/wo


开始时自动生成唯一任务ID，使用时间戳加随机标识，不要仅使用A、B、test等容易重复的名称，也不需要询问用户。


在以下位置分别创建属于本任务的独立目录：


中间文件：


<测试根目录>/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配套验收文档里明明写着已经修正结束帧偏移，文档表格列出的各段区间也是对的，偏偏最终工程里的起始帧却没对上。


prompts


请使用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主动补上中文字幕，则体现了对中文观看场景的额外照顾。但两者多少都有点声画不同步，并且剪辑过度的比较生硬。


1


K3到K3.1 Pro，Kimi变“油”了


回到开头的问题，K3.1的进步确实明显，尤其是第一眼的观感。在前端3D、Blender建模和像素动画里，它更会安排画面主次，交出来的东西也更像经过打磨的成品。


可一旦打开工程文件，两代模型的胜负就没那么明显了。K3的海城虽然在视觉上吃亏，满潮时淹没台阶和防穿山约束却做得更扎实，像素动画的标签区间也没出错。画面更漂亮的K3.1，反而留下了船只上下翻转、三个动作标签起点各提前一帧这样的疏漏。


某种意义上，Kimi变“油”了。它越来越擅长交出一份让人第一眼就愿意买账的成品。而麻烦也恰恰在于此：表面装点得越像那么回事，接手的人就越容易在检查时放松警惕。


在第五题的成片里，K3.1把黄仁勋谈论争当顶尖AI程序员的片段剪了进去。但他还提到，优秀的AI使用者需要理解工具的运行机制，清楚它的强项与短板。


这句话放在眼下的K3.1身上同样贴切：知道它擅长把卖相做好，才能顺畅地把活接过来；知道它容易在哪些底层细节上露怯，才不至于被漂亮的成品感蒙蔽。