阅读全文

⭐⭐⭐ Spring Boot 项目实战	⭐⭐⭐ Spring Cloud 项目实战
《Dubbo 实现原理与源码解析 —— 精品合集》	《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》	《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》	《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》	《Java 面试题 + Java 学习指南》

摘要: 原创出处 头哥侃码 「王晔倞」欢迎转载，保留摘要，谢谢！

• 误导1：三年后， AI将全面取代前端开发
• 误导2：玩什么监控，今后都是用大模型来精准定位了
• 误导3：ERP已死，中台已凉，低代码称王
• 误导4：上云成本太高，还是自建机房吧

---

🙂🙂🙂关注微信公众号：【芋道源码】有福利：

1. RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表
2. RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址
3. 您对于源码的疑问每条留言都将得到认真回复。甚至不知道如何读源码也可以请教噢。
4. 新的源码解析文章实时收到通知。每周更新一篇左右。
5. 认真的源码交流微信群。

---

关注我的很多朋友应该都看过我之前写的文章，也看过我很多次的直播。说起来，我本人是非常瞧不起网红的一个人，虽然很多人都把我当成网红。但是我做“网红”是属于比较偏正能量，或者说也是一个比较“刚”的人。

我基本把这些分享当作一个休闲的模式来看待，所以我不会在这个途径上去做标题党相关的操作，说白了就是我的分享不会刻意去带任何的商业利益价值。相对来说，我不会去为了某个人或者某些事情去发表意见，或者是提出什么建设性的措施等等，我只会去剖析它的一些真实性。

其次对于我来说，我个人是不太愿意去讲一些我没有经历过的事情。我也很少对一些事件和观点进行评头论足，我分享的故事也基本是我原先经历过的事情或者身边朋友的故事，所以它更多是一种经验的分享。

但是很多活跃在互联网的「头部博主」或者大V等等，他们就喜欢拿某个东西去做定性，尤其是一些没有标准答案的东西。而像大部分的网红，其实就是通过「制造话题」来引起大规模的讨论。因为他需要的就是流量，流量的背后是变现，所以这个是网红的一个正常「输出」途径。

说了这么多，其实今天就想跟大家唠唠过去这一年发生的事情。2023年发生了很多有意义的时代节点故事，比如AI大语言模型的诞生与爆火。大模型出来了以后，面对这种风口网红们自然不会放过。所以过去一年，我们看到了很多关于AI话题的讨论，各种「理论」也开始被鼓吹得越发厉害。

其实去年也有很多的小伙伴咨询我，问我说这些言论到底是不是正确的啊。其实我们私下也对这些话题有所探讨，所以今天就想趁着这个机会，好好跟大家聊聊过去一年，在我个人眼中，过去一年那些被“技术网红”误导的四个技术趋势。

误导1：三年后， AI将全面取代前端开发

首先，对于类似「三年后， AI将全面取代前端开发」这种话题，我个人认为这个说法可能过于激进，这实际上就是一些网红在制造舆论。

之前我邀请了很多嘉宾来我的直播间，一起探讨与大型语言模型、未来趋势等相关的话题。基本上很多人都认为，目前在AI领域，尤其是像GPT-3.5和GPT-4等大型语言模型的出现，这项技术确实是掀起了新的时代浪潮，但实际上它们目前在实践过程中还是存在很多局限性，或者说是能够完成的任务还是相对有限的。

所以，即便在未来三年，尽管它们可能有所改进，我还是认为AI的实际应用范围仍然相对狭窄。比如，前段时间我讨论了一个话题，关于AI是否会取代程序员。我举了一个实际例子，我们曾经使用Eclipse编写Java代码，然后发现现在有了更好用的工具可以直接使用等等。虽然工具可以让操作流程变得更方便，但如果你只是关注代码是否能够运行得通，对于后面的方式、方法、构造器等了解不深的话，你就可能会被淘汰。

所以对于AI在前端开发中的应用，我自始至终认为它还是一个辅助工具。从技术角度来看，AI在前端开发中的实践场景主要体现在提高工作效率层面。例如，AI可以辅助PRD到代码、设计到代码的流程，也能像Github Copilot、Vercel的v0一样，为开发提供便利。这些工具确实能够在开发中带来一些便捷，但并不意味着AI会完全取代前端开发人员。

具体来说，在需求分析、交互设计以及软件硬编码等方面的工作，AI为整个流程带来了实时在线和动态化的可能性。然而，这并不意味着前端工程师的角色会被淘汰。前端工程师的价值在于对业务的深入了解，这是AI所无法替代的。

我曾经有过一个经历，刚开始工作时我从事美工和3D建模，后来学习了编程，因为我意识到只有通过学习新技能才能确保未来的发展。因此，我建议大家多往业务方向发展，而不是过分关注技术。前端工程师需要更深刻地了解业务，因为他们是最接近业务的人之一。

所以，对于误导1的看法，总结来说就是太极端了。AI是一个辅助工具，可以提高效率，但前端工程师的设计和业务理解永远无法被完全替代。可能在某些公司和业务场景中，产品经理和前端工程师的职责会有所交叠，但前端工程师永远不会被全面取代。工具的升级只是为了更好地支持前端开发，而不是取代它。

在未来，我们可能会看到前端工程师越来越与产品经理结合，但这并不意味着前端工程师会被淘汰。最重要的是，前端工程师不要成为一个只会使用工具而不关注业务的人。如果你变成了一个只会撸代码的前端工具，你的存在意义将会变得模糊，可能最终被产品经理所替代。

最后，我提醒大家，很多自媒体，尤其是依赖流量变现的自媒体，在写关于AI和AIGC的文章时，往往倾向于制造焦虑。我告诉大家，焦虑的核心是增加焦虑。我们应该理性看待AI的发展，不要被过度渲染的言论所左右。

你瞧，这说着说着就绕进了心理学的范畴，而且和社会学经济学统计学以及其它学科挂上钩了。

误导2：玩什么监控，今后都是用大模型来精准定位了

我之前阅读过很多关于大型语言模型的文章，这些文章声称这些模型具备精准的分析和定位能力。很多人，尤其是在运维领域的从业者，将大型语言模型与我们的监控、APM以及AIOps联系起来。

在我之前的一场直播里我与某公司的一位运维总监进行了对话。我们一同讨论了与大型语言模型、运维和AIOps相关的话题。然而，我个人和他都不认同大型语言模型与运维和AIOps有所关联。我坚信这种关联是永远不可能的。

我发现在我们的圈子里，一些技术网红写了一些文章，将大型语言模型和AIOps联系在一起，提出了一堆理论。首先，我想说这个话题本身就不成立。

为什么呢？因为它存在以下几个矛盾点。

首先是成本不匹配。不论是大型语言模型还是小型语言模型，它们的源头是什么？一个模型要进行训练，它的基础是什么？我认为有两个关键因素，一个是基础的数据量，可被训练的数据量；第二个是算力，即运用场景和数据集。

在监控和UPS领域，数据是什么？数据通常是异常和故障。在UPS的运维过程中，我们首先发现问题，再解决。运维场景中有两个关键词，一个是发现，一个是解决。

如何才能发现异常和故障呢？这是一个挑战。有人可能会说，如果CPU或内存超过80%，就是异常。但实际上，运维是与业务相关的，每个系统的架构都不同，没有标准化的流程和规则。

想象一下，如果在一家公司内，系统架构在很长一段时间内不发生变化，并且有大量异常和故障数据用于训练模型，这种场景是否存在？是不存在的。

因此，我要告诉大家的是，虽然AI有用，但它不存在替换。它不仅不可能局部替换，更不可能全面替换。这是不可能的。

其次是运维，尤其是在最终决策方面，无论是算力还是存储，这些都是一次一次血的教训沉淀下来的。决策涉及到业务服务宗旨，是生死攸关的事情。你会发现有很多操作，比如重启。重启在技术上是很简单的，但为什么我们没有使用AI来执行重启呢？因为最终的决策权一定是由人来做的。

对于异常和故障以及决策这些运维动作，在业务看来都是造成阻塞的。

即使在一些特定场景下使用滚动下线和滚动升级，对业务也是有损的，算力下降了。

最后就是性价比太低。如果是依靠AI进行性能化工作，所需的投入相当高，而招聘一个SRE（Site Reliability Engineering）的成本相对较低。当然，我们希望在未来AI有这样的能力，但实际上这在短时间内是难以实现的。

因此，大模型的应用在运维领域存在一些不切实际的问题，远远没有取代人工的可能性。

误导3：ERP已死，中台已凉，低代码称王

去年也有一些技术网红写过一系列类似的文章，谈论「ERP已死、中台已凉、低代码称王」等话题。

我不知道大家是否看过这样的文章，尤其是关于中台凉了的这种文章，感觉「中台」这个概念已经被很多人玩烂了，而且现在你会发现，前几年低代码和无代码都非常火，许多公司或者项目都因此备受瞩目。

不过实际上，我们需要回到问题的本质，即ERP和中台这些东西，到底在解决什么问题？

我个人之前也分享过关于中台的相关文章。这里我也再提及一次，中台主要解决的是企业在增量市场中快速创新的问题。说白了就是企业在搭建系统的过程中害怕大量的重复性造轮子，而中台解决的是这个问题。它将大量相同和同质化的内容下沉，将个性化的内容上浮，实际上是解决快速创新的问题。

但如果你的企业没有遇到快速创新，比如你做的业务非常固化，那你就不需要中台。因为中台适用于需要频繁变化和创新的场景，比如电商。与此同时，中台适用于多条业务线的前提，所以很多公司它其实只有一条业务线，还要跟风在那搭建中台，这就说明，你连中台是什么都没搞清楚！

在我看来，中台必须具备两个特性。第一个是业务线比较多，而且逻辑组合变化快。你要有多条业务线，才有必要讨论中台的话题。第二个是你的公司和团队必须用屁股认可敏捷文化，该上浮的上浮，该下沉的坚决下沉。有的人天天挂在嘴上说敏捷，但在实践中永远不动，不用屁股去认可敏捷文化。这是一个很现实的问题。

比如像我之前在金融公司，当我们做互联网金融时，它追求的就是快，需要业务出来马上上线。在这种情况下，我们会把团队做成一条团队，包括开发、测试、业务和运维，效率一定会高。所以，我觉得中台解决的就是这个问题。

而低代码满足了企业敏捷能力的诉求，其核心价值是帮助企业快速建立敏捷能力。敏捷文化是拍脑袋决定的，但要快起来，你需要敏捷的工具，这就是低代码和无代码的价值。它们能够让你快速变化，比传统的硬代码更加灵活。

相比传统的硬代码，低代码更加灵活，通过简化开发流程，能够快速适应业务需求的变更。这使得企业能够更迅速地上线业务，对于需要频繁迭代的业务来说尤为重要。

总体而言，中台和低代码都是为了让企业更好地适应快速创新的需求。它们在不同的场景下各自发挥优势，为企业提供了更灵活、高效的解决方案。而并不是什么网红鼓吹的这不行了，那个相当行之类的。所以各自业务需要什么，还是要看实际场景和需求来选择。

误导4：上云成本太高，还是自建机房吧

我最后跟大家分享被技术网红误导的趋势，就是“下云”。记住这里是“下云”，不是“上云”。

为什么下云呢，因为上云成本太高了。

关于上云的成本太高，要下云或者自建机房的问题，凡是有提到自建机房好的文章，你会发现他基本就咬准了「上云的成本太高」这一个点去输出。

上云为什么成本高呢？其实主要有以下原因。

第一个是服务器的静默成本转向了动态成本，这个变化是巨大的，基本上是1.5倍到2倍，甚至更大。每家公司情况不同，但是软件成本，从云下切到云上，成本就高了。

大量的改变，比如你的数据库从Oracle迁移到云上，是非常困难的，需要业务切片和拆分，可能要搞5年都搞不定。所以，企业下云确实可以省钱，但这需要具备一定规模的服务器资源和强大的运营团队。

除此之外，其实还有一个最大的问题，那就是和做决策的老板的信仰有关。说到底就是老板的出身和脑回路决定了他怎么看待这个成本。如果老板是财务出身，他一定讲逻辑，讲脑回路，而成本中心的人很难用这样的逻辑去和他沟通。这在金融领域尤其突出，一些老派的金融领导就是这种思维，所以你解决不了这个现状。

当然，除了以上这些因素外，最关键的还是应用是否具备云原生能力。有的人认为上不上云没什么区别，因为上的都是虚拟机，都是容器化，部署都没区别。但实际上，在K8s上部署和在虚拟机上部署是不一样的，一个是在容器上，一个是在操作系统上。所以选择上云时，应用是否具备云原生特性是一个很关键的决定方向。

最后，在我看来，上云还是下云就好比买房和租房的矛盾。上云就像是租房，下云就像是买房。在现实中，租房和买房都有利弊，必须结合自身情况选择上云还是下云，才能走出正道。