没KPI反而爆了？Cursor大神一人敲出核心功能！CEO上手7天不宕机，AI编程玩法被打假

昨日，Cursor 的 CEO Michael Truell 在 X 上发帖表示，其在 Cursor 开发环境中，基于 GPT-5.2 构建了一款浏览器，并实现了连续一周无间断运行。

据介绍，这款浏览器的代码总量超 300 万行，目前已具备基础可用性。其渲染引擎为纯 Rust 语言从零开发，涵盖 HTML 解析、CSS 级联、布局排版、文本整形、绘制渲染等核心能力，并内置了定制化 JavaScript 虚拟机。网友纷纷表示，“既然我们可以自己制作个性化浏览器，为什么还要花时间下载 Chrome 呢？”

同时，Truell 在帖子下方分享了一篇主题是“扩展长时间运行的自主编码能力”的博客文章。博客中指出，Cursor 一直在尝试让编码 Agent 一运行就是数周，且完全自主地工作。通过在单个项目上同时运行数百个并发 Agent、协调它们的工作，并观察它们写出超过一百万行代码和数万亿个 token，其得出的结论是：结构太少，Agent 会互相冲突、重复劳动、不断偏离；结构太多，则会让系统变得脆弱。运行框架和模型本身固然重要，但提示词更重要。

从零开始构建出一个浏览器，就是他们在测试过程中的产物。据称，“Agent 持续运行了将近一周，在 1000 个文件中写出了超过 100 万行代码。”对此，有网友提出，“可以用 Cursor 来创建 Cursor 吗？”但这个项目，却火速被“打假”了，被证根本就没能成功编译。一位开发者发文指出，任何软件开发人员都能一眼看出，其绝非规范的工程化代码，而是“AI垃圾代码”（AI slop）。

然而，近期， Cursor 的工程负责人 Jason Ginsberg 接受了 LinkedIn 的联合创始人兼首席执行官 Harrison Chase 的采访。谈话中，他们围绕 Agent 和 AI 编程等话题展开交流，不仅揭秘了 Cursor 团队内部通过并行运行多个 Agent 的大型“甩活儿”工作模式，同时透露了 Cursor 未来的开发方向、最终交互模式、产品路线图及人员规划。在对话尾声，Ginsberg 还回答了许多来自访谈现场的开放问题。

下面是详细对话内容，我们在不改变原意的基础上进行了翻译和删减，以飨读者。

Jason Ginsberg： 好的。我目前在做一款 AI 编程工具，已经在 Cursor 工作了六个月，担任该产品的工程负责人。不过说实话，我日常的大部分时间还是在写代码和做设计工作。在加入 Cursor 之前，我在 Notion 负责 Notion Mail 相关工作。几年前，我创办了一家名为 Skiff 的公司，后来这家公司被 Notion 收购了。所以，我一直都在从事产品开发相关的工作，而且主要聚焦在生产力工具领域。

Jason Ginsberg： 我认为编码 Agent 的发展确实可以用 “翻天覆地” 来形容，而且这些变革基本上都是在一年多一点的时间里发生的。正如你所说，Cursor 最早开启了代码自动补全的先河，这种模式主要是在逐行的层面上提供辅助，适用范围也基本局限在单个文件内。而此后，几乎每隔几个月，我们就不得不提升产品的抽象层级，这其实是一个极具挑战性的产品设计难题。显然，Agent 的出现让开发者能够在多个文件之间灵活切换，并且可以放心地让 Agent 自主完成代码修改工作。

在过去两个月左右的时间里，我发现行业又出现了新的转变：开发者现在已经能够做到从项目启动到结束全程信任 Agent，并且会对整个代码库中多个文件的内容进行批量审核。因此，我们不得不对产品的整体布局进行大幅重新设计，将核心从逐行的代码差异对比，转向更偏向代码审查的模式。

展望未来的产品开发方向，我们的工作重心其实会更多地放在多 Agent 协同运行上。我们需要实现的是，能够快速验证这些 Agent 是否在正常运行，并且可以让它们并行工作，同时避免受到当前单一对话模式下各种选项和选择的束缚。

Jason Ginsberg：我认为大模型性能的提升是一个很关键的因素，这让开发者能够更加信任 Agent 编写的代码质量。要知道，以前大家必须对 Agent 生成的代码进行非常全面细致的审查。

同时，现在也有了更完善的代码审查工具。比如我们有 BugBot，市场上其实还有很多类似的工具，它们都能够自动检查代码中存在的问题。

此外，我觉得从行业文化层面来看，开发者们对 Agent 工具的接受度和使用信心也在不断增强，甚至可以说已经 “上瘾” 于这类工具带来的便捷。而且，一旦习惯了完全依赖 Agent 进行编码的工作模式，再切换回传统的编码方式其实是很困难的。所以现在，我们能看到越来越多的开发者已经将 Agent 辅助编程作为默认的工作方式。

Jason Ginsberg：其实在我们公司内部，工程师们使用 Cursor 的方式就五花八门。甚至团队里有几位工程师，他们完全不使用 Cursor 的 Agent 功能，比如负责安全和基础设施的同事。所以，确实有一部分用户非常依赖代码自动补全功能，日常使用中大部分操作都是基于补全功能完成的。但令人意外的是，我发现团队里一些最顶尖的工程师，我们称他们为 “核心用户”，他们做任何工作都会完全依赖 Agent，甚至会同时运行多个 Agent 并行处理任务。

至于我个人的使用习惯，我并不会去设计那些复杂繁琐的提示词，也没有什么所谓的 “Agent 使用秘籍”。我写的提示词往往都很简短，甚至还会带有拼写错误。我会针对手头不同的工作任务，或者同一个问题的不同模块，同时启动多个 Agent，然后等待它们返回结果。

目前我用得最多的是我们今天刚刚发布的一个新功能：调试模式。这个模式下，Agent 能够通过生成日志来进行自我评估，之后开发者复现相关操作步骤，Agent 就会通过查看日志判断问题是否得到解决。这个功能非常实用，因为它相当于通过投入算力去不断尝试解决问题，最终攻克那些手动排查起来极为棘手的难题。

Jason Ginsberg：其实我也认同你的这个想法。所以在开发调试模式的时候，我们内部确实有过不少争论。主要原因在于，Cursor 目前已经有很多功能模式了，如规划模式、询问模式等等，这些模式其实不太容易被用户发现。我们一直认为，这些模式都很实用，理想的状态应该是，Agent 能够根据用户的操作场景，自动匹配并启用最合适的模式，无需用户手动切换。

而现阶段调试模式之所以需要手动开启，是因为它的交互方式比较特殊。在运行过程中，Agent 会暂停当前的工作，向用户提问以获取反馈。如果用户不熟悉这种交互逻辑，可能会觉得比较困扰。

Jason Ginsberg：我举个例子吧。假设我正在开发一个前端应用，遇到了一个很让人头疼的问题：菜单总是在左上角弹出。这时候我会对 Agent 说：“这个菜单需要锚定到按钮的位置。” 随后，Agent 会启动服务器，并在整个代码库中添加大量日志，同时提出一系列可能导致该问题的假设，如 “可能是某个定位参数设置错误”、“可能是事件绑定逻辑有问题” 等。之后，Agent 会提示我：“麻烦你点击这个按钮，打开菜单，看看问题是否解决。” 如果我反馈问题依然存在，Agent 就会查看生成的日志，然后分析判断：“这个假设成立，那两个假设不成立”。通常这样反复两三次之后，Agent 往往就能找出并解决问题。

Jason Ginsberg：一两个月内，毕竟这个行业的发展速度实在太快了。

Jason Ginsberg： 很多时候，确实就是修改一下系统层面的提示词。不过在某些情况下，我们也需要对用户界面进行相应的调整。比如规划模式现在也加入了交互提问功能，运行过程中会主动打断用户操作，寻求反馈。用户有时也可以自行设置参数，如调整 Agent 打断的频率等。再比如询问模式，它不只是依赖特定的系统提示词，还会限制 Agent 调用某些与文件编辑相关的工具，以此来保证功能的稳定性和可靠性。

Jason Ginsberg：我觉得并没有什么 “最佳方式”，具体的使用方法很大程度上取决于工程师的个人工作习惯以及他们所处理的具体工作内容。目前行业里，既有异步运行 Agent 的应用场景，也有开发者深度参与、实时交互的模式，就像一边编程、一边像画画一样实时调整代码或者进行可视化的编辑操作。不过我经常在推特上看到一些所谓的 “Agent 使用技巧”，其实对此我是有点持保留态度的。很多人会说 “这才是使用 Agent 的最佳方式”，但在我看来，这些技巧往往是凭空杜撰的。

我们团队内部其实并不会使用那些冗长复杂的提示词，也不会采用多阶段规划的策略。大多数时候，我们都是快速迭代，如果 Agent 运行的结果不理想，就直接终止进程，重新启动 Agent。通常这种方式的效率是最高的。

Jason Ginsberg： 当然，我肯定会带有一定的主观偏向性。但我认为，终端工具并不会成为用户的首选。我觉得，真正驱动行业发展的是用户对 Agent 的信任度不断提升，他们更希望等到 Agent 完成所有工作后再查看最终的修改结果，然后决定是否采纳，同时也愿意让 Agent 运行更长的时间，以实现更智能的处理。

而 IDE 之所以至关重要，是因为它是为整个软件开发周期量身打造的工具。从项目的构思规划，到运行代码修改、查看代码内容、清晰对比代码差异、提交代码合并请求，再到在浏览器中预览效果所有这些环节，都可以无缝集成在 IDE 的模块化功能之中。这一点其实很容易被忽视，毕竟 IDE 的这些功能是经过了数十年的发展才逐步完善起来的。

我认为，当前行业的一个明显趋势是，产品层面的设计变得越来越重要。现在 Cursor 用户使用频率最高的功能，如规划模式，其实都需要可视化编辑器的支持，用户需要能够在编辑器中添加注释，并进行实时交互。一旦脱离了按钮、弹窗和菜单这些可视化交互元素，用户与工具的交互难度会大大增加。

不过，我觉得未来并非所有操作都必须局限在笔记本电脑的 IDE 中完成。这种模式并不会被完全取代，具体的使用场景会根据实际需求灵活变化，适用的场景也会更加广泛。用户在更多场景下，都能够使用到 Cursor 这样的工具。

Jason Ginsberg：对，我们确实有官网。这么做的原因是用户可以通过手机等设备随时随地访问。我觉得在不远的将来，用户完全可以戴着 AirPods，开启语音模式，和 Agent 实时沟通、碰撞想法，让 Agent 不断优化方案。等用户到了办公室，打开笔记本电脑，就已经有一堆代码修改记录或者演示视频等着审核了，到时候只需要简单确认通过或者驳回就行。如果某些细节还需要微调，再把项目下载到本地修改就好。

Jason Ginsberg：我觉得总体来说，我们产品的大部分设计其实并不是 AI 专属的。要知道，产品可用的交互组件和用户体验模式就那么多，市面上的应用本质上也都是基于一些传统的模式搭建的，如收件箱、仪表盘、聊天界面，这些都是很成熟的设计。所以我们的工作核心，更多是把这些现有的设计模式进行合理组合，然后在产品中恰当地呈现出来。这一点和 Notion 的产品理念是相通的，同时也是 Cursor 和集成开发环境（IDE）的核心特质：极高的模块化程度。

作为用户，你会发现每个人的 IDE 界面布局都可以千差万别。你可以自定义面板布局，把任意组件拖放到任意位置，和坐在你旁边的同事设置出完全不同的界面。我认为这种模块化设计对产品的适应性至关重要，毕竟如我之前所说，Agent 的能力发展日新月异，用户对产品的需求和期待几乎每隔几周就会发生变化。几个月前我们推出 Cursor 2.0 的时候，并没有把原来的产品推倒重来，只是把各个功能模块重新组合，调整为侧边栏收件箱式的管理布局，同时优化了聊天界面的信息密度而已。

Jason Ginsberg：我认为底层的设计逻辑和核心要素其实没有变，关键变化在于谁在主导界面交互。而在这个核心框架下，其实可以演变出无数种交互形式。就拿交互的抽象层级来说，一年前大家使用 Agent 的时候，都恨不得盯着它的每一步操作，全程 “盯梢”。但现在 Agent 的操作步骤变得无比繁杂，用户根本看不过来。所以我们需要优化信息呈现方式：如何对操作步骤进行分组？如何提炼关键信息？

当用户足够信任 Agent 的操作后，我们就需要把重点放在文件的实际修改内容上，并且为这些修改添加更详细的注释说明。当然，我们也可以进一步提升交互的灵活度，比如聊天对象不再局限于单个 Agent，而是可以同时和多个 Agent 对话。这就需要一套更智能的后台交互逻辑来支撑 ，系统要能识别用户在和哪个子 Agent 对话，并且协调这些 Agent 完成对应的修改。未来这种交互的抽象层级还会不断提升。

Jason Ginsberg：我觉得未来，我们现在看到的各种操作选项，如选择模型、选择功能模式、选择运行环境这些都会逐渐消失。最终的交互模式会变得像和真人对话一样自然。但这并不意味着任何人都能随便写代码，在那个阶段，这个工具依然是为专业工程师服务的。因为你还是需要具备专业的行业术语知识，清楚自己想要修改的内容是什么。做产品的人，要明确自己想要的工作流程和功能需求；做基础设施的人，要足够了解代码库，知道什么样的架构和系统设计最适合当前要开发的项目。

而且我想强调的是，随着抽象层级的提升，我们并不会摒弃现有的功能。用户依然可以随时深入底层，查看细节、调整参数。只是产品的默认交互方式会不断优化升级。

Jason Ginsberg：首先，就我们产品团队的工作模式来说，现在人工审查的比重已经大幅降低了。我们有一个叫 BugBot 的工具，它会自动检测代码问题，并且自主完成修复，还会在持续集成（CI）流程中不断迭代优化。这个工具的表现非常出色，也让我们对 AI 审查的代码质量更有信心。

其次是信息的语义化分组。用户查看代码差异时，可以清晰地看到 Agent 做了哪些修改。我们甚至可以展示 Agent 的原始指令，更理想的状态是，Agent 能够像人类一样，在处理大型代码合并请求时，为每一处修改附上注释，说明这么做的原因。我觉得这虽然算不上颠覆性的变革，但确实能给代码审查工作带来显著的优化。

Jason Ginsberg：哈哈，这个问题很有意思。如果你以工程师的身份加入 Cursor，会立刻发现一个现象：所有人都在深度使用自家产品。我记得我入职第一周的时候，修改了一个快捷键设置。那个快捷键是 Alt+Shift+Command+J，非常冷门，我当时觉得选这个键肯定没人会注意到。结果刚改完不到半分钟，就有三个同事在 Slack 上发来消息：“你改的这个快捷键直接打乱了我的工作流程！到底怎么回事？”几乎任何产品改动，都会立刻收到同事们的强烈反馈。我觉得这其实是一件好事，大家就是在这种高频的反馈和交流中，快速推进产品迭代的。

Jason Ginsberg：在我创办自己的公司之前，工程师们也会用邮件沟通，但用得并不多。大家甚至会说：“邮件只用来收垃圾邮件和购物通知，可别用它来发长篇大论的工作内容。”而在 Agent 这个赛道工作，其实完全不需要依赖邮件这种低效的沟通方式。我们团队的所有人都全身心投入工作，毕竟这是一个竞争非常激烈的领域，大家都对产品开发充满热情，会自然而然地用各种即时沟通工具协作。

另外，我在规划产品功能时，会遵循一个核心原则：我能开发什么功能，让自己的日常工作更轻松？ 具体来说，就是思考 “做什么能帮我明天更高效地完成工作，不用再处理那些烦人的报错和问题”。这个原则指导着我们的大部分工作。毕竟这种功能开发出来之后，我们自己能立刻受益，比如修复了一个烦人的漏洞，以后上班就不用再被这个问题困扰了。

Jason Ginsberg：这个比例确实随着公司规模的扩大在变化。现在我们也会制定月度的产品路线图和目标，但说实话，我们很多核心功能都来自自下而上的创新。比如 Cursor 的 Agent 功能，这可以说是大家提到 Cursor 时最先想到的核心功能。这个功能是我们团队的一个人开发的，最开始所有人都不看好这个想法，但他很快做出了原型。大家试用之后都惊叹：“哇，这东西居然真的能用！”

我之前提到的调试模式也是如此。感恩节假期的时候我闲着没事，就开发了这个自己很需要的功能，现在这个功能也即将上线。这些功能的开发初衷，都是为了解决团队内部的需求。我们判断一个功能是否具备发布条件，一个重要的衡量标准就是内部的使用率和认可度。

Jason Ginsberg：说实话，我们的工作流程其实非常精简，没有太多繁琐的制度。公司里虽然有几间会议室，也有一两位产品经理，但我们很少通过撰写文档或者开对齐会议来推进工作，大部分的讨论和决策都是在代码层面完成的。而这一切能够实现的核心原因，是我们对人才的极高要求。今年年初的时候，公司总共也就 20 人左右。之所以团队规模增长缓慢，就是因为我们的招聘门槛高到近乎苛刻。我们会反复评估：这个人很优秀，但他能成为团队里最顶尖的那批人吗？

正因为团队里的每个人都足够出色，所以我们可以放心地把任务交给任何一个人。团队成员的主观能动性都极强，从提出想法、设计用户体验，到在推特上回复用户的支持请求、和企业客户沟通需求，再到最终将功能落地，整个流程都能独立完成。所以说，我们能保持这样的速度，归根结底还是人的因素。

Jason Ginsberg： 我们确实会投入不少精力去思考未来，比如预判未来三个月可能实现的技术突破，然后主动押注相关方向，团队里有相当一部分人都在做这类前瞻性的工作。我们制定的月度路线图更多是围绕核心产品功能展开，聚焦于用户的实际需求以及那些能优化日常使用体验的功能。而那些需要投入两个月时间重构底层逻辑的重大项目，则会纳入更长期的规划范畴。

此外，我们的应变能力其实非常强。

有时候我们会提前拿到新模型的测试版本，试用之后如果发现它在某些方面表现特别出色，团队成员往往会主动利用周末时间加班，争取在新模型正式发布前就完成相关功能的开发。很多重要功能其实几天之内就能搭建完成。

Jason Ginsberg：我们发现，工程师使用我们产品时的编码场景，需要有专门适配的模型来支撑。Composer 模型就是针对这类场景打造的，它定位非常明确，具备速度快、质量高、逻辑智能三大特点，尤其适合 “人机实时协作” 场景。我自己做前端开发时就经常用它，因为我需要频繁做出细微的交互设计决策，这就要求 Agent 能在几秒内给出反馈。Composer 就像一个高效的协作伙伴，能快速响应需求、碰撞想法，和那些适用于长周期异步任务的模型形成了很好的互补。

Jason Ginsberg：我们确实有专门的团队负责 Agent 的性能优化，他们主要聚焦于工具链、调度框架的搭建以及效果评估。但正如我之前所说，我们的团队架构并不僵化，没有严格限制大家的工作范围。比如核心产品团队的工程师在开发规划模式时，如果需要对 Agent 进行调整，就会和 Agent 团队密切协作。而且在开发过程中，我们依然会深度使用自家产品进行测试，团队成员会分享使用感受，以此来评估功能的实际效果。

Jason Ginsberg：我觉得他们大多是偏产品方向的人才，而不是传统意义上的机器学习或算法研究专家。这些人经常在不同团队之间轮岗，因为 Agent 研发需要对用户的最终使用体验有很强的直觉，同时还要能准确解读团队的反馈意见。

Jason Ginsberg：我其实没有深度参与这方面的工作，但据我了解，我们的核心目标是打造高度灵活的架构。毕竟我们需要不断尝试新技术、新功能模式，所以架构必须能够随着模型能力的升级快速适配。

Harrison Chase：很有道理。毕竟整个行业都在飞速变化。

Jason Ginsberg：我觉得它并不是为沉浸式可视化编码设计的。就像我之前说的，这个功能最初是我为自己开发的，我本身就是一名做产品的工程师，它的核心用户群体其实是专业工程师和设计师。大家在开发应用时，肯定都遇到过这种情况：精心设计的界面，最后却变成了大家都看腻了的紫黄渐变配色。这个功能就是为了让大家能够精准把控细节，比如把内边距调整到精确的像素值。它为用户提供了一套更直观的 “视觉化操作语言”，比纯文本指令的精度更高。

而且就算不使用侧边栏，你也可以直接点击页面元素，随时输入提示词下达指令。借助这个功能，你可以在几秒内同时启动六个 Agent。如果开启热重载功能，你的网站会实时呈现修改效果，用起来其实还挺有意思的。

Jason Ginsberg：当然可以。未来的发展方向就是让 Agent 具备自主评估能力，根据需求长时间持续运行、循环迭代。现在的调试模式还需要人工点击按钮来确认日志信息，但这只是过渡方案。理想的状态是，Agent 能够自主完成评估、迭代，直到彻底解决问题。

Jason Ginsberg：我们正在进行大量的实验和探索。目前已经落地了规则管理、内存记忆、技能库等多个功能模块。现阶段，我们主要在研究高效的信息摘要技术。另外，借助我们的自研模型，我们也在探索让模型自主识别对话或代码中反复出现的关键信息。当然，跨组织的信息共享功能也很值得探索。不过这里有个需要注意的点，相关规则和信息可能会随着模型的迭代而过时。所以我们必须确保用户能够轻松更新这些内容，避免被过时的规则束缚。

Jason Ginsberg：你说的是 Composer 模型，对吧？我们会持续对它进行迭代优化，它并不是一个静态的模型。我们的核心关注点，是在速度和智能之间找到最佳平衡点，满足 Cursor 用户在大部分场景下的需求。不过在长上下文处理这类特定领域，我们确实还有提升空间。

Jason Ginsberg：坦白说，我们目前并没有把这类用户作为核心关注点。当然，我们认同工具的使用门槛确实需要不断降低，而且 Cursor 的易用性也在持续提升，比如新增的浏览器工具对设计师就很友好。但我们的核心目标，其实是赋能顶尖工程师。我们一直在思考：如何让世界上最优秀的工程师变得更加强大？在这个过程中，我们开发的工具自然会惠及更多人群。不过在产品优化方面，我们确实还有很多工作要做，如优化新手引导和环境配置流程。毕竟设计师和产品经理在配置 GitHub 等工具时，经常会遇到困难。我们希望通过优化这些环节，吸引更多用户尝试 Cursor。

Jason Ginsberg：说实话，我们正在尝试让 Agent 自主完成测试工作，不过这项功能目前还没有完全发布。对于从事质量检测工作的人员来说，我强烈推荐试试我们刚发布的调试模式。这个功能定位问题的逻辑非常清晰，几乎可以说是确定性的，用起来会很有帮助。

Jason Ginsberg：我觉得机遇不在于语音 Agent。用户现阶段最核心的需求，其实是让 Agent 变得更智能、运行时间更长、能处理的任务更多。现在的很多 Agent，本质上只是在 “读取代码”，并不能真正判断修改后的代码是否有效。未来的发展空间非常大，我们可以投入更多算力，让 Agent 承担更多人类目前负责的校验工作。我觉得未来三到六个月，整个行业都会迎来巨大的变革，非常值得期待。

参考链接：

https://www.youtube.com/watch?v=dKSGK-fPFyU