Mo composer 如何用“钞能力”击败 Cursor 的 composer，这可能大模型的杀手级场景

composer 是 Cursor 还在测试的重量级功能，至今没有在官方文档正式列出来。

有趣的是 Mo 也有 composer 的功能，确切的说 Mo 只有 composer 这一种 AI Coding 的方式，

今天正好有个小需求小改，于是我就用 Mo composer 和 Cursor composer 做个了对比测试

需求说简单也不简单，说复杂也不复杂

在 Mo AI Studio 的智能体面板里，我希望能够在进入面板的时候自动激活智能体所在的 Tab，这是个很常见的体验优化的需求，用提示词描述是这样

我希望在进入智能体设置的时候，能够自动激活当前选中的智能体的 tab

使用 Cursor Composer 尝试

输入需求

Cursor 的关键修改

结果嘛，当然是没效果，至于原因我后面会分析，接下来看 Mo 同样使用 Claude 3.5 sonnect 模型

使用 Mo 尝试

因为 Mo 是一个沉浸式开发的工具，我就一镜到底了

https://www.ixigua.com/7414424860115337764?utm_source=xiguastudio

为什么？同样的 Claude 3.5 sonnect 模型，都是基于 codebase 来做推理，为什么结果差这么多？

因为 钞能力 ，Mo 采用的是无损的上下文管理模式，本文用于测试的项目是 mo-ui 属于 mo ai studio 开源的一部分 https://github.com/kinop112365362/mo-ai-studio-ui，包含了 mo ai studio 所有可见的交互和操作，而 Cursor 使用的 RAG，通过将本地代码中部分片段的向量化建立索引。

进一步分析之前，昨天 openai 发布了 o1，无论是用过还是看过 o1 视频的应该知道 o1 采用了将 Cot Token 作为输入的一部分强化训练模型学会思考的方式大幅度增强了推理能力，如何在训练阶段做到这件事，openai 没有公布技术细节

但是回到我们这个对比的场景，其实道理是相同的，对于大模型来说上下文之间的因果关系对于最终的推理结果影响会非常大，同样的道理，人类的大脑也不可能就自己不知道的事情作出正确的推理。

这就是为什么 cursor 的 composer 效果没有 mo 的 composer 效果好的原因 ，因为 cursor 给到 Claude 的上下文是一个残缺的，甚至可能因果关系混乱的检索结果，对于真实的工程项目来说，哪怕是一行代码都可能导致工程启动不起来，例如一个角落里有人写了

window.name = ‘jacky’

然后某处关键代码使用了 if xxx === window.name 之类的，类似这样的情况很多，要准确作出问题推理，大模型或者工程师必须知道工程的每一处细节，人类工程师受制于自身的记忆限制和计算能力的限制，无法将大量代码装到脑子里分析和计算，所以才需要通过 debug，输出日志，全文检索等各种方式来找到问题的原因，或者给出正确修改的方案。但是大模型的上下文远超我们的大脑，可以同时装下近万行代码，我们看 100 行都费劲，同样的大模型并不会掌握人类腿逐步计划推断问题的这种能力，当然 o1 给出了一个指引，但是是否真的能达到人类的水准，还有待观察，但无论大模型会不会计划分解，给出正确的完整的具有因果关系的上下文都是发挥大模型推理能力的关键所在

不仅仅是上下文

Mo 能够胜出的另一个因素除了上下文，还有代码的全量生成，事实上这个问题 cursor 自己也知道，在他们 5 月的 blog 中提到了

可以顺便回答为啥大多数 AI Coding 的插件助手效果很差的原因，因为大模型的生成原理是 token 预测而不是内思的结果输出，大模型的思考方式是一边输出一边思考，而人类是思考后，将结果输出，两者可是天差地别，这就决定了当人类开始输出的时候，结果已经确定了，而大模型开始输出的时候结果还不一定呢，每一个 token 都可能影响后续 token 的生成，所以要生成高质量连续可用的正确代码，必须全量生成。

而 diff 模式从一开始可能就给出了错误的推测，错误的推测进一步影响了后续的 token 生成，变成一错再错，一错到底，最后就开始胡言乱语，胡说八道。

不过 cursor 虽然知道全量生成是最有效的，但是为了成本和用户体验，他们做了妥协，就是利用 Claude 给出建议代码，然后再用自己的快速模型做全量生成，这也是为啥 cursor 的速度这么快的原因，但是这个世界上哪有这么好的事情， 又省钱，速度又快，推理效果又好？

想要效果就得肯花钱，这个道理 OpenAI 也明白了，所以有了 o1

回到我们文章中的个例子，其实要做出正确的修改并不是很简单，我们来模拟下人类的过程，

因为 mo 是一个国际化项目，所以全文检索需要分两步。为了确保公平我也扮演一个没接触过项目的工程师，接到这个需求 我希望在进入智能体设置的时候，能够自动激活当前选中的智能体的 tab

我自然会先去搜文案“官方智能体”

然后根据 i18n key 再去搜要改的代码的位置, 经过一番查找，锁定这里

接下来我需要开始阅读代码，我得找到当前选中的智能体和这个 Tab 之间的逻辑关系，这个就比较复杂了，我就不展开了，你可以自己 clone mo-ui 的项目试试，根据不同人的经验，和对技术栈的熟悉程度，估计在 十几分钟 到 小半天不等。

等理清楚当前选中的智能体卡片的这个存储过程之后，再开始构思代码该怎么写，这是 Mo 最终给出的修改代码，修改的地方并不多，但整个推理过程其实并不简单，你若不信可以自己在项目里试试😂

最后继续👏贡献和关注 mo-ai-studio 项目，关于 mo 的所有提示词也都开源在项目中，如果你感兴趣可以自行尝试 https://github.com/mobenai/mo-ai-studio