Kimi向左，Claude、GPT向右

本文来自微信公众号： 人人都是产品经理 ，作者：怪哥

这两天刷某社交平台，看到两条重磅新闻，放在一起，还挺有意思的。

9月17日，Kimi Code正式推出桌面客户端，支持macOS和Windows。

这次Kimi把原来终端里的编程Agent搬到了图形界面，可以直接打开本地项目、修改代码、执行命令，还能查看文件改动、调用浏览器，以及通过不同权限模式控制AI的操作。

问题来了。

Kimi明明已经有了Kimi Work桌面端，能够读取本地文件、操作浏览器、处理办公任务，甚至还支持Agent Swarm和定时任务。

现在又来了一个Kimi Code。

以后电脑上想同时使用Kimi办公和编程，可能就得装两个客户端。

有趣的是，就在Kimi推出新客户端的前一天，Claude宣布了一个方向相反的决定。

把原本独立的Chat和Cowork合并成一个Claude。

用户不需要提前判断自己的任务应该交给聊天助手，还是办公Agent。问一个简单问题也好，处理一份报告、制作PPT也好，直接在同一个对话中提出需求，Claude会选择合适的工具。

OpenAI此前也做了类似的动作。

今年7月，Codex App开始并入新版ChatGPT桌面应用。如今一个客户端里就有Chat、Work和Codex，虽然功能入口依然分开，但不用再为不同任务安装不同的APP。

这就很有意思了。

Claude、ChatGPT正在做减法，Kimi却还在做加法。

大家都想抢占用户的电脑桌面，怎么走出了两种不同的路线？

01.Kimi为什么还要单独做一个Code？

我觉得先得看清Kimi Code和Kimi Work的区别。

虽然两者都能操作本地文件，也都可以让AI自己执行任务，但它们面对的工作环境有明显差异。

Kimi Work面向办公和知识工作，你可以让它整理文件、分析资料、生成报告，也可以让它操作浏览器完成一系列任务。

Kimi Code则围绕软件开发设计。它需要理解整个代码仓库，修改多个文件，运行命令，展示代码差异，并且让开发者能够审查和控制每一步操作。

举个例子。

你让Kimi Work制作一份行业报告，关心的可能是最终文档写得怎么样。

但你让Kimi Code修改一个项目，可能还得检查它改动了哪些文件、有没有引入Bug、能不能正常运行，以及是否需要撤销某一次修改。

开发者显然需要一套更专业的交互界面。

而且Kimi Code还有一个很容易被忽略的特点。

它支持接入第三方模型。

官方文档显示，Kimi Code可以配置Anthropic、OpenAI、Google等模型服务，也能对接DeepSeek、千问等兼容接口。桌面客户端同样提供第三方模型供应商配置。

这意味着，Kimi Code还在尝试成为一个面向开发者的多模型工作台。

哪怕用户不打算使用Kimi自家的模型，也可能因为喜欢它的编程工具而安装这个客户端。

对于Kimi来说，单独推出Code，至少有机会争取一批原本不会主动使用Kimi Work的开发者。

当然，这是一种基于产品设计的推测，Kimi并没有公开说明拆分客户端的商业动机。基于好奇心，我还特地在某社交平台看一下评论，感觉很多人也是想不明白。

某社交平台上的某个自称用户的人吐槽

02.Claude为什么又开始做减法？

Claude的经历更有意思。

它此前把聊天、Cowork和Design等能力放在不同的产品或工作区域里。

但Anthropic在9月16日的官方公告中解释，用户反馈的一个问题是：每次开始任务前，还得先决定去哪个入口，不同工作区域里的上下文也不能自然延续。

于是Claude开始把这些能力整合到同一段对话里。

这让我想起以前用手机的一种体验。

拍照要打开相机，修图要打开修图软件，做海报又得打开另一个App。

每一个软件都有自己的专业能力，但来回切换确实麻烦。

AI Agent也正在遇到类似的问题。

今天你让AI帮忙调研一个竞品，明天想把调研内容整理成PPT，后天又想让它根据PPT做一个演示网页。

如果每一步都需要重新打开一个产品、复制上下文、重新交代需求，所谓AI提升效率，可能有不少时间都浪费在切换工具上了。

Claude现在试图让用户只管提出需求，剩下的由系统选择能力。

不过，Claude Code目前并没有被彻底并入普通聊天。官方帮助文档明确说明，Code入口仍然保留。

这一点反倒说明，专业开发工具和普通办公助手之间，暂时还没有那么容易抹平边界。

03.Kimi未来会不会把Code和Work合并？

我的判断是，存在整合的可能，但未必会把两个产品简单地合成一个聊天窗口。

从ChatGPT的做法就能看出一种思路：客户端统一，专业功能保留。

它把Chat、Work、Codex收进同一个桌面应用，但用户仍然可以进入专门的Codex工作界面。

这样既照顾普通用户，也没有牺牲开发者需要的专业操作。

对Kimi来说，未来也可以考虑类似的路线。

比如，两个产品先共享账号、会员权益、模型配置和项目资料，再逐步打通任务和对话。

当一个用户在Kimi Work中提出开发需求时，可以直接调用Code的能力，不必从头创建项目。

如果以后真要统一客户端，也可以保留独立的编程工作区，而不是把所有功能都塞进一个对话框。

这只是一个可能的演进方向。目前Kimi尚未公布两个桌面客户端将合并的计划。

我甚至觉得，Kimi现在没必要急着合并。

刚推出独立客户端，先看看开发者究竟喜欢什么、需要什么，再决定哪些功能应该进入Work，可能比匆忙整合更有意义。

毕竟，软件开发是一个有特殊工作流的场景，办公Agent也有自己的用户需求。

把两套界面强行合并，未必真的能提升体验。

有意思的是，Kimi Code官方文档已经把编程和知识工作都列进了旗舰模型K3的能力范围。模型能力可以跨场景使用，产品界面却暂时分开。

这或许也是未来AI产品经理需要面对的问题。

当同一个模型能够写代码、做PPT、操作浏览器、处理文件，甚至完成越来越多复杂任务时，我们还需要为每一项能力开发独立的App吗？

Kimi正在把编程做成一个独立产品，Claude和ChatGPT则在尝试减少用户面对的产品入口。

现在看，两条路线都有自己的理由。

等到有一天，用户打开电脑，只需要告诉AI今天要完成什么，而不用再考虑应该打开哪个软件，Code和Work之间的这条界线，可能也就没有现在这么重要了。

到那时候再回头看，Kimi今天推出的独立Code客户端，究竟是一个长期存在的专业工具，还是通向统一AI工作台的中间站，就有答案了。