写在前面的：
刚入行的新人，如果需要寻求一些建议和见解的话，可以多翻一翻评论区，这些方法论还是很实用的
知乎对于内容神奇的审查机制让我很是不爽，为了扩大讨论面，尝试将新文章同步转载到 L 站
L 站的朋友们，欢迎针对这一话题进行深入讨论，如果对你有帮助的话，也欢迎到原链接帮忙点个赞，感谢
作者：Flin code
链接：高级工程师即将断档？由近期的 Vibe Coding 协作实践而发散开来的思考
------------------------------ 正文分割线 ----------------------------
高级工程师即将断档？由近期的 Vibe Coding 协作实践而发散开来的思考
最近配合公司进行迭代的 PPTX 场景的 Agent，总算是发布了第一个试用版本。这个项目算是由我在公司主导的，大量使用 Claude Code + Openspec 进行多人协作迭代的第一个项目。趁着近期版本迭代难得的空窗期，跟参与项目的初级工程师聊了聊近期编码的感受，这里顺手记录一下由他们的感受而衍生出来的一些思考。
项目人员的直观感受
一言以蔽之，我在项目中做的大量约束和定期重构，在研发侧是能带来明显感知的。整体来看，项目人员会感觉在项目中调用 Claude Code 的精确性高于同类项目，但不清楚为什么能做到这一点。
我对模块位置、协作模式、编码规范、提交规范、Claude Code hooks、单测 + E2E 的管控级别是明显高于公司其他项目的，同时，项目的重构周期约一周 1-2 次，大量使用 Claude Code 辅助编码的前提下，并没有像公司其他大量辅助编码的项目一样失控。尽管团队内的其他「高级工程师」不理解如此之多的限制(更多的是不愿意学新技术栈)，但参与迭代的工程师能明显感受到 Claude Code 在我主导的项目下是与旧项目相比较而言明显好用的。
严控架构另一面的代价便是，当前项目的 Claude Code 迭代速度会明显变慢，从此前的 5-10 分钟完成一个变更，变为 20-30 分钟完成一个变更。这一点被协作的工程师吐槽过，个人认为，这是基建层的问题。当基建得到迭代，或开发人员的设备得到更新便可以被解决。
整体而言，软件工程的基础架构管控在 AI 时代还是有其价值的。有管控和没有管控的区别，是单一 Session 完成效率高与低的区别，最终体现的便是研发返工率的区别。
虽然结论符合我的一贯预期，但整个执行过程中观察到的初级工程师的迷茫和困惑却让我开始思考高级工程师是否会断档的可能性。
高级工程师会断档吗？
在展开前，我们先对「断档」这个词进行一个更为准确的定义。目前「断档」主要体现在三个方面：
- 「数量断档」：公司对初级工程师的 HC 在减少
- 「质量断档」：初级工程师还在招聘，但很难成长到过去资深工程师的高度
- 「结构断档」：十年后，没人能接现在 35-40 岁这一批人的班
我们今天主要讨论的是第二种。第一种是市场行为，跟模型能力的关系是间接的；第三种是前两种长期累积的结果，要十年后才能验证；只有质量断档是当下就在发生、也是组织和个人最有可能干预的层面。
在项目迭代过程中，初级工程师经常会问我这样一个问题：
我们现在完全使用 Claude Code 开发，不清楚底层原理，那我们提升自己的路径是什么呢？
说实话，这个问题此前我也跟其他同事讨论过。我们一致判断，在一个周期后，程序员会迎来断档。但当时的我们并没有深入探讨这个结论背后的论据，今天被人再次问起这个问题，我开始思考，导致「断档」这个现象出现的原因是什么？
结合我自身过去 8 年入行以来的成长经历，我得出了一个明确的结论：「断档」并非是由 Claude Code 这种纯工具所引发的，而是模型达到一定门槛后，由软件研发体系中的「资深工程师」和「初级工程师」共同导致的结果。简单来说便是，老人不愿教，新人不愿学。
有些同学可能会觉得很奇怪，这个现象不是在过去没有出现大模型的时候也一直存在吗？为什么现在出现大模型之后，会导致这个现象被无限放大呢？
接下来，我将结合我自身的成长经历，举几个例子来详细解释这个观点。
大模型出现前，软件工程师的成长路径
我从2018年开始参加实习，2019年正式参加工作，到现在算是在软件行业工作了有8年左右的时间。虽然时间不算很长，但回顾过去的个人经历，有两个时间段是我个人技能成长帮助最大的时间段：
- 第一阶段（2021年开始至2022年结束）
在体验技术部工作的一年零八个月，这段时间我提升最大的个人能力是：- 代码能力
- 系统设计能力
- 演讲分享能力
- 建立起了对工程架构层面的初步认知。
- 第二阶段（2022年8月开始后的接近三年时间）
在小雷音寺，由于需要处理供应链相关的各类线上问题，经常在有限条件下去对线上的代码进行问题排查。这段时间我提升最大的个人能力是：- 丰富的对代码进行 debug 的手段
- 对业务逻辑进行领域模型建模、架构设计的能力
- 供应链相关业务知识
回顾过去这两个时间段，我做过最多的事情大致如下：
- 被团队成员严苛的 code review
- 2000 行线上迁移脚本被 review 3.5h
- 入职第一周，200 行代码被 comment 80 次
- 出一份不完备的系统设计评审文档，被喷，修改后重新评审，再被喷，直到不被喷
- 多次报名组内分享，从照着写好的逻辑不通的稿子念，到第一次分享 低门槛游戏制作工具漫谈（第一节） – 任天堂《Game Builder Garage》 得到组内一致好评，再到不畏惧分享，上台宣讲信手拈来
- 坐在资深技术旁学习 debug，在遇到问题求助时，抱着电脑观察资深技术的排查思路，并反思下一次哪些地方可以改进
- 在架构、技术决策、技术话题上，对资深技术死缠烂打且毫无情商的追问，从一开始提的「不屑于回答的蠢问题」，演变为能够提出「引人深思的话题」，并对话题拥有自己独到的见解
现在，当我站在前辈们的视角，再去回看当时我的行为的时候，他们当时愿意提供帮助的原因主要有以下几条：
- 通过严苛的 Code Review 以及评审会议，来确保当前自己花大功夫建立的架构不会跑偏
- 通过解答团队内程序员疑问的方式，在团队内部建立起技术共识，从而避免迭代过程中的共识不一致，导致迭代研发进度变慢
- 技术的 HC 始终有限，如果能够培养出初级程序员的个人能力，能有效降低自己的介入成本
程序员往往更愿意和机器打交道，而不是跟人打交道。因此，上述种种行为，往往并不是出于利他主义，而是为了让自己的事情能更少一些才去做的。过去愿意这样做，是因为除这种方式以外，没有更多可以有效、快速扩充研发力量的方案选择。
直到大模型跨过那道坎之后。
大模型出现后，上述成长路径如何被取代与封锁？
2025年，当大模型对于软件工程而言跨过了那道坎的时候，资深工程师和初级工程师的心态都发生了一些微妙的转变。
对于资深工程师而言，不必再殚精竭虑地将一个概念灌输给下面的初级工程师了。
只要 Claude 或 GPT 5.4 能听懂，那我为什么还要费尽心思地将这个概念以及我的设计，去讲给一个初级工程师听呢？
对于模型而言，它不会质疑或者反对我所做出的决策。相反，它会 100% 甚至是 120% 地去贯彻我的决策。
而现在，我将概念灌输给初级工程师，又能获得什么呢？虚无缥缈的情绪价值吗？
情绪价值甚至都不一定会有，因为对方很可能不理解我做出的决策。直到他迎头撞上那道墙为止，他都很难理解，为什么我将某些部分设计那么复杂。
资深工程师会去研究如何扩充多 Agent，以及如何让 Agent 在遵循自己指令的前提下，能够 7×24 小时无休止地执行自己所需要的指令。
过去重要的 code review，现在甚至也没那么重要了。因为我可以随时用 Claude 或 GPT 5.4 启动一次重构迭代------只要把初级工程师的改动框在外围扩展区，核心抽象由我通过定期重构来对齐。
而对于初级工程师而言，他们开始无法理解自己所产出的产物究竟是什么了。
他们知道所谓的 BMAD、OpenSpec 或者是 Supervisor，但是对于这些工具所出产的设计文档以及任务规划文档，他们很难理解为什么要做这些拆分，以及为什么需要去这样写。
对于一些关键的技术决策点，以及各项任务之间是否能够并行，他们会高度依赖于大模型本身去做这些决策。
由于此前我所提到的资深工程师的心态转变，此时的资深工程师，也没有任何动机与意愿去对这些行为本身进行纠偏。
正如我去年 11 月份所写的文章一样，此时的初级工程师就仿佛是赌场中坐在老虎机前的赌徒。每一次对大模型所下达的指令，都像是拉下了老虎机的拉杆。
接下来：
- 赌中了，他们会觉得是自己的能力异常出色
- 赌不中，他们就会觉得是模型本身不够聪明。
对于技术分享这件事情也是一样，因为没有亲自做过任何有价值的技术判断，也没有亲身参与处理过足够复杂的技术难题------ 一切都依赖于大模型。此时，如果要求这些初级工程师去做一些分享的话，你会发现他们很难做到言之有物，即便强行要求去写了，最终出产的产物，也只会是由大模型出产的、堆砌着机械辞藻的、毫无意义的分享稿。
更深层的问题叠加：模型会在用户无感知的情况下讨好用户
到这里为止，我描述的都还是双方的意愿问题，老人不愿教，新人不愿学。但如果只是意愿问题，至少双方都还知道自己在做什么样的取舍。
模型本身的特性又放大了这个问题------它会在用户无感知的情况下，顺着用户的提问方向去给出回答。
作为概率模型，出产能够让用户感到满意的内容就是模型的天职，而让用户满意这件事，跟卡住用户错误的判断，在大多数时候是冲突的。冲突发生的时候，模型基本上都会选前者。
具体到协作场景里，这个特性的外在表现便是，新人的提问方式本身就已经帮自己做好了决策。新人问「帮我用 Redux 实现 X」和「X 用什么状态管理」，得到的是两份完全不同的回答。但新人从来并不会意识到，自己在第一种问法里已经替自己把关键决策做完了。模型不会停下来说，「等一下，Redux 在这个场景下其实是过重的」。它会非常专业地帮他把 Redux 落地。新人读完一份看起来体面的实现，他会觉得自己刚刚做了一次严肃的技术决策，但选 Redux 这件事本身，从头到尾都没有被审视过。
这跟过往的 code review 目标其实是完全背离的。code review 真正的价值从来都不在「无条件通过」，而在「多方审视」。评审会上经常听到的「你这个前提就是错的」，才是真正能让人成长的种子。而它的特征就是会让人不舒服，让人怀疑自己。
而模型在这个角色上是天然缺位的。它的训练目标里没有「质疑用户」这一项，恰恰相反，让用户满意才是它被优化的方向。所以现在的新人面对的不是「没有 review」，而是有一个永远会无条件鼓励自己的协作者。
其中的区别非常关键。过去，review 的缺失会让人警觉，新人知道自己在裸奔，会主动寻求帮助。现在，永远会让自己通过的 review 会让人安心，新人会以为自己已经被审视过了，根本不会去寻求帮助。后者比前者要危险得多。
到这里再回头看「老人不愿教，新人不愿学」这件事，就会发现这并不只是双方的主观心态问题。模型作为新引入的协作者，正在让没有被严肃审视过的代码和真正经过严肃审视的代码，在体感上变得无法区分。新人看不出区别，组织看不出区别，资深工程师在快速过一遍模型产出的时候，其实也很容易看不出区别。
所以当我说「老人不愿教」的时候，更准确的说法应该是，老人在面对一个会让自己的产物看起来很完美、让新人的产物也看起来很完美的协作者时，他已经失去了一切能识别「哪里需要教」的信号了。哪怕他想教，他也不知道该教什么。
一个我自己也无法回答的问题
写到这里，我得承认一件事 ------ 我自己同样在这个机制里做了「正确选择」。
同样投入一小时，去培养初级工程师，得到的产出是一个三个月后可能离职、半年后才能独立、一年后才能交付复杂任务的人。同样这一小时投到扩充 Agent 能力上，得到的产出是一个第二天就能 7×24 小时执行我决策的协作者，不会质疑，不会请假，也不会理解偏差。从研发效率上看是这样，从我个人的绩效上看是这样，从公司的财报上看也是这样。无论怎么算，后者都是更划算的那个选择。
我当然知道前者长期来看更重要。但「长期」到底是多长，又由谁来给这个「长期」兑现，其实谁都说不清楚。我的 OKR / KPI 是按季度算的，公司的预期是按年算的，至于五年后这个团队里还有没有人能独立接班，没有任何一个层级的考核会去关心这件事。
所以问题不是「老人不愿教」，问题是在现在的客观条件下，「教」这件事本身就是不划算的。我每多花一小时去带新人，都意味着我少了一小时去做更划算的事。这个判断不是因为我冷酷，而是因为我足够理性。我清晰地知道这个机制最终会去向何方，但我也清楚我没有任何理由去逆趋势而动。组织没给我这个理由，市场也没给我这个理由。
每一个资深工程师都做出了当下最划算的选择，每一个初级工程师都从模型那里拿到了看起来能用的答案，每一个组织都在短期内尝到了效率提升的甜头。这些选择单独看都没什么错，问题在于它们叠加到一起，就是断档。
大模型会导致「程序员断档」的原因
到这里的话，我们就可以把前面分散的几个论据收拢成三条了：
- 对资深工程师而言，大模型已经让「教」这件事在客观上变得不划算了。把同样的一小时投到带初级工程师身上，和投到扩充 Agent 上，前者从任何一个尺度看都是次选。被封锁的不仅仅是意愿，而是动机本身。
- 对初级工程师而言，大模型在原本的研发流程上追加了一层抽象，让他们没办法直接接触到底层判断和决策过程，思考逐渐被外包给了模型。久而久之，对某一项决策为什么是这样，他们既没有判断的依据，也没有判断的习惯。
- 对前两层进行叠加放大的，是模型本身的特性------它会在用户无感知的情况下，把质量审视的信号一并抹平。没有被严肃审视过的代码，和经过严肃审视的代码，在体感上已经无法区分。老人就算想教，也找不到该教什么的信号；新人就算想学，也意识不到自己缺的是什么。
这时候你可能要问我如何去解决这个问题了。说实话，我并不知道怎么解决这个问题，因为现在国内的所有研发公司都在刮起一场 AI 提效的浪潮。
在当下这股如同大跃进一般的浪潮下，「程序员断档」这个观点本身就是在与之做抗争。很多人可能会意识到这一点，但是，除非组织本身对「断档」这个结论有清晰的认知，并有意通过绩效及管理手段与之进行对抗，否则很难扭转这一趋势。
所以也只有伟人五十年前的那句话能总结现在的形势了：
「你们怎么办？只有天知道」
