Skip to content

四火的唠叨

一个纯正程序员的啰嗦

Menu
  • 所有文章
  • About Me
  • 关于四火
  • 旅行映像
  • 独立游戏
  • 资源链接
Menu

AI 到底会怎样取代我们的工作

Posted on 02/15/202602/15/2026 by 四火

这是一个很多人都讨论的大问题。

我一直在思考,也一直没有一个足够确信的答案。去年这个时候,写了一点体会,如今的体会更深了。但是我觉得,我可以把凌乱的内容整理出来。

一些事件

在一两周前,Google Genie 3 出来的时候,因为 demo 展示了它可以很容易地生成一整个可以游玩的世界,游戏引擎 Unity 的投资者就被吓坏了,疯狂抛售,一天就跌了二、三成。Unity 的 CEO 站出来喊话,核心观点还是——AI 再强大它也是概率性的,而 Unity 程序员的工作,却是追求确定性的。因此 AI 应该是软件开发的加速器,帮助提升创作的真实性和速度,而非替代者。

朋友推荐我这篇 《The Eternal Return of Abstraction: Why Programming Was Never About Code》,这篇读起来有些费劲,不过它的核心思想大概是,编程一直以来的本质是什么?它的本质是把人的意图转化为机器可以理解的形式。它的意义比代码高多了,因为代码只不过是表达这个意图的一种形式而已,还有什么形式?有了 AI,自然语言就可以是这个新的形式。大语言模型的一个功绩在于提升了抽象级别,以前我们必须要准确地使用编程语法来告诉机器应该怎么做,现在不是了,自然语言就是基于概率的描述,这个不确定性的问题是从根上就有的。

今年初的 SaaS 软件板块抛售潮,伴随着一系列事件,被称为 SaaSpocalypse,所谓的 SaaS 末日。它缘起于市场突然意识到 AI 不再仅仅是程序员的工具,而是可能称为自主运行整个 SaaS 程序编写,并完成复杂流程的 “数字员工”。这其中包括 Anthropic 发布的 Claude Cowork,它可以直接操作软件界面,这被认为很多 SaaS 的按人头付费的模式崩塌;Klarna 公开宣布,决定停止使用 Salesforce 和 Workday 这样的 SaaS 服务,因为他们启用了 AI,这让市场怀疑起 SaaS 的护城河硬度;再有早些时候的 Chegg,使用率锐减,主要是 AI 都可以直接、免费地获取答案了,学生们不再需要它了;还有 Adobe 因为 Sora 的发布而受到质疑,虽然专业用户的门槛不好说,但是大众用户的视频和图像生成似乎已经可以通过说几句话就完成了。

如果看看 SaaS 公司的财报,似乎是另一番光景。比如 ServiceNow,Q4 的营收增长超过了 20%。似乎,能看得到的事情是,面对科技行业的大幅裁员,更少的程序员可以做更多的事情,这也是市场担心的一个主要由来。那么反过来想,如果是按照按人头卖的形式,显然 SaaS 的收入会大幅下降。不过,如果定价按照解决的问题、feature 使用的次数和使用 AI 能力的 token 来收钱,这也许就完全不是那么回事了。我们目前能看到一些收费方式的变化(也看到了一些抵触,比如很多企业不喜欢这样的新方式,因为缺乏财务上的可预测性),但是市场需要看到更多。

对 SaaS 行业的影响

好,现在冷静下来想想,到底哪些 SaaS 商业模式会出局?

首先想到的,知识库似乎会出局,因为 AI 可以非常方便地给出结论;其次,是文字组织和润色类工具,因为 AI 的文字能力比一般人都出色;再次,就是一些数据、声音、视频分析类的工具,这种把数据可视化,让人更容易从中找规律的软件,AI 也基本可以比较容易地代替。如果尝试泛化一些,似乎容易出局的软件模式是:需要的答案已经有了,只是要把它们从大量的内容中找出来,这种为了寻找答案而使用的专业工具,可能会被 AI 这种能够接受人类语言的特性所替代。换言之,如果提供的服务,没有硬核的、实质上的不可替代性,只有 “便捷性”,那就可能被踢出局。

那么,哪些 SaaS 商业模式很难被踢出局?

第一种,大概是拥有不可替代的数据。这样的 SaaS 软件拥有私有的、历史的和被视作宝贵资源的数据,而不是公开的、简单的和比较容易获得的数据。前面说的 Chegg 拥有的其实就是公开的数据,比如所谓的习题,还有像是 LeetCode 题解这样的也差不多;而 ServiceNow、Salesforce,以及 Jira 等等,这些企业专有的数据,让你没有办法直接使用一个公有的 AI 服务来直接替代掉。

第二种,就是高度复杂化和专业性的,AI 可以充当一个外行,但是没有办法触及最核心的精确性的。这包括某些媒体内容的制作,AI 可以提供丰富的素材,动画的画师可以使用 AI,但是主干必须要手动主导和干预,AI 可能能够生成关键帧之间的连接。

第三种,大概就是脱离软件的虚拟世界,和真实世界有着紧密的连接。比方说,对于很多 IoT 应用,通过各种各样的特定传感器来获知状态并连接。这些硬件的 “眼睛”、“耳朵” 和 “嘴” 需要特定的驱动程序,或是说,特定的软件才能工作。

还有一些 SaaS 应用,居于二者之间——可能能够暂时活一段时间,但是长远看,护城河也会被侵蚀。

第一种,复杂流程已经根植入企业人事流程的。这种只是代价高,但并非有那么强的不可替代性。

第二种,已经发展出专业技能的。有些学校里面都会教。比如 Unity 的技能和 Adobe 的技能等等。

第三种,那就是生态。比如 Jira 就有插件生态等等,生态意味着有很多为了方便提供某些特性而做出的定制化。

对软件工程师的影响

在说软件工程师之前,先跳出来想一下,哪些行业更容易被 AI 革命?

初级(简单劳动)的白领,是最容易被革命的。“简单劳动” 很容易理解,但是 “白领” 被淘汰是 AI 时代的特殊之处。如果说工业革命初期受到最大影响的是 “蓝领”,那 AI 革命初期受到最大影响的就是 “白领” 了。这一类初级白领,就是看似坐在电脑前工作,但是工作却是一些复制粘贴、流程安排和文字组织等等简单的活动,比方说翻译、秘书等等。

相应地,我记得李开复的《AI·未来》书上也讲到的,需要和真实世界的人交互的行业,影响可能是最小的。比如养老护理,体育竞技等等。还有一些行业,是蓝领,但是目前的 AI 和硬件设备的结合还要慢一步,比如汽车修理等等——AI 又没有手,因此这样的行业暂时也算安全,只不过随着机器人等强烈依赖硬件行业跟上来,这些也依然有被淘汰的风险。

好,接着再来看软件工程师。软件工程师,算是白领,但是算是 “初级” 白领吗?

其实,大家似乎比较容易能够达成共识的是,单纯编码,就是一个很容易就被 AI 淘汰的工种了。想起来其实也很容易理解,编码,说到底和英语或者任何其他人类语言的 “翻译” 到底有多大区别?可能区别也不过是,交流的对象从活生生的人变成了冷冰冰的机器,还是需要语义、语法,还是需要语言逻辑。如果从这样的角度来看,似乎 “编码员”(coder)可替代性真的太高了。

再深入一步,是用的更为广泛的 “程序员”(programmer)。这意味着,再代码的基础上,程序员设计逻辑、算法,从而把一个具体问题实现为程序代码。程序员也会关心程序员生命周期的其他活动,比如 bug 修改、feature 添加等等,但是核心依然是代码。程序员似乎比编码员好一点,但是 AI 的可替代性依然很高。

再来,就是软件工程师。我认为软件工程师是一群能够利用一定系统和规范的方法,来把软件工程化的专业人员。这就意味着他们解决的问题是实际世界的问题,需要把问题抽象成为软件可解的问题,以工程的方式实现,并且维护整个软件生命周期。

渐渐地,整个行业会有更加成熟的方法来知道 AI 实现需求,但是软件工程师依然会需要 “亲自阅卷”,他们也许会大大减少亲自实现的代码量,但会花更多时间评审 AI 的代码实现,寻找其中的问题,评估其中的风险等等。在整个软件工程流程上,也需要分析和思考用户的需求,敲定大体的方案,把大块复杂的任务拆分成小块的任务,交给 AI 来实现等等。总而言之,AI 成为了助手,或者是团队中的 “初级程序员”。传统观念上软件工程师的核心能力有了些许区别,比如说,如何提问 AI 的表述能力会被放到更加重要的位置。

这么看来,“初级软件工程师” 似乎非常容易被替代。比如说,初级软件工程师,经常会拿到设计方案,然后去实现。这在如今的互联网大厂是常态,大的 feature 或者系统,不太会完全丢给一个没什么经验的新兵来实现,这样的角色确实是比较容易被 AI 替代的。可是,成长是要有过程的,如果这个阶段不给足时间,那么初级软件工程师就不能成长为高级软件工程师,如果 AI 替代了这个阶段,势必会造成人才的断层。从长远来看,这才是让我最为忧心的。

如果我们仔细思考 AI 的擅长与不擅长,AI 目前还是有很大的局限性的。比方说,AI 还是更适合做具体的、明确的工作,对于一个复杂系统,对于用户的痛点感知,还是需要软件工程师开动大脑来分析思考,基本上这种活动都需要比较长的时间和比较丰富的积累。再有一个,AI 现在的两大问题,一个是 hallucination,就是 “一本正经说瞎话”;另一个是 sycophancy,就是在一些决策上面没有啥 backbone,很容易倒向谄媚的一侧。我可以想象,几年以后,AI 做更多的执行和辅助,然后把信息提炼、分析以后交给软件工程师,而软件工程师会做更多的思考和决策,并为结果负责。

我们还在这个时代变革的开头,这些观念只能说是目前的思考,两三年之后,它们还有效吗,我可以说完全没有什么信心。不过我确定的是,我们不能回避,要拥抱这个时代;既然选择了这一行,就要尽量保持开发,去倾听和接触新鲜事物,持续学习,那种抱着自认为 “经得起考验” 的过往成功的经验不放的自称 “老派” 的家伙,可能会吃大亏。

文章未经特殊标明皆为本人原创,未经许可不得用于任何商业用途,转载请保持完整性并注明来源链接 《四火的唠叨》

×Scan to share with WeChat

你可能也喜欢看:

  1. 初涉 ML Workflow 系统:Kubeflow Pipelines、Flyte 和 Metaflow
  2. 程序员看法上的几个典型错误
  3. 程序员学英语
  4. 编程的未来
  5. 进阶过程:程序员做项目的独立性

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

订阅·联系

四火,啰嗦的程序员一枚,现居西雅图

AI Amazon Google Groovy Hadoop Haskell Java JavaScript LeetCode Oracle Python Spark 互联网 华为 历史 同步 团队 图解笔记 基础设施 工作 工作流 工具 工程师 应用系统 异步 微博 思考 技术 投资 数据库 时间 曼联 测试 生活 程序员 管理 系统设计 缓存 编码 英语 西雅图 设计 评审 问题 面试

分类

  • Algorithm and Data Structure (30)
  • Concurrency and Asynchronization (6)
  • System Architecture and Design (43)
  • Distributed System (18)
  • Tools Frameworks and Libs (13)
  • Storage and Data Access (8)
  • Front-end Development (33)
  • Programming Languages and Paradigms (55)
  • Testing and Quality Assurance (4)
  • Network and Communication (6)
  • Authentication and Authorization (7)
  • Automation and Operation Excellence (13)
  • Machine Learning and Artificial Intelligence (7)
  • Product Design (7)
  • Hiring and Interviews (14)
  • Project and Team Management (14)
  • Engineering Culture (17)
  • Critical Thinking (25)
  • Career Growth (57)
  • Life Experience and Thoughts (42)
  • Business and Investment (8)

推荐文章

  • 聊一聊分布式系统中的时间
  • 谈谈分布式锁
  • 常见分布式系统设计图解(汇总)
  • 系统设计中的快速估算技巧
  • 从链表存在环的问题说起
  • 技术面试中,什么样的问题才是好问题?
  • 从物理时钟到逻辑时钟
  • 近期面试观摩的一些思考
  • RSA 背后的算法
  • 谈谈 Ops(汇总 + 最终篇):工具和实践
  • 不要让业务牵着鼻子走
  • 倔强的程序员
  • 谈谈微信的信息流
  • 评审的艺术——谈谈现实中的代码评审
  • Blog 安全问题小记
  • 求第 K 个数的问题
  • 一些前端框架的比较(下)——Ember.js 和 React
  • 一些前端框架的比较(上)——GWT、AngularJS 和 Backbone.js
  • 工作流系统的设计
  • Spark 的性能调优
  • “残酷” 的事实
  • 七年工作,几个故事
  • 从 Java 和 JavaScript 来学习 Haskell 和 Groovy(汇总)
  • 一道随机数题目的求解
  • 层次
  • Dynamo 的实现技术和去中心化
  • 也谈谈全栈工程师
  • 多重继承的演变
  • 编程范型:工具的选择
  • GWT 初体验
  • java.util.concurrent 并发包诸类概览
  • 从 DCL 的对象安全发布谈起
  • 不同团队的困惑
  • 不适合 Hadoop 解决的问题
  • 留心那些潜在的系统设计问题
  • 再谈大楼扔鸡蛋的问题
  • 几种华丽无比的开发方式
  • 我眼中的工程师文化
  • 观点的碰撞
  • 谈谈盗版软件问题
  • 对几个软件开发传统观点的质疑和反驳
  • MVC 框架的映射和解耦
  • 编程的未来
  • DAO 的演进
  • 致那些自嘲码农的苦逼程序员
  • Java 多线程发展简史
  • 珍爱生命,远离微博
  • 网站性能优化的三重境界
  • OSCache 框架源码解析
  • “ 你不适合做程序员”
  • 画圆画方的故事

近期评论

  • Decisivem on 聊聊商业模式——阿里巴巴
  • 四火 on 聊聊商业模式——Atlassian
  • bob on 聊聊商业模式——Atlassian
  • Battlele on 回国感悟
  • Anonymous on 聊聊商业模式——拼多多
  • Battlele on 聊聊商业模式——拼多多
  • Anonymous on 聊聊商业模式——拼多多
  • Anonymous on 所有文章
  • Anonymous on 倔强的程序员
  • rocky on 关于时间管理的一点新的感悟
© 2026 四火的唠叨 | Powered by Minimalist Blog WordPress Theme