一年成爆款，狂斩 49.1k Star、200 万下载：Cline 不是开源 Cursor，却更胜一筹？

编译 | 核子可乐、Tina

AI Coding 可能并不是一门好生意？！

AI 编程助手虽备受追捧、话题不断，但现实远没有想象中光鲜。许多热门工具——如 Cursor、Windsurf——其实都在亏本运营。TechCrunch 报道称，这类产品毛利率极低，甚至为负，也就是说，每新增一个用户，亏损就会进一步扩大。这并非初创公司为抢占市场的短期现象，而是市场在传递一个明确信号：这种商业模式走不通。

问题的根源在于，AI 市场正在自然形成三层竞争格局：模型层比拼技术实力（如 Anthropic、OpenAI、谷歌），基础设施层比拼价格优势，而编程工具层则比拼功能和用户体验。然而，像 Cursor 这样的公司试图将三者捆绑在一起，充当中间商从中获利。结果就像用 100 美元买电，却只卖 50 美元——完全不可持续。用户每月可能只支付 20 到 200 美元的订阅费，但实际推理成本却高达 1000 美元。

这种“推理套利”表面看是 ARR 高速增长，本质却是靠风险投资补贴在续命，说白了就是“VC 慈善”。Cline 团队甚至用梗图调侃了这种困境，甚至还有网友评论——像 Cursor 这样的中间商可能撑不过一年。

那么，AI 编码工具究竟该如何走出困境？Cline 给出了一种答案。

Cline 选择了开源，坚持“软件天然应该免费”的理念。它允许用户自由选择和组合各类 LLM 来完成编程任务，软件本身对个人开发者免费，其收入来源于企业服务——提供团队管理、安全保障、技术支持等增值功能。这走的实际是 Linux、Kubernetes 等成功开源项目的老路：软件免费、服务变现。

Cline 团队强调，他们不是“开源版 Cursor”或“开源版 Windsurf”，而是另一种完全不同的 AI 编码思路。Cursor 等公司依靠巨额补贴支撑的 20 美元低价订阅，并通过将请求转向更便宜的 AI 模型压低高昂成本；而 Cline “完全不玩这一套”——“我们在 AI 使用上分毫不赚，只是纯粹负责指挥推理过程。”

这种理念带来了惊人的增长：仅用一年时间，Cline 就从一次黑客马拉松的创意成长为拥有 270 万开发者社区的明星产品，并在 GitHub 上收获 49.1k 颗 star。

今年一月，Cline 发布了兼容 VS Code、Cursor 和 Windsurf 的 AI 工程师扩展。自发布以来短短六个月，其下载量已接近 200 万次。就在本月，Cline 宣布完成 3200 万美元的种子轮 +A 轮融资。

在 VS Code 分叉（如 Kiro）、终端智能体（如 Warp 2.0、Charm Crush、Augment CLI）等竞品层出不穷的背景下，这款免费开源的 VS Code 扩展为何能在 2025 年脱颖而出、表现亮眼？

近期，28 岁的 Cline 联合创始人兼 CEO Saoud Rizwan与 AI 负责人Nik Pash在Swyx主持的一期播客中分享了他们的思考。以下是精华内容：

为什么免费开源还能赢

Swyx: Cline 目前的拥趸着实不少，但在外界的知名度也还不算太高。我们先来介绍一下 Cline，让听众朋友们了解了解。

Saoud: Cline 是一款开源编程智能体，目前只是 VS Code 的一个扩展，但即将支持 JetBrains、NeoVim 和 CLI。只要给 Cline 一个任务，它就能立即执行。它能接管大家的终端、编辑器、浏览器、接入各种 MCP 服务，并最终支撑着整个开发工作流程。总之，它将成为我们完成所有工作的联络中枢。

Swyx: 明白。Pash，你有没有要补充的？或者说，你觉得 Cline 还有哪些值得强调的价值亮点？

Pash: 我补一点。Cline 应该算是智能体（所有开源智能体）的基础设施层，大家可以在它之上建立起类似智能体基础设施的体系。Cline 是一套完全模块化的系统，我们希望把它打造成这个形态。我们正努力进一步提升它的模块化水平，确保用户能在其上构建任何智能体。借助我们即将发布的 CLI 和 SDK，用户可以构建起完整的智能体系统。

Swyx：明白了，看来我对 Cline 的理解有点偏差。那咱们先聊聊编程，再逐步向外扩展。Cline 团队给 AI IDE 工作流引入的第一个关键“变量”，就是从按序对话模式转变为计划 + 行动模式，即由模型为所需变更建立概要，然后逐步完成任务。这听起来跟 Aider 有点像，不知道到底是哪边更早使用计划 + 行动的范式。你们要不要解释一下这个范式，包括为什么有必要在不同的场景下使用不同的模型？

Saoud: 没问题，我来介绍吧。计划 + 行动的范式确实是我先提出来的，Cline 也是首家为开发者提供这种模式的厂商。我们跟用户交流过，观察他们怎样使用 Cline，最初它也跟大模型一样、只开放一条输入字段。我们发现很多用户其实是先创建一个 Markdown 文件，再提交给智能体以据此制定某种架构规划，逐步完成接下来的工作。我们发现用户自然而然就形成了这种工作流程，所以我们思考怎么把它融入到产品当中。这样的设计对于新用户来说更加直观，基本没有学习门槛，而且能够明确引导智能体的行动。

后续用户还可以切换模式、为智能体设置护栏。比如在计划模式下，智能体可以更具探索性、读取更多文件、获取更多数据、理解用户需求，并在上下文中填充相关信息，据此为用户希望完成的任务制定出一份行动计划。而当用户切换到行动模式后，智能体会接收指令、查看计划并开始执行，包括运行命令和编辑文件。这样跟智能体的协作体验会轻松得多，Cline 做的就是这方面努力。

多数情况下，人们主要是在计划模式下跟智能体交互、反复沟通。这时候智能体会从开发者那里获取大量信息，比如提问：你想要什么样的主题？你想在网站上显示哪些页面？总之，就是各种用户在初始提示词中没有提供的信息。而在用户觉得做好充分准备、可以执行之后，他们就会切换到行动模式、勾选自动批准，然后到一边喝杯咖啡或者放空一会，让智能体完成工作。是的，大部分人类参与都发生在计划模式内；到了行动模式阶段，用户只需要对正在发生什么有个大概的了解，并在事情朝着错误方向发展时进行纠正。不过总体来讲，大模型都能完成得八九不离十。

Alessio: 这就是 Cline 最初的产品形态吗？还是说你们通过迭代慢慢建立起计划 + 行动的范式？你们当初还探索过其他解决方案吗？

Saoud: 其实在 Cline 早期，我们进行过大量实验，而且跟用户频繁沟通，观察他们怎么使用和设计工作流程、又如何将其转化成产品。所以，计划 + 行动的模式其实是我们在 Discord 上跟用户交流之后产生的灵感。我们会询问 Cline 怎么做会更好，需要在 UI 中添加哪些快捷方式。

其实计划 + 行动模式的本质就是一种快捷方式，能让用户省去手动输入的麻烦。比如我希望你问我几个问题，然后根据我的回答制定计划。市面上的其他工具往往要求明确说明，比如在执行或编辑文件之前先制定一项计划，将成果整合到 UI 当中，这就省去了用户自行输入的麻烦。

Alessio: 但你们从立项之初就想做一款编程产品，所以计划 + 行动模式的诞生其实源自你们对更佳用户体验的探索，对吧？那当时你们的评估结果是什么样的？计划 + 行动虽然听起来不错，但可能大模型没法端到端自主完成。那你们开始研究的时候，这种模式的效果好吗？具体有哪些局限性，哪些模型的表现会好一点？随着时间推移，模型的表现是不是越来越好了？

Cline 的模型评估与早期开发

Saoud: 确实，在第一次研究 Cline 的时候，大概是在 Claude 3.5 Sonnet 发布 10 天之后。

当时我读到 Anthropic 的模型说明，其中有一节提到了智能体编程，包括它怎样在分步执行任务方面做得更好。文档里提到了内部测试，如何让模型循环运行并调用工具。我明显意识到模型是分版本的，他们还有一些跟当时 Copilot、Cursor 和 Aider 截然不同的内部应用。他们不是按序进行推理和任务测试的，毕竟后者还是只适合问答和一次性提示这种比较简单的用例。

我记得是 2024 年 6 月，当时 Anthropic 真正拿出了一些开创性的成果，之前的所有模型都做不到。因此我决定从头开始创建点什么，充分发挥当时那个模型版本带来的提升。比如 Claude 3.5 在“大海捞针”测试中的表现就非常出色。对于超大规模的上下文窗口，比如在 20 万字节的窗口中将 90% 都给填满，Claude 3.5 就很擅长从其中筛选出细节。

在 Claude 3.5 之前的版本中，模型其实更关注上下文的开头和结尾，而 3.5 版本可以更好地理解更长的上下文，且更擅长分布完成任务、从头开始构建产品。这让我得以打造出跟当时其他成果有所不同的方案。Claude 3.5 初版的核心原则就是保持简洁，让开发者可以随心所欲进行体验和调用，同时尽量保持通用性，帮助用户建立起各种适合自己的工作流程。

除了编程，这个模型还可以用来做其他事情。我们的产品营销人员 Nick Bauman 就用它接入 Reddit MCP 服务器，抓取接入 X MCP 服务器的内容，然后发布推文。本质上它还是一个 VS Code 扩展加编程智能体，但 MCP 让它具备了万能属性，可以接入各种目标服务。也就是说，它能在产品中提供高度通用的功能，而不再局限于编程任务这一个方向。

Cline 为何成为 VS Code 的扩展，

而非分叉

Saoud：VS Code 扩展能够实现不少有趣的功能，比如访问用户的操作系统、访问用户的终端，还可以读取和编辑文件。扩展能够大大降低开发者的使用门槛。至少大家用不着单独安装应用程序嘛，也不用向上申报、层层批准。总之，扩展这个形态已经足够访问桌面文件、运行在终端上的程序、编码代码以及运用 VS Code 功能等等。它的用户界面也很棒，还能显示差异视图，比如文件变更前后的不同之处。

Swyx: 那你不想做个 VS Code 分叉吗？毕竟你现在可是有 30 亿美元的估值了。

Saoud: 并没有，而且我很同情那些不得不选择分叉的开发者，微软的制度真的让这些分叉维护起来特别困难而且痛苦。单是维护分叉就要耗费大量资源和精力，还得确保它跟 VS Code 的所有更新保持同步……

Swyx: 明白了，Cline 可以躲进自己的私有 repo 成一统，不用管外边的纷纷扰扰。

Saoud：没错，VS Code 发展太快了，所以搞分叉肯定会遇到各种各样的问题，不光是合并冲突之类、还有后端那头。微软一直在改进、修改，比如他们的 VS Marketplace API。有时候必须得进行逆向工具，才能搞清楚如何确保用户在使用时不会遇到问题。相信我，这永远是个巨大的难题。

但我们不一样，大家可以在 Cursor、Windsurf 或者 VS Code 中使用 Cline。我觉得 Cline 很好地补充了各种功能缺失，让我们有机会自由探索并与用户紧密合作，打造出最出色的智能体使用体验。

而 Cursor、Windsurf 和 Copilot 则必须考虑完整的开发者体验，比如内联代码编辑、问答系统以及编写代码所需要的其他各种功能。我们希望把精力集中起来，为未来编程找到最好地智能体范式。随着大模型的不断改进，人们会越来越多使用自然语言跟智能体协作，而不再需要费力编辑代码或者使用 Tab 自动补全之类的功能。

Pash: 是的，设想一下维护 VS Code 分叉需要耗费多少资源。躲开它，我们才能专注于核心智能体循环，针对不同模型家族进行优化和支持。你知道，这是需要投入大量工作的，而维护分叉肯定会让我们分心，且根本不值得。

编程智能体的经济价值

Alessio: 从你的说法来看，我似乎感受到一种二分：Cline 既想要成为未来编程的最佳选项，也希望给非编程人士带来助益。那最近这段时间，你们有发现更多用户开始使用 MCP 服务器处理某些技术含量不那么高的工作吗？这是个很有趣的领域，而且应该蕴藏着巨大的经济价值，所以希望你能多分享一点。

Saoud: 单从经济价值来说，编程肯定是目前大语言模型领域成本效益最高的应用。而且我发现很多模型厂商都更重视编程了。

MCP 生态系统正在不断发展，很多人将其用于编程以外的领域。大多数用例是开发者的工作。几周之前，Hacker News 上有篇文章，讲述一位开发者如何部署一个存在缺陷的 Cloudflare 工作器，再使用 Sentry MCP 服务器提取技术栈跟踪、参考 GitHub 上的 MCP 服务器关闭问题，要求 Cline 使用跟踪信息修复 bug，最终将修复程序部署至 Cloudflare。整个过程都是在 Cline 内以自然语言实现的，无需离开 VS Code 就能顺畅跟其他服务进行交互。

所以我觉得未来的发展方向，应该是应用层接入各种不同的服务，这些以往需要手动操作的服务成了一个个独立的接触点，允许用户通过自然语言进行交互。这样我们对代码的依赖度会越来越低，对智能体功能的理解则越来越深，而且始终有纠正的空间。我觉得这一点非常重要，也让 Cline 从这个嘈杂的空间中脱颖而出。

很多人对未来发展方向想法颇多，但同时又被严重局限在现状当中。要突破这个桎梏，首先需要理解大模型有哪些局限性、做不到什么。比如说，Cline 就很擅长让用户理解模型如何处理提示词、何时可能出现错误、错误的发生原因，以及模型调用了哪些工具。我们会尽量观察模型在各个任务步骤中的具体操作，并在顺利或者出错时及时提醒并生成反馈。我认为这种纠错机制非常重要，在实际工作中要比直接交给后台智能体要快得多。毕竟大家肯定都遇到过几小时后回来，才发现它完全出错的情况。大模型在编程时总得重试几次才能成功。

Alessio: Sentry 这个例子举得很好，我觉得 MCP 某种程度上就像在蚕食产品本身。我们之前用过 Sentry MCP，刚开始是免费的，我们觉得用起来确实很棒，但后来他们开始收费了。我觉得完全可以继续免费使用，把数据存进自己的编程智能体，由它免费解决问题并返回结果。或者，客户也可以订阅自己需要的 MCP，让更多人也能赚到钱。我个人觉得目前的利益分配结构似乎不太合理。

MCP 的早期应用

Pash: 没错，我们很早就开始应用 MCP 了，而且一直很好看 MCP。

Saoud: 我记得 Anthropic 首次推出 MCP 时，就针对这个新协议的开发和开源做出了重大声明。当时人们都不理解这到底意味着什么。我们花了点时间认真研究他们的文档，理解背后的工作原理和重要性。我觉得他们是把赌注押在了开源社区对生态系统的贡献上，这样它才能真正起飞。所以我想尽可能在这方面提供帮助。

接下来一段时间，很多客户都不理解 MCP 要怎么起效，更不知道要如何搭建 MCP 服务器。但之后 Cline 和 MCP 生态系统就一直紧密相依、共同发展。Cline 让开发者深入了解了 MCP 的底层工作原理，并真正开始使用。当初在 Cline 中推出 MCP 时，Discord 上的用户们讨论得可热烈了，都不明白要怎么用。这种看着客户们从头开始构建 MCP 服务器的感觉真的很棒。他们开始把各个环节串连起来，这就是 MCP 的核心意义所在。它让智能体能够接入各种工具、服务和 API，在很大程度上帮我省去了亲自处理这类工作的麻烦。

Pash: 当时 MCP 刚诞生不久，人们还在适应和理解。而且 MCP 的可发现性存在很大问题，所以我们早在今年二月就推出了 MCP 市场，用户可以一键安装、查看自述文件就能学会使用。整个过程就是接入 GitHub、安装完整 MCP 服务器，之后立即运行。估计也是从那会开始，MCP 才真正开始起飞，更多市场陆续出现。人们可以轻松找到 MCP，也能参与到 MCP 的贡献中来。

迄今为止，我们已经上线了超过 150 种 MCP 服务器。我们市场上排名先前的 MCP 下载量超过几十万次，大家都在日常使用。但你也提到，MCP 似乎在蚕食现有产品。但与此同时，我们看到新的生态系统也在持续发展，人们开始推动 MCP 货币化。

一个典型的例子就是 21st dev 的 Magic MCP 服务器，它为大模型编程智能体注入了新鲜元素。它为大模型提供一套精美的组件库，只需输入相关示例就能起效。这样 Cline 就能实现漂亮的 UI，而且配合标准 API 密钥来实现货币化。我们看到开发者开始喜欢上 MCP、参与构建，并建立起像 MCP 市场和 Cline 这样的分发平台，并围绕它培养出商业生态。换个角度看，这就相当于向智能体销售工具，这是个很有趣的探索方向。

Alessio: 之所以这一切能够成立，就是因为依托 VS Code，依托于终端。那你有没有考虑过推动 MCP 远程托管，或者你觉得没必要？

Pash: 确实，我们还没自主托管过服务器。但目前我们正在研究这个问题，而且远程 MCP 目前还处于起步阶段，不过我们当然有兴趣支持远程 MCP、并将其推上我们的市场。

Saoud:另一方面，我认为本地 MCP 服务器和远程 MCP 属于不同类型。

大多数远程 MCP 只用于接入不同 API，而这只是 MCP 用例中的一小部分。很多 MCP 都能帮用户接入计算机上的各种应用程序。比如有个 Unity MCP 服务器就能帮助用户在 VS Code 中直接创建 3D 对象，还有个 Ableton MCP 服务器能配合 Cline 或者其他设备创作歌曲。这类 MCP 服务器肯定没办法纯远程托管。所以本地 MCP 服务器和远程 MCP 服务器会始终共存。

我相信远程 MCP 服务器可以通过类似 OAuth 流程的方式简化安装，而且身份验证也不会像自主管理 API 密钥那么麻烦。

但总体来讲，MCP 生态系统还处于早期发展阶段，我们仍在努力在安全性和开发者便利性之间寻求最佳平衡。

目前大部分探索都是实验性质，但跟市场的对接也已经开始，人们开始分享技巧性的文章和参考流程，讲述 MCP 如何彻底改变自己的工作。未来肯定会有更多资源和精力被投入到生态和协议的构建当中。

Anthropic 已经规划了不少路线图，整个社区也各有想法，而市场则给出了落地实施的思路。开发者的现实需求让我们开始思考，未来的市场应该是什么样的？对我们来说，这将是多种因素的结合。比如很多用户都非常注重安全，如果不信任最终开发者，MCP 服务器在使用方面会带来不少风险。所以我们正努力探索该如何保证一定程度的安全，又该如何对所安装的 MCP 服务器建立信心？这个问题当下恐怕还没有答案，社区里还存在很多信任问题，而且不少企业开发者和组织还不愿倾力尝试。所以安全就是我们当前最关注的问题。

Swyx: Anthropic 和社区之间好像有种微妙的关系。你们内部有一套模型注册中心，老实说，我觉得应该把它正式对外公开。我在你们的网站上搜过，没有找到，唯一的访问方式就是安装 Cline。但 Anthropic 也说过他们会在时机合适时推出模型注册中心，或者讲 MCP 注册中心。那如果等他们行动起来，是不是咱们就被动了？你们会直接用 Anthropic 的注册中心吗？

Saoud: 应该会吧。我觉得整个生态系统都会围绕 Anthropic 的行动做配合。他们的分发渠道特别强，而且 MCP 也确实是他们最先想出来的。我觉得这样挺好。

最受欢迎的 MCP 及其用例

Swyx: 我观察过大多数 MCP 安装情况，这里想聊聊自己的结论。如果哪里说得不对，请随时打断我。其中最顶层的是文件系统 MCP，再就是随 MCP 初版一同发布的浏览器工具，还有 Context 7……这是干什么的？

Pash: Context 7 可重要了，它能帮助用户从任意位置获取文档。它有一套包含所有流行库及其文档的大型索引，这样用户的智能体就可以提交并搜索类似自然语言查询的文档。

Swyx: 能实现这一点显然离不开 Upstash。而由此实现的 Browser Use 也会跟浏览器工具形成竞争关系，对吧？这里也有巨大的探索空间，比如 Firecrawl 啦、Puppeteer 啦、Figma 啦，还有 Perplexity Research。

Pash: 是的，我还专门做过分叉。这是又一款高人气研究平台，用户可以在其中随意探索。

Swyx: 那大家为什么想要模拟浏览器呢？是打算访问 Git、文件系统、文档和搜索功能，还有别的吗？你觉得还有哪些重要的用法？

Pash: 还有很多啊。比如说可以用 Slack MCP 发送消息，我就专门设置过一套工作流程，可以在 Cline 中自动执行重复任务。我可以要求 Cline 拉取 PR，使用已经安装的 GitHub CLI 工具用终端拉取 PR、获取 PR 描述和讨论，再获取完整 diff，无需交互命令就能轻松实现。接下来就由我自己做决策，只要确认无误，Slack MCP 就能向团队成员发送消息。还有很多用户会用它来写作，效果同样相当不错。这种感觉很棒，基本上就是预先在 Cline 上设置好工作流程，它会在做任何事之前征求用户的意见，确保所发送的消息和执行的操作都得到用户的确认。

Swyx: 你有没有看到哪家很有趣的 MCP 初创企业？

Alessio: 大家的主要思路就是重新托管本地服务器，再进行远程操作，基本上只需要设置个位数的 MCP 就能实现，更多依托的是一条规范 URL。把所有工具都放进去，再通过服务器公开所有工具。这样 MCP 就能按需求运行其中部分工具。

Swyx: 没错，但我觉得这也存在同样的问题，那就是怎样激励人们开发出更好的 MCP。你觉得这件事主要靠第一方，还是第三方？

Pash: 把 MCP 安装在本地设备上，往往会伴随着巨大的风险。如果 MCP 是由个人创建的，那我们根本不知道这人是谁。他们可能会更新 GitHub、混入某些恶意内容。所以即使在上架时完成了验证，对方后续也可能偷偷修改。所以我最终只能分叉了几个版本，从中选出最可靠的一个。

Swyx: 明白了。我还想问一个问题，如果没有 Anthropic 牵头并开发出 MCP，这个世界会走向何方？未来会有什么样的变化，你们还仍然会选择 MCP 这条道路吗？

Saoud: 其实有些竞争对手也一直在开发自己的即插即用智能体工具，并将其集成到自己的产品中。所以我觉得这个领域中的每位参与者都会做出类似的尝试，只是 Anthropic 帮助我们省去了很多麻烦。他们发动了开源和社区驱动开发的力量，允许个人贡献者为各类用例创建 MCP、真正发挥了人们的想象力。我认为这对释放这类产品全部潜力来说非常必要。

编程智能体的市场定位与 IDE 集成矩阵

Alessio: 给大家介绍一下市场矩阵吧，比如说这里有纯代理式、无 IDE 的，还有代理式加 IDE，再加上各种辅助工具。那大家该怎么理解这些不同工具，还有 Cline 最擅长或者说最不擅长做的又是什么？

Saoud: 我觉得我们最擅长的，就是体会开发者的难处。现在的模型需要一些洞察和引导，而 IDE 正是这条完美通道，可以实现这些功能。用户可以看到它正在执行编辑、运行命令、调用工具。它能提供完美的用户体验，带来充足的洞察力和控制力，并根据当前模型的局限性调整工作方式。

但我也相信随着大模型越来越完善，用户的必要介入会越来越少，而工具能做的则越来越多。我们只需要进行初步规划、给予提示，模型就几乎能够完全按照我们的期望完成工作。

当然，大模型可能永远无法真正理解我们的想法，所以双方之间总会存在一些差距。这时候就必须确保提供最全面的信息，详尽说明想要得到什么。表达越差，大模型返回的结果就越糟糕。当然，我们都需要在这个过程中不断学习，学习怎样正确组织提示词、怎样强调自己想要什么，还有怎样避免可能出现的问题。

而 Claude Code 的有趣之处，就在于它更像是一份宏观层面的清单，还没有涵盖智能体到底在做什么。当然，等到未来算力和 token 足够便宜，大家可能也不会再费心去研究了。实在不行，多跑几遍就好，这种方式特别适合试水性质的新项目。但对于某些更严肃、更复杂的任务，确实需要一定程度的洞察力，或者说开发者的参与。比如说用到一些能够提供更多洞察的工具。比如说可以让智能体编写测试、或者由多个智能体同时修复同一个错误，这都是不用太多介入的用例；但对于那些需要更多创造力和想象力的工作，就必须想办法把我们自己脑中的上下文展示给大模型，甚至需要来回反复。而 Cline 就特别适合这方面需求。

Pash: 比如说对于智能体正在做什么的可见性，还有自主性——类似于自动化程度。这分别对应的是两类用户群体。有些用户想要开发应用程序，但完全不懂技术，只知道对结果满不满意。这类方案就不太强调对过程的可见性，好比是氛围程序员，他们完全把工作交给 AI 去做，只为快速构建完成。很多开源用户和业余爱好者都喜欢这种形式。但也有一些严肃工程团队，他们不能、至少目前还不能把所有工作都交给 AI，要求对每一步进展拥有高度可见性，确保真正理解代码的运行情况。就个人而言，我在用 Cline 的时候就喜欢每一步都参与，引导它朝着正确的方向探索。在这种情况下，混合型方案就更适合我的需求。当然，偶尔我也会放松一下，直接批准所有结果、出去喝杯咖啡，然后回来审查工作成果。

Alessio: 身为工程师，我们当然希望所有复杂的部分都由自己亲自把关。那你们会怎么看待这种复杂性边界随时间推移的变化？如果 12 个月前我们讨论这个问题，那时候模型的能力还不够强，所以复杂性肯定比现在要低得多。你觉得这种变化速度够快吗？比如再过 18 个月，也许有 75% 甚至 80% 的工作都能让生成式 AI 完成。或者说，你觉得发展还不够快？

Saoud: 我认为，几年前的复杂性跟当下完全不同。如今我们要更有意识地关注前期做出的架构决策，还有如何在此基础上构建模型。比如几年前我们认为很复杂的东西，比如算法挑战，对于如今的模型来说已经相当简单了，用不着多费心力。只要设定一个具体的期望值或者单元测试，它就会开始运行，最终整理出完美的解决方案。但正因为如此，我们才需要在架构决策期间做出更全面的思考，而这实际上源自我们对于哪些方法有效、哪些方法无效的经验积累。谁对项目发展和代码库前景拥有更清晰的认知，谁就能更好地发挥模型优势。这些都是大模型本身难以替代的，毕竟它的应用范围有限，无法洞察开发者的愿景、也无法真正理解我们想要实现的目标，唯一的办法就是把所有需求都整理清楚。但无论如何，很多几年前还需要耗费大量时间研究的工作现在都彻底改变了，而且是往好的方向变化。我觉得现在架构决策比选择算法组合更重要、也更有趣。

Pash:这在很大程度上解放了高级软件工程师的精力，让他们能够更多深入到架构层面的思考中去。在理解了代码库的现状和架构情况后，他们的每一次决策实际都是架构层面的思考。他们可以把自己的洞察解释给 Cline，当然这也需要一些技巧。有些问题可以通过追问、主动澄清等方式来实现。但只要做到这一切，智能体就可以深入研究、实现所有功能。这样的工作做起来也更有趣。就个人而言，我发现从架构层面思考会更有吸引力，这对初级工程师们来说也是学习代码库的好办法。这就像自己身边永远有位高级工程师，我们可以随时向 Cline 提问，比如这个 repo 是干嘛用的？要实现特定功能需要参考哪些文件？

Alessio: 关于这点我还有个问题。你前几天发了条推文，有人要求 Roo Code 添加对 Gemini CLI 的支持，你们回复说“直接照我们的抄就行”。这到底是友好讨论，还是说气氛真有点紧张？

Cline 分叉与开源遗憾

Pash: 我只是在开玩笑啦，Cline 确实有很多分叉。

Saoud: 大概有 6000 多个。

Pash: 没错，如果大家在 VS Code 市场上搜索 Cline，会发现整个页面上都是 Cline 的分叉，甚至分叉还有自己的分叉。这些子分叉甚至都融资了，简直太疯狂了。

Saoud: OpenRouter 中排名前三的应用都是 Cline 和 Cline 的分叉。

Pash: 有意思。是啊，这背后对应的可是几十亿的 token。在欧洲有我们的分叉，在中国也有。三星最近在《华尔街日报》上发表文章，说他们正在使用 Cline，而且用的就是他们自己的分叉版本。这都代表着大家对 Cline 的认可。

Alessio: 那在开源方面，你觉得有什么遗憾吗？

Saoud: 完全没有。Cline 在立项之初就给编程智能体建立了良好的基础，人们可以在其中心情发挥自己的灵感、打造衍生品和新概念。大家表现出的热情让我们非常感动，也让我们了解到哪些方法有效、哪些没用，再据此持续调整产品设计。

总的来说，我认为这种全新的智能体编程范式至关重要，将彻底颠覆我们几十年来所熟悉的软件编写方式。所以从宏观角度看，我觉得 Cline 开源对整个开发领域乃至世界都是件好事，所以并没有什么遗憾。

智能体设计的简单性与复杂性

Pash: 我们的想法一直很简单：尽量简化模型、放手让模型解决问题、不做改变也不靠推理赚钱，同时关注上下文。

说回 Claude Code，很高兴看到这样一款产品的出现，它证明我们这种尽量保持简单的理念是可行的。

这跟 RAG 概念类似，那已经是 2022 年左右的早期产品了。当时的向量数据库厂商的上下文窗口非常小，虽然他们号称能给 AI 无限的记忆容量，但那只是忽悠风险投资人的营销策略。可他们的说法确实影响了很多人，所以直到现在也会有企业用户问我们会不会做索引、做 RAG。

这时候我就会反问，为什么非得做 RAG？从本质上讲，RAG 就是把所有文件切成小块再扔进一个超维向量空间当中，并在搜索相关片段时提取出这些随机数据。

在我看来这简直有点精神分裂……这会分散模型的注意力，而且还要拖累性能，就像高级软件工程师们刚接触新 repo 时得浏览文件夹结构、厘清依赖关系那样。相反，现在我们用代理方式探索 repo，发现效果更好。类似的情况还有很多，我们发现简单的方案总能胜出。

Fast Apply 就是个典型的反而教材。Cursor 是在 2024 年 7 月发布这项功能，当时的大模型还不太擅长编辑文件。在代理式程序的上下文中，编辑文件是这样实现的：先有搜索块，再有替换块，而且搜索块必须跟想要替换的内容完全匹配。这样，替换块才能将搜索块替换掉。当时的模型还不够好，他们内部使用的 GPT 没办法完美生成这些搜索块，失败的比例相当高。所以他们想出一个“聪明”的办法来微调这套 Fast Apply 模型，即输出我们熟悉的惰性代码片段，再把它输入到经过微调的 Fast Apply 模型当中——这是一种非常小巧的模型。这个小模型可以将输出以代码变更的形式覆盖整个文件。

但 Aider 的一位创始人很早就曾在 GitHub 会议上提到过，这种办法并不靠谱，因为一个模型就很容易出错了、现在出错几率直接翻倍。事实证明确实是这样，这个小模型的推理能力不够好，最大输出 token 只有 8000 到 1.6 万，下阶段的训练目标也只有 3.2 万……而 repo 中随便几个文件的长度就超过这个数，比它能输出的最大长度还要长。在这种情况下，模型就会犯各种错误，而且错误本身又相当微妙，看似可以正常工作、但实际上暗藏麻烦。

好在随着大模型越来越强大，我们再也不需要这些“聪明”的曲线解决办法了。现在我们不再领先 RAG 或者 Fast Apply，只需专注于核心智能体循环并最大限度降低编辑故障，这可谓是真正的解放。比如在我们自己的内部基准测试中，Claude Sonnet 4 的编辑失败率已经降低到了 5% 以下，大概在 4% 左右。而在 Fast Apply 刚推出时，这个数字大概在 20%、30%。那么六个月之后呢，会不会降到零？至少会逐渐趋近于零。

我们还跟一些采用过 Fast Apply 的企业谈过，他们坦言 Fast Apply 其实是纯粹的过渡时期产物，而且就快结束了——也许是三个月、也许更短。也就是说，RAG 在某些场景下仍然有用，比如那些包含大量知识、人类可读且并不具备明确内部逻辑的文档库。对于这类强调索引、分块、检索，且不涉及搜索和替换的场景，Fast Apply 模型仍有用武之地。

Saoud[00:46:33]: 无论 RAG 还是 Fast Apply，都只是工具包中的一种工具，那时候的模型在处理长上下文或者搜索替换和差异编辑方面都不够强。但现在的大模型自身变好了，所以这两者就成了多余的“配料”，反而可能会拉低准确率。

Cognition Labs 发布过一篇关于多智能体编排的文章，其中提到在使用多种模型和多种智能体时，往往会忽略掉很多细节，但正是这些细节决定成败——包括确保智能体不会陷入循环运行、不会反复遇到同样的问题、始终拥有正确的上下文。

所以我认为随着技术发展，我们应该把完整的上下文全都交给大模型，而不再采用所谓成本优化方案来提取相关上下文。

没错，这样的方式肯定成本更高，意味着 Claude Sonnet 这类顶尖模型会 grep 整个代码库并将其填充到上下文当中。但付出越多，得到的也就越多。

而开源的另一个好处，就是我们开发者可以观察到底层发生的一切。包括他们的请求被发送到哪里，提示词如何进行处理等等。这有助于建立信任。很明显，当用户每天花费 10 美元、20 美元甚至 100 美元购买服务时，他们肯定希望知道自己的数据大致被发到了哪里。要不然，人家凭什么花这份钱？

Pash: 没错，如果每个月只收 20 美元、还想保持正常的经营收益，那就肯定得用更小的模型，或者配合 RAG 来优化成本。但如果不靠推理赚钱、而是允许用户直接使用大模型，比如由用户自带 API 密钥，那就不需要刻意控制成本了，只要尽可能优化智能体质量就行。目前整个行业也确实朝着这个方向发展，大家开始接受按需付费模型或者直接为推理付费。我觉得这应该就是未来的趋势。

Cline 的商业模式

与自带 API 密钥方法

Alessio: Cline 在定价方面，遵循怎样的商业模式？

Saoud: 目前的方式是提供 API 密钥，相当于由用户向推理提供商做出预授权，并指定大家认为最适合自己工作的模型。只需要将 Anthropic、OpenAI 或者 OpenRouter 等 API 密钥接入 Cline，它就会直接接入用户指定的任意模型。我认为这样的透明度正是我们打造出色产品的前提。

我们不会浪费精力来设计什么套餐价格或者模型组合来牟利，这些用于提高利润空间的降本优化技巧意义不大。我认为这正是 Cline 独特的优势所在，让我们能够充分发挥顶尖大模型的潜力。而且这也透露出一个基本原则：一分钱一分货。要想用 Cline 处理任务，成本就不会很低。

Pash: 但高水平智能就是不会便宜。

Saoud: 没错，高水平智能不会太便宜。Cline 目前的商业模式就是允许用户选择如何开源、如何分叉、指定数据来源、选择向谁付费。我们的很多客户都从提供商那得到了一定程度的批量折扣，但总体来讲，Cline 的使用成本是挺高的。

Swyx: 但说来说去，我怎么感觉你们就不赚钱啊？那你们怎么承担员工工资呢？

Pash:其实主要利润来自企业级客户。企业级应用才是真正的重头戏。

Saoud: 开源和 API 密钥的引入让我们更容易得到企业组织的接受，Cline 也一直重视数据隐私、控制和安全问题。这一点非常重要，需要牢记。企业肯定不愿意把自己的代码和明文文本发送到莫名其妙的服务器上当作训练数据，所以 Cline 这种确保用户知晓自己数据被发到哪里、作什么用途的设计就很关键。客户可以放心，所有数据都不会经过我们自己的服务器，大家完全完全控制自己数据在整个应用流程中的走向。

过去几个月来，我们一直在讨论怎么进一步降低技术使用门槛。从本质上讲，真正要做的就是让更多客户和企业理解 Cline 智能体的解码方式。

Pash: 没错，而且我们将 Cline 推向开源，得到了大家的热烈欢迎。开发者在组织内使用，企业对于这类开源项目也相对比较认可，毕竟我们不会把他们的业务数据传来传去。他们可以使用现有的 API 密钥，我们则在网站上列出一份企业联络表单。如果大家对企业级产品感兴趣，可以直接联系我们。刚开始我们还没有企业级产品，结果很多企业客户都主动联系，甚至有一家顶尖大厂找到我们，说公司里有几百名工程师都在用 Cline，但根本搞不清楚他们具体用的什么 API 密钥、花了多少钱、把数据发到了哪里。他们的诉求很简单，“我们出钱，你们做个企业级产品吧。”于是产品就这样开发出来了。

Saoud: 反正事实证明，多听用户的意见肯定没错。在发布这个企业联络页面后，我们收到了大量需求，包括企业级功能、安全护栏、治理和洞察等等，这些都是组织管理员最需要的功能，帮助他们更可靠地使用 Cline 这类工具。也有很多客户希望我们能提供发票，帮他们更好地管理预算和支出。特别是欧洲那边的用户，这类需求就很典型。还有件事让人惊讶，就是 Cline 确实能为他们带来好处、让他们从中获益。而事过留痕的好习惯也让他们能有证据，向其他团队乃至企业高层证明 Cline 有多大的帮助，甚至错失 Cline 有可能被整个行业甩在身后。

Swyx: 就是说这能帮助企业内部用户证明 Cline 带来的投资回报率。明白了。

Saoud: 是的，他们可以用这个来证明支出的合理性。

模型成本下降的影响

Swyx: 还有一点我比较好奇，如果模型成本最终降到零会怎么样？比如 Gemini Code 刚出来的时候就号称免费，那肯定是件大好事吧？

Saoud: 那必须是件大好事。所以我还是那个观点，推理本身不足以成为一门生意。

Swyx: 就是说不可能单靠推理赚钱，对吧？

Saoud: 我们希望让最终用户以完全透明的方式理解价格，我认为这非常重要，而且他们也愿意花钱。目前这个领域的价格还太过混乱，导致开发者不愿意选择那些固定价格的套餐。好在越来越多的人开始倾向于透明的理念，就是不加推理、只提供产品，同时充分尊重开发者——让他们不仅了解成本来源，还了解自己在使用什么模型，这样能更有信心地处理工作。RAG 和 Fast Apply 之类的降本技巧当然仍会存在，但多数情况下编程智能体的投资回报率已经足够高，人们愿意多花点钱来完成工作。

Pash: 对于一款真正优秀的编程智能体来说，投资回报其实很难计算。但现在我们有了 Cline，很多原本懒得去做的实验、业余项目或者有待修复的随机 bug 都可以高效处理了。这到底产生了多大价值？其实很难具体量化的。

Swyx: 我们也可以换个问法……后台智能体和多智能体。比如说 Codex，它每分钟启动一项 PR；又或者是 Devin 和 Cognition。你觉得 Cline 会上服务器吗？就像看板那样同时运行在服务器和终端设备上的并行智能体。目前已经有人在为 Cursor 和 Claude Code 制作看板界面，Cline 会不会有类似的并行或者后台版本？

后台智能体与多智能体系统

Pash: 我们即将发布 Cline 的 CLI 版本，它是完全模块化的。就是说用户可以让 Cline 运行 CLI 来启动更多 Cline，或者在 GitHub Action 中以某种云进程的方式运行 Cline。就是说，CLI 实际就是这类完全自主智能体的构成要素。只要能够利用计算机上运行的现有 Cline CLI，并引导它朝着正确的方向运行，就能产生无数的可能性。Saoud，你觉得呢？

Saoud: 我觉得这不是个非黑即白的问题。各种不同的模式之间可以良好互补。Codex、Devin 乃至 Cursor 的后台智能体其实都是一个道理。如果要推出自己的版本，我想它将成为更多开发者在 Cline 基础上进行构建的前提。我们最近讨论过要不要构建一个开源框架，可以面向任意平台编写智能体、构建 SDK 和工具，以及其他有现实意义的功能。

如此一来，我们就能把 Cline 转化成 Chrome 扩展、CLI、JetBrains、Jupyter Notebook 乃至智能车载程序等。我们希望为开发者社区奠定基础，由社区在此基础之上做进一步开发，充分发挥自己的实验精神、想象力和创造力。

展望未来，我认为我们将要构建的是开源基础与构建模块，能够将 Cline 乃至其他工具引入软件开发之外的广泛领域。我认为这将让万物互补成为可能，但再次强调，这不是个非黑即白的问题。后台智能体肯定适合某些类型的工作，而并行看板多智能体可能更适合于实验性质的项目，比如给登录页面准备五个不同版本的外观。但如果需要获取上下文信息并为一项高度复杂的任务制定非常复杂的计划时，像 Cline 这样的单一智能体永远更有效率。我想这些工具之间会相互补充，人们会逐渐了解并体会到自己最适合哪种模式。总之展望未来十年，我们希望能继续站在时代前沿，为后台智能体乃至多智能体之外的下一代技术奠定基础。

上下文工程的现状

Swyx：我本来想聊聊上下文工程，这也是当前的热门话题。你在文档里聊过上下文工程，还有关于记忆库的部分，都让人印象深刻。我觉得现在很多人都在琢磨 AI 记忆这事。那咱们先从宏观说起，再具体聊记忆。你是怎么理解上下文工程的？就是说提示词工程。我觉得这不光是技术，更是一门艺术，它让智能体也出现了优秀与平庸的二八比例。很多人不清楚上下文中应该包含哪些内容，也不知道 MCP 和系统 Cline 间的相互作用。而这些，最终决定了智能体的实际质量。

Pash: 是的，上下文管理的一大组成部分就是把哪些内容加载进上下文。

另外一部分，则是在进入上下文窗口时，应该怎么清理其中的内容、怎样管理整个生命周期。我认为有很多可行的选择，但每种选择都有可能误导智能体、或者导致智能体的注意力涣散。有些人觉得可以用 RAG 或者其他检索的形式，我们则觉得智能体探索的效果更好。而且现在看来，智能体探索正逐渐占据优势。一般来讲，为了把内容加载到上下文中，需要配合提供一些工具，由模型决定具体要加载哪些内容。这有点像绘制一张导航图，展示正在发生什么，比如抽象语法树和 VS Code 中已经打开的选项卡等。在内部基准测试中，这种方法效果非常好。在打开几个选项卡后，它就像能读懂用户的想法一样。

Swyx: 这让我感觉有压力啊……我平时习惯放一大堆不相干的选项卡，现在看来得先把没用的关掉才好开始工作了。

Pash: 其实没必要想太多，Cline 在导航方面还是很智能的。虽然总有意外，但大多数情况下，我们都不用刻意给它准备什么。至于上下文管理，最重要的就是当信息逼近窗口最大容量时，该如何压缩原有内容？我们之前尝试过简单的截断方法，就是直接把对话的前半部分丢弃。但这样显然是有问题的，就像读书只读了后一半，那根本就不知道前一半到底讲了什么。叙事完整性很重要，每个任务、每位客户都像一个故事。作为主角，编程智能体的任务就是解决各种问题。

而我们则尽量保持叙事完整性，让智能体在每一步上都能预测下一个 token，也就是预测故事的后续走向。所以我们尝试了一些方法，比如清理重复文件，效果很好。但最终，我们认为这个问题也可以交给大模型——比如直接问模型，你觉得哪些信息舍监被放进上下文中？另一种方式则是总结，就是提取所有相关细节，这种方法也非常非常有效。

Swyx: 你又提到了抽象语法树（AST），它是用来做什么的？

Saoud: 它目前只是个工具，工作原理就是当 Cline 进行某种智能体探索、尝试获取相关上下文时，它会去了解特定目录中发生了什么。比如从目录中提取所有语言类型，或者类名、函数名之类。这样它就能大致判断这个文件夹是干什么用的。如果初步判断跟待完成的任务相关，那它就会实际读取这些文件，并跟上下文做匹配。本质上讲，它的作用就是搞清楚该如何在大规模代码库中导航。

Pash: 是的，其他一些公司也在搞相关研究。抽象语法树同时也是一种知识图谱，我们可以在知识图谱上运行各种确定性操作，比如找出代码库中的所有函数、找出未使用的函数并加以删除之类。智能体可以用这种类似 SQL 的语言进行推理，配合知识图谱执行全局操作。无论是检查并删除所有未使用函数，还是执行成规模的重构操作，编程智能体就都能实现了。以往这类尝试往往徒劳，耗费了大量 token 却最终失败。有了这些工具，智能体就可以通过查询对整个 repo 执行正确操作。我觉得这个方向还有很大的潜力，相当于抽象语法树的下一个层次，是一种用于查询知识图谱的语言。

但从 Claude 4 的情况来看，各大前沿模型厂商还是倾向在自己的应用层上进行训练。这就带来了新的问题，我们可能想出一种非常聪明的工具，理论上可以良好运行，但在 Claude 4 上的实际效果却很差，因为这套模型在训练中使用的是 grep。我们都以为顶尖模型会随时间推移变得更加通用，但实际上它们却变得更加专业化，要求用户选择更适合自己的模型家族。

Alessio: 那再聊聊记忆问题吧。记忆就是一种总结，比如总结上下文并提取一些侧面。那你们在研究中发现哪些有趣的现象了吗，比如关于代码的记忆可能不那么直观？我们肯定更熟悉人类的记忆模式，但关于代码库的记忆又是什么样的？

编程智能体中的记忆系统

Saoud:我认为就目前来讲，记忆很大程度上没有作用。大家并不想去解码记忆的构成，更重要的是如何保留智能体在工作过程中学到的部族知识，也就是那些并非靠记录或者规则文件来体现的知识。

Pash: 是的，这有点像某种“潜规则”。我们还专门进行过内部实验，构建了一款待办事项清单工具。这款工具的特点在于并不直接存储消息内容，而是保存整体清单的最新状态，而且每隔一段时间传递一次上下文信息。我们发现在经过多轮上下文汇总和压缩之后，智能体确实可以保持靠谱，而且从头开始构建一整套远超上下文窗口的复杂任务。这样的结果让我们大受鼓舞，目前正在努力做实施落地。记忆库的概念是我们的市场营销人员 Nick Bauman 提出的，他会随时把正在处理的事情记在小本子上。我觉得智能体也可以采取这样的思路，也有一个虚拟的小本子，上面记录的是目前为止已经做了什么、还剩什么之类。在会话之间传递这些上下文信息，也许就能实现记忆共享。

Alessio: 你对 Claude.md、Agents.md 和 Agent.md 是怎么看的？我开发过一款名叫 Agents927 的开源工具，类似于 XKCD，只要把它粘贴到不同文件名中即可，这样就能让其他工具访问它。你觉得使用同一个文件会有问题吗？我总觉得 IDE 规则和智能体规则是不一样的，这样是不是不好？

Saoud: 我觉得不同工具保持各自的特定指令没有问题，毕竟我自己也会分别使用 Cursor 规则和 Cline 规则。我希望 Cline 智能体的工作方式能跟 Cursor 保持一定的差异。所以虽然我有看到很多人对此表达了不满，也会让代码库变得有点乱，但我还是觉得区分开来利大于弊。

Cline 的招聘与团队文化

Swyx: 听说你们正在招人，现在团队只有 20 个人，后续打算扩展到 100 人。那你们打算用什么宣传语来吸引新鲜血液？

Saoud: 到目前为止，我们招聘的大部分员工都是朋友介绍、自己认识的人或者之前合作并且信任的伙伴，我们知道他们能胜任这个极其艰巨的项目。未来还会有更多挑战，我觉得面对高难度问题是最令人兴奋的。很多工程师喜欢那种能多赚钱的工作，但我个人还是喜欢做有挑战性的，尤其是开发编程智能体。所以我们需要的是那些真正有上进心、愿意应对挑战的人，比如愿意规划未来十年的发展方向，为后台智能体或者多智能体的后续发展奠定基础，并真正参与到方向性的决策当中。

我们建立了一个由用户和开发者组成的活跃社区，开源也帮助我们积累下极高的人气。我们收到的很多反馈对于路线图的制定都很有建设性、很有帮助。我们与这样优秀的社区合作开发产品，绝对是让人成就感满满。虽然大家大部分时间是在办公室里，但有时候也会组织卡丁车、皮划艇之类的活动。总之工作很辛苦，但一路上的乐趣也不会少。

Pash: 没错，Cline 是一家独特的公司，同事们就像好朋友一样，而且能创造出超酷的成果。我们得超级努力才行，毕竟这个领域的竞争不能说激烈、而是超级激烈。每一家竞争对手都有机会拿到几千万融资，就连我们的分叉项目都有机会。我们现在有 20 个人，目标是到今年年底扩张到 100 人。

开源项目也面临着自己的挑战。我们需要做大量研究、组织内部基准测试、确保我们的 diff 编辑算法足够健壮，然后把成果开源并发布在 Twitter 上。但我们并不怕其他人抄袭，我们是这个领域的领导者，正在为整个行业指明方向。作为一名工程师，开发出这么多产品真的非常让人兴奋，能跟同事们并肩作战超级幸福。

原文链接：

声明：本文为 InfoQ 翻译整理，不代表平台观点，未经许可禁止转载。

今日好文推荐

用户集体大逃亡！Cursor“自杀式政策”致口碑崩塌：“补贴”换来的王座，正被反噬撕碎他救了OpenAI、年赚过亿、三家明星CTO，却自曝跟不上AI发展了！硅谷大佬告诫：不是马斯克，就别碰大模型OpenAI深夜祭出GPT-5，所有人能免费用！Altman：像和博士级专家对话从烧光现金、裁掉一半员工，到 ARR 9 个月破亿：Replit用“全栈平台”反杀Cursor，赌赢“每层都赚钱”模式

会议推荐

首届 AICon 全球人工智能开发与应用大会（深圳站）将于 8 月 22-23 日正式举行！本次大会以 “探索 AI 应用边界” 为主题，聚焦 Agent、多模态、AI 产品设计等热门方向，围绕企业如何通过大模型降低成本、提升经营效率的实际应用案例，邀请来自头部企业、大厂以及明星创业公司的专家，带来一线的大模型实践经验和前沿洞察。一起探索 AI 应用的更多可能，发掘 AI 驱动业务增长的新路径！