我让Kimi K2.7 Code，修好了Fable 5写的3个bug！

前几天的文章里说过，我用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装的那个skills目录，不用重装。记不住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记了一笔。