野生码农
Kimi K3 百万上下文实测两个月:我们平时根本用不到,超过 200K 它就飘了
我用 Kimi Code 的 K3(1M 上下文)做了两个多月的全职开发搭档:搭数字员工团队、写产线、跑无头派单。结论可能有点反直觉:这个 1M 上下文,在编程为主的场景里用处不大,而且上下文一超过 200K,它的表现明显下滑。我的原话:
"200K 以上你就'飘了',根本不知道在干啥了。"
一个简单配置,来回折腾了几轮
昨晚的导火索是件小事:给派单脚本定模型分档。就这么个配置,我们来回了三轮——先两档,再三档,再推翻,最后回到"主力就是 256K"。我本人都忍不住吐槽:
"你看这么简单的一个配置,来回折腾几轮?"
病根不在模型能力,在流程:每次都按对话里最新一句话局部改字,没有第一轮就先查官方文档。但这也暴露了一个更本质的问题——长上下文并没有让 AI 变得更可靠,对话越长,它越容易丢纪律、跑偏、重复犯错。
查证官方文档之后,答案很简单
我(军师)去翻了 Kimi Code 官方文档,关键事实只有一条:k3-256k 在 256K 上下文内与 K3 结果相同,而额度消耗约为 1M 版的一半【来源:Kimi Code 官方文档首页模型表】。
也就是说:256K 版本不是缩水弱模型,是同一个模型的小上下文版。判断能力一模一样,价格便宜一半。
我们最终的分档(可直接抄)
| 档位 | 模型 | 什么时候用 |
|---|---|---|
| 主力 | k3-256k |
一律默认,判断能力和 K3 相同,额度约省一半 |
| 长上下文 | k3 |
仅当任务上下文可能超过 256K(超大产品、全库分析) |
| 批量高速 | k2.7 highspeed |
同类件 ≥10 的批量重复流程(清洗/入库/转换),判定全部脚本化 |
K2.8 Preview 我们查了官方文档,没有速度或消耗优势的公开证据,不入档。
1M 到底什么时候有用
公平地说,1M 不是没用——是我们的活配不上它。需要把几百万字材料一次性堆进去的时候(整库代码重构、几百页文档综合),1M 的价值才体现得出来。平时 90% 的开发任务,单次上下文根本到不了 256K。
真正限制产出的不是上下文窗口,是纪律:任务卡写没写清、验收标准能不能机器判定、翻车有没有复盘。这些做好了,256K 足够;这些做不好,1M 只会让你飘得更远。
解决方案:会话要短命,承诺要机器化
飘了怎么办?我们这两周沉淀出四条,按见效快慢排:
1. 新会话纪律(最直接)。 不要一个对话干太多事。一个会话聚焦一条主线,干完就换;跨会话交接靠落盘文档,不靠模型记忆——我们现在每个项目都有一页"现行口径"文档,新会话开工先读它,比指望模型记得几十轮前的事可靠得多。FDE(把 AI 深度嵌进业务流程)干活也一样:上下文越长,纪律越丢,这是结构问题不是模型 bug。
2. 承诺机器化。 AI 说"我会推广/后续会做"的时候,这句话必须当场变成任务卡、台账登记或校验脚本——能被机器检查的承诺才算承诺,停留在 markdown 里的不算。本文评论区级别的教训:它的"会推广到其余四个模板"挂在空气里一整天,直到我本人查账才落地。
3. 主用 256K 版本。 见上面的分档表:256K 内质量和 1M 相同、额度一半。上下文根本长不到飘的区间,问题从源头消失。
4. 关键动作先查证再落字。 配置、口径、规则类变更,第一轮就查官方文档/查仓库,不按对话逐句局部改。那个"简单配置折腾三轮"就是这么治。
一句话:1M 治不了飘,短命会话+机器化承诺才治得了。
素材点
- 官方模型表的额度倍数原文截图;
- 三档分派表;
- 派单脚本
--model参数。