整理 | 华卫、Tina

过去一年，编码 Agent 的变化速度，已经快到让人很难用“功能升级”来形容。

如果把时间拨回到一年前，Agent 还主要停留在代码补全、对话式改几行代码的阶段；而今天，在 Cursor 内部，工程师已经开始同时运行多个 Agent 并行“甩活儿”，让它们在代码库中自主修改、调试、复盘，再由人类在最后阶段集中审核结果。开发者不再盯着 Agent 的每一步操作，而是开始习惯“等它跑完再看答案”。

在最近一次访谈中，Cursor 工程负责人 Jason Ginsberg 给出了一个明确判断：这不是渐进式优化，而是一场正在发生的“换代”。更重要的是，他把这场变化的时间窗口，压缩到了未来三到六个月——在他看来，Agent 将不只是“更聪明”，而是会真正接管更长周期、更复杂的工程任务，整个行业的工作方式也将随之重塑。

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

一年多时间，编码 Agent“翻天覆地”

Harrison Chase：Jason，你能跟大家简单介绍一下自己吗？也给大家讲讲 Cursor 是什么吧。

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

Harrison Chase：非常棒。我有很多话题想和你探讨。要不我先抛砖引玉，问问你对编码 Agent 的发展历程，以及这些年来人机交互模式演变的看法吧。你们可以说是这个领域的先行者之一，我认为编码 Agent 的发展经历了几个阶段的转变：从最初的代码自动补全，到集成在集成开发环境（IDE）中的对话式交互，再到如今出现的各类终端工具，以及基于云端的异步 Agent。我很想听听你的看法，你觉得这样概括其用户体验的演变历程是否准确？或者你们团队是如何看待这一发展过程的？

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

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

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

Harrison Chase：推动这些变革的核心因素是什么？仅仅是因为大模型的性能变得越来越好，还是有其他更多的影响因素？

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

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

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

最顶尖工程师的干活秘诀：全靠 Agent？

Harrison Chase：你观察到大家使用 Cursor 的方式都有哪些不同？或者你自己平时是怎么使用 Cursor 的？

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

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

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

Harrison Chase：调试模式具体是什么样的？为什么需要专门设置这样一个模式？难道不能自动完成调试吗？直接给 Agent 下达调试指令不也可以吗？

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

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

Harrison Chase：Agent 具体会询问哪些问题，又需要用户提供什么样的反馈呢？

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

Harrison Chase：你觉得人类还需要手动操作多久？就不能让 Agent 自主完成点击、测试这类操作吗？

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

Harrison Chase：刚才你提到了 Agent 的多种不同模式，比如规划模式、解释模式、调试模式等等。这些模式在实际应用中到底意味着什么？难道只是为 Agent 设置不同的提示词这么简单吗？还是说背后有更复杂的逻辑？

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

Harrison Chase：回到之前的话题，关于大家使用 Cursor 的不同方式，你觉得未来使用编码 Agent 或者说 Cursor，存在所谓的 “最佳方式” 吗？

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

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

自然 “唠嗑”是 Cursor 最终交互模式？

Harrison Chase：如果让你预测一下一年后的情况，你认为开发者在 IDE、终端以及其他形态的载体上使用 Cursor 的时间占比会是怎样的？

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

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

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

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

Harrison Chase：未来会有更多场景都能用上像 Cursor 这样的工具。你们应该有对应的官网吧？用户可以直接在网页上进行交互操作，是这个思路吗？

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

Harrison Chase：我认为 Cursor 真正的优势，在于围绕 Agent 交互打造的整套设计和用户体验体系。你之前在 Notion 工作过，我记得即便是在生成式 AI 普及之前，Notion 的设计和用户体验就已经广受认可了。当然，他们在生成式 AI 时代也很好地完成了转型。从一家在生成式 AI 普及前就拥有出色设计积淀且顺利完成转型的公司，再到如今专注 Agent 相关工作，你觉得 Agent 的出现给产品设计和用户体验带来了哪些变化？现在的工作模式和之前有相似之处吗？

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

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

Harrison Chase：听你这么说，很多组件的底层逻辑其实是相通的。那有没有出现新的组件？或者某些组件的优先级发生了变化？毕竟这些组件最初都是为 “人类与软件交互”“人类通过软件协作” 的场景设计的，现在加入了 Agent 这个新角色。这其中有没有产生什么新的变化？还是说其实本质上没有太大不同？

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

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

Harrison Chase：你觉得交互的抽象层级最高能达到什么程度？我知道预测未来很难，但还是想听听你的看法。

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

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

Cursor 内部工作揭秘：少审代码、高频反馈

Harrison Chase：你之前提到了人类在 Agent 工作流程中的角色，比如查看代码差异、进行代码审查。你觉得 AI 会给代码审查工作带来哪些改变？

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

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

Harrison Chase：出于好奇，我想问一下，Cursor 的工程师用 Cursor 写代码，用 BugBot 审查代码，那他们还需要和其他工程师沟通协作吗？

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

Harrison Chase：从组织管理的角度，你们有没有采取什么措施来鼓励或者引导这种高频反馈的协作模式？毕竟大量的反馈涌进来，有时候也会让人应接不暇。

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

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

迭代狂飙背后，核心功能竟来自员工 “自嗨”？

Harrison Chase：你觉得你们的产品路线图，有多大比例是由 “让自己工作更轻松” 这个需求驱动的？又有多大比例是来自外部用户的需求？这个比例随着公司发展有变化吗？

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

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

Harrison Chase：你们的产品迭代速度快得惊人，是怎么保持这种高效的开发节奏的？

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

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

Harrison Chase：你们是如何规划产品路线图的？你刚才提到了以月为单位的规划周期，这是目前的常规规划时长吗？有没有更长期的规划？另外，行业技术迭代的速度实在太快了，你们是如何平衡 “跟进现有技术浪潮” 和 “实现技术跨越式发展” 这两者的？会不会主动预判技术趋势，提前布局未来方向？

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

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

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

Harrison Chase：说到模型，你们发布了自研的 Composer 模型。开发这个模型的初衷是什么？目前用户的使用情况如何？这个模型有没有改变大家使用 Cursor 的习惯？

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

Harrison Chase：Cursor 的 Agent 相关研发工作是全员参与，还是有专门的团队负责？

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

Harrison Chase：无论是 Agent 团队的成员，还是其他团队中擅长 Agent 研发的工程师，他们身上有没有什么共同特质？他们的专业背景或者个人能力有没有什么特别之处？

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

Harrison Chase：上周你们和 OpenAI 合作发布了一篇博客，内容是针对 OpenAI 的新模型优化 Cursor 的 Agent 调度框架。我在推特上经常看到大家讨论 “Agent 调度框架” 这个概念。你们是如何看待模型的底层支撑架构的？这类架构是否需要和特定模型深度绑定？比如 Composer 模型和 CodeLlama 模型，对应的架构会不会有很大差异？

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

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

开放问答

提问者 1：刚才提到了新增的可视化浏览器功能，我发现有些工具比如 Lovable 也有类似的功能。请问这个功能是朝着 “沉浸式可视化编码” 的方向发展吗？

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

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

提问者 2：我特别喜欢你们的浏览器 Agent，一直在用。但我发现一个小瑕疵：我想持续迭代优化设计方案，可 Agent 总是会中断我的工作，直接提交代码合并请求。未来有没有可能实现不间断的持续迭代？

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

提问者 3：我不知道你是否深度参与 Agent 相关的研发工作，但我注意到 Cursor 的内存管理功能做得很好。它可以根据工程师个人、部门乃至整个公司的偏好、规则和流程，自主管理相关信息。我们都知道，信息和上下文对 Agent 来说至关重要。请问你们有没有计划进一步拓展和升级这个功能？尤其是在长上下文处理方面，你们有什么思路？

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

提问者 4：关于你们发布的 Composer 模型，我认识一些开发者，他们基于 Gemini 模型微调了一个医疗领域的专用模型。但他们发现，这个微调后的模型效果还不如直接用原生 Gemini 模型做单次提示词调用。他们分析的原因是，微调模型需要持续维护，要跟上 Gemini 等基础模型的更新节奏。请问你们是如何制定策略，确保 Composer 模型不会落伍的？

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

提问者 5：我自己是产品经理，一直在用 Cursor 做原型开发，甚至在团队里还客串设计师，用它替代 Figma。我很好奇，有没有用户是在使用 Cursor 之前，从未安装过任何集成开发环境（IDE）的？这类用户会不会成为你们未来重点关注的群体？毕竟现在的编码 Agent 已经足够强大，很多工作都能在上面完成。

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

提问者 6：我一直在尝试用 Cursor 做智能合约的验证矩阵构建和试运行逻辑测试。请问在深度质量检测和安全加固方面，有没有什么不太为人知的实用工作流可以推荐？或者刚才提到的调试工具能不能派上用场？我对智能合约的质量检测特别感兴趣。

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

提问者 7：您认为未来两到四个月，Cursor 面临的最大机遇是什么？会不会是语音 Agent？

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

参考链接：

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

整理 | 华卫、Tina

过去一年，编码 Agent 的变化速度，已经快到让人很难用“功能升级”来形容。

如果把时间拨回到一年前，Agent 还主要停留在代码补全、对话式改几行代码的阶段；而今天，在 Cursor 内部，工程师已经开始同时运行多个 Agent 并行“甩活儿”，让它们在代码库中自主修改、调试、复盘，再由人类在最后阶段集中审核结果。开发者不再盯着 Agent 的每一步操作，而是开始习惯“等它跑完再看答案”。

在最近一次访谈中，Cursor 工程负责人 Jason Ginsberg 给出了一个明确判断：这不是渐进式优化，而是一场正在发生的“换代”。更重要的是，他把这场变化的时间窗口，压缩到了未来三到六个月——在他看来，Agent 将不只是“更聪明”，而是会真正接管更长周期、更复杂的工程任务，整个行业的工作方式也将随之重塑。

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

一年多时间，编码 Agent“翻天覆地”

Harrison Chase：Jason，你能跟大家简单介绍一下自己吗？也给大家讲讲 Cursor 是什么吧。

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

Harrison Chase：非常棒。我有很多话题想和你探讨。要不我先抛砖引玉，问问你对编码 Agent 的发展历程，以及这些年来人机交互模式演变的看法吧。你们可以说是这个领域的先行者之一，我认为编码 Agent 的发展经历了几个阶段的转变：从最初的代码自动补全，到集成在集成开发环境（IDE）中的对话式交互，再到如今出现的各类终端工具，以及基于云端的异步 Agent。我很想听听你的看法，你觉得这样概括其用户体验的演变历程是否准确？或者你们团队是如何看待这一发展过程的？

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

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

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

Harrison Chase：推动这些变革的核心因素是什么？仅仅是因为大模型的性能变得越来越好，还是有其他更多的影响因素？

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

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

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

最顶尖工程师的干活秘诀：全靠 Agent？

Harrison Chase：你观察到大家使用 Cursor 的方式都有哪些不同？或者你自己平时是怎么使用 Cursor 的？

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

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

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

Harrison Chase：调试模式具体是什么样的？为什么需要专门设置这样一个模式？难道不能自动完成调试吗？直接给 Agent 下达调试指令不也可以吗？

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

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

Harrison Chase：Agent 具体会询问哪些问题，又需要用户提供什么样的反馈呢？

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

Harrison Chase：你觉得人类还需要手动操作多久？就不能让 Agent 自主完成点击、测试这类操作吗？

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

Harrison Chase：刚才你提到了 Agent 的多种不同模式，比如规划模式、解释模式、调试模式等等。这些模式在实际应用中到底意味着什么？难道只是为 Agent 设置不同的提示词这么简单吗？还是说背后有更复杂的逻辑？

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

Harrison Chase：回到之前的话题，关于大家使用 Cursor 的不同方式，你觉得未来使用编码 Agent 或者说 Cursor，存在所谓的 “最佳方式” 吗？

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

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

自然 “唠嗑”是 Cursor 最终交互模式？

Harrison Chase：如果让你预测一下一年后的情况，你认为开发者在 IDE、终端以及其他形态的载体上使用 Cursor 的时间占比会是怎样的？

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

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

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

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

Harrison Chase：未来会有更多场景都能用上像 Cursor 这样的工具。你们应该有对应的官网吧？用户可以直接在网页上进行交互操作，是这个思路吗？

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

Harrison Chase：我认为 Cursor 真正的优势，在于围绕 Agent 交互打造的整套设计和用户体验体系。你之前在 Notion 工作过，我记得即便是在生成式 AI 普及之前，Notion 的设计和用户体验就已经广受认可了。当然，他们在生成式 AI 时代也很好地完成了转型。从一家在生成式 AI 普及前就拥有出色设计积淀且顺利完成转型的公司，再到如今专注 Agent 相关工作，你觉得 Agent 的出现给产品设计和用户体验带来了哪些变化？现在的工作模式和之前有相似之处吗？

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

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

Harrison Chase：听你这么说，很多组件的底层逻辑其实是相通的。那有没有出现新的组件？或者某些组件的优先级发生了变化？毕竟这些组件最初都是为 “人类与软件交互”“人类通过软件协作” 的场景设计的，现在加入了 Agent 这个新角色。这其中有没有产生什么新的变化？还是说其实本质上没有太大不同？

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

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

Harrison Chase：你觉得交互的抽象层级最高能达到什么程度？我知道预测未来很难，但还是想听听你的看法。

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

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

Cursor 内部工作揭秘：少审代码、高频反馈

Harrison Chase：你之前提到了人类在 Agent 工作流程中的角色，比如查看代码差异、进行代码审查。你觉得 AI 会给代码审查工作带来哪些改变？

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

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

Harrison Chase：出于好奇，我想问一下，Cursor 的工程师用 Cursor 写代码，用 BugBot 审查代码，那他们还需要和其他工程师沟通协作吗？

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

Harrison Chase：从组织管理的角度，你们有没有采取什么措施来鼓励或者引导这种高频反馈的协作模式？毕竟大量的反馈涌进来，有时候也会让人应接不暇。

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

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

迭代狂飙背后，核心功能竟来自员工 “自嗨”？

Harrison Chase：你觉得你们的产品路线图，有多大比例是由 “让自己工作更轻松” 这个需求驱动的？又有多大比例是来自外部用户的需求？这个比例随着公司发展有变化吗？

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

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

Harrison Chase：你们的产品迭代速度快得惊人，是怎么保持这种高效的开发节奏的？

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

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

Harrison Chase：你们是如何规划产品路线图的？你刚才提到了以月为单位的规划周期，这是目前的常规规划时长吗？有没有更长期的规划？另外，行业技术迭代的速度实在太快了，你们是如何平衡 “跟进现有技术浪潮” 和 “实现技术跨越式发展” 这两者的？会不会主动预判技术趋势，提前布局未来方向？

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

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

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

Harrison Chase：说到模型，你们发布了自研的 Composer 模型。开发这个模型的初衷是什么？目前用户的使用情况如何？这个模型有没有改变大家使用 Cursor 的习惯？

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

Harrison Chase：Cursor 的 Agent 相关研发工作是全员参与，还是有专门的团队负责？

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

Harrison Chase：无论是 Agent 团队的成员，还是其他团队中擅长 Agent 研发的工程师，他们身上有没有什么共同特质？他们的专业背景或者个人能力有没有什么特别之处？

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

Harrison Chase：上周你们和 OpenAI 合作发布了一篇博客，内容是针对 OpenAI 的新模型优化 Cursor 的 Agent 调度框架。我在推特上经常看到大家讨论 “Agent 调度框架” 这个概念。你们是如何看待模型的底层支撑架构的？这类架构是否需要和特定模型深度绑定？比如 Composer 模型和 CodeLlama 模型，对应的架构会不会有很大差异？

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

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

开放问答

提问者 1：刚才提到了新增的可视化浏览器功能，我发现有些工具比如 Lovable 也有类似的功能。请问这个功能是朝着 “沉浸式可视化编码” 的方向发展吗？

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

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

提问者 2：我特别喜欢你们的浏览器 Agent，一直在用。但我发现一个小瑕疵：我想持续迭代优化设计方案，可 Agent 总是会中断我的工作，直接提交代码合并请求。未来有没有可能实现不间断的持续迭代？

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

提问者 3：我不知道你是否深度参与 Agent 相关的研发工作，但我注意到 Cursor 的内存管理功能做得很好。它可以根据工程师个人、部门乃至整个公司的偏好、规则和流程，自主管理相关信息。我们都知道，信息和上下文对 Agent 来说至关重要。请问你们有没有计划进一步拓展和升级这个功能？尤其是在长上下文处理方面，你们有什么思路？

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

提问者 4：关于你们发布的 Composer 模型，我认识一些开发者，他们基于 Gemini 模型微调了一个医疗领域的专用模型。但他们发现，这个微调后的模型效果还不如直接用原生 Gemini 模型做单次提示词调用。他们分析的原因是，微调模型需要持续维护，要跟上 Gemini 等基础模型的更新节奏。请问你们是如何制定策略，确保 Composer 模型不会落伍的？

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

提问者 5：我自己是产品经理，一直在用 Cursor 做原型开发，甚至在团队里还客串设计师，用它替代 Figma。我很好奇，有没有用户是在使用 Cursor 之前，从未安装过任何集成开发环境（IDE）的？这类用户会不会成为你们未来重点关注的群体？毕竟现在的编码 Agent 已经足够强大，很多工作都能在上面完成。

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

提问者 6：我一直在尝试用 Cursor 做智能合约的验证矩阵构建和试运行逻辑测试。请问在深度质量检测和安全加固方面，有没有什么不太为人知的实用工作流可以推荐？或者刚才提到的调试工具能不能派上用场？我对智能合约的质量检测特别感兴趣。

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

提问者 7：您认为未来两到四个月，Cursor 面临的最大机遇是什么？会不会是语音 Agent？

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

参考链接：

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

整理 | 华卫、Tina

过去一年，编码 Agent 的变化速度，已经快到让人很难用“功能升级”来形容。

如果把时间拨回到一年前，Agent 还主要停留在代码补全、对话式改几行代码的阶段；而今天，在 Cursor 内部，工程师已经开始同时运行多个 Agent 并行“甩活儿”，让它们在代码库中自主修改、调试、复盘，再由人类在最后阶段集中审核结果。开发者不再盯着 Agent 的每一步操作，而是开始习惯“等它跑完再看答案”。

在最近一次访谈中，Cursor 工程负责人 Jason Ginsberg 给出了一个明确判断：这不是渐进式优化，而是一场正在发生的“换代”。更重要的是，他把这场变化的时间窗口，压缩到了未来三到六个月——在他看来，Agent 将不只是“更聪明”，而是会真正接管更长周期、更复杂的工程任务，整个行业的工作方式也将随之重塑。

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

一年多时间，编码 Agent“翻天覆地”

Harrison Chase：Jason，你能跟大家简单介绍一下自己吗？也给大家讲讲 Cursor 是什么吧。

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

Harrison Chase：非常棒。我有很多话题想和你探讨。要不我先抛砖引玉，问问你对编码 Agent 的发展历程，以及这些年来人机交互模式演变的看法吧。你们可以说是这个领域的先行者之一，我认为编码 Agent 的发展经历了几个阶段的转变：从最初的代码自动补全，到集成在集成开发环境（IDE）中的对话式交互，再到如今出现的各类终端工具，以及基于云端的异步 Agent。我很想听听你的看法，你觉得这样概括其用户体验的演变历程是否准确？或者你们团队是如何看待这一发展过程的？

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

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

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

Harrison Chase：推动这些变革的核心因素是什么？仅仅是因为大模型的性能变得越来越好，还是有其他更多的影响因素？

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

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

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

最顶尖工程师的干活秘诀：全靠 Agent？

Harrison Chase：你观察到大家使用 Cursor 的方式都有哪些不同？或者你自己平时是怎么使用 Cursor 的？

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

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

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

Harrison Chase：调试模式具体是什么样的？为什么需要专门设置这样一个模式？难道不能自动完成调试吗？直接给 Agent 下达调试指令不也可以吗？

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

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

Harrison Chase：Agent 具体会询问哪些问题，又需要用户提供什么样的反馈呢？

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

Harrison Chase：你觉得人类还需要手动操作多久？就不能让 Agent 自主完成点击、测试这类操作吗？

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

Harrison Chase：刚才你提到了 Agent 的多种不同模式，比如规划模式、解释模式、调试模式等等。这些模式在实际应用中到底意味着什么？难道只是为 Agent 设置不同的提示词这么简单吗？还是说背后有更复杂的逻辑？

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

Harrison Chase：回到之前的话题，关于大家使用 Cursor 的不同方式，你觉得未来使用编码 Agent 或者说 Cursor，存在所谓的 “最佳方式” 吗？

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

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

自然 “唠嗑”是 Cursor 最终交互模式？

Harrison Chase：如果让你预测一下一年后的情况，你认为开发者在 IDE、终端以及其他形态的载体上使用 Cursor 的时间占比会是怎样的？

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

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

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

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

Harrison Chase：未来会有更多场景都能用上像 Cursor 这样的工具。你们应该有对应的官网吧？用户可以直接在网页上进行交互操作，是这个思路吗？

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

Harrison Chase：我认为 Cursor 真正的优势，在于围绕 Agent 交互打造的整套设计和用户体验体系。你之前在 Notion 工作过，我记得即便是在生成式 AI 普及之前，Notion 的设计和用户体验就已经广受认可了。当然，他们在生成式 AI 时代也很好地完成了转型。从一家在生成式 AI 普及前就拥有出色设计积淀且顺利完成转型的公司，再到如今专注 Agent 相关工作，你觉得 Agent 的出现给产品设计和用户体验带来了哪些变化？现在的工作模式和之前有相似之处吗？

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

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

Harrison Chase：听你这么说，很多组件的底层逻辑其实是相通的。那有没有出现新的组件？或者某些组件的优先级发生了变化？毕竟这些组件最初都是为 “人类与软件交互”“人类通过软件协作” 的场景设计的，现在加入了 Agent 这个新角色。这其中有没有产生什么新的变化？还是说其实本质上没有太大不同？

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

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

Harrison Chase：你觉得交互的抽象层级最高能达到什么程度？我知道预测未来很难，但还是想听听你的看法。

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

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

Cursor 内部工作揭秘：少审代码、高频反馈

Harrison Chase：你之前提到了人类在 Agent 工作流程中的角色，比如查看代码差异、进行代码审查。你觉得 AI 会给代码审查工作带来哪些改变？

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

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

Harrison Chase：出于好奇，我想问一下，Cursor 的工程师用 Cursor 写代码，用 BugBot 审查代码，那他们还需要和其他工程师沟通协作吗？

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

Harrison Chase：从组织管理的角度，你们有没有采取什么措施来鼓励或者引导这种高频反馈的协作模式？毕竟大量的反馈涌进来，有时候也会让人应接不暇。

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

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

迭代狂飙背后，核心功能竟来自员工 “自嗨”？

Harrison Chase：你觉得你们的产品路线图，有多大比例是由 “让自己工作更轻松” 这个需求驱动的？又有多大比例是来自外部用户的需求？这个比例随着公司发展有变化吗？

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

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

Harrison Chase：你们的产品迭代速度快得惊人，是怎么保持这种高效的开发节奏的？

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

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

Harrison Chase：你们是如何规划产品路线图的？你刚才提到了以月为单位的规划周期，这是目前的常规规划时长吗？有没有更长期的规划？另外，行业技术迭代的速度实在太快了，你们是如何平衡 “跟进现有技术浪潮” 和 “实现技术跨越式发展” 这两者的？会不会主动预判技术趋势，提前布局未来方向？

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

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

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

Harrison Chase：说到模型，你们发布了自研的 Composer 模型。开发这个模型的初衷是什么？目前用户的使用情况如何？这个模型有没有改变大家使用 Cursor 的习惯？

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

Harrison Chase：Cursor 的 Agent 相关研发工作是全员参与，还是有专门的团队负责？

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

Harrison Chase：无论是 Agent 团队的成员，还是其他团队中擅长 Agent 研发的工程师，他们身上有没有什么共同特质？他们的专业背景或者个人能力有没有什么特别之处？

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

Harrison Chase：上周你们和 OpenAI 合作发布了一篇博客，内容是针对 OpenAI 的新模型优化 Cursor 的 Agent 调度框架。我在推特上经常看到大家讨论 “Agent 调度框架” 这个概念。你们是如何看待模型的底层支撑架构的？这类架构是否需要和特定模型深度绑定？比如 Composer 模型和 CodeLlama 模型，对应的架构会不会有很大差异？

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

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

开放问答

提问者 1：刚才提到了新增的可视化浏览器功能，我发现有些工具比如 Lovable 也有类似的功能。请问这个功能是朝着 “沉浸式可视化编码” 的方向发展吗？

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

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

提问者 2：我特别喜欢你们的浏览器 Agent，一直在用。但我发现一个小瑕疵：我想持续迭代优化设计方案，可 Agent 总是会中断我的工作，直接提交代码合并请求。未来有没有可能实现不间断的持续迭代？

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

提问者 3：我不知道你是否深度参与 Agent 相关的研发工作，但我注意到 Cursor 的内存管理功能做得很好。它可以根据工程师个人、部门乃至整个公司的偏好、规则和流程，自主管理相关信息。我们都知道，信息和上下文对 Agent 来说至关重要。请问你们有没有计划进一步拓展和升级这个功能？尤其是在长上下文处理方面，你们有什么思路？

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

提问者 4：关于你们发布的 Composer 模型，我认识一些开发者，他们基于 Gemini 模型微调了一个医疗领域的专用模型。但他们发现，这个微调后的模型效果还不如直接用原生 Gemini 模型做单次提示词调用。他们分析的原因是，微调模型需要持续维护，要跟上 Gemini 等基础模型的更新节奏。请问你们是如何制定策略，确保 Composer 模型不会落伍的？

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

提问者 5：我自己是产品经理，一直在用 Cursor 做原型开发，甚至在团队里还客串设计师，用它替代 Figma。我很好奇，有没有用户是在使用 Cursor 之前，从未安装过任何集成开发环境（IDE）的？这类用户会不会成为你们未来重点关注的群体？毕竟现在的编码 Agent 已经足够强大，很多工作都能在上面完成。

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

提问者 6：我一直在尝试用 Cursor 做智能合约的验证矩阵构建和试运行逻辑测试。请问在深度质量检测和安全加固方面，有没有什么不太为人知的实用工作流可以推荐？或者刚才提到的调试工具能不能派上用场？我对智能合约的质量检测特别感兴趣。

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

提问者 7：您认为未来两到四个月，Cursor 面临的最大机遇是什么？会不会是语音 Agent？

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

参考链接：

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

前端生态最具影响力的开源项目之一 Tailwind CSS，正经历一场罕见的生存压力测试。

其创始人 Adam Wathan 近日在社区公开表示，由于 AI 对业务模式造成的“残酷冲击”，Tailwind 在一天之内裁掉了工程团队约 75% 的员工。

他在 1 月 7 日一期自述播客中进一步解释：在 AI 编程工具大规模采用 Tailwind、使用量持续走高的同时，这种“被默认使用”的成功并未转化为可持续的商业回报，反而持续侵蚀了团队的生存空间。若趋势不变，大约 6 个月后将无法继续支付工资。Adam 形容这是一种“非常糟糕的认知”，迫使他们必须立刻缩编，避免走到“既撑不住工资、也拿不出体面遣散”的境地。

“我真的难受。胃都拧在一起了。”Adam 说。

“因为这件事，我感觉自己像个失败者：我做出了一个几乎‘统治世界’的开源 CSS 框架，用的人越来越多、越来越火，但商业上的成功，却和开源的成功呈现出一种反向关系。”

“我们只剩下六个月了。”

“我现在的每一秒，都必须用来让公司活下去”

这场裁员风波最终被外界注意到，触发点是一则围绕“大模型（LLM）文档支持”的 GitHub Pull Request。

2025 年 11 月，社区开发者向 Tailwind 官方仓库提交了一项合并请求，要求新增一个 llms.txt 端点，用于提供面向 LLM 优化的 Tailwind CSS 全部文档的纯文本合并版本。以此希望在所有文档页面加一个“复制为 Markdown”的按钮，因为现在很多人会把文档内容直接喂给 AI。

从描述来看，这个 PR 是将 Tailwind 所有官方文档（共 185 个文件）在构建阶段静态合并为一个纯文本、无 JSX、按章节顺序排列的文档文件，方便 LLM 直接读取和使用。从工程实现上看，这只是一个构建期脚本，改动规模有限。

但该 PR 提交后长期未获推进。面对社区的追问，Tailwind 创始人 Adam Wathan 回应称，当前团队有更重要的事情要做，比如先想清楚怎么让公司赚到足够的钱、把业务维持下去。他直言，如果越来越多的人不再访问文档，而是直接依赖 LLM 去爬 Markdown 文件，“只会导致文档访问量进一步下降，也就意味着更少的人会了解到我们的付费产品，最终让业务变得更加不可持续。”

“很抱歉，我现在没有时间去做那些不能帮我们付账单的事情。”

Adam 关闭了这个 PR。当然，评论区立刻炸了：这对社区太糟糕了，你们只想着赚钱，太失望了......

有社区开发者认为，让软件更容易融入用户工作流、解决他们日常互动中的痛点，本身就是扩大潜在付费用户的关键前提；而此功能旨在让人们能够使用 Tailwind 更快、更高效地构建更多内容，现在 Adam 以“变现”为由拒绝此类功能，“等于是在告诉你的客户，从他们那里赚钱比为他们提供服务更重要。”

争议升级后，Adam 不得不再次回应，并披露了 Tailwind 的真实处境。

他坦言他知道这个功能的价值，但现实情况是：“就在昨天，我们工程团队里有 75% 的人失去了工作，这是 AI 对我们造成的残酷冲击。”

在这样的背景下，他坦率地说，自己已经很难再把时间投入到这类“不直接带来收入”的事情上：“我现在的每一秒，都必须用来让公司活下去。确保还留在这里的人，每个月都能拿到工资。”

他同时透露，尽管 Tailwind “比以往任何时候都更受欢迎”，但 “我们的文档流量相比 2023 年初已经下滑了大约 40%。”而文档是他们的唯一分发渠道，没有客户，就意味着 “我们根本负担不起继续维护这个框架。”

更残酷的是，虽然 Tailwind “增长速度比历史上任何时候都更快，规模也比任何时候都更大”，但 “收入却下滑了接近 80%。”他总结说，眼下 “让 Tailwind 变得更好用”，与 “让这个框架的开发在商业上变得可持续” 之间，“几乎已经看不到任何相关性。”

所以，他必须先解决生存问题，不然“一旦没人继续维护，这个项目最终会变成无人问津的弃置软件。”

更反直觉的现实：Tailwind 反而“到处都在被用”

这件事迅速在 Hacker News 上爆了。

HN 首页一条帖子标题很直接：“Tailwind 的创作者裁掉了 75% 的工程团队”，链接指向 TailwindLabs 的 GitHub 讨论。发出约 10 小时后，评论也堆到 598 条，迅速变成当天的高热讨论。

这场裁员之所以在社区引发震动，很大程度上来自一种强烈的反差感。

2020 年 7 月，Adam Wathan 还在公开回顾 Tailwind 的“上升期叙事”：Tailwind 的累计安装量刚刚突破 1000 万，而他们的首个商业化产品 Tailwind UI 上线仅约 5 个月，收入就即将跨过 200 万美元。他把这段经历形容为“完全超出想象”，并特意把最初发布在 Twitter 的长帖重新整理成文章。

而且在 AI 的世界里，在大多数开发者的体感里，Tailwind 也不是处在衰退期，恰恰相反，它正在悄然变成一种 AI 生成 UI 的“默认选项”。当人们打开 AI 编程工具，让模型生成一个页面、一个组件，甚至一整套 UI 时，模型往往不会再询问“要不要写 CSS”，而是直接给出一串熟悉的 class——这种选择并非出于偏好，而是因为在当下的工程环境里，这样做最快、最稳，也最不容易出错。

Glide CEO 兼创始人 David Siegel 认为：“你可以把 Tailwind 看成是一套无代码（no-code）工具包，它实际上让 AI 在设计这件事上变得更强了。”

有意思的是，AI 在使用 Tailwind 这件事上，确实表现得异常出色。就像无代码平台通过预制组件，帮助非开发者也能构建稳定、设计良好的应用一样，AI 也开始把 Tailwind 当作一套“组件库”来使用——这让它能够更快工作，并生成更可靠、更一致的样式结果。

“AI 并不是在 CSS 这种底层样式语言上变得更强了，”Siegel 解释道，“而是我们发明了一种 AI 更擅长使用的‘高层语言’，它叫 Tailwind。”他进一步指出：“它看起来几乎就像自然语言。你不用写一堆括号、冒号之类的东西，只需要写 text-black，文本就变成黑色；写 rounded-md，按钮就会变成中等圆角。这些组件库，本质上就是建立在设计之上的低代码 / 无代码抽象。”

现代 AI 编程助手最擅长的，往往是遵循清晰、可重复的模式，或者在一个定义良好的词汇体系中进行组合与生成。而 Tailwind 的方法论恰好满足了这一点：它提供了一套高度一致的 class 命名和样式模式，使 AI 更容易生成正确、相关且稳定的代码建议。

正如Vercel CEO Guillermo Rauch所说：“整个 Web 生态正在向 Tailwind 标准化，所以每个 AI 工具都在用它。”

“我们只剩下六个月了”

在 Adam Wathan 看来，AI 一把极其锋利的双刃剑。

“我认为，AI 是我们业务陷入困境的重要原因之一——即便它也让 Tailwind 变得比以往任何时候都更受欢迎。但同时，我也觉得 AI 是一项了不起的技术，我对它感到兴奋，也在思考它如何帮助我、帮助我们。在目前这个阶段，我们可能被迫要更认真地思考，如何利用 AI 来覆盖我们需要处理的所有事情。”

在 1 月 7 日发布的音频中，Adam 反复提到一个他此前一直试图回避、却最终不得不正视的事实：公司的收入已经连续多年处在下滑通道，而且还在继续下滑。

过去几年，这种下滑并不剧烈，甚至“慢到让人几乎察觉不到”。每个月的收入只是比上个月少一点点，账单依然能付，团队还能维持运转，久而久之，这种“更低但还能接受的收入水平”就变成了新的常态。

Adam 形容，这是一种典型的“温水煮青蛙”状态。

真正的转折点，发生在最近的假期里。他第一次不再凭感觉判断，而是认真做了一次收入预测：拉数据、画曲线、计算每个月的平均下降额。结论比他预期得要糟糕得多：收入并没有触底企稳，而是以几乎固定的绝对值持续下滑——这意味着，从比例上看，下滑速度只会越来越快。如果假设什么都不改变，那么大约6 个月之后，公司就将无法继续支付工资。

对一家小型团队来说，6 个月并不算长。如果继续拖下去，等到现金流真正断裂，团队不仅保不住，甚至连体面的遣散都无法提供。相比之下，现在主动缩编，至少还能给被裁的同事留出缓冲期，让他们有时间寻找下一份工作。

于是，在本周一，Tailwind Labs 正式裁掉了工程团队的 75%。

公司规模并不大，“75%”对应的其实是3 个人。但 Adam 特意强调比例的意义：如果只说“裁了 3 个人”，听起来像是小幅调整；而现实是，工程团队原本只有 4 名工程师，如今只剩1 人。这对团队而言是一次结构性的变化。

裁员之后，Tailwind 的资源配置也被压缩到了极限：

现在的团队结构是这样的：剩下的核心成员是三位公司合伙人——我自己、因 Refactoring UI 而为人熟知的 Steve（一直负责设计），以及 Jonathan Rennick（最早和我一起创建 Tailwind，也做了 Inertia.js）。

 

除此之外，我们只有一名全职工程师 Robin——他从零开始做了 Headless UI，也从零做了 Tailwind 3 和 Tailwind 4，是在公司待得最久的人。

 

还有 Peter，他更多是兼职，负责合作伙伴计划、一些运营事务和客户支持。

 

就这些人了。

换句话说，整个公司只剩下“3 位合伙人 + 2 名员工”，“这就是我们接下来全部的资源”。

接下来，Adam 也将重新回到更偏 IC（个人贡献者）的角色。他承认这算是某种“银边”：随着团队变大，他的工作越来越偏高层和战略层，关注哪些事情需要完成，并分配给合适的人，而不是亲自构建；而现在，团队规模逼迫他必须亲自下场。

被裁的三位工程师，都是他非常欣赏、也非常享受共事的人：Philip既能啃 Tailwind 核心，也能把 Tailwind Plus 的 elements 组件库和组件预览的复杂前端界面硬生生推进落地；Jordan是团队的“疑难杂症终结者”，最擅长扎进陌生代码库定位上游/兼容性问题、快速开 PR 修复，同时也能在 Headless UI 与服务器排障上扛住关键战役；Dan则以设计工程师身份主导 Tailwind 4 的视觉与品牌更新，设计 P3 色彩体系并自研选色与预览工具，还贡献了大量高质量的图解与课程平台素材。

他原本对未来和他们一起继续做新东西充满期待，脑子里有很多计划，很多想一起推进的方向。但现实摆在面前，只剩下两个选择：要么让他们在这里“免费工作”，要么放他们离开，去一个真的能每个月按时发工资的地方。

他选择了后者。“我真的很难受，”Adam 说，“胃都拧在一起了。”

而且他也意识到，外界并不总能理解裁员背后的现实逻辑。在社交平台上，总有人会把裁员简单归因为贪婪、冷血，或者“不在乎社区”。作为创始人，这几乎是一种默认要承受的角色负担——你很容易被塑造成反派。

“不是因为我贪婪、想赚更多钱，而是因为收入正在逼近零点，而我刚刚裁掉了我这辈子见过最优秀的三位工程师之一。我不想事情变得更糟。”

“说实话，我甚至把 tailwindcss.com 的仓库暂时设成了私有，只是不想再面对 issues 和 PR。睡了一觉之后，我可能会撤回这个决定。但我会反复动摇，本身就说明我这周的情绪状态真的不太对。”

“现在，开源项目越受欢迎，生意反而越艰难。这真的很残酷。这就是现状。”

参考链接：

https://news.ycombinator.com/item?id=46527950

https://github.com/tailwindlabs/tailwindcss.com/pull/2388#issuecomment-3717222957

https://adams-morning-walk.transistor.fm/episodes/we-had-six-months-left