夜雨聆风AI 杀死了软件工程师（然后创造了更好的东西）
核心要点：软件工程行业正在被立即重写，不是缓慢地，不是在某个遥远的未来。绝大多数公司的应对方式恰好是错误的。
先看数据
Cursor（AI 编程工具）每个员工产生约 330 万美元收入。中位数 SaaS 公司是多少？13 万美元。25 倍的差距。仔细想想这个数字。
OpenAI 发布 Sora Android 应用仅用了 4 名工程师、28 天。不是 40 人，不是 400 人，是 4 个人。
目前全球 41% 的代码由 AI 参与编写。
核心要点：如果你的公司还没有从根本上重组软件开发方式，你已经落后了。不是差一点，而是差一个数量级。
瓶颈转移了
以前写代码是困难的、昂贵的、需要花费很长时间的事情。现在不一样了。代码现在既便宜又丰富。AI 生成代码的速度比任何人类都快得多。
现在稀缺的是代码周围的一切：
生成前：架构、规范、上下文，确保 AI 有正确的输入来产生有用的东西 生成后：验证、审查、判断——你能判断 AI 刚生成的代码是否真的正确？它与系统其他部分是否契合？它能在真实条件下承受考验吗？
Microsoft 进行了一项 AI 原生工程实验，发现工程师最终将 73% 的时间花在战略性工作上：规划、架构和审查。纯实现工作降至个位数，之前大约是 50%。
软件工程师的角色已从编码者转变为编排者。如果你全部价值在于做一个 glorified 的打字员，把英语翻译成 Go 或 Python，我有个坏消息告诉你。那份工作没了。你从来都不是工程师，你是代码猴子，而 AI 是比你更好的代码猴子。你的价值现在在于思考，而不是打字。
人的一面
让我们谈谈这实际上是什么感觉。因为那些数字背后是真实的人正在经历真正迷茫的时期。
一位匿名的初级工程师直言不讳地说：「我基本上是 Claude Code 的代理。我的经理告诉我做什么，然后我告诉 Claude 做。」这是一个真实的人描述他真实的工作。与此同时，高级工程师正在蓬勃发展，报告巨大的生产力提升。两种体验之间的差距令人震惊。
加州大学系统（University of California）2025 年计算机科学入学率下降了 6%。这是自互联网泡沫破灭以来的首次下降。学生和家长正在审视这个行业，想知道这里是否还有职业发展空间。
注意事项： paradox：84% 的开发者使用 AI 工具，但对 AI 准确性的信任度从 43% 下降到 29%。开发者正在使用他们不信任的工具，因为他们觉得自己别无选择。
人们正在分化为三个群体：
核心要点：
第一群：适应并蓬勃发展的人——主要是拥抱转变、看到产出倍增的高级工程师 第二群：焦虑但正在参与的人——努力跟上，不确定今天学的东西明天是否还有用 第三群：可能处境最糟糕的人——各个级别都有，拒绝 AI 或没有熟练掌握它的人
至少焦虑的人知道地面在移动。那些忽视它的人才是会被突然袭击的人。
核心要点：AI 接手了你一直想要做的繁琐部分。样板代码、脚手架、测试生成、文档、常规重构。这些重复性的、定义明确的工作从来都不是工作中有趣的部分。AI 现在处理这些，而且处理得很好。
人类仍然不可替代的工作是你可能一直想要做的：架构、业务背景、创造性解决问题、调试复杂系统、伦理判断。这些事情需要理解一个系统为什么存在，而不仅仅是它如何工作。
AI 时代的软件开发
所有这些都从根本上改变了我们构建软件的方式。传统的 SDLC（软件开发生命周期）已死。至少应该死了。
新周期看起来是这样的：指定 → 计划 → 生成 → 验证 → 部署。规范是唯一真相。代码是生成的产物，可以丢弃，可以重新生成。如果规范正确，你可以扔掉代码并重新生成。
每个周期的大小也很重要。你不是一次构建整个功能，也不是写单行代码。正确的大小是一个小的、隔离的、可审查的、可测试的任务。每个任务本质上都是一个 TDD 检查点：指定它应该做什么，AI 生成它，测试验证它，然后继续。周期时间是几小时或几天，而不是几周或 sprint。
当周期压缩到那种程度时，它会迫使你重新思考一切：如何组织团队、谁做什么、哪些角色仍有意义。
核心要点：Spec First。不是 Design First，不是 MVP First，是 Spec First。在任何人写或生成一行代码之前，轻量级、可测试的规范。然后 AI 在几小时内生成原型。设计和代码趋同，因为「应该做什么」和「可工作的版本」之间的差距缩小到几乎为零。
给 Agent 多少自主权？
正在形成的运营模式很简单：委托 → 审查 → 拥有。
AI 处理第一轮 人类验证 人类对结果负责
核心要点：每个人都会产出更多。但你产出质量的多少完全取决于你的经验、判断力和品味。AI 是一个放大器。它放大你原本是谁。拥有强架构判断力的高级工程师 + AI = 令人难以置信的产出。缺乏上下文又没有经验的初级工程师 + AI = 快速产出一座代码山，但其中很多会以他们甚至无法检测的方式出错。同样的工具。截然不同的结果。好工程师和差工程师之间的差距不会因为 AI 而缩小。它会爆炸。
AI 让你快速到达 80%。但最后那 20% 都是判断力：集成、细微 bug、性能边界情况、架构契合度。如果你在前 80% 时就精神上退出了，最后那 20% 就变成了不可逾越的高墙。你无法审查你不理解的东西。
上下文工程是关键
你可能听说过有人声称 AI 不起作用。它产生垃圾。不应该用于严肃的工程。老实说，如果你所做的只是输入「给我构建一个 REST API」并且零上下文，输出确实是垃圾。
但取得出色结果的人在做完全不同的事情。他们向 AI 提供架构文档、编码规范、安全需求、运行手册——Agent 理解他们在特定代码库中如何做事情所需的一切。
核心要点：这就是上下文工程。持久化上下文文件。架构文档。编码规范。规则文件。安全策略。没有这些，AI 就是一个日结承包商，出现时对你的代码库、你的模式或你的约束一无所知。它会产生在隔离环境中工作但会破坏周围一切的代码。
大多数 Agent 失败不是模型失败。是上下文失败。模型能力足够。你只是没有给它做好工作所需的东西。
为 AI 重构团队
上下文工程只是谜题的一部分。你可以给 AI 完美的上下文，但如果周围的一切都停留在过去，它仍然救不了你。你的系统、流程、文化，一切都需要改变。
想想 Kubernetes 早期发生了什么。公司做的是「提升转移」：把传统应用塞进容器，部署到 Kubernetes 上，期待奇迹。好处微乎其微，有时甚至是负面的。他们把新技术螺栓连接到旧架构上，然后想知道为什么没有改善。
同样的事情现在正在 AI 领域发生。公司采用 AI 工具但不现代化任何其他东西。他们的系统没有暴露适当的 API，所以 Agent 没什么可操作的。他们的流程仍然需要两周的 PR 审查周期，所以代码生成速度快 10 倍也无所谓。他们的文化仍然把 AI 当作玩具，而不是工作的核心部分。
Gartner 预测，到 2027 年底，超过 40% 的 Agentic AI 项目将被取消。不是因为 AI 不起作用，而是因为传统系统无法支持它。70% 的开发者报告因架构不匹配而遇到集成壁垒。
链条只和最薄弱环节一样强。
如何实际组织公司
彻底扁平化。砍掉只存在来协调其他管理者的管理层级。交付单位是一个 3-5 人组成的产品舱（pod），端到端拥有一个领域。不是部门，不是功能团队。是一个能做决定、在获得六层上级批准之前就能发货的小型自治团体。
Linear 是一个很好的例子。他们整个公司只设一个产品负责人。不是产品部门，就一个人。2-4 人围绕项目组队——一个设计师加一两个工程师——然后解散重组。除移动端和基础设施外，没有永久性功能团队。没有每日站会，没有传统意义上的 sprint 规划。一切都优化以聚焦和产出。
核心要点：扩展原则很关键。永远不要把舱弄大。当产品领域变得太复杂时，拆分成两个舱。横向复制，从不纵向复制。舱负责人是工程师，不是经理。推动交付的人应该是最了解系统的人，而不是主要技能是安排会议的人。
一个舱的内部是什么样的
专职核心：1 名高级工程师或架构师 + 1-2 名 AI 增强工程师。这就是你的交付引擎。
然后是跨 2-3 个舱共享的角色：一名设计师、一名质量工程师、一名拥有技术标准的 Code Architect（代码架构师）。一名产品负责人，理想情况下是专职的，但实际上可以是具有强大产品感知的工程师。你不一定是每个舱都需要传统的项目经理。
舱拥有的是一个面向用户的产品领域，端到端。所有部分。前端、后端、数据库、基础设施、部署、监控。不是「API 层」或「数据库团队」这样的技术切片，而是真实用户接触的产品垂直切片。构建功能的团队与部署它、在凌晨 3 点它出问题时被叫醒的团队是同一个。
注意事项：平台团队是唯一的例外。那是唯一应该永久且专业化的团队。他们拥有内部开发者平台、CI/CD、开发环境、可观测性，以及越来越多的 AI 工具层。
工具和语言选择的变化
过去在编程语言或工具之间切换是一项巨大的投资。你必须学习新的语法、新的习语、新的命令、新的生态系统。这种摩擦使团队锁定在他们已经知道的东西上，即使其他东西可能更合适。
这种摩擦正在消失。AI 处理语法。重点正在转移到知道要做什么以及什么是好的结果，而不是用 Go 还是 Rust 写，用 Terraform 还是 Crossplane 管理基础设施，用 JSON 还是 YAML 格式化数据。哪个最适合手头的任务。以前一直是规则，但从来都不容易遵循。现在越来越容易了。
哪些工程角色能在 AI 中存活
现在谈谈让人不舒服的部分。谁留下，谁离开。
Shopify CEO 告诉员工：在任何新招聘之前，团队必须证明为什么 AI 做不了这份工作。这就是所有人的方向。让我们诚实面对。
核心要点（按能力而非职称）：
架构思维：扩展——这是现在最大的瓶颈。AI 无法做跨系统权衡或考虑组织约束 高级工程与系统设计：保留并大力投资——能判断 AI 输出是否正确、安全、架构合理的人是你最高杠杆的资产 平台工程：增长——更多 AI 生成的代码意味着更多部署、更多基础设施复杂性、更多 golden paths 需求 产品策略：转型并保留——消除写工单和管理积压的工作。AI 现在做这些。保留和培养驱动策略、客户洞察和跨职能对齐的人 常规实现：大幅减少——初级和中级人员传统执行的任務——样板代码、简单 bug 修复、基本 CRUD 操作——正是 AI 最擅长的 手动测试和 QA 执行：大幅减少——将剩余部分转变为质量工程，定义测试策略和构建 AI 驱动的测试框架 流程促进：作为专职角色取消——Scrum master、仪式促进者、状态追踪者。将促进工作分配给团队本身。AI 处理文档和报告 常规文档：大幅减少——AI 生成文档、API 参考和变更日志做得很好。为策略和复杂概念工作保留少数人 生产设计工作：在初级层面大幅减少——AI 处理线框图、基本原型和设计系统组件。以系统思维进行有意义用户研究的人变得更有价值，而不是更少
如何评估每个人在哪里
四个维度：
AI 杠杆：这个人能用 AI 工具倍增产出吗？ 架构判断：他们能 catch AI 引入的细微 bug 和设计缺陷吗？ 领域知识：他们理解系统为什么以这种方式构建吗？ 跨职能范围：他们能在多个领域工作，而不仅仅是一个狭窄的专业领域吗？
注意事项：如果停止招聘初级员工，下一代架构师和高级工程师从哪里来？我们现在看到的招聘悬崖意味着 5-10 年内合格的技术领导者会急剧减少。整个行业正在消耗自己的未来。
答案不是继续像以前那样招聘初级员工。而是维持一条小而精心的学徒轨道，并重新定义初级工作的样子。初级工程师应该审查 AI 输出，学习系统思维，两次构建东西——一次用 AI，一次不用 AI——这样他们实际上理解底层发生了什么。他们的 ramp-up 是学习系统和领域上下文，而不是记忆 AI 处理得更好的语法。
现在立即做什么
周一早上你实际做什么？以下是建议：
工作流程：
评估你的团队——不是按职称，而是按能力。谁能用 AI 倍增产出？谁有架构判断力？谁深入理解领域？谁能在多个领域工作？这告诉你谁在正确的座位上，谁需要移动
选一个舱作为试点进行重构——3-5 人，端到端拥有一个产品领域。给他们适当的 AI 工具、上下文工程和自主权。看看会发生什么。不要试图一次转型整个公司，但也不要太慢。从试点开始，快速学习，然后积极扩展
投资上下文工程——建立持久化上下文文件、架构文档、编码规范、规则文件。这是提高 AI 输出质量单杠杆最高的事情，而大多数团队根本没有做
开始衡量真正重要的东西——周期时间、变更失败率、每位工程师的收入。这些告诉你是否在变得更好。杀死不重要的指标。故事点、代码行数、提交数量。那些一直是虚荣指标，但现在更明显是虚荣指标了
没有人已经完全弄清楚。地形在每个人脚下都在移动。但现在开始的公司，即使不完美，也将比等待确定性的人领先 miles。
确定性不会来。适应或被抛在后面。
文档来源：AI Just Killed the Software Engineer (And Created Something Better)
本文由 AI 助手整理优化，欢迎关注、分享转载，请注明出处
