本文永久链接 – https://tonybai.com/2026/06/23/ai-divide-developers-into-lazy-juniors-and-the-burnedout-seniors

大家好，我是Tony Bai。

在铺天盖地的技术宣传中，我们每天都在听到关于 AI 如何实现“10倍速研发”、“干掉技术债”的宏大叙事。每个大厂的 CTO 都在兴奋地描绘着未来的降本增效蓝图，仿佛软件工程的黄金时代已经触手及极。

然而，在这场由算法和算力编织的盛世繁华背后，一个正在全球软件工程界悄然蔓延的“身份危机与心理崩溃潮”，正在被无情地掩盖。

近日，硅谷投资人、前 Google 工程师 Deedy Das 在 X 发布了一篇Post，撕开了大厂内部代码库正在腐烂的真相。

他的结论冷酷而残忍：由管理层激进推行的“代币最大化（Tokenmaxing）”和 AI 辅助，并没有消灭技术债，反而正在将研发团队割裂为两个截然对立的阶级——狂欢的“托管派(The Lazy )”与心碎崩溃的“代码守夜人(The craftsmen)”。

这篇推文在 X 上引发了大家的共鸣。无数程序员工程师下场，用自己正在经历的真实梦魇，拼凑出了 AI 时代最真实的系统性危机。

托管派的狂欢：“我根本不看代码，我只是它的搬运工”

在这场阶级分化中，第一类人被称为 “托管派（The Lazy / 捷径派）”。对于他们来说，AI 的爆发不是生产力的解放，而是一场完美的“带薪摸鱼”狂欢。

“这群人每天甚至不需要在电脑前呆满两个小时。”Deedy 描述道。

他们的工作流极其简单、机械且完全交由 AI 托管：

• 任务下发：看一眼 Jira 上的看板任务。
• 生成代码：把任务复制给 Claude，一键生成代码。
• 提交合并：不测试、不重构、甚至自己连看都不看一眼，直接发起 Pull Request（PR）。

当人类同僚或资深工程师在 PR 下方留言，质疑某段代码的逻辑漏洞时，他们的反应同样是“托管”的：

• 直接把同事的问题丢给 AI；
• 把 AI 的回答复制粘贴回去；
• 如果需要参加每日站会（Standup），没关系，让 AI 帮他们写一段听起来极其专业、忙碌且无懈可击的发言稿。

在这些“托管派”看来，软件工程早就不再是一门关乎设计和解决问题的“手艺”，而是一场通过操纵 AI、安全托管所有开发流程，向管理层证明自己“既聪明又努力”的舞蹈。

甚至，由于 AI 的极度高效，这群人中的聪明者开始行动起来——利用 AI 在三家公司同时挂职，拿着三份高薪，而背后的系统代码，全是由大模型堆砌起来的垃圾（Slop）。

守夜人的崩溃：被 20000 行“黑盒垃圾”淹没的系统工匠

在天平的另一端，是那些对代码品质有着近乎固执追求的 “系统手艺人（The Craftsmen / 守夜人）”。

这群人，如今正在经历职业生涯中最痛苦的“精神磨难”。

“守夜人”们极度疲惫。他们的 PR 队列里永远躺着 15 个甚至几十个等待评审（Review）的请求。

由于底层的“托管派”只管用 AI 生成代码，理解这些代码、并保证它们上线后不会把服务器搞崩的全部心智负担（Cognitive Overload），全部沉重地压在了这些守夜人的肩上。

他们经历着日复一日的“荒谬循环”：

1. 认真纠错：资深工程师花了一个小时，梳理清楚了某段 AI 代码的逻辑死角，写下一段详尽的重构建议。
2. 敷衍应付：底层的托管派收到建议，看都没看，直接转手丢给 AI：“我同事说这里有错，帮我改一下。”
3. 二次喂垃圾：AI 吐出了另一段依然带着微妙 Bug 的代码。托管派直接提交，并附带一句礼貌的废话：“你说得太对了！我已经按照你的建议改好了，求求你快合并吧！”
4. 循环往复：第二天，守夜人的邮箱里，又多出了一个由 AI 生成的、多达 20,000 行的庞大 PR。

“这简直是‘垃圾代码加农炮（Slop Cannons）’。”一位网友愤怒地评论道。

初级开发用 AI 疯狂开炮，管理层只看 LOC（代码行数）图表开心地数数，而资深工程师则在废墟里流血、流泪。

直到有一天，这些守护系统最后防线的手艺人终于看清了现实，他们不再坚持，不再分忧，选择闭上眼睛按下了合并键，放任系统走向腐烂。他们最终“杀死了”自己热爱的手艺，加入了全套托管的队伍。

唯指标论的代价：为什么“代币狂热（Tokenmaxing）”是万恶之源？

这场分裂的源头，往往来自于那些坐在办公室里、脱离一线开发的 CTO 和非技术经理。

这群人正在疯狂布道一种被称为 “代币最大化（Tokenmaxing）” 的指标：他们天真地以为，团队烧的 Token 越多，代码行数增长越快，就代表研发效率越高。

他们甚至引入了“AI 自动 Code Review 智能体”——让一个模型去评审另一个模型写的代码。

正如 一位X 网友的意图辛辣的嘲讽：

“让一个模型去审查它自己刚写完的代码，简直就是给一个‘只会敲键盘说 Yes’的应声虫发了一块键盘。它会给自己的作业打上 A+ 的高分，然后带着致命的 Bug，一路绿灯奔向生产环境。”

大企业（尤其是成立 10 年以上、人才密度参差不齐的官僚企业）往往有着极长、极迟钝的反馈链。管理层在看着“代码提交量翻倍”的精美 PPT 沾沾自喜，直到几个月后，系统在某个深夜毫无征兆地全盘崩溃，而所有人在面对那堆由 AI 堆砌出的几十万行“黑盒代码”时，面面相觑，无能为力。

消失的导师制：我们正在亲手消灭下一代优秀工程师

除了系统的脆弱，AI 原生分裂正在对软件工程的未来造成毁灭性的根基动摇——人类导师制（Mentorship）的消亡。

在传统软件工程中，一个新手走向资深，必须经历被资深工程师无情 Code Review、探讨方案设计、在痛苦的 Debug 中磨练系统直觉的过程。这是一个高频、有温度的“人际传递（Human Experience）”。

但现在，这个链条断裂了。

初级开发在遇到问题时，不再向身旁的资深同事请教，而是去向 Claude 索要一个当场能跑通、却不知道为什么能跑通的补丁。

“他们避开了所有通往‘深度理解系统’必经的痛苦，直接拿到了一个廉价的答案。”

这就导致了“技能萎缩（Skill Atrophy）”的发生。两三年后，当这群习惯了完全托管的 junior 程序员晋升为 senior 时，他们除了会写 Prompt 之外，根本不具备排查底层网络、多线程死锁、或者是内存泄露的能力。

“我们正在用廉价的快感，透支整整一代程序员的成长空间。”

小结：重建手艺人精神，夺回代码所有权

Deedy Das 的这篇推文，揭示了软件工业在狂热背后最真实的隐痛。

AI 确实是一个前所未有的强大生产力工具，但如果企业管理层继续推行无脑的“代币狂热（Tokenmaxing）”，如果开发人员继续沉迷于不带脑子的“托管开发”，那么我们正在迎来的，绝不是软件开发的黄金时代，而是一个由“黑盒屎山”构成的技术地狱。

程序员的成长，从来不是一场比拼“谁敲键盘更快、谁烧 Token 更多”的速度竞赛。

要想在这场分裂中不被平庸所吞噬，我们唯有重建“手艺人精神（Craftsmanship）”。

• 不要让 AI 替你思考；
• 不要提交任何你自己没有彻底读懂、没有亲手测试过的代码；
• 在 AI 吐出的漫天垃圾代码前，死守住属于你作为工程师的架构底线与职业尊严。

工具越强大，执笔之人的心智与品味就越关键。唯有夺回对代码的智力所有权，我们才能在这场算法的洪流中，立于不败之地。

资料链接：

• https://x.com/i/trending/2067934439586385964
• https://x.com/deedydas/status/2068238634600554699

今日开放讨论：

AI 确实极大降低了“落笔写代码”的物理门槛，但在“托管派（The Lazy）”与“守夜人（The Craftsmen）”严重撕裂的今天，我们也极度渴望听听你在一线最真实、不加粉饰的声音：

1. 在你的团队中，是否已经出现了这种两极分化？ 你是那个每天面对几十个由 AI 拼凑出的、长达数万行的 PR 而欲哭无泪的“心碎守夜人”，还是已经彻底看开、万物皆可一键托管的“托管派”？
2. 作为技术 Leader 或架构师，你认为应当如何建立“智能体时代的代码防线”？ 我们该如何制定规则，才能阻止初级开发用“AI 垃圾代码大炮（Slop Cannons）”把生产系统彻底击垮？
3. 你赞同“编程作为一门手艺（Craft）已经死去了”这一悲观论调吗？

欢迎在评论区留下你的吐槽。也请把这篇文章一键分享给身边的“守夜人”同事，今天，我们一起在评论区抱团取暖！

还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：

• 告别低效，重塑开发范式
• 驾驭AI Agent(Claude Code)，实现工作流自动化
• 从“AI使用者”进化为规范驱动开发的“工作流指挥家”

扫描下方二维码，开启你的AI原生开发之旅。

原「Gopher部落」已重装升级为「Go & AI 精进营」知识星球，快来加入星球，开启你的技术跃迁之旅吧！

我们致力于打造一个高品质的 Go 语言深度学习 与 AI 应用探索 平台。在这里，你将获得：

• 体系化 Go 核心进阶内容: 深入「Go原理课」、「Go进阶课」、「Go避坑课」等独家深度专栏，夯实你的 Go 内功。
• 前沿 Go+AI 实战赋能: 紧跟时代步伐，学习「Go+AI应用实战」、「Agent开发实战课」、「Agentic软件工程课」、「Claude Code开发工作流实战课」、「OpenClaw实战分享」等，掌握 AI 时代新技能。
• 星主 Tony Bai 亲自答疑: 遇到难题？星主第一时间为你深度解析，扫清学习障碍。
• 高活跃 Gopher 交流圈: 与众多优秀 Gopher 分享心得、讨论技术，碰撞思想火花。
• 独家资源与内容首发: 技术文章、课程更新、精选资源，第一时间触达。

衷心希望「Go & AI 精进营」能成为你学习、进步、交流的港湾。让我们在此相聚，享受技术精进的快乐！欢迎你的加入！

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。

本文永久链接 – https://tonybai.com/2026/06/22/why-is-go-dominating-in-cncf-landscape

大家好，我是Tony Bai。

如果你去翻阅 CNCF（云原生计算基金会）的全景图（Landscape），你会发现一个极其震撼、甚至近乎垄断的现象：

从奠定容器时代基础的 Docker，到统治现代云编排的 Kubernetes；从服务网格的 Istio，到监控标准的 Prometheus；再到分布式协调的 Etcd、包管理器的 Helm、持续交付的 ArgoCD……

在这个代表着人类最先进分布式系统和云基础设施的宇宙中，：从基础设施到服务网格，Go 语言几乎构建了现代云计算的一切底座，几乎 90% 以上的核心项目都是用 Go 语言编写的。

Go 语言，在日常开发中经常被吐槽“语法简陋”、“缺少表达力”、“GC（垃圾回收）性能不如手动管理”，但它却在云原生这一含金量最高、对并发和高可用要求最严苛的黄金领域，达成了近乎绝对的统治。

最近，在 Reddit 的 r/golang 讨论区，一个帖子激起了千层浪：为什么 Go 能在 CNCF 生态中称霸？（Why is Go dominating in CNCF landscape?!）。

海外大厂的架构师、K8s 核心贡献者和分布式系统老兵们纷纷下场，用工程视角，层层剥开了 Go 语言在云原生时代“天命上位”的底层逻辑。今天，我们就来深度拆解这场技术演进的偶然与必然。

历史的引力：从 Google 内部的 Borg 到 K8s 的 Go 语言重写

探讨 Go 的统治地位，不能脱离历史的语境。

Reddit 的一位开发者指出：“Google 创造了项目 Borg（Kubernetes 的前身）和 Go 语言，这绝非巧合。CNCF 的大厦就是建立在这个强大的基因组合之上的。”

1. Borg 的遗产与 K8s 的诞生：Google 内部运行了十几年的 Borg 系统是用 C++ 编写的。当 Google 决定向社区贡献开源的 Kubernetes 时，他们最早曾尝试用 Java，但由于 JVM 的沉重和复杂性，很快就放弃了。当时，Google 内部刚刚孵化成熟的 Go 语言，由于其极高的高并发支持和简洁性，成为了重写 K8s 的天选之子。
2. Docker 的惊人抉择：2013 年，Solomon Hykes 创立 Docker。当时他需要一门语言来快速构建一个轻量级的、能方便打包并分发的命令行工具。Go 编译出来的单一无依赖静态二进制文件，完美契合了 Docker 的这一诉求。

在系统工程中，生态的“地心引力”是一旦形成就无法阻挡的。

当 Docker 和 Kubernetes 这两个云原生宇宙的“太阳”都决定用 Go 编写时，周围的所有卫星项目（如 Etcd、Prometheus、Helm）为了能与 K8s 的底层 runtime、Client 库和 API 完美契合、无缝通信，就只能义无反顾地选择 Go。Go 语言的生态引力，在云原生早期完成了史诗级的“坍缩”。

黄金分割点：为什么 Go 是基础设施的“完美妥协”？

但是，仅仅靠历史机遇是不够的。云原生系统对算力有着极致的要求，为什么在后续的发展中，性能更好的 C++、Rust，以及生态极其庞大的 Java，都没能抢走 Go 的王座？

因为在真实的大厂运维场景下，Go 站在了系统性能与开发效率（Devex）的完美黄金分割点上。

我们可以通过与其他三大语言的对比，来看清 Go 的“降维打击”：

1. Go vs Java/C#：“128MB 内存容器”的算力账单

在 Kubernetes 编排的微服务架构中，一个物理节点上可能要挤上百个小型的 Sidecar（如 service mesh 代理、监控 exporter、日志搜集器）。
* Java/C# 的噩梦：JVM 或 CLR 运行时极其沉重。一个最简单的 Java Daemon 进程，刚刚启动什么都没干，往往就要吃掉 200MB 以上的内存。如果每个 Pod 旁边都挂一个 200MB 的 Sidecar，整台服务器的内存在瞬间就会被空转的垃圾回收引擎榨干。
* Go 的轻量红利：Go 编译出来的容器，运行内存常常可以轻松控制在 128MB 以内甚至只有十几兆。Go 极低的运行时开销，让企业在大规模部署微服务时，能够省下数以百万美元的硬件开销。

2. Go vs Python/JS：“单一静态二进制”的部署神话

部署一个 Python 或 Node.js 应用，是每一个运维（Ops）人员的噩梦：你需要折腾 pip、npm、虚拟环境、复杂的动态依赖库，以及随时可能崩溃的系统依赖。

而在 Go 中，通过简单的：

bash
CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build

你就能得到一个完全不依赖系统任何动态链接库的、孤立的静态二进制文件。你可以把它直接丢进一个最干净的 scratch 镜像里，容器体积只有十几兆。这种“Drag-and-Drop”式的极致部署体验，奠定了现代容器镜像（Container Image）轻量化的技术标准。

3. Go vs C/C++：内存安全的降维打击

C/C++ 是极致的高性能，但也是“极致的危险”。在网络高并发的云原生底座中，C/C++ 的手动内存管理极易暴露出内存溢出、野指针等安全漏洞（Security Vulnerabilities）。

况且，C/C++ 至今没有一个标准的官方包管理器（Package Manager）。你要怎么在 K8s 里管理成千上万个复杂的第三方网络库？Go 的标准库“自带电池（Batteries included）”且内存安全，直接帮开发者屏蔽了这一万丈深渊。

4. Go vs Rust：“认知负载（Cognitive Load）”与开源效率

Rust 拥有极致的性能和绝对的内存安全。但正如 Reddit 上的资深开发者所指出：“Kubernetes 如果用 Rust 编写，它绝对无法拥有今天这样繁荣的开源生态。”

Rust 的借用检查器（Borrow Checker）和复杂的生命周期理论，给普通开发者筑起了极高的心智壁垒。

而 Go 是出了名的“简单、枯燥、无聊（Boring）”。Go 只有 25 个关键字，任何一个普通的后端程序员，花上几天时间就能上手写出及格的 Go 代码。

这种极低的参与门槛，让全球成千上万的开发者能够无痛地参与到 Kubernetes、Prometheus 的开源贡献中，造就了 CNCF 生态无与伦比的繁荣。

揭秘 Go 的三大“开挂级”工程特质

除了定位优势，Go 标准库和语言特性的设计，仿佛就是为了云原生时代“量身定制”的：

• 开箱即用的跨平台编译（Cross-compilation）：

在 macOS 上，你只需要一行命令：GOOS=linux GOARCH=mipsle go build，就能完美编译出一个可以在家用路由器上直接跑的 MIPS 架构二进制，中间不需要安装任何跨平台交叉编译器。这种体验在其他语言中完全是不可想象的天方夜谭。

• GMP 并发模型与协程：

云原生底座（如 Etcd, Istio）本质上是大量的网络 I/O 密集型应用。Go 的 Goroutines 能够以极低的代价处理数以万计的并发网络连接，其内置的 Channel 让并发状态的同步变得极其符合直觉。

• 强悍的向后兼容性（Backward Compatibility）：

Go 官方有着近乎固执的兼容性承诺：你在 2012 年写好的 Go 1.0 代码，直接用今天最新的 Go 1.26 编译器，依然能够一行不改地直接编译成功。对于需要维护十年、八年以上的 CNCF 核心基础设施来说，这种“不折腾”的确定性，是建立企业级信任的基石。

小结

CNCF 宇宙对 Go 语言的选择，并不是一时的技术风潮，而是软件工程学、经济学、以及开源生态演进规律共同作用下的必然结果。

在云原生世界里，Go 用它那看似“枯燥”、“不完美”的设计，完美践行了工程学上的 “Worse is Better（做更少，得更多）” 哲学。它在性能、开发效率、运维成本和社区活跃度之间，找到了那个最完美的平衡点。

只要我们还在使用容器，只要我们还在运行 Kubernetes，Go 语言在云端长达十年的统治地位，就依然坚不可摧。

资料链接：https://www.reddit.com/r/golang/comments/1u3v83g/why_is_go_dominating_in_cncf_landscape/

今日开放讨论：

你认为未来诸如 Zig、Carbon 或是 Rust 这类新兴的系统语言，有没有可能在某些特定的云原生细分领域（如服务网格的 Proxy 节点或高频冷启动 Serverless）彻底取代 Go？在你的技术选型中，开发效率（Devex）和极致性能（Performance）哪个拥有更高的优先级？

欢迎在评论区留下你对“云原生技术栈演进”的独特看法，我们一起探讨 AI 时代的系统级编程！

还在为写 Agent 框架频频死循环、上下文爆炸而束手无策？我的新专栏 《从0 开始构建 Agent Harness》 将带你：

• 抛弃臃肿框架，回归“驾驭工程 (Harness Engineering)”的第一性原理
• 用 Go 语言手写 ReAct 循环、并发拦截与上下文压缩引擎等，复刻极简OpenClaw
• 构建坚不可摧的 Safety Middleware 与飞书人工审批防线
• 在底层实现 Token 成本审计、链路追踪与自动化跑分评估
• 从“调包侠”进化为掌控大模型边界的“AI 操作系统架构师”

扫描下方二维码，开启从 0 开始构建Agent Harness 的实战之旅。

原「Gopher部落」已重装升级为「Go & AI 精进营」知识星球，快来加入星球，开启你的技术跃迁之旅吧！

我们致力于打造一个高品质的 Go 语言深度学习 与 AI 应用探索 平台。在这里，你将获得：

• 体系化 Go 核心进阶内容: 深入「Go原理课」、「Go进阶课」、「Go避坑课」等独家深度专栏，夯实你的 Go 内功。
• 前沿 Go+AI 实战赋能: 紧跟时代步伐，学习「Go+AI应用实战」、「Agent开发实战课」、「Agentic软件工程课」、「Claude Code开发工作流实战课」、「OpenClaw实战分享」等，掌握 AI 时代新技能。
• 星主 Tony Bai 亲自答疑: 遇到难题？星主第一时间为你深度解析，扫清学习障碍。
• 高活跃 Gopher 交流圈: 与众多优秀 Gopher 分享心得、讨论技术，碰撞思想火花。
• 独家资源与内容首发: 技术文章、课程更新、精选资源，第一时间触达。

衷心希望「Go & AI 精进营」能成为你学习、进步、交流的港湾。让我们在此相聚，享受技术精进的快乐！欢迎你的加入！

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。