👉 这是一个或许对你有用的社群
🐱 一对一交流/面试小册/简历优化/求职解惑，欢迎加入「芋道快速开发平台」知识星球。下面是星球提供的部分资料：
《项目实战（视频）》：从书中学，往事上“练”
《互联网高频面试题》：面朝简历学习，春暖花开
《架构 x 系统设计》：摧枯拉朽，掌控面试高频场景题
《精进 Java 学习指南》：系统学习，互联网主流技术栈
《必读 Java 源码专栏》：知其然，知其所以然
👉这是一个或许对你有用的开源项目
国产 Star 破 10w+ 的开源项目，前端包括管理后台 + 微信小程序，后端支持单体和微服务架构。
功能涵盖 RBAC 权限、SaaS 多租户、数据权限、商城、支付、工作流、大屏报表、微信公众号、CRM 等等功能：
Boot 仓库：https://gitee.com/zhijiantianya/ruoyi-vue-pro
Cloud 仓库：https://gitee.com/zhijiantianya/yudao-cloud
视频教程：https://doc.iocoder.cn
【国内首批】支持 JDK 21 + SpringBoot 3.2.2、JDK 8 + Spring Boot 2.7.18 双版本
关注我的很多朋友应该都看过我之前写的文章，也看过我很多次的直播。说起来，我本人是非常瞧不起网红的一个人，虽然很多人都把我当成网红。但是我做“网红”是属于比较偏正能量，或者说也是一个比较“刚”的人。
我基本把这些分享当作一个休闲的模式来看待，所以我不会在这个途径上去做标题党相关的操作，说白了就是我的分享不会刻意去带任何的商业利益价值。相对来说，我不会去为了某个人或者某些事情去发表意见，或者是提出什么建设性的措施等等，我只会去剖析它的一些真实性。
其次对于我来说，我个人是不太愿意去讲一些我没有经历过的事情。我也很少对一些事件和观点进行评头论足，我分享的故事也基本是我原先经历过的事情或者身边朋友的故事，所以它更多是一种经验的分享。
但是很多活跃在互联网的「头部博主」或者大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的发展，不要被过度渲染的言论所左右。
你瞧，这说着说着就绕进了心理学的范畴，而且和社会学经济学统计学以及其它学科挂上钩了。
基于 Spring Boot + MyBatis Plus + Vue & Element 实现的后台管理系统 + 用户小程序，支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能
项目地址：https://github.com/YunaiV/ruoyi-vue-pro
视频教程：https://doc.iocoder.cn/video/
误导2：玩什么监控，今后都是用大模型来精准定位了
我之前阅读过很多关于大型语言模型的文章，这些文章声称这些模型具备精准的分析和定位能力。很多人，尤其是在运维领域的从业者，将大型语言模型与我们的监控、APM以及AIOps联系起来。
在我之前的一场直播里我与某公司的一位运维总监进行了对话。我们一同讨论了与大型语言模型、运维和AIOps相关的话题。然而，我个人和他都不认同大型语言模型与运维和AIOps有所关联。我坚信这种关联是永远不可能的。
我发现在我们的圈子里，一些技术网红写了一些文章，将大型语言模型和AIOps联系在一起，提出了一堆理论。首先，我想说这个话题本身就不成立。
为什么呢？因为它存在以下几个矛盾点。
首先是成本不匹配。不论是大型语言模型还是小型语言模型，它们的源头是什么？一个模型要进行训练，它的基础是什么？我认为有两个关键因素，一个是基础的数据量，可被训练的数据量；第二个是算力，即运用场景和数据集。
在监控和UPS领域，数据是什么？数据通常是异常和故障。在UPS的运维过程中，我们首先发现问题，再解决。运维场景中有两个关键词，一个是发现，一个是解决。
如何才能发现异常和故障呢？这是一个挑战。有人可能会说，如果CPU或内存超过80%，就是异常。但实际上，运维是与业务相关的，每个系统的架构都不同，没有标准化的流程和规则。
想象一下，如果在一家公司内，系统架构在很长一段时间内不发生变化，并且有大量异常和故障数据用于训练模型，这种场景是否存在？是不存在的。
因此，我要告诉大家的是，虽然AI有用，但它不存在替换。它不仅不可能局部替换，更不可能全面替换。这是不可能的。
其次是运维，尤其是在最终决策方面，无论是算力还是存储，这些都是一次一次血的教训沉淀下来的。决策涉及到业务服务宗旨，是生死攸关的事情。你会发现有很多操作，比如重启。重启在技术上是很简单的，但为什么我们没有使用AI来执行重启呢？因为最终的决策权一定是由人来做的。
对于异常和故障以及决策这些运维动作，在业务看来都是造成阻塞的。
即使在一些特定场景下使用滚动下线和滚动升级，对业务也是有损的，算力下降了。
最后就是性价比太低。如果是依靠AI进行性能化工作，所需的投入相当高，而招聘一个SRE（Site Reliability Engineering）的成本相对较低。当然，我们希望在未来AI有这样的能力，但实际上这在短时间内是难以实现的。
因此，大模型的应用在运维领域存在一些不切实际的问题，远远没有取代人工的可能性。
基于 Spring Cloud Alibaba + Gateway + Nacos + RocketMQ + Vue & Element 实现的后台管理系统 + 用户小程序，支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能
项目地址：https://github.com/YunaiV/yudao-cloud
视频教程：https://doc.iocoder.cn/video/
误导3：ERP已死，中台已凉，低代码称王
去年也有一些技术网红写过一系列类似的文章，谈论「ERP已死、中台已凉、低代码称王」等话题。
我不知道大家是否看过这样的文章，尤其是关于中台凉了的这种文章，感觉「中台」这个概念已经被很多人玩烂了，而且现在你会发现，前几年低代码和无代码都非常火，许多公司或者项目都因此备受瞩目。
不过实际上，我们需要回到问题的本质，即ERP和中台这些东西，到底在解决什么问题？
我个人之前也分享过关于中台的相关文章。这里我也再提及一次，中台主要解决的是企业在增量市场中快速创新的问题。说白了就是企业在搭建系统的过程中害怕大量的重复性造轮子，而中台解决的是这个问题。它将大量相同和同质化的内容下沉，将个性化的内容上浮，实际上是解决快速创新的问题。
但如果你的企业没有遇到快速创新，比如你做的业务非常固化，那你就不需要中台。因为中台适用于需要频繁变化和创新的场景，比如电商。与此同时，中台适用于多条业务线的前提，所以很多公司它其实只有一条业务线，还要跟风在那搭建中台，这就说明，你连中台是什么都没搞清楚！
在我看来，中台必须具备两个特性。第一个是业务线比较多，而且逻辑组合变化快。你要有多条业务线，才有必要讨论中台的话题。第二个是你的公司和团队必须用屁股认可敏捷文化，该上浮的上浮，该下沉的坚决下沉。有的人天天挂在嘴上说敏捷，但在实践中永远不动，不用屁股去认可敏捷文化。这是一个很现实的问题。
比如像我之前在金融公司，当我们做互联网金融时，它追求的就是快，需要业务出来马上上线。在这种情况下，我们会把团队做成一条团队，包括开发、测试、业务和运维，效率一定会高。所以，我觉得中台解决的就是这个问题。
而低代码满足了企业敏捷能力的诉求，其核心价值是帮助企业快速建立敏捷能力。敏捷文化是拍脑袋决定的，但要快起来，你需要敏捷的工具，这就是低代码和无代码的价值。它们能够让你快速变化，比传统的硬代码更加灵活。
相比传统的硬代码，低代码更加灵活，通过简化开发流程，能够快速适应业务需求的变更。这使得企业能够更迅速地上线业务，对于需要频繁迭代的业务来说尤为重要。
总体而言，中台和低代码都是为了让企业更好地适应快速创新的需求。它们在不同的场景下各自发挥优势，为企业提供了更灵活、高效的解决方案。而并不是什么网红鼓吹的这不行了，那个相当行之类的。所以各自业务需要什么，还是要看实际场景和需求来选择。
误导4：上云成本太高，还是自建机房吧
我最后跟大家分享被技术网红误导的趋势，就是“下云”。记住这里是“下云”，不是“上云”。
为什么下云呢，因为上云成本太高了。
关于上云的成本太高，要下云或者自建机房的问题，凡是有提到自建机房好的文章，你会发现他基本就咬准了「上云的成本太高」这一个点去输出。
上云为什么成本高呢？其实主要有以下原因。
第一个是服务器的静默成本转向了动态成本，这个变化是巨大的，基本上是1.5倍到2倍，甚至更大。每家公司情况不同，但是软件成本，从云下切到云上，成本就高了。
大量的改变，比如你的数据库从Oracle迁移到云上，是非常困难的，需要业务切片和拆分，可能要搞5年都搞不定。所以，企业下云确实可以省钱，但这需要具备一定规模的服务器资源和强大的运营团队。
除此之外，其实还有一个最大的问题，那就是和做决策的老板的信仰有关。说到底就是老板的出身和脑回路决定了他怎么看待这个成本。如果老板是财务出身，他一定讲逻辑，讲脑回路，而成本中心的人很难用这样的逻辑去和他沟通。这在金融领域尤其突出，一些老派的金融领导就是这种思维，所以你解决不了这个现状。
当然，除了以上这些因素外，最关键的还是应用是否具备云原生能力。有的人认为上不上云没什么区别，因为上的都是虚拟机，都是容器化，部署都没区别。但实际上，在K8s上部署和在虚拟机上部署是不一样的，一个是在容器上，一个是在操作系统上。所以选择上云时，应用是否具备云原生特性是一个很关键的决定方向。
最后，在我看来，上云还是下云就好比买房和租房的矛盾。上云就像是租房，下云就像是买房。在现实中，租房和买房都有利弊，必须结合自身情况选择上云还是下云，才能走出正道。
欢迎加入我的知识星球，全面提升技术能力。
👉 加入方式，“长按”或“扫描”下方二维码噢：
星球的内容包括：项目实战、面试招聘、源码解析、学习路线。
文章有帮助的话，在看，转发吧。
谢谢支持哟 (*^__^*）
190
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
