编译 | 伊风
事情的发展越来越有趣了。
Anthropic 在断供 WindSurf 模型接入时公开表态：把 Claude 卖给 OpenAI 的产品，确实“感觉很怪”。这番话，让不少用户直接为 WindSurf 判了“技术死刑”。
但更出人意料的是——早在 Claude 4 发布前，Anthropic 就已经和 Cursor 携手做了一期技术播客。
再加上 Claude 4 发布当天，WindSurf 就失去了模型接入权限……这些时机一叠加，不免让人多想：
难道继 AI 公司纷纷投靠大厂后，AI 编程产品也得“选边站”？
现在，这期播客已经可以观看了。抛开这些商业角力的八卦不谈，这期播客在技术维度上绝对是干货拉满！
一边是被认为在编程能力上遥遥领先的 Claude，另一边是当下最受欢迎的 AI 编程工具 Cursor，四位核心成员坐在一起，聊透了“AI 正如何重塑软件开发”。
图片
左起：
Jacob，Cursor 研究员，负责机器学习和检索系统
Aman，Cursor CTO&联合创始人，在 Cursor 做机器学习相关工作
Lucas，Cursor研究员，在 Cursor 主要负责 AI 编程系统方面的工作
Alex，Anthropic Claude 的开发者关系团队负责人
这场对谈不仅涉及技术演进和产品理念，更直面一个核心问题：
当 AI 能“写代码”，开发者还需要什么能力？
话不多说，先来画个重点：
- Claude 3.5 Sonnet 是一个明显的转折点，它让AI编程从单一的自动补全，走向了多文件、长上下文等复杂任务。
- Claude内部是这么平衡模型代码能力与其他能力的：代码不是唯一方向，但研究人员发现，当模型在代码上表现得更好时，它们在复杂推理、多步骤任务、agent-style 的交互上也会同步提升。
- Cursor内部坚持使用Cursor做研发，这样能最快地试验新功能，如果不work就立即放弃，不用等用户数据的反馈。
- Cursor致力开发的“Background Agent（后台代理）”，可以直接处理完整的 PR（拉取请求），未来我们会支持同时操作三四个变更，随时放后台、拉前台。
- AI编程接下来的最大瓶颈将是“代码验证”。因为模型已经非常擅长生成大量代码，但开发者目前已经将70% 花在代码检查上。
- AI编程可能将促使一类“更高抽象层级工作的软件工程师”——他们并不掌握太多底层知识，却依然能高效地开发。
- AI编程的强大，反而让开发者的角色更重要了：你需要判断这段代码应该做什么，你需要有判断力、品味，你要能引导软件向正确方向发展。
以下是经过整理的播客全文，enjoy：
模型带给Cursor新的可能
主持人 Anthropic Alex:
这次我们既会聊 Cursor 本身，也会聊你们如何与 Claude 集成。今年对 Cursor 来说可谓爆发式的一年，关注 AI 行业的人都知道——Cursor 在一年内实现了超 3 亿美元营收，这太疯狂了！现在已经有数百万开发者在使用 Cursor。在你们看来，今天的 Cursor 和一年前相比，最大的变化是什么？
CTO Aman：
我觉得主要有几件大事发生。语言模型从一开始就有很大潜力，而 Cursor 算是最早一批真正把这些能力发挥出来的公司，尤其是在编码领域。
与此同时，模型本身的能力也在大幅提升。比如 Claude 3.5 Sonnet 就是一个明显的转折点，它让“代码生成”变得不再只是自动补全，而是可以处理多文件、上下文更深的任务。在那之前，我们主要做的还是像 tab 补全、局部编辑这些事情。
但当我们把 Sonnet 3.5 的推理能力和我们自己开发的检索模型结合起来，再应用到整个代码编辑流程中时，就打开了“跨文件编辑”这个新维度。我认为那是 Cursor 用户量激增的真正关键点。从那之后，我们一方面跟随模型能力的提升，另一方面也不断优化底层逻辑，把模型的潜力发挥到极致。
主持人 Anthropic Alex:
这条进化路径是自然演化的，还是说当你们第一次用上 Sonnet 3.5 时立刻意识到“哇，我们现在可以做以前做不到的事了”？这个转变过程是怎样的？
CTO Aman：
其实是渐进的。每次模型升级后，我们都能在使用中隐约感受到它变得更聪明，但那种改变不是立刻就爆发的。老实说，我们自己有时候都不太擅长“品尝”这些模型的质量，因为我们使用它们的方式，和真实用户场景差异挺大。
我们是在反复试错中，逐步看到某些模型更擅长推理、更能处理通用编码任务，慢慢摸索出一些可以“真正跑起来”的功能。Sonnet 是第一个让我们能让“跨文件交互”真正跑通的模型。后来我们又在“工具调用”和“像 Agent 一样嵌入编辑器”的方向上，继续推进。
主持人 Anthropic Alex:
明白了。新模型能力的提升，会带来新的探索机会，然后你们再把这些验证过的能力转化为产品功能，回馈到 Cursor 里。
CTO Aman：
是的，完全可以这么理解。
如何用Cursor开发Cursor？
主持人 Anthropic Alex:
那也就引出下一个问题——我听说你们团队是在“用 Cursor 开发 Cursor”，形成了一个自我改进的反馈闭环。你能说说这在日常中是怎么运作的吗？
Lukas:
其实这很依赖于每个员工的具体工作内容，也跟他在负责的产品模块所处阶段有关。
比如说你要从头铺设一个新模块，就很适合用 Agent 功能快速生成基本结构；如果是在调 bug，那就很适合用 Claude 这样的思考型模型；如果是小改动，tab 补全就很好用。对陌生代码库，QA 和检索能力就很关键——而 3.5 和 4 系列模型在“代码结构研究”这块表现都特别出色。
主持人 Anthropic Alex:
也就是说，在探索代码时，这些工具能帮助你搞清结构，而你们在使用过程中发现某个点做得不够好，就会反过来改进产品？
Lukas:
对，我们很多功能其实就是解决自己遇到的痛点。内部试用时，谁卡住了，就会去想“能不能做一个什么功能来解决它”。我们鼓励每个人都去尝试添加功能，用完后马上内部反馈，再决定是否推广。
主持人 Anthropic Alex:
那你觉得，从“更高视角”来看，这种“做自己最核心用户”的状态，是一种竞争优势吗？
CTO Aman：
绝对是。我们能非常快地试验新功能，做出一个东西，发现不好用，立刻扔掉都可以，不用等用户数据来反馈。内部就能立刻判断：“这玩意不行。” 所以整个迭代速度快得多。
而且从我们公司内部来看，其实每个人用 AI 的方式差别也很大。
主要看你在做什么样的工作。如果你对某块代码库非常熟悉，你脑中已经有了结构图，这时候直接敲代码可能反而更快，而 tab 补全就能帮你大幅提速。
但如果你进入一个不熟悉的模块，或要写大量重复逻辑，这些都可以交给模型处理。包括一些基础推理任务也能靠模型完成。
像 Lucas 进入 Linear（一个新代码库）时就是这样，你会感受到模型带来的那种“阶跃式提速”。而随着模型越来越好，Cursor 也越来越能在“你状态在线”时帮你加速，在“你迷路时”帮你找路。
主持人 Anthropic Alex:
听起来，这些功能的适配性也像是一个“使用光谱”——越熟悉的时候用自动补全，越陌生时就更依赖模型的主动帮助。
CTO Aman：
是的，可以把这个功能的“使用光谱”想象成一端是“Tab 补全”，适合你完全掌控、明确知道自己在做什么的时候；再往前是“Command+K”编辑某个具体区域，甚至整个文件；更进一步是“Agent”——它已经能处理多个文件的编辑；而最末端的，就是我们最近一直在开发的“Background Agent（后台代理）”，它可以直接处理完整的 PR（拉取请求），非常强大。
主持人 Anthropic Alex:
你们最近刚发布了 Background Agent 的预览版，能介绍一下它是什么吗？
CTO Aman：
现在模型在完成端到端任务上确实越来越强，但还没达到 100%，短期内也不会。这种情况下，加速开发者的方式，是允许他们并行处理任务，而不是像以前那样完全“放在后台跑”，然后出来一个 PR，去 GitHub 审阅。如果这个 PR 只有 90% 完成度，那你就得接管后续的修改，这时就需要借助 Cursor 的特性，快速在前台和后台之间切换。这种流畅切换真的很关键。现在还只是这个功能的早期阶段，我可以想象，未来我们会支持同时操作三四个变更，随时放后台、拉前台，非常有趣，可能会改变大家使用 Cursor 和开发软件的方式。
Lukas:
从更广义的角度看，Background Agent 其实是一种新的“计算原语”（primitive），它可以用在很多地方。目前的交互方式比较直接，就是你输入提示词后，它就可以在后台独立运行并迭代。但未来我们还会有更多集成方式，支持各种触发场景，我觉得这是个有很多产品潜力的方向。
主持人 Anthropic Alex:
那它是不是把代码库放进一个虚拟机里？这个“转移”到底是怎么发生的？
Lukas:
没错，我们会启动一个独立环境（VM），预装好所有开发环境工具，Agent 可以直接使用它们。包括所有 VS Code 插件，它可以看到 linter 报错等。
AI编程的下一步是“代码检查”
主持人 Anthropic Alex:
现在我们确实看到越来越多的“异步任务”、“后台任务”，从编码到研究都是如此。你觉得如果未来我们有成千上万个代理在后台并行处理问题，会是什么样的情景？就像一整支“AI团队”在后台作战一样？
CTO Aman：
我觉得接下来最大瓶颈会是“代码验证”。模型已经非常擅长生成大量代码，但设想一下，开发者的时间可能有 70% 花在代码审查上，30% 写代码。即使写代码的部分完全自动化，也只能把效率提升 3 倍。验证的过程必须优化，AI 代码是否“正确”，这不只是功能实现了这么简单——还要匹配开发者的原始意图。
CTO Aman：
所以我们要解决的，是如何让开发者更容易验证代码、对 AI 的修改更有信心。正确性本身很模糊，有时你给 AI 的指令可能并不清晰，它只能在这个含糊的范围里尽力做到最好。问题是：这是不是你心中真正想要的？所以，我们非常重视优化“代码审查体验”。
主持人 Anthropic Alex:
那你们有没有一些初步的想法？
CTO Aman：
我们团队有不少想法在内部讨论。其中一个是我们 CEO Michael 特别喜欢的设想：通过一种“抽象表示形式”来操作代码库，比如用伪代码来描述变更，然后系统能确保这些变更与真实代码完全一致。这样，验证过程可以大大缩短。这就类似“vibe coding”模式有效的原因——你可以快速验证修改是否生效。但在生产环境里，这套方法很难直接用，如何扩展它，是我们非常重视的问题。
主持人 Anthropic Alex:
这是个好问题——vibe coding 适用于小工具或 demo，但如果面对的是企业级代码库，上千万行代码，这时该怎么做？现阶段的模型能胜任吗？
Jacob：
这正是我们在设计 Background Agent 时重点考虑的问题。比如说，一个简单的任务是“这里有个测试失败了，请修复代码让它通过。”这对简单代码库来说不难。但在企业级项目中，依赖设置可能非常复杂，模型无法直接运行测试。所以我们重点优化的是：如何为开发者自动创建一个可以运行测试的环境，并使其可重复更新。
这样一来，模型可以在后台开启 VM，不断尝试修改，有些能通过测试，有些不能。最终开发者只需要关注“成功的那个结果”。这个流程的基础设施和用户体验非常重要，我们花了很多精力去打磨。
CTO Aman：
另外还有一些更底层的问题。就像刚才说的，如果你能让模型“尝试让测试通过”，也许就能一定程度上验证它。但在大型代码库中，你常常会遇到“领域特定语言”（DSL）或定制开发的工具链，几乎形成了独特的语言体系，分布在上百万个文件里，总 token 数量可能达到数亿，甚至更多。
我们已经做了很多工作来提升模型对大规模代码库的理解，包括训练检索模型、整合其他上下文来源。例如，最近你在代码里修改的地方，往往能反映出你正在专注的方向，这其实就蕴含了很多有价值的信息；还有团队成员最近做的改动，也同样可以作为提示信号。不过我认为，仅仅给模型提供更好的检索能力，依然不足以让它真正“理解”一个庞大的代码库。这仍是一个本质性的难题，我们非常希望能解决它。
主持人 Anthropic Alex:
可能还需要结合“记忆”机制和长上下文窗口来解决吧。
CTO Aman：
是的，记忆是一种很有意思的尝试，让模型能从你与它的使用过程里“学习”。但目前来看，它带来的性能提升还比较有限，比较原始，离我们真正需要的那种对大规模代码库的掌握，还有很长的路。
Lukas:
而且在大型代码库中，目标不仅仅是“让测试通过”。更重要的是以正确的方式实现它：要参考已有代码的风格和结构，把新代码融入进去，并遵循所有既定的规范。我们为此投入了很多努力，比如跨越式规则整合、引入多种上下文来源等。
CTO Aman：
就拿防抖（debounce）函数举例，我当然可以手写一个新的 debounce 函数，让测试通过，但这并不是正确做法。你应该使用已有的 debounce 函数。但问题是，可能这个项目里已经有三四个类似函数，如何知道该用哪个？可能只有发个 Slack 问下某位老员工才能搞明白。所以说，在这种体量下，要解决这些问题真的非常困难。
主持人 Anthropic Alex:
你这个例子很有意思。原来还有这么多组织知识是存在于代码库之外的，而这些隐性知识却会深刻影响开发决策，尤其在处理大型项目时。
CTO Aman：
我不认为“组织知识”是当前的主要瓶颈。但就算你让模型能“完美理解代码库”，你可能也就获得 5 倍、10 倍的提升而已。接下来会卡在另一个瓶颈：模型能否获取那些永远不会出现在 PR、代码注释或文档中的信息。这些才是真正影响开发效率的隐性背景。
Lukas:
而且很多商业侧的上下文，比如销售、业务逻辑，也必须被纳入到 Cursor 的体系中，才能真正发挥作用。
主持人 Anthropic Alex:
也就是说，未来的 Cursor 需要对接更多系统，才能真正“智能”。
CTO Aman：
是的，但我觉得这还不是最迫切的任务。眼下我们还有很多路要走，比如更好地利用用户与代码库的交互行为、历史提交记录等，来增强 Cursor 的能力。
代码写法需要兼顾“模型读者”吗？
主持人 Anthropic Alex:
我最近在网页内容领域看到一个趋势，人们开始试图优化页面以便于大语言模型（LLM）阅读和理解。你觉得在代码世界，会不会也出现类似的趋势？比如说，代码写法将不再只针对“人类读者”，而是要兼顾“模型读者”？
Lukas:
这个趋势其实已经开始了。比如 API 设计正在发生变化——我们不仅改内部版本号，还会显式地告诉模型这是新版 API，确保它能正确调用。而普通代码和内部库的写法也在改变，我们试图避免深层嵌套结构，尽量把代码结构保持在两层以内，这样模型理解起来会更轻松。
Jacob：
其实“干净代码”（clean code）的原则，既适用于人类，也适用于模型。你要避免重复、避免不必要的复杂结构，这对人和 AI 都很重要。未来，随着 AI 编码能力增强，我们能写出更多代码，那就更要注重代码的整洁性和美感。
主持人 Anthropic Alex:
说得很好，尤其是“品味”这个话题。我感觉有些人天生审美好一点，但大多数人还是靠经验，靠踩坑学来的。在 AI 参与代码创作越来越多的今天，很多人担心，这会不会让年轻程序员变懒，失去从零构建复杂系统的机会？你们怎么看这个问题？要如何在“AI 助力”和“保留工程师核心能力”之间找到平衡？
Jacob：
我觉得这些工具在教育层面也非常有价值，能帮助开发者成长。如果你对某段代码不理解，现在可以直接按 Command+L 问 Claude：“这是什么？怎么工作的？”它会一步步解释给你听。这种能力让你写出更多代码，确实会出现质量参差不齐的问题，但总体上，这是一个能显著提升门槛的强大工具。
Lukas:
代码质量很多时候来源于快速迭代——你犯错，修复，理解为什么失败，再改进。我认为 AI 模型极大地加快了这个反馈循环，让你更快地知道什么方法有效、什么不行。从长期看，这对初学者和有志于承担更复杂项目的开发者都是非常有益的。
CTO Aman：
我觉得接下来程序设计会如何演变会很有意思。未来很长一段时间内，我们仍然需要那些了解底层细节、能深入“草丛”的工程师。但我也在想，会不会慢慢出现一种新型开发者——他们并不掌握太多底层知识，却依然能高效地开发。我觉得现在阶段，你仍然需要理解大量细节，但随着时间推移，可能会出现一类主要在更高抽象层级工作的软件工程师。
也许未来开发者的“品味”会更像在做交互设计。比如你要构建一个类似 Notion 的应用，最终你无法完全把这事交给语言模型来做。你需要去表达：“当我进行某种交互时，我希望页面这样弹出来。” 也许你不需要具体写实现逻辑，但仍需要清晰地描述交互意图和系统大致行为——这其实也是一种编程方式。
如何在Cursor里集成最新的Claude模型
主持人 Anthropic Alex:
换个话题，我们来聊聊模型。等这个视频上线时，Claude Opus 4 和 Sonnet 4 已经发布了。想听听你们对新模型的看法，以及打算如何将它们集成到 Cursor 里？
CTO Aman：
我们真的非常喜欢这些新模型。第一次试用新版 Sonnet 时我们都挺震惊的。3.7 已经是非常优秀的模型，在“目标明确地解码”方面表现很强，但大家也知道它有些缺陷，比如有点过于积极。
主持人 Anthropic Alex:
就是太爱主动“做事”了（笑）。
CTO Aman：
对，比如它会主动修改测试用例。Sonnet 4 基本修复了这些问题，表现好得多。而且它的“智能程度”也明显跃升——我们见过一些模型也在“智能性”方面进步了，但还不如 Opus 3 的解码表现。而 Sonnet 4 则可以与其平起平坐，但价格却便宜很多。所以我们对 Opus 4 非常兴奋，觉得它会成为后台执行任务时的理想选择。
主持人 Anthropic Alex:
太好了！我们这次确实花了很多精力解决“测试编写”和“过度热情”这类问题，特别是reward hacking——模型为了拿到奖励信号，会尝试走捷径。这次我们把这种现象削减了大约 80%。
CTO Aman：
我一直挺好奇，3.5 Sonnet 是怎么诞生的？感觉它是 Anthropic 第一个真正意义上的“高质量代码模型”。
主持人 Anthropic Alex:
怎么诞生的？其实就是训练出来就很不错（笑）。说实话，从公司创立初期我们就知道，“让模型擅长写代码”这事非常重要，尤其是当你打算构建更多模型时。3.5 Sonnet 是我们第一次系统性投入资源来打磨代码能力，尤其是跨文件编辑、工具调用、长任务规划等“远距离代码能力”。我们把所有这些能力整合到一体，结果非常好，也为之后的模型定下了基调。
CTO Aman：
那你们是怎么平衡“代码能力”与其他方向的？比如 Opus 和 Sonnet 除了写代码，还有哪些重点领域？
主持人 Anthropic Alex:
代码当然是主要方向之一，但并不是唯一。我们发现，当模型在代码上表现得更好时，它们在复杂推理、多步骤任务、agent-style 的交互上也会同步提升。而这些能力对需要融合代码、信息检索、研究任务的应用场景非常有用。
总的来说，我们就是在不断推动模型能力的边界。当然我们会考虑安全性，确保模型输出对用户有帮助，且符合我们对 AI 应有行为的判断。但我们也希望向世界展示模型到底能做到什么，比如去年 10 月发布的 computer use（屏幕理解和操作）能力，这是另一个重大方向——模型直接阅读屏幕图像，并在 UI 上完成类似人类操作，而不是只靠 API 或工具调用。
还有一个我们特别重视的方面是“角色感”。Amanda Askew 是我们这方面的核心研究人员之一，专门负责Claude 的性格与人设打造。我们花了很多精力思考 Claude 应该给人怎样的感受、说话风格应该如何。毕竟它不仅是代码助手，还可能成为用户的倾诉对象、陪伴者。这影响我们对训练策略的很多决策。
CTO Aman：
那从 Anthropic 整体来看，你们是如何看待未来的发展方向？不管是软件工程领域，还是 AI 研究的长期演变——比如模型将如何增强、替代或重塑现有工作流？
主持人 Anthropic Alex:
我可以说说我个人的看法。就像我们之前聊到的，我不觉得我们是在“被取代”，而是因为现在有了能帮你完成很多“机械性敲代码”的模型，我们其实能做的事更多了。拿我自己举例，我大学是学计算机的，也做过软件工程工作。现在如果你让我做一道 LeetCode 题，模型肯定写得比我快、比我好——它就是比我强（笑）。
但有意思的是，我反而觉得自己现在能做的比过去更多。我可以用模型快速做出原型，迅速搭一个 demo，如果我想展示某个新概念，完全可以在几小时内做出个雏形。这种感觉非常赋能，而不是让人觉得自己被抛弃了。
而且我觉得，正因为我有过去写代码的经验，我能更好地“驾驭”这些模型。我知道它们哪里好、哪里要引导，如果我完全不懂编程，那我可能就不会知道怎么“用对”。——说到未来，我们来预测一个问题好了，两年后回来看这条回答可能会很有意思：
假设是 2027年1月1日，你们觉得那时世界上有多少代码是由 AI 生成的？而那时候开发者的“日常工作”又会变成什么样？
Jacob：
这就像问 1995 年的律师，“未来的法律文件会有多少是用文字处理器写出来的？” 答案是——几乎 100%。AI 将参与未来绝大多数代码的编写。
但即便如此，开发者的角色反而更重要了：你需要判断这段代码应该做什么，你需要有判断力、品味，你要能引导软件向正确方向发展。
CTO Aman：
说实话，我们现在在 Cursor 里就已经接近 90% 的代码由 AI 生成了。因为我们大量使用高阶功能，比如 Ask, MCC, 自动补全等等。而就算是你手动敲代码时，也往往是你敲几个字，Tab 自动帮你补完后面的 70%。所以即使你“在写”，其实也有大部分是 AI 在协助。
主持人 Anthropic Alex:
从“键盘打下去的字符数”来看，应该已经占比很低了。
CTO Aman：
没错。我觉得，软件开发的每一个环节，未来都会在某种程度上与 AI 结合。
主持人 Anthropic Alex:
你觉得我们会不会最终进入一个“按需生成软件”的世界？那时会是什么样子？
Jacob：
我认为我们会看到，很多原本不是开发者的人也开始写软件，比如销售人员以前不会写代码，但未来他们可以自己搭建一个仪表盘来追踪自己关注的关键指标。
这时候，“审美”就变得非常重要——你可以生成一个 dashboard，但你仍然需要决定它展示哪些数据，这个判断 AI 代替不了。
我们会看到更多人“造自己的软件”，但瓶颈在于：你能不能定义出一个独特的需求，而不是重复已有工具。
主持人 Anthropic Alex:
我特别喜欢的一个例子是：我们有个公关团队的同事，居然在修复 Claude AI 的生产环境 bug！他本身完全不是产品线的一员，突然跳出来提了一个 PR，我们当时都惊了，结果发现他用 Claude Code 这类工具就能修补代码了。
Jacob：
没错，他修的是正式代码库里的 bug（笑）。
主持人 Anthropic Alex:
这真的很厉害。这也说明——只要你有判断力和直觉，你就能做很多事。我觉得未来角色会变、工作样貌会变，但如果你能用这些工具做更多的事，那一定是件好事。
CTO Aman：
我觉得这条路未来会有很多“分支”。其中一个极端的版本是：你用的软件会根据你的使用方式实时改变。比如你用了某个功能觉得不爽，下一次它就自动改掉了。
你甚至不需要主动去改代码，系统会根据你交互中的行为自己适配，这就很酷。我不确定未来是不是所有人都想自己写软件，但“需要个性化软件”的人群可能是整个世界。
主持人 Anthropic Alex:
好，那最后一个问题吧：如果有一位优秀工程师在看这段视频，他/她正打算找下一份工作，犹豫要不要加入像 Cursor 这样的初创公司，或者去更大的平台，你们会对他说什么？
CTO Aman：
我觉得现在初创公司在吸引顶尖人才方面越来越有优势。像 Anthropic 或 Cursor 这样的团队，能吸引到非常棒的人才，这在大公司反而很难做到。
大公司当然也有优秀的人，但人才密度（talent density）低。而在一个小团队中，你能每天跟很多超棒的同事一起工作，大家都能碰撞出很强的能量。
你在构建改变世界的软件和模型，而你不是几千人中的一个小螺丝钉——而是几十人、甚至十几人里的一份子。这是非常有成就感的事。
主持人 Anthropic Alex:
真的太棒了！感谢你们的分享，这次聊天非常精彩。
CTO Aman：
谢谢你，谢谢大家！
