AI淘汰的是机械的执行者

本人最初是误打误撞进入了 SRE 这个赛道，但是也从最开始的小白一直到现在对这个领域有了一定的见解，也希望能给一些迷茫的同学分享一些经验吧，全篇大白话通俗易理解1.SRE 岗位是干什么的大多数大厂应届生工作内容主要是：业务运维，会跟业务对接，处理业务相关的问题，处理工单，排障，做预案等，还包含 on call 值班，处理对应负责业务的告警内部平台/工具 自动化开发，资源治理，容量规划，监控告警，CI/CD 等等相关的开发，技术栈主要是 Python/go，部分有可能会做 aiops 相关，目的基本都是提高运维效率故障演练和应急响应，进行故障演练，确保在系统出现问题时能够迅速响应和恢复2.在求职中， SRE和开发有什么区别？招聘投递，后端的岗位量大于 SRE，但是后端的竞争会相当激烈，就个人经验而言，SRE 竞争压力会小很多，而且在大厂里 SRE 的学历要求会低一些面试，SRE 侧重于 Linux 相关（Linux 内核、shell 脚本、开源中间件，虚拟化等），后端开发的话技术栈更侧重于开发语言，还有就是 SRE 算法难度会低于后端开发薪资，对应届生而言，在大厂技术岗里，薪资主要看个人（学历，实习经历，面试表现）定级，大多数人基本都差不多，但是在顶尖那一批人里，后端开发的薪资上限会高一些希望可以给一些同学解疑答惑吧，接受 一对一咨询

感觉今年应该会非常不错的哈哈，加油，新年快乐！

原文链接：HikariLan's Blog 当提到“如何为大模型提供大规模的可用于检索的信息”时，我们第一反应想到的大概率是 RAG 一类的解决方案，但现在我要说，基于文件系统访问（FileSystem Access）的检索方式可能远比使用 RAG 更好。 什么是 RAG？为什么需要 RAG？ **Retrieval-Augmented Generation（检索增强生成，RAG）**是一种可以允许 LLM 从大规模非结构化信息中进行语义检索的技术方案。 我们之所以需要 RAG，是因为大模型内置的知识内容可能不符合我们的需要，例如这些内容可能已经过时（因为用于大模型训练的语料库并不会随着使用者...

为什么标题起这个，是因为高中的时候有个好朋友就喜欢说这句话，于我而言，我并没有这句话写的那么积极向上，或者阳光忘了在哪里还看过另一句话，说如果生活把你的门关上，那你就再打开，因为这是门，门就是这样用的其实写代码这行挺没意思的，特别是现在，同事给我说，10年左右的时候，大家都以996为荣，如果一个公司不说自己996，反而会被面试者看不起，因为当年大家真的是抱着改变世界的想法去写代码的，那么改变世界速度当然是越快越好，当年给钱自然也是很慷慨现在嘛，这个世界已经和十几年前很不一样了，互联网软件再怎么发展，感觉也不如让大家早下班几个小时来的实在我入职了也有半年了，其实也才就半年，这里就和我刚入职的时候...