大家好，我是孟健。
Kimi K3 正式发布了。这个结果，我终于可以公开说了：发布之前，我已经把 ShipSolo 微信小程序这个真实项目整个交给它，从需求梳理到部署验证走完全程，最终完整交付。
交付出来的体感，已经摸到 GPT-5.5 和 Claude Opus 4.8 那一档。跑完这一趟，我最直接的感受是：国产模型真的到这一档了。
过程不是一路顺风：它在 Windows 本地打包环节捅出过一个真会伤到生产的错，好在自己测出来、自己回滚、自己换了条路子修好，没等我来救场。这段我会摊开写，不让它抢在结果前面。
体感之外，Moonshot AI 官方也公布了一份 K3 的 Coding benchmark，图中所有模型都设置为 max 或 xhigh thinking effort。
DeepSWE 上，K3 拿到 67.5，略高于 GPT-5.5 的 67.0，明显高于 Opus 4.8 的 59.0，比 Fable 5 的 70.0 和 GPT-5.6 Sol 的 73.0 低一截。Terminal Bench 2.1 上，K3 88.3，只比 GPT-5.6 Sol 的 88.8 低 0.5 分，高于 Opus 4.8、Fable 5 的 84.6 和 GPT-5.5 的 83.4。
Program Bench 上，K3 77.8，是图中所列模型里排名第一的成绩，GPT-5.6 Sol 77.6，Fable 5 76.8。FrontierSWE 上，K3 81.2，仅次于 Fable 5 的 86.6，高于 GPT-5.6 Sol 的 71.3、Opus 4.8 的 66.7、GPT-5.5 的 64.9。
这张图值得停一下。过去看国产模型，我会先问够不够用；这次我开始问，哪些项目可以先交给它。
单看 Coding，K3 已经稳定站进第一梯队。benchmark 给的是位置，ShipSolo 实测回答的是这种能力能否落到真实项目。
这篇文章把整个过程摊开写：它做对了哪些判断，错在什么地方，我又是怎么用它的。
01 这个项目比看上去复杂得多
ShipSolo 是我在运营的产品，官网已经有 24 篇免费文章、会员手册和一整套做站 Skills。这次给它配一个微信小程序，听着简单，实际接手的是一整套已经在跑的系统。
现有系统里有基于 D1 的后端数据，有 Google OAuth 账号体系，有一个只写了一半、留着历史遗留问题的小程序 repo，还有 Nginx + SSL 的服务器和 Cloudflare Worker + OpenNext 的部署链路。域名有两个：shipsolo.io 面向海外用户，shipsolo.cn 已经完成备案。微信小程序的 request 合法域名必须走备案域名，.io 这条路走不通，只能靠 .cn。
我给 K3 的首轮需求有五点：小程序尽量复用 shipsolo.io 的现有数据；Google 登录的用户要和微信身份打通；文章要方便在微信群、朋友圈转发阅读；小程序定位偏获客引流；遇到搞不清楚或者信息不够的地方，主动来问我，不要自己瞎猜。
从空白页面生成一个静态站，现在的模型基本都能应付。接一套带着历史包袱、数据和账号都在线上跑的系统，考验的是完全不同的能力：能不能先把结构看懂，再动手。
02 它没有急着写代码，先把问题摸清楚
拿到需求后，K3 没有直接开工。
它先把 README、NEXT_STEPS、miniapp 目录、backend 代码、D1 的 schema 通读了一遍，又抓取了 shipsolo.io 的线上页面，再用本机 GitHub CLI 把网站源码克隆下来，把现有的 API 结构、认证方式、内容组织方式摸了个遍。
这一轮调研的产出很具体，直接找出 4 个上线阻断：tabBar 图标缺失导致编译不过、复制微信号功能内容为空、搜索接口路由有 bug、分享按钮点了没反应。这些问题都藏在现有 repo 里，一轮调研就被它翻了出来。这四个问题不解决，小程序连提审的资格都没有。
它还识别出小程序合法域名必须备案这条硬约束，提出用 api.shipsolo.cn 做一层桥接。后端数据方案给了三个选项：反代加 D1 单库、MySQL 双向同步、Cloudflare 直连，把维护成本和数据一致性风险逐条列出来，最后建议单库反代，理由是能避免双写和数据漂移。
账号打通的方案也是双向设计：Google 用户扫码把账号绑定到微信 openid；反过来，先在小程序端用 openid 建一个占位账号，等用户之后用 Google 登录，再自动合并到 email 账号，历史数据不丢。
方案摆完，它停下来等我拍板，没有替我做决定。我选了反代 + D1 单库、扫码绑定、纯引流版本作为 V1。
看完这一轮调研，我心里的判断很直接：先把系统读懂、把选项摆清楚、再等我拍板，这个顺序它没有搞反。读懂系统的耐心，它是有的。
03 两个 coder agent 并行，跨栈往前推
决策定下来后，K3 启动了两个 coder agent：一个负责 io Worker 端的小程序接口，另一个专门处理小程序本身的阻断问题和数据源接入。
这个拆分是沿着依赖边界走的：Worker 接口不依赖小程序端代码，两边可以真正同时动手，不是嘴上说并行、实际互相等。
推进范围覆盖了 Worker 的 schema 和接口、分享功能、登录流程、直播页、Nginx/SSL 配置、Cloudflare 部署，还有那套账号合并逻辑。中途它想读一个同步脚本，发现文件根本不存在，确认清楚之后换了条路继续推，没有卡在一个报错上原地打转。
Worker、D1、小程序、Nginx 四层同时往前走，个别文件或工具失败也没有让它停摆；但一遇到需要产品决策和生产授权的节点，它会主动停下来问我。
04 它把生产打坏了，然后自己救了回来
事故是这样发生的：K3 在 Windows 本地把 OpenNext Worker 构建完，直接部署了上去。部署完它主动做了一轮冒烟测试，发现全站动态路由全部返回 500。
它当场执行了回滚，确认线上恢复之后，才去查根因。
问题出在构建环节：Windows 系统下生成的文件路径带反斜杠，构建插件按正斜杠去过滤路径，两边对不上，最后生成了一个空的路由查找逻辑，动态路由的 handler 全都丢了。网上能查到公开的 GitHub issue，记录的正是同一类 Windows 环境下的 OpenNext 路径问题，现象和根因都对得上。这说明这个归因不是它凭空编的，但也不能说是它第一个发现这个问题，issue 是不是已经被官方修复也没法确认。
查清楚之后，它说明了原因，提出改走 push main 触发 Linux CI 来构建部署，而且在真正执行 push 之前，先来找我要批准。
批准之后，Linux CI 完成构建和部署，它又做了一轮接口回归，微信开发者工具里的 ShipSolo 小程序正常跑起来了。到这一步，整个交付才算真正落地。
先把话说死：犯错就是犯错，这是实打实的减分项。 Windows 和 OpenNext 的兼容性问题不是没人知道，它没能在部署之前把这个坑识别出来。这次没造成持续影响，靠的是冒烟测试这道闸，后面处理得再漂亮，前面这个错也不会因此被抵消。
但另一面同样要说：发现问题、及时止损、回滚、查清根因、换条路子重来，这一整套本身就是工程能力。 它没有带着 500 硬扛下去，没有假装没事继续往前走，也没有自己决定就把 push main 按下去。生产带病运行的时间窗口被它压得很短，这个窗口的长短，直接决定了一次错误的代价有多大。
这次事故真正改变的是我对它的信任方式：一次成功，让我看到它有能力；出错之后还能自测、回滚、查因、重新请求授权，才让我敢让它继续碰真实项目。
演示里的 Agent 能一次成功，往往是因为选的路径本来就没什么意外。真实项目面对的是没见过的环境组合，还有一堆历史包袱，出了错能不能自己发现、自己收住，比一次生成成功更接近真实交付要面对的问题。
05 为什么我说体感到了 GPT-5.5 和 Opus 4.8
先说清楚：这是我基于这一个项目的真实体感，我没有跑独立 benchmark。依据拆成四点。
存量系统理解。两个带着历史的 repo、混合认证体系、备案带来的域名约束，它读完之后给出的架构判断是站得住的，没有乱动已经在跑的逻辑。这类项目考的是能不能准确建立上下文，它做到了。
长任务连续性。从需求梳理一路做到部署验证，任务跨了至少四个技术层，中间没有断线到需要我反复重新给它讲背景，方向一直没跑偏。
工具和 Agent 协同。用 GitHub CLI 拉代码、拉起并行 coder agent、动 Nginx 配置、跑 Cloudflare 部署，跨工具串起来完成。遇到读不到的文件，确认清楚真实状态就换路，不会卡死不动。
纠错和权限感。把生产打坏了，自己测出来，自己回滚，自己查清原因，下一次高风险动作之前主动来请示。从发现问题到恢复正常这一整套流程，它没等我提醒，自己走完了，再把最终的选择权交回给我。这几项能力凑在一起，在我用过的模型里不算常见。
这次的体验和 Opus 4.8 很接近，中等复杂度的项目它完全能扛下来。
06 可以交给它，但护栏要先装好
这次经历同时证明了两件事：K3 扛得住中等复杂度的项目；Agent 上生产，关键节点仍然必须有人盯着。
我自己的做法，可以直接照抄。
开工之前让它把整个项目读完，文档、schema、现有逻辑都过一遍。不读就写，大概率会在意想不到的地方栽跟头。这次它的架构判断之所以靠谱，就是因为调研做在了写代码前面。
任务按依赖边界拆分：接口归接口，页面归页面，部署归部署，每一段都要有明确的验收标准。依赖关系理清楚了，并行才是安全的，不然就是并行的表演。
冒烟测试要内置进部署流程，不能等出了事才想起来做。 每次部署之后跑一遍核心路由验证，确认正常再往下走。这次把生产从 500 里捞回来的，靠的正是这一步。
生产变更必须有可回滚的路径，而且要在部署前就准备好，不是出事了再现想。这次它能当场回滚，前提是有一个稳定版本可以切回去。
push main、改 DNS、动凭证这类操作，一律要人工授权。它可以把方案准备好等我确认，但不能自己按下执行键。这次它主动来请示，说明这个意识是有的，但边界仍然要写进流程里，靠流程比靠模型自觉更可靠。
K3 已经进了我的日常工具箱，模型能力到了这个位置，工程配套跟上，这类项目的交付速度是实打实提上来的。
国产模型跑到这一步，值得认真看一眼------第一梯队里，终于多了一个可以直接上手的国产选择。
下一个中等复杂度的项目，我还会先扔给它试试。
👋 我是孟健，前腾讯 T11 / 前字节技术 Leader，现在全职做 AI 编程。
🔥 更多 AI 编程实战：
- GitHub：@mengjian-github
- 专栏：AI编程实战
觉得有用？点赞+收藏 就是最大支持 🙏