Kun Chen 四篇长文解析 AI 时代软件业的需求、价值与职业走向：软件没有死，而是正要起飞！

"软件已死"的说法混淆了三件事：把软件的价格等同于软件市场的规模，把软件等同于代码，把软件工程师等同于写代码的人。Kun Chen 的观点是：AI 会让单个软件变便宜，但整体市场会更大；有价值的软件远不止代码；工程师这个职业的本质是"用软件解决问题"，需求反而在增长。

Part 1 · 杰文斯悖论：便宜带来更大的市场
蒸汽机变得更省煤以后，煤的总消耗量反而上升，因为更多场景用得起蒸汽机了。同理，AI 大幅降低了做软件的门槛，单个软件的价格会下降（Kun Chen 设想：Adobe 全家桶变成 10 美元买断，应用商店变成 5 美元一个月随便用），但用软件的人和做软件的人都会大幅增加，软件经济的总盘子会变大。

Part 2 · 技术普及不等于替代专业服务
Kun Chen 举了四个例子：微波炉普及后餐厅照样增长，家用咖啡机和咖啡店同时增长，人人有手机摄像头后职业摄影师的就业基本稳定，TikTok 爆发后影视业也没有被冲垮。原因是专业服务卖的不只是功能，还有服务体验、社交、仪式感和情感价值。大众拿到新工具后，通常会去做新的东西，而不是替代原有的专业生意。读者可以检查一下自己用得最多的 App（X、微信、YouTube 等），看看哪一个值得自己用 AI 重写？AI 真正的价值在于做出以前不存在的东西，而不是"你做了一个看板工具，我也做了一个"。

Part 3 · 软件不等于代码
有价值的软件往往是：
· 网络：克隆一个 X 或 Uber 没有意义，因为你在乎的人不在上面；
· 基础设施的冰山一角：代码能生成，但没法生成 Google 的数据中心；
· 商业模式：比如 Tinder，谁付费、为哪些功能付、付多少，这个平衡是长期摸索出来的；
· 合规：企业买 Salesforce、Workday，买的是把数据存储、保留期限、各国法规的风险交给别人去承担；
· 商务谈判：比如 Spotify 背后的版权授权和分成协议。

只有一小堆代码的简单工具（比如健身记录 App）确实容易被复制，但这类产品本来就很难支撑一门可持续的生意，也从来不是软件行业的主体。

Part 4 · 软件工程师这个职业会消失吗？
Kun Chen 用母亲做会计的经历打比方：从算盘到计算器、电脑，再到打电话沟通，工具一直在变，但"帮企业做出正确的财务决策"这个本质没有变，她最后以会计团队负责人的身份退休。同理：
· 如果把这份工作理解为"别人让我写什么我就写什么"，这样的岗位已经没有了；
· 如果理解为"我能写出很好的代码"，作者估计 1 到 3 年内也会失去价值；
· 需求在增长的是能够精准、主动、借助杠杆解决问题的工程师。作者附了图，说明美国 SWE 岗位的招聘数量在增长，增量主要来自资深岗位、AI 相关岗位和 FDE（前线部署工程师）。当竞争对手用的是同样的 AI 时，决定胜负的是人。

“软件正在起飞”系列第 4 部分

（原文正文仅有这一句标题，没有更多章节或内容可供整理。）

最近的一些讨论让我意识到，很多说「软件已死」的人，其实想的是「软件工程作为一种职业」这件事。

换句话说，他们讨论的不是软件本身，而是软件开发这份工作。这两者并不是一回事。软件——作为工具、作为产品、作为基础设施——并没有消失，它只是被重新分配、重新组合，并且越来越多地被非专业开发者、AI 代理和自动化流程生产出来。

真正受到冲击的，是「以写代码为职业」这一默认路径：入门级岗位减少、工作内容向更高层的设计与审核迁移、企业对「软件工程师」这一角色的定义发生变化。

这并不意味着软件工程专业消亡，而是意味着它的形态在改变：更少的重复性编码，更多的系统设计、需求判断、质量把关与跨领域协作。

所以，与其说「软件已死」，不如说「只靠写代码就能立足的时代正在结束」。软件仍然无处不在，只是生产它的方式和从事它的人，正在被重新定义。

软件工程……死了吗？

所以……软件工程死了吗？

这是最近在开发者圈子里被反复提起的一个问题。随着 AI 编程工具的快速进化，从自动补全到能够独立完成多文件任务的智能体（agent），越来越多的人开始怀疑：传统意义上的软件工程，还有未来吗？

它到底在问什么

这个问题表面上是在问一个职业是否消亡，实际上包含了好几层不同的焦虑：

• 写代码这件事本身：如果 AI 能根据自然语言直接生成可用代码，那还需要人一行一行地敲吗？
• 工程能力的位置：需求拆解、架构设计、测试、部署、维护，这些环节里哪些会被自动化，哪些仍然依赖人的判断？
• 职业路径：新人还要不要从基础编码练起？资深工程师的价值又体现在哪里？

为什么现在会被提出来

这并不是第一次有人预言程序员要消失。但这一轮讨论的不同之处在于，工具的能力边界确实在快速外扩：

1. 代码生成从「补全一行」发展到「完成一个函数、一个模块」。
2. 智能体可以读取仓库、修改多个文件、运行测试并根据失败结果迭代。
3. 自然语言正在成为一种可行的「编程接口」，降低了把想法变成可运行程序的门槛。

%%IMG1%%

但软件工程不只是写代码

如果把软件工程等同于「把需求翻译成代码」，那它确实正在被大幅压缩。但真实的软件工程包含的内容要宽得多：

• 搞清楚到底要解决什么问题，以及在各种约束下做取舍；
• 设计能够演进的系统结构，而不是只让当前测试通过；
• 保证正确性、安全性和可维护性；
• 在出问题时定位根因，并对生产环境负责；
• 与团队协作，让代码和决策能够被他人理解和接手。

这些工作里，很多恰恰是 AI 目前最不擅长的部分：它们依赖上下文、责任归属和长期判断，而不是单次的文本生成。

支持状态（Support Status）

关于「AI 能在多大程度上替代工程工作」，目前的现实状态可以这样概括：

换句话说，工具在变强，但「对结果负责」这件事仍然落在人身上。

快速开始（Quick Start）

如果你想亲自判断这件事，最直接的方式是上手试用，而不是看别人的结论：

1. 选一个你熟悉的小型仓库，先用补全类工具，观察它对你代码风格的理解程度。
2. 再给它一个明确的、范围可控的任务，例如「为某个函数补充测试并让测试通过」。
3. 记录它需要多少次人工纠正，以及纠正的成本落在哪里。
4. 把任务范围逐步放大，直到你感到明显不可靠为止——那条边界就是当前的现实。

%%IMG2%%

技术栈（Tech Stack）

围绕这类工具的典型技术栈大致包括：

• 模型层：通用大语言模型，以及针对代码微调的专用模型；
• 上下文层：代码检索、仓库索引、文件与符号定位；
• 执行层：沙箱、终端、测试运行器，让智能体能够真正验证结果；
• 协作层：IDE 插件、代码评审集成、版本控制工作流。

这些环节共同决定了一个工具「看起来能用」和「真的能用」之间的差距。

结论

软件工程没有死。死掉的只是「软件工程等于熟练敲代码」这种过于狭窄的理解。

更准确的看法是：实现成本在下降，而对判断力的需求在上升。当写出一版代码变得越来越便宜，决定「该写什么、不该写什么、如何验证它是对的」就变得越来越重要。这依然是软件工程，只是重心发生了移动。

小时候，我妈妈是一名会计。晚上我写作业的时候，总能听到她拨算盘的声音。那声音非常大，也很吵。

多年来，拨算盘的声音变成了敲计算器的声音，接着又变成了敲键盘的声音，最终变成了打电话的声音。她几年前才退休，当时担任会计团队总监。

如果你还以为会计这一行就是「拨算盘」，那它早就消亡了。但如果你明白会计的工作实际上是「帮助企业做出正确的财务决策」，你就会意识到它永远不会过时。

软件工程是否已经死了，几乎完全取决于你如何理解这个职业本身。

如果你的定义是“我写别人让我写的代码”，没错，那种职业已经死了。

如果这条推文说的是“我写代码写得非常好”这类内容，那它还不算完全过时，但我推测它会在未来 1 到 3 年内过时。我会在下面的推文串里链接另一篇帖子，在那里我解释了原因。

哪种类型的工程师需求正在增长？

%%IMG1%%

原文标题：So what's the type of engineer that's seeing growing demand?

正文内容尚未提供完整章节。请补充原文 Markdown 的其余部分（包含 Support Status / Quick Start / Tech Stack 等章节），我才能按你的要求完整整理为简体中文 Markdown。

图 1 显示，美国软件工程师（SWE）的整体招聘岗位数量呈增长态势。而这一切恰恰发生在编码智能体（coding agent）取得最疯狂进展与普及的一年里，这本身就说明了很多问题。

图 2 显示，大部分增长来自高级岗位或与 AI 相关的岗位。下文将说明原因。

图 3 展示了 FDE（Forward Deployed Engineer，前置部署工程师）的兴起

对软件工程师日益增长的需求，指向的是那些具备以高精度、主动性和杠杆效应解决问题之能力的人——这些特质早在人工智能出现之前就一直是人们所渴求的，而且至今没有任何消退的迹象。

换个角度想——当两家竞争公司都能用上同样的 AI 时，谁会赢？决定胜负的将是他们的人，而他们会尽可能多地招揽这样的人。

软件工程这一职业，从来就不在于编写打孔卡片、编写汇编语言或编写 C 语言。它也从来就不在于使用 vim、emacs 或 visual studio。代码、工具和工作内容，一直都在不停地变化。

这个职业一直以来的核心都是「用软件解决问题」。如今有更多问题变得可以解决，每个人都获得了相当惊人的杠杆效应——从来没有比现在更好的时机。