你好我是小 G。Kimi K3 上周五正式发布了这两天被问得最多的基本都是同一个问题K3 能力到底怎么样写代码体感如何国内外已经有很多大佬把 K3 拿去和一线 Coding 模型对比反馈都很不错。数据也不会骗人这几天 K3 的订阅和使用量暴增算力都快顶不住了。我还是更想看它在真实项目里的表现我觉得这才是最实际的。所以这次我准备了三个非常典型的案例一个全栈项目、一个现有 Java 项目改造再加一个从零做游戏 Demo。K3 这次带来了2.8T 参数、1M 上下文、原生多模态以及面向长程 Agent 编程的架构优化。可以看到它要的核心就是让 Agent 在更长任务里持续读代码、看截图、跑工具、修问题。这篇还是按我的老办法来先看怎么接入再看它在几个工程任务里的实际表现最后回头聊 K3 这次更新的亮点。接入 Kimi K3K3 支持几乎所有主流的 Coding Agent 和通用 Agent 框架例如 Claude Code、Roo Code、OpenCode、OMP、OpenClaw、Hermes。这里先以 Kimi 官方的 Kimi Code CLI 为例介绍最短接入路径。已经在用 Claude Code、Roo Code、OpenCode 或 CC Switch 的话也可以继续沿用原来的工具链。Kimi Code CLI 接入这是 Kimi 官方的终端 Coding Agent和 Claude Code 类似。安装成功之后你在项目目录里执行kimi命令然后就可以让它读代码、改代码、跑命令、解释报错、生成提交说明。macOS 和 Linux 的安装命令如下curl-fsSLhttps://code.kimi.com/kimi-code/install.sh|bashWindows PowerShell 使用irmhttps://code.kimi.com/kimi-code/install.ps1|iex安装完成后可以用kimi --version看一下版本号装好后切到准备测试的项目目录运行kimi第一次启动会要求登录 Kimi 账号。进入 Kimi Code CLI 后输入/model选择k3即可。对于我个人来说我一般在正式用之前会做一个只读小测试阅读当前项目的目录结构和核心代码说明各模块的职责。先不要修改文件也不要执行有副作用的命令。已有 Coding Agent 也能继续用Claude Code、Roo Code 或 OpenCode 已经用顺手的话不用为了 K3 重搭工作流。创建 Kimi Code API Key 后可以通过兼容接口把 K3 接进去。OpenClaw、Hermes 等通用 Agent 框架也能调用 Kimi Code。K3 负责模型推理具体怎么读文件、调用工具和管理权限仍然由外面的 Agent 框架处理。以 CC Switch 为例新增供应商时可以直接选择 Kimi For Coding然后填入 API Key 和请求地址API 格式默认即可点击获取模型列表把模型角色映射到k3这里不需要额外开路由实际测试一下案例一搭建热点追踪系统第一个案例我让 K3 搭一个热点追踪系统项目名叫HotPulse。这次我没有只让它做一个好看的前端页面。前端当然要看但我更想看它能不能把后端链路、数据库、队列、测试、错误恢复这些东西串起来。这次的验收目标是一套能跑起来的 MVP用户创建关键词 Monitor系统定时或手动抓取 Hacker News / RSS把原始内容落成 Observation再经过 analyze 阶段生成 Entry最后走 Notify 投递。前端要能看 Feed、Monitor Run、Delivery 状态还要支持阅读、收藏和归档。我在给 K3 的系统设计方案中重点做了这些约束后端用 Hono、SQLite、Drizzle前端用 React 19、React Router、TanStack Query再加 Socket.IO。测试不能依赖真实公网通知用 fake webhook server数据库用临时 SQLite。为了跳过文件写入和命令执行的人工审批我们可以使用kimi -y命令。任务推进用到了/goal命令。为了看模型本身在长任务里的能力我没有启用任何 Skills也没有给它额外的项目专用外挂。这里有个小细节图里出现了 8 小时多不代表模型实际连续工作了这么久。我是昨晚 12 点左右开始跑的中途卡住后就放着了早上继续推进。实际有效完成时间大概在 1 小时左右。它先把后端链路跑通K3 的推进顺序还挺稳先做 shared 契约、Zod schema 和单测再补服务端配置、数据库、队列、领域服务最后把抓取、分析、通知、定时调度、后台 Worker 和维护任务串起来。中间也不是一路绿灯。K3 会自己跑 TypeScript 检查和测试看到报错后再回去修 helper、handler 和测试。后端全绿后再做前端服务端这边中途先跑到了94/94全绿然后 K3 才开始处理 client 侧。前端部分补了 Monitor、Feed、Targets、Deliveries、System 这些页面。下面是 HotPulse MVP 最终交付报告最终交付的功能范围基本覆盖了我给它的 MVP 验收条件。不过第一版能跑但确实比较粗只能算 MVP 版本。Monitor 编辑页能配置名称、关键词、运行间隔、启用状态和来源Feed 页能展示抓取和分析后的 Entry也支持按状态、Monitor、排序和收藏过滤继续优化后面我又让 Kimi 继续优化了几轮。这轮主要是把第一版「能用」的地方继续往产品形态上推了一步。比如默认首页、新手引导、手动运行反馈、按钮 pending、防重复提交、toast、删除确认弹窗还有更统一的中文文案。再进一步我还让它做了多源扩展。这次就不是单纯修界面了。HotPulse 不再只看 Hacker News / RSS而是把 RSS、Webpage、GitHub、Twitter 都接进同一条 scrape → analyze → notify 管线里。这块最有意思的不是多写了几个抓取器而是 K3 把这些来源统一到了source_items中间层用(monitorId, externalId)做唯一键再用contentFingerprint做内容变化检测。真正的监控系统难点在于某个来源挂了、页面结构变了、接口变慢了之后整条链路还能不能稳住能不能自动降级能不能继续跑并且把问题位置暴露出来。这是现在跑出来的效果已经接近一个产品形态了。演示视频地址https://www.zhihu.com/pin/2062834508802569097这个案例最有价值的地方在于K3 在一个比较长的任务里能持续抓住目标读需求、拆模块、改代码、跑测试、修报错最后交出可验证的结果。案例二现有项目改造第二个案例我准备放两个在现有项目上修问题或加功能的小任务。这类任务和第一个全栈 MVP 不太一样。重点是先读懂已有代码再沿着现象去找调用链、数据源和实现细节。对 Coding Agent 来说这种任务更贴近日常开发线上或本地发现一个问题把它定位清楚改最小范围然后跑验证。这里我们以星球的下一个多智能体股票分析实战项目为例这段时间依然在持续完善和补充教程中。先放第一个修复股票搜索乱码。修复股票搜索乱码问题现象一眼就能看出来股票搜索结果里的中文名称全变成了乱码只剩股票代码还能看。我把截图和现象丢给 K3 后它先顺着搜索入口找到marketDataService.searchStock再继续追到数据源回退逻辑。最后问题落在HttpBodyFetcher/HttpUtils这条链路上新浪的suggest3.sinajs.cn搜索接口和hq.sinajs.cn行情接口返回 GBK 编码而项目里的SinaDataSource默认走HttpUtils.get固定按 UTF-8 解码中文名就在这里被解坏了。修复核心就是让新浪数据源按 GBK 解码并补上支持Referer请求头的请求方法。修完后K3 跑了mvn -pl stock-crawler -am install重启后端并实测GET /api/market/search?keyword开确认返回“神开股份、开立医疗、经纬辉开、开开 B 股、开发科技”等正常中文名。这个小任务看起来不大但比“给我写个工具类”更能看出模型的工程习惯它从入口、数据源、HTTP 解码工具一路追到外部接口编码最后也没有扩大到无关模块。开发持仓收益看板第二个任务是在这个股票项目里加一个持仓收益看板。它要做的是基于已有自选股的成本价、持仓量和实时行情算出总市值、浮动盈亏、今日盈亏、最大仓位等信息。并且样式需要和现有的保持一致。这个需求看着像一张页面实际要同时把后端计算、接口分层、前端展示和测试补齐。K3 先读了项目的自选股字段、行情接口和现有分层再开始实现。金额计算统一用BigDecimal行情缺失时让单只股票降级避免一条异常把整页带崩。最后交付的是一个能直接访问的看板上面是总市值、总成本、浮动盈亏等汇总卡片下面能看到每只股票的成本、现价、仓位和收益。后端接口、前端路由和测试也一起补上了。到这一步其实已经能用了。但我后来想了一下真实项目里很多问题不是「页面有没有」这么简单而是口径能不能对齐异常能不能兜住指标能不能继续往下钻。所以我又让 K3 在这个看板基础上做了一版 V2。这一版会继续补业务口径和风险指标。比如修复部分行情不可用时汇总口径不一致的问题增加收益贡献排行、前三大持仓占比、HHI 集中度、年化波动率、最大回撤。这里我觉得比较有意思的是它没有直接在前端堆字段而是先回到后端确认 K 线服务字段、交易日期对齐、停牌和数据不足时怎么降级再把计算逻辑放进独立的PortfolioRiskCalculator里。这就很像一个正常工程师干活的节奏。最后 V2 页面里原来的持仓明细还在下面多了收益贡献和风险概览。收益贡献能看到哪只股票真正贡献了组合盈亏风险概览里也能看到年化波动率、最大回撤、VaR、HHI 集中度和前三大持仓占比。这个案例中它能在已有项目的约束里把完整链路接起来先复用数据再补计算和接口最后跑测试、验页面。更关键的是第二轮继续优化时它还能顺着业务口径往下追把「能展示」推进到「数据口径更靠谱」。另外完成之后我还用 GPT 5.6 Sol 审核了一下代码整体实现逻辑和代码质量都是没问题的可以直接提交。案例三从零做一个 3A 质感游戏 Demo第三个案例我一开始其实纠结过。前面已经有一个全栈项目也有一个现有 Java 项目改造。如果再放一个普通 Bug 修复信息量会有点重复。后来我决定换一个更直观的。做游戏。这个方向有点不一样。业务系统看的是分层、接口、测试和数据口径游戏看的是另一套能力画面、物理、输入手感、镜头、战斗反馈、音效、UI、性能还有最重要的能不能真的玩起来。而且 K3 做游戏这块真的挺离谱的。我在海外社区也刷到不少类似反馈有人直接说 K3 一句话 prompt 做小游戏很猛甚至拿它去复刻《我的世界》风格的 3D Demo。那我就想行别只看别人玩。我自己也来试一下。我的提示词很简单要求它在当前空目录里从零开发一款有 3A 质感的第三人称科幻动作游戏 Demo。背景是一座废弃的未来工业基地玩家要进入基地击败沿途敌人取得能源核心最后打机械 Boss 并撤离。技术上我要求它用 Vite、TypeScript、Three.js 和 Rapier。不要手写物理引擎角色移动、碰撞、重力都交给 Rapier。游戏里必须有移动、奔跑、闪避、瞄准、射击、受击、死亡重开、普通敌人、精英敌人、多阶段 Boss、完整任务循环、PBR 材质、动态光影、阴影、雾效、粒子、Bloom、命中反馈和镜头震动。说实话我写这个 prompt 的时候心里预期也没那么高。因为游戏不是普通网页。一个网页按钮歪一点还能看一个游戏的镜头、碰撞、射击、敌人 AI、Boss 阶段、特效和音效只要有一个环节不对玩家马上就能感觉到。K3 先给了游戏设计和技术方案。项目叫《STEEL HAVEN · 钢铁庇护所》完整流程是降落平台、突破基地大门、中央庭院精英守卫、夺取能源核心、唤醒 WARDEN-9 Boss、三阶段 Boss 战、撤离点坚守死亡后从检查点重开。然后它开始直接写项目。第一步交付出来之后已经不是那种「贴几块方块然后说这是游戏」的程度了。它真的把游戏循环做出来了第三人称角色控制、WASD 移动、Shift 奔跑、空格闪避、右键瞄准、左键射击、R 换弹、E 交互、普通敌人、精英敌人、三阶段 Boss、任务目标、Boss 血条、死亡重开、胜利结算甚至还有 PBR 材质、环境反射、阴影、雾效、Bloom、枪口火光、爆炸粒子、命中标记和屏幕震动。当然第一版不是没有问题。它自己在交付报告里也写了几个已知问题比如无跳跃、Boss 正对玩家时会被自身模型短暂遮挡、构建产物偏大。更关键的是我实际玩下来能明显感觉到射击手感还可以继续打磨。这就进入第二步。我让它重点优化射击动作和战斗体验不要重新做一套游戏而是基于现有项目继续修。它先看截图和代码列出了 7 个影响手感的问题左手不参与持枪、枪口和准星对不齐、瞄准时角色挡画面、枪口火光被身体挡住、连射扩散和真实 spread 没有对应、命中反馈层次不够、换弹音效和动作脱节。然后它开始改 Player、PlayerController、CameraRig、Weapon、Game、Physics、AudioManager、HUD 和敌人模块。这轮改完之后变化就更像游戏了。瞄准时角色从画面中心移到右下准星前方更干净开火有枪体后顿和镜头上抬连射会积累扩散换弹有下沉内倾、弹匣弹出、插入和拉机柄的分段动作命中、暴击、击杀有不同标记和音效墙面火花也沿着法线喷出来不再像贴在墙上的硬编码贴花。演示视频地址https://www.zhihu.com/pin/2062833196090275836这个案例为什么我觉得必须放进来因为它特别能体现 K3 的多模态和长程 Agent 能力。第一轮它要从一句需求里拆出玩法、关卡、敌人、Boss、物理、视觉、音频、UI 和测试。第二轮它又要根据截图和实际体验回头修手感把「能玩」推进到「更像一个游戏」。这不是简单生成一个前端页面。这是把很多主观体验翻译成代码细节。射击手感这种东西很难用一个单元测试定义。准星有没有被身体挡住开火有没有顿挫命中有没有反馈换弹有没有节奏Boss 战有没有压迫感这些都要靠视觉和体验来判断。它说明 K3 不只是能写业务代码也能处理更综合的创意工程任务。只要目标足够清楚验收条件写得足够具体它可以从玩法设计一路跑到可玩的浏览器游戏 Demo再继续根据体验反馈做第二轮优化。这块真的有点超出我的预期。K3 这次更新有什么亮点几个 Coding 榜单里K3 基本都站到了第一梯队有些项目甚至直接排到第一。尤其是 Terminal Bench、Program Bench、SWE Marathon 这类更接近日常开发和长任务的测试表现都挺亮眼。当然了benchmark 只能当参考。实际项目中Agent 接触到的场景会更复杂任务越跑越长需求、代码、日志、测试输出全挤在一起。所以1M 上下文就很关键。它至少能让更多需求、代码和终端输出留在现场不至于跑几轮之后前面发生过什么都被压没了。不过1M 只解决能放多少不能自动解决会不会用。所以 K3 这次还提了 Kimi Delta Attention 和 Attention Residuals。百万级 token 上下文里最高 6.3 倍更快解码小于 2% 的额外成本下带来大约 25% 的训练效率提升。你不用记这些名词简单来说就是K3 的长任务场景得到了质的提升更稳了Agent 和多模态这块也挺有意思。通用 Agent、表格、浏览器任务里K3 基本都在第一梯队部分项目直接排第一。视觉任务也没有掉队整体看下来很均衡。不过普通开发者最后看的还是三件事效果够不够成本扛不扛得住速度快不快。K3 这块给我的感觉是速度很快价格放到同类模型里也比较低可以说是接近 Sonnet 的价格同时在复杂任务里达到 Opus 级的体验性价比确实非常高。⭐️推荐阅读后端开发学习 面试指南覆盖 Java、计算机基础、数据库、框架、系统设计等后端开发核心知识与面试内容。AI 应用开发学习 面试指南覆盖 LLM、RAG、Agent、MCP、Prompt、评测、系统设计等 AI 应用开发知识与面试内容。AI 编程实战指南覆盖 Claude Code、Cursor、Codex、Trae 等工具的使用技巧与面试内容。小结这几个案例跑完后相信大家和我一样对 K3 的能力有了更直观的认识而不仅仅是依赖参数和榜单。Kimi 在前端能力上一直是最顶的那一档。这次的 K3 发布能力更加全面了。全栈 MVP 里/goal能把长任务往前推现有项目修问题时它能沿着入口、服务层、数据源、工具类一路追下去到了游戏案例里它又能把玩法、物理、镜头、射击手感和反馈系统串起来。我会更愿意把它放在目标清楚、验收条件明确、允许它持续执行命令和修复的任务里。比如搭一个 MVP、修一个跨模块 Bug或者做一个可玩的交互 Demo这类任务比单纯生成页面更能看出 Coding Agent 的水平。这次比较打动我的地方在于K3 确实能在长任务里稳得住而且完成任务的效果很赞这几个案例完成之后几乎都没有 bug。如果后续价格、速度和可用性都能稳住K3 会是性价比和能力都很能打的第一梯队模型。我这里就不写「超越谁」「吊打谁」了。开发者最后看的其实很简单任务能不能跑完报错能不能修掉代码能不能过 review价格能不能让自己日常用得起。K3 最近在国内讨论得很热也有不少人给了差评。我的建议还是别急着跟风吹也别急着跟风踩最好自己拿真实项目跑一跑用实践和体感去评价一个模型。