2026-10-23 官方发布之后两小时内，X 上同时出现了两类帖子。一类是"追上 Opus 5.5、GPT-6 Astra"（@kimmonismus，♥2,205），另一类在几小时后出现：博主 @PawelHuryn 用两个真实仓库、105 个重新植入的 bug 做测试，Kimi K3.1 Pro 得分 36，排在第四，低于 DeepSeek V4.1 Flash（42.7）、Muse Wonder（42）和 Opus 5.5（41.7）。
两种说法都没造假，但它们不是同一层数据。把三层混着读，就会得出"全是吹"或"全是黑"这两种同样没用的结论。
本文只做一件事：把官方自测、第三方榜单、个人实测分别拆开，说清各层能回答什么、偏差从哪来，最后给一个能落到自己任务集上的组合方法。所有数字标注来源与日期，检索时间 2026-10-26。
三层数据各是什么
| 层级 | 谁产出 | 典型产出 | 主要偏差来源 | 能回答的问题 |
|---|---|---|---|---|
| 官方自测 | 厂商 | 基准分数、内部评测、示例视频 | 题目集选择、内部基准不可复现、样本偏向 | 这次版本在官方关注的方向上是否进步 |
| 第三方榜单 | 独立评测机构 | 统一方法下的指数与排名 | 方法与权重、是否用同一 API 入口 | 横向位置与价格效率 |
| 个人实测 | 博主、开发者 | 具体任务、耗时、花费、截图 | 样本小、prompt 不公开、作者主观 | 某类真实任务上是否可用 |
三层不是"谁更可信"的关系，是分辨率不同的三种观测。
第一层：官方自测给了什么
官方文档与发布帖给出的数字集中在代码、3D、金融三块：
| 项目 | 数值 | 说明 |
|---|---|---|
| Terminal-Bench 4.0 | 65.7% | 对照 GPT-6 Astra 58.2%、Claude Opus 5.5 66.4% |
| Kimi Code Bench 3.0 Long-horizon | 61.2% | 对照 K3 55.95%，官方内部基准 |
| BenchCAD | 92.7%（带工具） | 对照 Opus 5.5 96.2%、GPT-6 Astra 95.9% |
| OfficeQA Pro v2 | 64.4 | 官方称 SOTA |
| 内部金融基准 | 建模 +7.2 分、研究 +11.6 分 | 相对 K3 |
| 模拟商业运营 | 37.0 | 官方称约 K3 的 4.2 倍 |
| 事实错误率 | 单项 6.85%、整体约前代 46.4% | 去标识化对话压力测试 |
来源：Kimi K3.1 Pro 模型介绍、@Kimi_Moonshot 发布帖，均检索 2026-10-26。
这三块数据里，只有 Terminal-Bench、BenchCAD、OfficeQA Pro v2 属于外部基准，有横向对照意义。其余是内部基准，能证明"比 K3 强"，但不能证明"比别家强"。
官方自己也标了两处限定，值得照抄下来当阅读笔记：
一是幻觉那组数字的样本说明——刻意聚焦模型容易出错的情形，所报告的错误率不代表日常使用中的整体水平。二是 Terminal-Bench 的对照写法是"超过 GPT-6 Astra、与 Claude Opus 5.5 仅有微弱差距"，这是相对描述，不是排名声明。
还有一个容易被忽略的细节：官方英文发布帖写"2.8T total / 104B active params"，中文文档写"3 万亿级参数"。同一家公司两个口径，具体数字与量级定位并存。看到别人引用参数规模时，先确认他引的是哪一个。
第二层：第三方榜单给了什么
Artificial Analysis 的模型页在发布当天就有了 K3.1 Pro 的条目，且方法公开——Intelligence Index v4.3.2 由 10 项评测加权，包括 AA-Briefcase、GDPval-AA、AutomationBench-AA、Terminal-Bench 4.0、SciCode、Humanity's Last Exam、GDP.pdf、CritPt、AA-Omniscience、AA-LCR。
页面上的可核验数字：
| 指标 | 数值 | 位置/说明 |
|---|---|---|
| Intelligence Index | 55 | 第 4 / 215，比 K3 高 11 分 |
| 速度 | 57.5 tokens/s | 第 141 / 186，页面原话"notably slow"，同组中位数 82 |
| 价格 | $2.00 输入 / $10.00 输出 | 每百万 tokens，Cache Discount 90% |
| 每任务成本 | $2.11 | Intelligence Index 加权平均 |
| 输出量 | 150M tokens | Intelligence Index 累计，同组中位数 87M，页面称"very verbose" |
| 上下文 | 1M | 输入支持文本与图像 |
来源：Artificial Analysis · Kimi K3.1 Pro，检索 2026-10-26。
同一机构在 X 上的帖子补了几个页面没有展开的数字：每个 Intelligence Index 任务输出 token 比 K3 多 14%（55K vs 48K）；Cyber Index 64%，比 K3 的 41% 高 23 分；Intelligence 比 K3 高 11 分（原帖，2026-10-23）。
这份数据的价值不在"55 分"，而在三个可比性：方法公开、同一入口跑、价格与速度同时给出。它把"模型强不强"变成"在什么成本与延迟下多强"。
但它也有明确的盲区：Index 是加权合成的，权重选择由该机构决定；它衡量的是任务平均表现，不回答"我的场景行不行"；速度与输出量是在其评测配置下测的，换成你的 prompt 长度与 reasoning_effort 档位，绝对值会变。
两个来源冲突时怎么处理
Terminal-Bench 4.0 上，官方写 65.7%。我在 Artificial Analysis 的 X 帖子摘要里看到过 67% 的说法，但该条正文只保留了链接，没能核到页面数字，因此本文采用官方 65.7%，并把差异标为未核验。
处理这类冲突的规则只有一条：不取平均，写清口径或取保守值。两个数字如果来自不同的运行方式（不同的任务超时、是否重试、是否允许工具、pass@k 还是 pass@1），平均出来的中间值没有任何意义。
第三层：个人实测给了什么
个人实测是最容易被当成"真相"的一层，也是样本最不规整的一层。它没有对照组设计，但有一件事榜单做不到：任务是真的。
| 作者 | 任务 | 关键结果 | 能说明什么 | 不能说明什么 |
|---|---|---|---|---|
| @PawelHuryn | 2 个真实仓库、105 个重新植入的 bug | Kimi 36，低于 DeepSeek V4.1 Flash 42.7、Muse Wonder 42、Opus 5.5 41.7 | 在"定位并修复遗留 bug"这类任务上它没有优势 | 不覆盖新功能开发、长程重构 |
| @notjazii | 同一 prompt、最高推理档，与 GPT-6.1 Sol 对比 | 结果相近；Kimi 25 分钟 / $1.50，Sol 17 分钟 / $0.70 | 单位任务成本可能高于对标模型 | 单次任务，不构成价格结论 |
| @yuhasbeentaken | 四模型同 prompt 写 Three.js 中央公园场景，纯代码 | 四方对比，作者称细节差异明显 | 前端/3D 这类高感知任务适合用同 prompt 横评 | 观感判断主观 |
| @arena | 3D 场景、HTML 动画、网站、UI、研究型页面 | 首轮印象，与 K3、Opus 5.5、Sonnet 5.5、GPT-6.1 Sol、Gemini 4 Argon 同场 | 多场景覆盖比单点测试更接近真实选择 | 首轮印象不等于长期可用 |
| @FaztTech | 3D 生成 | 称场景、游戏、建模提升明显、错误少 | 与官方主打的 3D 方向一致 | 未给可复现的评分标准 |
| @ziwenxu_ | 自托管成本估算 | 8-bit 下 2.8T 约需 6 台 512GB 机器，自建 $60K 起 | 权重开放≠人人可跑 | 仅为估算，未含运维与电力 |
读这一层有三个前提必须记住。
第一，这些都是作者自述，证据形态多为截图与录屏，无法逐帧核验。引用时正确的写法是"作者称""按其自述"，而不是"测试证明"。
第二，样本量与任务选择决定了结论半径。105 个 bug 的测试对"修 bug"很有说服力，对"从零搭项目"几乎没有信息量。
第三，prompt 通常不公开。同一句"写一个 3D 场景"，细节要求差一行，结果就会差很多。
三层怎么组合成一次决策
不要试图判断哪一层"更对"，按下面的顺序把三层当成三段过滤：
前三段的作用是缩小候选集，只有第四段能回答"该不该上生产"。前三段全绿的模型，在你的任务集上仍然可能不达标；反过来，某位博主的一次垫底，也不足以否掉一个在你的场景里可能更好用的模型。
自己跑第四段时记什么
如果只记"感觉更好"，A/B 就白做了。建议至少记这七列：
| 字段 | 为什么必须记 |
|---|---|
| 任务与输入 | 决定结论的适用范围 |
reasoning_effort 档位 | 切档会同时改变质量、延迟、成本与缓存命中 |
| 输出 token 数 | 输出变多会抵消单价下降 |
| 缓存命中 / 未命中 / 写入 | 三段之和应等于总输入 |
| 首 token 延迟与总耗时 | 交互体验与批量吞吐是两个指标 |
| 每任务成本 | 唯一可与第三方"成本/任务"对比的口径 |
| 是否通过 + 人工修订量 | 把"能跑"与"能交付"分开 |
其中"输出 token"这一列最容易被跳过，偏偏这代模型正好在这项上退化明显——第三方测得每任务输出比上一代多 14%。单价降 35%、输出涨 14%，净收益没有单价看起来那么大。
五种常见误读
1. 把一次垫底当成普遍结论。 一个 105 bug 的测试说明这类任务没有优势，不说明整体能力。反过来，一条"追平 Opus 5.5"的帖子也不说明任何具体任务。
2. 把指数当能力上限。 55 分是 10 项评测的加权平均。平均分高，单项可能差距很大；要看你关心的那一项。
3. 忽略冗长与延迟。 官方与第三方都在强调能力，速度与输出量往往只在第三方页面出现。一个慢且话多的模型，在批量任务上成本会比你按单价算的高。
4. 把搜索摘要当原文。 我在整理这批帖子时就遇到：某些数字只出现在搜索引擎的页面摘要里，回到帖子正文只剩一句和链接。这类数字要么标注"未核验"，要么不用。
5. 混用日期与版本。 K3.1 Pro 的对照模型版本、官方文档最后更新时间（2026-10-23）和你的实测时间必须写清楚。模型供应商会在不通知的情况下更新端点行为，参照系一旦漂移，前面的比较全部失效。
限制与结论
三层数据的边界必须说清：官方自测回答"官方想证明什么"，第三方榜单回答"在统一方法下的相对位置"，个人实测回答"某个具体任务上发生了什么"。三者都不能直接回答"我的业务该不该换"。
本文引用的一手来源是 Kimi 官方文档与官方 X 发布帖、Artificial Analysis 模型页与 X 帖子；个人实测部分全部为作者自述、未公开 prompt 与完整日志，属于线索级证据，不能单独支撑关键结论。
如果要给一个可执行的结论：先看第三方榜单确认价格效率，再看官方基准确认方向，再把与自己业务最接近的一两条个人实测当作预警信号，最后用 30～50 条真实请求做一次带成本与延迟记录的 A/B。做完这四步，"它强不强"会变成一个可以写进决策文档的数字。
