> ## Content Index > Fetch the complete content index at: https://huizhou92.com/llms.txt > Use this file to discover other available public pages before exploring further. # 软件工程师的身份危机 by Annie Vella - URL: https://huizhou92.com/e8-bd-af-e4-bb-b6-e5-b7-a5-e7-a8-8b-e5-b8-88-e7-9a-84-e8-ba-ab-e4-bb-bd-e5-8d-b1-e6-9c-ba-by-annie-vella/ - Published: 2025-03-26T11:17:56.000Z - Updated: 2026-09-06T11:41:15.000Z - Description: 软件工程师的身份危机 by Annie Vella. 原文地址： https://annievella.com/posts/the-software-engineering-identity-crisis/ 我们很多人选择成为软件工程师，是因为我们在亲手 创造 事物中找到了自我价值——而非仅仅管理或监督已有事。 - Author: huizhou92 - Tags: talk, 职业生涯, #lang-zh-cn 原文地址： [https://annievella.com/posts/the-software-engineering-identity-crisis/](https://annievella.com/posts/the-software-engineering-identity-crisis/?ref=huizhou92.com) 我们很多人选择成为软件工程师，是因为我们在亲手*创造*事物中找到了自我价值——而非仅仅管理或监督已有事物。 但这种身份认同正面临挑战。 人工智能（AI）编码助手不仅仅改变了我们编写软件的方式，它们还在从根本上动摇了我们对自我身份的认知。我们正在从创造者转变为编排者，从建造者转变为监督者。从工程师变成了看起来非常像……管理者的人。 这种讽刺意味，直击痛点：多年来，我们一直认为软件工程超越了单纯的编码。需求、设计、测试、运维——这些都被认为是我们的专业技能的一部分。然而，行业却将我们推向了相反的方向。我们将这些职责交给了专业人士——产品负责人、架构师、质量工程师、平台工程师——而我们则加倍投入到我们的编码专业知识中。我们成为了代码大师，成为了现代魔法的骄傲使用者。 现在，就在我们完善这项技能的同时，人工智能正威胁着要夺走它。 ## 我们即将失去的快乐 让我们坦诚地谈谈这里存在着什么风险。我们中的许多人不仅仅是编写代码——我们**热爱**编写代码。我们的身份融入到我们精心设计的每一个优雅的解决方案中，融入到我们通过的每一个测试中，融入到我们通过纯粹的逻辑和创造力解决的每一个问题中。这不仅仅关乎职业或技艺，而是我们身份的真实写照。 想想那些充满成就感的时刻：当你最终追踪到那个困扰生产环境的难以捉摸的bug时，当你计算出如何优化那个缓慢的算法并看到响应时间从几秒降到几毫秒时，当你把一个迷宫般的遗留代码改造成干净且可维护的东西时。这些不仅仅是成就——它们是我们作为工程师的表达。它们是提醒我们为什么选择这条道路的时刻。 现在想象一下人工智能接管这些精雕细琢的时刻。这些工具的创造者描绘了一幅乐观的图景——他们说我们将花更多的时间在**定义意图**、**高层架构**和**系统思考**上。但仔细听听他们真正想说的是什么：我们将成为监督者而不是创造者，管理者而不是建造者。 ![软件工程师正在进化为系统架构师？](https://images.hxzhouh.com/blog-images/2025/03/d902c8a0f8ab5ac9bb58e2077195feb7.png) [软件工程师正在转变为系统思考者和高层架构师吗？](https://www.linkedin.com/posts/ashtom%5Fhow-ai-tools-are-reshaping-the-coding-workforce-activity-7303108929264275456-O5v2?ref=huizhou92.com) 这种转变引发了关于我们作为建造者的身份的重要问题：监督是驱动我们的动力吗？是它让我们早上从床上跳起来，渴望解决下一个难题吗？ ## 身份转变：它已经到来 我们现在讨论的并不是什么理论上的未来——而是我们正在经历的现实。当谷歌最近透露人工智能[生成了他们超过四分之一的新代码](https://arstechnica.com/ai/2024/10/google-ceo-says-over-25-of-new-google-code-is-generated-by-ai/?ref=huizhou92.com)时，这仅仅是个开始。Y Combinator 的首席执行官 Garry Tan 透露，对于他们大约四分之一的初创公司来说，[95% 的代码现在是由人工智能编写的](https://www.cnbc.com/2025/03/15/y-combinator-startups-are-fastest-growing-in-fund-history-because-of-ai.html?ref=huizhou92.com)——标志着一个真正意义重大的转变。我自己的硕士研究也揭示了类似的景象：77% 的人花费在编写代码上的时间变少了，几乎一半的人认为我们的核心技能可能会退居二线，让位于提示工程（prompt engineering）。想想这种转变：从设计解决方案到设计提示。 ![提示工程会取代传统的编码技能吗？](https://annievella.com/images/prompt-engineering-replace-coding-skills.png) 提示工程会取代传统的编码技能吗？ 当被问及如何培养提示工程技能时，软件工程师强调要提高沟通技巧。让 AI 按照你想要的方式行事，意味着能够清晰地表达事情——提供恰到好处的上下文，并清楚地描述任务。你与生成式人工智能（Gen AI）沟通得越好，输出结果就越有可能符合你的期望。有些人甚至建议对这些工具**礼貌**一些，像对待团队成员一样对待它们——好像你在引导另一个人为你做某事。 这些变化如此深刻，以至于我们正在创造新的术语来描述我们正在成为什么样的人。以 **vibe coding**（氛围编码，一种依赖 AI 建议进行编码的方式）为例，这是 [Andrej Karpathy](https://karpathy.ai/?ref=huizhou92.com) 最近在 [推特](https://x.com/karpathy/status/1886192184808149383?ref=huizhou92.com) 上创造的一个词。它捕捉到了我们编写软件方式的深刻转变。 在这种方式的一端是传统的方式——工匠的方式。我们有目的地编写每一行代码，每一个函数名和架构决策都反映了我们对系统的深刻理解。 在另一端呢？我们让 AI填补空白，与它的建议“产生共鸣”。我们关注的是“是什么”，而不是“怎么做”。正如 Karpathy 所说：“完全沉浸在氛围中，拥抱指数增长，忘记代码的存在。” 最后一部分让我们停顿了一下——如果我们忘记了所有关于代码的事情，我们还是工程师吗？ 在最近的一次[结对编程](https://www.youtube.com/watch?v=HtqxI53h7zM&ref=huizhou92.com)会议中，工程领域的思想领袖 [Gene Kim](https://itrevolution.com/author/gene-kim/?ref=huizhou92.com) 和 [Steve Yegge](https://steve-yegge.medium.com/?ref=huizhou92.com) 演示了这在实践中是什么样子的。他们使用 AI 编码助手，将一个 3500 行的遗留 Ruby 脚本移植到 Kotlin——这项任务通常需要一周的时间——仅用了一个小时。人工智能不仅仅翻译了代码，还改进了它，添加了他们多年来一直想要的模块化架构和单元测试，但却无法证明花费的时间是合理的。 甚至连 DevOps 的教父 [Patrick Debois](https://www.jedi.be/?ref=huizhou92.com) 也认为这种转变正在重塑我们的身份。在他[最近对 AI 原生开发模式的分析](https://ainativedev.io/news/the-4-patterns-of-ai-native-dev-overview?ref=huizhou92.com)中，他概述了我们工作方式的四个根本性转变： ![Patrick Debois：AI 原生开发的 4种模式](https://annievella.com/images/patrick-debois-four-AI-native-patterns.png) [Patrick Debois：AI 原生开发的 4 种模式](https://ainativedev.io/news/the-4-patterns-of-ai-native-dev-overview?ref=huizhou92.com) 这些模式揭示了一个深刻的转变：我们正在从 AI 系统的生产者转变为管理者，从详细的实现转变为表达意图，从交付转变为通过快速实验进行发现，以及从内容创建转变为知识管理。我们的角色正在演变为将创造与组织、构建与监督相结合。 总的来说，我认为可以公平地说，我们职业身份的本质正在发生核心变化。 ## 塑造我们身份的技艺 要理解这种身份危机，我们需要看看编码的技艺对我们产生了多么深刻的影响。从本质上讲，编写代码是关于掌握和控制——我们花费了多年时间来完善的技能。现代编程语言比过去使用的那些语言高级得多，但它们仍然需要深厚的技术理解。如今，很少有开发人员处理指针和内存管理的细节，但我们仍然以了解事物在底层是如何运作的而自豪。即使框架承担了更多繁重的工作，我们仍然保持着我们作为工匠的身份，我们对自己的工具了如指掌。 今天的编程更多的是以创造性的方式将 API、框架和库拼接在一起，以构建有意义的东西。事实上，谷歌最近的一项研究表明，软件工程中的**创造力**主要集中在[巧妙的重用而不是纯粹的创新](https://ieeexplore.ieee.org/document/10445159?ref=huizhou92.com)这一概念上。这对我来说很有意义——我经常评论说，我们现在真的都只是“集成”工程师。 尽管如此，我们仍然以了解构建某些东西所需的所有奇怪语法而感到自豪。这就像一种只有我们才能理解的秘密语言。精通一门编程语言使你能够灵活驾驭、精准操控它。它非常详细——仅仅一个错误的字符就会破坏整个程序，而且可能需要大量的时间和耐心才能让它按照你想要的方式运行。 > 首先，必须完美地执行。在这方面，计算机也类似于传说中的魔法。如果一个字符，一个停顿，咒语的形式不严格正确，魔法就不会起作用。 ——弗雷德里克·P·布鲁克斯，《人月神话》，第一章，Addison-Wesley，1975 其他 99% 的人认为我们理解代码是魔术，而且确实，可能需要多年的刻意练习才能掌握它。那些掌握不止一种编程语言的人有幸被称为“多面手”。我们中的许多人以编写干净、优雅的代码而感到自豪。我们热情地争论不同的风格和最佳实践，而且常常对此过于认真。 ## 一位不甘心的管理者自述 让我分享一个关于身份演变的故事，它可能会引起共鸣。 在做了十年个人贡献者之后，我遇到了技术职业道路上臭名昭著的天花板。“高级首席软件工程师”——这就是技术职业道路的尽头。当时 Staff+ Engineering（资深工程师之上的职级）还不存在，而我所在公司的唯一架构师职位也已有人选。我面临着一个会改变我身份的选择：继续做一名建造者，还是成为一名监督者。 我选择了管理。不情愿地。这就是这条路引导我的方向。我告诉自己这仍然是工程，只是在一个不同的层面上。管理系统与管理人员并没有什么不同。我仍然可以在其他任务之间继续编写代码。 听起来很熟悉吗？这其中的相似之处令人惊叹。正如我不得不将直接解决问题的工作换成会议和文档工作一样，我们现在也被要求用提示工程来代替编码。那些定义我们作为工程师的技能——掌握语法、优雅地构建我们的代码、捕获和处理边缘情况、调试复杂问题——正在被降级到人工智能。相反，我们被告知要专注于听起来非常像管理的技能：清晰的沟通、系统思考、问题定义。 但这里没有人谈论的是：身份危机。当你意识到你不再用自己的双手建造东西时的那种深深的失落感。当你的技术专长变得不如你“管理”工具的能力重要时。当你的技能变成监督时。 组织人工智能能给我们带来同样的身份认同感吗？一种作为建造者、创造者、问题解决者的感觉？ ## 当机器挑战我们的身份时 现在，我们身份危机的根源变得清晰起来。我们花费多年时间完善的技能——那些给予我们目标、意义和自豪感的技能——现在正被机器以更快、更便宜和更大规模的方式完成。当然，质量不如你手写的代码（但目前而言）。但是现在编写代码的速度是惊人的，企业都在争先恐后地参与进来。 这就是一线希望出现的地方。还记得那种讽刺吗——我们是如何将更广泛的技能方面交给专家的？人工智能正在推动我们重新获得我们曾经知道的东西：软件工程超越了单纯的编码。这个核心真理依然存在——最终，软件工程是关于解决问题、创造解决方案、构建重要的东西。 这些更广泛的技能——Addy Osmani 在他关于[人工智能辅助编码中人类 30% 的文章](https://addyo.substack.com/p/beyond-the-70-maximizing-the-human)中称之为“持久的工程技能”——一直将伟大的工程师与优秀的工程师区分开来。沟通、大局观思考、处理歧义——这些在人工智能驱动的世界中变得更加重要。 然而，这种对更广泛技能的强调在我们的社区中引发了争论。对于某些人来说，这听起来很像重新包装过的管理。而且他们并没有完全错——最近的一篇 [CIO 文章](https://www.cio.com/article/3509174/ai-coding-assistants-wave-goodbye-to-junior-developers.html?ref=huizhou92.com) 证实，开发团队已经在进行重组，以专注于监督而不是创造。这篇文章设想未来的团队由一个产品经理、一个用户体验设计师和一个主要使用人工智能生成原型的软件架构师组成。这些架构师或高级开发人员必须“理解内容……了解客户是谁以及我们试图实现什么”——这是被重新包装成技术工作的经典管理职责。 ![披着技术外衣的管理](https://annievella.com/images/addy-osmani-durable-engineering-skills.png) 披着技术外衣的管理 这种演变引发了关于我们作为工程师的身份的根本性问题：随着传统职业阶梯的转变，下一代软件工程师将如何发展他们的技能？我们如何在拥抱这些新工具的同时，保留塑造我们职业的深厚技术理解和技能？也许最令人不安的是——随着人工智能能力的指数级进步，我们作为工匠的角色是否会像工业革命期间的手工织布工一样过时？ ## 前进的道路 也许答案不在于抵制这种转变，而在于通过历史的视角来理解它。这些身份危机——这些通过我们的工作来定义我们自己的根本性转变——并不是什么新鲜事。它们是技术重塑一个职业时重复出现的一种模式的一部分。 在[工业革命](https://www.britannica.com/story/the-rise-of-the-machines-pros-and-cons-of-the-industrial-revolution?ref=huizhou92.com)期间，工匠们也面临着类似的危机。他们经过几代人磨练的传统技能正在被机器取代。但接下来发生的事情令人着迷：许多人适应了，成为了可以修理和改进这些威胁要取代他们的机器的专业人士。其他人则找到了应用他们对材料和工艺的深刻理解来改进整个工厂运营的方法。 如果我们把这种类比应用到我们的人工智能时代，就会出现一条类似的道路。软件工程的核心——解决问题和创造价值——仍然没有改变。我们的工具正在发展，随之而来的是有效使用它们所需的技能。 问题不在于我们是否会成为机器的管理者——而在于我们是否能在这种技能的演变中找到同样的满足感。 ## 工程师的困境 那么，这会把我们带到哪里？我们是否注定要成为人工智能智能体的监督者，而不是代码的编写者？这是一个应该抵制还是拥抱的未来？ 真相，一如既往，是细致入微的。正如一些工程师自然而然地倾向于管理，而另一些工程师则更喜欢保持亲力亲为一样，我们可能会看到在如何与人工智能互动方面出现类似的范围。有些人会擅长组织人工智能系统，专注于高层设计，并使这些系统更高效和可靠——指挥一场技术交响乐，而不是进行独奏。另一些人则会在人类专业知识仍然至关重要的领域找到自己的使命——可能是在安全敏感的应用程序、人工智能缺乏训练数据的新领域，或性能和可靠性至关重要的系统中。关键不是抵制这种演变，而是在其中找到自己的位置。 显而易见的是，“软件工程师”的定义正在扩大，而不是缩小。使某人有价值的技能正在多样化。这既带来了挑战，也带来了机遇。 对于那些热爱编码技能的人来说，这种转变可能会让人感到威胁。但请记住，人工智能工具仍然只是工具。它们不了解代码背后的“为什么”、业务背景或所服务的人类需求。它们无法真正意义上进行创新，至少目前还不能。而且据我们所知，它们无法**感受到**解决复杂问题的满足感或创造新事物的乐趣。 也许在这个新领域中最有价值的技能不是提示工程或系统架构，而是**适应性**——愿意进化、学习新技能，并在一个快速变化的领域中找到自己独特的位置。 ## 光明的一面 尽管存在这些挑战，但我们需要承认一些重要的事情：这些人工智能工具可以非常强大。借助像[Windsurf](https://codeium.com/windsurf?ref=huizhou92.com) 和 [Cursor](https://www.cursor.com/?ref=huizhou92.com) 这样将软件开发提升到一个全新水平的自主智能体集成开发环境（agentic IDE），就像拥有一个始终在你身边的支持性结对编程伙伴一样，随时准备帮助你解决以前可能看起来令人望而却步的问题。 对于初级开发人员或我们这些可能感到有些生疏的人来说，人工智能助手可以增强信心——在你盯着一个空白文件时帮助你入门，在你犹豫不决时验证你的方法，或者以一种对你有意义的方式解释复杂的概念。对于经验丰富的开发人员来说，它们就像拥有一个不知疲倦的助手，可以处理日常任务，而你可以专注于问题的更具挑战性的方面。 如今，我们能迅速搭建原型、探索各种方法，甚至在几分钟内掌握新技术——这速度着实令人震撼。可能需要数周的研究和反复试验才能完成的事情通常可以在几小时甚至几分钟内完成。这就像拥有超能力一样——能够放大我们的能力，并比以往更快地将我们的想法变成现实。 ## 现实检验 但是，能力越大，责任越大。最近一项全面的 [GitClear 研究](https://arc.dev/talent-blog/impact-of-ai-on-code/?ref=huizhou92.com) 分析了 2.11 亿行代码，揭示了一些令人担忧的趋势，因为人工智能代码生成工具变得越来越普遍： - 复制粘贴的代码增加了 17.1%，这是人工智能辅助的代码重复首次超过重构（移动）的代码。 - 重复代码块增加了 8 倍，现在有 6.66% 的提交包含重复的代码段。 - 代码改动增加了 26%，所有代码更改中有 5.7% 在两周内被修改或删除。![GitClear：代码更改趋势](https://annievella.com/images/gitclear-2025-trends-in-code-changes.png) [GitClear：代码更改趋势](https://arc.dev/talent-blog/impact-of-ai-on-code/?ref=huizhou92.com) 虽然我们生成代码的速度比以往任何时候都快，但我们也花费更多的时间来修复人工智能生成的错误并处理更难维护的代码。这不仅仅是速度问题——而是关于编写可持续、可维护软件的技能。 ## 隐藏的身份危机 然而，在这些表面上的变化之下，隐藏着一个更深层次的挑战——一个触及我们作为工程师的核心的挑战。新兴的人机协作领域正在揭示关于我们未来的令人不安的真相。[2024 年的一项研究](https://www.sciencedirect.com/science/article/pii/S2352250X24000502?ref=huizhou92.com)表明，当人类和人工智能一起工作时，结果往往达不到预期。不是因为人工智能缺乏能力，而是因为信任在机器和人类之间的运作方式不同。 我们与人工智能建立信任的方式与我们与人类团队成员建立信任的方式不同。 对于人类来说，信任是通过共同的成功逐渐建立起来的。一起解决的每一个问题都会加强这种联系。即使是处理得当的失败也能加深信任。对于人工智能来说，信任通常开始时很高，但会迅速瓦解。 每一个不正确的回答、每一个幻觉般的错误修复、每一次放错地方的信心都会削弱我们对机器的信任。与人类关系中信任通常会随着时间的推移而增长不同，人工智能的信任通常会在早期达到顶峰并下降。 当信任消失时，生产力也会下降。 该研究揭示了原因： - 人工智能在解释我们的意图方面存在固有的不可预测性 - 它缺乏使人类协作流畅的上下文意识 - 它的决策通常缺乏透明度，因此一旦失去信任就很难重建 这些挑战反映了我们许多人在转变为技术领导者时所经历的事情。正如新的工程经理必须学会信任他们团队的工作而无需自己动手一样，我们现在也面临着与人工智能类似的转变——学会指导和验证，而不是自己编写每一行代码。 现实是严峻的：尽管人工智能具有原始能力，但团队在有人工智能的情况下通常比没有人工智能的情况下表现更差。正如团队的生产力在无效的领导下会受到影响一样，当我们不了解如何使用我们的人工智能工具时，我们的效率也会降低。 ## 重塑你的身份 从我作为一名不情愿的经理的历程以及我对这种人工智能转型的研究中，我看到了三种我们可以保留我们作为建造者身份的方式： 1. **抵制**——有些人会选择专注于人类创造力和深厚技术专业知识仍然至关重要的领域 2. **适应**——另一些人会拥抱人工智能编排，成为一种新型技术交响乐的指挥家3\. **平衡**——还有许多人，像我一样，会寻求一条中间道路——使用人工智能来完成日常任务，同时保留直接解决问题的乐趣 然后我意识到一个改变我观点的事实：*我们不必只选择一条道路*。 ## 身份的钟摆 也许我们身份危机的答案在于[工程师/经理的钟摆](https://charity.wtf/2017/05/11/the-engineer-manager-pendulum/?ref=huizhou92.com)。我自己在这些角色之间转换的经历教会了我一些关于身份的关键知识： - 管理并没有取代我的工程师身份——它扩展了它 - 回归亲力亲为的工作并不是倒退——而是身份的更新 - 钟摆的摆动本身成为了我的一部分——适应性强、不断成长、不断进化 就在那时，我突然意识到：*这正是我们需要的人工智能时代的模型*。如果我们不必被迫成为永久的“人工智能经理”，而是可以在以下角色之间切换，那会怎么样呢？ - 深入的技术工作，我们可以直接编写和完善代码 - 战略编排，我们可以指导人工智能系统 - 将这两种方法结合起来的创造性问题解决 这种平衡的方法与我从其他工程师那里听到的声音产生了深刻的共鸣。我的研究表明了一个明确的信息：保持强大的工程基础比以往任何时候都更加重要。我们需要深厚的技术知识才能有效地审查、验证和调整人工智能生成的代码——因为它通常不太正确。当被问及他们对人工智能编码助手的担忧时，软件工程师将代码质量和安全性排在工作保障之上。 ![对人工智能编码助手的主要担忧](https://annievella.com/images/ai-concerns.png) 软件工程师对人工智能编码助手的主要担忧 这告诉我一些深刻的事情：我们把自己视为工程卓越的守护者，确保人工智能生成的解决方案遵循可靠的软件工程原则。我们并不是想把我们的专业知识委托给人工智能——我们正在进化以新的方式应用我们的技能。 ## 你的行动 当我们驾驭这种转型时，一个基本的真理浮出水面：我们的身份危机实际上根本不是关于人工智能的。对人机协作的研究、与管理转型的相似之处、角色的钟摆——它们都指向更深层次的东西。除了在建造者或监督者之间做出选择之外，还存在着我们作为创造者的核心。 现在我们又回到了原点：人工智能并没有抢走我们的工作，而是给了我们一个机会来重新获得我们交给专家的那些更广泛的角色方面。回到软件工程不仅仅意味着编写代码的时代。当它意味着理解整个问题空间时，从用户需求到业务影响，从系统设计到卓越运营。 钟摆的比喻在这里为我们提供了智慧。正如我们中的许多人在工程和管理角色之间摇摆一样，我们可以以类似的方式拥抱人工智能的流动性。有些时候，我们会深入研究代码，体验设计优雅解决方案的快感。其他时候，我们会退一步来指导人工智能系统——不是作为监督者，而是作为了解他们技能的每一个部分的大师级建造者。就像工业革命的工人成为优化改变他们技能的机器的专家一样，我们可以掌握这些人工智能系统——使它们成为我们创造力的工具，而不是我们创造力的替代品。 在人工智能时代，最重要的是保留我们本质的东西：构建事物、解决难题、使某些东西完全正确运行的纯粹乐趣。我们的工程卓越不仅仅是验证人工智能的工作——它源于对系统如此熟悉，以至于我们可以塑造它们、改进它们、改变它们。 选择不是人工智能是否会改变我们的行业——它已经在改变了。真正的选择是我们如何与它一起进化。我们是会坚持对成为一名工程师的过时观念吗？还是会重新获得我们的技能，不是作为单纯的编码员，而是作为人工智能增强型系统的大师级建造者？ 钟摆正在摆动——你会坚守阵地，还是随之而动？ --- - [本文长期链接](https://huizhou92.com/e8-bd-af-e4-bb-b6-e5-b7-a5-e7-a8-8b-e5-b8-88-e7-9a-84-e8-ba-ab-e4-bb-bd-e5-8d-b1-e6-9c-ba-by-annie-vella) - 如果您觉得我的博客对你有帮助，请通过 [RSS](https://huizhou92.com/sitemap.xml)订阅我。 - 或者在[X](https://x.com/@piaopiaopig?ref=huizhou92.com)上关注我。 - 如果您有[Medium](https://medium.huizhou92.com/?ref=huizhou92.com)账号，能给我个关注嘛？我的文章第一时间都会发布在Medium。