作者丨马晓宁、郑佳美

编辑丨陈彩娴

当 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 科技评论进行了不改原意的编辑整理：

1. 从辅助工具到工程变革

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 工程师时代的起点。

2. 好的技术，是需求的释放

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

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

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

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

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

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

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

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

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

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

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

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

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

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是不是最好的形态了。

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

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会公开代码吗？

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

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

完整直播回放：

Summary

人工智能编程工具如GitHub Copilot、Cursor和Claude Code正在改变软件开发领域，引发了关于程序员是否将成为首个被颠覆的职业的讨论。目前，人工智能在处理原型和小型项目方面表现良好，但在应对复杂的企业系统时仍面临挑战。程序员的角色正在发生转变 — — 从编写代码转向定义需求、构建逻辑架构以及管理由人工智能构建的系统 — — 这为“业务逻辑设计师”等新角色铺平了道路。