Cursor如何利用Claude构建AI编码的未来「油管Rosetta」
内容介绍
本次访谈邀请了AI编程工具Cursor的核心团队成员Jacob Jackson、Lukas Möller和Aman Sanger,与Anthropic的Alex Albert共同探讨软件开发的变革前景,特别是AI在其中的作用。对话围绕Cursor在过去一年中取得的显著增长展开,深入剖析了语言模型的进步(如Anthropic的Claude系列模型)如何推动了Cursor从最初的Tab自动补全发展到支持复杂的多文件编辑,并催生了如“后台代理”(Background Agent)这样的创新功能。
访谈中,Cursor团队分享了他们“用Cursor构建Cursor”的独特开发模式,以及这种自我迭代如何加速产品优化。同时,双方就AI辅助编程面临的挑战进行了坦诚交流,包括大型生产代码库的上下文理解、软件验证的未来瓶颈,以及如何平衡自动化与工程师核心技能的培养。此外,对话还展望了代码本身可能的演化方向、Anthropic在模型开发上的理念,以及未来软件工程师角色的转变。
对于希望了解AI如何重塑软件开发流程、AI编程工具的最新进展,以及顶尖AI公司如何思考行业未来的读者,这份访谈实录提供了来自实践者和模型开发者的一手见解与前瞻思考。
内容纲要
├── 引言
│ ├── 访谈嘉宾与主题介绍 (Anthropic的Alex Albert主持,Cursor的Jacob Jackson, Lukas Möller, Aman Sanger参与)
│ └── AI将改变软件生产的各个方面
├── Cursor的增长与演变
│ ├── 过去一年的快速增长与营收 ($3亿美元)
│ ├── 语言模型进步与Cursor功能拓展 (如3.5 Sonnet推动多文件编辑)
│ └── 从早期功能 (Tab补全) 到多文件编辑的演进
├── 模型的进步与Cursor的迭代
│ ├── 模型质量的渐进式提升与阶梯式进步
│ ├── 实验与调整在模型应用中的重要性
│ └── Sonnet模型与多文件交互、工具使用的实现
├── 用Cursor构建Cursor:自我迭代与优势
│ ├── 团队日常使用Cursor进行开发的实践
│ │ ├── 不同场景下的功能应用 (Agent, 思考模型, Tab补全, QA功能)
│ │ └── Claude 3.5/3.7在代码库研究中的作用
│ ├── 解决自身问题驱动产品迭代的理念
│ └── 作为自身最佳客户的优势 (快速迭代、功能验证)
├── 功能谱系:从辅助到自主
│ ├── 不同开发者与工作场景下的AI使用差异
│ └── 从Tab补全到Command K、Agent及后台代理的功能谱系
├── 后台代理 (Background Agent) 的理念与实现
│ ├── 背景:模型能力增强但未达100%,提升开发者并行效率
│ ├── 核心理念:后台与前台任务的快速切换与控制
│ ├── 未来展望:作为新基础能力的多场景应用
│ └── 实现机制:独立的、预装工具的虚拟机环境
├── 未来的瓶颈:软件验证
│ ├── AI生成代码能力增强带来的验证挑战
│ ├── 验证对软件工程效率提升的重要性
│ └── 潜在解决方案:代码的不同表示形式 (如伪代码)
├── 大型生产代码库的挑战与解决方案探索
│ ├── 大型代码库中运行测试与依赖管理的复杂性
│ ├── 后台代理在大型代码库中的应用与环境配置
│ ├── 检索模型、上下文集成应对代码理解难题
│ ├── “正确方式”编码的挑战 (符合代码风格、规范)
│ └── 组织知识与业务需求对编码的影响
├── 代码的演变:为AI和人类优化
│ ├── API设计与代码结构为适应LLM而调整的趋势
│ └── 整洁代码原则对人与模型的重要性统一,品味将更重要
├── 自动化浪潮下工程技能与代码质量的维系
│ ├── AI工具的教育价值与学习辅助作用
│ ├── AI对代码质量的双重影响与整体水平提升
│ └── 未来工程师技能的可能演变 (细节掌握 vs 高层抽象与UX品味)
├── Claude新模型 (Opus 4, Sonnet 4) 的特点与集成展望
│ ├── Cursor团队对Sonnet 4的积极评价 (修复缺陷、智能提升)
│ ├── 对Opus 4作为后台代理的期待
│ └── Anthropic在Sonnet 3.5开发上的努力与成果
├── Anthropic的模型开发理念与未来展望
│ ├── 编码作为核心领域及其能力迁移性
│ ├── 推动模型能力边界,兼顾安全与对齐
│ ├── 模型“性格”塑造的重要性
│ └── 个人观点:AI赋能而非取代开发者
├── 未来图景:AI在软件开发中的普及与变革
│ ├── 2027年AI生成代码占比预测 (接近100%参与度)
│ ├── 开发者角色将更侧重理解需求与品味
│ ├── 非软件背景人士构建自定义工具的趋势
│ └── “按需软件”与个性化软件体验的畅想
└── 给工程师的建议:选择与机遇
└── 创业公司在人才吸引与影响力方面的优势
对话实录
访谈嘉宾:
- Cursor核心团队成员:Jacob Jackson、Lukas Möller、Aman Sanger。
- Anthropic代表:Alex Albert。
引言
Aman (Cursor): 我认为软件生产的每一个方面都将以某种方式使用AI进行改变。
Alex(Anthropic): 非常高兴今天能邀请到你们。我期待这次对话已经有一段时间了。如你们所知,我是Alex,在Anthropic负责Claude开发者关系。
Lukas(Cursor): 我是Lukas,在Cursor从事代理系统(agentic systems)方面的工作。
Aman (Cursor): 我是Aman,Cursor的创始人之一,负责机器学习和检索方面的工作。
Jacob(Cursor): 我叫Jacob Jackson,在Cursor从事机器学习方面的工作。
Alex(Anthropic): 我非常非常期待这次对话,希望能和你们聊聊Cursor,你们正在构建什么,以及你们是如何使用Claude的。对于Cursor来说,这是重要的一年,对于任何关注AI行业的人来说都显而易见。
Cursor的增长与演变
Alex(Anthropic): 你们在短短一年多的时间里,规模扩大到年收入超过$3亿美元(原文为: over $300 million revenue),现在有数百万开发者在使用Cursor。这太疯狂了。在你们看来,发生了哪些变化?今天的Cursor版本与一年前相比有何不同?
Aman (Cursor): 是的,我认为有几件大事发生了改变。我的意思是,鉴于当前语言模型的水平,利用它们能做的事情一直存在巨大的潜力空间,而我认为Cursor可能是编码领域首批能够通过一系列不同功能稍微缩小这一差距的公司之一。然后,反过来,你也看到这些模型在编码方面变得越来越好,我认为 Sonnet是这方面的第一个明显例子,或者说是在编程能力上的这种阶梯式进步。因此,在此之前,Cursor在诸如Tab自动补全(预测你的下一次编辑)这类事情上非常有用。单凭这一点,Cursor的增长就相当快,还有在单个文件内的编辑。但我们确实看到,当你将像 Sonnet这样模型的智能与我们用于检索的一些其他定制模型,以及应用这个更大模型所做的编辑结合起来时,你就具备了进行多文件编辑的能力。我认为那是导致Cursor被大规模采用的阶梯式进步,从那以后,一方面是模型变得越来越好,另一方面是我们试图在底层做得越来越好,比如我们能将这些模型推向多远。
模型的进步与Cursor的迭代
Alex(Anthropic): 那是一个自然的演进,是自然而然发生的,还是你们在 Sonnet那个首个版本出来时注意到,哇,现在我们突然可以做所有这些以前不可能做到的事情了?那具体是怎样的情景呢?
Aman (Cursor): 感觉上是有些渐进的。模型质量确实存在这些阶梯式的进步,但你在之前的顶尖模型中也能看到一些端倪。事实上,我们在品鉴这些模型方面向来表现不佳,因为你知道,我们使用它们的方式与你将它们推向世界,看其他人如何使用它们是非常不同的。但随着时间的推移,每一个新模型的出现都在推理能力、执行更多代理式编码任务方面变得越来越好,这其中有很多的修补和尝试,看什么有效,什么失败。是的,我想Sonnet可能是第一个我们能够让多文件交互真正良好工作的模型。从那以后,出现了一系列阶梯式的进步,包括工具使用,对吧?然后你就可以让这些模型在编辑器中像真正的代理一样行动。
Alex(Anthropic): 嗯,我明白了。所以新模型的进步,新能力的出现,随着时间的推移,允许了进一步的修补和探索,这在某种程度上又反馈到你们的产品中,让你们能够构建新的功能。
Aman (Cursor): 是的。
Alex(Anthropic): 这很有趣,也引出了我想谈的下一个问题。
用Cursor构建Cursor:自我迭代与优势
Alex(Anthropic): 我听说过很多关于你们团队如何使用Cursor来构建Cursor的故事,这就像一个自我改进的递归反馈循环。首先,也许你可以深入谈谈这具体是怎样的?在日常工作中,当你们致力于构建新功能时,Cursor内部的使用情况是怎样的?
Lukas(Cursor): 是的,我认为这在很大程度上取决于每个员工的个人使用场景,而且我认为这也很大程度上取决于你可能正在从事的产品哪个部分,以及那个部分处于哪个阶段。所以,我认为对于最初搭建一些代码库、一些新功能来说,使用Agent功能来启动是非常非常有用的,然后可能会使用思考模型来查看你可能面临的个别错误,而对于进行非常精确的编辑,我认为那主要是靠Tab自动补全。然后,在刚开始接触一个可能不太熟悉的代码库时,会大量使用QA功能,大量使用搜索,我认为这也是Claude 和一直表现出色的地方,即在代码库中进行研究,弄清楚某些东西是如何相互作用的。
Alex(Anthropic): 我明白了,所以使用这些功能来探索你们的代码库使过程更容易,然后你们在使用这些功能的过程中学习到,哦,这个领域存在不足,我们应该去改进它。
Lukas(Cursor): 是的,更容易。我认为Cursor很大程度上是由解决我们自己的问题驱动的,弄清楚我们在解决问题时遇到的困难,并使Cursor变得更好,然后,是的,弄清楚我们可以在那里做什么,然后进行大量实验。我们非常信奉这样的理念:每个人都可以尝试新事物,尝试向产品添加新功能,然后在内部观察它们的使用情况以及收集到的反馈。
Alex(Anthropic): 你认为在更宏观的层面上,成为自己内部最好的客户是否存在优势?
Aman (Cursor): 我认为百分之百是。我认为这就是我们能够非常迅速地构建新功能,并舍弃那些明显无效的东西的原因,因为我们可以非常诚实地对待自己,判断我们是否觉得它有用,而不必将其发布给用户,跟踪人们如何使用它,然后再决定是否继续开发某个功能。我认为这只是加快了构建功能的迭代循环。
功能谱系:从辅助到自主
Aman (Cursor): 是的,回到我们如何使用AI进行编程的整体情况,感觉上,公司内部不同人使用它的方式存在很大的多样性。我认为首先区别在于你正在做的工作类型。所以,你知道,有很多人可能在他们非常熟悉的代码库的某些部分工作,对吧?在那种情况下,当你脑子里已经有了所有内容时,通过键入代码来传达意图通常更快,而这时Tab自动补全就非常有用,因为它能在那方面提高你的速度。但是,当你在不太熟悉的地方,或者你需要写出大量代码时,你可以将很多工作,甚至一些推理工作,交给这些模型。然后,你知道,当你到达像Lukas描述的那样你非常不熟悉的地方,你正在接触一个新的代码库时,使用这些模型会带来巨大的效率提升。我们观察到的是,随着时间的推移,随着模型变得越来越好,以及Cursor在使用这些模型方面变得越来越好,当你更投入、对代码库有更多了解时,你也会做得越来越好。
Alex(Anthropic): 所以,一个功能何时最适用于你的用例是变化的,它在某种程度上几乎像一个谱系。
Aman (Cursor): 是的,这个谱系的一端是Tab自动补全,适用于你完全掌控并且知道自己在做什么的时候;然后是Command K,用于编辑单个给定区域,也许是整个文件;在另一端,你有Agent,它非常适合编辑多个文件;最后,你还有我们一直在开发的这种后台代理(Background Agent),它可以用于基本上完成整个PR(Pull Request)。
后台代理(Background Agent)的理念与实现
Alex(Anthropic): 你们刚刚发布了后台代理的预览版。什么是后台代理?
Aman (Cursor): 我认为很明显,模型在完成端到端任务方面正变得越来越好,但它们还没有达到的水平,而且我认为要达到还需要一段时间。所以,你提高开发者效率的方式是,让他们并行处理这些事情。但是,与其让它只是在后台运行然后生成一个你在GitHub上查看的PR,如果它只完成了,你会想介入并控制,完成剩下的部分,然后你会想使用Cursor的功能来做到这一点。所以,能够在后台和前台之间快速切换非常重要。而且我认为,我们正处于这个功能的早期阶段,我可以想象有很多有趣的方式可以操作,例如同时处理三到四个变更,然后快速地将它们切换到后台,再移到前台。看看这将如何改变人们使用Cursor的方式以及整个软件开发的方式,将会非常有趣。
Lukas(Cursor): 我的意思是,我们基本上将后台代理视为一种新的基础能力(primitive),可以在许多不同的地方使用。当前暴露它的方式非常直接,你只需提供一个提示,然后将其推送到后台,它就会独立地对此进行迭代。但是,可能会有更多的方式来生成这些东西,我认为可以从中创造出很多产品。
Alex(Anthropic): 那么这是将你的代码库放到一个虚拟机里,还是具体发生了什么样的转换?
Lukas(Cursor): 正是如此,是的。我们有足够小的独立环境,这些环境已经安装了所有的开发者环境工具,然后代理可以使用这些工具,并且它拥有所有可用的VS Code扩展,通过这些它可以获取等等。
未来的瓶颈:软件验证
Alex(Anthropic): 我知道我们正在目睹这种异步任务、后台任务在许多不同事物中的趋势,从编码到研究等等。在您看来,随着这种趋势发展到我们可能有成千上万个这样的代理在运行,甚至可以看到整个代理团队在后台攻击一个问题,那会是什么样子?那个未来会是怎样的?
Aman (Cursor): 我认为你将遇到的下一个瓶颈是软件的验证,代码的验证。模型在生成和编写大量代码方面变得越来越好,但是,假设开发者花费——我会说一些大概的数字——的时间编写代码,或者的时间审查代码,的时间编写代码。如果你完全解决了编写代码的问题,你仍然没有真正将软件工程的速度提高超过三倍。是的,所以我认为我们需要弄清楚如何让人们更容易审查代码,以及如何确信代理所做的更改不仅仅是正确的——因为“正确”可能很模糊,对吧?它可能只是在你指定的事情上,由于指定得不够充分,它实际上做了对于即使是最好的人类程序员来说也是可能做到的最好的事情,但它实际上并不是你心目中所想的。因此,让你的这个过程变得更好,我认为将非常非常重要。这也是我们非常感兴趣的事情。
Alex(Anthropic): 关于那方面有什么初步的想法吗?
Aman (Cursor): 我认为公司里不同的人有一些零散的想法。我们的CEO Michael非常喜欢的一个想法是在代码库的不同表示形式中操作。也许它看起来像伪代码,如果你能用这种非常简洁的方式表示更改,并且能保证它能清晰地映射到实际软件中所做的实际更改,那应该能大大缩短验证时间。但那只是一种可能的途径。我认为,所谓的“感觉式编程 (vibe coding)”之所以经常有效,是因为验证过程非常简单,因为它所做的只是摆弄软件,对吧?你做一个更改,然后实际操作你构建的任何软件。我认为对于真实的生产代码库来说,这会非常困难,解决这个问题非常重要。
大型生产代码库的挑战与解决方案探索
Alex(Anthropic): 这是一个很好的问题,关于像他们可能正在进行“感觉式编程”的独立项目与拥有数百万行文件的生产代码库之间的区别。在你们看来,这两者之间有什么区别?就目前模型在其中工作的能力而言,我们处于什么阶段?
Jacob(Cursor): 我认为这是我们在后台代理方面思考了很多的问题。因为有些事情非常简单,显然用这些模型应该很容易做到,比如我这里有一个测试,这个测试目前失败了,你能修复代码让它通过吗?然后问题就变成,我们如何实现这一点?模型需要能够运行测试,如果你的代码仓库非常简单,那也很简单,但是当你开始接触那些大型企业代码库时,要正确设置依赖项以便模型能够运行测试,可能会变得很复杂。但这是我们在后台代理方面思考了很多的问题,即如何使开发者创建这种环境(代理可以在其中运行测试)的过程变得简单直接,然后使其可重复,这样你就可以对其进行快照,并且当你的代码状态发生变化时可以快速更新它。这就解锁了在后台启动一个虚拟机,让模型进行实验的能力,你知道,其中一些实验会使测试通过,一些则不会。最终,作为开发者,你只需要关心测试成功的情况。这其中涉及大量的基础设施和用户体验,把这些做好非常重要。
Aman (Cursor): 是的。然后我认为还有其他根本性的问题。一种方法是你让模型尝试通过测试,对吧?那样你或许可以保证某种程度的正确性。但是对于这些大型代码库,你经常会处理一些几乎像是它们自己语言的东西,它们在某些语言内部有这些类似DSL(领域特定语言)的东西,所有事情都以这种特定的方式完成,并且它确实分散在数百万个文件中,这可能是数亿个token,甚至更多。我们已经做了很多事情来显著改善这一点,包括训练检索模型,以及集成其他上下文来源。例如,你可以想象,你最近在编辑代码时所做的更改中蕴含着大量丰富的信息,它在某种程度上表明了你正在努力的方向。你团队中其他人,尤其是在最近,在你的代码库中所做的更改中也可能蕴含着丰富的信息,并将这些作为提示。但我确实认为,仅仅给模型提供非常好的检索能力,对于让模型真正理解代码库来说,仍然感觉不够,这是一个我们非常感兴趣要解决的问题。
Alex(Anthropic): 嗯嗯。可能通过某种组合,比如内存加上长上下文窗口和……
Aman (Cursor): 是的。其他东西。我认为内存是人们让模型从你的使用中学习的一种有趣的方法,但它也感觉像是,你知道,性能上的一点点提升,而且相对于我们需要达到的水平,以便获得在大型代码库上表现出色的东西而言,它感觉相当初级。
Lukas(Cursor): 是的,对于大型代码库而言,不仅仅是让测试通过,还关乎以正确的方式去做。比如审视现有代码,让新代码与之匹配,并将其整合到正确的结构中,以及正确地使用所有指南。我们一直在非常努力地通过Cursor的规则、集成不同类型的上下文等方式来实现这一点。
Jacob(Cursor): 嗯。是的,比如我可以从头开始写一个debounce函数,然后直接用它,这样测试就能通过,但那不是正确的做法。你应该使用已有的debounce函数之一,也许代码库中使用了三四个debounce函数。你怎么知道哪个才是正确的?也许唯一知道的人是因为他们在Slack上给某人发了消息说应该这样做。所以,是的,我认为对于超大型代码库来说,解决这些问题变得非常非常困难。
Alex(Anthropic): 这很有趣。所以这里面也有一种存在于代码库本身之外的组织知识的因素,这在某些决策中,尤其是在操作大型代码库时,有时会起到主要作用。
Aman (Cursor): 是的。我不认为那是今天的瓶颈,但我认为如果你解决了,比如你让模型在理解代码库方面变得完美——是的。——我想你可能会立即,也许会得到大约5倍,也许10倍的改进,但你无法超越那个程度,因为现在它完全受限于它对那些从未在PR和代码实际状态中明确提及或展示的事物了解多少。
Lukas(Cursor): 嗯嗯。然后还有来自业务方面、销售等方面的外部考虑。这些也必须被引入到Cursor中才能使其工作。
Alex(Anthropic): 对。所以未来某个版本的Cursor将不得不接入更多的系统——
Aman (Cursor): 是的。——和事物。需要明确的是,我认为,你知道,要让那些东西变得非常非常关键,相对于其他事情而言,还有一段路要走。我认为我们在仅仅利用用户交互、他们代码库的细节以及所做的提交来使Cursor变得更好方面,还有很长的路要走。
代码的演变:为AI和人类优化
Alex(Anthropic): 我开始注意到一个有趣的现象,至少在网页和内容方面,人们现在开始思考如何优化页面以便LLM阅读和浏览。你认为我们会在代码方面看到类似的情况吗?也就是说,如果你主要是为人类审查者和在代码库中工作的人类编写代码,那么代码的通常编写方式和外观是否会发生转变,以适应模型?
Lukas(Cursor): 我认为这完全已经是事实了。我的意思是,API设计已经在调整,以便LMS(语言模型)更适应。例如,不仅改变内部版本号,还要让模型非常清楚地知道这是某个软件的新版本,只是为了确保API被正确使用。而且我认为这同样适用于普通代码库和内部库,比如将代码结构化,使得人们不必经过N层交互,也许只需经过两层交互,就能让LLM模型更好地处理该代码库。
Jacob(Cursor): 对。但我认为最终,整洁软件的原则,当你希望它能被人类和模型阅读时,并没有那么大的不同。你知道,当你试图编写整洁的代码时,你希望,你知道,不要重复自己,不要把事情搞得比它们需要的更复杂。这对模型和对人一样重要。而且我认为代码的品味,以及什么是简洁而不比实际需要更复杂的解决方案,随着这些模型的进步,实际上会变得更加重要,因为编写越来越多的代码会变得更容易,因此,以有品味的方式组织它将变得越来越重要。
Alex(Anthropic): 关于品味,这是一个很好的观点。
自动化浪潮下工程技能与代码质量的维系
Alex(Anthropic): 品味这种东西,我觉得可能有些人天生比其他人更有品味,但通常你是通过经验、学习什么有效、看到失败和成功来培养品味的。在一个AI越来越多地为我们编写代码的世界里,有些人提出了强烈的反对意见,他们说,哦,这会使程序员变懒,或者你不会给初级开发者机会去学习在一个大型代码库中工作以及做所有这些事情的实际情况。你如何看待在实现这种自动化或辅助的同时,也保留软件工程师可能必须经历的核心工程技能,那些考验和磨难?
Jacob(Cursor): 我认为这些工具在教育方面也非常好,它们可以帮助你成为一名优秀的程序员。你知道,如果你对某件事如何运作有疑问,如果你想让某个概念得到解释,现在你只需按下Command L,问Claude,你知道,这是什么?它是如何工作的?你能给我解释一下吗?我认为这非常有价值。它确实使得编写更多代码和做更多事情变得更容易,这可能导致更高质量和更低质量的代码出现。这是事实,但我认为总的来说,这是一个非常非常强大的工具,它会提高标准。
Lukas(Cursor): 我认为质量很大程度上来自于快速迭代,犯错误,弄清楚某些事情为什么会失败。而我认为模型极大地加速了这个迭代过程,并且实际上可以通过这个过程让你更快地学习什么有效,什么无效。所以我认为从长远来看,对于刚起步并从事越来越大项目的开发者来说,这是一个非常有用的工具,可以帮助他们弄清楚什么有效,什么无效。
Aman (Cursor): 是的,我认为看看编程将如何演变会非常有趣。我想在很长一段时间内,你仍然需要那些了解细节、能够深入研究的工程师。我想知道,你会在多大程度上开始看到那些现在正在学习编程,但并不了解许多细节,却仍然能够相当有效的人。我认为今天你仍然需要了解很多细节。我认为随着时间的推移,可能会出现一类软件工程师,他们需要了解的底层细节非常少,但仍然能在更高层次上操作,也许这看起来更像是思考,比如品味更偏向于用户体验(UX)的品味,对吧?比如说你正在尝试构建像Notion这样的东西,对吧?最终,我不认为你可以把整个事情都交给语言模型。你需要描述,比如说,当我进行这种类型的交互时,我期望它以这种特定的方式弹出,对吧?也许你不必深入到编写实现这一功能的纯软件的细节,但仍然需要描述那些交互,描述这个东西大致是如何工作的。这本身就是一种编程。
Alex(Anthropic): 稍微转换一下话题,关于模型。
Claude新模型(Opus 4, Sonnet 4)的特点与集成展望
Alex(Anthropic): 我们最近,当这个视频发布的时候,Claude Opus 4和Claude Sonnet 4将会面世。很想听听你们对这些新模型的看法,以及你们开始如何考虑将它们集成到Cursor中。
Jacob(Cursor): 我的意思是,我们非常喜欢这些新模型。我想我们试用新的Sonnet时相当震惊,因为我认为是一个非常棒的模型。它在代理式编码方面更好,但每个人都知道它有点缺陷,对吧,它可能有点过于急切——
Alex(Anthropic): 喜欢做很多事情。
Jacob(Cursor): 是的,它确实会。有时会喜欢修改测试用例,让它们通过。
Alex(Anthropic): 是的,是的。
Jacob(Cursor): 我们发现Sonnet 4有效地修复了所有这些问题,它好得多,而且智能水平也有了很大的提升。你知道,你也见过其他在智能方面有所提升的模型,也许在代理式编码方面没有那么强,但比如O3就是一个例子,我们发现它与O3不相上下,尽管它是一个便宜得多的模型。所以我们对Opus非常兴奋,因为我们认为它将是一个非常棒的、可以在后台使用的代理。
Alex(Anthropic): 是的,很高兴听到这个。测试编写和过度积极的问题是我们试图用这些模型着力解决的事情,还有奖励 hacking 的概念,即模型会找到某种捷径来达到强化学习中的最终奖励。我们做了很多工作来减少这个问题。我想在这些新模型中,我们把它减少了大约。
Jacob(Cursor): 我非常好奇 Sonnet是如何诞生的,因为那感觉像是Anthropic推出的第一个真正优秀的编码模型。
Alex(Anthropic): 它是如何诞生的?我们训练了它。它就是很好。是的,我想我们很早就知道,可能从公司成立之初就知道,我们希望让模型在编码方面非常出色,这对于你做的其他所有事情似乎都很重要,尤其是当你制造更多模型的时候。 Sonnet是,我不会,我的意思是,我认为-Opus在当时也是一个非常好的编码模型。但是 Sonnet是我们第一次真正投入了巨大的、专门的努力,去让这些模型在编码方面表现出色,但不仅仅是特定的编码,而是那种更长远的编码,它需要做一些像你之前在对话中提到的事情,比如在不同的文件上进行编辑,执行一个命令,调用一个工具,然后去其他地方做修改。那是第一个我们能够将所有这些东西整合在一起的模型,而且我认为结果非常好,为我们未来的模型奠定了基础。
Anthropic的模型开发理念与未来展望
Jacob(Cursor): 你们是如何看待代码相对于你们希望Sonnet和Opus擅长的其他领域的关系的?
Alex(Anthropic): 是的。我的意思是,代码是主要领域之一,但我认为它不是唯一的领域。我认为模型在代码方面变得非常出色,可以很好地迁移到它们在推理、执行多项操作以及以这种代理方式工作方面的能力提升上。当你在处理可能混合了代码,但还需要从其他地方检索知识或进行研究的应用时,这种迁移是非常有益的。总的来说,我们致力于尽可能地用我们的模型推动前沿。当然,我们也会考虑安全性,并确保模型符合你作为用户的期望,以及我们认为模型应该做的事情。但总的来说,我们希望不断推动这些模型能力的极限,并向开发者和全世界展示模型的能力。比如计算机使用,当我们在去年十月公布它时,那是我们真正向前推进的另一个方向,即模型如何能够很好地操作一个主要是人类界面的东西,对吧?所以它不是在API或工具调用的世界里,而是像人类一样真实地看着一个图像,然后必须在该屏幕上指挥一个动作。我们如何思考这些模型的“性格”(character),正如现在所知,Amanda Askell是我们这项工作的首席研究员之一,她在塑造Claude的性格方面做了很多工作。我们投入了大量的思考和考量,关于Claude应该给人什么样的感觉和声音,以及一个AI在某人生活中扮演非常重要的角色意味着什么。不仅仅是作为一个编码代理,而是某种意义上的知己,一个你将花费大量时间与之交谈的实体。所以这也真正地融入了我们围绕这些模型以及如何训练它们所做的所有决策中。
Jacob(Cursor): Anthropic作为一个整体是如何看待未来发展方向的,无论是在软件工程方面,还是在研究方面,比如这些模型将在多大程度上增强、取代或完成大量这类工作?
Alex(Anthropic): 是的,这里我可以谈谈个人看法。就我个人而言,我认为我们不会被取代,正如我们之前讨论过的,当你拥有能够完成所有这些,你知道,基础性的编码工作的模型时,你现在能做的事情就多得多了。我自己也是这么看的。比如,我在大学学的是计算机科学,也做过软件工程,现在我觉得模型在生成代码方面比我强,比如如果我只是想做一个LeetCode题目或者类似的事情,在一个封闭的环境中,模型需要编写代码,它会打败我。然而,我觉得我能做的事情比以往任何时候都多。我可以制作任何东西的原型。如果我想展示一个新概念,我可以非常非常快地搭建出演示。从这个意义上说,它让我感到非常有力量,而不是剥夺或轻视我一直在做的事情。这和我感觉到的类似,正因为我过去拥有软件工程的知识,我现在实际上可以更好地利用它,我可以比我仍然对代码一无所知的情况下,把模型推向更远。
未来图景:AI在软件开发中的普及与变革
Alex(Anthropic): 也许在更深入地探讨未来的一些有趣猜测之前,我想问一个实际的问题,几年后我们可以回顾这个问题,看看我们的预测结果如何。2027年1月1日,那么,离现在不到两年时间,你认为AI生成的代码将占多大比例?以及,那些现在认为自己是开发者的人,他们的日常生活会是什么样子?
Jacob(Cursor): 我认为这有点像回到,比如说我出生前,但你知道,1995年,问一位律师未来多大比例的法律文件将由文字处理器生成,答案是,或者接近。AI将参与几乎所有代码的编写。但是,你作为律师或开发者的角色,在理解代码需要做什么、拥有品味以及指导软件如何使用方面,将比以往任何时候都更加重要。
Aman (Cursor): 我的意思是,在Cursor,这个比例可能已经超过了,但那是因为其中很大一部分是使用了更高级别的功能,比如Agent。
Alex(Anthropic): 是的。
Aman (Cursor): 还有Command K之类的。但其中很多是你正在输入,然后Tab自动补全会在你输入时完成的工作。
Alex(Anthropic): 对。
Aman (Cursor): 所以在你实际手动操作的情况下,Tab仍然完成了大部分的更改。
Alex(Anthropic): 对,所以实际输入的字母百分比非常非常低。
Aman (Cursor): 是的。但我认为软件生产的每一个方面都将以某种方式使用AI进行改变。
Alex(Anthropic): 你认为我们最终会进入一个基本上可以按需获得软件的世界吗?那会是什么样子?
Jacob(Cursor): 我认为你会看到人们构建软件,组织职能部门的人构建软件,而这些人以前是不构建软件的。你知道,比如销售人员以前不会构建自己的工具,但现在他们会构建,例如,仪表盘来跟踪对他们重要的事情。回到品味比以往任何时候都更重要这一点,你知道,现在你可以构建仪表盘,但你仍然需要决定仪表盘要显示哪些指标。它并不能免除你做这个决定的需要。我认为你会看到更多的人构建自己的软件,但这将受限于你是否有一个独特的、希望通过软件实现的需求,而这个需求没有被现有的方案很好地满足。
Alex(Anthropic): 我喜欢给人们举的一个例子是,我们传播团队有个人,他实际上一直在为Claude.ai提交bug修复,这简直太疯狂了。他属于组织中一个完全不同的部门,根本不接触产品,但他却提交了一个PR,还要求批准,你会想,你在做什么?事实是,是的,他正在使用,你知道的,Claude的代码或者某个以Claude为基础模型的编码工具,来修复生产代码库中的bug。我认为这也太棒了。这又回到了那个普遍的观点,嘿,如果你有品味,如果你有好的直觉,你就能做很多事情。我就是这样看待世界持续进步的。我认为事情会改变,角色在五年、十年后会大不相同,但总的来说,我非常赞同,如果你能用这些东西做更多的事情,那通常总是一件好事。
Aman (Cursor): 是的,我觉得这有很多有趣的发展路径。一种是完全即时的按需软件,比如我正在使用我自己版本的某个应用程序,就在我使用它的时候,我不喜欢某个交互,它就为我改变了。这是一种你可以想象的疯狂的未来,甚至不是你主动去做,而是仅仅基于你与它的交互,你正在使用的任何软件都会改变以适应你。这是一个很酷的潜在前进方向,我不知道世界上是否每个人都想,我不知道那些想自己构建软件的人的总数是否那么多。
Alex(Anthropic): 对。
Aman (Cursor): 但我认为那些能够从适应他们需求的软件中受益的人,可能是全世界的人。
Alex(Anthropic): 好的,也许最后一件事情来结束今天的谈话。
给工程师的建议:选择与机遇
Alex(Anthropic): 对于所有正在观看这个视频的人,如果你是一位有才华的工程师,并且正在考虑你的下一步行动,或者你想更多地参与到这个行业中,并且你正在犹豫是去一家大公司还是加入像Cursor或Anthropic这样节奏更快的初创公司,你会对处于这种境地的人说些什么?
Aman (Cursor): 是的,我认为如今初创公司在吸引真正优秀的人才方面具有优势,比如Anthropic和Cursor,而在大公司,很多人,你知道,世界上很多最优秀的人会觉得那里不那么令人兴奋,对吧?有些人确实喜欢大公司,而且大公司当然也有优秀的人才,但那种人才的密度往往要低得多。而在初创公司,你可以获得非常高的人才密度,这使得与一群优秀的同事一起工作非常愉快。你可以在一个非常小的团队中从事真正有影响力的事情,对吧?构建一个改变世界编写软件方式的产品,构建改变世界编写软件方式的模型。你可以成为从事这项工作的数十、数百或数千人中的一员,这真的很酷。
Alex(Anthropic): 是的。太棒了。非常感谢你们。这是一次很棒的对话。
Lukas(Cursor): 谢谢你。
Aman (Cursor): 谢谢你。
要点回顾
引言
- 软件生产的每一个方面都将以某种方式使用AI进行改变。
- Alex (Anthropic) 主持,嘉宾为 Cursor 的 Lukas (负责代理系统)、Aman (创始人之一,负责机器学习和检索) 和 Jacob Jackson (负责机器学习)。
- 讨论 Cursor 的发展以及如何使用 Claude。
Cursor的增长与演变
- Cursor 在过去一年中快速扩展,年收入超过$3亿美元 (原文为: over $300 million revenue),数百万开发者正在使用。
- 一年前与现在的 Cursor 的不同之处:
- 语言模型现有水平与实际应用之间存在巨大差距,Cursor 在编码领域率先缩小了这一差距。
- 模型在编码能力上大幅提升,例如 Sonnet 在编程能力上实现了阶梯式进步。
- 早期 Cursor 主要用于标签补全、单文件内编辑。
- 结合 Sonnet 的智能和 Cursor 自定义的检索模型及编辑应用模型后,实现了多文件编辑能力,推动了大规模采用。
- 此后,模型持续进步,Cursor 也在底层不断优化,以拓展模型的应用极限。
模型的进步与Cursor的迭代
- 模型的进步感觉是渐进的,每次新模型发布都能在推理和代理式编码方面看到进步。
- Cursor 团队在初期并不擅长“品鉴”模型的好坏。
- 需要大量尝试和调整来发现有效的方法。
- Sonnet 是第一个能让多文件交互良好工作的模型。
- 随后的进步包括工具使用,使模型能像编辑器内的真实代理一样运作。
- 新模型的进步和新能力的出现,促进了更多的实验和探索,这些成果又融入到产品中,催生新功能。
用Cursor构建Cursor:自我迭代与优势
- Cursor 团队使用 Cursor 来构建 Cursor,形成自我改进的递归反馈循环。
- 日常使用方式因人、用例、产品部分和开发阶段而异:
- 初始化代码库、新功能:使用 Agent 功能启动。 -调试:使用思考模型分析单个错误。
- 精确编辑:大量使用 Tab 自动补全。
- 探索不熟悉的代码库:大量使用 QA 功能和搜索 (Claude 和 在此表现出色,能进行代码库研究,理解不同部分如何交互)。
- 通过使用自家产品发现不足,进而改进。
- Cursor 的开发很大程度上由解决自身问题驱动,鼓励全员尝试新功能并根据内部使用反馈进行迭代。
- 作为自己产品的最佳客户的优势:
- 能够快速构建新功能,并舍弃无效功能。
- 能对自己诚实评估功能的有效性,无需先发布给用户再收集反馈。
- 加速了功能构建的迭代循环。
功能谱系:从辅助到自主
- 公司内部不同人使用 AI 的方式存在多样性,取决于工作类型:
- 熟悉的代码库:直接编写代码更快,Tab 自动补全很有用。
- 不太熟悉或需编写大量代码:可以将部分工作和推理交给模型。
- 完全不熟悉的新代码库:使用模型能带来巨大效率提升。
- 随着模型和 Cursor 的进步,即使开发者对代码库有更多了解,AI 辅助效果也越来越好。
- 功能适用性随用例变化,形成一个谱系:
- Tab 自动补全:开发者完全掌控时使用。
- Command K:编辑单个给定区域或整个文件。
- Agent:适用于编辑多个文件。
- 后台代理 (Background Agent):可用于完成整个 PR (Pull Request)。
后台代理(Background Agent)的理念与实现
- 模型在端到端任务上的能力越来越强,但尚未达到 。
- 通过允许开发者并行处理任务来提速。
- 如果后台任务只完成了 ,开发者希望介入并使用 Cursor 的功能完成剩余部分,而不是仅在 GitHub 上审查一个 PR。
- 在后台和前台之间快速切换非常重要。
- 该功能尚处早期,未来可能支持同时操作三到四个变更,并在后台和前台间切换。
- 后台代理被视为一种新的基础能力,可以应用于许多不同场景。
- 当前的实现方式:用户提供提示,代理在后台独立迭代。未来可以有更多集成方式。
- 实现机制:使用小型的、独立的、预装了所有开发环境工具和 VS Code 扩展的虚拟机环境,代理可以在其中运行。
未来的瓶颈:软件验证
- 异步任务和后台任务是跨多个领域(编码、研究等)的趋势。
- 若有成千上万的代理同时工作,下一个瓶颈将是软件验证和代码验证。
- 模型在生成大量代码方面越来越强。
- 假设开发者花费,一些随机数字,的时间编写代码 或 的时间审查代码,的时间编写代码。如果完全解决了代码编写问题,软件工程效率提升也难以超过3倍。
- 需要让代码审查更容易,并确保代理所做更改不仅正确(“正确”可能模糊不清,因需求未充分说明),而且符合开发者心中的预期。
- 早期想法:
- Cursor CEO Michael 提出的一个想法是:在代码库的不同表示形式(如伪代码)中操作。如果能以简洁方式表示变更,并保证其能清晰映射到实际软件中的变更,将极大缩短验证时间。
- “感觉式编程 (vibe coding)”之所以有效,是因为验证过程简单(即实际操作软件)。但这对于真实的生产级代码库很难实现。
大型生产代码库的挑战与解决方案探索
- 单独项目与拥有数百万行文件的大型生产代码库的区别:
- Cursor 在后台代理功能中对此有很多思考。例如,修复一个失败的测试,模型需要能运行该测试。
- 对于大型企业代码库,正确设置依赖项以便模型运行测试可能很复杂。
- 后台代理的目标是简化开发者创建代理运行环境的过程,支持快照、随代码状态快速更新。
- 这使得模型可以在后台虚拟机中进行实验,开发者只需关注成功的案例。需要大量基础设施和用户体验优化。
- 其他根本性问题:
- 大型代码库通常包含类似领域特定语言 (DSL) 的结构,代码分散在数百万个文件(可能达数亿token)。
- Cursor 的应对:训练检索模型,集成其他上下文来源(如用户最近的编辑、团队成员最近的提交)。
- 仅靠良好的检索对于模型真正理解代码库来说似乎仍不够。
- 解决方案可能涉及内存机制和长上下文窗口的结合。
- 内存机制(从用户使用中学习)是一种尝试,但性能提升有限,相对于解决大型代码库问题的需求而言仍较初级。
- 大型代码库不仅要求测试通过,还要求以“正确的方式”实现,即符合现有代码风格、结构和规范。
- Cursor 通过规则 (Cursor rules) 和集成不同类型的上下文来努力实现这一点。
- 例子:从头写一个 debounce 函数能通过测试,但正确做法是使用代码库中已有的(可能存在多个,需选择合适的)。这种“正确性”的知识可能仅通过非正式渠道(如Slack消息)传播。
- 组织知识(存在于代码库之外)对决策有重要影响。
- 这目前还不是主要瓶颈。如果模型能完美理解代码库(带来5-10倍改进),那么组织知识和业务层面的考虑将成为新的瓶颈。
- 未来的 Cursor 可能需要接入更多系统(如业务、销售系统)。
- 当前阶段,更重要的是利用用户交互、代码库细节和提交历史来改进 Cursor。
代码的演变:为AI和人类优化
- 出现为 LLM 阅读和浏览而优化网页的趋势,代码领域是否也会类似?
- Lukas 认为这已经发生:API 设计正在调整以适应 LLM(例如,版本号更显式,以便模型正确使用API)。
- 普通代码库和内部库也在发生类似变化,例如通过减少交互层级使代码结构更易于 LLM 理解。
- Jacob 认为整洁软件的原则对人类和模型而言并无太大差异(如DRY原则,避免过度复杂化)。
- 随着模型编写更多代码,“代码品味”和简洁的解决方案将变得更加重要,关键在于如何有品味地组织代码。
自动化浪潮下工程技能与代码质量的维系
- “品味”通常通过经验培养。AI编写代码引发担忧:程序员变懒,初级开发者失去学习机会。如何平衡自动化与核心工程技能的培养?
- Jacob 认为这些工具在教育方面也很有价值,可以通过提问(如向Claude提问)来学习概念。
- AI使编写更多代码更容易,可能导致更高质量的代码,也可能导致更低质量的代码。但总体而言,AI是提升整体水平的强大工具。
- Lukas 认为高质量源于快速迭代和从错误中学习,模型能极大加速此过程,帮助更快学习有效方法。长期看对初级开发者非常有帮助。
- Aman 认为编程将如何演变:长期内仍需要了解细节的工程师。未来可能会出现一类不了解底层细节但仍能高效工作的软件工程师,他们可能更侧重于高层次的思考,如用户体验(UX)层面的“品味”,描述交互本身也是一种编程。
Claude新模型(Opus 4, Sonnet 4)的特点与集成展望
- Anthropic 最近发布了 Claude Opus 4 和 Claude Sonnet 4。
- Cursor 团队对新模型的看法:
- 对新 Sonnet (Sonnet 4) 印象深刻。之前的 (很可能指Sonnet 3.5) 模型在代理式编码方面很出色,但存在一些缺陷(如过于“积极”,有时会修改测试用例以使其通过)。
- Sonnet 4 有效修复了这些问题,并且智能水平也有显著提升,可以与 O3 (Opus 3) 等模型媲美,且成本更低。
- 非常期待 Opus (Opus 4),认为它会是一个出色的后台代理。
- Alex (Anthropic) 回应:测试编写和“过度积极”是新模型着重改进的方面(针对奖励 hacking 问题),在新模型中此类问题减少了约 。
- Jacob 提问 Sonnet 的由来:
- Alex 回答:Anthropic 一直致力于提升模型的编码能力。-Opus 在当时已是不错的编码模型。 Sonnet 是首次在更长远规划的编码任务(如多文件编辑、工具调用)上投入大量专项努力的成果,它整合了多方面能力,效果很好,为后续模型奠定了基础。
Anthropic的模型开发理念与未来展望
- Jacob 提问 Anthropic 如何平衡 Sonnet/Opus 在编码与其他领域的表现。
- Alex 回答:
- 编码是主要领域之一,但不是唯一领域。模型在编码方面的熟练度能很好地迁移到通用推理和代理式工作能力上。
- 这种迁移对于处理混合应用(编码+知识检索/研究)很有益。
- Anthropic 的目标是尽可能推动模型能力边界,同时兼顾安全和对齐(符合用户期望和 Anthropic 的价值观)。
- 向世界展示模型的能力,例如去年10月展示的计算机使用能力(模型操作人类图形界面)。
- 重视模型“性格” (character) 的塑造(由 Amanda Askell 主导),思考 Claude 给人的感觉、声音,以及 AI 作为用户生活中重要角色的意义(不仅仅是编码助手,更是某种意义上的“知己”)。这些都融入到模型训练决策中。
- Jacob 问 Anthropic 对软件工程和研究未来(AI的增强、替代作用)的看法。
- Alex (个人观点):
- AI 不会取代开发者。当模型能处理基础的编码工作后,开发者可以做更多事情。
- 个人体验:模型在某些编码任务(如 LeetCode 题目)上可能比他强,但他现在能做更多事(如快速搭建原型、演示新概念),感到更有力量。
- 拥有软件工程背景知识有助于更好地利用模型。
未来图景:AI在软件开发中的普及与变革
- Alex 提问:到2027年1月1日,AI生成的代码占比会是多少?开发者的日常生活会是怎样?
- Jacob 类比:1995年的律师,文字处理器生成的法律文件占比?答案是接近 。AI将参与几乎所有代码的编写。开发者的角色(理解需求、品味、指导软件方向)将比以往更重要。
- Aman:在 Cursor,AI 生成/辅助的代码占比可能已达 以上,因为大量使用 Agent、Command K 等高级功能。即使是手动输入,Tab 自动补全也完成了约 的工作。
- Jacob:软件生产的每个方面都会因AI而改变。
- Alex 问及“按需软件 (software on demand)”。
- Jacob:非软件工程背景的人(如销售人员)将能构建自己的工具(如仪表盘)。但仍需“品味”来决定仪表盘展示哪些指标。更多人会构建自己的软件,瓶颈在于是否有独特的需求未被现有方案满足。
- Alex 举例:Anthropic 的一位公关团队成员使用 Claude 的编码工具为 Claude.ai 修复了bug。这说明有“品味”和直觉的人能做很多事。
- Aman 设想的未来路径:
- 完全动态的按需软件:用户在使用某个应用时,若不喜欢某个交互,软件能即时为用户调整。
- 并非每个人都想构建自己的软件,但全世界的人都可能从能适应自身需求的软件中受益。
给工程师的建议:选择与机遇
- Alex 提问:对正在考虑职业发展(大公司 vs. Cursor/Anthropic这类快节奏创业公司)的优秀工程师有何建议?
- Aman 回答:
- 如今,创业公司在吸引顶尖人才方面具有优势。
- 在大公司,许多顶尖人才可能会觉得缺乏激情(尽管大公司也有优秀人才,但人才密度通常较低)。
- 在创业公司,可以有很高的人才密度,与优秀的同事共事非常愉快,能在小团队中从事极具影响力的工作,构建改变世界编写软件方式的产品和模型。