谷歌的A2A看起来很美，就不要想得太美了。

大家好，欢迎收听老范讲故事的YouTube频道。

“看起来很美，就不要想得太美了。”这句话哪来的呢？来自于猫腻的小说《将夜》。这个里面有一句话叫：“你长得很美，所以就不要想得太美了。”事情是在哪呢？是在隆庆皇子看到桑桑酒量很好，就想收其为侍女。桑桑呢，是里面的一位女主，而隆庆皇子呢，长得很漂亮，而且身份地位非常高，手持大义的一个人。他提出了这样的一个要求，当时的主人公宁缺就进行了反击，说：“你长得很美，就不要想得太美了。”意思是什么呢？就是保持对现实的清醒认知，你要知道自己是谁，几斤几两。而且呢，也要敢于对强权逻辑进行挑战。

那么，这个事儿跟今天咱们要讲的谷歌A2A有什么样的关系呢？首先先讲一下，谷歌A2A到底是个什么东西。

计算机和软件专家这么多年来呢，其实一直在为一件事情努力。什么事呢？就是让不同的系统，特别是异构的系统（所谓异构系统，就是说你的系统拿C语言写的在Windows上，我的系统是拿Python语言写的在Linux上，他的系统是拿其他什么语言写的在IBM小型机上或者什么这样的），让这些系统呢可以相互之间配合协作，完成一些更复杂的服务。这是这么多年来，计算机专家一直在努力干的事情。

很多的系统都沉淀下来了，你说你把那玩意扔了，让我重写一遍，这肯定不行。所以一定还是要让这个系统为我们大的事业去提供新的热量，不能推翻重干。这些旧的系统呢，实际上里边就都是“屎山”嘛，我们管它叫“屎山代码”。你真要重写一遍，也不是说写不出来，但是你总会丢一点什么东西。现在可能觉得不是什么问题，但是等以后需要找的时候，这个成本就可能会变得很高。你丢掉的这些东西，可能会变得很值钱。这些东西就是能不动就不动。像程序员讲的就是什么：“说我这代码很烂，说能跑不？”什么意思？“说代码跟你有一个能跑就行，要么代码能跑，要么你能跑。”所以能不动就别动这个东西，就要想办法让大家凑合起来，先把事儿做了。

A2A呢，其实也是类似这么一个事儿。它呢是人工智能代理协作的一个标准化方案。现在我们都在玩AI Agent，各种各样的Agent要搁在一起。A2A呢，就是Agent to Agent。它呢定义了统一的通信规则，智能体发现呀、任务分配呀、状态管理呀，我们定了一堆规则来解决跨平台协作的问题。比如说你这是Gemini，那边是OpenAI，Gemini下头还有一大堆的……

什么谷歌翻译、谷歌搜索、谷歌地图，OpenAI后头没准还有一堆office的东西，还有GPT4O画图。等于有一些这样的工具，它们相互之间说：“我们要去聊个天了，怎么能够协作把这事做好？”

我也不惦记说我把OpenAI干掉，你通通都用Gemini；OpenAI反过来也是这样，我也不惦记把Gemini干掉。咱们协作着能够把事干完就完了，各自把擅长的事情做掉。这个事呢，看起来挺美的是吧？

那咱们接着往下说。它呢还挺开放，这个协议。它基于什么样的通信协议呢？是HTTP，也就是咱们浏览网页的这个协议。通过这个协议来走，不要再去定义一些新的私有协议了。

然后，我们使用叫“服务端事件”的这样一种方式，来去确定说对方的服务器干怎么样了。叫SSE，Server-Side Event。通过这样的方式，来确定对方干完了没有，干成什么样了，去决定这个事情是不是接着往前走。

然后呢，让每个智能体写一个叫“智能体卡片”的东西。什么叫智能的卡片呢？就是说你写一个文件说：“我是谁谁谁，我擅长干什么，我在哪个服务器上，我的位置怎么样，你怎么找到我。”大概写这样的一个卡片，然后把这卡片呢找一个地方放好。

当要开始干活的时候，咱把这个卡片都找齐了。有这么多智能体，这个适合画画，那个适合搜索。我们把这些智能体都找齐了，然后现在我们要看一下，我们整个要干一什么事，让各个智能体一起去干活去。

然后还有一些什么状态管理干嘛呢？比如说视频渲染。我现在用AI生成视频了，这挺慢的对吧？你不能让所有的都等它一个。你说：“这边你去生成视频去吧，我就不管你了。”过一段时间去看一下，你的这个状态做完没有。过个5秒钟试一次，过个5秒钟试一次，发现做完了，我再把这个视频拎出来，合到整个的结果里边去。

它呢，通过任务对象，实现复杂协作流程的异步管理。这个话呢是有点计算机专业术语了。这里呢讲一下什么叫异步吧。同步、异步，这是两个相对应的词。

同步的意思就是说，我这边发出请求了，你要给我干一什么事。但是呢，你没干完之前，我站这等着你；你等你干完了，我拿着结果，我再往前走。这叫同步。

异步什么意思？就是刚才咱们讲的，你给我干事去，我就干别的去了。过过一会我再来回来看你，看一下状态对不对。状态变了以后，我再把你结果回收，我再接着去做其他事情。这个就是并行处理的一种方式吧。

所以现在呢，A2A都是可以支持异步处理的。这是目前为止Agent的通讯方面。

定义的最完善的一个协议了。能想到的，没想到的，基本上人全想到了。谷歌嘛，也不是白来的。

现在呢，有三种主流的大模型通讯协议，其实干的活都差不太多。

第一种是Function Calling，OpenAI做的。它呢，就是你把能够做事的工具描述成一个Function，也是用一个描述文件把它描述完了以后，告诉大模型说：“我这有一功能，等你需要的时候你就调就完了。”这是一种方式。

第二种方式呢，就是MCP，叫Model Context Protocol（模型上下文协议）。它呢，是把刚才我们讲的这个描述的过程变成了一个对服务的描述，说：“我这个功能是在哪台服务器上，或者是在本地的一个外部服务器上，怎么去调用，它能解决哪些问题，输入哪些参数，输出哪些参数。”也是这样的一个描述，然后把这个描述扔给大模型，它就干活去了。

那A2A呢，其实干的活也类似。它呢，就是说我们把所有的，甭管是功能也好，还是Agent也好，我们通通都写出卡片来：“我能干什么，我在哪。”然后把这些东西通通都扔在一个地儿，等干活的时候，我们把所有的卡片收集齐了，然后来决定到底怎么去干。

其实干的活都差不太多，只是呢：
– Function Calling必须是在本地进行编程；
– 而这个MCP呢，它支持调用服务器上的东西，可以调用远程的东西；
– 而A2A呢，就是你调用的东西不再仅仅是由大模型调用工具了，它可以在Agent之间、大模型之间进行调用了。它是这样的一个更进一步的协议。

说白了，这三个都差不太多，都是基于JSON的方式将功能描述出来，然后将这些描述呢作为提示词直接扔给大模型，扔过去就完事了。大模型适时调用，就是我需要的时候我就调它，调完了以后呢，让大模型是等在这儿，还是说接着干别的事去，定期来问询，来去确认状态。等收到结果以后，再把结果合并到大模型推理过程中再去干别的。

他们三个的区别就是一个比一个复杂，一个比一个完备，也就差在这了。那你说做的完备，这有什么不好的吗？这不应该把它设计的很完备吗？很多人听了以后说：“老范学了这么多年计算机，难道老想着拿这种半不拉拉的东西就凑合吗？”这个您还真说对了。最后流行起来的各种技术，基本上都是这种半吊子设计的。特别完备的技术一般都流行不起来。

给大家举一些历史上的这种追求完备性的失败的案例吧。这里说的失败呢，并不是说完全没有用起来的这个东西，而是说在未来没有成为主流协议，在大的竞争中失败了。

但是呢，还是有一些单位会去使用的这些方案。第一个叫Lotus Domino，这个呢就是多米诺骨牌那个Domino。这个是1996年出来的东西。IBM当时呢收购了Lotus Notes之后，雄心勃勃推出的系统。Lotus现在估计很多年轻人都没听说过。大家现在使用什么office、Excel这些东西，都觉得很强大很厉害。最早的做类似这种功能的人是谁呢？就是Lotus。第一个在电脑上可以让大家方便处理表格的工具，叫Lotus 123。Lotus也做了类似于Powerpoint、类似于word这样的工具。所以最早做office的实际上是他。后来被微软抄袭了以后呢很生气，把自己卖给IBM了。IBM说这我得替你把公道整回来，我们要让大家一起来继续用Lotus。

Lotus当时还做了一个叫Lotus Notes的工具，不但是把office功能都做完了，还做了很多的协作功能。我现在需要做工作流，我需要做OA系统，我需要在里头有权限，有正常的批文流转，你就可以用Lotus Notes来去实现的，要比office当时还是要领先挺多的。后来到IBM手里来说，我们既然已经可以让这个东西流转起来了，我们要怎么更进一步？他们就出了一个东西叫Domino。你像Domino骨牌嘛，推倒一块，哗啦哗啦要一一直这么往前走，起这个名字也是为了这个。它是最早期的群建解决方案，就是说可以把各种的信息都包装起来，支持分布式的数据库和安全机制。我的数据库不一定都要存在一个地儿，我可以存在不同的地方，相互之间配合来工作。曾被视为办公自动化的标杆，当时也是觉得非常非常强大。我当时还学了好长时间呢，学这玩意说这东西实在太厉害了，比其他的这些都要强太多了。因为各种你能想到没想到的，它全都给你做出来了。

但是就遇到了很多其他的问题。第一个是对于复杂系统的二次开发成本和部署、培训成本实在太高了。你要想开发这个系统，你必须要先去问说有几个处长，谁审批什么事，大家是怎么流程，你要先去干这个事。而且整个开发完了以后，你还要培训人家怎么使用。整个都做完了以后呢，下一个问题是什么？你业务不能变。你只要业务开始发生变化了，有迭代了，你刚才花的这些成本再来一遍，这个是很麻烦的。而且呢Lotus Domino有一个很大的问题是什么？它不支持Windows。IBM当时在推一个东西叫OS 2。IBM为什么去收购Lotus？

Lotus Notes回来要去跟Office打一仗呢，不服气。我是花钱找比尔·盖茨去开发PC DOS，后来又花钱去找比尔·盖茨去开发OS/2。结果比尔·盖茨呢，一边拿着我的钱去给我开发OS/2，还给我拖进度；一边自己偷偷把Windows做出来了。Windows把我的OS/2打得满地找牙，我不服气。我要找一个跟我补齐短板的东西，一起去把Windows跟Office重新战胜它。OS/2也没有打败Windows，Lotus Domino也没有打败Office，大概就是这样的。

而且IBM还干了一个什么事呢？它全套使用自己的解决方案和开发工具。你要想集成一些第三方的拓展，也是很麻烦的。最后呢，是被微软的Exchange和Office打败了。微软Exchange实际上是一套功能很强大的外部服务器。这是我们讲的第一个案例。

第二个案例是什么呢？叫SOA。这个东西呢，叫服务导向架构（Service-Oriented Architecture）。2000年左右开始推出，谁在后边推呢？Sun、IBM和Oracle。它是基于当时的J2EE架构。它什么意思呢？就是当时大家都是用Java去开发各种各样的业务系统。这些业务系统呢，你要让它跑起来，要让它相互串起来。比如说你开发了一个库存管理，我开发了一个电商系统，那边开发了一个物流系统。我们怎么能够让系统整个转起来呢？我最好是写一个我们叫企业服务总线，在这个上面把这个物流系统、仓储系统、电商系统串一块，这个事不就跑起来了吗？你们那系统我们就不用改了。

这个当时其实也是一个非常美好的愿景。它呢，支持跨语言、跨平台的服务调用，推动企业应用集成的规模化落地。你们原来都已经花了好多钱了，做了一大堆的这种子系统了，我们现在给你串起来，干这样的一个事情。他干这个事跟刚才咱们讲那个Lotus Domino有一点点像，只是这一块呢要更先进一些了。但最后也是失败了。

失败的原因呢，是服务编排依赖集中式治理，难以适应敏捷开发。大家都做好了以后，我们现在要给大家串起来。但其实是真的是每一个提供的服务接口后边都是一个屎山，光看所有的这些文档都看不过来。现在想规划各种新的业务，只能在屎山基础上再叠加屎山，最后就变得越来越复杂。这是第一个错误原因。

第二个呢，过度依赖于一些特别复杂的重量级标准。比如说里头有一个叫WSDL，这个标准呢叫Web服务描述语言。

Web service description language 就是我们要发现你的服务嘛？你这儿做了一个服务怎么办呢？你要写一堆的文件，让我去调用的时候可以去发现你。我们现在做很多的类似这种工作，都要做一个叫自解释。

我这有一个仓储管理的系统，这个仓储管理系统到底应该怎么用呢？你应该调用以后，你就出一个类似于文档式的东西，告诉你要怎么怎么调用，我使用什么样的权限，要把这东西都写在文档里，或者说写在一个说明的服务里面。就是你要调用这个服务，然后我来给你说明，我给你讲清楚，你才来个调用，要有很多这样的东西在里头。

然后呢，还有一个很重的协议叫SOAP（简单对象访问协议，Simple Object Access Protocol）。你也要描述说，我这个对象到底是怎么回事，它等于有一大堆这样的协议在里头。最后调用起来就非常非常麻烦。而且你想他这些东西，你也要把改造原来那个系统。以前你这有一个仓储系统，肯定是不支持什么WSDL和SOAP的，你得改造这个东西。

最后说我们懒得动了，或者说这个系统人家已经交付了，钱都付完了，我现在再去找人弄，没人理我了。所以最后也没推起来。最终呢，这个是被微服务架构给替代了。不要做这么复杂，不要做这么重，独立部署和轻量化的通讯，最后替代了这种SOA的系统。

现在我们正在使用的各种Restful。Restful是什么？就是说我也不用去说明你这个服务到底是怎么回事，我只管调用，调用完了以后，得到一个Json的返回结果就完事了。我们现在使用OpenAI的ChatGPT，使用Gemini，使用所有的这些网上服务的调用API接口，实际上都是Restful。这个就要简单很多，不需要这种自解释。

这是第二个失败案例。第三个失败案例呢叫Sharepoint。这个东西是2006年微软推的。微软说我这有office，有Windows，还有这么复杂的权限系统，大家进到我的Windows系统里头去，谁有什么样的权限我都管好了。我也想打造一个企业级的内容管理和协作平台，文档、门户、业务流程我都给你整合在一块。你们不要再去折腾找人买OA系统，找人再定制开发，别干这事了，我都一站式给你搞定。

我们以前写OA系统的时候，有一个很头疼的点是什么呢？就是我们需要处理office文档。你做了一大堆的各种流程，最后你还是要在office文档里去干活。微软说干脆我自己弄吧。

就整了这么一套东西出来。SharePoint这个东西，我也是参加过培训，还折腾了挺久。最后呢，也没有太大用起来。

它呢，深度集成了Office套件，提供了开箱即用的文档、版本控制和工作流引擎。比如说，你这儿是财务系统，我这儿是销售系统，那边是一个HR的系统。我们自己做自己的文档管理，别人想到我们的财务系统里去看一下财务的各种规章制度、一些相关的文件，根据他的权限就可以进来找了。它的这些功能都是完整的，听起来也是头头是道的一套系统。

最后呢，也是没玩下去。用户体验极其僵化，界面复杂、定制化依赖代码开发。你要定制这东西，你还是得写大量代码，非技术用户基本上没办法进行自我配置。而且它的生态碎片化非常严重，第三方插件兼容很差。企业需要投入大量的资源维护定制化功能，因为每一个企业都有各自的需求。这块对于SharePoint系统来说，基本上就是地狱。

最后替代的技术是什么呢？Slack。我们也别费劲了，你也别研究说谁有什么权限或者什么样的，咱们直接上IM，大家聊天就完了。需要的时候就直接把文件丢在里头，就传过去了。国内呢，就是像什么钉钉、飞书、企业微信，这些系统就把它替代掉了。微软呢后来说，我也不再推SharePoint这样复杂的、完善的东西了，最后做什么？叫Microsoft Teams。咱们在这个里面聊天传文件就完了，别搞什么权限管理这么复杂东西。

那么这些项目都是怎么失败的呢？咱们讲到这么多项目。第一个呢，就是这些都是大厂推的。咱们刚才讲的这三个案例，一个是IBM的，第二个是IBM、Sun、Oracle的，第三个是微软的，都是大厂在推，而且都是花了大钱在推。这3个都是请讲师讲课、出书、组织培训，我都参加过培训，也都买过书、都学过，而且非常完善，看起来都很美。他怎么能失败呢？

第一个是默认需求和各个组件的能力是固定的，要干什么这事就一定是定死了，不许改。第二个呢，就是每一个组件到底能干什么也是确定的，不允许有什么变化。这是他们这些系统在设计之初就已经埋下的雷，所以他们应对各种变化、应对第三方的这种接入，都是非常麻烦的。

那你说我们的系统就是很复杂，怎么办呢？他们解决的方法呢，都是通过增加复杂度来应对各种灵活性问题。你想把这东西变得稍微灵活一点，可以，没问题，我们增加一点复杂度，写点程序是可以搞定的。但这件事呢，你肯定是越往后复杂度就越高，那你最后里头堆积的屎山代码就越多。

最后，这维护性就越来越差嘛。而且呢，做类似这种协议里头，还有一个很大的问题是什么？私心太重。就像刚才咱们讲那个隆庆王子的故事似的，他想要人家女主回来给自己做侍女，都是有私心的。那你说这些大厂能有什么私心呢？都是想捆绑自己家的服务。一开始IBM说我不上Windows，我要上OS/2，这不是捆绑自己的东西吗？后边Oracle、IBM和Sun去推SOA的时候，他们都是卖小机的，卖中间件服务器的。你一旦走了这条路，大家就一定要把它这个全套系统都买齐。所以肯定还是说店家推自己的东西。至于最后这个Sharepoint，那微软说你得买我的操作系统，你买我的Office，一套都买齐了，你不要用别人任何东西。大家私心都很重，所以第三方技术很难兼容进来。

这种技术应用，刚才咱们讲了不是说没人用，也有人用。但是呢，它有一个很大的前提，就是需要有自上而下的需求，由最上面开会来决定这事要这么干，一层一层讨论，从上往下布置。这个事是可以用起来的。上层决策者呢，通常喜欢大厂，也喜欢相对比较完善的方案。举个例子吧，比如日本。日本的IT企业一般都是自上而下决策的。刚才咱们讲这三个技术：Lotus Domino，部分制造业企业比如丰田，早期用于内部的OA系统，依赖定制化开发。但是因为维护成本实在太高，后来还是被淘汰了，因为你不支持Windows，这事咋弄？没法整。SOA，日本的金融行业，比如像三菱的UFJ银行，曾经通过这个SOA进行整合过。但是因为架构僵化，难以支持移动端创新，近年来逐渐转向微服务，还没有彻底转干净。当时做SOA的时候，还没有移动互联网呢，所以没想到过这个问题。Sharepoint，政府机构比如说总务省用于文档管理。但是因为界面实在太不友好了，协作效率实在太低，现在已经逐渐被Google Workspace取代了。

走这条路呢，基本上就退出了创新迭代的第一梯队。最上面这个老板，他也是信息茧房，并不知道一线的人每天在遇到什么样的事情。由他去拍脑袋决定，下边人只管执行的这种模式，不是说这东西就做不好。但是呢，四平八稳的，所有新东西跟他没关系。通过这种方式呢，日本失去了它的互联网和移动互联网时代。现在在AI时代面前呢，也在踌躇吧，大概是这样的一个状态。

总结一下，A2A协议的设计逻辑呢，与历史案例中的很多失败范式高度相似。试图通过顶层设计解决复杂的协作问题，却忽略了技术演进。

{的动态性和生态多样性。当前Agent的核心其实还是大模型，而大模型本身的能力边界还非常不清晰，依然在快速扩张之中。这两天，谷歌Gemini 2.5又升级了，现在升级到Gemini 2.5 Pro 0506版，也就是5月6号这个版本，又遥遥领先了。这次是真遥遥领先，特别是在编码这一块遥遥领先。

那你现在都已经到这样了，你说你做一大堆A2A，把代码写进去了以后，你发现大模型升级了，你咋弄？你根本没法整这个事。所以，A2A的未来呢，充满了非常大的不确定性。作为现在的一些新的程序员，或者是一些新的技术人员来说，这种系统出来呢，还是值得学习一下的。但是，不建议大家在上面投入太多的精力，把一些很重的系统直接搭建在类似这样的协议上面去，未来转向会比较麻烦的。

好，这个故事今天就跟大家讲到这里。感谢大家收听，请帮忙点赞、点小铃铛，参加DISCORD讨论群。也欢迎有兴趣、有能力的朋友加入我们的付费频道。再见！

和文科生聊了一个小时的编程，我真的感受到了学文科是一件很重要的事情。大家好，欢迎收听老范讲故事的YouTube频道。前几天去字节跳动参加他们的TRAE发布会，和两个文科生——准确地说应该是一个文科生、一个设计师——聊了一个小时如何用AI做编程。我作为一个老程序员来说呢，很多时候还是偏保守的。我觉得现在AI编程还有很多事情没有做的那么好，但是产品经理是个文科生，另外一个是设计师，他们都异常兴奋，觉得哎呀这个实在是好厉害，一下就可以解决我们的很多问题。

今天呢，跟大家稍微的回顾一下下，然后再说一下我的感受。首先我感受到了深深的怨念。什么是深深的怨念？这个产品经理就说了，说你们这些程序员是不是很讨厌产品经理，每次看着我都很不耐烦，老觉得我什么也不会，只会给你们找事情。然后我每次提什么要求，你们这些程序员都不愿意给我做，总是找各种各样的理由。设计师也是满满的怨念，说我明明都设计好了，你为什么做出来就跟我设计的不一样呢？你们这些程序员还不停的来找我，说我能不能做出来跟你这个稍微差一点点，你为什么底下要画根线，我这根线能不能不做上去，你为什么要把这个按钮设计成这个颜色这个形状，下面还要有一个圈，我能不能不做这个东西，因为每次做这个东西都很费劲。

原来我们在猎豹移动的时候干过一个什么事情。当时的猎豹浏览器也是很多栏嘛，当时的设计师要求当你点击了某一个栏位，光标要从原来正在活跃的这个栏位上飘过来。但是这个东西很难做，大家知道我们写程序的时候是面对Chrome的底层去写程序，那个玩意不是从头就是我们做的。所以当设计师提出要求来的时候，程序员就会去问他说，你一定要这个光标飘过来吗？我直接把这个变亮，把那个变灭不就完事了吗？不要有这个中间飘的过程行不行？设计师说不行，我设计要有这种一致性，我整个的设计风格是什么样的。他们就会有这样的矛盾。

其实我跟产品经理和设计师打交道的机会并不多。为什么呢？因为我那个时代，程序员就负责所有的事情。我写程序的时候都是九几年，到2000年前后我在写程序，我写了10年的程序。然后，程序员开始跟产品经理、跟设计师打交道，是在后面大量的web应用、大量的这种移动应用上来以后，才会有后边的这个故事。像我们以前就是自己做就完了。我们那个时候做的产品都很难用，你必须要经过认真的培训，才可以把它用起来，而且都奇丑无比。因为我们那个时候，就是自己写就可以了嘛。我记得当时我去考大学的时候，学计算机不可以色盲。后来我说为什么学计算机不能色盲，说色盲的人设计出来的界面会大红大紫，红绿色盲嘛，你看不到这个颜色吗。后来，我上班了以后，就碰到了一位色盲程序员，本科不是学计算机的，他学了其他专业的本科，然后出来以后转行做程序员了。他设计出来那个界面就大红大绿的。但是后来的话，程序员、设计师跟这些产品经理，就成了三个冤家，必须要凑在一起才能干活了。他们讲完了那个话以后，我说哎呀我感受到了你们的怨念，你们都想把我干掉，然后他们也在那乐。这个沟通、适配、迭代，这是我们当时写程序的时候，团队里边解决怨念的方法。实在不行就出去喝一顿大酒，这个事情解决了，继续往前走。但是有的时候呢还很麻烦，为什么？因为有的时候这个程序员是男的，这个设计师和产品经理是女的，那个女生她不愿意出去跟你喝一顿大酒。当然也有一些程序员呢，就跟产品经理或者设计师，喜结连理了，吵着吵着就变成欢喜冤家了吧。产品经理呢给我们还讲了一个故事，产品经理他自己开了一个AI编程的课程，他原来一点编程都不会，然后写了一本书叫《AI编程蓝皮书》，开着课程开始去教课去了。然后一位60多岁的创始人，跑来学编程了，他就问人家说，您都这么大岁数了，您来学编程，而且您原来创业这个项目，也不像是公司里没有程序员的样子呀。这个老的创始人就跟他说了，我们原来公司里也有程序员，有十来个程序员的。

但是呢，我老信不过他们。每次向他们提点要求呢，他们就是：“哎呀，这个干不了，那个干不了，这个只能做成这样了，那个只能做成这样了，这个必须要一个月才能做完，那个还得再干俩月。”我老信不过他们，干脆我自己学一下，他们以后就不能再糊弄我了。

这就像什么呢？叫“非我族类，其心必异”。就像我们面对那些医生、律师、会计师那样，也是这么想的：“总有刁民想害朕，你们是不是都想坑我？”所以这位60多岁的老创始人，就跑去学编程去了。反正一个敢教，一个就真敢学。两人都不会编程，一个是产品经理，一个是从来没有学过编程的创始人，也是个团队的创始人嘛。两个人就开始学起来了。

我觉得等这位老创始人学成回去以后，估计会上演很多的狗血剧情。回头我再去问问他，这个老创始人学完了以后，他有没有做回访。但是我能够想象的出来，这种事情一定会鸡飞狗跳的。

那么，程序员到底在想什么？咱们来解答一下那位老创始人的疑问。你们来去跟程序员沟通，说：“把这个给我做一下，做不了；给我那个做一下，能不能打个折扣，稍微调整一下，找一个我熟悉的方式来做；你这个地方帮我改个小错误，就这么简单的一个错误给我改一下，这得改俩月，这可费劲了。”到底是发生了什么？

程序员思考的问题里头，完成功能只是很小很小的一部分。那你说你们做程序员的，你不给把功能完成了，你们都在想什么呢？第一个很简单的问题，技术选型。你要让我完成这个功能，我到底是用什么东西来去完成呢？你让我去炒个菜，那你说我是出去买个预制菜回来炒一下呢，还是说从现在开始耕地种粮食呢？程序员经常会想这样的问题。

而且有的时候为了做出最符合自己要求的这个功能来，他们真的会耕地种粮食，就是会从很根本的地方开始去做，而不是说用人家已经做的差不多了一半的东西，用现成的东西直接拼。这个用现成东西拼就是预制菜嘛。所以程序员经常会很纠结，到底选哪个呢？其实通常是选他自己熟的那个。然后程序员会想下一个问题是什么？代码复用。

我写完了这段代码了。我下次是不是还能再把它用上？或者我以前写的哪个代码好像跟这差不多，我怎么能把它用上？我为了让这个代码下次还可以用，我就要给这段代码里头写很多你当前这个功能所不需要的代码进去。为什么呢？因为我首先要写个注释吧，我要告诉他，我这个东西前面干什么了，后边干什么了，这个下回还能怎么用。然后还要写很复杂的这个架构吧，因为你想一段代码，比如说有1,000行，那我不能说我把这1,000行都用上，我要把它分好架构。而这个是50行，那个是30行，1,500行里头分成50行一段，30行一段。有人说你这不对，一开始说1,000行，怎么变1,500行了？因为凑这些架构又多出500行来。你说我只管把所有事都干完了，可能1,000行干完了，然后你说我为了有所有的这些架构，架构还很清晰，那我又多出500行来。那我下一次说，我用到这个里头的200行，我下次再用到另外那20行，他是这样来去规划的，叫代码复用。

然后还要思考什么？怎么进行效率提升？并行处理呗，哪两个事情之间不影响，让他们并行起来，这也是需要去思考的。还有一个很麻烦的是什么呢？环境适配。这个是什么东西？我这个程序能在PC上跑，能在网页上跑，能在安卓手机上跑，能在苹果手机上跑，或者我还有一部分是要到亚马逊云上去跑，或者到阿里云上去跑。那每一个系统后边都有一大堆的规范文档在那儿，那我要想适配他们，这个也很麻烦。还要避免各种各样的极端情况，什么极端情况？同时有30个人用这个事没问题，可以跑，同时有1,000个人用，程序崩了，这个也是需要在写程序的时候思考的问题。

而且写程序的人有的时候叫什么呢？叫江湖越老胆子越小。为什么？就各种坑都踩过了嘛，等下次再走的时候说，你怎么用这样奇怪的一个姿势在这儿走路？你不知道那里有坑，他是这样的一个发展过程。所以这就是导致为什么说这些文科生，这些设计师，这些产品经理，这些创始人。

觉得程序员那么不可理喻的一个原因，而且程序员想的刚才所有这些东西，其实都是可能在写程序的过程中很小的一部分。那你说剩下的时间你们都干嘛去了？这个程序员的工资不低，你们都天天在这摸鱼吗？不是，当然摸鱼肯定也要摸了。这个程序员真正用很多的时间去思考的东西，叫团队协作。这什么意思？我写完代码下一个人要改，下一个人可能还是我。那你说你这怎么又绕回来？明日之我不是今日之我，他是这样的一个过程。像我们经常写着写着程序说：“哎呀，这个程序是我三年前写的，当时到底怎么想的？”

我记得原来有一个故事，大夫写字不都写的特别潦草吗？有一次写了个药方子，到那个药房去抓药去了，实在认不出来是什么字了，然后就回去找这大夫，说：“大夫，您这字到底写的什么呀？”这大夫看了半天，然后一拍桌子：“何不早问？你早干嘛去了？现在你问我，我也想不起来了。”

所以呢，我们要做很多很多的事情是为协作的，即使是自己跟自己协作，也是需要写很多的代码，写很多的注释，做很多的加工设计。所以软件的本质是工程，不是软件本身。真正实现功能的部分只占很少很少很少的一部分，软件里面绝大部分的内容都是防止程序员迷路的。我们在这里钉个小牌牌，说：“你再往前走三步有一个坑。”这个是真正软件工程里边去做的。而且你钉完小牌牌以后，还要写某年某月某日，谁谁谁在这里钉的小牌牌。

所以呢，这就是屎山代码，什么意思？就是一大坨代码谁也不敢动。因为我们刚才讲复用嘛，你复用了以后，就会有这个代码依赖的关系，这个代码要依赖那个代码。那么你在这个东西想要再去调整，再去修改，就会变得非常非常难，叫牵一发动全身。你修改掉一个bug以后，可能带来10个bug。然后为了避免这个东西，我们还要有一堆人再去思考，再去研究。还有很多人硕士、博士学位，出来学什么软件工程学，人家学的不是说我要去实现什么功能，就是我们学习如何在可以接受的成本范围内，组织很多的人进行分工。

把一个巨大的软件工程完成掉，这也是一门专门的学问。那么，非程序员到底是怎么看程序员的呢？其实就像我们去看老中医。这些非程序员不愿意为功能之外的事情进行沟通。你说找个程序员来给我做个功能吧，这个程序员再去跟他讲效率，再去跟他讲兼容性，再去跟他讲，说你到底是要在安卓手机上用，还是要在苹果手机上用的时候，文科生、产品经理、设计师就会觉得很烦，而说这个就这么简单的一个事情，怎么搞不定呢？

我举一个最简单的案例。你比如说设计师设计了一个小动画，程序员就去问了，说你要安卓手机用还是苹果手机用。这个设计师说，你就都实现了不就完了吗？然后这个程序员就哭了。为啥呀？因为苹果手机好实现，你可能一句话把这事搞定了。安卓手机呢，可能就费劲，你可能需要写很多很多的代码才可以实现。而且你一旦要求安卓手机实践的话，他还要问你说，你这个到底是在2,000块钱以上的安卓手机上实现呢，还是4,000块钱以上的安卓手机上实现呢，还是要求1,000块钱以下的安卓手机也能实现呢？

很多人觉得这不是问题，没做过程序员的人完全无法想象这个。为什么？我告诉你，安卓手机算力是有限的。很多这种前端界面上的事情，到这个很便宜的安卓手机上是渲染不出来的，或者渲染出来会很难看，会有这样的问题。所以你作为设计师来说，你给我作出来不就完了吗？程序员说，您上下嘴一碰说出来了，但是到我这可费劲了。所以这个会有很多的沟通、交流上的一些障碍。

除了不愿意为了功能之外的事情进行沟通之外呢，这些非程序员还有一个问题是什么？他们不愿意为了功能之外的事情支付成本。比如说创始人来了说程序员，你给我去做一个什么什么功能。咱们依然是上面这个事情，你如果只做苹果的，很快就可以做完了。你要求把安卓的也做了，而且要求1,000块钱以下的安卓手机也能跑，那你要花很多的时间，甚至花很多的钱，那个程序员工资会上升的。

能够解决这样问题的程序员是很贵的。这种事情我们原来是真的发生过的。原来跟大家吹过牛，我们以前投资的Musically，他最早就只做了苹果的版本，安卓版本他没做。等到做安卓版本的时候，发现他做不出来了。为什么？他们做的大量功能，在苹果手机上一句话就搞定了，因为iOS系统其实是相当完善的。安卓系统呢？你说为什么不做那么完善呢？这个谷歌就笨吗？谷歌也不笨。他之所以不做那么完善的原因，是因为他没有办法控制硬件。他把这个功能都做的很完善了以后，你到不同的这个硬件厂商上，三星的、HTC的、华为的、小米的手机上，它不一定都跑得起来。所以呢，它就很多的功能它不能做，它一定要让手机厂商去把它完善出来。所以当时他们就搞不定了，说Musically这个软件要到安卓手机上实现，实现不了了。那怎么办呢？找我们说你作为投资人，微暴移动你投了我们了，这事你得搞定。那没办法，那上边我们就派了大量的程序员，坐到他们的办公室里来，我们替你搞定，每一个功能都可以实现出来。但这个就是成本。你要碰到这种不是那么明白的人去搞这个事情，这就费劲了。你像刚才我们讲的，60多岁的老创始人，找了一个不会编程的产品经理，学了半天AI编程以后，那回去不炒成一锅酱糊才怪嘞。最后一个问题是什么呢？就是这些非程序员，他们往往是以结果论成败的。很多东西在表面上他是看不到的。就像刚才我们讲的，你同样的功能，你在安卓手机上实现出来，可能还没有苹果手机上实现出来好看，但是呢，费老鼻子劲了。对于不懂程序的这些文科生或者设计师来说，你们这些苹果程序员好厉害，你们这些安卓程序员很笨。原因其实很简单，苹果自己做的好，安卓自己本身底层比较烂，那也没办法，他就会有这样的片面的认知在里头。而且后台的程序他看不到，他们就说前台的这帮人，你们这个功能一个一个实现的很好，后端的人你们程序怎么又蹦了。他只永远只看到这一个，因为后台嘛，只有这一个结果。

崩了，没崩。崩了，没崩。没有别的了。讲到这了，很多人会觉得，我是不是要为程序员叫屈？但是看看前面我的标题是什么？是我觉得学文科是很重要的。文科生非常非常重要。为什么我跟他们聊完了以后，他们对程序员有这么大的怨念，我反而会得出结论说文科很重要的？其实这就是设身处地的思考。

我用Midjourney画图，画了自己也很开心。画完了以后，我觉得我的情绪会得到了抒发，这个非常棒。我用DeepSeek写小说，写出来的东西呢，我看着也挺开心的。这一段看着不错，那段看着也不错。但是我在那天听完了他们讲之后，我突然意识到了一个问题是什么？我是没有能力将很多的画，按照统一的风格，或者说呢叫做一致性，把这些一致性的画，拼凑成一个完整的绘本呢。我也没有能力把这个几十万字、几百万字拼凑在一起，成为一本小说了。

像这个DeepSeek也好，或者各种的写小说的这个AI也好，你命令下去以后，大概就给你写1,000字出来。你要想让他写2,000字都很费劲。而且你命令他写2,000字的话，后面的1,000字的质量就会明显的下降。所以千万不要试图让AI一次性给你输出很长的内容。很多人说DeepSearch这样的东西，不是一次出来很多的东西吗？对，他那个东西不是一次出来，他也是拼成小段，一段一段出来的。所以呢，我是没有能力拼出小说来的。

而且呢，我也没有办法去判定一幅画，或者1,000字、1,000字的这种文字片段，到底好还是不好。术业有专攻。我上了四年大学，几十年的工作训练，掌握了非常多的技巧。那么我就可以去跟这些文科生去讲，跟这些设计师去讲，说：“哎，为什么你这东西能做？为什么不能做？你如果一定想做，到底需要支付多少成本？”这个事情我能跟他讲清楚。而且哪个东西会更好一些，更坏一些，这个事情我也可以给他讲清楚。

文科生、艺术生其实同样是这样。他们也是上了大学，也是经过十几年、几十年的工作训练。而且文科生跟艺术生……

他们所掌握的技巧是更难进行衡量、量化和迭代的。像我们其实一直在研究工程的问题，我们做的所有结果都是可以量化、可以进行迭代的。他们那些东西很多是感性的东西，比我们这个还费劲。所以在这样的一个情况下，我觉得他们更加重要一些。

所以现在很多人说，我们是不是应该把文科的取消掉，应该让更多的人去学理工科。这个事是错的。AI距离替代程序员目前还非常遥远，当然它在快速的向这个方向走。但是AI距离替代文科生和艺术生，应该更远。

很多人说不对，AIGC它生成内容了，它能生成图片、能够生成视频、能够生成音乐、能够生成文字了。但是这个东西距离诗和远方还非常非常遥远。就像文科生写程序一样，他们写出来的就是一坨坨屎。这个真的不是说看不起他们，因为AI现在所生成出来的这些代码片段，就像我们生成的图片或者写出来的文章是一样的，是没法拼凑在一起了。拼出屎山这件事本身是很难的，不是说你可以把一堆屎搁在一块，就是一堆屎山的。最后一大堆碎片，你可能连拼都拼不起来。

像我们写程序也是有风格化的，也是有一些代码编程规范的。现在AI生成的代码，它会在不同的文件里边生成不同规范、不同风格的代码。这种东西是拼不到一块的。还有就是我们没有办法去判断这些图片跟文字的好坏，这个时候还是需要这些文科生、需要这些艺术生，他们才可以去判断。

那么为什么大家都觉得可以取代对方呢？这个还是评判的标准不一样。我觉得我画的Midjourney很漂亮，让我的情感得到了抒发，让我的情绪得到了满足。我觉得我写的小说也挺好，这就是程序员在评判文科生跟艺术生的成就。而那边呢，产品经理教人写程序，大家都觉得挺好。这就是文科生跟艺术生觉得他们懂编程了。

其实是一样的，就是我们拿出来的这些画，我们拿出来这些文字，让文科生看了以后，让艺术生看了以后觉得很可笑。就跟他们拿出来的代码让我们看了，也觉得很可笑是一样的。

但是现在，8岁小女孩写游戏这样的故事，他很有传播性。大家对于AI也抱有了远远超越其能力的这种预期。AI创业者呢，其实也不愿意出来纠正这种误解。他希望说：“你们先误解着，我那头没准加加班赶赶工，这个AI就赶上来了呢。等你发现这个东西有问题之前，我就把功能做出来了。”这个是很多程序员喜欢干的事。所以这就是大家现在都觉得可以替换别人，各个公司都在这疯狂裁员，就是这样的一个原因。

Deepseek今年其实已经造成了大量的裁员。那么，应该如何面对未来呢？肯定还是要交叉学习对方的技巧。因为现在有了AICC以后，工作效率提升了，有了一些空闲的时间，多去学一些交叉的学科。但是与此同时，一定要心怀敬畏，千万不要上来说：“我懂了，你们都靠边站。”这个是要翻车的，是要出问题的。

而且，我们要准备迎接更加奇轨的未来，就是端道端。刚才我还在讲我们在吵架，文科生、理科生、美术生，三个人坐在这在吵架呢。等到最后端到端的时候，就连吵架的机会都没有了。到那个时候，就是上帝说要有光，于是就有了光。可能我们就真的不知道该去搞什么了。

那么，应该如何去迎接端道端这个过程呢？其实就像自动驾驶一样，先是给你一些提醒，最基础的是：“哎，前面有车了，我给你警告一下。”然后呢说：“我可以帮你去开一点，但是你的手要放在方向盘上。”再然后呢是说：“唉，手可以不用放在方向盘上了，但你人得坐着得看着，随时准备接管。”最后呢，是说：“人不用在这呆着了。”到最后一步就叫端到端了。这个也是一个一步一步往前走的过程。

端到端之后的话，我觉得我们可能应该学习日本人造汽车的方法。他们始终会保持一条纯手工的生产线，就是其他的都是用机器来生产，用流水线。绝大部分汽车也都是在流水线上做出来的。但是呢，始终有一条线是用纯手工生产。最后，他要确保生产线上下来的汽车跟纯手工组装的汽车品质完全相同。这可能是我们未来面对端到端的时候所必须去采取的一些措施。否则的话，万一出了一些问题。

因为一旦端到端了以后，出了问题你是一点办法都没有。你都不知道中间是发生了什么。这可能就是我们的未来。在未来的话，文科生、设计师都很重要，程序员也很重要。谁都不应该失去工作。好，这个故事今天就讲到这里。请帮忙点赞、点小铃铛，参加Discord讨论群，也欢迎有兴趣、有能力的朋友加入我们的付费频道。再见。