喝点VC｜a16z合伙人：开发者市场或成为AI首个真正意义上的万亿级市场；当前模型最致命的缺陷是永远不愿承认"我不知道"



图片来源：a16z

Z Highlights：

• 问题越常见，所需上下文越少。比如"写个博客网站"这类典型教学案例，模型生成这类代码易如反掌。但面对缺乏训练数据的新颖需求时，你必须精确描述需求、提供API文档等完整上下文，难度会指数级上升。

• 未来更重要的可能是：阐述问题定义、理解算法基础、设计系统架构与数据流。而具体代码实现细节，比如如何优化for循环，将变成更专业的细分领域。

• 计算机科学教育之所以不可替代，正是因为这些底层概念（比如"进程"）的认知需要系统训练。但同时，现有大模型之上还没形成类似操作系统的范式框架。

• 当模型具备复杂推理能力后，可能会分层处理：一个模型负责内部思考，另一个专门生成用户界面输出。比如聊天型、旅游向导型、JSON生成型模型各司其职——推理层与输出层最终可能解耦独立。

a16z (Andreessen Horowitz)是一家风险投资公司，以其多元化的投资领域著称，被投资公司包括Airbnb、Meta和Twitter等。本次访谈由a16z于2025年5月发布，Guido, Yoko以及Matt三位合伙人分享了关于传统编程和最近的vibe coding编程模式的看法。

AI编程生态跃迁：万亿美元市场的效率革命

Matt Bornstein: 我们基本可以确定，目前编程是AI领域的第二大市场。如果我说错了请纠正——纯聊天机器人应该排第一，编程排第二，这是单纯看数据的结果。

Yoko Li：但消费者市场是很多不同领域的集合。

Matt Bornstein：完全正确。

Guido Appenzeller：这是我的市场定义方式。如果看真正同质化的市场，编程可能确实是第一。

Yoko Li：编程市场比陪伴型应用更大吗？

Guido Appenzeller：是的。

Yoko Li：我也这么认为。

Guido Appenzeller：现阶段确实如此。可能要看如何归类像ChatGPT这样的产品，某种程度上它也被用于情感陪伴。

Matt Bornstein：现在大部分ChatGPT的使用场景其实属于陪伴型。

Guido Appenzeller：确实如此。

Matt Bornstein：说到底，人类是更渴望创造事物还是寻找爱情？这两者可能难分高下。AI编程有个独特优势常被低估：它其实延续了用户既有习惯。比如大家遇到难题时，原本就会去Stack Overflow找解决方案，这已经成为肌肉记忆。现在AI模型只是提供更高效的解决方案——毕竟业内早有玩笑说过去X年大部分代码都是Stack Overflow写的，未来这些需求可能都会转向AI模型。

Guido Appenzeller：哈哈很难说这是不是玩笑。

Matt Bornstein：可能真不是玩笑。GitHub Copilot这类产品做了开创性工作，引导用户从Stack Overflow转向AI模型。像Cursor这样的公司做得更出色，他们巧妙利用了用户既有行为习惯，在现有市场中推出了革命性产品。

Guido Appenzeller: 我认为还有一个关键点：开发者一旦掌握最新AI技术，首先会解决自己的痛点。他们最清楚日常工作中的问题，所以会主动构建工具优化流程。

Yoko Li: 开发者天生是新技术的尝鲜者。他们喜欢折腾工具，又"懒"得重复劳动，自然拥抱能提效的技术。此外，编程市场的优势在于结果可验证——输入输出明确，不像用户偏好等问题难以量化。甚至很多其他领域的问题都能转化为编程问题。比如艺术生成本质上也是编程：Adobe Photoshop早年在AI还没火的时候就用机器学习控制笔刷轨迹，矢量图生成同样是代码逻辑。编程的魅力在于能将现实问题转化为机器可处理的范式。

Guido Appenzeller:市场规模也至关重要。全球3000万开发者，假设人均年创造价值10万美元，总量就是3万亿美元。金融机构数据显示，仅部署基础版编程助手就能提升15%效率，而我认为潜力远不止于此——若全球开发者效率翻倍，释放的价值相当于再造一个苹果公司。去年AI领域年度投资约2000亿美元，和3万亿美元潜在价值相比简直微不足道。更何况开发者市场易于切入，很可能成为AI首个真正意义上的万亿级市场。

Matt Bornstein: 这个观点很棒。全球每个机构的软件开发者都创造巨大价值，AI编程正是切入核心生产力的捷径。Guido提到的自我强化效应也很关键——不仅是效率提升，AI模型还能催生全新应用，形成良性循环：更好的编程模型能开发更强大的AI应用，而这些应用又能反哺模型进化。

Guido Appenzeller: 当AI革命尘埃落定时，开发者这个职业会变成什么样？现在我已经体验到变化：写代码时更多是在写需求文档，和AI讨论实现方案。简单功能可以直接让AI生成代码，我只做审核。未来流程会完全重构吗？我们会集体转型成产品经理，只写需求文档让AI编程，偶尔调试就行了吗？目前有共识吗？

Yoko Li: 哈哈，或者全员转行当测试工程师？专门检查代码是否符合需求。

Matt Bornstein: 这反转太讽刺了，我们当初可都是为了不当测试才入行的！Guido说的很有意思，不如大家都聊聊自己现在怎么用AI编程？分享些具体案例？

Guido Appenzeller: 没问题，虽然我是这里最不常写代码的。过去六个月使用方式变化巨大：早期就像用升级版Stack Overflow——遇到问题把提示词扔给ChatGPT，复制代码到编辑器测试运行。

Matt Bornstein: 这有点像是Stack Overflow的替代品，就是当你不可避免地遇到问题时，不用去Stack Overflow寻求帮助，而是去ChatGPT聊天，它实际上会给你返回代码。

Guido Appenzeller: 本质还是复制粘贴，只是换了数据源。

Matt Bornstein: 这大概是六个月前的事？这也许九个月前吧。

Guido Appenzeller: 接下来更进阶的是IDE集成工具，比如GitHub Copilot和Cursor。它们实现了真正的自动补全——不再是零散提问，而是嵌入工作流。从单行代码补全，到整段代码生成，再到独立聊天窗口进行深度讨论。现在甚至能通过IDE调用命令行工具，比如直接说“用UV帮我初始化Python项目”，AI就能自动执行命令。

现在我的开发流程是这样的（非生产环境，只是尝试一些新东西）：先写一份粗略的需求文档，内容比较抽象。然后让模型（比如GPT-3.5/4或Gemini）评估可行性，提出疑问并细化需求。过程中会遇到各种问题，比如需要API密钥，或是架构决策——用数据库还是本地文件存储？这种持续对话能帮我理清思路，AI就像个思维陪练。直到需求足够明确，才会让AI开始写代码。同时需要给模型大量上下文：我的Python编码规范、注释习惯、面向对象风格、类结构设计，是否使用类型注解等等。本质上是在向AI灌输开发方法论，通过反复沟通共同构建解决方案。这是我的编码方式，你们呢？

Yoko Li: 比起半年前，现在用编程助手时我会提供更多实时信息。之前主要依赖模型的基础知识——比如问它今天日期，永远显示2023年（模型训练截止时间），而我给的参数已经是2024年的了。现在工作流有两种变化：一种是结合项目管理工具，比如把Linear上的任务直接导入Cursor，让AI先尝试实现；另一种是主动查询——以前要手动复制文档到Cursor窗口，现在直接说"用FireCrawl搜索最新Clerk文档"，它就能自动抓取并解析。

Guido Appenzeller: 用MCP协议实现的吗？

Yoko Li: 底层用了MCP，不过对用户是透明的，可能是工具调用。重点是现在能更好对接现实数据源。

Matt Bornstein: 你们太有计划性了！我通常是周六晚上突发奇想，把天马行空的应用创意丢给Cursor硬刚。发现它特别擅长处理复杂度高、容易让人抓狂的部分——比如前端开发，比如人们现在使用的所有CSS类，边距和内边距。我不认为有人能记住所有这些。

Yoko Li: AI现在会居中div了吗？咱们应该做个居中div专项测试！

Matt Bornstein: 绝对有必要！做一个居中div的网上教程。这是莫名其妙的问题，明明有五种方法居中元素，我却永远记不住。好在AI现在确实能搞定。但遇到冷门库或复杂函数调用时还是容易翻车，所以Yoko说的FireCrawl这类实时抓取文档的功能太实用了，我之前总得手动复制文档片段。

Yoko Li: 我有时直接把Milify文档丢给Cursor。他们官网有LLM专用扩展说明，输入URL让AI读取后就能直接调用。

Matt Bornstein: 你们用AI编程翻过车吗？

Yoko Li: 不算翻车，但结果受AI Agent行为影响很大。比如有个工具能生成漂亮页面并返回React组件，有次我让Cursor根据它的输出开发。结果Cursor看了代码说"不错，但按我的方案改改"，完全没采纳原方案——两个AI Agent居然在"较劲"，特别有意思。

AI编程革命：上下文赋能、工具进化与模型局限的碰撞

Matt Bornstein: Yoko，你在MCP上做了很多工作，你认为这目前有什么影响？

Yoko Li: MCP的核心是为LLM提供最相关上下文。现在各种MCP服务器（比如Linear/GitHub的MCP）都能被调用，支撑了我刚才说的体验。工具调用只是技术实现细节，关键在于精准输送上下文——给模型最需要的背景信息才能更好协作。

Matt Bornstein: 这类IDE工具是否会让资深开发者更受益？过去有个争议：AI编程擅长做酷炫demo帮助新手快速上手，但被戏称为"技术大胡子"的架构守护者们（负责系统稳定和架构设计的人）往往持怀疑态度。你觉得这种深度集成能打动这些核心开发者吗？

Yoko Li: 这取决于资深工程师的专注领域。擅长快速实现创意的应用工程师能更好利用这些工具，但像专攻分布式系统优化的顶尖专家可能暂时难受益——毕竟AI无法实时获取分布式系统状态，很多问题仍需人工干预。不过随着上下文窗口扩大和工具调用能力提升，未来会有改观。目前IDE支持的工具数量有限（比如40-50个），这天然限制了AI能调用的上下文和工具范围。

Guido Appenzeller: 我发现一个规律：问题越常见，所需上下文越少。比如"写个博客网站"或"简易电商系统"这类典型教学案例，网上有海量样例代码，模型生成这类代码易如反掌。但面对缺乏训练数据的新颖需求时，你必须精确描述需求、提供API文档等完整上下文，难度会指数级上升。

Matt Bornstein: 最气人的是AI总是自信满满地给出错误答案！我经常发现它推荐不存在的函数，还信誓旦旦说"这个函数完美符合需求"，结果一查压根不存在。

Guido Appenzeller: 更糟糕的是它陷入这种状态后很难纠正。你指出函数不存在，它反而会幻觉生成另一个虚构函数。

Matt Bornstein: 就像在说"抱歉，这里还有一个不存在的函数可能适用"。

Guido Appenzeller: 当前模型最致命的缺陷是——永远不愿承认"我不知道"。

Yoko Li: 如果训练时引入强化学习（RL），让模型在模拟环境中调试分布式系统，能改善这个问题吗？

Guido Appenzeller: 极端情况下，比如你要为全新架构芯片开发首个驱动（全球零训练数据），AI还是无能为力，毕竟模型目前不具备真正的创造力。但好消息是，这类场景只占软件开发的0.01%，像ERP系统开发这种有海量数据支撑的领域，AI工具已经极具威力。

编程平权：技术民主化浪潮下的教育重构与范式革命

Matt Bornstein: 我们还没深入聊"Vibe Coding"——现在非开发者也能写代码了，这很酷不是吗？就像打破技术壁垒，程序员不再是必须的"电脑祭司"。让普通人直接操控计算机，而非只能使用现成软件，是极具潜力的方向。

Guido Appenzeller: 但有个关键问题：这适用于所有规模吗？就像人人能搭棚屋，但建摩天大楼可不行。

Matt Bornstein: 这正是重点！现在大家用网站生成器或Cursor做的demo，可能只是周末小项目。但假设其中一部分人逐渐深入，用完全不同于我们这代程序员的方式开发复杂应用——我对此非常乐观。新鲜血液会用全新视角创造前所未有的软件形态。

Yoko Li: 这让我想到2000年代的博客浪潮。当年人人都要建博客，现在WordPress依然活跃，这个我确实没想到。现在的Vibe Coding就像全民开发个人软件：从静态内容到个人CRM管理社交关系。虽然不深但实用。Martin有句话很对："你至少得懂比当前抽象层低一级的技术"。我在思考——对Vibe Coding者来说，底层是代码？是IDE？还是其他？很好奇您们的想法。

Guido Appenzeller: 这是个极好的问题。让我重新表述一下：未来从事软件开发的人究竟需要学习什么？是更底层的知识？还是横向扩展的能力？有人认为"学计算机科学已无意义，重点该转向社交情感学习"，我对此持保留态度。

Matt Bornstein: 这种论调每隔20年就会轮回出现。

Guido Appenzeller: 确实存在周期性。坦白说，我完全无法预测5年后计算机科学教育会变成什么样。以计算领域为例，当人类从手工计算转向Excel时，簿记员转型成了会计师——底层数据录入变得次要，高层抽象概念处理能力成为核心。按照这个模式推演，未来更重要的可能是：阐述问题定义、理解算法基础、设计系统架构与数据流。而具体代码实现细节，比如如何优化for循环，将变成更专业的细分领域。

Matt Bornstein: 这感觉就像我们在等待某种技术突破不是吗？而且其实传统计算机本科教育并不追逐最新潮流——比如很多课程会教汇编语言。

Yoko Li: 反而教的全是最古老的技术。

Matt Bornstein: 没错，从底层开始。我甚至上过处理器设计课，虽然我是最差劲的计算机工程师，体验过用门电路搭处理器。我们还学过Lisp、文件系统、操作系统，当时Java还是前沿技术。人们很容易认为AI就是建立在传统之上的"下一代技术"，编程教学只是出于历史传承。但我不确定这个逻辑是否成立——过去几十年新增的技术层都是真正的编程接口，而AI本身并非编程接口或框架，更像是现有工具的增强助手。这让我思考：我们是否在等待真正的范式变革？比如通过自然语言提示直接生成代码的终极形态？现在的AI Agent只是起点，未来可能彻底重构编程方式。这都是我好奇的东西。

编程范式跃迁：AI抽象层与传统形式化语言的共生演进

Guido Appenzeller: 目前AI还称不上是更高级的语言抽象，但未来可能吗？

Matt Bornstein: 好问题，您觉得有可能吗？

Guido Appenzeller: 我认为我们还没找到答案。假设用LLM重构传统编译器设计，思路会完全不同——比如能用自然语言精准定义某些逻辑，并直接作为编译器输入，这可能引发质变。

Yoko Li: 这里有个类比：现在企业开发Agent系统时，你会发现AI Agent的工作模式像极了操作系统里的进程管理（创建子进程、任务分配、资源协调）。

计算机科学教育之所以不可替代，正是因为这些底层概念（比如"进程"）的认知需要系统训练。但同时，现有大模型之上还没形成类似操作系统的范式框架。

Matt Bornstein: 形式化语言存在是有原因的，无论是编程语言还是规范语言。人类需要高表达力的工具来设计软件或其他事物。因此Python这类语言不会彻底消失——正如Yoko所说，你必须至少理解低一层的抽象逻辑。有趣的是，某些语言可能因更适配AI而流行（目前Python和JavaScript领先），但尚无定论。工具链发展也值得关注：Python生态正涌现大量新工具，这对AI插件的协同效果大有裨益。总之，传统编程不会完全被取代。

Yoko Li: 我认为需要了解底层抽象的核心逻辑在于系统优化。就像过去用Java写计算器无需懂JVM，但优化多线程时必须掌握。Vibe Coding同理：搭建营销网站无需懂CDN缓存，但规模化服务时必须了解底层机制。关键在于——计算机能力受形式化语言约束，不同抽象层相互嵌套。想真正掌控系统，就必须理解这些"调节旋钮"对应的语言。Guido你怎么看？

Guido Appenzeller: 我认同形式化语言不会消亡，因为它们本质是最简明的意图表达方式。自然语言往往不够精准，需要冗长描述才能达到相同效果。有趣的是：当AI具备充足上下文（比如人类语义理解、特殊符号辅助、跨文档调用能力）时，是否能针对特定问题精准翻译自然语言描述？目前某些领域已实现（比如日常AI编程），但能否由此发展出混合型新语言仍是未知数。

Matt Bornstein: 你对"复杂"的区分很精妙——既可指系统本身难以预测，也可指使用门槛高。编程语言看似难学，实则结构清晰（可用语法树完全描述）。而AI编程虽易用，底层却更复杂（就像戴面具的绿色巨兽梗图）。如何平衡？或许需要混合方案，比如Cursor团队提倡的"形式化规范"——正如Guido所说，未来开发者将更多从事精确需求描述的工作。

Guido Appenzeller: 这就像你和AI之间的协同优化过程——从模糊的概念雏形，逐步淬炼出可落地的精准需求文档。

Yoko Li: 深有同感。最近和一位传统Vibe coding者交流，我问他是否需要代码界面（比如输入提示词生成代码），他的回答很有趣："看到AI生成大量代码让我有掌控感，但当我想自己修改时却无从下手"。这说明AI生成代码与用户操作层之间存在断层，需要设计中间产品让用户也能调节底层参数。

Matt Bornstein: 这不仅是新手问题。就算我们尝试Vibe Coding，经过四五轮迭代后想修改代码也会陷入困境——代码结构完全黑箱化。

Yoko Li: 我在用Blender MCP时深有体会。作为Blender新手，通过Cursor的MCP服务器轻松生成A6Z基础设施微缩模型后，想调整3D模型结构时直接懵了——既不懂操作逻辑，也不明白建模原理。这种AI能力与用户认知的断层地带，恰恰是创新机会所在。

Matt Bornstein:最酷的是，AI正在软件编程中创造前所未有的"上下文层"和"意图层"。比如用AI迁移旧代码——银行想淘汰COBOL系统几十年了，但AI只能辅助而非根治问题。它能转译COBOL到Java，但几十年来系统早已面目全非（从机票预订演变成HR+订票+煮咖啡系统），原始开发者和文档都已消失。更值得关注的是：如果用AI开发新系统，开发过程中的意图记录会被自动留存。这相当于免费获得了一套元数据，用全新方式捕获软件设计意图。未来若普及，将形成革命性的开发范式。

Guido Appenzeller: 这几乎像是更高阶的语言抽象？

Matt Bornstein: 但有本质区别——它无法直接编译....

Guido Appenzeller: 某种程度算是吧。

Matt Bornstein: 我认同。

Guido Appenzeller: 你提到了一个关键痛点。最近和几家大企业交流，他们正用AI迁移大型机遗留代码（如COBOL、PL1）。问题正如你所述——仅看旧代码根本无法理解原始意图，直接转译会保留旧语言的怪异特性。比如Java有更现代的语法结构，但AI可能沿用COBOL的老式逻辑。目前最有效的方法是先通过旧代码反推出需求文档，再用AI根据文档重新实现。这样生成的代码更简洁现代。

Matt Bornstein: 这两个环节都离不开AI辅助。

Yoko Li: 这很有趣，因为我实际上刚刚在想，重写现代软件（ZP注：这里指过去十年内的软件）其实要容易得多。从Angular转换到React实现起来要容易得多，尤其是这两个框架Agent都很熟悉。但如果状态……

Guido Appenzeller: 从PHP转到Angular有点难。

Yoko Li: 比如Laravel框架的迁移就相对顺利，具体难易度还是取决于框架类型。但当系统状态横跨多个子系统时就麻烦得多——需要先进行系统探查，或者让AI Agent具备这种探查能力。另外硬件环境特殊性也是难题，比如Docker容器需要特定内存配置才能运行。这些细节往往早已丢失，除非能对运行时环境做完整快照（记录运行方式和资源需求），否则这类系统迁移极其困难。

Matt Bornstein: 我已经提前感受到噩梦场景了——生产环境崩了，只能翻ChatGPT聊天记录猜当初开发者想干嘛。

不确定性新边疆：AI混沌系统与开发者工具链的重构挑战

Matt Bornstein: Guido，有个有趣的问题——如果把AI视为应用程序的基础组件（而不仅是编程工具），它似乎大幅扩展了软件中不确定性和非确定性行为的边界。回想早期单机软件时代，开发者能精准预判执行结果；网络时代引入了不可预测性，但尚能用术语描述和应对。如今AI带来的不确定性更甚——无论是用AI编写代码还是集成到软件中，结果都充满未知。你觉得这种类比合理吗？网络时代的经验能否帮助我们应对AI带来的挑战？

Guido Appenzeller: 我认为部分合理，但我们尚未完全消化这些经验。网络系统曾带来超时等新故障模式，催生出重试机制；分布式数据库需要处理原子性和回滚，复杂度陡增。直到今天，某些设计模式仍缺乏成熟的软件架构方案。

Matt Bornstein: 是否有些问题本质上无解？

Guido Appenzeller:根本问题或许无法解决，但至少能让开发者更轻松——工具的本质就是为开发者缓冲冲击。有趣的是，当AI模型温度参数设为0时，输出其实是确定性的（相同输入必有相同输出）。真正的挑战在于输入的微小变化可能导致输出剧烈波动，这本质上是混沌系统的特性。

Matt Bornstein: 用户可能在文本框输入任意内容，系统就变得混沌失控。过去只需防范SQL注入（比如检查单引号），现在任何文本输入都可能引发意外。

Guido Appenzeller: 没错，比如用户输入"忽略之前所有指令"就能破坏预设逻辑。

Matt Bornstein: 但你的观点很有趣——或许我们不该压制所有潜在故障（比如网络超时），而是向开发者开放系统底层能力，使其能自主应对。

Guido Appenzeller:这只是一方面，还需改变预期。某大银行部署文本生成系统时，要求大语言模型绝不能提供投资建议（哪怕隐晦暗示）。但这是个无解难题——可通过优化降低概率，却无法根除。即使增加第二层过滤，仍有漏网之鱼。最终他们调整评估标准：将AI违规概率降到训练有素人员的50%即达标。

提示词革命：AI抽象层的窄腰化构建与范式演进

Yoko Li: 如果把视角拉远——您二位或亲历互联网崛起，或主导网络研究，互联网形成过程中存在"协议窄腰"。AI领域是否会出现类似结构？或者说AI的"腰"可能永远无法收窄？

Guido Appenzeller: 我认为"窄腰"已经存在，它就是提示词（Prompt）。

Yoko Li: 有趣！为什么这么说？

Guido Appenzeller: 重大技术周期往往建立在能封装底层复杂度的抽象层上。比如数据库领域的SQL查询——底层用B*树实现（我们在研究生课学过），但用户只需关注查询逻辑。现代机器学习崛起同理：不再需要高薪聘请斯坦福博士训练模型，普通Python开发者通过提示词就能驾驭大语言模型。

Yoko Li: 精辟！如果深入分析提示词——您认为它是对意图的自然语言表达，还是因缺乏标准而呈现无序状态？这似乎是个"半成品窄腰"，毕竟它并非形式化语言。

Matt Bornstein: 现在的提示词显然也不是标准英语。感觉我们在集体学习一门新"语言"，而且不同模型还有方言差异——本质上是个翻译适配问题。

Guido Appenzeller: 未来会发展出正式的提示语言吗？

Matt Bornstein: 估计有高薪聘请的斯坦福博士正在研究，拭目以待吧。

Yoko Li:Agent框架算正式提示语言吗？

Guido Appenzeller: 我认为算雏形。现在出现结构化提示，比如用户提问Agent响应的对话模板，或是用<think>标签包裹思考过程。虽不严谨，但已初现端倪——未来模型可能针对结构化表达做专项训练。

Yoko Li: 确实！现在所有模型都支持JSON模式，用户可定义类型系统约束输出。比如提示"生成三种水果，键名必须是'fruits'，值用苹果等具体品类"，代码端再设定格式校验。这本质是种形式化规范。

Guido Appenzeller: 长远看，当模型具备复杂推理能力后，可能会分层处理：一个模型负责内部思考，另一个专门生成用户界面输出。比如聊天型、旅游向导型、JSON生成型模型各司其职——推理层与输出层最终可能解耦独立。

编程范式革新：Vibe Coding在企业级开发中的实践

Guido Appenzeller: 未来会出现"Vibe coding模型"和"企业级编程模型"的分野吗？

Yoko Li: 我认为不会。所谓"Vibe Coding"，是用户只定义需求，让模型自主处理实现细节——不关心代码怎么写，只关注输出是否符合预期。

Guido Appenzeller: 所以比传统编程更非正式、约束更少？那和传统Web开发的区别呢？

Yoko Li: 传统编程需要做大量技术决策（比如选用哪个SDK），而Vibe coding只需确保结果正确——不过问底层实现，但高层需求把控仍不可缺，否则写代码的意义何在。

Guido Appenzeller: 明白了。

Yoko Li: 所以企业用户完全可能采用vibe coding，这可是褒义词哦。

原文：Who's Coding Now? - AI and the Future of Software Development https://www.youtube.com/watch?v=6Z5hlKIDV44

编译：Julie Qiao

文章来自于微信公众号“Z Potentials”。