AI Coding 目前是第二大 AI 市场，仅次于 Chatbot，甚至有可能成为最大的单一市场。
这是 a16z 的播客中，三位投资合伙人 Matt Bornstein、Yoko Li 和 Guido Appenzeller 的观点。
和别的聊 AI Coding 的节目不同，a16z 对于编程的未来没有那么悲观。比如在他们看来，现在的 Vibe Coding 就像 20 年前开始流行的博客一样，让「创作」成为一件没有门槛的事情。
「软件的落地深度能做到什么程度？说实话，我觉得不会很深，但这不重要。只要对人们来说实用就行。」
编程语言不会被取代、资深工程师依然很被需要。核心是，「新人群+新方法很可能催生全新的软件形态和应用场景。」
只能说，不愧是 a16z，看到的全是新机会。
不管是对于创业者，还是程序员们，都强烈推荐一读。
一些有趣的观点：
-
AI Coding 已成为第二大 AI 市场，仅次于面向消费者的聊天机器。人工智能生成代码预计将给市场带来数万亿美元的生产力增长。
-
AI 不会让「学编程」变得无关紧要。相反，理解底层抽象和架构、数据流等基础知识会变得更重要。未来的开发者可能更像「产品经理」或「QA 工程师」，需要善于表达需求、制定规范、理解系统优化，而不是只会写 for 循环。
-
Vibe Coding 的影响有限。Python 和 Java 这样的语言会一直存在，即使自然语言交互变得普遍。
-
AI 更适合标准化、样本丰富的问题，面对新颖任务时，开发者仍需提供大量上下文和明确规范。
-
现在多数 IDE 对使用工具的数量有限制（比如 40-50 个），这天然限制了 AI 能调用的上下文和工具的范围。
-
现在的一些 AI Coding 工具与程序员操作之间存在断层，需要中间产品赋予用户修改底层的能力。
-
AI 可以辅助企业将老旧的 COBOL、PL1 等主机代码迁移到现代语言和架构，虽然不能完全自动化，但能极大提升效率。这为企业服务商、咨询公司、AI 迁移工具等带来了新商机。
-
AI 让软件变得更「混沌」，开发者需要适应新的失败模式和不确定性，甚至要调整对「完美可控系统」的预期。
-
AI Coding 将鼓励更多人参与「写程序」这件事。新人群+新方法很可能催生全新的软件形态和应用场景。
超 4000 人的「AI 产品市集」社群！不错过每一款有价值的 AI 应用。
-
最新、最值得关注的 AI 新品资讯；
-
不定期赠送热门新品的邀请码、会员码；
-
最精准的AI产品曝光渠道
Coding 目前是第二大 AI 市场
Matt：从数字上看，我们很确定 Coding 目前是第二大 AI 市场，第一名是面向消费者的纯 Chatbot。
Guido：如果将像 ChatGPT 这样的工具归类为「有用的伴侣」，那么编程市场可能比聊天机器人市场更大。
Matt：AI Coding 实际上是现有行为发生的「转变」。以前，当人们遇到无法解决的问题时会去互联网上查找信息，比如 Stack Overflow（一个关于编程方面的问答网站）。有一些玩笑说，「在过去数年里，Stack Overflow 实际上编写了大部分代码」，现在这个动作被转移到了 AI 模型上。
比如 Github Copilot，它就做了这项非常基础的工作。通过它，人们开始从使用 Stack Overflow 转移到使用 AI 模型，像 Cursor 这样的公司现在在这方面做得更好。
总之，AI Coding 针对的是一个有需求的市场。这就像在存量市场中，销售一个很有竞争力的新产品。
Yoko：开发者是新技术的早期采用者，因为他们喜欢尝试新工具，任何能够提高生产力的技术都会被他们快速接受。
而且，编程问题具有明确的验证标准（如输入输出），这使得 AI 编程工具的应用场景非常清晰。
Coding 的美妙之处在于，你可以将许多现实世界的问题转化为机器可处理的格式。
Guido：AI Coding 是一个比较容易占领的市场。
因为开发人员相对而言理解 AI 技术，这可能是人工智能的第一个真正的大市场。试着算了一下，全球大约有 3000 万开发者。假设每个开发者每年创造 10万美元的市场价值，那么市场总价值能达到约 3 万亿美元，相当于苹果公司这种科技巨头的市值。
而且，开发者们的效率还会提升。
有大型金融机构估算，普通 Copilot 的部署可以提高开发人员大概 15%的生产力。我的直觉是，这个提升还将更大。完全可以想象，未来世界上所有开发人员的生产力会提高一倍。
去年，关于我们是否过度投资 AI 的讨论非常热烈。我记得当时的数字是每年投资 2000 亿美元，但如果和 3 万亿美元的市场价值比较，这个投入就像是「花生米」的大小。
Coding 今天的瓶颈是
上下文不够长
Matt：程序员们的工作会发生很多变化。
当下已经能看到一些迹象。比如我现在写代码时，其实是在编写「规范」，和一个模型讨论如何实现某个功能。对于简单的功能，可以直接让模型去实现，人只需要审查一下。
那么之后，开发者会不会都变成只负责编写规范的产品经理，然后让 AI 去写代码，只是偶尔介入调试一下？这也有可能发生。
Yoko：或者我们都成为 QA 工程师，测试它是否足够好。
Guido：就我自己来说，过去的六个月里，我使用这些模型的方式发生了很大变化。
以前，首先我会选择最喜欢的工具，比如 ChatGPT 或类似的工具，然后给它提示词（prompt），它会输出一个程序，然后把这个程序复制到编辑器里，看它是否能运行。它这就像是 Stack Overflow 的替代品。当我遇到问题时，不会去 Stack Overflow，而是去 ChatGPT 找它直接返回代码。
到下一步，就是开始集成到 IDE。比如 GitHub Copilot 和 Cursor 这样的工具，它们有自动补全功能，这是一大进步。不再像以前那样是单一的、块状的解决问题，而是融入了开发流程。在代码行级别，我可以询问关于代码段的问题，或者我可以有一个单独的聊天界面，用于进行更长的讨论。
接着，IDE 开始能使用命令行工具。我们可以对它说：「嘿，你能帮我设置一个新的 Python 项目，使用 UVloop 或类似的东西吗？」它可以运行命令来完成所有这些工作。
现在，当人们想要编写一个新的软件片段时，是在尝试先编写一个规范，而不是生产代码。基本上，人们问的问题没有经过深思熟虑。比如我会问模型（可能是 Sonnet 3.5 或 3.7 或 Gemini）。「我想要做 xxx，这说得通吗？请问我有没有说不清楚的地方，给我写一个更详细的版本。」然后模型就开始工作了。
通常，它也会有很多问题问我，比如「嘿，我需要一个 API 密钥才能做到这一点」，比如「你想要如何管理状态？我们应该把它放在数据库里吗？还是只是用一个计算机文件之类的东西？」
它会通过来回讨论，帮助我理清思路。虽然有些奇怪，它确实有效。随着时间的推移，我会得到更详细的规范。当有了这些规范后，我就会要求模型实现。
Yoko：与六个月前相比，我现在使用 Coding Agent 的方式是，我更多地提供知识。以前，我主要依赖于基础模型的知识。
现在，我觉得很自然地会去 Linear（一个项目管理工具）那里，找到对应的工单（ticket），然后把我的想法拉到 Cursor 中，Agent 会先尝试实现它，这是一种工作流程的变化。
另一种变化是更用户驱动的，像主动查询。以前，我可能需要把文档复制粘贴到我的 Cursor 窗口中。现在，我只需要让 Cursor Agent 去用 Firecrawl（一个爬虫工具）查找最新的 Clerk 文档（一个提供身份验证服务的平台的开发者文档）。它会实际抓取一个页面，然后我可以阅读它。
Guido：那是如何工作的，要使用 MCP 吗？
Yoko：要使用 MCP，但更多可能是与现实世界有更多的集成。
Matt：你们听起来比我经验丰富得多。对我来说，场景通常是这样的：周六晚上，我终于有一个小时的空闲时间，突然有了一个奇怪的应用程序想法，我就会直接开始动手让 Cursor 去完成所有的事情。
我发现它在处理复杂度高、繁琐的任务时特别有效，比如前端开发。如果现在地球上有人能记住现在用来设置边距和内边距的所有 CSS 内容，那真是难以想象。
我们有相应的标准记录。这本不该是一个很难的问题。总共有五种不同的方法可以用来居中文本和元素，但我从来记不住它们。但 AI 模型在这方面真的很擅长，而且它们现在可以做到。当我开始涉及到更小众的库和函数调用时，我喜欢用 Firecrawl 。
Yoko：是的，有时我也会像复制 Mintlify Docs 那样，直接拷贝整段 LLM 文本。我只需要提供文档的 URL 或者文件，然后让 Cursor 去实现它。
Matt：Yoko 你在 MCP 方面上做了很多工作，你觉得 MCP 扮演了什么角色？
Yoko：我认为 MCP 的本质就是提供相关性最强的上下文给语言模型。我可以使用 Linear MCP，也可以使用 GitHub MCP 来拉取相关的上下文和技术细节。但 MCP 的核心其实还是上下文，它要搞清楚自己能给模型提供最相关的东西是什么，以便模型能更好地帮助用户。
Matt：你觉得在 IDE 中集成这类 AI 工具，是否意味着 AI 编程对资深开发者更高效或更实用？
因为长期以来有个质疑是，AI Coding 更多是”vibe coders”在使用，因为 AI 能快速做出很炫的 demo，初级开发者也能快速上手。而那些资深派，比如负责集群架构、防止系统崩盘的程序员，往往对 AI 持怀疑态度。你认为 IDE 中集成 AI 工具是吸引他们参与的一种方式吗？
Yoko：我觉得这取决于资深工程师的核心目标。比如有些资深应用工程师擅长快速实现想法，这类工具能均衡他们的技能分布，他们只需要把技术栈搭起来就行。
但如果是专精分布式系统或性能调优的资深工程师，目前 AI 可能还不太行。
因为编程助手无法获取分布式系统的全部状态，很多问题仍需人工干预。不过随着上下文窗口扩大和工具调用能力增强，我们正在朝这个方向进步。现在多数 IDE 对工具数量有限制（比如 40-50 个），这天然限制了 AI 能调用的上下文和工具的范围。
Guido：这里有一个规律：问题越是深奥，你试图解决的问题越新颖，需要提供的背景信息就越多。比如「帮我写篇博客”或者”做个简化版网店”——这种标准本科软件开发课的题目，网络上的样例几乎无穷无尽，模型已经见过无数次，完成起来就会非常拿手。
但若遇到训练数据极少的领域，情况就完全不同。你必须事无巨细地说明需求：提供上下文、API 规范等，难度陡增。
Matt：而且模型还会「信心十足」地给出错误答案。更糟的是它死不认错，还会继续编造。
Guido：当前模型最致命的缺陷，就是”无法承认自己不知道”。
Yoko：你认为强化学习能改变这点吗？理论上，它能够模拟相关的分布式系统并调试 AI。
Guido：极端情况下，如果你是地球上第一个解决某个问题的人，训练数据就是零。我认为现在模型目前还缺乏真正的创造力，它们只能做有限的知识迁移。比如为全新架构芯片编写首版驱动，这基本还得靠人工。
但好消息是，这类情况只占软件开发的 0.01%。像无数 ERP 系统，我们有海量训练数据，这些工具就能大显身手。
描述问题、设计架构的能力
会越来越重要
Matt：虽然我们没多谈”Vibe Coding”，但非开发者现在也能写代码，很酷对吧？
Guido：这个话题中的问题是，这件事能否在所有情况下成立。就像人人能搭棚屋，但造不了摩天楼？
Matt：这正是关键——多数人第一次用网站生成器或 Cursor 做的 demo 可能没啥实际价值。但如果其中一部分人逐渐进阶，用完全不同于传统编程的方式做出复杂项目，会发生什么呢？我对这件事非常乐观：新人群+新方法很可能催生全新的软件形态和应用场景。
Yoko：这让我想起 2000 年左右，「博客」还是个新鲜词，所有人都觉得「我得开个博客」。然后大家一窝蜂去建博客，接着 WordPress 出现了。直到现在还有人用 WordPress，我还挺意外的。
而这次 vibe coding 的浪潮，感觉就像所有人——我、我妈、甚至我妈的邻居——都在尝试用这些模型来打造个人化的东西。我们算是从「个人静态内容」过渡到了「个人 CRM 客户关系管理」，用来管理人际关系之类的事情。
软件的落地深度能做到什么程度？说实话，我觉得不会很深，但这不重要。只要对人们来说实用就行。
另外，我一直在想，对于「Vibe coder」来说，低一层的抽象（level lower abstraction）是什么？是代码？是 IDE？还是别的什么？想听听你们的看法。
Guido：我觉得这是个非常好的问题。我稍微重新表述一下：未来想从事软件开发的人，到底需要掌握什么？是更深一层的东西，还是说其实是横向的某种能力？有些人会说：「现在学计算机科学没意义了，重点是社会情感学习（Social and Emotional Learning，简称 SEL）」。我其实不太认同。
说实话，我完全不知道五年后的计算机教育会变成什么样。
但如果回顾历史，类似的事情发生过——比如计算方式的演变：我们从手动加减数字到用 Excel，但「记账员」这个职业并没有消失，而是变成了「会计师」。数据录入和手动计算变得不那么重要，更高层次的抽象能力（比如分析模式）反而更关键。
如果按这个规律推测，未来「描述问题、解释算法基础、设计架构、梳理数据流」会越来越重要，而「如何用最巧妙的方式展开循环」这种很细节具体的编程，很可能会变成更小众的专业技能。」
Matt：在经典的计算机科学本科教育中，学生不仅仅是学习最新的东西。在多数情况下，甚至要会花一学期学汇编语言。
都是从「最古老」的东西开始学习。即便是「世界上最糟糕的计算机工程师」，同样要学习怎么接门电路，学习处理器是如何工作的。接着是文件系统和操作系统基础。当然也学 Java——当时它还是尖端技术，不过现在嘛……所以人们容易认为，新一代技术只是堆叠在这些基础之上的工具，而学编程可能只剩历史或教育意义。我不确定是否真是如此。
几十年，有很多新的编程接口（programming interface）出现。但 AI 实际上并不是一个编程接口，它也不是一个框架。它更像是一个工具，它帮助你使用你已经拥有的东西。
所以这让我怀疑，我们是否是在等待下一个迭代，即 AI 真正可以改变计算机编程方式的东西。比如，或许会出现一种能直接将自然语言提示词转化为代码的机制，而现在的 AI 代理只是起点。这就是我好奇的方向。
编程语言不会消失，
AI 与 Vibe Coder 之间的空白地带有很多机会
Guido：今天我认为 AI 不仅仅是一个高级语言抽象之类的东西。但未来会不会演化成那样？
用大语言模型（LLM）来设计编译器或编程语言，和用经典的编译器设计，思路会完全不同。虽然我们还不知道最终会是怎么样，但如果能用精炼的人类语言直接定义某些逻辑，并将其作为编译器输入，变革会非常巨大。
Yoko：类比来看，现在很多公司在开发 agent。当观察它们的运作方式时，会发现它们本质上就像操作系统课程里学的「进程」——一个进程处理任务后交给下一个，再配合资源管理。
这正是计算机教育不会消失的原因：它提供了一套理解本质的参照系。否则你甚至不会知道‘进程’这个概念的存在。但另一方面，在基础模型之上，我们还没发明出类似操作系统那样的成熟范式。
Matt：形式化语言（formal languages）的存在有必然性——无论是编程语言还是规范语言。
人类总需要一种高带宽、高表达力的方式来设计软件（或其他事物）。所以我很难想象 Python 或编程语言会完全消亡。就像刚才 Yoko 说的：你必须理解至少低一层的抽象。
有个有趣的问题：某些语言是否会因为更「AI 原生」而变得更流行？比如现在的 Python 和 JavaScript。
工具链的发展也很有意思——Python 生态最近涌现了大量新工具，活跃度前所未有。这自然会影响到它与 AI 扩展的兼容性。所以，我觉得我们不可能完全抛弃这些传统语言。
Yoko：需要理解底层抽象的原因在于：当你要优化系统时，有些知识就派上用场了。如果不需要优化，确实可以不懂。就像早年用 Java 写计算器的人根本不用了解 GBM（Gradient Boosting Machine ），但如果要用它做多线程优化就必须懂。
Vibe coding 也是同理——做个营销网站可能不需要深究优化，但如果要支撑大规模访问，就得懂 CDN、页面缓存这些。
Yoko：不了解本质几乎不可能成功。计算机可以做某些事情，是由形式语言定义的。这些语言层层堆叠，要想真正操控系统，就必须理解它们。
Guido： 我同意。我认为这些语言不会消失，因为它们虽然看起来很复杂，但往往是用最简洁的方式表达精确意图的最佳载体。
自然语言通常不够精确，需要更多词汇才能达到同样效果。
现在有趣的问题是：AI 能否在某些场景下，通过理解人类语境、结合智能符号系统，将自然语言描述准确转化为代码？目前在某些领域已经可行，但能否进一步杂交出新型语言？我还说不准。
Matt：你提到的复杂性区分很精妙，这可以理解是一种繁杂的系统，也可以理解成难以使用。
人们常觉得编程语言复杂是因为难学，但实际上它们可以很简单，可以用一套有表达范式的东西画一棵树。
当我们转向的「AI 编程」虽然看似更易用，但底层却复杂得多。
所以关键是如何平衡？是否需要混合方案？Cursor 团队提倡的’形式化规范’写作或许是个方向——就像 Guido 说的，未来人们可能更多需要撰写精确的规格说明。
Yoko：我最近采访过一位典型 Vibe Coder。我的问题是：「你真的需要编程界面吗？」毕竟现在输入提示词就能生成大段代码。他的回答很有意思：「AI 生成代码并展示给我看的过程让我充满成就感，但当我想手动修改时，却完全无从下手。」
这说明 AI 生成代码与程序员操作之间存在断层，需要有个中间产品来赋予用户修改底层的能力。
Matt：这不限于新手程序员。就算是我们这些人，用 AI 生成四五轮代码后想手动编辑也会非常困难——整个代码变得极其晦涩。
Yoko：我在用 Blender MCP 时遇到了这个问题。我以前从未使用过 Blender，我通过 Cursor IDE 的 MCP 服务，轻松生成了微缩模型。但要修改这个 3D 模型时，系统就崩溃了，我连该从哪开始改都不知道。
所以，AI 与 Vibe Coder 之间的空白地带也有很多机会。
Matt：最酷的地方在于，AI 实际上为软件开发创造了一个前所未有的新语境层和意图层。比如，AI 能帮助迁移旧代码吗？比如银行业试图淘汰 COBOL 语言都喊了快一百年了。
但说实话，答案可能是否定的。 AI 当然能提供帮助，但解决不了核心难题。具体来说：AI 或许能把 COBOL 转译成 Java，可当年编写这些 COBOL 代码时的大量上下文早已在几十年间消失殆尽。
这些系统往往经历了魔改，最初只是个机票预订系统，后来逐渐塞进了人力资源模块、甚至订咖啡功能（笑）。而许多参与开发的程序员（顺便说一句，他们基本不写文档或注释）可能早就不在这家公司——或者不在人世了。
AI 现在能协助但无法彻底解决这个问题。
不过话说回来，真正让我更感兴趣的是另一件事，当我们讨论测试用例和规格文档时，我就在想：如果当年构建这些系统时就有 AI 参与，那么开发者的原始意图就会自动留下完整的记录。这相当于白送的白送的福利对吧？根本不需要事后补做。
而现在越来越明显的趋势是：随着 AI 的普及，我们将获得另一种元数据体系，它能以全新的方式捕捉软件设计意图。这其实非常酷。
Guido：这个观点很有趣。我最近和一些大型企业交流时发现，他们正在用 AI 处理遗留代码库——特别是大型主机上的 COBOL 和 PL/I 这类语言。
这个过程特别有意思，他们遇到的正是你描述的问题：如果只看旧代码，根本搞不清原始开发意图；如果直接翻译代码，又会继承旧编程语言的各种古怪特性（毕竟 Java 有更现代的语法结构，而 COBOL 根本没有这些特性）。
目前我从多个机构听到的最佳实践是：先让 AI 根据旧代码生成技术规范说明书，然后基于这份规范重新实现代码。这样做得到的结果远比直接转译要好——代码更精简、更符合现代标准。就像处理古董家具，与其强行改造榫卯结构，不如先测绘图纸再重新打造现代版本。
Yoko：是的，很有趣。我刚刚就在想：重写现代软件（比如近 10 年的）其实容易得多——比如从 Angular 迁移到 React，尤其是 Agent 对这两个框架都很熟悉的情况。但如果是 PHP 转，那可能就不一样了。像 Laravel 这类框架，迁移起来还算顺利，毕竟生态比较完善。但具体难易程度还得看框架类型。
真正的硬骨头是那些横跨多个软件系统的遗留系统——你得先做全面的系统勘探，或者训练一个能自主探索的智能体，这个方案我觉得理论上可行。
但还有硬件层特有的坑，比如某些遗留系统跑在特制硬件上，比如要给 Docker 容器分配精确的内存参数，或者需要特定运行时配置。
就像你刚才说的，这些细节往往早已湮灭，除非能对运行时环境做完整快照。否则连系统到底需要什么资源都搞不清楚，这种迁移根本是无米之炊。
如何应对 AI 的不确定性：
调整评估标准
Matt：如果我们把 AI 视为应用程序的原生组件，而非仅是写代码的工具。它似乎正在突破软件系统中确定性与非确定性行为的边界。
想想很早之前——开发者只为本地机器写代码时，对程序行为了如指掌。后来网络的出现带来了不可预测性，但至少还能用相同范式去描述。而当 AI 被集成进系统，或让它生成代码时，你根本不知道会发生什么。你觉得这种类比成立吗？从网络时代积累的经验，能否帮我们应对 AI 带来的混沌与未知？
Guido：确实可以这么类比——虽然我们还没完全消化这些经验教训。 回想网络系统刚普及时，冒出了全新的故障模式。比如超时问题以及随之产生的重试机制等解决方案。但到了分布式数据库阶段，问题就复杂多了：必须处理原子性和数据回滚这些数字语境下的新挑战。
而直到今天，这些设计模式仍不完善，虽然有强大的潜力，又带着各种不稳定的特性。
Matt：有些问题可能是无法解决的？
Guido：根本性问题确实无法解决，但至少可以让开发者用起来尽可能简单。说到底，所有工具都是为了帮开发者缓冲这些冲击。
模型的有趣之处在于——当参数设为零时，模型在技术上是确定性的。问题不在于相同输入会产生不同输出（这是我们主动引入的随机性），真正的挑战在于：输入的极微小变化可能导致输出完全失控。
Matt：是的，现在的输入框简直成了混沌系统，早年间只要防住单引号就能安全执行 SQL 语句，现在呢？用户可能输入任何东西，任何事情都可能发生。
或许我们真正需要做的，是重新定义系统的基础能力和接口规范，让开发者能够合理使用这些能力，而不是要试图消除所有可能的故障模式，比如完全规避网络超时问题。
Guido：我认为这只是问题的一部分。我们还需要改变预期标准。我曾与一家大型银行交流，他们部署了一个文本生成系统。要知道，金融机构从不提供投资建议，所以他们要确保这个语言模型既保持高实用性，又绝对不能（哪怕是隐晦地）给出投资建议。
这本质上是个无解难题。你可以不断优化模型，但永远无法彻底杜绝这种情况。即便设置第二道过滤机制，这个安全层偶尔也会因为”误判为有效帮助”而出错。最终他们不得不做出决定：我们无法开发出绝对不犯错的系统，必须调整评估标准。
我记得最终设定的标准大概是：出错概率不得超过训练有素的银行职员在相同情境下犯错概率的一半。
提示词（prompts）
会是 AI 编程的核心节点
Yoko：互联网的演进过程中曾存在关键的”窄腰结构”（narrow waist，如 TCP/IP 协议栈中的 IP 层，拥有非常精简的核心功能，却承担着数据链路中承上启下的联通作用）。你认为 AI 发展会呈现类似的架构规律吗？这种类比是否成立？或许 AI 系统根本不会形成这样的核心约束层？
Guido：我认为可能是提示词（prompts）。
重大技术变革往往建立在抽象层之上，就像 SQL 数据库用简洁的 API 封装了底层复杂性，以及早期事务型数据库的 B*树索引机制。那是研究生课程内容，现在谁还需要关心？我们只需编写查询语句。
现代机器学习的发展轨迹如出一辙：不再需要高薪聘请 PhD 专家训练模型，现在通过提示词（prompt）就能驾驭模型。这使得一个普通的 Python 程序员，也能通过提示词调用强大的 LLM 能力。
Yoko：如果深入研究这些提示词，你觉得它们像是你想要做的事情的自然语言表达吗？因为没有标准，提示词可以是任何东西，无所不包，它几乎没有一个明确的规范，可以说它并不是一种正式语言。
Matt：当然，它显然也不像英语，这让我觉得，我们其实都在学习一种新的语言，用来引导这些工具。
Guido：我们会有正式的提示语言吗？
Matt：有斯坦福的博士们正在研究这个问题，希望他们能有所突破。
Yoko：我们亚洲的团队也在研究正式的提示语言。
Guido：我们已经开始看到一些有结构的提示语了，比如在问答结束时说一句「好的」。但这也算不上很正式。但我觉得这是一个起点，未来模型可能会在更结构化的表达上进行训练和微调。
Yoko：这种情况已经发生了。现在的模型都有 JSON 模式，用户可以定义自己想要的东西。
Guido：从长远来看，我一直在思考对于一个推理模型而言，如果大部分思考过程发生在内部，那么面向用户和机器的输出模型，是否会与推理阶段的模型完全不同？这听起来可能有些抽象。
比如，我们可能需要一个健谈的聊天模型，或者一个更简洁的模型，又或者专门生成 JSON 格式输出的模型。这就引出一个可能性：未来的模型输出层可能会与推理层完全分离。
那么问题来了，我们是否最终会发展出面向”Vibe Coder”的模型和面向企业级开发的模型这两个完全不同的分支？
Yoko：我不这么认为。
我觉得 Vibe Coding 就是你让模型根据需求去生成需要的东西。你不在乎实现的细节，关心的是最终实现的结果是否是自己想要的。传统编程中，开发者需要做出大量技术选型决策，比如选择使用这个 SDK 而非另一个。
在 Vibe Coding 中，只要最终能达成目标，开发者根本不需要关心底层技术细节，但仍需聚焦需求（否则写这段代码的意义何在？) . 现在我完全可以预见，企业用户也会采用 Vibe Coding 模式。
（文：Founder Park）