Hands-on test of Kimi K3.1 Pro: Terminal-Bench 4.0 rises to 67.2%, and it can fix simulator errors on its own

文 | 象先志

用上K3.1 Pro，我的第一反应是：快了。哪怕用的是Pro，也比之前的K3快了很多。

K3刚出来的时候，速度确实难以评价。这次测试的时候，感觉一切都丝滑无比。虽然肯定还达不到各家flash那种感觉，但是完全是正常偏快的思考速度。

之前一堆人喊着蒸馏被ban之后国产大模型就不做pro了，Kimi这不就直接出来打小黑子的脸了。

速度思考能力又开始结合

这次我没有开高速模式，普通Pro的速度就已经让我满意。Kimi还推出了Pro Highspeed，按官方说法，效果与普通Pro相同，模型输出速度约为它的2—3倍。

但这不是K3到K3.1的提速幅度。普通Pro为什么变快，官方没有单独解释推理端做了哪些调整。技术博客更多谈的是训练：Kimi增加了后训练投入，让模型在数百个下游领域中接受联合强化学习，也改进了长上下文处理和执行任务的环境。

榜单里，执行任务的成绩涨得最明显。独立评测机构Artificial Analysis公布的综合指数中，K3.1 Pro从K3的44分升到55分，排名第4。终端任务测试Terminal-Bench 4.0则从12.6%升到67.2%，排在该次公布结果的首位。它要求模型在电脑终端中完成任务，通过全部检查才算成功。

独立评测中，执行任务的进步明显，长上下文推理略有回落

对于非技术背景的使用者，办公相关的两项成绩更有参考价值。GDPval-AA比较模型制作文档、表格和演示文稿的质量，K3.1 Pro排到第3。AutomationBench-AA考的是跨邮箱、表格和客户管理系统完成工作的能力，Pro的目标完成得分从58.3%升到了73.3%。

在Kimi公布的成绩表中，Pro也拿到了两项领先：长任务编程测试SWE-Marathon v1.1为51.7%，高于Opus 5.5的46.3%；财务资料问答OfficeQA Pro v2为64.4%，高于Opus的62.2%。两项均排在该表所列模型的首位。这里Pro的成绩由Kimi自测，对手成绩部分来自外部榜单。

进步并不均匀。在官方HLE全量难题测试中，使用工具的Pro拿到70.0%，高于Opus 5.5；不用工具时，Pro只有51.1%，低于Opus的59.8%。AA的长上下文推理测试里，K3（Max）原有88.7%，Pro是86.3%。

官方的人体行走演示更直观：一个虚拟人起初不断摔倒，经过几版训练，逐渐能连续行走。K3.1 Pro编写模拟器、安排训练和评估，再根据实验结果修改方法。过程中，手臂动作一直不理想，调整奖励也没有解决；模型随后检查模拟器，修复了36处肩部肌肉力臂计算错误，再重新训练控制器。

官方演示中，虚拟人从摔倒到学会连续行走

人体的动作由仿真和控制策略产生，Kimi负责根据结果继续改进训练。它没有停在调整奖励上，还找到了模拟器里的错误，这部分比最后走得多像人更让我感兴趣。

做这类长任务，调用量自然会增加。Kimi这次把普通Pro的API输出价格降了下来：每百万输出token，K3为100元，Pro为68元，Highspeed则要136元。Token是平台计算文字和代码用量的单位，包月用户仍按套餐额度使用。

Kimi Code的高速版也要消耗约两倍额度，而且提速只发生在模型输出阶段。读写文件、执行命令和运行程序，仍然需要原来的时间。普通Pro已经够快时，我会先把额度留给后面的修改。

速度上来了，额度未必够用

有用户觉得普通Pro够快了。他贴出的一条调用记录达到每秒111个token，表示不开高速版也够用。

获得Kimi官方提前访问的Chetaslua则放出了网页演示，自述是模型一次生成，并附上CodePen入口，读者可以直接打开看效果。

也有用户在来回修改时碰到了额度问题。

LanceYang给了模型五张参考图，让它做一个可交互的3D游戏手柄。第一版之后又改了两轮，部件形状和空间关系还是不对，模型验证修改结果时又碰到了用量限制。他用的是199元套餐，开始做手柄之前已经用掉了一部分额度。

在知名的鹈鹕骑单车测试中，另一个帖子里的两位用户报出了很不同的消耗。有用户用199元套餐，选高速版和最高思考档，生成后又要求“继续优化”，滚动额度就接近用完。Sanyeg用599元套餐，模型档位相同，却说一个鹈鹕任务只消耗了约6%。套餐、任务和修改过程都不同，很难只看比例判断哪个更划算。所以现在整体看来，token消耗略微有点迷。

按Kimi的规则，各项功能共享月度额度，模型、上下文和工具调用都会影响消耗，Code另外还有滚动用量限制。用户能否顺利完成一个作品，要看从生成到修改的全部用量。

场景有小bug，但能自修复

我选了七道编程题，每道都新建会话，允许Kimi自行运行、检查和修改，结束后再验收首次交付。我们没有替它改代码。图片、动图和提示词节选放在下面，完整提示词及输入素材附在发布包中。

“鹈鹕骑自行车”已经被测得太多，怕有题库优化。所以我们选择：让自行车骑鹈鹕

实际提示词（节选）：画面左右两个同等大小的舞台同时播放，左边表现“鹈鹕骑自行车”，右边表现“自行车骑鹈鹕”。……自行车由鹈鹕背部承托，两个车轮都离开地面，鹈鹕双腿交替迈步并向前行进。

自行车到了鹈鹕上方，却没有落在鸟背上

Kimi做了左右对照：左边鹈鹕蹬车，右边鹈鹕走路，自行车悬在它上方。位置换过来了，车和鸟背之间却空着一截，看不出鹈鹕在承托自行车。这部分应该是逻辑上鹈鹕和自行车前面的节点连接，所以导致后面的悬空，另外一个小问题是自行车的车轮还在一直转，这点逻辑上有点问题，但是也是可以进行优化的。

物理题的表现更好。我们设置了小球在转动的七边形里碰撞，观察实际的碰撞和运行规律，效果还是很不错的。

实际提示词（节选）：正七边形外接圆半径320，以0.2弧度/秒顺时针转动。内部放20个半径12的小球，编号1至20、初始互不重叠，受竖直向下500像素/秒²的重力；……墙面反弹需考虑旋转墙面的局部速度。

小球随边框转动，被带高，再滚回底部

通过持续运行模拟、检查小球位置，没有发现穿墙或丢球。它也把墙面的运动速度算进了反弹过程。这道题交出的初稿，已经可以用来演示重力和碰撞。

声音分析题，我另外换了低音和高音文件，检查频谱是否真能反映输入。

实际提示词（节选）：通过Web Audio API分析实际播放的声音，显示频谱、RMS响度和主频Hz；频率轴范围至少0至4000Hz，使用可解释的真实数据，禁止预编节奏动画。音量滑块影响输出和分析结果。……附带F05-demo.wav可用于开发，但程序须支持其它同格式音频。

换上新的音频，频谱和读数仍然对应得上

换成低音和高音文件后，图表与频率读数都能对应。音量减半，测出的振幅也接近减半；静音后，振幅归零，主频数值不再显示。

不过，短促的声音会在图上拖一会儿才消失。用它看声音的高低、强弱已经够用，想让画面紧跟鼓点，还得调整。

像素跑者只有12×8像素，要用四帧动作表现奔跑。

实际提示词（节选）：用最多32种固定RGB颜色画七彩道路、星空和12×8像素的跑者。跑者有可辨识的四帧跑动循环，身体始终保持12×8逻辑尺寸；道路向左滚动，角色停留在画面水平中心。

四种姿态拼成奔跑动作，人物仍保持像素风格

尺寸、颜色数量和动作帧数都符合要求。小人的胳膊和腿交替摆动，七彩道路向后滚，画面虽然简单，跑动的动作已经能辨认出来。

还有一道，让同一张卡片在按钮、播放器等控件之间连续变形。

实际提示词（节选）：画面中心同一个卡片外壳在16秒内依次变成按钮、加载器、成功勾、播放器、音量控件、开关、柱状图、提示条，再回到按钮。……用形状、圆角、尺寸、图标和文字的连续变换表现状态，不能仅用整页切换。

同一张卡片在按钮、播放器等控件之间变形

大部分变化都顺畅，问题出在最后：提示文字先消失，画面留下空白按钮，下一圈开始时，按钮上的文字突然出现。看截图容易忽略，连续播放就能发现。

回到按钮时，文字突然出现

在测评3D建模能力的部分，我们选择了清明上河图的案例，并且特意要求人物和船都动起来。过桥时，脚下的高度要跟着桥面变化；搬运工则要先取货，再走到码头放下。把镜头拉近，才看得清它有没有把动作和场景配合好。

实际提示词（节选）：请制作一个可在浏览器中自由漫游的3D《清明上河图》场景，重点表现汴河、木拱虹桥、桥头集市、沿河商铺和远处城门。……人物要有可辨认的身体和肢体动作，持续进行不同活动，至少包括沿街行走、过桥、摊前交易，以及在码头搬运货物；船要沿河航行，船上人物随船运动。……行人沿可通行道路、码头和桥面移动，脚贴着当前地面或桥面高度，不走进河里、建筑、摊位，也不从栏杆穿过去。

虹桥、街市和码头都做成了可以环视的三维场景

制作过程中，我看到小人离地，也看到有人走进河里、穿过铺子。这些问题最初都会发生。然后Kimi还是自行优化。

Kimi开始自己逐步调整，穿模问题、人物走过河的问题，这些基本的逻辑问题我们并没有额外增加提示词，并且它还自行修正了人物的高度，也改了穿过商铺的行走路线。

最牛的是，阴影部分的计算都是非常准确的，可以明显感觉模型已经开始理解物理世界的真实规律了。

这些修改发生在Kimi自己的检查过程中，我们没有追加修改提示。

交付版里，搬运工会拿起货物走到码头，再空手返回，顾客也会在摊前停下来。近看仍能发现问题：行人走动时，身体会穿进商铺墙面。河道也有问题：水面被地面挡住，船看起来像在地上滑行。

交付版仍有行人穿入商铺、水面被地面遮挡的问题

最后，我让Kimi做了一套离线视频剪辑器。时间线、预览和导出得使用同一份编辑结果，刷新网页也得保留刚才的修改。

实际提示词（节选）：每个片段可以精确设置入点、出点；支持在当前播放头位置分割片段、删除片段、重新排列片段顺序，以及撤销和重做编辑。……真正导出可播放的 WebM 视频，允许实时导出。导出必须反映剪切和重排后的内容，不能下载原始视频冒充导出。……本地保存项目状态；刷新或重新打开后，能恢复已导入的素材与编辑结果。

剪过的片段重新排列后，可以导出成片

我们把跑者和鹈鹕两段录像导进去，各截取一段，调整成先跑者、后鹈鹕。检查导出的视频，顺序和截取范围都对应得上。刷新网页，素材和剪过的时间线也恢复了。分割、删除、撤销和重做在这轮操作里都正常，这套初稿已经能完成这次简单剪辑。

导出文件还有个小毛病：在测试用的Edge浏览器里，刚打开时读不到视频总时长，要播完一次才能识别。视频内容正确，文件信息还没处理完整。

这一轮里，物理、音频分析和简单视频剪辑已经有实际用途。几道视觉题也交出了可以继续修改的初稿，空间关系和动效衔接仍需检查。

Kimi把Pro称为K3.1系列的首个模型，目前还没有公布Flash或Ultra。如果以后推出Flash，我更看重它能不能降低频繁调用的成本。

多个Agent同时工作，会产生更多的模型调用。如果Flash能以更低的价格、更快的速度处理简单步骤，开发者就能把复杂问题留给Pro。

此前有报道，月之暗面开始招募具身智能人才，一些机器人公司的员工接到了Kimi的招聘电话。报道还援引参与面试人士的说法，称内部对Agentic Robotics（智能体机器人）路线仍有保留。

Google已经尝试把Flash用于机器人。它以Gemini 3.5 Flash为基础，经过专门的具身推理训练，做出了Gemini Robotics ER 2。这个模型负责观察环境、规划和监测任务，再调用下层动作模型执行。

人体行走的演示，再加上具身人才招聘，很难让人不相信，Kimi也想在这个领域继续探索。

我目前最看好的具身方案，就是让强模型参与设计和改进训练，让控制策略在仿真中学会动作；实际运行时，由快速模型观察环境、规划任务，再交给下层控制模型执行。训练可以反复试，机器人面对变化中的环境时，却要及时作出反应。假如Kimi未来有低延迟、低成本的多模态Flash，它就可能用在观察和规划这一部分。

至于Ultra，我期待的是它补上更难的推理和长任务能力。Pro在不用工具的难题测试中仍有差距。

虽然这次测试没有“震惊瘫坐”，但其实可以推断出Kimi在朝着真实物理世界方向以及整体的能力优化提升有着比较稳步的推进节奏，毕竟这次还是在K3的底座上进行优化。

Kimi已经交卷了，现在开源就等Qwen4了。