写代码的退场，调度 AI 的上桌。

作者丨马晓宁、郑佳美

编辑丨陈彩娴

当 AI 大模型飞速进化，最先被卷入洪流的，不是写作画画或运营，而是程序员。过去几年，从 GitHub Copilot 开始，到 Cursor、Codeium、Claude Code，再到各类 Agent 框架如雨后春笋般涌现，AI 开始进入代码世界，试图不仅写代码、补代码，更要理解工程、构建系统，乃至在没有人的指令下完成一次次自动迭代。

这场看似技术层面的革新，其实正在悄然重塑整个软件开发范式，也让“AI 是否将程序员作为第一个被颠覆的职业”成为一个日益无法回避的问题。

然而，颠覆，从来不是一个单向度的词。AI Coding 正在打开的是一条分叉的路径：在存量程序员眼中，它是效率的跃迁工具，是写代码的新搭子；在非程序员眼中，它是一种“去编程化”的自由工具，是一种“用自然语言造软件”的全新可能。而在真正理解软件工程的人看来，AI Coding 更像是刚刚起步的“工程幼儿园”：离真实的复杂协作、架构设计、上下文演进与严肃生产环境仍有巨大距离。

7 月 19 日上午，AI 科技评论组织了一场围绕“AI Coding”的线上圆桌，请到了三位长期深耕于 AI Coding 领域的代表人物：峰瑞资本的投资合伙人陈石、Auto Coder 创始人宿文与 ClackyAI 创始人李亚飞。他们的身份横跨资本、模型与产品，也代表了对这个问题的三种路径观察。

以下是此次讨论的精彩分享，AI 科技评论进行了不改原意的编辑整理：

从辅助工具到工程变革

AI 科技评论：欢迎大家来到今天的 GAIR Live 直播论坛。本场主题是 “AI 颠覆的第一个职业会是程序员吗？”我们的第一次问题：什么才叫 AI Coding？它与传统软件工程（SWE）有什么区别？AI 是否可能成长为一种新的工程范式？下面先请陈石来分享他的看法。

陈石：我理解的 AI Coding，如果从狭义角度来看，目前更多指的是AI 自动生成或补全代码，甚至是自动完成整个代码编写过程。但这个“完成”往往并不符合真正的软件工程范式，也很难满足我们在软件开发中常提到的一些规范性要求。

当然，未来的 AI Coding 一定会朝着更工程化的方向演进。它不仅要遵循现有的软件工程规范，甚至可能会发展出一种全新的工程范式。这种范式不仅要求 AI 能写代码，还要求它能参与整个开发流程：从需求拆解、架构规划，到代码生成、测试验证、持续集成部署（CICD），甚至包括多智能体协作、自我修复、持续迭代等关键环节。

所以，我认为今天我们看到的 AI Coding，还处于非常早期的原型阶段，只能在局部场景中解决一些简单问题。但它的未来潜力不容低估——它会从生成“demo 级”的小程序，发展到真正具备构建大规模、复杂系统能力的工具。这才是我眼中 AI Coding 的真正方向。

AI 科技评论：所以目前来看，AI Coding 还处在一个比较早期的阶段，确实还无法真正达到软件工程的标准。那接下来想请宿文老师谈谈您的看法。

宿文：我们观察到，今天 AI Coding 的产品形态，基本可以分为两大类，它们分别对应两类主要用户。第一类是存量的程序员用户。从最早的 GitHub Copilot，到后来的 Cursor、最近的Claude Code，这类工具主要围绕开发者的 IDE 环境，提升代码补全、协作效率等，甚至开始探索 SWE Agent 这样的新范式。这个方向本质上是面向已有开发者市场的，属于一个存量场景，所以吸引了大量程序员的关注和使用。

第二类则是增量用户，主要面向非程序员群体。他们率先服务的还是posumer，这些人可能不会写代码，但有明确的软件或应用需求，有点像产品经理，但是是“打着引号的产品经理”——他们可以用自然语言描述自己的需求，并期望 AI 帮助把这些想法变成一个原型产品。

目前，AI 模型在前端 UI 生成方面已经比较成熟，但真正的软件工程深水区，比如后端逻辑、数据库设计、高并发、高可靠性的处理能力等更难的技术栈，还远远没有突破。这正是接下来整个技术体系要努力的方向。

所以我们认为，AI Coding 一方面是在提升存量程序员的效率，另一方面也在拓展增量市场、实现开发能力的“平权”。最终的目标，是让更多人即使不具备编程能力，也能自由地实现自己的软件想法，而不再受限于“程序员供给”的门槛。

AI 科技评论：听起来这是两个方向——一个面向程序员的效率提升，一个面向非程序员的能力扩展，确实可以看作是两条路径。那接下来也想请李亚飞老师来聊一聊，特别是 ClackyAI 最近刚发布了新产品，我们也很期待听听你的观察和看法。

李亚飞：好的，刚才大家聊到了 AI Coding 的定义，我也想从两个角度补充一下我的理解。第一，是从软件工程的复杂度维度来划分。我们可以把软件项目按照工程复杂程度分成五个等级，从 C1 到 C5：

C1：最简单的项目，比如通过 GPT 聊天生成一个前端页面、小工具、小游戏，通常只有一个文件，纯前端逻辑即可。

C2：稍微复杂一些的小工程，可能包含 10 个文件以内，具备基本样式和简单逻辑，比如带 UI 的小网页。

C3：像公司官网这样的项目，结构更完整，文件量可能在 100 个以内，涵盖完整的前端和部分简单交互。

C4：真正意义上的软件工程，具备前端、后端、数据库，业务逻辑相对复杂，通常涉及多个模块的协同。

C5：超级大工程，比如 Linux、Windows 这类操作系统级项目，涉及百万文件、成千上万名开发者协作。

目前我们看到的 AI Coding，大多还停留在 C1 到 C3 的阶段。也就是说，它能胜任原型开发、小工具生成，但距离严肃软件工程（C4以上）还有一段路要走。

第二个维度，是 AI Coding 对人类价值的进化阶段。我们可以理解为 AI Coding 本身也在经历从「工具」到「合作者」的过程：

第一阶段是“辅助补全”阶段，AI 能补全代码、预测你接下来可能写的内容，就像文章写作里的自动续写功能，这一阶段已经发展了近两年。

第二阶段是“AI 原生编程”，像 Cursor 这样的产品代表，基于聊天辅助的编程工具。AI 能围绕用户的需求实现具体模块、功能，好的就留下来，不好的就可以丢掉。开发者还是主驾驶员，但 AI 已能提供有价值的思路和建议，

第三阶段是我们现在正进入的 “Agentic” 阶段，AI agent作为一个“AI工程师”真正参与到从 0 到 1 的项目建设中。我们一年前就开始做了，但真正能落地还是在最近一个月。这是以Claude Code为代表的新型的软件开发模式，这种体验非常独特：你告诉它一个目标，它会在后台持续“工作”，几个小时后告诉你“已经搞定了”。你去检查时会发现，大约七成已经搭好了，剩下三成搞差了。这个过程既矛盾又开心。

这一阶段，我们认为才是真正的 AI 工程师时代的起点。

终局清晰，路径仍模糊

AI 科技评论：有人跟我说，你在旧金山的一个 zip code下面，你能找出来 20 家 AI Coding 的公司，而且每一家切入点都不太一样，有做 code review，有做 document 的，各种都有，那这个赛道它有没有机会收敛？很多不同种类的公司的同时并存，是不是一个很长期的事情？

李亚飞：我简单说一下我看到的一些现象。现在中国这边其实还没那么“热”，大家应该也能感受到，虽然也有一些公司在做，但整体氛围相对克制。反倒是美国那边、尤其是硅谷，非常活跃，因为那边是软件的天堂嘛。

但也因为软件工程的复杂度很高，它早就形成了非常明确的分工体系。在今天 AI 还处于相对早期阶段的情况下，其实每个工种理论上都能被赋能。这也是为什么你会看到市面上有那么多 AI Coding 公司：做 code review 的、做测试的、做需求管理的……整个软件开发流程每个环节都能开出一家公司来。

人类工程师掌握不了那么多的知识密度，所以需要分工，现在的AI可能在某个方向不是超级专家，但是它在大多数方面都是个中级工程师，这个时候分工就要发生变化了。

我觉得现在的趋势就是从多 Agent 走向单 Agent 架构。因为分工带来的成本太高，反而不如一个大模型“一人多能”来得划算。有些场景可能不存在了，比如code review 这个环节，都是AI写的，你还 review 啥？你是在为人类写代码做AI，还是在为“AI时代新的软件工程”做AI？这里面有本质的变化和区别。现在大家看得也都不太清楚，所以这么多公司百花齐放，大家冲进去先干，活下来再说。这是我目前的观察。

AI 科技评论：那你觉得，接下来这些基于分工诞生的 AI Coding 公司，会不会随着分工变少、被逐渐取代？未来是不是就不再需要这么多细分方向了？

李亚飞：可能开始有很多山头，然后会进入收敛阶段，我不觉得会完全一家独大——因为软件工程太复杂了，不太可能被某一个玩家完全吃掉。更现实的情况是，会在几个方向、几个垂类场景里，各自形成一些稳定阵地。这个行业用户的付费能力和意愿都很强，市场空间也足够大，所以哪怕到终局，也不会是一个标准答案。

AI 科技评论：那陈石老师你从投资人的视角怎么看？

陈石：为什么美国有这么多切入点不一样的公司？我觉得 AI Coding 是当前 AI 应用落地中最有机会的几个方向之一。所谓“最有机会”，我觉得可以从三个维度来看：第一，用户规模足够大；第二，模型能力已经接近可用水平，至少达到了能满足基本使用的程度；第三，市场上已经有一部分产品找到了初步的 PMF，比如 Cursor，好像现在已经能做到年化 5 亿美金的营收了。这三点决定了为什么这个赛道这么热、公司这么多。

但与此同时，我们也看到这个行业没有明显的收敛趋势，原因在于很多关键问题还没有达成共识，这一点作为一个天天见项目的投资人，我感受非常深。

首先是 Copilot 还是 Agent ？未来我倾向于认为 Agent 会更有潜力，但也一定会存在大量 Copilot 的场景，毕竟熟练的程序员很多时候还是更喜欢“手搓”。我们原本觉得 Copilot 不太适合创业公司，但 Cursor 的出现又让这个观点变得不那么确定了。

还有一个悬而未决的问题是：模型能力的边界到底在哪？ 现在看，模型在处理一些垂直方向，比如单元测试、Code Review 这类任务上表现还不错，端到端地做简单或中等复杂度的程序时也能胜任，但面对真正复杂的软件系统、长链条的逻辑结构时还是不行。

同时还有个现实问题是：模型厂商的业务边界在哪里？ 有些创业公司会选择做 Agent，但他们会有意避开模型公司可能会直接做的端到端方案，转向更具壁垒的垂直场景。

Vibe Coding的市场有多大？很多人其实逻辑思考能力并不强，没有能力把自己的需求有效地表达出来，所以这里头有很多不太确定的东西。

我认为， code review 或者单元测试这些 AI Coding的机会不太大，因为需求和产品定义得很清楚了，产品规范上没有门槛了。未来的Coding应该是每一个软件都是定制化的软件，有机会的应该是能围绕垂直行业和 “深度上下文”展开的Agent，这是模型公司做不了的事情。围绕着这些垂类行业的深度上下文，做大量的加工，总结成良好的提示词和上下文工程，跟模型做交互，这才是我们创业公司比较好的发展机会。

AI 科技评论：宿文老师，您说您希望做一些“用完即焚”的软件。我觉得这个思路和刚才陈石老师提到的“定制化软件”某种程度上是相通的，所以也想请您展开聊聊这个想法，背后有哪些考虑？

宿文：其实这个是我们公司的一个 slogan，上半场是 Auto-coding is AGI，下半场是 Personal App is the End。意思是说，以后每个人都有属于自己的 Personal App。这个APP可以是长期消费的，也可以是一次性的软件。

我们可以先预测一下终局，如果所有的Coding都是依赖于token去完成的，那可能就会发展为模型厂商赢者通吃的局面。走向未来的过程中，其实每一轮新的工具或技术出现，首先都是在现有的存量市场中扎根的。毕竟这么多专业的人才、聪明的大脑，一定会尝试拥抱它，把它应用到已有的工作场景中。毕竟我们看到整个软件世界体量非常庞大，从芯片往上一层一层搭建上来，最终都汇聚在“软件”这个抽象层。

有些语料是大模型在后训练（Post-train）或者预训练（Pre-train）阶段见不到的，都是这些垂直领域的玩家在用自己的知识去做的。这里面的卡点就是，今天的模型应该怎么去支持他们？模型架构在往前迭代，现在主流模型支持的上下文大概在 120K token 左右，往上做到几百 K 的已经是极限了，Gemini做到Mb级别的长度了。

我们自己就是从模型层开始干的，我们就发现很多问题，只要模型迭代下就解决了，但下游开发者只能被动的等待或者迁移。

所以对我们来说，在这个不断变化的过程中，最关键的是找到一个落点——我们会去寻找那些不容易被“堆人”、“堆资源”就能打下来的场景。很多产品和场景，可能按月、按季度就会被迭代掉。我们思考的也是，既要看清一个远处的终局，也要找到当下能活下去的路径，所以我们也考虑向 C4 这个环节去突破，面向严肃的生产环境制作软件。

李亚飞：我想补充问一个问题，想请教一下宿文。其实刚才提到的 C4 工程——也就是涉及前端、后端、数据库这些完整链路的软件开发——它其实是可以有很多不同的解法的，对吧？比如说，有些人会选择无代码、低代码的方式来处理，也有一些人坚持用标准的技术栈、按照传统软件工程方法来推进。那我挺好奇的是，你们在这方面是怎么思考和选择的？你们更倾向于哪种路径？

宿文：你肯定观察到了最近的一些新闻，包括最近被Wix收购的Base44，这个产品是挺好用的，但是典型地用到了低代码的手段，很亲和于Wix的建站场景，整个软件世界肯定不止这些。我们自己的判断是，原有那套软件开发架构还是局限于场景之中，是为“人”设计的，尤其是为架构师、程序员设计的，它的核心是：链条越长、分工越细，就越能发挥规模协作的优势。比如一个大厂有几千上万程序员，每个人都是一个“螺丝钉”，整个链条组织得非常高效。但大模型来了之后，它的理解和处理方式完全不是这么玩的，我们在做全栈类生成的时候就非常明显地感受到这点。

所以我们现在的重点方向是，探索一种面向语言模型亲和、以生成为核心的软件 agent 架构。我们认为这两条路径缺一不可。怎么去理解面向模型的生成式软件架构，这是我们要去摸索的。举例而言，在面向B端的应用中，每个页面都会有一个搜索组件，但是在生成式的软件中，整个架构中只有一套搜索的组件，我们再去选择如何适配各种场景。

我们现在的看到的，比如 Devin 这套架构里面，它本质上是要替代程序员的，但是又按照程序员的分工协作去做的技术链条的设计，我觉得这样很怪。我们在尝试一条新的道路。

李亚飞：明白，这个问题其实我们作为创业者，真的会有很深的感受。它本质上是一种“内心的矛盾状态”。这个矛盾来自两个方向：一方面，我们知道市场、尤其是投资人这边，确实会有压力，大家都希望你能尽快跑出 PMF，最好能快速闭环，用户开始付费，模型也能用起来。

那么从战术上讲，其实是有一些作弊的方法的。比如说我就只做个纯前端界面，模型生成完一闭环，看起来像个产品，就能收钱了；又比如说我提前把整个技术栈锁定，用低代码的方式、围绕某套提示词和上下文优化打磨，也是可以很快搞出东西的。这些办法都能跑得快、看起来也“成型”了。

但另一方面，作为搞了十多年全栈开发的工程师，我们心里也非常清楚——这些方式不是终局，甚至说是“偏离正确道路”的妥协。它们让团队进入了一个短暂的“舒适区”，但那个方向很可能不是 AI Coding 的未来。所以这时候你就会非常矛盾。

到底是坚持正确的选择，还是马上进入快车道去做闭环，有时候会让团队陷入一种无所适从的状态。刚才听宿文的回答，我觉得他其实在那套路径里，也体现出了一种对这类矛盾的平衡。这个我挺有共鸣的。

陈石：我这边想补充一句，其实亚飞老师刚才说的那种“矛盾”，确实在市场上是存在的，甚至可以说是目前不少创业者都会面对的现实困境。

就比如现在大家经常讨论的一个路径问题：是不是应该先从 Copilot 做起，有了局部的数据和经验，再泛化到 Agent？但自动驾驶行业又有不同说法，例如有些专业人士认为，L2做得越好，就距离L4越远（当然很多业界人士包括我自己并不完全认同这个观点）。这也引申到 AI Coding 的问题上——你是先专注于一个垂直场景，做得足够深，然后再图泛化？还是说一开始就奔着通用方向去？这两种路线还没有形成什么共识，现在还处于一个多种探索并存的阶段。

李亚飞：今天 Cursor 上个月改了收费方式之后，就被用户打回原形了，就是这个矛盾的体现。就是作为 Copilot 产品，现在想按 agent 产品收费，用户不 buy in。这就是一个矛盾。但如果你第一天就是做的 agent，那你就按这个方式，比如按任务规模复杂度来收费，那就可以了。

陈石：我觉得Cursor的经济模型可能做不过来了。

李亚飞：我同意。我补充一个使用体验上的角度。Cursor原来的收费方式是，一个月内500次调用收费20美金。这是基于上个阶段的Chat-Base program的产品结构所定义的收费方式。但是 Agent 的工作方式是，给它一个目标，它能自己循环500次。结果 Agent 花了500次的钱，只收了用户1次的钱，那Cursor肯定想改。这就是 Agent 模式和 Copilot 模式打架的问题。

“幻觉”仍是模型最大短板

AI 科技评论：去年一整年，随着Claude 3.5、3.7的发布，AI 编程已经变得越来越“实用”了，甚至开始推动整个交互范式往 Agent 模式转变。那问题来了——作为投资人，以及亲自参与模型开发和基于模型做产品的人，你们怎么看当前模型能力的瓶颈？

宿文：其实从我们自己的观察来看，整个大模型的能力还远远没有达到理想状态，离我们想象中那个“终点”还差得挺远的。但是我们也不能等下一个版本出现，因为说实话，你等再久，它也不会主动把你的用户数据纳入到 Pre-train 里，所以我们不应该做技术等待型的公司。

Claude 3.5出来，伴随着一个很有意思的产品，Artifacts，我们今天就看到了 lovable 这种首先找到一个变现场景的产品，不管争议多大，用户量都有了，前端也能写的很好。其实前端语言的逻辑性是很弱的，很多前端代码都暴露在公网，所以这些都能做出来。但是我们不能拿到数据库，拿到后端代码。

大模型的问题在于，今天的Transformer架构很难把业务的长链条解决得很好，这是Transformer本身的天花板所决定的，那我们就会想去解决其中的一部分问题，其中一个就是“幻觉”。模型为什么产生幻觉？我们后来反复研究，发现它的根源其实还在最早的 Pre-train 阶段，特别是反向传播的机制本身就有偏差，那我们就看有什么更好的网络结构去改造。

所以我们自己的结论是：如果真的要解决问题，必须从网络结构层面去动刀，真正让模型在 Pre-train 阶段就变得更靠谱。这才是能带来陡峭提升的地方。说实话，从 DeepSeek-V2 发布到现在，我们看到整个行业在这方面的创新还很有限。那我们就自己想办法解决了。

陈石：刚才宿文老师提到了“幻觉”这个问题，我也非常认同，这是当前大模型能力的一个关键短板。而除了幻觉，另一个普遍存在的技术瓶颈，就是上下文窗口的限制。我们现在看到很多代码库其实体量都非常大，很容易就超越了上下文窗口的上限。

此外，受限于当前AI模型训练的机制，模型训练完成后就被冻住了，在运行时一般不再做参数更新。而每个用户在使用模型的时候，都需要某种程度的定制化，或者说都需要有自己的上下文记忆，现在解决定制化的方法是靠应用去存储和捕捉上下文，以反复Prompt的方式传递给模型。这个成本很高，且运行时间越长，Prompt长度越大，每一个交互都需要费大量token。现在虽然像 ChatGPT 引入了一些“记忆功能”，但我觉得还远远不够。我认为未来模型应该可以直接“记住”你的上下文，让它能像人一样保有长期记忆，而不是每次都靠 prompt 临时加载。

我猜未来会有一些变化，要么是模型结构上的，允许在运行阶段动态调整参数；要么是解决记忆存储的安全与隐私问题，比如如何以安全、可控的方式把用户或企业的长期上下文交给模型来处理。

AI 科技评论：亚飞总怎么看待这个问题呢？

李亚飞：首先我挺佩服真正敢下场做大模型、做 Pre-train 的团队，今天的大模型确实还有不少问题和短板需要解决，而我认为，在工程领域看待这些问题，可以从两个不同的视角入手。

第一个视角，是智能性，也就是大家经常说的“推理能力”。这一块现在很多模型都在突破，比如陈石总刚才提到的上下文处理问题的两种思路：一种是直接把尽可能多的上下文“塞”进模型中，另一种思路则是像人类那样通过外部记忆进行知识调用。实际上这波 Claude Code 展现了外脑获取知识的能力，它会自己反思看代码，现在我的测试结果是，它能把10 万级别的文件处理得也很好。

第二个视角，就是幻觉问题。我觉得这和人类的想象力类似，某种程度上是生成能力的一部分，它可能永远无法被完全“消除”。但在 Coding 领域，我们能做的最好的方式是，给模型提供充分的tools，让模型具备反思能力——也就是要能“犯错-觉察-修正”。

第三个，我觉得大家经常忽略掉的，就是我们要给它一个更强大的反馈系统。我们从工程领域看到的，比如debug类的信息，没有给它。原来的debug是单步单点，这是给人类设计的。其实AI不需要单步单点，如果AI研究一会儿看不出错误，它就跟你说，请你把调试器打开把那个错误粘给我，然后我才能继续。为什么我们不能把这个信息直接丢给AI呢？这些能力加上之后，AI的能力会明显地变强变好。

目前来看，Claude 4.0 的智能性已经相当强，从今年 6 月开始，真正属于 Coding 领域的 Agentic 时刻已经到来了。剩下的问题无非就是，Cli是不是最好的形态了。

原型做得快，生产还得慢慢来

AI 科技评论：要想提升AI的编程能力，哪些东西是模型能做的？哪些是产品设计中能做的？

宿文：在我看来，这两方面还比较难拆开。模型迭代得很快，我们核心还是构建数据飞轮。产品层面来看，工程也是很重要的一件事情。我们的模型和产品缺乏一个超级动态规划，其实大家今天都静态得不能再静态了。

那模型层要做什么呢？我觉得最核心的还是数据飞轮的构建。之前美国红杉开会的时候，几乎没有一家公司的CEO能说清楚怎么构建的。我们认为，真正有效的数据飞轮一定从 Pre-train 阶段开始。但 Pre-train 成本极高，不可能频繁跑。所以关键在于怎么通过网络结构创新来支持“增量预训练”，而不是传统意义上的增量微调（Post-train），从而让token的权重可以快速地进行动态调整。这肯定是网络结构决定的，我们今天基本上能够做到了。

然后你再看上下文的处理问题。去年的上下文窗口竞争，一度“卷”到兆级上下文。但那其实更多是post-train层面的改造，不是真正从 Pre-train 层解决上下文编码能力的问题。比如去年 Magic.dev 的探索就很有代表性，他们认为编程的卡点在大上下文，于是基于mamba的架构去做了，虽然过程不顺，但思路非常有价值。混合架构加上位置编码的方式，能不能把上下文扩展到Mb级别？我觉得是可以的，那我们就这样做了。

而从产品层面，我们关注的重点是用户的真实表达能力。你的用户可以是程序员，也可以是非程序员，甚至是完全不懂技术的“普通用户”。关键在于你能否让他们把自己的需求讲清楚。而这恰恰是今天对话式交互里最大的挑战。我们肯定去做社区，做内容沉淀让更多的知识可复用；还有就是摆脱对话式，做图形的交互方式等等。产品考虑的是用户入口的事，模型考虑的是智能迭代的事。

AI 科技评论：明白。陈石总，从您作为投资人看过这么多产品的这个角度来看，您觉得呢？

陈石：我之前也做过技术和 CTO，虽然现在离技术有些远了，但对这个话题还是有一些感受。AI Coding 想要在未来真正发展起来，我认为核心在于“两端能力”的协同推进：

一端是模型侧能力的持续进化，包括更强的逻辑推理、对上下文的理解与处理能力、以及上下文窗口的进一步扩展等等。这是模型层面的事。另一端则是应用层的“上下文工程”。也就是说，产品要通过巧妙的设计和人机交互方式，帮助用户清晰、完整地表达出他们的上下文和需求。

模型和应用端面临的挑战就是，如何帮助那些逻辑表达不够清晰的用户，把他们真实的心理需求，以清晰的方式用自然语言的方式表达出来。

AI 科技评论：大多数基于 LLM 的编码助手 AI Coding 的产品并不公开其内部逻辑，所以我们很难去验证它生成代码的准确性，也不能够去理解它为什么会做出来这样的输出，就没有办法去嵌入到真实的这个项目环境，但是Vibe Coding这个词又很热，所以我们应该怎么去看待它的价值？

陈石：对于早期的尝试性用户，如果有一些编程基础，他们可能觉得比较好。我们要认识到Vibe Coding还是一个原型验证的阶段，偏向于把创意激发出来。

有些人可以告诉AI，你给我写个贪吃蛇游戏，它就写出来了。因为这是一个很容易的代码。如果是一个复杂的东西，受限于人类的自然语言表达能力，和当前的语言模型的编程能力，还是比较难的。所以不要把快速做出贪吃蛇当回事，这只是个很简单的功能，甚至不需要大语言模型。

我们的诉求是，产品侧帮助用户把真实需求以规范的产品文档方式表达出来，以及在模型侧怎么形成好的软件工程范式，这两段的努力能够让Vibe Coding产生更大的价值。

AI 科技评论：宿文总好像对贪吃蛇这种游戏类可以说几句。

宿文：游戏是个非常复杂的事情。今天大家看到 AI 做马里奥、贪吃蛇这些案例，确实能跑通，更多是因为这些场景早已有很多类似样本，模型能“见多识广”，所以比较容易实现。

我不太喜欢Vibe Coding 这个词，但是今天到底能做到哪一步？目前典型产品，比如lovable、bolt.new 甚至更早一些的工具，确实已经能做到做出原型，而原型这件事在很多场景下本身就已经很有价值了。它能够帮助开发者省去大量方案设计、产品需求撰写和原型构建的工作，所以才会有那么大的用户量。

我们更关注的是下一步：如何进入真正的生产环境，并赢得用户信任。过去由人来写代码，哪怕出错也能溯源、有人背锅。但今天基于大语言模型的代码生成，本质上是概率模型，天然带有不确定性。如何让用户信任这种“不确定性里的生产力”？这需要分阶段、分角度来推进。以前只有少数程序员能够做的高阶工程，以后也会以token的形式交付出来，这样一步一步验证它的安全性，慢慢影响用户心智，从而进入生产环境。

到底要不要放开源代码，我们持相对开放的态度，有一个问题是，一旦放开，用户再一改代码，整个deploy环境就乱套了，也就破坏完整的数据闭环了。

AI 科技评论：为什么不喜欢Vibe Coding这个词？

宿文：国内最主流的翻译是氛围编程，这感觉不是一个能进生产环境的词。

李亚飞：有一个词更合适，叫松弛编程，就是我心情比较轻松，氛围编程就好像是在玩，瞎搞。

今天我们对此有两个矛盾。第一个矛盾是：来自业务侧的“小白用户”，他们很多都是非常专业的商业人士，只是完全不懂编程。但他们有明确的需求，想自己动手做一个应用。然而现实是，哪怕今天的工具已经进步了很多，这种需求和能力之间还是没有完全拉齐。所以 Vibe coding 才会在某些圈子里被嫌弃——因为它给了用户“好像能搞定一切”的错觉。

第二类矛盾是：专业工程师的认知正在迅速分化。我最近观察到一个有趣的现象：本来就是“十倍效率”的高阶工程师，在接入“松弛编程”之后，效率能再提升十倍，甚至达到百倍。普通的工程师，只要用对方法，也能获得显著提升。还有一些工程师是坚决反对甚至排斥的。但这并不代表他们错了——可能只是因为还没真正看到这些工具的威力。我自己就反复横跳了两次，但是它一次次改变了我的想法。

我们现在早就不是贪吃蛇可以一键生成的时代，Vibe Coding已经可以做到 one-shot 生成一个完整的官网页面，甚至借助它做点外包项目。今天的一些工程师已经可以通过松弛变成搞定 C3、C4 复杂度的项目，包括后台、数据库等全套系统。

这类能力距离“完全小白用户”使用还有一段距离，当然，也可能未来永远不会出现“完全小白用户”能独立做工程的那一天。毕竟软件开发本质上是软硬工程结合的复杂工作——懂行的人都知道它有多难。但有一点是可以肯定的：未来的开发过程一定是“松弛的”，以后的工程师都是业务逻辑式的，技术水平只需要以前的三分之一，但是他们能捋清商业逻辑，捋清产品逻辑。

如果你本身就掌握了编程技能，在 Vibe Coding 这个浪潮里，你依然能够做到比别人高出十倍的效率。

AI 科技评论：以后Vibe Coding会公开代码吗？

李亚飞：我的答案是应该公开。它的本质还是代码，还是资产，谁都能来接管。自动驾驶的汽车司机也能接管，只是没必要。

“倒车式”创新

AI 科技评论：正好也衔接我们接下来的话题。现在大家都在讨论：为什么Claude Code能在这么短的时间里积累起这么大的声量，获得这么多用户的转化？是、因为它是Anthropic的产品？还是说它在产品形态或能力上真做出了重大突破？

李亚飞：我的体感可能会更强一些。我觉得它在形态上是“开了倒车”的——它回到了 30 年前命令行程序那一套，甚至可以说是 GUI 出现之前、60 年代那种技术形态。产品定义上是倒车的，但是程序员是相对能接受的。

它之所以爆火，关键在于它非常充分地激发了 Claude 4.0 的智能能力。它几乎不需要很长的上下文，也不依赖太多的人类提示或“补丁”，就能产生足够好的智能性。所以我觉得这是一个真正的 Agentic 工具。

基模在ChatGPT3.5那个时代，它只能做补全，而且还只是一些小文件，所以只能做Copilot，后来到了Claude 3.5，大家发现我们能跟AI有一些基本的对话了，可以做出一些功能性的能力了，现在到了Agent的阶段，但是AI也没强到那种程度，只能算是初中级工程师。

我认为 CLI 最终不是未来，未来一定是云端、多工协作的模式。Agent就像是一个工程师，以后雇一个工程师不满意的话，就雇三个、五个，多开多干。

AI 科技评论：我觉得“倒退”也未必是坏事。宿文老师，您怎么看？

宿文：这个问题可能亚飞总更专业一些，因为我自己离开写代码已经挺久了，严格来说我既不是Claude Code也不是 Cursor 的典型用户。

从我们内部的观察来看，真正的源头，还是看谁掌握模型。lovable也好、Cursor也好，一定程度上都是Claude的token的二道贩子。特别是在这样一个早期且剧烈变化的阶段，握有底层模型能力的一方必然占据更多主动权。我认为归根结底，今天还是谁握着模型、谁的主动性就更强。

AI 科技评论：陈石总以前做过CTO，您怎么看Claude Code？

陈石：我觉得Claude Code 之所有受到好评，主要原因首先是它的上下文工程做得好，毕竟没有人比模型厂商更知道如何全面、有效率地向模型提供它完成任务需要的Prompt。其次是Claude Code刚好有些取巧，它当前只提供命令行界面（CLI），愿意且有能力使用CLI来编程的人大部分是有经验的程序员，而这批人更有能力取得好的体验。

据Anthropic公司的统计，Claude Code上80%的左右使用的是Agent功能，而Cursor上只有50%，这也是CLI界面上编程序的特点，它相对于图形界面（GUI）是不友好的，做深度复杂的编程是很难的，程序员要在这么多文件上来来回回切来切去也很麻烦，所以大家更愿意去用Claude Code的Agent功能，这也让它有了更大的声量。

李亚飞：对一些老程序员来说，Cli做开发比较快。

陈石：还有我觉得前端还是有很多价值的，否则Google也不会发那么多钱去收购windsurf，这可能也是我们应用创业的一个机会吧。

AI 科技评论：我下一个问题就想请陈石总先谈谈——Agent 未来有没有可能成为研发流程里的核心 Controller 或 Planner？从您目前的观察来看，这个路径是否已经成为业界的共识？

陈石：从趋势上来看，确实有越来越多创业公司涌向 Agent 路线。Copilot 这个方向现在难度太高了，海外大厂都在做，比如微软的GitHub Copilot ，此外Cursor这些领先的创业公司也做得不错。你再去从头做一个 Copilot，几乎没有多少空间了。所以很多人选择了 Agent 这条路线。

Agent 作为 Controller 和 Planner，虽然当前取得一些进步，但是现在还谈不上成熟。你让它去做一个深度的任务规划，或者真的做一个“项目经理”角色，其实还是非常困难的。何况让它写对逻辑性和一致性要求非常高的代码，稍微复杂一点可能连编译都通不过。

虽然 Agent 的方向是对的，但要走通它还面临很多挑战。未来模型能力会提升，这是肯定的；但在这个过程中，我们必须有一套流程设计，让人类能够参与其中，承担监督和反馈的角色。哪怕是做标注、做奖励反馈，只要能把人类嵌进 Agent 的工作流中，Agent 的表现就会更好。

现在最大的问题是，Agent 做完一整套操作之后，大部分情况要么完全跑不通，要不跑通但不符合用户需求，且普遍存在用户反馈滞后稀疏的情况。这种反馈结果非常不利于模型做强化学习。所以关键还是流程设计：要让人类愿意提供高质量的反馈，让模型在过程中就能获得奖励信号，这样才能真正训练出一个好用的 Agent。

AI 科技评论：亚飞总您怎么看？现在做 Agent 是不是已经成为行业共识？

李亚飞：我觉得“成为共识”可能还言之尚早。我今天最大的任务，就是想告诉大家——Agent 应用，尤其是在 Coding 领域，已经可以用了。

现在很多人还是将信将疑的。其实那么多大厂、那么多团队，就像微软早早地做了 Copilot，结果看着Cursor做了起来，我觉得其实是大厂内部没有那么笃信。

你看中国的大厂，还在搞IDE呢，Cursor都被弯道超车一个月了。有些大厂还希望你把模型私有化进去，做Copilot。

宿文：我们从第一天就认为，Agent肯定是未来，但是就怕它不是这一波泡沫中应该出现的事儿呢。

我觉得Coding Agent在这一波技术周期还是能落地很多场景的，但是现在仍然是完全不成熟的状态。我们自己内部讨论的时候，有人说超级动态planning，要让产品很灵活，效果又都有保障，结果我们发现，底层的给Agent做的infra是完全不完善的。我们期待会有一些更好的Agent框架，如果出现了，我们就快速地拥抱，同时我们自己也在做一些突破。目前来看还是有瓶颈的。

AI 科技评论：那你们有哪些尝试呢？

宿文：我们目前最核心的探索，其实还是聚焦在“如何更灵活地满足用户的个性化需求”上。因为如果你要提供一个端到端的方案，首先是你整个技术栈得非常完整，其次是要面对用户非常长尾分散的需求。

现在不管是Manus还是Devin提出的一些东西，我们都不太能够借鉴得上，我们先一步步地做自己的生成式软件agent架构，未来留待拥抱更多的灵活性。

AI 科技评论：确实，agent 的能力和未来的落地还存在很多挑战。请陈石总从更宏观的角度聊聊，您怎么看待 AI Coding Agent 生态的发展？

陈石：我觉得可以抽象为两个关键方向：第一，是基础设施层面的统一，尤其是要为 agent 或 AI 特别设计的一整套基础设施；第二，是协作与监督工具的完善，让人类和 AI 能更高效地协作，同时对 AI 有一定可控性。

比如 OpenAI 的 CodeX、Claude Code 模块等，都会配套一些沙盒环境。这类“安全可控”的运行环境非常关键，因为最好的验证方式，其实就是让 Agent 在虚拟环境先跑一遍，这类基础设施非常重要。我觉得这一类产品会慢慢成为一个既安全又能形成标准的一个运行环境。还有就是用户端的长期记忆和上下文共享的机制，包括MCP、一些向量数据库等等。

再说协作监督工具。如何让一个逻辑能力弱一点的用户，也能把需求准确表达出来？这个过程需要一整套引导机制。

还有一个特别重要但现在缺失的东西是可视化调试工具。现在的大模型像个黑盒，用户不知道它为啥出错、哪里错了，就跟自动驾驶的 corner case 一样，你没有办法预警，也很难修复。如果能有像仪表盘那样的可视化系统，让人可以在高层级上看清 AI 的“决策路径”，那人就能更有效地“标注” agent 的行为，形成一个更健康的闭环反馈系统。

所以总结来说，基础设施统一和协作监督机制，是 agent 生态目前最需要补足的两大块。

AI 科技评论：那这些工作应该主要由谁来做？是 Agent 开发者、平台方，还是说这其实是很适合创业团队切入的机会？

陈石：关键是判断哪些模块是适合做在应用层的，哪些模块适合在模型层做。像我们投资的做一体化 Agent 工作环境的产品，就是一个创业团队在做。你可以从 Infra 层切入，也可以从应用层往下扎。比如 Cursor 本身做了很多前端上的交互设计，它也在做一些记忆机制、上下文优化，还有数据收集与回溯能力，这些也都在增强 Agent 的协作能力。所以说这些事，应用开发者和平台方其实都可以做。

AI 科技评论：宿文总，您在市场上有看有接触过这样的公司，或者是有这些需求吗？

宿文：我们从 2023 年底决定切入这个领域开始，就特别关注，在未来的研发与商业化过程中，会存在哪些“生态型卡点”会让这种不确定性非常高，所以前期规划的时候我们尽可能把能规避的都规避了。

我们看到的比较大的，我们尝试解决，也希望产业链的小伙伴能共同解决的一个难点就是，生成式数据库。因为我们今天做的大多数场景，仍然集中在 CRUD 类型的系统开发上，而这个场景上最重要的就是数据库。

我们今天做的还是相对简单的独立系统，但是人类至少积累了三四十年的数据资产，大量企业从 90 年代就开始使用 ERP 系统，里头积累了三四十年的合规数据、进销存数据，后面一代代的系统都是在这个系统上去做增量开发，或者叠加的。那么大模型时代生成的内容跟历史内容之间的交互关系在哪儿？这是我们认为在端到端这件事情上比较大的卡点。

李亚飞：大家今天聊到了很深的场景话题。我们相信“端到端生成”就是未来，在AI能力不断变强的情况下，端对端的核心逻辑就两个：第一，是一个真正的Agent在工作。未来一定不是 prompt based 的一次性交互，而是一个智能体，真正作为开发者参与到项目全流程中。第二，今天人类在架构设计、系统认知上的优势仍然远超 AI，所以我们就应该把这些难点提前替 AI 处理好，给它创造一个“可控的工作空间”。

哪些难点呢？宿文刚才说的数据库是一个，还有就是框架选型，根据需求匹配最合适的语言架构。我们帮助Agent把这个运行环境给准备好，对于非专业工程师来说，这就是Agent的工作区。万事俱备，我们最终才能塑造一个真正意义上的端对端APP的交付。

先提效，再提质

AI 科技评论：那下一个问题是一个现实但可能略显“悲观”的议题：我们现在看到 AI 在生成代码的过程中，会大量制造“垃圾代码”，因为成本太低，导致很多大厂的代码库越来越庞杂、难以维护。这是一个真的需要担心的问题，还是只是个“杞人忧天”？

李亚飞：这个问题绝对是现实存在的，而且已经非常广泛。因为今天code写起来实在太容易了，大模型倾向于写点code去帮你解决问题，我就亲眼见过，它写了一个不work，它顺手在下面又写了一个，最后一块交给我了。

解决这个问题的思路并不复杂，人类是有版本管理的，代码推送之后是要确认的，如果你是一个比AI更好的工程师，你就在确认环节把它这些不太好的方案干掉。

其他的解决思路还有，在 prompt 设计和上下文设计里面要充分地让 AI 知道不要瞎写东西，尽可能多约束AI，随时打断。

宿文：我们其实完全没担心过“生成垃圾代码”这件事。这种现象在历史上都出现过。比如在知识传播这件事上，从古代口耳相传到现代信息爆炸的时代，我们也没担心过这个事儿。

当然，这个类比未必完全贴切。但如果我们要精准地回答这个问题，其实很简单：你不进生产环境，代码再脏也是工程师的事情。至于工程师在这个过程中如何转变角色、如何管理质量，那是另一个话题。

所以，我们完全不会担心这会影响到软件的实际使用者。这个问题是可以解决的，而且应该在提升效率之后再回头解决质量问题。就像生成式数据库的问题，我们会基于存量的各种各样的数据库构建今天的系统，但是我们知道未来新的IT架构会倒逼新的 Infra 产生。

同样的一个字段，在不同的软件开发厂商的数据中可能明明完全不一样，那就需要后端程序员通过API等业务理解去做的。大模型去跨系统去理解这个事情是很难的，一定要做语义贴合，不然成本太高，所以我们只能停留在上一代的数据库形态上。但是人类有个特点，只要倒逼到那一步，大概率也有聪明脑袋能解决。

陈石：我也同意大家的看法。这个问题是存在的，但不需要过度焦虑。放眼整个互联网，我们已经充满了“垃圾数据”了，但并没有因此停滞。更重要的是，代码和文本不同，它具有结构性、逻辑性和可验证性——你写得好不好，其实能跑一遍测试就知道了。

在编程世界里，有很多方法论可以帮助我们做代码质量筛选，比如 lint 工具、单元测试、代码审查等等。更重要的是，AI 现在也能调用这些工具自动检测代码。我相信有朝一日，AI 写出的代码质量会超过大部分普通程序员。

李亚飞：大家为什么会关心这个问题呢？我觉得本质上，软件是一种负债，生产出来的软件，你就得维护它，你不维护它就像一个生命一样就要死掉了。如果你写出来刚刚好能work的代码，没有及时消除你的债务的话，它就指向了一种持续维护的成本，这就有个隐形的雷。

软件工程里面这个问题还是比较严重的，必须要消除掉。我们不能说这一代程序员写出来就不管了，等下一代程序员来了接手这个“屎坑”。

陈石：这个问题最终的解决不在于代码上，有可能就在于你的prompt提炼出来的产品规范上。如果产品规范定义得足够优质，下一次你换个架构或换种编程语言去重写一遍代码问题也不大了。

李亚飞：站在产品角度，我们把它叫做产品架构，站在技术角度，我们把它叫做技术架构，这是两位一体的东西，也是一个好产品的核心骨架。只要骨架还在，外围的代码烂一点关系不大。

好的技术，是需求的释放

AI 科技评论：最后一个问题，我们今天讨论了很多 AI Coding 的进展。那放眼未来，它可能会彻底改变人类与代码的交互方式。你们认为程序员的工作会发生什么样的变化？映射一下我们今天的主题，AI 颠覆的第一个职业，会是程序员吗？

宿文：好的技术一定是通过创造供给的方式，激发出更多需求。当然，第一阶段一定是服务于“已有程序员”的——让他们用得更爽、更高效，尤其在一些高度垂直、封闭的场景，比如半导体领域的 firmware 这套软件的开发，这不可能是大模型能做的事情，反而是这些程序员可以利用好 AI，工作质量可能更上一层楼。所以会有很多垂类场景长期存在。

但在另一些场景中，程序员的角色可能真的会被“再定义”。比如很多行业其实需要的只是把业务需求“翻译”为软件，但因为供给的效率、供给的成本、供给的质量等等限制，这个需求长期被压抑。现在有了 AI，门槛降低了，大量非技术用户就能用 token 去完成代码生成，触发出新的增量市场。这些也是我们的商业模式的范围。

既然以后所有的代码是依赖于token实现的，那就把它变成infra，变成infra的时候，Coding的收费逻辑也会发生改变的。这些是5年之内可以预期到的事情。

AI 科技评论：那亚飞总，您是程序员出身，肯定感受更深。

李亚飞：是，我本身就是工程师出身，所以体会确实很直接。我觉得可以用一句话总结：打孔的人不需要了，但懂打孔机原理的人仍然有价值。早期的程序员其实就是在打孔、输入程序，那种工种确实消失了。

没有AI干得好的人，确实不需要了。但好消息是——懂底层原理的人，在新的体系中会更加值钱。他们会成为“维护打孔机的人”，会更快地适应新范式。同时，这也意味着新工种的诞生。这是一个新的工作机会，因为生产软件变得更便宜了，个性化软件需求时代会到来。新时代生产软件的人，我姑且称之为“业务逻辑师”。

陈石：未来发展的瓶颈就变成了人和AI结构化的沟通。今天程序员真正写代码的时间，其实只占工作量的 20%-30%，大多数时间花在沟通、逻辑整理和系统设计上。如果模型越来越强，它不仅能写出高质量代码，甚至可以自动挑选最合适的语言、架构和实现方式。那时候，真正的“源代码”可能是你在AI帮助下写出来的产品规范文档。

这份“文档”可以是自然语言、流程图、界面草图的组合，它的结构清晰度越高，AI 实现的准确性就越好。而未来的 IDE，也许不再是代码编辑器，而是一个“集成思维澄清器”——帮你厘清思路、表达逻辑、形成规范，剩下的都交给 AI。

到那时，程序员的核心能力，可能不是写代码，而是能不能清晰表达需求、构建逻辑架构。这也印证了刚才亚飞总说的“业务逻辑师”这个概念——甚至我觉得一些逻辑性强的职业，比如律师，都可能在这个新工种中如鱼得水。

AI 科技评论：三位的回答其实都不约而同地指向一个趋势：未来的程序员，也许不是“代码工匠”，而是“业务翻译者”和“需求架构师”。写代码这件事，逐渐被抽象掉，真正有价值的，是结构化表达与逻辑构建的能力。

至于“AI 颠覆的第一个职业是不是程序员”——可能不是简单的“被替代”，而是彻底的“角色转变”。

非常感谢宿文老师、陈石老师、李亚飞老师，今天的分享非常深入且富有启发。这次圆桌分享到这里就正式结束了，谢谢大家！