AnthropicCursor对谈实录程序员的工作方式正被AI重新定义

Anthropic × Cursor，会擦出什么火花？

这几天翻完了一场看似普通但内容密度爆表的访谈 —— Anthropic 请来了 Cursor 的三位核心成员来了一场高质量对话。

从 Claude 的进化、到 Cursor 的产品哲学、再到整个 AI 编程的未来走向，这场对谈基本把「写代码」这件事未来几年可能出现的变革路径，提前剧透了个七七八八。

如果你今天还在写代码、带团队、思考技术方向，或者单纯对 AI 编程的落地进展好奇，这半小时内容可以帮你提前看见 —— 我们和 AI 工具的关系，正在发生什么质变。

它讲的不只是 Claude 有多强，也不只是 Cursor 开发了什么新功能，而是回答了一个更为关键的问题：

当代码可以自动生成，我们的角色会变成什么？

01｜不只是 Claude 强，是 Cursor 太会用了

要说 Cursor 为啥能这么快出圈，访谈里说得很直白： 他们是最早一批「把模型真正用于生产级别多文件编辑」的团队。

换句话说，不只是 Claude 写得好，是 Cursor 敢真用，还用得狠。

Cursor 早期就把 Claude 3.5 Sonnet 拉进了自己的 IDE 里测试，发现不仅能写写函数，还能处理跨文件的逻辑修改，再配上自己训练的小模型做代码检索，硬是把 LLM 从“编辑器自动补全”拉成了“跨文件 PR 草稿生成器”。

之后的每一次 Claude 升级，Cursor 都第一时间集成、试错、试探边界，然后把发现的痛点，反过来改进 Cursor 本身。

比如 Claude 3.7 开始支持更复杂的 agent-style 操作，Cursor 马上就搞了 Background Agent —— 把代码改动丢给虚拟环境后台跑，跑完直接出 PR 草稿，哪怕你人在前台干别的，也能继续提速。

是的， Cursor 是用 Cursor 自己开发出来的。

如果说 Cursor 是一台 AI 编程的发动机，那么 Claude 就是燃料，而 Cursor 团队 —— 是真正的点火器。

02｜Agent 不只是新功能，是新范式

他们提到一个很有意思的事：Cursor 的功能不是一上来就开挂，而是呈现出一个渐进的「功能迭代」：

最熟悉代码时，用 Tab 补全速度最快；

文件内精修，用 Command K 区域改动；

多文件联动，则启动 Agent 模式打通逻辑；

如果懒得切换上下文，直接让 Background Agent 直接后台做完，给你 PR 草稿。

这不只是在推出新功能，而是在帮开发者形成一种新的“写代码”路径：从“动手做”到“调度 Agent 做”，从“盯着逻辑走”到“发指令后跳转验证”，甚至开始接受“并行多任务代码迭代”。

这无疑会倒逼我们的老程序员，开始在 IDE 里学习“提问”与“调度”能力 —— 甚至得重新定义什么是“熟练”。

未来的熟练工，不是背 API 的人，是会设计提示词流程、懂上下文控制、知道 agent 跑在哪、出什么结果、该在哪接手的人。

写代码不再是敲代码，而是组织代码产出的流程。

03｜写代码的未来，不是写，是验证

访谈中有一句话印象深刻：

“即使模型把代码写得再快，软件工程的最大瓶颈，马上会变成代码审查和验证。”

这是现在 Cursor 团队内部真正在意的事 ——

模型写代码 90% 没问题，难的是最后那 10% 是否“对”，对到不只是通过测试，而是能否真正对齐“你脑中的预期”。

这事太真实了。我们平时写代码，很多时候不是逻辑对不对，而是 ——

这段风格是不是和主代码仓库一致？

这段逻辑有没有别的地方已经实现过？

这个权限判断，是该自己写，还是用团队统一封装的方法？

而这些东西，往往不在代码里 —— 而在飞书、在 Lark、在脑袋里、在“我们一直就这么干”的潜规则里。

所以 Cursor 正在探索的一种方式是：构建“代码意图中间层”，比如用伪代码或语义图方式表达改动，再映射到真实代码中，这样能加快代码审查和验证的效率。

代码验证问题，未来解决不了就不是工程问题了，是产品问题、“人 + AI”协作问题，甚至是组织知识建模问题。

04｜Taste will matter even more

“随着模型越来越强，程序员的品味会变得前所未有地重要。”

这句话乍一听有点悬，但细想一下，现在写功能越来越快，很多时候你可以生成十种实现方式，模型也能跑通，但 ——

哪一种更高效？

哪一种跟现有系统耦合更低？

哪一种更便于调试和未来拓展？

这些判断，拼的不是知识，是经验、品味、对复杂系统演化路径的直觉。

而这种品味，是 AI 给不了的，是你撸了足够多代码之后才能领悟出来的。

未来能驾驭 AI 编程的人，可能不是提示词写得好的人，而是知道什么时候接手、什么时候打断、什么时候用哪个模块的人。

毕竟，AI 会把“能不能写”变成“谁写得好看”。

结语

程序员、产品经理、技术领导者，在未来 AI 编程的链条里会怎么变？

Claude、Cursor、Agent —— 是工具，也是变化的触发器。

我把这次访谈的 中文翻译版 放在文末了，感兴趣的小可爱可以细读。

附录｜访谈翻译全文

点击 阅读原文 查看原视频。

以下为访谈逐字整理 + 中文翻译（翻译由 Claude Opus 4 提供支持），供参考。

开场介绍

Jacob： 我觉得软件生产的方方面面都会以某种方式融入AI。

Alex： 非常高兴今天能邀请到各位。我期待这次对话已经有一段时间了。如大家所知，我是Alex，在Anthropic负责Claude关系管理。

Lukas： 我是Lukas，在Cursor负责智能体系统的工作。

Aman： 我是Aman，是Cursor的创始人之一，负责机器学习和检索系统。

Jacob： 我叫Jacob Jackson，在Cursor负责机器学习。

Alex： 我对这次对话感到非常兴奋，想聊聊Cursor、你们正在构建的产品，以及你们是如何使用Claude的。

Cursor的增长

Alex： 对任何关注AI行业的人来说，Cursor度过了重要的一年，这是显而易见的。你们在短短一年多时间里，营收已经超过3亿美元。相当惊人，现在有数百万开发者在使用Cursor。在你们看来，是什么发生了变化？今天的Cursor与一年前相比有什么不同？

Aman： 是的，我认为有几个重大变化发生了。考虑到当前语言模型的能力水平，以及你能用它们做多少事情，一直存在着巨大的潜力。我认为Cursor可能是编程领域最早能够通过多种不同功能来缩小这个差距的公司之一。

与此同时，你也看到这些模型在编程方面变得越来越强大。我认为3.5 Sonnet是第一个明确的例子，它在编程能力上实现了阶跃式的提升。

在那之前，Cursor主要在代码补全、预测你的下一次编辑等方面发挥作用。仅凭这一点，我们就增长得相当快，然后是单文件内的编辑功能。但当你将像3.5 Sonnet这样的模型的智能与我们用于检索的其他定制模型相结合，再应用这个大型模型所做的编辑时，你就获得了进行多文件编辑的能力。我认为这是导致Cursor被大规模采用的关键性突破。从那时起，就是模型不断改进和我们努力在底层不断优化的结合，看看能把这些模型的能力推进到什么程度。

模型的进化

Alex： 这是一个自然的进展过程，还是当3.5 Sonnet第一个版本发布时，你们突然意识到"天哪，现在我们可以做所有这些以前不可能的事情了"？具体是什么样的情况？

Jacob： 确实感觉有些渐进。虽然模型质量有这些阶跃式提升，但你在之前的最先进模型中就能看到它的迹象。事实上，我们在评估这些模型方面一直做得不太好，因为我们使用它们的方式与将其投放到世界上让其他人使用时非常不同。

但随着时间推移，每个新发布的模型在推理能力和执行更多智能体类型的编程任务方面都越来越好。然后需要大量的调试和尝试，看看什么有效，什么失败。

是的，我认为Sonnet可能是第一个让我们能够真正让多文件交互很好地工作的模型。从那时起，出现了许多阶跃式改进，包括工具使用功能，对吧？然后你就可以让这些模型在编辑器中像真正的智能体一样行动了。

用Cursor构建Cursor

Alex： 嗯，我明白了。所以新模型的进展、新能力随时间的出现，允许进一步的调试和探索，然后在某种程度上反馈到你们的产品中，让你们能够构建新功能。这很有趣，也引出了我想问的下一个问题：我听说过很多关于你们团队如何使用Cursor来构建Cursor的故事，它处于这种自我改进的递归反馈循环中。首先，也许你可以深入介绍一下这是什么样子的？在日常工作中，当你们在Cursor内部构建新功能时是什么样的？

Lukas： 是的，我认为这很大程度上取决于每个员工的个人使用场景，也很大程度上取决于你正在开发产品的哪个部分以及该部分处于什么阶段。

所以我认为，对于最初搭建某个代码库或某个新功能，使用Agent功能来启动它非常非常有用。然后可能使用思考模型来审视你可能面临的个别问题。对于进行非常精确的编辑，我认为Tab功能用得很多。

当初次接触一个可能不太熟悉的代码库时，会大量使用问答功能和搜索功能。我认为这也是Claude 3.7和3.5擅长的地方——在代码库中进行研究，弄清楚某些组件是如何相互作用的。

Alex： 我明白了，所以使用这些功能来探索你的代码库让过程变得更容易，然后你在使用这些功能时学到"哦，这个领域有不足，我们应该去改进它"。

Lukas： 是的，更容易。我认为Cursor非常注重解决我们自己的问题，找出我们在解决问题时遇到困难的地方，让Cursor变得更好，然后找出我们能做什么，进行大量实验。我们非常有这样的理念：每个人都可以尝试新事物，尝试向产品添加新功能，然后看看内部如何使用它们以及收集什么样的反馈。

Alex： 你认为在更宏观的层面上，成为自己内部最好的客户有优势吗？

Aman： 我认为百分之百有优势。我认为这就是我们能够在构建新功能方面快速行动的原因，然后抛弃那些明显不起作用的东西，因为我们可以对自己非常诚实，是否觉得它有用，而不必将其发布给用户，跟踪人们如何使用它，然后再决定是否继续推进某个功能。我认为这极大地加快了构建功能的迭代循环。

功能谱系

Jacob： 是的，回到我们如何使用AI编程的整体情况，感觉公司内部在不同人如何使用它方面有很多多样性。我认为首先在你正在做的工作类型上有所不同。

比如，有许多人会在他们非常熟悉的代码库部分工作。在那种情况下，当你把一切都记在脑子里时，通过输入代码来传达意图往往更快，Tab功能在这时真的很有用，因为它能加快你的速度。

但当你在不太熟悉的地方，或者需要编写大量代码时，你可以把很多工作，甚至一些推理工作交给这些模型。然后，当你到了真正不熟悉的地方，就像Lukas描述的那样，当你进入一个新的代码库时，使用这些模型会带来巨大的阶跃式改进。我们看到的是，随着时间推移，随着模型变得更好，随着Cursor使用这些模型变得更好，当你更多地处于心流状态、对代码库有更多了解时，你的效率会越来越高。

Alex： 所以某个功能何时最适用于你的使用场景是有变化的，这在某种程度上就像一个功能谱系。

Jacob： 是的，就像谱系的一端是Tab，用于当你完全掌控并知道自己在做什么的时候；然后是Command K，你在编辑单个给定区域，可能是整个文件；在另一端你有Agent，它非常适合编辑多个文件；在最远端，你有我们一直在开发的后台智能体，它基本上可以用于完成整个PR（拉取请求）。

关于后台智能体

Alex： 你们刚刚发布了后台智能体的预览版。什么是后台智能体？

Aman： 我认为很明显，模型在完成端到端任务方面越来越好，但它们还没有达到100%的准确率，我认为要达到100%还需要一段时间。

所以加速开发者的方式是让他们并行地做这些事情。但不同于让它在后台运行，然后在GitHub中生成一个你去查看的PR，如果它只完成了90%，你会想要介入并接管控制权完成剩下的部分，然后你想使用Cursor的功能来做到这一点。所以真正能够在后台和前台之间快速切换是非常重要的。

我认为我们还处于这个功能的早期阶段，我可以想象有很多有趣的方式，例如能够同时操作三个或四个更改，然后快速将它们推到后台，再将它们移到前台。看看这如何改变人们使用Cursor和一般开发软件的方式将会很有趣。

Lukas： 我们基本上将后台智能体视为一个新的基础原语，我们可以在许多不同的地方使用它。当前展示它的方式相当直接，你可以获得一个提示，将其推送到后台，然后它独立地进行迭代。但可以有更多的集成方式来生成这些任务，我认为你可以从中创造很多产品。

Alex： 所以这是把你的代码库放在虚拟机中，还是到底发生了什么转换？

Lukas： 正是如此，是的。我们有足够小的独立环境，已经安装了所有开发环境实用程序，然后智能体可以使用这些，它拥有所有可用的VS Code扩展，通过这些它可以获得各种功能。

未来瓶颈

Alex： 我知道我们正在见证这种异步任务、后台任务的趋势，从编码到研究等许多不同的领域。在你看来，随着这种进展，我们可能有数千个这样的智能体在运行，你可以看到整个智能体团队在后台攻克一个问题。那个未来会是什么样子？

Jacob： 我认为你将遇到的下一个瓶颈是软件验证、代码验证。模型在生成和编写大量代码方面变得非常非常好，但假设开发者花费——我会抛出一些随机的数字——但假设30%的时间编写代码，30%的时间审查代码，70%的时间编写代码。如果你完全解决了编写代码的问题，你仍然没有真正将软件工程的速度提高超过三倍。

所以我认为我们需要弄清楚如何让人们更容易审查代码，以及如何确信智能体所做的更改不仅仅是正确的——因为"正确"可能是模糊的，对吧？它可能只是在你指定的事情中，规格说明不够充分，实际上它做了即使是最好的人类程序员也可能做的最好的事情，但实际上你脑海中想的是什么。所以让这个过程对你来说变得更好，我认为将会非常非常重要。这也是我们真正感兴趣的事情。

Alex： 在这方面有什么早期的想法吗？

Jacob： 我认为公司里的各种人有一些想法在流传。我们的CEO Michael真的非常喜欢的一个想法是在代码库的不同表示形式中操作。所以也许它看起来像伪代码，如果你能以这种真正简洁的方式表示更改，并且你有保证它能干净地映射到真实软件中所做的实际更改，那应该会大大缩短验证时间。

但这只是一个可能的路线。我认为，所谓的"氛围编码"（vibe coding）之所以经常有效，是因为验证过程真的很容易，因为它只是玩弄软件，对吧？你做了更改，然后实际操作你构建的任何软件。我认为对于真正的生产代码库来说，这将会非常困难，攻克这个问题真的很重要。

大型生产代码库的挑战

Alex： 这是一个关于独立的氛围编码与拥有数百万行代码的生产代码库之间差异的好问题。你们如何看待这两者之间的差异，以及我们在使用当前模型处理它们方面处于什么位置？

Aman： 我认为这是我们在后台智能体方面思考了很多的事情。因为有些事情真的很简单，显然这些模型应该很容易做到——比如"我这里有这个测试，测试当前失败了，你能修复代码使其通过吗？"就像，好吧，我们如何实现这个？

嗯，模型需要能够运行测试。如果你有一个非常简单的代码仓库，那很简单。但当你开始处理这些更大的企业级代码库时，正确设置依赖项以便模型可以运行测试可能会变得复杂。

但这是我们在后台智能体方面思考了很多的事情——如何让开发者创建这个环境的过程变得简单直接，让智能体可以运行测试，然后使其可重复，这样你就可以对其进行快照，当你的代码状态发生变化时可以快速更新它。这解锁了在后台启动虚拟机的能力，让模型进行实验，其中一些会让测试通过，一些不会。然后最终作为开发者，你只需要关心它成功的情况。那里有很多基础设施和很多用户体验需要正确处理。

Jacob： 是的。然后我认为还有其他基本问题。所以一种方法是让模型尝试通过测试，对吧？这就是你如何保证某种正确性的方式。但是对于这些大型代码库，你经常处理的东西几乎看起来像它们自己的语言，它们在某些语言中有这些领域特定语言（DSL），一切都以这种特定的方式完成，它真的分散在数百万个文件中，这可能是数亿个令牌，也许更多。

我们已经做了许多事情来大幅改善这一点，包括训练检索模型，然后集成其他上下文来源。例如，你可以想象在你最近所做的更改中有很多丰富的信息，当编辑你的代码时，它表明你正在努力实现什么。你团队中其他人在你的代码库中所做的更改可能包含丰富的信息，特别是最近的更改，可以将这些用作提示。但我确实认为这仍然是一个真正困难的基本问题——仅仅给模型访问真正好的检索功能，对于让模型真正理解代码库来说感觉是不够的。我认为这是我们真正有兴趣解决的问题。

Alex： 嗯。可能通过某种记忆加长上下文的组合，还有其他方法。

Jacob： 是的。我认为记忆是人们采取的一种有趣方法，让模型从你的使用中学习，但它也感觉像是性能的小幅提升，相对于我们需要达到的地方以获得在大型代码库上表现出色的系统，它感觉相当原始。

Lukas： 是的，大型代码库不仅仅是让测试通过，还涉及以正确的方式做到这一点。比如查看现有代码并使新代码与之匹配，将其带入正确的结构，正确使用所有指导原则。我们一直在努力通过Cursor规则、通过集成不同类型的上下文等方式来实现这一点。

Jacob： 是的，就像我可以从头开始编写一个防抖函数并使用它，这会让测试通过，但这不是正确的方法。你应该使用现有的防抖函数之一，也许代码库中使用了三个或四个防抖函数。你如何知道使用哪个是正确的？也许有人知道的唯一原因是因为他们在Slack上给某人发消息说这是你应该采用的方法。所以我认为，对于极其庞大的代码库，解决这些问题变得非常非常困难。

Alex： 这很有趣。所以组织知识也存在于代码库本身之外，这在某些决策中有时起着重要作用，特别是当你在操作大型代码库时。

Jacob： 是的。我不认为这是今天的瓶颈，但我认为如果你解决了——比如如果你让模型在了解代码库方面变得完美——我认为你会立即获得可能5倍或10倍的改进，但你不能走得更远，因为现在它完全受到瓶颈的限制：它对这些从未在PR和代码的实际状态中明确提及或显示的事物了解多少。

Aman： 然后还有来自业务方面、销售等的外部考虑。这些必须被带入Cursor才能使其工作。

Alex： 对。所以Cursor的某个未来版本必须插入更多的系统和工具。

Jacob： 是的。要明确的是，我认为相对于其他事情，这还有一段路要走才能变得真正关键。我认为我们仍然有很长的路要走，仅仅使用用户的交互，比如他们代码库的细节和提交记录，就能让Cursor变得更好。

代码将如何演变

Alex： 我开始注意到的一件有趣的事情，至少在网页和内容方面，是人们现在试图思考如何优化页面以供LLM阅读和浏览。你认为我们会在代码方面看到类似的情况吗？代码可能会改变它通常的编写方式和样子，如果你主要是为人类审查者和在代码库中工作的人类编写，转而为模型编写？

Lukas： 我认为这已经完全是这种情况了。我的意思是API设计已经在调整，以便LLM对此更加舒适。例如，不仅改变内部版本号，而且让模型非常明显地看到这是某个软件的新版本，只是为了确保API被正确使用。

我认为同样也适用于普通代码库和内部库，比如以一种不必经过n级交互而可能只需经过两级交互的方式构建代码，使得LLM模型在处理该代码库时表现更好。

Jacob： 对。但我认为最终，当你希望代码能被人和模型阅读时，干净软件的原则并没有那么大的不同。

你知道，当你试图编写干净的代码时，你想要不重复自己，不让事情变得比需要的更复杂。这对模型和人来说同样重要。我认为代码品味和什么是不比需要更复杂的干净解决方案实际上会变得更加重要，因为随着这些模型变得更好，编写越来越多的代码会变得更容易，所以以有品味的方式构建它会变得越来越重要。

在自动化中保持工程技能和质量

Alex： 这是关于品味的一个很好的观点。品味是这样一种东西，我觉得也许有些人天生就比其他人有更多的品味，但通常你通过经验培养品味，学习什么有效，看到失败和成功。

在一个我们让AI编写越来越多代码的世界里，有些人真的反对，说"哦，你会让程序员变懒"，或者"你不会给初级开发者一个机会去学习在大型代码库中工作实际上是什么样子"，做所有这些事情。

你如何看待平衡这种自动化或在这种情况下的协助，与保持软件工程师必须经历的核心工程技能、那些试炼和磨难？

Aman： 我认为这些工具在教育方面也非常好，它们可以帮助你成为一名优秀的程序员。你知道，如果你对某些东西如何工作有疑问，如果你想要解释某个概念，现在你只需按下command L并询问Claude："这是什么？它是如何工作的？你能向我解释一下吗？"我认为这非常有价值。

它确实使编写更多代码和做更多事情变得更容易，这可能导致更高和更低质量的代码同时存在。这是真的，但我认为总的来说，它是一个非常非常强大的工具，将提高整体标准。

Lukas： 我认为质量很大程度上来自快速迭代、犯错误、弄清楚为什么某些事情会失败。我认为模型大大加速了这个迭代过程，实际上可以通过这种方式让你更快地学习什么有效，什么无效。所以我认为从长远来看，对于刚开始的开发者来说，这是一个超级有用的工具，可以处理越来越大的项目，并弄清楚什么有效，什么无效。

Jacob： 是的，我认为看到编程如何演变会非常有趣。我认为在很长一段时间内，你仍然需要那些了解细节、能深入细节的工程师。

我想知道你会在多大程度上开始看到现在学习编程的人不知道许多细节但仍然相当有效。我认为今天你仍然需要知道很多细节。我认为随着时间的推移，你可能会有一类软件工程师需要知道很少的低级细节，仍然在更高级别上操作，也许看起来更像是思考品味方面——比如更多的是用户体验品味，对吧？

比如说你试图构建类似Notion的东西。归根结底，我不认为你可以将整个事情外包给语言模型。你需要描述："好吧，当我做这种类型的交互时，我期望它以这种特定的方式弹出"，对吧？也许你不必深入到编写纯软件来实现这一点的细节，但仍然要描述这些交互，描述这个东西大致的工作方式。那是一种编程形式。

Claude 4模型

Alex： 稍微转换一下话题，关于模型的话题。所以我们最近——当这个视频发布时，Claude Opus 4和Claude Sonnet 4将已经向世界发布。很想听听你们对新模型的看法，以及你们如何开始考虑将它们集成到Cursor中。

Jacob： 我们真的很喜欢新模型。我认为我们在试用新的Sonnet时相当震惊，因为我认为3.7是一个很棒的模型。它在智能体编码方面表现更好，但每个人都知道它有这些缺陷，对吧，它可能有点过于热切——

Aman： 喜欢做很多事。

Jacob： 是的，它确实如此。有时会改变测试，让它们通过。我们发现Sonnet 4有效地修复了所有这些问题，它好得多，然后智能也有了很大的提升。你已经看到了其他在智能方面有所提升的模型，可能在智能体编码方面不那么强大，但比如O3就是一个例子，我们发现它与之不相上下，尽管是一个便宜得多的模型。

所以我们对Opus非常兴奋，因为我们认为它将是一个在后台使用的绝佳智能体。

Alex： 是的，听到测试编写和过度热切的问题是我们试图用这些模型密集解决的事情，这真是太棒了。还有奖励黑客的概念，其中模型会找到某种方式基本上走捷径来获得强化学习中的最终奖励。

所以我们做了很多工作来减少这种情况。我认为我们在这些新模型中将其减少到了大约80%。我真的很好奇3.5 Sonnet是如何产生的，因为那感觉像是第一次真正的突破——"这对Anthropic来说是一个真正优秀的编码模型"。

Alex： 它是如何产生的？

Jacob： 我们训练了它。就是这样，它很好。

是的，我认为我们已经知道有一段时间了——我的意思是可能从公司成立以来，我们就想让模型在编码方面真的很好，这对你做的其他一切似乎都很重要，特别是当你制作更多模型时。

3.5 Sonnet是——我不会说——我认为3-Opus也是一个非常好的编码模型，特别是在它的时代。但3.5 Sonnet是我们第一次真正投入强大的专门努力："嘿，让我们让这些模型擅长编码"，但不仅仅是专门的编码，还有这种更长期的编码，它必须做这些事情，比如你在对话早期提到的在不同文件上进行编辑，去执行这里的命令，调用工具，然后去其他地方进行更改。

那是我们能够将所有这些东西组合在一起的第一个模型，我认为它的表现真的很好，为我们未来的模型奠定了基础。

Anthropic模型开发

Alex： 你们如何看待代码与你们希望Sonnet和Opus擅长的其他领域？

Jacob： 我的意思是代码是主要领域之一，但我认为这不是唯一的领域。我认为你看到模型在代码方面变得真正好，在推理、采取许多行动和以这种智能体方式工作方面也变得更好，有很好的迁移效应。

当你处理可能混合代码但也必须从其他地方检索知识或进行研究的应用程序时，这种延续性非常好。总的来说，我们致力于尽可能地推动我们模型的前沿。当然，我们在安全方面有一些考虑，确保模型符合你作为用户的期望，以及我们认为模型应该做什么。但总的来说，我们想继续推动这些模型能做什么的极限，向开发者和世界展示这就是模型的能力。

所以像计算机使用这样的功能，当我们在10月推出时，那是我们真正推进的另一个方向——模型如何能够很好地实际导航主要是人类界面的东西，对吧？所以它不在API或工具调用或类似的世界中。它实际上只是像人类一样查看图像，然后必须将动作指向该屏幕。

我们对这些模型的性格也有很大一部分思考，正如现在所知的，Amanda Askell是我们在这项工作上的首席研究员之一，塑造Claude的性格。我们对Claude应该感觉和听起来像什么，以及AI在某人生活中扮演真正重要角色意味着什么，投入了大量的思考和考虑。

不仅仅是作为一个编码智能体，而是作为他们的知己，以及你将花费大量时间与之交谈的实体。所以这也真正影响了我们围绕这些模型及其训练方式所做的所有决定。

Alex： Anthropic作为一个整体如何看待事情的发展方向，无论是在软件工程方面，还是在研究方面——比如这些模型将增强、替代多少这类工作？

Jacob： 是的，可以在这里发表个人意见。所以我个人认为我们不会替代。正如我们之前讨论的，现在你可以做更多的事情，因为你有模型可以为你做所有这些——基本上为你输入代码的细节工作。

我也在自己身上看到了这一点。比如我在大学学习计算机科学并做软件工程，现在我觉得我处于这样一个阶段：模型在生成代码方面比我更好。比如如果我只是想做一个LeetCode问题或类似的事情，在一个受限的环境中，模型必须编写代码，它会打败我。但我觉得我可以做的比以往任何时候都多。

我可以制作任何东西的原型。如果我想展示一个新概念，我可以超级超级快地启动演示。从这个意义上说，它感觉非常赋能，而不是剥夺或轻视我一直在做的事情。

这与我的感觉相似，就是因为我有过去软件工程的知识，我实际上可以更好地利用它。我可以使用模型，我可以比我对代码一无所知时更进一步地推动它。也许在这方面进入更有趣的未来推测——

未来可能的样子

Alex： 我想问一个也许是实际的问题，几年后我们可以回到这个问题，看看我们的表现如何。2027年1月1日，那是从现在起不到两年的时间？你认为有多少百分比的代码将由AI生成？接下来，现在认为自己是开发者的人的日常生活是什么样的？

Aman： 我认为这类似于回到——比如说在我出生之前，但你知道，1995年，问一位律师：在未来有多少百分比的法律文件将由文字处理器生成？答案是100%或接近100%，因为AI将参与几乎所有编写的代码。

但你作为律师或开发者在理解代码需要做什么、有品味和指导软件做什么方面的角色将比以往任何时候都更重要。

Jacob： 我的意思是在Cursor已经可能是90%以上，但那是因为很大一部分使用了更高级别的功能，如Agent和Command K等等。但其中很多是你在输入，然后Tab会在你输入时完成70%的工作。所以在你实际手动进行的情况下，Tab仍在进行大部分更改。所以实际输入的字母百分比非常非常低。但我认为生产软件的每个方面都会以某种方式被改变以使用AI。

Alex： 你认为我们会达到一个基本上按需提供软件的世界吗？那会是什么样子？

Aman： 我认为你会看到人们构建软件——组织职能中的人们构建软件，他们以前不构建软件。你知道，比如销售人员以前不会构建自己的工具，现在将构建，例如，仪表板来跟踪对他们重要的内容。

回到品味如何变得比以往任何时候都重要——你知道，现在你可以构建仪表板，但你仍然需要决定仪表板将显示什么指标。它不会阻止你必须决定这一点。

我认为你会看到更多的人构建自己的软件，但它将受到瓶颈的限制：你想用软件做的独特事情没有被现有需求正确服务。

Alex： 我喜欢告诉人们的一个例子是，我们有一个通信团队的成员，他实际上一直在向Claude.ai提交错误修复，这绝对是疯狂的。

比如他在组织的完全不同部分，他根本不接触产品，但他带着PR出现，要求审核，你就想："你在做什么？"就像，是的，他正在使用Claude代码或某个编码工具，以Claude作为基础模型来修复生产代码库中的错误。

我认为这也很棒。它与这种一般的理念联系在一起：嘿，如果你有品味，如果你有好的直觉，你就能做很多事情。这就是我看待世界继续发展的方式。

我认为事情会改变，角色在五年、十年后会看起来很不一样，但总的来说，我非常赞成：如果你能用这些东西做更多，这通常总是一件好事。

Jacob： 是的，我觉得这可能采取很多有趣的路径。一个是完全即时按需的软件，我正在使用我自己版本的某个应用程序，就在我使用它时，你知道，我不太喜欢这种交互，它就为我改变了。

这是你可以想象的一个疯狂的未来，它甚至不是你主动做的，而是基于你与它的交互，你正在使用的软件，无论是什么，都会改变以适合你。这是一个很酷的潜在前进路径。我不知道世界上是否每个人都想要——我不知道想要构建自己软件的人的总规模是否那么大。但我认为可以从适合他们需求的软件中受益的人可能是整个世界。

给工程师的建议

Alex： 好吧，也许最后一件事来结束这个话题。对于所有观看这个的人，如果你是一个有才华的工程师，你正在考虑你的下一步行动，或者你想更多地参与这个行业，你正试图决定是去一家更大的公司还是加入一个更快节奏的初创公司，比如Cursor或Anthropic，你会告诉处于这种情况的人什么？

Jacob： 是的，我认为像Anthropic和Cursor这样的初创公司现在在获得真正优秀的人才方面有优势。当你在一家更大的公司时，很多人——世界上很多最优秀的人觉得这不太令人兴奋，对吧？

有些人确实觉得兴奋，当然大公司也有优秀的人，但人才的密度往往要低得多。在初创公司，你可以获得这种真正高的人才密度，这使得与一群其他优秀的同事一起工作真的很愉快。

你可以在这个令人难以置信的小团队中从事真正有影响力的事情，对吧？构建一个产品，构建改变世界编写软件方式的模型。你可以成为从事这项工作的几十人、几百人或几千人中的一员，这真的很酷。

Alex： 是的，太好了。好吧，谢谢你们。这是一次很棒的对话。

Jacob： 谢谢你。