机器之心编辑部

AI 正在让职场打工人面临痛苦的转型。当我们聚焦一个个体的故事时，这种痛苦变得非常具象。

最近，一篇题为《LLM 正在损害我的软件工程职业生涯，我不知道该怎么办》的帖子在 Hacker News 上引发关注。

作者是一位拥有 10 年经验的软件工程师。他的职业路径看起来相当清晰：从前端起步，转型后端，深耕金融与支付领域，积累了 PCI 合规、双重记账、幂等性防重复扣款、支付生命周期管理等一整套专业知识。他曾笃定地认为，这些靠「真金白银」的项目经验换来的领域积累，是他在行业里安身立命的根本。

然而，他却用「三根支柱相继倒塌」描述了自己这两年的职业体验。

第一根支柱：领域专业知识

去年，他被一家金融领域的公司录用。此前他就职的公司虽然运营或产品中也涉及支付和金融模块，但并非纯粹以金融为核心的企业。

这家公司全面拥抱人工智能，因此他从入职第一天起就获得了 ChatGPT 和 Claude 企业版账户，并被鼓励在调研、探索甚至编码中使用这些工具。不过他被提醒：每一行进入生产环境的代码仍需由他自己审核并负责。

他接手的首批项目之一，是重构一团糟的旧版在线支付系统。公司看中他以往构建此类系统的经验，因而将这项任务交给了他，并对他委以信任。

与他之前工作过的其他公司不同，这家公司希望他编写的「设计文档」既能让工程师看懂，也能让产品经理理解 —— 所以文档不能是过于技术性的 deep dive，而应更像架构视图。他在极少借助 AI 的情况下完成了第一份文档 —— 当时他甚至称大语言模型为「随机鹦鹉」（如今他已不再持这种观点）—— 并交付了成果。

他珍视自己的知识，认为没有哪个大语言模型能取代它。

随后他的经理找他谈话：「虽然你交付代码的速度不错，但写这些设计文档花的时间太长了。你用 AI 了吗？你应该多用 AI。」

他心里想：「这绝对行不通。」但还是同意了。那时的模型不如现在强大，但确实显著提升了他的写作效率，甚至辅助了决策。

接着他开始意识到：自己多年积累的所有知识 —— 不同实现方案之间的权衡、收单机制如何运作、如何构建幂等性以防止重复扣款 —— 一切都在变得毫无价值。尽管模型仍需要一些引导，但它们已经能自行串联起设计这类系统的要点，而这恰恰是最难的部分，通常需要多年实战经验才能在脑中形成。这是他遭遇的第一次冲击。

但他转念一想：模型能做到这一点，是因为网上有大量解释这类系统原理的文章，以及所有技术文档，还有大量博客文章讲解如何将技术工具应用到业务领域。对人来说，学会这一切需要很长时间，但这些东西本就是训练数据，模型自然可以习得。

模型永远无法擅长、人类将大放异彩的领域是 —— debug！他在生产环境中调试竞态条件和分布式系统方面积累了丰富的经验。这曾是他长期保有饭碗的保障。

第二根支柱：debug 与分布式系统

在大语言模型开始擅长撰写文档、辅助规划具体实现之后，它们又变得擅长编码。这始于 2025 年下半年的 Claude Code 热潮，接着 Codex 等工具相继出现。虽然此前他每天都用大语言模型写单元测试，但还不信任它们能直接完成完整的实现。

下一步自然是将更多 AI 引入编码过程。说实话，他喜欢这样。他既喜欢编码，也喜欢把产品推上线、看到用户满意，所以只是用一种自己喜欢的事替换了另一种，挺公平的。

大语言模型越来越擅长编码，但仍然无法 debug（无论是模型还是人）留下的混乱局面，所以他仍然有一个比「操控机器人」更大的角色 —— 这是他保住工作的门票。

一切似乎还不错。

接着，MCP、智能体工作流以及 Claude 4.5 出现了，天开始塌了。

说实话，Claude 4.5 并没有那么好。给定堆栈跟踪和一些上下文（大多数情况下，开启 Sentry MCP 并提供一个 Sentry 链接就够了），它大约能解决 60% 的缺陷。有时它会给出听起来合理但完全错误的解决方案。

然而这一次，他不再怀疑机器的能力。他看到过去往往需要一整天专职 debug 才能解决的缺陷，被 Claude Code 一次性解决。当然，还不是全部，但趋势已经很明显。

然后 4.6、4.7、GPT 5.5、Opus 4.8 以及 DataDog MCP 相继问世…… 现在他拥有的命令行工具可以一次性解决跨分布式系统的缺陷，那些他过去无法解决的缺陷，那些需要整整两天专职调试的缺陷。那些缺乏分布式可观测性的跨系统缺陷。如今 90% 的缺陷都能一次性解决，包括诡异的竞态条件、意外的边缘情况、第三方集成问题、未文档化的 API 边界情形 —— 一切。他几乎不需要介入。

当然，他依然有工作可做，因为总得有人审核代码、操控机器人。但他现在只不过是个普通到随时可替换的工程师。他的任何领域专长，另一位操控大语言模型的高级工程师都能轻易匹敌。他感觉，他所有的金融和支付领域知识、所有通过汗水和泪水换来的调试直觉和分布式系统知识，现在都可以通过提示词获得。

我们曾被告知：通才和专才永远各有其位。但现在市场正把每个人都塑造成通才。这本身并非坏事 —— 直到你审视供需的经济学：如果人人都成了通才，而没有与之匹配的需求，通才的价格就会下跌。而我们都清楚，需求正在枯竭。

第三根支柱，尚未消蚀的那根：代码质量与架构

不过，他还有一根支柱屹立不倒：代码质量与软件架构 —— 也就是现在被简称为「品味」的东西。

在他的职业生涯中，他一直喜欢重构，珍视高质量的代码，并在迭代中争取时间做这件事。DDD、六边形架构、整洁架构 —— 这些流行词他都很熟悉。他喜欢这个话题，喜欢讨论不同的权衡和塑造代码库的思路。他真的很喜欢。

这是最后屹立的支柱。只不过，现在没人在乎了。

智能体在保持代码库整洁方面表现极差。如果你不加以引导，它们很快就会碰到循环依赖问题。它们会重复代码、添加无关的注释、混用纯函数和副作用、无视 SOLID 原则。

这本来应该能让人类保住工作，然而这项技能如今已被简化为「品味」一词。但不仅仅是重新命名 —— 整个行业正在走向一个代码组织不那么重要的世界。

没错，人类应该引导智能体，防止出现带有循环依赖图的意大利面条式代码库。没人想要那种碰一下就出问题的 F 级代码库。但 C 级或 D 级呢？现在完全可以接受。不再需要 A 级或 B 级的代码库了，因为代码是为大语言模型写的，而不是给人读的。

他不想争论这本身是好是坏。如果源代码现在是为机器而非人类阅读而写的，那么以机器为目标也许也没问题。

但这又是他专业技能中一根正在消蚀的支柱。他在这方面积累的大量知识不再那么有价值。他花费的所有时间 —— 读书、做实战练习、与其他工程师讨论、编写架构决策记录 —— 都在变得无用。

接下来该怎么办？

作者表示，他依然有工作，并且认为自己可预见的未来（至少在这家公司）仍会受雇，但他不知道长期该如何看待。

他花了十年（如果算上非职业经验则更久）去精通那些价值越来越低的事情。他最后的专业支柱如今被简化为「品味」，而且很可能也撑不了多久。

而且他知道，有这种处境的不只是他。大约八个月前，他现在的公司进行了一轮裁员（据称与 AI 无关）。一些出色的前同事被裁，至今仍在找工作。他们大多面临同样的问题：他们的领域专长已不足以让他们脱颖而出。

公司现在又开始招聘少量岗位，领域熟悉度已不再是强有力的区分因素。过去他们会招聘「软件工程师 - 某领域」。现在只写「软件工程师」，团队分配在录用之后才进行。

当然，这对那些从未有机会深入特定领域、现在获得更好就业机会的优秀工程师来说是好事，但想到那些穷尽一生积累领域知识的其他优秀工程师如今不得不在同一条赛道上竞争，也不免令人感伤。

作者认为，要想长期保住饭碗，现在看来唯一的出路是把他的领域专长转向大语言模型不那么容易掌握的方向。但还剩下什么呢？

他曾考虑重返校园，学习数学、统计学、高级机器学习，然后申请前沿实验室的研究岗位。然而他的国家没有前沿实验室，少数几个存在的实验室也收到海量申请，而且他因家庭原因难以移居他国。等到他有条件完成这一跳跃时，RSI 可能已经让研究员变得多余。

最后他写了一句调侃的话：「或许应该考虑把木工爱好变成职业……」

回应争议

这篇博客发布之后在社交媒体上被大规模传播。作者挑出了一些代表性评论进行回复。

关于「领域知识真的没用了吗？比如本地税务法规」

有评论指出：大语言模型在处理本地税务法规、会计流程细节、分类账实现等方面经常出错，怎么可能取代人类的领域知识？

作者承认自己原文说得不够清楚。LLM 确实无法自动搞定所有本地税法或极其细碎的规则 —— 但这些通常由法务团队处理（而法务团队也在大量使用 LLM 自动化例行工作）。问题在于，他多年积累的领域知识（虽然比法务团队浅得多）如今用 ChatGPT Pro/Extended Thinking 就能直接提示出来。这才是让他沮丧的地方 —— 他曾经以为，在一个「只会写代码」的程序员世界里，拥有这些知识能让他脱颖而出，但现实已不是这样。

至于 Agent 以前不擅长这类细节，他承认。但随着新模型、面向 Agent 的文档、以及在代码库根目录放 AGENT.md 强制要求 Agent 先读文档再写代码，情况已经改变。他越来越不需要去问那些在公司待得更久、了解细节的同事了。现在他完成工作所需的人类输入大大减少 —— 停下来想想，这很可怕。

关于「你们公司经理让你用 AI 加速设计文档，这也太不靠谱了」

有评论认为，一家金融科技公司的管理者竟然建议用 AI 加快写设计文档，说明这家公司对待金钱业务太草率。

作者同意这不靠谱，但他有自己的应对方法：

文档写得笼统：设计文档中只放状态机等相对通用的内容，给自己留出仔细实现的空间。AI 到来（以及裁员）之后，所有人都淹没在长篇文档和 PR 审查中，审查者远没有以前挑剔了。

在项目板上做文章：他总是会加一些端到端测试的任务，借机发现缺陷，在功能发布前提交缺陷 / 改进单。这为他争取了谨慎审查实现的时间。另外，他会把敏感的核心实现拆分成比平时更多的任务卡片，以便从容实现和审查。

他喜欢这样做吗？当然不。但他有什么选择呢？从他认识的人反馈来看，他的公司还不算「氛围编程」的最极端案例，跳槽去一个可能更糟的环境并不划算。至少在这里，他知道如何控制相关方的焦虑（他的审慎和仔细为他赢得了声誉），而且公司没有强迫他全速进入「氛围编程」。

关于「你要学会冲浪，每次技术浪潮都一样」

有评论说：你以前冲过网站 /webapp 的浪潮，现在不过是新浪潮而已，学新本事，驾驭工具，游戏没变。

作者表示同意，他现在正是这么做的。他是公司里不断改进 Agent 工具链的工程师之一，用不同模型做对抗性代码审查，保持自己的技能和提示词工具库。他实际上已经成了所谓的「AI 原生工程师」（虽然他讨厌这个词）。

但他更担心的是未来。

如果模型及其工具链在未来几年继续以同样的速度变强，那么软件工程这个职业将被彻底商品化。有人会提起杰文斯悖论（效率提升导致需求增加），但他不同意。软件需求一定有上限。

他以文案写作（copywriting）为例。这个职业曾需要多年修炼，收入也不错。随着电商和广告技术带来的需求高峰过后，市场逐渐饱和，而 LLM 直接摧毁了绝大多数从业者的工作。原因很简单：大部分需求来自小公司，它们用 ChatGPT 生成的文案就足够了。少数公司还会雇人做提示、审核和发送，但需求不是无限的，不可能所有人都找到这样的工作。一个文案现在能干过去十个人的活，但需求总量固定。需求不会因为你供给多了十倍就变成十倍。

当然，顶尖的 1% 文案仍有工作，但其余 99% 在为残羹剩饭而战。用户体验写作曾是不错的职业，现在他认识的从业者都被裁了，甚至大公司也裁掉了他们 —— 你直接提示 ChatGPT 生成界面文案，90% 的情况下没问题，所以公司没有必要养十个人，裁掉九个留一个就够了。

如果模型继续沿着同一方向改进，软件工程师都将走向同样的命运。会有人被雇来操控 Agent，但他们将是可替代的、廉价的（又是供需规律）。这正是他在文章中强调的。而且这不只是软件行业的事 —— 实验室的低垂果实是软件，但他们接下来会瞄准金融、生物、法律、营销，所有知识工作。这已是公开的目标。

关于「这跟当年 OOP 浪潮没什么不同」

有评论说，90 年代和 00 年代也有「面向对象编程（OOP）改变一切」的浪潮，最后不也过去了？

他指出：OOP 没有让知识变得可提示（promptable）。OOP 没有显示出快速、复合增长、朝着取代横跨多个领域（不限于软件工程）大量工人的方向前进。这不是同一回事。人们总倾向于认为过去能预测未来（其实没有哪个严肃的历史学家信这个），但有时极端事件会发生。

现在类似的事情正在发生，而人们因为 OOP、元宇宙、NFT 等失败的类比而轻视它。作者不想危言耸听，但眼前的东西确实比 OOP 更大：我们建造了一个矩阵乘法机器，在合适的工具和提示下，可以连续数小时输出有用的文本。这是科幻级别的存在。我们应以相应的态度来对待它。

关于「只要工程原则过硬，你就安全」

有评论认为，如果作者对未来的预判是正确的，那有能力的软件工程师仍然是安全的 —— 领域知识可以学得快，但如何应用好的工程原则很难学。

作者不同意这个观点。模型终将学会好的工程原则。举例来说，有一家叫 Turing AI 的公司，正在雇佣工程师编写跨各种领域和语言的「好代码」，用于实验室的强化学习。所谓「人类护城河」不会永远存在。

关于「你低估了自己的引导能力」

有评论认为，他能把模型引导出好结果，是因为他已经懂了这个领域。

作者表示：但愿如此。但他发现 LLM 在向他解释和提供其他完全陌生的领域建议方面也很擅长，而且他拿去跟法务 / 产品经理交叉验证，通常都是对的。

也许，这就是我们这代人真正要面对的问题：不是「AI 会不会取代我」，而是「当我花了十年建立起来的一切都可以被提示词绕过时，我还剩下什么」。技术乐观主义者会说总会有新岗位，现实主义者会看到供需曲线的无情。你可以继续做那个驾驭浪潮的人，但浪潮的方向不再由你决定。而这，与过去任何一次技术变革都不一样。

本文转自：凤凰网科技

原文地址： https://tech.ifeng.com/c/8uA2J6Yp2Su