Kimi K3.1 Pro 编程实测:3个月27万行代码,每年1.7万预算下如何9分钟修好顽固Bug

大家好,我是孟健。

过去 3 个月,我一人协同多个 AI 写了 27 万行代码。

完成近 3000 次提交。

全年在各类 AI 工具上的订阅花费,大概 1.7 万元。

在这套一人公司的商业交付体系里,我选模型只看两笔账。

一个是 Token 计费成本。

另一个是真实工程排障的交付率。

10 月 23 日到 24 日,月之暗面正式发布了 Kimi K3.1 Pro。

正好我自研的内容分发工具「字流」里,压着一个陈年 bug。

之前换了几个模型都没修好。

这次我直接把任务丢给 K3.1 Pro 实测。

从敲下回车到复现、修改、验证完毕,全程约 9 分钟。

说实话我没想到,整个过程我一行代码都没写。

这篇我把它的基准跑分、API 成本账单,以及修 bug 和做前端落地页的完整工程链路,彻底拆开讲清楚。

先看跑分与算账

K3.1 Pro 采用混合专家架构,总参数规模达 2.8 万亿。

官方称它为 3 万亿级参数模型。

它每次激活约 1040 亿参数。

上下文窗口支持 100 万 Token,很长的代码库和文档能一次读进去。

官方承诺在 2026 年 11 月 4 日前,开源完整模型权重。

在第三方评测机构 Artificial Analysis 的 AA 榜上,K3.1 Pro 拿了 55 分。

全球排第四。

the-decoder 10 月 24 日那篇报道里提到,排在它前面的只有三个模型。

也就是 Claude Opus 5.5(58 分)、Claude Sonnet 5.5(56 分),以及还没开放 API 的 Muse Wonder Full(56 分)。

再看国产模型,小米 MiMo、通义千问、DeepSeek、GLM 都在 45 分上下。

K3.1 Pro 直接拉开了整整 10 分差距。

比上一代 K3 的 44 分,也涨了 11 分。

国产模型第一次这么近地贴着 Claude 跑。

AA 榜看的是综合分。

作为独立开发者,我更在意的是编程与命令行实操。

挑三个核心基准数据来看。

一个是测长时间连续写代码的 SWE Marathon v1.1,它跑了 51.7%。

直接位列榜首。

这个成绩超过了 Claude Opus 5.5 的 46.3%,也高过 GPT-6 Astra 的 42.5%。

测 AI 自己干活的 Agents' Last Exam,表现同样位列前排。

再看测真实终端受限任务的 Terminal-Bench 4.0,它拿到 65.7%。

上一代 K3 只有 13%。

这个成绩只比 Claude Opus 5.5 低了 0.7 个百分点。

但比 GPT-6 Astra 高出了 7.5 个百分点。

再算一下独立开发者最关心的 Token 账单。

OpenRouter 和官方定价里写着,K3.1 Pro 的 API 价格比前代降了大概三分之一。

国内标准版输入是 13 元每百万 Token,缓存命中 1.3 元。

输出是 68 元每百万 Token。

国内高速版输入 26 元,输出 136 元。

海外美元版这边,标准版输入 2 美元,缓存命中 0.2 美元,输出 10 美元。

高速版则是输入 4 美元,输出 20 美元。

你想想看,跑分领先真不等于全场景通吃。

理论基准与真实业务代码库之间,永远隔着一层工程边界。

回到刚才那个问题,它在真实项目里到底行不行?

下面直接看实测。

我自研的产品「字流」一年内累计提交了 192 次代码。

收件箱采纳过超 1300 条评论和私信。

写好一篇稿子,它能一键分发到各个平台。

其中 X 长文章这条链路,一直有个毛病。

一篇文章 11 张配图,自动插进去总会少一张。

永远只插进 10 张。

正文里还会留下一串乱码一样的占位文字。

每次我都得打开草稿手动补图、删字。

这事到底难在哪?

X 的编辑器有一套自己的光标位置记录机制。

程序在外部强行挪动光标,编辑器不一定认。

结果就是程序以为选中了占位文字,实际选中的却是别的东西。

更麻烦的是,这个问题只有在真实登录的 X 页面里才会触发。

平时写的自动化测试根本测不出来。

这种活光会写代码不够。

它得会读代码,会自己跑起来复现,还得会自己验证。

这次我用的是官方命令行编程工具 Kimi Code。

在项目目录里一行命令启动,直接调用 K3.1 Pro。

bash 复制代码
kimi -m kimi-code/k3.1-pro --yolo

这里的 --yolo 允许它读写文件和跑命令,不用每次停下来等我确认。

只有在自己的项目里,且改动都能用 git 追踪时,我才会这么开。

我给的提示词没有搞复杂的套路,只立了四条死规矩。

第一是现象,说明 11 张图只插进 10 张,还剩一个占位,附上日志原话。

第二是复现命令,给一条能直接跑起来的命令。

第三是修改范围,只许改指定的那一个文件,其它文件一律不准碰。

第四是红线,只存草稿,严禁点发布。

改完必须自己跑一遍验证,再用中文告诉我原因和结果。

9 分钟零人工介入排障

K3.1 Pro 接手后的第一步,最让我服气。

它先读了相关的 3 个文件。

它没有急着改代码,而是先把我的复现命令原样跑了一遍。

日志里当场抓到了现行。

程序本来要选占位文字,实际选中的却是一段正文标题。

很多 AI 拿到 bug 的第一反应,是先猜问题在哪,然后直接改。

K3.1 Pro 的顺序是对的。

先复现,再动手。

这就是有经验的工程师干活的样子。

定位到根因后,它的改法很干脆。

它不再从外部强行挪光标。

而是模拟鼠标点击占位文字,让 X 编辑器自己感知光标位置。

原来代码里「选中文字不对就不删」的校验保险,它也完整保留了下来。

改完代码,它立刻跑了一遍构建和复现命令。

它还顺手检查了 git 状态,确认只改了我允许的文件。

几分钟后,它给出三段总结,分别写明了根因、改法和验证结果。

正文图片 11/11 张,残留占位 0 个,全程没点发布。

我随后自己跑了一遍验证。

打开 X 草稿一段一段对着原稿核对。

11 张图全部归位,乱码占位文字一个不剩。

这个换了几个模型都没啃下来的硬骨头,9 分钟解决了。

修 bug 考的是工程逻辑,我更在意的是它的前端审美与交付闭环。

我让它给字流桌面版做一个落地页首屏,外加一屏三个卖点。

我给的约束很明确。

要有设计感,别做千篇一律的紫色渐变模板。

中文排版要讲究,双端都要做好响应式适配。

严禁编造用户数和评分这类假数据。

我还给它挂载了两个前端设计 skill,也就是 taste 和 impeccable。

它干活的流程很扎实。

先定视觉方向,写了一页产品说明,随后才开始写代码。

写完后,它自己调起浏览器,在桌面端和移动端两个尺寸下截图检查。

第一轮自检,它自己挑出 3 处毛病。

包括手机端面板掉出橙色区、说明没点明产品、第二屏界面尺寸太小。

它自己改完代码再查,直到检查全部通过。

它给出的设计思路,是以「中文活字校样台」为概念。

用石墨黑、纸白和信号橙替代模板化 AI 渐变。

直接把「一篇原稿分流到不同平台」做成主视觉。

首屏主标题定为「写一篇,各自成章。」

右侧面板可以直接点击切换小红书、知乎、抖音。

同一篇原稿会实时渲染成对应平台的排版。

第二屏的三个卖点配了界面示意,没堆砌廉价卡片。

切到手机尺寸时,布局会自动转为单列。

哪些坑你得提前知道

实测下来,K3.1 Pro 的工程能力确实能打。

但作为一人公司的主力工具,我觉得有几个客观短板必须说在前面。

第一个是超长难任务仍有差距。

在 AA 榜上,Claude Opus 5.5 比它高 3 分。

官方公布的长程编程评测里,它的得分从 K3 的 55.95% 升到了 61.2%。

但面对 GPT-6 Astra 依然落后,科学类的命令行任务差距更大。

官方也坦白,去掉网络攻防数据后,在安全测试上 pass@3 是 81.0%。

网络安全方向的能力,确实还落后于闭源前沿模型。

第二个是推理速度偏慢。

修那个 X 编辑器的 bug 用了 9 分钟。

做落地页加上多轮自检,前后跑了半个多小时,中间还断了一次连接。

如果你对响应速度敏感,建议切到同步发布的 Highspeed 版。

官方数据显示它输出能快 2 到 3 倍,但 API 成本也会翻倍。

第三个是套餐额度消耗极快。

这是我最想吐槽的一点。

修 bug 和做页面要跑好几轮测试与截图,Token 消耗量极大。

这次我刚准备测,Kimi Code 就提示本周额度用尽,要么等刷新要么加购。

10 月 26 日,官方账号 @月之暗面Kimi 也专门发文致歉。

承认会员使用时出现限流和不必要额度消耗,并重置了额度。

如果你是极度关注交付产出的独立开发者,我的结论很明确。

手头有拖了很久的复杂工程 bug,或者要做高品质前端界面,我非常推荐用它。

但要是做超大规模跨模块的长程重构,或者追求极高响应速度,建议先等等。

最后把这套排障提示词模板留给你,复制到项目里就能用。

markdown 复制代码
1. 故障现象:[描述具体少了几张图/报了什么错,直接贴终端日志原话]
2. 复现命令:[给出一条可在当前目录直接执行的测试或构建命令]
3. 修改范围:[明确列出允许修改的文件路径,严禁触碰其它文件]
4. 验收红线:[明确禁止执行的操作如发布/删库,要求改完后自行跑一遍复现命令验证,并用中文输出根因、改法与验证结果]

下一阶段,我会在自己的出海产品矩阵里实测更多模型。

你最近让 AI 处理过最难缠的工程任务是什么?

欢迎在评论区交流。


👋 我是孟健,前腾讯 T11、前字节技术 Leader,现在全职做 AI 编程。

🔥 更多 AI 编程实战:

  • GitHub:@mengjian-github
  • 专栏:AI编程实战
  • 这期的完整清单:评论区回复「编程实测」,我把领取方式发你

觉得有用?点赞+收藏 就是最大支持 🙏

本文由作者借助 AI 辅助整理,内容经作者实测与审校。

相关推荐
sbjdhjd1 小时前
AI产业周度动态:从“更强模型”走向“可执行、可治理、可计价”的系统竞争 (2026年10月19日—10月25日)
人工智能·笔记·ai·开源·gemini·信息差·claude code
孔令飞1 小时前
知己知彼,百战不殆:AI SKILL 实现原理剖析
云原生·go·ai编程
inksci1 小时前
在线编辑表格,功能强大,json互转
前端·javascript·html
沉浮yu大海1 小时前
开源项目吐槽大会:一篇技术文章的大纲设计
开源
咩咩啃树皮1 小时前
JavaScript 中 this 指向为什么总在变?
开发语言·前端·javascript
2501_944525542 小时前
开源鸿蒙平台 KMP_CMP 三方库「EitherNet」适配全流程
华为·开源·harmonyos
彭亚川Allen2 小时前
从零手搓 RAG 之 Embedding 技术
前端·后端·面试
OpenTiny社区2 小时前
GenUI SDK v1.4.0 的 React 渲染器到底做对了什么?
前端·github·ai编程
十方空烬2 小时前
开源雷达 · 2026-10-26:什么时候该多开一个 Agent,有人写成了阈值
开源·ai编程