核心内容摘要
Skill 模型全景解析
过去一年编码 Agent 的变化速度已经快到让人很难用“功能升级”来形容。
如果把时间拨回到一年前Agent 还主要停留在代码补全、对话式改几行代码的阶段而今天在 Cursor 内部工程师已经开始同时运行多个 Agent 并行“甩活儿”让它们在代码库中自主修改、调试、复盘再由人类在最后阶段集中审核结果。
开发者不再盯着 Agent 的每一步操作而是开始习惯“等它跑完再看答案”。
在最近一次访谈中Cursor 工程负责人 Jason Ginsberg 给出了一个明确判断这不是渐进式优化而是一场正在发生的“换代”。
更重要的是他把这场变化的时间窗口压缩到了未来三到六个月——在他看来Agent 将不只是“更聪明”而是会真正接管更长周期、更复杂的工程任务整个行业的工作方式也将随之重塑。
下面是详细对话内容我们在不改变原意的基础上进行了翻译和删减以飨读者。
1 一年多时间编码 Agent“翻天覆地”Harrison ChaseJason你能跟大家简单介绍一下自己吗也给大家讲讲 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 辅助编程作为默认的工作方式。
2 最顶尖工程师的干活秘诀全靠 AgentHarrison Chase你观察到大家使用 Cursor 的方式都有哪些不同或者你自己平时是怎么使用 Cursor 的Jason Ginsberg其实在我们公司内部工程师们使用 Cursor 的方式就五花八门。
甚至团队里有几位工程师他们完全不使用 Cursor 的 Agent 功能比如负责安全和基础设施的同事。
所以确实有一部分用户非常依赖代码自动补全功能日常使用中大部分操作都是基于补全功能完成的。
但令人意外的是我发现团队里一些最顶尖的工程师我们称他们为 “核心用户”他们做任何工作都会完全依赖 Agent甚至会同时运行多个 Agent 并行处理任务。
至于我个人的使用习惯我并不会去设计那些复杂繁琐的提示词也没有什么所谓的 “Agent 使用秘籍”。
我写的提示词往往都很简短甚至还会带有拼写错误。
我会针对手头不同的工作任务或者同一个问题的不同模块同时启动多个 Agent然后等待它们返回结果。
目前我用得最多的是我们今天刚刚发布的一个新功能调试模式。
这个模式下Agent 能够通过生成日志来进行自我评估之后开发者复现相关操作步骤Agent 就会通过查看日志判断问题是否得到解决。
这个功能非常实用因为它相当于通过投入算力去不断尝试解决问题最终攻克那些手动排查起来极为棘手的难题。
Harrison Chase调试模式具体是什么样的为什么需要专门设置这样一个模式难道不能自动完成调试吗直接给 Agent 下达调试指令不也可以吗Jason Ginsberg其实我也认同你的这个想法。
所以在开发调试模式的时候我们内部确实有过不少争论。
主要原因在于Cursor 目前已经有很多功能模式了如规划模式、询问模式等等这些模式其实不太容易被用户发现。
我们一直认为这些模式都很实用理想的状态应该是Agent 能够根据用户的操作场景自动匹配并启用最合适的模式无需用户手动切换。
而现阶段调试模式之所以需要手动开启是因为它的交互方式比较特殊。
在运行过程中Agent 会暂停当前的工作向用户提问以获取反馈。
如果用户不熟悉这种交互逻辑可能会觉得比较困扰。
Harrison ChaseAgent 具体会询问哪些问题又需要用户提供什么样的反馈呢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。
通常这种方式的效率是最高的。
3 自然 “唠嗑”是 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
0 的时候并没有把原来的产品推倒重来只是把各个功能模块重新组合调整为侧边栏收件箱式的管理布局同时优化了聊天界面的信息密度而已。
Harrison Chase听你这么说很多组件的底层逻辑其实是相通的。
那有没有出现新的组件或者某些组件的优先级发生了变化毕竟这些组件最初都是为 “人类与软件交互”“人类通过软件协作” 的场景设计的现在加入了 Agent 这个新角色。
这其中有没有产生什么新的变化还是说其实本质上没有太大不同Jason Ginsberg我认为底层的设计逻辑和核心要素其实没有变关键变化在于谁在主导界面交互。
而在这个核心框架下其实可以演变出无数种交互形式。
就拿交互的抽象层级来说一年前大家使用Agent的时候都恨不得盯着它的每一步操作全程 “盯梢”。
但现在 Agent 的操作步骤变得无比繁杂用户根本看不过来。
所以我们需要优化信息呈现方式如何对操作步骤进行分组如何提炼关键信息当用户足够信任 Agent 的操作后我们就需要把重点放在文件的实际修改内容上并且为这些修改添加更详细的注释说明。
当然我们也可以进一步提升交互的灵活度比如聊天对象不再局限于单个 Agent而是可以同时和多个 Agent 对话。
这就需要一套更智能的后台交互逻辑来支撑 系统要能识别用户在和哪个子 Agent 对话并且协调这些 Agent 完成对应的修改。
未来这种交互的抽象层级还会不断提升。
Harrison Chase你觉得交互的抽象层级最高能达到什么程度我知道预测未来很难但还是想听听你的看法。
Jason Ginsberg我觉得未来我们现在看到的各种操作选项如选择模型、选择功能模式、选择运行环境这些都会逐渐消失。
最终的交互模式会变得像和真人对话一样自然。
但这并不意味着任何人都能随便写代码在那个阶段这个工具依然是为专业工程师服务的。
因为你还是需要具备专业的行业术语知识清楚自己想要修改的内容是什么。
做产品的人要明确自己想要的工作流程和功能需求做基础设施的人要足够了解代码库知道什么样的架构和系统设计最适合当前要开发的项目。
而且我想强调的是随着抽象层级的提升我们并不会摒弃现有的功能。
用户依然可以随时深入底层查看细节、调整参数。
只是产品的默认交互方式会不断优化升级。
4 Cursor 内部工作揭秘少审代码、高频反馈Harrison Chase你之前提到了人类在 Agent 工作流程中的角色比如查看代码差异、进行代码审查。
你觉得 AI 会给代码审查工作带来哪些改变Jason Ginsberg首先就我们产品团队的工作模式来说现在人工审查的比重已经大幅降低了。
我们有一个叫 BugBot 的工具它会自动检测代码问题并且自主完成修复还会在持续集成CI流程中不断迭代优化。
这个工具的表现非常出色也让我们对 AI 审查的代码质量更有信心。
其次是信息的语义化分组。
用户查看代码差异时可以清晰地看到 Agent 做了哪些修改。
我们甚至可以展示 Agent 的原始指令更理想的状态是Agent 能够像人类一样在处理大型代码合并请求时为每一处修改附上注释说明这么做的原因。
我觉得这虽然算不上颠覆性的变革但确实能给代码审查工作带来显著的优化。
Harrison Chase出于好奇我想问一下Cursor 的工程师用 Cursor 写代码用 BugBot 审查代码那他们还需要和其他工程师沟通协作吗Jason Ginsberg哈哈这个问题很有意思。
如果你以工程师的身份加入 Cursor会立刻发现一个现象所有人都在深度使用自家产品。
我记得我入职第一周的时候修改了一个快捷键设置。
那个快捷键是 AltShiftCommandJ非常冷门我当时觉得选这个键肯定没人会注意到。
结果刚改完不到半分钟就有三个同事在 Slack 上发来消息“你改的这个快捷键直接打乱了我的工作流程到底怎么回事”几乎任何产品改动都会立刻收到同事们的强烈反馈。
我觉得这其实是一件好事大家就是在这种高频的反馈和交流中快速推进产品迭代的。
Harrison Chase从组织管理的角度你们有没有采取什么措施来鼓励或者引导这种高频反馈的协作模式毕竟大量的反馈涌进来有时候也会让人应接不暇。
Jason Ginsberg在我创办自己的公司之前工程师们也会用邮件沟通但用得并不多。
大家甚至会说“邮件只用来收垃圾邮件和购物通知可别用它来发长篇大论的工作内容。
”而在Agent这个赛道工作其实完全不需要依赖邮件这种低效的沟通方式。
我们团队的所有人都全身心投入工作毕竟这是一个竞争非常激烈的领域大家都对产品开发充满热情会自然而然地用各种即时沟通工具协作。
另外我在规划产品功能时会遵循一个核心原则我能开发什么功能让自己的日常工作更轻松 具体来说就是思考 “做什么能帮我明天更高效地完成工作不用再处理那些烦人的报错和问题”。
这个原则指导着我们的大部分工作。
毕竟这种功能开发出来之后我们自己能立刻受益比如修复了一个烦人的漏洞以后上班就不用再被这个问题困扰了。
5 迭代狂飙背后核心功能竟来自员工 “自嗨”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 ChaseCursor 的 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很有道理。
毕竟整个行业都在飞速变化。
6 开放问答提问者 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 面临的最大机遇是什么会不会是语音 AgentJason Ginsberg我觉得机遇不在于语音 Agent。
用户现阶段最核心的需求其实是让 Agent 变得更智能、运行时间更长、能处理的任务更多。
现在的很多 Agent本质上只是在 “读取代码”并不能真正判断修改后的代码是否有效。
未来的发展空间非常大我们可以投入更多算力让 Agent 承担更多人类目前负责的校验工作。
我觉得未来三到六个月整个行业都会迎来巨大的变革非常值得期待。
学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】