前几天的文章里提过，用Claude Fable 5一天做出了一个想了很久的Coding Agent容器——FanBox。文章末尾留了一句话：你那个搁置很久的项目，说不定也就差一个这样的周末。

结果……周末还没到，Kimi先来了。

昨天Kimi发布并开源了K2.7 Code，Kimi Code里已经全量切换，现在打开就能用。

正想趁这个机会测一波Kimi Code在自家产品里的效果，顺便试着看看K2.7 Code到底怎么样。

昨晚干了两件事：让它设计一个动画，再让它修复FanBox里的三个bug。两件事干完，突然领悟了硅谷这两周正在热议的一个词：loop engineering。这个放在文章后半说。

测试1：试试Skill和审美

给Kimi Code的第一个任务，是用自己的设计skill（Huashu Design）做一个介绍K2.7发布的动画。

事后复盘才发现一个小插曲。Kimi Code里调skill的正规姿势，是输入/skill后从下拉列表里选，它把机器上装的一百多个skill全索引了出来，看起来直接认了Codex装的技能目录，不用重装。记不住skill名字的人有福了。

但当时按Claude Code的肌肉记忆直接敲了斜杠命令，严格说没真正触发skill机制。结果Kimi读懂了意图，自己在文件夹里把那份SKILL.md翻出来，照着执行了。

流程跑成什么样呢？它先弹了三个问题确认需求：动画给谁看、最想突出什么、用在哪。中间调那个提问工具时还报了一次参数错误（选项给多了），它自己读了报错信息，砍掉一个选项重试，完全没用人管。

发完指令后的15秒，没有加速，看下它的真实速度：

接下来是最喜欢的部分。skill里有一条要求：给用户看真实的设计，而不是用文字描述风格。Kimi的做法是直接拉起三个并行agent，每个按一种设计流派做一版完整的HTML动画样稿，还自己截了图。

这个并行agent的能力，Claude Code里叫subagent，Kimi Code里叫swarm。它调用得非常主动，不用你去提。

从按下回车到三个设计摆在面前，8分钟。

三个都挺喜欢。最后选了中间那版：三角网格像活物一样缓缓形变，珊瑚红的几何块浮在上面，有种「代码是活的」的感觉。

顺便说一句，动画的美感超出了预期。之前用Claude Code做HTML动画，出来的东西总有点像会动的PPT。这次不太一样，自己看：

它确实把HTML动画这个能力用到了挺好的水平。

当然，也完全可以让它每次给出10个、20个设计来选（如果token足够多的话?）。

测试2：让它去修Fable 5搞出来的三个bug

做动画的过程中发现了几个bug。不是Kimi的bug，是FanBox的：在FanBox的内嵌终端里跑Kimi Code，预览它生成的HTML时，页面不自适应宽度；agent输出的长路径被截断后点不了；文件区被拖得太矮时点什么都看不见。

这里有个背景：FanBox是用Claude Code加Fable 5做的，这两天连发了13个版本。也就是说，现在是在一个Fable 5写的App里跑Kimi，让Kimi修Fable 5留下的毛边（如果没被绕晕的话，可以继续看下去?）。

三个bug，发了三段截图加描述，20分钟修完，全程没碰键盘改过一行。

过程里有两个瞬间让人对这个模型刮目相看。

第一个，FanBox的前端代码里有几个故意写进字符串的特殊字节（Fable 5写的），Kimi的文件读取工具直接拒读这个20万字符的文件。它没卡住，用Python做二进制定位，确认那几个字节是有意为之，然后全程换用脚本读写这个文件。前沿模型挖的坑，它自己爬出来了。

第二个，它改完代码起本地服务自测，curl返回502。它查了进程、查了环境变量，发现是电脑上的全局袋里劫持了localhost请求，加参数绕过。这个坑自己之前踩过，Claude配置里专门记了一条。Kimi没有这份记忆，自己踩出来又自己解了。

修完它还没完事，跑了语法检查，构造了三种边界情况的测试页面挨个验证，确认没问题才汇报。汇报里专门写了一句：改动只影响预览端点，「浏览器打开」功能不受影响。

这种边界意识，还挺像个靠谱的老工程师的。

它为什么显得这么快

两件事干下来，最直接的体感是快。差点误以为已经不小心用上了高速版本？后来查了下发现并没有……

琢磨了一下，这个快是两个因素叠出来的。

一个是物理速度，K2.7标准版本吐token就挺快的。

另一个是心理速度：它全程展示思考过程。能看到它在那想、在那试，等待的焦急感会少很多。这算是产品设计策略的功劳了。同时，也正好和K2.7 Code在模型层面的策略有些关系。他们强制开启了thinking（Claude Fable 5也是，估计thinking可能就是保证模型能力的关键因素），关闭它API直接报错。官方还专门优化了过度思考的毛病，比上一代少用30%的思考token。

benchmark这里就不逐项解读了，相比K2.6提升还挺多的。

部分编码基准已经接近GPT-5.5和Opus 4.8。

然后是重点。Kimi官方说下周一，高速版上线：同一个模型，输出速度5到6倍，常规编程场景180 token/s，短上下文能跑到260。

忍不住开始狂想：这次做动画8分钟，修三个bug20分钟，都是普速版跑的。除以6，那就是2分钟做完动画、4分钟修完三个bug发个新版本？这速度不敢想。

冷静讲，吐字快6倍不等于端到端快6倍：读文件、跑测试、还有自己按回车的速度，都不会跟着变快。所以瓶颈在自己咯？

人类跟不上了，怎么办

接着这个「不敢想」往下想，就到了开头埋的那个词。

昨晚修bug那20分钟里，真正闲着的人是自己。

说实话，现在这个速度本身还跟得上：多开两个窗口，这边在跑就去那边派活，边vibe coding边想下一个需求，这大致就是人能消化的节奏。

但把它乘以6呢？几个窗口同时在十分钟内交活，连验收都排不过来。到那时候，喂不饱它的人是自己。agent越快，人想活、派活的速度就越是整条流水线上最慢的一环。

那怎么办？顺着推就是：既然人是瓶颈，那就把人挪出去。human in the loop，变成human out of the loop。

推到这一步突然发现：难道这就是所谓的loop engineering了么。

Claude Code的负责人Boris Cherny上周发了条X说他已经不prompt Claude了，他的工作是写loop。你看，连造工具的人都不在loop里干活了。

然后对着自己昨晚的两个任务想了想，发现这事其实已经在做了，只是之前没意识到。

做动画那次，为什么只忙了开头几分钟？因为那个设计skill本身就是提前写好的一个loop：先问需求、再出多版真实设计、最后等挑选。Kimi拉起三个swarm并行干活，是这个loop在自己转；它开头弹的那三个问题，是设计进loop里的检查点。

修bug那次，为什么后半段彻底闲着？因为修bug这件事还没写loop，就是裸发三段截图在那等。

这么一对比，答案自己冒出来了：人不是被赶出loop，是从loop里面挪到loop上面。设计loop，agent跑loop，验收结果。不会写代码，但能写SKILL.md（其实也是让agent写），写loop这件事，从来不是工程师的特权。

这也是现在看模型分工的方式。Claude Fable 5那种又慢又准又贵的，适合开荒：从零到一把loop本身设计对。K2.7这种又快又稳又便宜的，适合守家：在loop里日夜不停地转。

这也许是Loop Engineering时代该开始出现的任务形态分工，昨晚两件事它都是独立从头干到尾的。用Fable 5两天发了13个版本，已经觉得是极限了；高速版上线之后，loop转起来可能还会再快一大截？

顺便，Kimi Code这个CLI自己就是这么迭代的：5月发布到现在，几乎日更，十几个版本。工具在日更，用工具的人也在日更。

最后

给想上手的人几个实用信息。

入口是kimi.com/code，会员49块起，额度按5小时滚动窗口计，档位越高次数越多，和Claude Code、Codex的限量逻辑类似，但更便宜。开发者走API的话，每百万token输入6块5、输出27块，缓存命中降到1块3。

高速版的API定价有个记忆点：6倍速度，2倍价格。

高速版下周一上线，Kimi Code里切fast模式。

至于那个被修好的FanBox，凌晨已经发了个新版本，给Kimi Code记了一笔。