夜雨聆风
导读：
本文作者是一名拥有十年从业经验的后端工程师，长期深耕金融、支付领域。随着大语言模型与 AI 智能体快速普及，他赖以立足的三大核心能力接连被冲击：专业领域知识、线上问题排查与分布式系统调试能力优势不再，就连代码架构与代码质量把控这最后一道壁垒也逐渐弱化。行业岗位要求趋于同质化，资深工程师的竞争力不断被稀释，作者陷入职业迷茫，开始思索程序员在 AI 时代的出路。
我是一名软件工程师，到今年从事软件开发正好满10年。
我的职业生涯始于Web前端工程师（当时调试前端代码对我来说更容易，所以选择了这条路），但很快我就转到了Web后端，一直深耕勤学，再未离开过。
通过经历一系列的巧合，当我踏入后端开发领域后，最终从事了IT金融、财务和支付处理领域的开发工作。在这些工作中，我有着很大的自主权，并且与产品经理和利益相关者建立了密切而坦诚的关系。
我学到了很多关于该领域的专业知识，以及如何有效地编写相关的程序：PCI 合规性、复式记账、托管、对账、支付生命周期、银行转账幂等性等等。
很显然，我应该将职业生涯重点放在该领域，并且成为这领域的专家，以便在这个对领域专家的需求日益增长的领域中脱颖而出，成为一名专业的从业者。
第一个被削弱的支柱：领域特定知识
去年，我又加入了一家金融领域的公司。在此之前，我曾就职于一些业务/产品中包含较强支付和金融成分的公司，但并非纯粹的金融公司。
那家公司全心全意地拥抱人工智能，因此我从一开始就获得了 ChatGPT 和 Claude Enterprise 帐户，公司管理层鼓励我使用它们进行研究、探索甚至编码，尽管也警告说我仍然应该审查并拥有投入生产的每一行代码。
我最早的项目之一是改造原有的在线支付系统。公司原来那套系统简直一团糟。公司聘用我的原因之一就是我之前有过搭建这套系统的经验，并且信任我，把这项任务交给了我。
这与我之前工作过的公司不太一样，他们希望我在编码之前编写的“设计文档”能够同时被工程师和产品经理阅读。因此，这些文档不应该包括深入的技术分析，而应该更侧重于架构和功能层面。
我的第一份设计文档是在几乎没有人工智能辅助的情况下编写的——当时我甚至把人工智能称为“随机鹦鹉”（现在我这么认为了）——并且成功交付了。
我珍视自己的知识，认为任何大语言模型都无法取代它。
然后，我的小组领导联系我说：虽然你代码交付速度很快，但设计文档的交付速度太慢了。你有没有用人工智能？你应该多用一些它们。
“这肯定行不通，”我心里想，但还是同意了。当时的模型虽然不如现在的先进，但确实大大提高了我的写作速度，甚至决策效率。
然后我开始意识到：我多年来积累的所有知识——不同实现方式之间的权衡、获取机制的运作方式、如何构建幂等性以防止重复收费等等——都将变得毫无用处。尽管这些模型仍然需要一些指导，但它们能够将构建此类系统的各个环节串联起来，而这才是最难的部分，只能通过多年的实践经验才能在大脑中形成。那是我第一次感到震惊。
但是我想，没有什么问题，因为网上有很多文章讲解这玩意儿的工作原理，还有各种技术文档，我们也有博客解释如何将这些技术工具应用到实际领域。对人类来说，学习所有这些可能需要很长时间，但这些都是训练数据，大语言模型可以从中学习。
模型永远无法胜任的，也是人类的强项，就是调试！我在生产环境中积累了丰富的调试竞态条件和分布式系统的经验。这正是我长期就业的保障。
第二个被削弱的支柱：调试和分布式系统
所以，当大语言模型（LLM）开始擅长编写文档和协助规划实际实现方案后，他们也开始擅长编码了。这始于2025年下半年Claude Code的热潮，随后Codex出现等等。虽然在此之前我每天都使用LLM来编写单元测试，但我当时并不信任他们能够独立完成完整的实现。
下一步自然而然就是将更多人工智能引入代码编写中。
说实话，我挺喜欢的。我喜欢把产品发布到生产环境，看到用户满意，就像我喜欢写代码一样。所以，我用一件我喜欢的事换了另一件我喜欢的事，这也很公平。
LLM虽然越来越擅长编程，但仍然无法调试（当时或人类留下的）混乱局面，所以我的角色仍然比操控机器人更重要——这是一张获得就业机会的门票。
一切似乎都很正常。然后又出现了 MCP、代理工作流程和 Claude 4.5，天开始塌下来了。
说实话，Claude 4.5 并不算太好用。它只能解决大约 60% 的 bug，前提是提供堆栈跟踪和一些上下文信息（大多数情况下，只需要启用 Sentry MCP 的 Sentry 连接即可）。有时它给出的解决方案听起来合情合理，但实际上完全错误。
然而这一次，我不再怀疑机器了。我发现，过去需要花费一整天全职调试才能解决的bug，现在用Claude Code一次就解决了。当然，并非所有bug都解决了，但规律已经很明显了。
随后出现了 4.6、4.7、GPT 5.5、Opus 4.8 和 DataDog MCP……现在我有了命令行工具，可以一次性解决分布式系统中的各种 bug。这些 bug 以前我根本解决不了，以前需要我花两天时间全职调试，而且这些 bug 还存在于缺乏分布式可观测性的分布式系统中。现在 90% 的 bug 都能一次性解决，包括各种奇葩的竞态条件、意想不到的极端情况、第三方集成问题、未记录的 API 边界情况等等。我几乎不用再插手了。
当然，我仍然有工作，因为总得有人来审查代码和操控机器人。但我现在只不过是个现成的工程师而已。我没有任何高级工程师在操控LLM系统时无法比拟的领域专业知识。我所有在金融和支付领域的专业知识，所有通过无数汗水和泪水积累的调试直觉和分布式系统知识，现在都变成了摆设。
我们一直被教导，通才和专才永远各司其职。但如今，市场正在将所有人塑造成通才。这本身并非坏事，直到你深入了解供求关系：如果人人都是通才，而市场需求又不足以匹配通才的需求，那么通才的价格就会下降。而我们都知道，这种需求正在萎缩。
第三大支柱，也是尚未被削弱的支柱：代码质量和架构
不过，我仍然坚持一个原则：代码质量和软件架构——现在却被简化为所谓的“品味” 。
在我的职业生涯中，我一直喜欢重构，始终珍视优质代码，并会在迭代开发中为此争取时间。领域驱动设计（DDD）、六边形架构、整洁架构，你肯定听说过这些热门词汇。我喜欢这个话题，喜欢探讨代码库构建的各种权衡取舍和不同思路。我真的很喜欢它。
这是硕果仅存的支柱。只是，现在已经没有人关心了。
人工智能代理程序在维护代码库的组织方面做得非常糟糕。如果不加以引导，它们很快就会遇到循环依赖问题。它们会重复编写代码，添加不必要的注释，混淆纯函数和副作用，并且无视 SOLID 原则。
这本应能保障人类的就业，但如今这项技能却被简化成了“品味”一词。但这不仅仅是改名而已，整个行业正在迈向一个代码组织不再那么重要的世界。
当然，人类应该引导智能体避免出现带有循环依赖关系的意大利面条式代码库。我们不希望出现那种一碰就坏、根本无法修改的代码库。但是，C到D现在没问题了。没人再需要A到B那种代码库了，因为它们是为LLM编写的，而不是供人类阅读的。
我不想争论这本身是好是坏。如果源代码现在是为机器而非人类编写的，那么针对机器进行攻击或许也无妨。
但这是我另一项正在衰落的专业技能。我之前积累的很多相关知识现在都不再那么有价值了。我之前投入的所有时间——读书、做实际的练习、和其他工程师讨论、撰写应用设计报告——都变得毫无意义。
接下来，我该怎么办？
我目前还有工作，而且我认为在可预见的未来（至少在那家公司）我还会继续工作。但我不知道该如何考虑更长远的发展。
我花了十年时间（如果算上非专业经验，花的时间更长）钻研一些如今越来越不值钱的技能。我最后一块赖以生存的专长如今也只剩下“尝鲜”的一面，而且恐怕也维持不了多久了。
我知道这并非我个人的感受。大约八个月前，我所在的公司进行了裁员（据他们所说，与人工智能无关）。一些才华横溢的前同事被裁掉，至今仍在找工作。他们中的大多数人都面临着我之前提到的同样的问题：他们的专业知识已不足以让他们脱颖而出。
公司目前再次招聘几个职位，领域知识不再是重要的加分项。以前我们会写“软件工程师 - 领域”，现在只需写“软件工程师”，团队分配会在录用后确定。
当然，这对那些从未有机会深入了解某个领域的优秀工程师来说是好事，他们现在有了更好的就业机会；但想到其他一些毕生致力于积累领域知识的优秀工程师现在也在同一条道路上竞争，也让人感到难过。
现在看来，要想长期保持就业能力，唯一的出路似乎是将我的专业领域转移到大语言模型（LLM）难以精通的领域。
除此之外，还有什么好选择？
我曾想过重返校园，学习数学、统计学和高级机器学习，然后申请前沿实验室的研究职位。然而，我所在的国家根本没有前沿实验室，仅有的几个申请也人数爆满，而且我还有一些家庭事务，难以移居到国外。等到我经济条件允许的时候，RSI（重复性劳损）或许已经让研究人员这个职业过时了。
或许我应该考虑把木工爱好发展成一项职业。
作者：一个前端
原文：
https://human-in-the-loop.bearblog.dev/llms-are-eroding-my-software-engineering-career-and-i-dont-know-what-to-do/
