从 Cursor 刷屏说起：为什么 AI Coding 是一个巨大的机遇？

Question

从 Cursor 刷屏说起：为什么 AI Coding 是一个巨大的机遇？

szwnba opened this issue 24 days ago · comments

Johnson zhang commented 24 days ago

💡 写在前面：最近 Cursor 刷屏，周日的早上，被 @泛函 激发，我用 Cursor 在 10 分钟写了一个「Emoji 的 AI 翻译器」，（10分钟还包括了注册硅基流动，用它的 API 调 Llama）。无比感叹！

整个过程中，我能强烈感觉到 Cursor 是一个 Day 0 开始就思考如何成为 AI Native 的 IDE，思路和交互都很丝滑。

接下来，要成为牛逼程序员，恐怕最重要的不再是「不断学习的能力」，而是「克服对代码恐惧的能力」。

greylock 在5月写过一篇非常好的讲 AI Coding 的综述文章。感谢 @庄明浩转发分享，「十字路口」编译分享给大家。

前提是：创造出高保真、可靠的 AI ，使之用于代码生成和工程工作流。

编程等工程任务非常适合 AI 增强或替代，原因如下：

(i) 编码本质上要求工程师将问题分解成更小、更易管理的任务；
(ii) 有大量现有的训练数据；
(iii) 任务需要判断力和基于规则的工作相结合；
(iv) 解决方案利用可组合的模块（开源软件库等）；
(v) 在某些情况下，工作成果可以通过经验测试其正确性。这意味着可靠准确的 AI 编码工具可以提供可量化的价值。

鉴于这些因素，仅在过去一年里，AI Coding 工具的尝试就呈爆炸式增长。但仍有许多悬而未决的问题，关于必须解决哪些技术难题才能制造出在生产环境中与人类工程师一样好（或更好）的编码工具。

在这篇文章中，我将阐述我们看到的创业生态系统中的三种方法，以及这些工具面临的三个开放性挑战：

我们如何创造更强大的上下文感知能力？
我们如何让AI agents在端到端编码任务中表现得更好？
拥有特定于代码的模型是否会带来长期的差异化？

在过去的一年里，我们看到创业公司采取了三种方法：

AI copilots 和 chat 界面，与工程师在工具中并肩工作。
能够替代工程工作流程的 AI agents，通过 end-to-end 端到端执行工程任务。
特定代码的基础模型。这些是用代码特定数据训练的定制模型，并与面向用户的应用程序垂直整合。

即使在回答这些首要问题之前，我们相信上述每种方法都能在短期内带来有意义的影响。让我们仔细看看行业地图：

如今，绝大多数 AI coding Startup 都采用IDE内的 copilot 或 chat 界面的形式来增强工程工作流程。

虽然像Tabnine这样的公司多年来一直在开发代码助手，但 AI coding 工具的重大时刻是在2021年GitHub Copilot发布时到来的。从那时起，我们看到了大量针对工程师各种工作的创业公司涌现。

找到市场的创业公司正在针对围绕代码生成或代码测试的工作流程。这是因为：

它们是工程师工作的核心部分
它们可能只需要相对较少的上下文就能足够有用
在大多数情况下，它们可以在单一平台内捆绑
在可靠性稀缺的世界里，将输出直接放在用户面前（即在IDE中）允许他们对任何需要的修正负责

房间里的大象是挑战GitHub Copilot的难题，后者已经拥有相当大的分发和心智份额（恭喜**Devin[1]**刚刚获得了与微软的合作）。创业公司正在通过寻找差异化的切入点来解决这个问题。例如，Codeium采取企业优先的方法，而Codium则从代码测试和审查开始，并从那里扩展。

我们也相信，针对代码重构、代码审查和软件架构等任务的工具有很大的机会。这些可能更复杂，因为它们不仅需要在代码内更大范围的理解，还需要理解不同文件之间的知识图谱、对外部库的了解、对业务背景的理解、软件的最终使用模式，以及复杂的工具选择。

无论切入点如何，我们在这一层面看到的一个反复出现的挑战是如何获取相关上下文来解决公司代码库中更广泛的任务。具体如何做到这一点是一个开放的问题，我们将在本文最后一节探讨。

如果增强工程工作流程是有价值的，那么更大的机会是弄清楚哪些工作流程可以完全被取代。

能够端到端执行工程任务的 AI Coding 产品 - 可以在人类工程师做其他事情时在后台工作 - 将创造全新水平的生产力和创新。远远超越 AI copilots， AI copilots 可以将我们从销售工具的领域带入销售劳动力的领域。在编码 agents 变得非常优秀的世界里，你可以让一个人类同时监督多个" AI 工程师"。

AI agents 的基本能力不仅仅是预测代码行中的下一个词。它需要将这种能力与执行复杂任务的能力结合起来，这些任务可能涉及数十个步骤，并且像工程师一样从用户的角度思考产品。例如，如果被要求修复一个bug，它需要知道bug的位置、问题的性质、它如何影响产品、修复bug可能导致的任何下游变化，以及更多信息，然后才能采取第一个行动。上下文必须来自诸如摄取Jira票据、更大块的代码库和其他信息源等方面。能够编写详细的代码规范和准确的代码规划将成为采用 AI 工程师的核心。

我们在这个领域看到的公司和项目包括（但不限于）Devin、Factory、CodeGen、SWE-Agent、OpenDevin、AutoCodeRover、Trunk等。

那么问题是：需要做什么才能让 agents 能够端到端完成更大比例的任务？这个问题在我的开放性问题部分得到了解答。

一些创始人认为，为了在代码应用层面建立长期的差异化，你需要拥有一个支持它的特定于代码的模型。

这不是一个不合理的建议，但似乎有一些开放性问题使其他创业公司远离这种资本密集型方法 - 主要是不清楚特定于代码的模型是否会被基础模型层的改进所超越。我将在开放性问题部分进一步讨论这个话题。

首先，让我们回顾一下，大多数基础LLM并不是专门在代码上训练的，许多现有的特定于代码的模型，如CodeLlama和AlphaCode，是通过取一个LLM基础模型，给它数百万个公开可用的代码点，然后针对编程需求进行微调而创建的。

注：时间线仅显示部分特定于代码的模型和被广泛用于编码用例的LLM

如今，像Magic、Poolside和Augment这样的创业公司正试图更进一步，通过生成自己的代码数据并使用人类对编码示例的反馈来训练自己的特定于代码的模型（Poolside称之为"基于代码执行反馈的强化学习[2]"）。这个理论是，这样做将导致更好的输出，减少对GPT-4或其他LLM的依赖，并最终创造最持久的护城河。

这里的核心问题是一个新团队是否能超越前沿模型的改进速度。基础模型领域发展如此之快，如果你尝试深入研究特定于代码的模型，你就面临着在你的新模型完成训练之前，一个更好的基础模型出现并超越你的风险。考虑到模型训练的资本密集性，如果你在这个问题上判断错误，就会有大量的时间和金钱风险。

我知道一些团队正在采取（非常吸引人的）方法，即在基础模型之上对特定任务进行特定于代码的微调，这样可以受益于基础模型的进步，同时提高代码任务的性能 - 我将在开放性问题3中详细讨论这一点。

无论采取哪种方法，都需要解决一些技术挑战，以解锁具有低延迟和良好用户体验的可靠代码生成工具：

我们如何创造更强大的上下文感知能力(context awareness)？
我们如何让AI agents在端到端(E2E)编码任务中表现得更好？
拥有模型和模型基础设施是否会导致长期的差异化产品？

开放性问题1：我们如何创造更强大的上下文感知能力？

上下文问题的核心在于某些编码任务需要工程师正在工作的开放文件之外的信息和上下文，这些信息和上下文不能简单地通过增加上下文窗口大小来访问。

从代码库的不同部分（甚至是外部）检索这些信息不仅具有挑战性，还可能增加延迟，这在即时自动完成的世界中是致命的。

这为那些能够准确和安全地找到并摄取编码任务所需上下文的创业公司提供了巨大的机会。

目前，有两种方法来做到这一点：

持续微调：我听客户说过"我希望一家公司能在我的代码库上安全地微调他们的模型"。虽然理论上对自己的代码库进行模型调整可能有意义，但实际上有一个问题：一旦你调整了模型，它就变成静态的，除非你在进行持续的预训练（这是昂贵的，并可能有延续现有偏见的效果）。没有这个，它可能在有限的时间内表现得很好，但它实际上并没有随着代码库的演变而学习。话虽如此，微调正变得越来越容易，所以定期对你的代码库进行模型微调可能是可行的 - 例如，Codeium**声明[3]**他们确实提供"客户特定的微调"，但他们明确表示应该谨慎使用，因为最佳方法是上下文感知RAG。
上下文感知RAG：RAG可能是目前提高上下文的最佳可用方法，通过检索代码库的相关片段。这里的挑战是在非常大的代码库中的检索排名问题是非平凡的。像Agentic RAG和RAG微调这样的概念正在获得普及，可能是更好地利用上下文的有力方法。例如，Codeium在一篇**博客文章[4]**中分享了他们如何使用教科书式的RAG，并辅以更复杂的检索逻辑，爬取导入和目录结构，并将用户意图（如您过去打开的文件等）作为上下文。能够在检索中使用这种细粒度的细节可能成为初创公司的重要护城河。

开放问题2：我们如何让AI agents 在端到端编码任务中表现得更好？

虽然我们距离完美的AI工程师还有一段路要走，但像Cognition、Factory、Codegen、SWE-Agent、OpenDevin和AutoCodeRover这样的少数公司和项目正在取得有意义的进展。

SWEBench评估显示，大多数基础模型只能修复4%[5]的问题，SWE-Agent可以达到12%[6]，据报道Cognition可达14%[7]，OpenDevin最高可达21%[8]。一个有趣的想法（由Andrej Karpathy在**这里[9]**重申）是围绕流程工程的概念，它超越了单一提示或思维链提示，专注于代码的迭代生成和测试。诚然，提示工程是一种无需训练模型就能提高性能的好方法，但目前尚不清楚这对一家公司来说在长期内能否构成多大的护城河。

注意，这种测量方式存在一些局限性：就上下文而言，SWE-bench由GitHub上的问题和拉取请求配对组成，所以当模型在其上进行测试时，它们只会得到代码仓库的一小部分（这是一种提示，同时也引入了偏差），而不是给予整个仓库并让它们自行解决。尽管如此，我认为SWE-Bench在当前阶段是一个良好的基准，可以开始理解这些 agents 。

代码规划将在AI agents 中扮演核心角色，我很期待看到更多公司专注于生成代码规范，这些规范可以帮助 agents 构建目标、规划功能并定义其实现和架构。多步骤 agents 推理仍然是一个广泛未解决的问题，据传闻这是OpenAI下一个模型的重点关注领域。事实上，一些人（如Jim Fan在**这篇文章[10]**中）会认为，AI编码 agents 的护城河实际上并不源于"包装器"，而是来自LLM本身及其"解决现实世界软件工程问题的能力，具有人类级别的工具访问能力... 搜索StackOverflow、阅读文档、自我反思、自我纠正，并执行长期一致的计划"。

这就引出了我们最后一个——可能也是最大的——开放问题。

开放问题3：拥有模型和模型基础设施是否能带来长期的差异化产品？

这个价值十亿美元的问题是，一家初创公司是应该依赖现有模型（无论是直接调用GPT/Claude模型还是微调基础模型），还是经历资本密集型的过程来构建自己的特定于代码的模型——即使用高质量的编码数据专门为代码预训练模型。我们实际上并不知道一个特定于代码的模型是否会比下一套大型语言模型有更好的结果。

这个问题归结为几个基本的未知因素：

一个较小的代码模型能否胜过一个大得多的基础模型？
模型需要在多大程度上预训练代码数据才能看到显著改进？
是否有足够的高质量代码数据可供训练？
基础模型的大规模推理能力是否胜过一切？

Poolside、Magic和Augment的假设是，拥有底层模型并在代码上训练它可以显著决定代码生成质量。考虑到竞争对手，这种潜在优势是有道理的：据我所知，GitHub Copilot并没有一个完全从头训练的模型，而是运行在一个较小的、经过大量代码微调的GPT模型上。我猜这些公司不会试图构建一个基础级大小的模型，而是一个更小、更专业的模型。根据我与这个新兴领域工作的人的交谈，我的结论是，在结果发布之前，我们仍然不知道这种方法会带来多大规模的改进。

对代码模型方法的一个反驳来自于这样一个事实：现有成功的编码助手，如Cursor和Devin，已知是建立在GPT模型之上的，而不是特定于代码的模型。

而且据报道[11]，DBRX Instruct的表现优于专门训练的CodeLLaMA-70B。如果用编码数据训练有助于推理，那么前沿模型肯定会在未来的模型中包含代码执行反馈，从而使它们更适合代码生成。与此同时，主要在语言上训练的大型模型可能拥有足够的上下文信息，使其推理能力胜过对代码数据的需求——毕竟，这就是人类的工作方式。

这里的关键问题是，基础模型的改进速度是否大于特定于代码的模型随时间推移的性能提升。我认为，大多数助手公司可能会开始采用前沿模型并在自己的数据上进行微调——例如，使用Llama3-8b并在其基础上通过代码执行反馈进行强化学习——这允许公司从基础模型的发展中受益，同时以非常高效的方式使模型偏向代码性能。