大家好 我是为什么叫QQ

Hello everyone, I'm WhyCallQQ.

一个开放权重模型 在终端编程测试里拿到65.7分

An open-weight model scoring 65.7 on a terminal coding benchmark,

离Claude Opus 5.5只差0.7分

just 0.7 points shy of Claude Opus 5.5.

看到这张图 我也很想直接说一句 平替来了

Looking at this chart, it's tempting to call it an open-source drop-in replacement.

但程序员每天面对的 远远不止一张排行榜

Yet developers face far more each day than a leaderboard ranking.

你要处理依赖冲突 要读懂前任留下的代码

You have to resolve dependency conflicts, decipher legacy code,

还要在测试红了以后继续查

and debug when test suites turn red.

Kimi K3.1 Pro这次值得看的

What really makes Kimi K3.1 Pro worth watching

是它能在一项任务里走多久 出错以后会不会修正

is how long it stays on task, whether it self-corrects after failures,

以及整条链路要花多少钱

and how much the entire pipeline costs.

跑分只负责让它进入候选名单

Benchmarks only earn it a spot on the shortlist;

项目里的验收结果才决定它能不能留下

acceptance testing in real repos decides if it actually stays.

否则分数再高 也只会多制造一批需要返工的提交

Otherwise, high scores just produce another batch of commits that need rework.

官方发布帖给出的规格是2.8万亿总参数

The official release post lists 2.8 trillion total parameters,

每个Token激活1040亿参数 采用MOE架构

activating 104 billion parameters per token via an MoE architecture,

支持多模态和百万Token上下文

with multimodal support and a 1-million-token context window.

Highspeed版本主打两到三倍速度

The Highspeed edition boasts 2x to 3x throughput,

普通版和高速版已经能用于Kimi Code与API

and both standard and high-speed tiers are already live in Kimi Code and the API.

完整权重计划在2026年11月4日前发布

Full model weights are scheduled for release by November 4, 2026.

截至录制当天 这仍是发布计划

As of recording, this remains an upcoming release schedule.

很多人会觉得 参数这么大 离个人开发环境很远

Many assume a model this massive is out of reach for local dev rigs,

这个判断基本符合现状

and that assumption is largely accurate.

开放权重给了你自托管和审计的入口

Open weights give you an avenue for self-hosting and auditing,

硬件门槛却不会随许可证一起消失

but hardware barriers don't vanish with an open license.

个人用户更现实的入口 仍是云端API和托管服务

For individual developers, cloud APIs and hosted endpoints remain the practical path.

K3.1 Pro基于K3做后训练

K3.1 Pro builds upon K3 through post-training,

官方把主要投入放在更大规模的联合强化学习

with the team investing heavily in larger-scale joint reinforcement learning.

为了覆盖数百个下游领域

To cover hundreds of downstream domains,

他们同时改了训练框架 长上下文推理

they overhauled the training framework, long-context inference,

沙箱 任务调度和环境质检

sandboxes, task scheduling, and environment quality checks.

这里有个很关键的地方

Here lies a critical takeaway:

模型在Agent任务里的表现

an agent's performance on real-world tasks

也取决于它练习过的环境是否稳定 反馈是否可靠

depends heavily on how stable its training sandbox is and how reliable its feedback loops are.

你让模型反复修代码 测试本身却时好时坏

If you train an agent to iterate on code while tests are flaky,

它学到的可能只是应付测试

it may only learn to game the test runner.

这也是评估Agent平台时经常被忽略的一层

That's an often-overlooked factor when evaluating agent platforms.

你觉得编程模型的下一轮竞争

Do you think the next round of coding model competition

会更偏数据 环境 还是基础架构？

will hinge more on data, environments, or infrastructure?

把你的看法打在公屏上

Drop your thoughts in the comments.

官方图表里 Terminal- Bench 4.0的65.7分很亮眼

On the official chart, Terminal-Bench 4.0's 65.7 score looks impressive,

高于GPT-6 Astra的58.2分

outperforming GPT-6 Astra at 58.2.

可到了Terminal-Bench Science 0.1

Yet on Terminal-Bench Science 0.1,

K3.1 Pro是38.1分 GPT-6 Astra是68.1分

K3.1 Pro scores 38.1 while GPT-6 Astra hits 68.1.

另一个内部长程任务测试Kimi Code Bench 3.0

On their internal long-horizon benchmark, Kimi Code Bench 3.0,

则从K3的55.95升到61.2

its score climbed from K3's 55.95 up to 61.2.

三组数字放在一起 比一句“全面领先”有用得多

Putting all three numbers together tells a far more nuanced story than claiming across-the-board dominance.

不同任务的能力分布并不均匀

Capabilities are unevenly distributed across different task profiles.

内部测试也需要第三方复现

Internal benchmarks also require third-party replication.

你选型时至少要跑两类任务 一类贴近日常业务

When evaluating models, test at least two task types: one matching daily workflows,

另一类专门覆盖它可能不擅长的边界

and another stress-testing edge cases where it might stumble.

榜单脚注里的harness和推理设置

And make sure to screenshot the benchmark harness details

也应该一起截图保存

and inference settings right from the footnotes.

官方内部案例里

In an official internal case study,

模型基于human-atlas搭建人体行走仿真

the model built a human walking simulation on human-atlas,

经历167个任务和420次独立评审

working through 167 tasks and 420 independent reviews

让角色连续行走11.2秒

to keep the character walking for 11.2 seconds.

奖励塑形没能改善手臂动作后

When reward shaping failed to improve arm motion,

它做了开环动力学探测

it ran open-loop dynamics probing,

修正36处肩部肌肉力臂计算错误 再重新训练

fixed 36 shoulder moment-arm miscalculations, and retrained.

官方页面没有给出完整轨迹

The announcement page doesn't share the full trajectory,

不能当成普遍能力证明

so this shouldn't be taken as proof of generalized capability.

我很喜欢其中展示的排查路径：

Still, I really appreciate the troubleshooting path it demonstrated:

实验受挫后 模型开始检查被测系统

faced with setbacks, the model began inspecting the system under test.

工程里的很多Bug也藏在假设里

Many real-world engineering bugs lurk inside faulty assumptions.

测试一直失败 除了改实现 还得有人验证测试

When tests keep failing, don't just rewrite implementation—verify the tests,

工具和物理模型

the tooling, and the physical models.

所以我会把环境自检列进Agent的默认排查步骤

That's why I'd make environment self-inspection a default debugging step for agents.

官方演示覆盖了Unity Unreal和Godot

Official demos covered Unity, Unreal, and Godot,

也展示了完整游戏与网页场景

alongside complete games and web-based 3D scenes.

画面确实适合传播 但项目能否维护

The visuals look great for social media, but real-world maintainability

要看另一组东西：

depends on a very different set of factors:

依赖有没有锁定 资源路径是否稳定

are dependencies pinned, are asset paths stable,

场景能否重复构建 改动有没有越界

can the scene be rebuilt reproducibly, and did changes bleed out of scope?

你接手AI生成的项目时

When taking over an AI-generated codebase,

可以先要求它输出运行命令和验证步骤

start by asking for exact run commands and verification steps,

再让它补一条最小测试

followed by a minimal automated test.

别让一次成功运行变成唯一的验收标准

Never let a single successful run be your only acceptance gate.

能重新clone 重新安装 重新跑通

Cloning fresh, reinstalling cleanly, and passing end-to-end

才开始接近可交付

is what actually moves code closer to production-ready.

再检查Git diff 防止它顺手改动无关模块

Always inspect the git diff to catch unintended edits to unrelated modules.

对程序员来说

For developers,

这比演示视频里多一个光效实在得多

this matters far more than an extra lighting effect in a promo video.

BenchCAD的图很适合观察工具的价值

The BenchCAD chart clearly illustrates the power of tool usage.

K3.1 Pro使用工具时是92.7分

With tools enabled, K3.1 Pro scores 92.7,

不用工具的单次生成是72.8分 相差19.9分

compared to 72.8 on single-turn generation without tools—a 19.9-point jump.

它还能直接编写并运行Blender和CAD脚本

It can also write and execute Blender and CAD scripts directly,

修改几何 材质与场景布局 无需MCP连接器

manipulating geometry, materials, and scene layouts without MCP connectors.

可复用的经验在这里 把生成结果接进可执行环境

The reusable takeaway is clear: plug generation into an executable runtime.

模型写出参数化脚本

The model produces parametric scripts,

软件负责运行 评分程序检查输出

the host software executes them, scoring scripts validate the output,

失败信息再回到下一轮

and error diagnostics feed into the next iteration.

单靠提示词让模型“想得再仔细一点”

Merely prompting the model to 'think harder'

很难替代这条反馈链

can never substitute for an executable feedback loop.

你的Agent项目也可以先补齐执行器和检查器

For your own agent pipelines, prioritize building solid executors and validators;

这比单纯增加提示词长度 更接近可靠自动化

that gets you much closer to reliable automation than bloated prompts.

API使用OpenAI SDK 替换base_url

The API works with the standard OpenAI SDK—swapping base_url,

密钥和模型名就能发出基础请求

api_key, and model name is enough to send basic requests.

不过有几个细节会影响迁移

However, several migration details demand attention.

K3.1 Pro始终开启思考

K3.1 Pro has reasoning permanently enabled;

reasoning_effort可选low high max 默认是max

reasoning_effort accepts 'low', 'high', or 'max', defaulting to 'max'.

temperature top_p等参数被固定 请求里应省略

Parameters like temperature and top_p are fixed and should be omitted from requests.

流式响应把reasoning

Streaming responses separate reasoning

_ content和最终content分开 前端别混着渲染

_content from final content, so don't mix them up in the frontend.

推理档位可以按任务挑

You can tune reasoning effort to each workload:

长任务值得对比max 简单修改可以先测low

benchmark 'max' on long-horizon tasks, and start with 'low' for simple patches.

把质量和账单一起记录 别只看回答有没有变长

Track quality alongside token costs—don't just gauge whether responses grew longer.

官方国际站价格里

According to the official international pricing,

普通版每百万Token输入2美元 输出10美元

the standard tier costs $2 per million input tokens and $10 per million output tokens,

缓存命中输入0.2美元

with cache hits priced at $0.20 per million input tokens.

Highspeed是输入4美元 输出20美元

Highspeed costs $4 for input and $20 for output per million tokens.

它始终思考 推理Token也会进入实际消耗

Because reasoning is always on, thinking tokens add directly to your usage.

Hacker News上有人因此担心

Some commenters on Hacker News worry

单价下降未必带来单任务成本下降

that lower unit prices won't necessarily reduce per-task costs.

这个担心值得用实验回答

That concern is best settled with real empirical testing.

建议你固定一批任务

We recommend pinning a representative benchmark suite,

记录成功率 重试次数 总Token和人工返工时间

logging success rates, retry counts, total tokens, and manual rework time.

高速版适合对延迟敏感的交互

Use the Highspeed tier for latency-sensitive interactive sessions,

普通版可以先跑离线任务

and run batch offline tasks through the standard tier.

选型看每个通过验收的任务花多少钱

Base your model selection on cost per accepted task,

账面单价只是一部分

since sticker prices only tell part of the story.

缓存写入费也要算进长前缀任务

Cache write fees must also be factored into long-prefix tasks,

百万上下文也不建议每次整库重传

and a 1M context doesn't mean re-uploading entire repos on every turn.

API会自动缓存符合条件的重复前缀

The API automatically caches qualifying duplicate prefixes,

TTL可选5分钟或1小时 写入单独计费

with TTL options of 5 minutes or 1 hour, billing writes separately.

不足一个缓存块的部分无法写入

Sub-block fragments cannot be written to cache.

工具调用还有一处容易踩坑：

There is another common pitfall with tool calling:

多轮请求要完整回传assistant消息

multi-turn requests must return full assistant messages

再追加匹配的tool结果 不能只保留content

followed by corresponding tool results—never discard tool calls and keep just content.

动态加载的工具定义也要留在历史里

Dynamically loaded tool definitions must remain in the conversation history;

服务端不会替你保存

the server will not retain them for you.

官方网页搜索正在更新

The built-in web search tool is currently being updated,

文档暂不建议用于近期生产流程

and official docs advise against using it in production for now.

现有项目接搜索前 要准备替代工具和失败降级

Before plugging search into existing stacks, prepare alternative tools and fallbacks,

工具定义有变化时 也要重新跑一轮兼容测试

and rerun compatibility tests whenever tool definitions change.

官方内部压力测试里

In official internal stress tests,

Kimi Hallu Bench Hard的陈述

on Kimi Hallu Bench Hard, statement-

级幻觉率从K3的23.4%降到8.3%

level hallucination rates dropped from K3's 23.4% to 8.3%,

发布帖把它概括为下降约65%

summarized in the launch post as a roughly 65% reduction.

这个方向很有价值

This is a promising trend,

但官方也提醒 题目专门挑选容易出错的场景

though the team notes the dataset specifically curates error-prone prompts,

不能推成日常错误率 代码助手同理

so it shouldn't be extrapolated to everyday coding error rates.

它能写出看似完整的迁移脚本

While it can generate seemingly thorough migration scripts,

仍可能漏掉数据兼容和回滚条件

it might still miss backward compatibility or rollback logic.

涉及生产环境时 给模型只读权限起步

When touching production code, start by giving the model read-only permissions,

要求引用文件与行号 再用测试和人工评审兜底

require file-and-line citations, and safeguard with automated tests and human review.

可靠性要落进流程 不能只挂在模型宣传页上

Reliability belongs in engineering workflows, not just promotional slides.

没有这些约束 再低的平均错误率也难落地

Without these guardrails, even the lowest error rates will fail in production.

网络安全部分有个少见的对照

The cybersecurity section offers a rare comparative datapoint.

未做相关数据清理的内部检查点

An uncurated internal checkpoint

在xdev-bench-hard上pass@3为90.5%；

scored 90.5% pass@3 on xdev-bench-hard,

发布版做了训练数据与强化学习环境过滤后

while the release checkpoint, filtered for training data and RL environments,

得分是81.0%

came in at 81.0%.

Hacker News评论区对此分成两派

Hacker News commenters split into two distinct camps:

一方担心防御能力也被削弱

one side worries defensive auditing capabilities were also hobbled,

另一方支持控制开放权重的攻击能力

while the other supports curtailing offensive capabilities in open weights.

两种担心都真实存在

Both concerns are entirely valid.

团队做安全审计时 可以把模型放在隔离沙箱

When conducting security audits, isolate the model inside a quarantined sandbox,

限制网络与凭据 保存完整操作日志

restrict network access and credentials, and retain full operational logs.

通用编码能力增强也会外溢到漏洞研究

Stronger general coding skills naturally spill over into vulnerability research;

权限设计不能依赖模型自觉

security architecture must never rely on model self-discipline.

开放权重之后 这些防护更需要部署方自己完成

With open weights, implementing these safeguards falls squarely on the deployer.

Hacker News的讨论还集中在两件事：

Hacker News debates also centered on two recurring themes:

开放权重能否真正自托管 API与订阅怎样比较

whether open weights can genuinely be self-hosted, and how APIs compare to subscriptions.

3T级模型对多数个人设备都不友好

A 3T-parameter model is impractical for almost all personal hardware,

社区里的失落很具体

and the community's frustration is understandable.

另一边 单纯拿API单价和包月订阅对比

On the flip side, comparing raw API token pricing directly against flat subscriptions,

也会漏掉用量与限额

overlooks actual token consumption and rate limits.

我的判断是 先分清你购买的是哪种控制权

My take is to first clarify what kind of control you're paying for:

API省去运维 适合快速验证；

APIs eliminate ops overhead and enable rapid prototyping;

自托管涉及数据 定制和基础设施控制

self-hosting provides data sovereignty, customization, and infrastructure control,

成本也要另算 这个分歧很适合交给实践检验

though at substantial operational cost. This trade-off is best settled in practice:

你更愿意为省心的订阅付费

would you rather pay for a friction-free subscription,

还是为可控的部署付运维成本？

or invest ops effort into a self-controlled deployment?

把看法打在公屏上

Drop your thoughts in the comments.

两种方案没有统一答案 团队约束会先替你筛选

There's no universal answer—team constraints will usually decide for you.

看到这里你可能会想 自己的项目该怎么试

At this point, you might wonder how to evaluate this for your own codebase.

我会留一份固定任务集

I recommend building a fixed benchmark suite containing:

里面放一个小Bug 一次跨文件重构

one isolated bug fix, one multi-file refactoring task,

一个需要工具的长任务

one tool-dependent long-horizon problem,

再加一个过去失败过的案例

and one historical edge case where previous models failed.

每个任务都准备自动验收

Equip each task with automated verification,

记录通过率 延迟 费用和人工接管点

tracking pass rate, latency, token spend, and human intervention points.

简单任务同时测低推理档和便宜模型

Test simple tasks against low reasoning effort and cheaper alternatives,

长任务再比较max与Highspeed

reserving 'max' and Highspeed tiers for complex long-horizon work.

若失败集中在需求含糊 先改任务说明；

If failures cluster around ambiguous specs, refine prompt instructions first;

若集中在环境报错 先修工具链

if they cluster around environment errors, fix your toolchain first.

模型评测只有进入你的仓库 才会变成工程决策

Model benchmarks only translate into sound engineering decisions inside your repo.

换模型之前 先把失败原因分清楚

Before switching models, diagnose the root causes of failure clearly.

测试集别频繁更换

Keep your benchmark suite stable—

否则不同版本的结果没法横向比较

otherwise, you won't be able to compare results across versions.

接下来 编程模型的竞争会继续向长任务

Going forward, coding model competition will continue shifting toward long horizons,

工具链和成本曲线移动

robust toolchains, and shifting cost curves.

开放权重若按计划发布

If the open weights arrive on schedule,

还会增加自托管与二次训练的选项

they will unlock valuable paths for self-hosting and fine-tuning.

但部署门槛仍需实测 你不必今天就替换主力模型

Yet hosting hurdles remain real—you don't need to replace your daily driver today.

拿十条真实任务跑一次 留好轨迹和账单

Run ten real tasks from your own codebase, log trajectories and token costs;

比追一轮发布更有收获

that yields far more insight than chasing launch hype.

把这次结果留下来 下次升级才有可比的基线

Preserve those results as a baseline for evaluating future updates.

我更关心一个问题：你现在的AI编程流程里

The question I'm most curious about is: in your current AI coding workflow,

最贵的失败是重复调用 错误合并 还是人工返工？

what costs you the most: repeated retries, bad merges, or manual rework?

欢迎在评论区贴出你的场景

Share your experience in the comments below.

感谢观看 如果这份测试方法对你有用

Thanks for watching! If this evaluation playbook was helpful,

记得一键三连 我是为什么叫QQ 我们下期见

don't forget to like, bookmark, and subscribe. I'm WhyCallQQ—see you next time!