AI Coding 最全图谱：Agent 将如何颠覆软件

编程领域的投资现在正站在两个核心变化的风口上：底层推理引擎的马力越来越足，而整个市场版图也在悄然重塑。这两股力量搅在一起，让这个领域格外值得关注。LLM作为推理引擎，编程简直是它最完美的应用场景——代码的逻辑比自然语言清晰得多，而且执行结果还能让AI自己验证。所以你能看到，从Sonnet 3.5到o1 pro，每一次模型能力的跃迁，几乎都会在编程能力上立竿见影，整个赛道的进步也因此格外扎眼。

这种持续的能力提升，让我们开始期待一个更宏大的场景：未来参与软件生产的，或许不再只是专业开发者。这次我们干脆对整个AI编程领域做了一次全景式的扫描。在研究框架里，我们不仅看了那些面向专业开发者（包括企业和独立开发者）的产品，也把目光投向了“小白”用户（也就是那些泛知识工作者）的方向。这两类产品的重心，截然不同。

对于专业开发者，我们更期待的是，编程能比其他垂直领域更快地从“副驾驶（Copilot）”进化成“自主袋里（Agent）”，并且两者长期共存。现在，Cursor、Windsurf这些产品带来的“副驾驶”体验已经非常优秀，极大提升了独立开发者的工作效率和体验。但在大型企业里，情况就复杂得多：庞大的代码库、错综复杂的工程上下文，还有极其严格的安全合规要求，这些都不是短期内能搞定的。所以，“自主袋里”会更多地先在测试、代码审查、代码迁移这些具体的场景里落地。与此同时，通用的“副驾驶”IDE依然会发挥价值，成为编程Agent的工作底座。

至于那些不会写代码的用户，我们期待软件的生产方式会发生碘伏性的变革，会出现一种全新的产品形态——“任务引擎”。AI编程能让更多知识工作者的长尾需求得到满足，生成那种“随用随抛”的一次性应用。未来的软件，不需要动辄百万日活，而是为每个用户提供高度个性化的体验，内容甚至可以实时生成。这里的关键在于UI/UX层面的创新，谁能把交互的门槛降得更低，谁就能让更多人表达自己的个性化需求，最终就有可能成为编程Agent层面上的新一代操作系统。回顾PC的历史，我们现在可能还处在“命令行”时代，而AI编程领域的“GUI时刻”正在被翘首以盼。

01. 投资主线

总而言之，编程领域的投资逻辑，主要围绕着两个大变化：底层推理引擎的持续进步，和市场空间的结构性扩张。

在强化学习（RL）的范式下，一个能自动验证的环境和明确无误的奖励模型，是提升推理能力的关键前提。编程几乎完美符合这个要求，它很可能会成为LLM从“副驾驶”迈向“自主袋里”的第一个试验场。o1 pro的发布，再次印证了这个判断。

全世界会写代码的专业开发者只有5000万，还有99%的人不会。但这里面有大量的人，其实有个性化的任务需求，非常适合用软件来实现规范化。之前，试错成本太高了。而现在，AI驱动的“任务引擎”能带来大量这样的软件。

你可以想象一下，下一代的互联网，用户在浏览器地址框里敲的可能不再是网址，而是一句自然语言的指令，所需的内容就会实时生成并渲染出来；下一代的操作系统，每次打开，都能根据你近期的行为、时间和环境，给你最合适的内容。这里面，可能就孕育着AI时代的Google，成为赛博世界的新入口。这才是我们看好AI编程领域投资机会的根本原因。

接下来，我们用一张“二维坐标系”来梳理一下当前AI编程领域涌现出的各类产品：

• Y轴：产品在多大程度上需要人类参与？越靠上，越能端到端地完成任务；越靠下，则越专注于赋能开发者。
• X轴：产品的目标用户，开发能力有多强？左边是专业开发者，右边是没有编程基础的用户。

• 左下象限：面向专业开发者的副驾驶。
  最近口碑炸裂的Cursor、Codeium、Windsurf等基本都在这儿。它们在早期开发者的圈子里混得风生水起，这背后，对用户需求的深刻理解和Claude Sonnet 3.5出色的意图理解能力，缺一不可。它们保持增长的关键是：优秀的产品体验能赢得独立开发者的心，但对企业销售来说，这只是必要条件，而非充分条件。从产品到企业信任，中间还横着隐私、合规等一大堆复杂的需求。同时，最近开始大力迭代的GitHub Copilot，也会挤压它们的市场空间。

• 右上象限：面向普通用户的袋里。
  给普通人用的编程Agent，产品形态还没固定下来。Vercel的V0、bolt.new能智能生成前端网页，Replit Agent可以跟用户多轮交互生成基础的软件。而像websim、wordware这类早期创业公司，产品形态更新颖：websim在模拟一个实时生成的Chrome浏览器，wordware用类似Notion的交互方式让用户创作软件。但这个象限的机会可能才刚开始，目前的产品思路还有点拘泥于过去。可以类比施乐实验室发明GUI之前的命令行时代，对大众用户的门槛太高了，只能留在早期用户圈子里玩。

• 左上象限：面向专业开发者的袋里。
  要实现这个愿景，模型能力还得再上一个台阶。欧美已经有好几家融资过亿美金的公司在攻坚这个方向。因为处理代码token的消耗量极大，要解决的工程问题也很多。其中最核心的问题是企业的代码库上下文：一方面，如何从巨大的代码库里精准地找到你需要的东西，这是个难题，科技大厂也常因老员工离职导致旧代码项目没人懂。AI理论上可以有更长的上下文窗口，但理解和搜索的精度还不够。另一方面，企业的代码库里包含了大量公司内部的业务逻辑，这需要专有数据微调，甚至要本地化部署。像摩根士丹利、可口可乐这类大型企业，开发者数量不比Google、Meta少，而它们对合规和隐私的要求，远高于技术本身。

• 右下象限：面向普通用户的副驾驶。
  这个领域已经有了比较成熟的解决方案，所以后面的公司图谱里不会出现它。之前的Low-Code、RPA已经出了不少成功产品，比如上市公司UiPath和独角兽Retool。但它们都停留在“副驾驶”阶段，抽象方式只能辅助用户完成固定的工作流。反倒是Excel，成了最好的无代码产品，帮助大量知识工作者实现了科学计算和统计任务。这是个很有趣的历史启示。这一代AI编程产品要面对的“Excel”，是拥有5亿月活用户的ChatGPT。创业团队们需要认真思考如何绕过它庞大的用户基础和最强模型，并持续迭代。

02. AI编程图景现状

基于上面的分析，我们对整个AI编程图景下的创业公司做了一次系统性的盘点：

• 面向专业开发者的副驾驶：
  按工作流可以分成编码、测试、代码审查和代码搜索。其中核心价值还是集中在入口级的编码部分。

• 面向专业开发者的袋里：
  这里有两大类公司：编程Agent和编程模型公司。最大区别在于是否自己训练模型。前者是基于顶尖LLM来构建工作流和Agent，后者则从头开始训练编程专用模型。对于后者，我们持保守态度——它们正走在LLM大公司的主航道上。

• 面向普通用户的袋里：
  这个领域的公司还在百花齐放，我们大致分为三类。第一类是“任务引擎”，为用户完成任务、实现原型；第二类是前端网页生成；第三类是用“乐高”式组件搭建应用的Low-Code产品。最终大家的目标可能都是“任务引擎”，只是现在选择了不同的路线去赌。

面向专业开发者的副驾驶

专注于编程体验的产品，可以分为IDE和VSCode插件。两者各有千秋：自己做IDE，产品自由度和用户数据积累更完整；做VSCode插件则更轻快，用户迁移成本也更低。Cursor团队在这里的选择很聪明——通过Fork VSCode，把两者的优势都占了。Codeium也在通过Windsurf往IDE切入，因为IDE毕竟是更好的入口级产品，能自己积累数据、有更多修改功能的空间，这对构建产品的护城河很重要。

Cursor在用户体验上下了大功夫，核心就两点：“快”和“下一步动作预测”。开发者用起来就是不断按Tab，进入一个快速获得反馈的正向循环里——快，就意味着有趣，就能让人进入心流。上个月他们收购Superma ven，就是把产品体验里的“快”做到极致；这也说明，短期内的重点还是人与AI的同步协作，像o1那种异步交互，暂时还不是产品主线。

Codeium团队从VSCode插件做到IDE，体现了和Cursor完全不同的思路。Cursor更强调编程体验和预测用户意图，而Codeium的新产品Windsurf更强调高自动化。他们的Chat功能做得比Cursor更完善，很多用户甚至不用亲手写代码，就能完成基础的开发工作。同时，他们的产品还体现出了对企业级需求更强的理解，支持本地化部署和各种各样的合规协议。这就引出了它们在市场策略上的巨大差异。

根据Sacra的最新报告，Cursor的ARR已经达到了6500万美元，大约对应30万付费用户。由于Cursor的产品并不重视企业级代码库，它们的核心用户还是硅谷的独立开发者。那么，它们未来的关键就在于，独立开发者在所有开发者中的比例是否会变高。如果AI产品的开发范式下，独立开发者数量能增长到500万，也就是今天所有开发者的10%，Cursor的市场空间才有可能达到10亿美元。

企业侧的销售和开发者市场的增长方式完全不同。Codeium在企业销售和签单方面的能力很强。因为企业数据合规的需求，比最流畅的产品体验更重要。在Latent Space的一篇专访里，Codeium的创始人Anshul提出了“企业基础设施原生”的概念，强调要服务好世界500强用户，就必须突破硅谷开发者圈子的思维定势。这里有几个核心要点：

先说安全：需要支持多种部署选项，比如本地化或混合部署；容器化部署是基础，要确保客户环境的数据隔离。再谈合规：企业对LLM的训练数据高度敏感，你得证明你没用过受版权保护或未经许可的数据；数据清理和数据来源追踪，是保证合规的关键。然后是个性化：数据质量直接决定个性化效果，要对数据的时效性和相关性进行评估，通过微调/RAG帮企业写出更高质量的代码。数据预处理和基于角色的访问控制（RBAC）是重点，避免因信息整合导致数据泄露。ROI分析也不能少：生成式AI的ROI很难量化，你可以通过提供分团队的使用数据，帮客户优化效果、证明价值。最后是规模：企业环境复杂且规模庞大，涉及数万个代码库和开发者，你必须解决好大规模索引和延迟管理的问题，确保系统在高用户量、高数据量下也能稳定高效。

企业侧的机会可能更明确，是更低的果实。只是它们要面对GitHub Copilot那极其强大的分发渠道。面对竞争，用研究去解决GitHub可能做不好的地方，就显得至关重要。

这些编程公司，不能只当成应用层产品公司来看，它们更像是研究和产品一体化的公司。Cursor官网上自称是“应用研究实验室”，Codeium的官方博客写了大量关于微调/RAG技术方案的思考，Augment也在检索、强化学习等方向上做了大量探索。Augment和Codeium更关心的是企业级的技术方案，尤其是GitHub Copilot目前解决不好的问题。比如，Augment在处理的是在数万个企业代码库中，如何精准地做好检索和交互理解。和企业的文档RAG遇到的难题类似，代码库的检索需要重新训练专用的嵌入模型，对话、补全、跨文件生成需要的嵌入方式都不一样。Codeium还思考了很多在企业本地化或VPC上部署专用编程模型的问题，以求在安全性和智能程度之间找到平衡。

而对于Cursor，在强推理能力下的异步协同，是研究的核心方向，对应到内部项目就是Shadow Workspace。Shadow Workspace是Cursor为后台的编程Agent设计的开发空间。这个空间需要能“看到”Agent修改带来的lint提示信息，并与IDE背后的LSP协议充分交互，但不能修改用户的原始文件。AI和用户会一起根据Shadow Workspace下的lint反馈，来决定是否进行下一步迭代。这个过程，和o1的推理时计算思路类似。

代码测试是每个开发者必经的工作流，目的是保证代码质量。常见的有两类：一是单元测试，在错综复杂的系统里，代码更新后需要用单元测试来验证其可用性，减少意外崩溃的概率；二是前端或应用开发里，需要对UI的每个功能进行交互测试。测试任务和代码生成（codegen）的适配度很高，因为写测试过程重复性高、有规律可循，而且是人类工程师不太愿意干的活——绝大部分团队的单元测试覆盖率都比较低，就能侧面说明这一点。同时，Cursor团队在访谈中提到过，调试对LLM底座来说很有难度。LLM的训练方式不是去发现错误，要让LLM理解一个看起来不太严重的错误可能引发的连锁反应，是比较难的。因此，这里给独立创业公司留下了机会。

这个领域的代表公司中：QA Wolf是LLM出现前就有的公司，用基于规则的方法就能实现很多测试用例。Momentic是最近在YC和AI Grant中涌现的项目，更偏向人和AI协作对视觉产品的UI进行测试。Gru AI则是为单元测试场景设计专用的Agent，来端到端地解决企业中的测试需求。

代码审查与重构是开发者工作中重要的质量保障工作，无论是企业还是独立开发者，都得花时间审核内外的PR请求。根据TechCrunch，50%的企业开发者每周要花5个小时来进行代码审查。这个领域的代表公司CodeRabbit，在不到一年的时间里就实现了超过1亿美元的ARR，成为GitHub和GitLab上安装次数最多的AI应用，已经审查了超过300万条PR。这说明，原生的LLM产品在这个领域已经能提供不错的服务了。

除此之外，还有更大规模的CI/CD任务可以被归类为代码重构。比如，对项目进行优化和重构，解决历史遗留的技术债，甚至需要对技术架构进行重构和迁移，那就是代码迁移。这类需求同样繁重，也是人类工程师不太愿意干的。因此，这也成了我们接下来要说的编程Agent公司最早获得PMF的场景。

面向专业开发者的袋里

编程Agent公司的平均融资规模是最大的，因为目标是端到端地替代人类开发者，这个过程工程量大、消耗的代码token数量多。这个领域目前面临两个核心问题：一是技术层面，模型的底层推理能力还不够。要在企业的庞大代码库中完整地处理问题，需要很强的推理能力去理解用户和代码库两端的上下文，然后将任务拆解成多个步骤。这种长上下文加长程推理能力，才能真正去解决企业侧复杂的工程问题。二是产品层面，UI/UX需要与人协作方式的创新。既然模型能力还没到完全可用的地步，如何让人类介入到协作中，就成了一个难题。模型遇到难题时，是选择推理时计算进行搜索，还是把问题交给用户，让他给更多指导或上下文？如果这个问题解决不好，就会出现AI自己埋头苦干12小时，结果发现没辙了，交给用户时，用户也很难在AI的基础上进行修正。

由于以上问题，我们推测当前真正能有PMF的场景，会是代码迁移、代码重构和PR提价这类任务。这些任务对开发者来说往往是苦活累活，他们可以借助Agent把精力解放出来，投入到其他更有创造力的领域。因此，现阶段的编程Agent，更多是在做从1到100的事情，还没到从0到1的阶段。我们看好编程Agent在未来2年内会逐渐承担更多的责任，但这需要底层模型能力和上层Agent框架的共同进步。

定价问题也很值得思考。传统的开发工具一般按使用者数量（seat-based）收费，但对编程Agent而言，按消耗量（consumption-based）付费可能更合理。一个优秀的、能完成大量任务的编程Agent，其价格可能值得和初级开发者处在同一数量级。

编程领域对模型能力的要求其实不完全一致。比如代码分词器（code tokenizer）要对代码中的变量、符号、函数名做专门切分。而且，主流LLM的训练目标函数是文本生成，代码能力看起来更像是智能的副产品。因此，出现了像Poolside和Magic这样的独立编程模型公司。Magic强调特别长的上下文窗口，能把企业中复杂的代码库完整读进来，尽量不依赖检索。Poolside则强调通过机器反馈进行强化学习，能把Git历史中复杂的工程链条完整解决。

不过，这一领域的公司处在OpenAI、Anthropic的主航道上。考虑到编程能力是模型推理能力最好的袋里指标，这两家巨头一定会基于LLM+RL的范式，持续提升编程能力。对于独立公司来说，挑战依然巨大。

面向普通用户的自动驾驶

“任务引擎”对应的是“搜索引擎”。用户得到的，不再是基于搜索关键词的网页，而是基于用户需求实时生成的软件。我们用“任务引擎”这个词，是希望能淡化“软件”和“代码”带来的高门槛感。编程能力带来的杀手级应用，应该是大众用户都有意愿和能力去用的。Anthropic的Artifact和OpenAI的Canvas，某种程度上也是想实现这个目标，但产品形态并不是很好用，加上用户对主产品的预期还是聊天机器人。因此，现在的“任务引擎”还处在命令行时代，需要一个GUI级别的产品创新，来让更多用户理解并使用。

目前这类产品的形态还有很大分歧：

• Replit Agent：
  一个为编程Agent打造的云端IDE。产品使用多轮对话，每次执行操作都是渐进式的，遇到问题会向用户提问来补足上下文、厘清需求。这个过程有点像开发者和产品经理对需求。这种产品设计用对齐（alignment）解决了模型多步执行时的可靠性问题，但也要求用户对自己的需求想得比较清楚。

• Wordware：
  一个面向LLM应用的Notion。产品完成度高，使用体验有点像创作内容。通过一个讽刺bot在Twitter上走红，打响了病毒式增长的第一枪，有点像去年的Perplexity。但成为ProductHunt增长最快的产品后，流量又开始快速下降。高度依赖头部流量产品，是Wordware现在的挑战。

• Websim：
  用类似Google Chrome的简陋界面，打造了一个用户可以同时创作和消费网页应用的产品。想象空间很大，用户可以在别人模板的基础上继续生成和修改，有点像Canva的模板化思路。而且用户在Websim上做的网站，每个超链接都可以点击并深入生成新的网站。不过产品设计细节还欠打磨，有点像Character.ai，有一个好框架但产品还不够极致。

这个领域的公司之前在前端框架和部署领域就有比较深的积累。比如Vercel是Next.js框架的发明者，主要业务是前端网站的部署，ARR已经超过1亿美元。它们的V0产品一直在进步，无论是审美风格还是对话修改体验，都比刚发布时好了很多。另一个很火的产品是bolt.new，也能通过一句话把产品需求变成一个不错的网页应用。它的进步速度更快，同样的指令，每隔一两周都能看到生成质量的提升。

这类产品的效果已经接近可用了，但在实际持续使用时，会遇到一些问题。生成的网页应用demo非常优秀，但由于技术栈比较杂乱，产品真正开始有规模后，很难维护和管理。因此，前端生成的未来使用场景很可能是“一次性应用”——这个网页的生成，就是为了服务某个临时的、长尾的需求，不需要为更大的群体和更长的时间去维护。前端是开发中相对容易上手的领域，所以之前每一代Low-Code/No-Code都会讲“前端民主化”的故事，诞生了WordPress、Wix、Shopify这样的公司。这个市场很大，但需求比较零碎，头部集中度不高。AI前端生成现在看起来很有前景，但它们是否能抓住大量的增量需求，甚至替代过去的存量需求？这直接决定了其市场规模的上限。

03. 开放讨论

技术带来一个领域的民主化，这是很多领域都发生过的故事。比如Canva，成了“设计师民主化”的一站式模板和设计平台。那么开发领域是否也会有类似的民主化故事？我们认为会民主化的不是编程能力，而是软件工程。这意味着，随着AI编程的到来，软件的制造成本会大幅下降，但用户不一定需要理解代码是如何操作和执行的，只需要明白高层级的运行逻辑即可。也就是说，用户不需要是开发者，但需要是自己需求的产品经理。

未来的开发体验，可能由同步和异步共同组成。同步部分：开发者一边写代码，AI一边在后台同步做代码测试、审查、优化。异步部分：在o1的范式下，推理时计算能把编程任务拆解成多个子任务，推理出最合适的解决方案并自己验证。而未来更广义的AI编程也是如此：很多软件可以实时根据上下文来生成，而真正复杂的任务则不需要实时交互，AI能异步地完成，并通过邮件等方式向用户同步。现在的产品交互门槛还是偏高，有点像GUI到来前的命令行时代。等待新交互到来时，AI应用的空间会被打开，而编程领域，很可能是最先被验证和感知到的。