吴恩达LangChain对话:别纠结Agent定义,成功的智能体往往从线性工作流开始,Vibe Coding这个概念充满误导 原创

毫无疑问,Agent,也就是智能体已经预定了今年的最火AI关键词。不知道明年会不会是AGI呢,既然OpenAI和Anthropic的预测都是在2027年左右。而在Agent领域,非常有发言权的一位就是吴恩达。LangChain前不久的开发者活动Interrupt上,LangChain创始人Harrison Chase邀请了吴恩达专门做了一场对话

毫无疑问,Agent,也就是智能体已经预定了今年的最火AI关键词。不知道明年会不会是AGI呢,既然OpenAI和Anthropic的预测都是在2027年左右。而在Agent领域,非常有发言权的一位就是吴恩达。LangChain前不久的开发者活动Interrupt上,LangChain创始人Harrison Chase邀请了吴恩达专门做了一场对话,我感觉含金量蛮高。

虽然我们这个专栏主要是谈技术思想,但是也不能天天说AGI,也要讲点具体的技术问题。

吴恩达LangChain对话:别纠结Agent定义,成功的智能体往往从线性工作流开始,Vibe Coding这个概念充满误导

吴恩达按说就不用多介绍了,他是Coursera联合创始人、前斯坦福教授、AI Fund创始人。对很多人而言,他还有一个重要的身份是Google Brain的负责人,而且也曾经在百度任首席科学家。而Harrison Chase,则是近年来备受瞩目的LangChain框架创造者,该框架已成为构建AI应用的重要工具。

这场对话的背景是,当前AI智能体技术正处于从概念验证走向实际应用的关键阶段。特别是如何构建真正有用的AI智能体成为关注焦点。但是,于我个人而言,印象最深刻的是关于Agent定义这部分。因为当人人都在说智能体,但是对于何为智能体,现在没有统一共识。

可是吴恩达认为,不要纠结,不要把智能体狭义地定义。这番话让我想起很多年前我采访工业大数据专家李杰,我问他什么叫工业4.0。李杰当时就说,别纠结啥叫工业4.0,到底是3.5还是4.0(时隔多年了,大概是这个意思),只要说想解决什么问题就可以了。这和吴恩达的说法基本是异曲同工。

老规矩,放三个金句在最前边。

第一,"智能化程度"思维胜过"是否智能体"的二元判断。

当你不再纠结于定义,就能专注于解决实际问题。这个思维模式可以应用到很多技术讨论中——与其争论是否够格称为某个概念,不如讨论如何提升实际效果。

第二,评估系统要"先破后立"。在快速迭代的世界里,一个能用的差评估胜过一个完美的无评估。这个原则其实适用于很多工程实践——原型优于规划,反馈优于假设。

第三,速度是创业成功的头号预测因子。 技术窗口期越来越短了。但这里的速度不是盲目的快,而是基于技术理解的精准执行。没有深度技术知识的速度只是瞎忙活。

对了,对于AI创业,吴恩达和YC加速器的观点明显不同。YC认为,技术已经被AI解构了,不构成护城河,行业知识才是门槛。但是吴恩达却认为,AI创业的本质还是对技术的理解。

一、重新定义智能体概念:从二元判断到连续光谱

Harrison开场就提到了吴恩达一个备受引用的观点——谈论应用的"智能化程度"而非判断"是否为智能体"

吴恩达回忆起一年半前他和Harrison都在同一个会议上发言,当时两人都在努力说服业界关注智能体技术。然而到了去年夏天,情况发生了戏剧性变化——营销人员开始大量使用"agentic"这个词汇,导致这个概念逐渐失去了原有的精确含义。"就像贴标签一样,到处都能看到这个词,"吴恩达略带无奈地描述当时的情况。

真正的问题出现在吴恩达观察到的一个现象:太多人在争论什么是真正的智能体,什么不是。这种争论往往陷入"这个系统是否真正自主"的哲学讨论,而非专注于解决实际问题。吴恩达意识到,这种二元化的判断方式阻碍了技术的实际应用和社区的发展。

因此,吴恩达提出了一个更加实用的框架:将智能体视为一个连续的光谱,不同系统具有不同程度的自主性。在这个框架下,一个只能执行简单任务的系统和一个能够进行复杂决策的系统,都可以被称为"agentic系统",只是智能化程度不同而已。

"如果你想构建一个具有一点自主性或很多自主性的智能化系统,这都很好,"吴恩达解释道,"没必要花时间争论这是否是真正的智能体。让我们把所有这些都称为具有不同自主程度的智能化系统。"

这种思维转变的意义在于,它将焦点从概念争论转向了实际构建。开发者不再需要纠结于自己构建的系统是否配得上"智能体"这个称号,而是可以专注于提升系统的智能化水平和实用性。吴恩达认为,这种方法减少了社区内部的无意义争论,让大家能够专注于真正重要的事情——构建有用的智能化系统。

事实证明,这种方法是有效的。吴恩达表示这个概念框架在社区中得到了广泛接受,帮助更多开发者专注于实际的技术挑战而非概念争论。这就为后续讨论当前智能体发展的实际状况奠定了基础。

二、当前智能体发展现状:线性工作流占主导

在概念澄清的基础上,吴恩达深入分析了当前智能体应用的实际发展状况,他的观察令人意外:大多数成功的智能体应用都是相对简单的线性工作流,而非复杂的自主决策系统

吴恩达的团队在处理最复杂的问题时确实会使用LangGraph这样的复杂流程工具,但他发现更多的商业机会实际上存在于相对简单的线性工作流中。这些工作流通常是线性的,偶尔会有一些分支判断,但整体结构并不复杂。

他举了一个典型的商业流程例子:企业中经常有员工需要查看网站表单、进行网络搜索、检查数据库中的合规问题(比如确认是否应该向某些客户销售特定产品),然后复制粘贴信息,可能再进行另一次网络搜索,最后将信息填入另一个表单。这些看似复杂的业务流程,实际上可以分解为一系列顺序执行的微任务,只是偶尔会有一些基于规则的分支,通常是用来处理异常情况或拒绝某些工作流程。

"在商业流程中,实际上有很多相当线性的工作流,或者说是线性的但带有非常小的规则和偶尔的分支,"吴恩达解释道。这些分支通常表示工作流程的失败或需要人工干预的情况。

然而,吴恩达指出了一个关键挑战:企业很难将现有的业务流程转化为智能化工作流。这个挑战包含几个层面的困难:

首先是粒度把握问题。企业需要决定应该以什么样的粒度将复杂的业务流程分解为微任务。分解得太粗,智能体难以理解和执行;分解得太细,又会导致系统过于复杂且难以维护。

其次是性能优化问题。构建了初始原型后,如果系统性能不够好,企业需要知道应该优化哪个步骤才能获得最大的性能提升。这需要对整个工作流程有深入的理解,以及识别性能瓶颈的能力。

最后是评估体系问题。企业需要建立适当的评估框架,不仅要了解整体系统的性能,还要能够追踪到各个步骤的表现,从而精确定位问题所在。

吴恩达认为,这整套将业务流程智能化的技能集合目前仍然过于稀缺。很多企业都有智能化改造的需求,但缺乏将现有业务流程进行合理分解、构建原型、设置评估体系、迭代优化的能力。这不仅需要技术知识,还需要对业务流程的深入理解以及系统性的项目管理能力。

虽然确实存在更复杂的智能化工作流程,吴恩达也听到了很多关于复杂循环和高级系统的讨论,但从机会数量和潜在价值来看,简单工作流程仍然有大量未被开发的空间。这个观察为后续讨论智能体开发所需的技能提供了重要的背景。

三、智能体开发者必备技能:从理论到实践的技能差距

基于对当前智能体发展现状的观察,Harrison向吴恩达提出了一个核心问题:智能体开发者应该掌握哪些关键技能,特别是考虑到从简单到复杂的各种应用场景。

吴恩达的回答展现了他作为教育者和实践者的洞察。他首先坦诚地表示:"这是个好问题,我希望我知道一个好答案。"这种坦诚反映了这个领域仍在快速发展,最佳实践尚未完全形成的现状。

吴恩达分析了典型的业务流程智能化场景:通常涉及合规、法务、人力资源等部门的多步骤流程。开发者需要解决几个层面的技术挑战:

数据集成与系统连接是第一个挑战。无论是通过LangGraph这样的集成工具,还是通过新兴的MCP(模型上下文协议)来简化数据接入,开发者都需要掌握如何高效地获取和处理数据,然后通过提示工程或多步骤处理来构建端到端的系统。

评估框架的构建是吴恩达特别强调的技能。他观察到,正确的评估框架不仅要评估整体系统性能,还要能够追踪各个步骤的表现,从而帮助开发者精确定位问题所在。这种细粒度的评估能力对于系统优化至关重要。

然而,吴恩达发现一个普遍的问题:大多数团队过度依赖人工评估。每次修改系统后,团队成员就坐下来查看大量输出结果,手动判断系统表现。这种方法不仅效率低下,而且难以获得系统性的改进洞察。吴恩达认为,大多数团队都过慢地建立系统性评估框架,这成为项目进展的重要瓶颈。

更重要的是,吴恩达强调了"战术直觉"的重要性,这是一种很难量化但极其宝贵的能力。有经验的开发者能够通过观察输出结果、查看执行轨迹,在几分钟或几小时内做出关于下一步行动的正确决策。而缺乏经验的团队往往会走进错误的技术路径,花费数月时间试图改进某个组件,最终被有经验的团队告知"这个方法永远不会成功,换个思路吧"。

"我希望我知道更高效的方法来获得这种几乎是触觉式的知识,"吴恩达坦言。这种知识往往需要开发者在实际项目中观察输出、分析轨迹、查看结果,然后在极短时间内做出战术决策。这种能力目前仍然非常稀缺,而且很难通过传统的教学方法快速传授。

吴恩达的分析揭示了一个重要现象:智能体开发需要的技能组合既包括技术层面的工程能力,也包括很难定义的项目判断力和战术直觉。这种技能差距解释了为什么尽管工具越来越丰富,但真正成功的智能体项目仍然相对稀少。这个观察自然地引出了对当前工具生态的讨论。

四、AI工具生态的"乐高积木"理论

为了进一步阐释智能体开发的复杂性,吴恩达提出了一个生动的"乐高积木"类比来解释当前AI工具生态的特点和开发者面临的挑战。

"我经常在脑海中想象这样一个画面:如果你只有紫色乐高积木,你就构建不出什么有趣的东西,"吴恩达解释道。他将各种AI工具比作不同颜色和形状的乐高积木,包括RAG(检索增强生成)、聊天机器人框架、内存系统、评估工具、护栏机制等等。

工具多样性的价值在吴恩达看来是显而易见的。就像拥有红色、黑色、黄色、绿色等各种颜色和形状的乐高积木一样,开发者掌握的工具越多样,就能越快地组装出真正酷炫的东西。这种多样性让开发者能够根据具体需求选择最合适的工具组合。

吴恩达进一步解释了这种工具掌握度的实际意义:"当你试图构建某个东西时,有时你需要那个形状古怪的特殊乐高积木,一些人知道并能够插入正确位置,然后完成工作。"但是,如果开发者从未构建过某种类型的评估系统,他们可能会花费额外的三个月时间做一些有经验的人几周就能完成的工作。

这种经验差距在AI领域尤其明显。吴恩达举例说,有经验的开发者会直接建议"我们应该用这种方式构建评估系统,使用LLM作为评判者,然后按照这个流程进行,"这样可以大大缩短开发周期。

工具的快速演进增加了这种挑战的复杂性。吴恩达特别提到了一个重要的变化:由于大语言模型的上下文长度越来越长,一年半前的很多RAG最佳实践现在已经不那么相关了

他回忆起Harrison在这些技术发展中的先锋作用:"Harrison很早就接触了很多这些技术,所以我试用了早期的LangChain RAG框架、递归摘要等功能。"但是,随着LLM上下文记忆能力的增强,现在的做法是直接将更多内容塞入LLM上下文中

这种技术进步带来了实际的便利:"RAG并没有消失,但超参数调优变得容易多了。现在有很大范围的超参数都能正常工作。"这意味着开发者不再需要像以前那样精确地调优RAG系统的各种参数。

吴恩达指出了一个重要的教训:随着LLM技术的持续进步,两年前的很多技术直觉可能已经不再适用。这要求开发者不仅要掌握当前的工具,还要持续更新自己的知识库,适应技术发展的快速变化。

这种"乐高积木"理论不仅解释了为什么智能体开发需要广泛的工具知识,也揭示了为什么项目决策速度如此重要——有经验的开发者能够快速识别和组合正确的工具,而缺乏经验的团队可能会在错误的技术路径上浪费大量时间。这个观察为接下来讨论被低估的工具和技术铺设了道路。

五、被低估的技术重点:评估系统的实践哲学

当Harrison询问哪些"乐高积木"工具被低估时,吴恩达的回答出人意料地回到了评估系统这个话题,尽管这是当天会议上已经有三位演讲者讨论过的内容。这个选择反映了一个重要现象:即使大家都在谈论评估的重要性,实际执行却严重不足

吴恩达分析了这种知行不一的根本原因:人们往往将构建评估系统视为一个巨大的、必须做对的工程项目。这种心理负担导致很多团队迟迟不开始构建评估系统,总是在等待"完美的时机"或"完整的方案"。

然而,吴恩达提出了一个截然不同的评估构建哲学:"我把评估系统看作是我要快速组装的东西,大概20分钟内完成,而且质量不会太好。"这种方法的核心在于快速启动,而非追求完美

吴恩达详细描述了他的实际做法:当他构建一个系统时,总会遇到某个特定问题导致性能回退——"我以为修好了,然后又坏了;我以为修好了,然后又坏了。真该死,这太烦人了。"在这种情况下,他会针对这个特定问题快速编写一个简单的评估,可能只有五个输入示例,用一个非常简单的LLM评判者来检查这个特定的回退问题。

这种方法的关键优势在于增量式改进。吴恩达强调:"我不是用自动化评估替代人工评估,我仍然会自己查看输出。但是当我修改某些东西时,我会运行这个评估来减轻思考这个问题的负担。"

渐进式评估构建的理念类似于软件开发中的迭代方法。吴恩达解释:"就像我们构建应用程序的方式一样,我们先构建一个快速且粗糙的、不工作的东西,然后逐步改进。我构建评估的方式也是如此——我构建了非常糟糕的、勉强能用的评估,然后当你看到它的表现时,你会说'这个评估有问题,我可以修复它',然后你逐步改进它。"

这种方法解决了评估系统构建中的心理障碍问题。许多团队因为追求完美的评估系统而永远不开始,吴恩达的方法则是"先有一个有缺陷但有用的评估,然后基于使用经验逐步改进"。

吴恩达还提到了一个更广泛的原则:评估系统的价值在于快速反馈,而非完美测量。一个简单但能够快速指出明显问题的评估系统,比一个复杂但构建周期很长的"完美"评估系统更有实际价值。

这种评估哲学体现了吴恩达作为实践者的智慧:在快速发展的AI领域,完美是优秀的敌人。通过降低评估系统的初始门槛,团队可以更快地进入迭代改进的正循环,而这恰恰是构建成功智能体系统的关键。这个讨论自然地引出了另一个被低估的技术领域——语音应用。

六、语音技术栈的隐藏价值与实现挑战

在讨论被低估的技术时,吴恩达特别强调了语音技术栈的巨大潜力,这个观点令人意外,因为语音技术看似已经得到了广泛关注。

吴恩达观察到一个有趣的现象:语音应用在大型企业中引起了极大的兴趣,他的朋友们对语音应用非常兴奋,很多大型企业也在积极探索语音应用的可能性。然而,在开发者社区中,专注于语音技术栈应用的开发者数量却远小于语音技术在大型企业中受到的重视程度

吴恩达认为这种不匹配反映了一个重要的市场机会。语音应用的价值不仅在于技术先进性,更在于用户体验的根本性改进

语音交互的心理学优势是吴恩达特别感兴趣的领域。他发现,文本输入框对很多用户来说实际上是令人生畏的。"对于很多应用,当我们对用户说'告诉我你的想法,这里有一个文本输入框,为我写一些文字'时,这实际上对用户来说非常令人生畏。"

更重要的是,文本输入存在一个根本性的用户体验问题:退格键的存在。"这里有一个问题,人们可以使用退格键,"吴恩达解释道,"所以人们通过文本回应会比较慢。"用户会反复编辑、修改自己的文字,试图表达得更准确或更完美。

相比之下,语音交互具有时间的不可逆性:"对于语音,时间会向前推进,你必须继续说话。你可以改变主意,实际上可以说'哦,我改变主意了,忘记前面说的那个',AI也很擅长处理这种情况。"

这种特性带来了意想不到的好处:语音交互降低了用户使用某些应用的摩擦。用户不需要组织完美的语言,不需要担心语法或表达的精确性,只需要"告诉我你的想法",然后用语音回应即可。

然而,语音应用也带来了独特的技术挑战,最关键的是延迟要求。"最大的区别是延迟要求,"吴恩达强调,"如果有人说了什么,你真的希望在一秒内回应,理想情况下少于500毫秒是很好的,但真正理想的是在一秒内。"

这个延迟要求与许多现有的智能化工作流程产生了根本性冲突,因为很多智能化工作流程需要运行很多秒。吴恩达分享了一个具体案例:当dblm.ai与RailAvatar合作构建吴恩达的虚拟形象时(这个虚拟形象现在可以在网页上与用户对话),初始版本有5-9秒的延迟,这造成了"糟糕的用户体验——你说了什么,然后9秒的沉默,然后我的虚拟形象回应"。

为了解决这个问题,团队开发了一种叫做"预回应"的技术。就像真实对话中人们会说"嗯,这很有趣"或"让我想想"一样,他们训练虚拟形象做类似的事情来掩盖延迟。"我们提示它基本上做这样的事情来隐藏延迟,实际上效果很好。"

吴恩达还分享了另一个有趣的发现:背景音效对用户接受度的影响。"如果你正在构建语音客服聊天机器人,如果你播放客服中心的背景噪音而不是死寂,人们对延迟的接受度会高得多。"

吴恩达强调,语音应用的价值不仅限于最新的端到端语音模型。事实上,他发现这些原生音频输入输出模型"非常难以控制"。相反,使用更智能化的语音技术栈工作流程能够提供更好的可控性。

语音交互的心理学效应是吴恩达认为最重要的价值所在。"我觉得当我们说话时,我们不会像写作时那样感觉需要达到完美,"他观察道,"所以人们更容易开始表达他们的想法,改变主意,来回讨论。这让我们能够从他们那里获得我们需要的信息来帮助用户前进。"

这个洞察揭示了语音技术的真正价值:不仅仅是技术便利性,更是用户行为和心理状态的根本性改变。这为语音应用在各种场景中的应用提供了理论基础,也解释了为什么大型企业对语音应用如此感兴趣。

七、MCP协议的现状与发展前景

谈话转向了最近备受关注的MCP(模型上下文协议),吴恩达和Harrison对这个新兴标准进行了深入的分析和评价。吴恩达首先透露,就在对话当天早上,他们与Anthropic联合发布了一门关于MCP的短期课程

吴恩达选择制作这门课程的原因很有趣:"我实际上在网上看到了很多关于MCP的内容,我觉得相当令人困惑。"这种困惑促使他们决定"创建一门真正优秀的MCP短期课程,清楚地解释它"。

MCP的重要性得到了行业认可。吴恩达认为MCP是"fantastic"的,因为它填补了一个明显的市场空白。更重要的是,OpenAI也采用了MCP标准,这证明了这个协议的重要性。在AI领域,当多个主要参与者都支持同一个标准时,通常预示着该标准具有长期价值。

吴恩达解释了MCP解决的核心问题:数据集成的复杂性。"当我使用LLM或构建应用程序时,坦率地说,对我们很多人来说,我们花费大量时间在管道工作上——数据集成,将上下文传递给LLM以使其能够做一些通常相当合理的事情。"

推理模型的能力与集成困难形成鲜明对比。吴恩达指出,特别是对于大型企业用户,"AI,尤其是推理模型,已经相当聪明了。当给定正确的上下文时,它们可以做很多事情。"问题在于,团队花费大量时间处理管道工作、数据集成,以便将上下文传递给LLM

MCP试图通过标准化接口来解决这个问题,使其"更容易让智能体(主要是智能体,但坦率地说我认为其他类型的软件也可以)连接到不同类型的数据"。这种标准化的价值在于避免了N×M的集成复杂度——如果有N个模型和M个数据源,理想情况下集成工作应该是N+M而不是N×M。

然而,吴恩达也坦诚地指出了MCP目前面临的挑战。"感觉有点像狂野西部,"他描述道,"你在网上找到的很多MCP服务器都不工作。"这种不成熟体现在多个方面:

认证系统的不稳定性是一个主要问题。"即使对于非常大的公司,MCP服务器的认证系统有点笨拙,不清楚认证令牌是否完全工作,何时过期,这类事情很多。"

协议本身仍然处于早期阶段。吴恩达分析了MCP当前架构的局限性:"现在,MCP给出了可用资源的长列表。最终,我认为我们需要某种更分层的发现机制。"

他进一步解释了这个问题的严重性:"想象你想构建某种东西——我不知道这是否会成为LangGraph的MCP接口,但LangGraph有如此多的API调用,你不能简单地有一个包含所有内容的长列表让智能体去筛选。"这需要某种分层发现机制来管理复杂性。

尽管存在这些挑战,吴恩达对MCP的前景仍然非常乐观:"我认为MCP是一个非常棒的第一步。绝对鼓励你学习它。如果你找到好的MCP服务器实现,它可能会让你的生活更轻松,帮助处理一些数据集成。"

吴恩达强调了MCP背后的核心理念的重要性:"当你有N个模型或N个智能体和M个数据源时,这不应该是N乘以M的工作量来完成所有集成,应该是N加M。我认为MCP是朝着这种数据集成方向迈出的一个极好的第一步。"

MCP将需要持续演进,但它建立了正确的基础架构思想。吴恩达预测,随着更多成熟的实现出现和协议本身的改进,MCP将成为AI应用开发的重要基础设施。这个讨论自然地引出了对另一个新兴领域——多智能体系统的探讨。

八、多智能体系统的现实与局限

当Harrison询问智能体间协作的发展情况时,吴恩达的回答展现了他作为实践者的务实态度。尽管多智能体系统在理论上具有吸引力,但吴恩达认为这个领域仍然过于早期

吴恩达首先坦诚地描述了当前面临的根本性挑战:"大多数人,包括我,我们甚至很难让我们的代码正常工作。"这个看似简单的陈述实际上揭示了一个深层问题:如果单个智能体系统的构建都充满挑战,那么多个智能体的协作就更加困难

他进一步阐释了这种困难:"让我的智能体与其他人的智能体协作,感觉像是需要两个奇迹的要求。"这种"双重奇迹"的比喻生动地说明了多智能体系统的复杂性——不仅每个智能体都需要正常工作,它们之间的协作协议也需要完美执行。

吴恩达区分了两种不同的多智能体场景。同一团队内的多智能体系统通常是可行的:"当一个团队构建多智能体系统时,这通常能工作。因为我们构建一堆智能体,它们相互通信,我们理解协议,这能工作。"

问题出现在跨团队的智能体协作上。吴恩达观察到,"至少在目前这个时刻,也许我是错的,我看到的一个团队的智能体或智能体集合成功与完全不同团队的智能体或智能体集合交互的例子数量,我认为我们在这方面还有点早。"

这种限制有多重原因。首先是技术标准化问题。不同团队开发的智能体可能使用不同的架构、协议和数据格式,使得互操作性变得复杂。其次是质量控制问题。当智能体需要与外部系统交互时,系统可靠性的要求会急剧增加,因为错误可能会传播和放大。

最后是复杂性管理问题。单个智能体系统已经需要大量的测试、监控和维护工作,多智能体系统的复杂性呈指数级增长。

吴恩达的评估得到了Harrison的认同:"我同意,我认为这还很早期。"他们都认为,如果说MCP还处于早期阶段,那么智能体间协作比MCP更加早期

这种务实的评估反映了AI领域的一个重要特点:理论可能性与实际可行性之间往往存在巨大差距。多智能体系统在理论上可以实现强大的功能,但在当前的技术成熟度下,专注于构建可靠的单智能体系统可能是更明智的选择。

吴恩达的观点暗示,多智能体系统的发展需要等待基础技术的进一步成熟。只有当单智能体系统变得足够可靠和标准化,跨团队协作才能成为现实。这个讨论为后续探讨当前热门的"vibe coding"现象提供了背景。

九、"Vibe Coding"现象的误解与本质

当两位聊起当前最受关注的"vibe coding"现象,吴恩达对这个术语表达了不满,认为这个命名误导了很多人对AI辅助编程本质的理解。

吴恩达首先肯定了AI辅助编程的价值:"很多人现在编程时几乎不看代码,我认为这是件好事。"但他对"vibe coding"这个名称感到遗憾:"不幸的是,它被称为vibe coding,因为这误导了很多人认为只需要凭感觉——接受这个,拒绝那个。"

这种命名的问题在于它暗示编程变成了一种轻松、随意的活动,只需要凭直觉就能完成。吴恩达的亲身经验完全否定了这种观点:"坦率地说,当我用AI编程系统进行一天的编程后,到一天结束时我筋疲力尽。这是一项深度智力活动。"

吴恩达强调,真正的AI辅助编程是一项高强度的智力工作。虽然开发者可能不需要亲自键入每一行代码,但他们需要:

  1. 理解AI生成的代码逻辑
  2. 判断代码质量和正确性
  3. 决定接受或修改建议
  4. 调试和优化生成的代码
  5. 整体把控项目架构和方向
"不过,虽然我认为这个名字很不幸,但这个现象是真实的,而且正在兴起,很棒,"吴恩达总结道。

这个讨论引出了一个更深层的话题:AI时代的编程学习建议。吴恩达透露,在过去一年中,一些人建议其他人不要学习编程,理由是AI将自动化编程工作。吴恩达认为这是"我们回顾时会发现的一些最糟糕的职业建议"。

吴恩达从历史角度分析了这种观点的错误性:"在过去几十年中,随着编程变得更容易,更多人开始编程。"他列举了几个历史例子:从打孔卡到键盘和终端的转变,从汇编语言到COBOL的进化。特别有趣的是,吴恩达发现了一些非常古老的文章,记录了当编程从汇编语言转向COBOL时,"当时就有人争论,'是的,我们有COBOL,它如此简单,我们不再需要程序员了。'"

历史的教训很清楚:每当编程变得更容易时,学习编程的人数量实际上会增加,而不是减少。"显然,当编程变得更容易时,更多人学会了编程。"

吴恩达预测,AI编程辅助将导致更多人学习编程:"随着AI编程辅助,更多人应该编程。"这个预测基于一个重要洞察:未来最重要的技能之一是能够准确告诉计算机你想要什么,让它为你执行

理解计算机工作原理的价值在AI时代不仅没有降低,反而变得更加重要:"理解计算机如何工作让你能够更精确地提示或指导计算机,这就是为什么我仍然建议每个人学习一门编程语言——学Python或其他什么。"

吴恩达分享了自己的经验来说明这个观点:"我个人是一个比JavaScript强得多的Python开发者。但是通过AI辅助编程,我现在写的JavaScript和TypeScript代码比以前多得多。"即使是在不熟悉的编程语言中,编程基础知识仍然至关重要:"即使在调试其他人为我编写的、我没有亲手编写的JavaScript代码时,真正理解错误情况是什么、这意味着什么,对我调试JavaScript代码真的很重要。"

这个分析揭示了AI时代编程的新特征:编程知识的作用从直接编码转向了理解、判断和指导。这种转变让编程技能变得更加重要,而不是相反。当Harrison询问吴恩达是否有更好的术语来替代"vibe coding"时,吴恩达承认这是个好问题,值得进一步思考。

十、AI创业的核心成功要素

对话的最后部分聚焦于吴恩达最新宣布的AI Fund新基金,以及他从多年创业投资经验中总结的核心成功法则

吴恩达首先介绍了AI Fund的运营模式:"AI Fund是一个风险工作室,我们构建公司,我们专门投资于我们共同创立的公司。"这种模式让吴恩达能够深度参与创业过程,也为他提供了观察成功要素的独特视角。

基于回顾AI Fund的经验教训,吴恩达提出了第一个也是最重要的成功预测因子:速度。"我会说成功创业的头号预测因子是速度,"吴恩达强调。

这个观点可能令人意外,但吴恩达进一步解释了为什么速度如此关键。"我知道我们在硅谷,但我看到很多人从未见过熟练团队能够执行的速度。"他观察到,很多人根本没有概念一个有技能的团队能够以多快的速度执行项目

"如果你以前从未见过,我知道你们很多人都见过,它就是比任何……慢节奏企业知道如何做的事情快得多,"吴恩达描述道。这种速度差异不是简单的效率提升,而是质的差别

吴恩达提到的第二个重要预测因子是技术知识。"第二个预测因子,也非常重要,是技术知识。"这个因素的重要性在于技术发展的快速变化。

吴恩达分析了创业所需技能的分布情况:"如果我们看构建创业公司所需的技能,有一些事情,比如如何营销、如何销售、如何定价等等,这些都很重要,但这些知识已经存在,所以分布更广。"

相比之下,技术知识的稀缺性使其成为最宝贵的资源:"但真正稀少的知识是技术实际上如何工作,因为技术发展如此快速。"吴恩达对非技术技能表示尊重——"我对市场开拓人员有深深的敬意,定价很难,营销很难,定位很难"——但他强调技术知识的分布更加稀缺。

"最稀少的资源是真正理解技术如何工作的人,"吴恩达总结道。这种理解不仅包括当前技术的工作原理,还包括技术发展趋势和可能性边界的判断。

基于这两个核心要素,AI Fund特别偏好与深度技术人员合作:"所以AI Fund,我们真的喜欢与深度技术人员合作,他们有良好的直觉或理解该做什么、不该做什么,这让你能够快两倍。"

这种技术深度带来的速度优势是显著的。有技术直觉的团队能够快速判断技术路径的可行性,避免在错误方向上浪费时间。他们知道什么时候应该坚持,什么时候应该放弃,什么时候应该采用不同的方法。

吴恩达最后表达了对商业技能的平衡看法:"很多商业方面的东西,那些知识非常重要,但通常更容易搞清楚。"这不是在贬低商业技能的重要性,而是指出在当前AI发展阶段,技术理解的稀缺性使其成为竞争优势的关键来源

这两个成功要素——速度和技术知识——在AI领域尤其重要,因为技术变化的速度要求团队能够快速适应和执行,而技术的复杂性要求团队具备深度的技术理解能力。

来源:至顶AI实验室

0赞

好文章,需要你的鼓励

2025

06/03

15:03

分享

点赞

邮件订阅