2026-01-07 12:20:33
本文永久链接 – https://tonybai.com/2026/01/07/stop-vibe-coding-professional-developers-master-coding-agent-2025
大家好，我是Tony Bai。
在社交媒体上，我们经常看到这样的神话：“我用 AI Agent，只凭感觉（Vibe）就写出了整个应用，甚至不需要看代码。” 这种被称为“Vibe Coding”的现象真的代表了专业开发的未来吗？
近日，来自 UCSD 和康奈尔大学的研究团队发表了一篇题为《Professional Software Developers Don’t Vibe, They Control: AI Agent Use for Coding in 2025》的论文。通过对 13 位资深开发者的实地观察和 99 份详细调查，他们揭示了一个截然不同的真相：专业开发者并不“Vibe”，他们严密“控制”。
研究发现，经验丰富的开发者（平均 12.8 年经验）虽然高度认可 AI Agent（如 Cursor, Claude Code, GitHub Copilot）带来的生产力提升，但他们拒绝交出方向盘。
与“Vibe Coding”所倡导的“完全信任 AI、不看代码、只管运行”不同，专业开发者采取了一种战略性的控制（Strategic Control）模式：
论文通过大量数据，梳理出了 AI Agent在当前技术水平下的“能力边界”。这对于我们日常决定“何时使用 AI”极具参考价值。
这些任务被认为是高收益、低风险的：
对于以下任务，开发者普遍表示 AI “不胜任”或“风险过高”：
* 核心业务逻辑：涉及复杂领域知识、特定业务规则的代码。
* 复杂重构：跨越多个文件、涉及架构调整的大规模重构。
* 系统设计与决策：没有人愿意将技术选型或架构决策交给 AI，虽然可以用它来头脑风暴，但决策权始终在人。
* 安全关键代码：涉及支付、鉴权等高风险模块。
* “一步到位”的完美代码：AI 几乎从未在第一次尝试中就生成完美无缺的代码，必须经过多轮迭代。
研究中最有趣的部分是观察资深开发者如何写 Prompt。他们不是在“聊天”，而是在“编程” AI。
高效 Prompt 的特征：
这篇论文给 2025 年乃至如今的开发者们吃了一颗定心丸：AI 不会取代你，但会“增强”你——前提是你懂得如何控制它。
真正的专业人士不会沉迷于“Vibe Coding”的虚幻快感。相反，他们利用深厚的软件工程积淀（测试、版本控制、代码审查能力）来驾驭 AI，将其变成一个不知疲倦的结对编程伙伴。正如一位受访者所言：
“我觉得 AI Agent棒极了，只要你坐在驾驶位上，并且时刻检查它的工作。一旦你不强制它遵守那些确立已久的工程原则，它就会变成灾难。”
论文链接：https://arxiv.org/abs/2512.14012
你的 AI 协作模式是？
读完这篇论文解读，我不禁想问大家：在你日常的开发中，你是更倾向于“Vibe Coding”（跟着感觉走），还是像文中提到的资深开发者那样，时刻保持着“战略性控制”？
欢迎在评论区分享你的 AI 协作心得或踩坑经历！ 让我们一起探索人机协作的最佳边界。
如果这篇文章让你对 AI 编程有了更清醒的认识，别忘了点个【赞】和【在看】，并分享给你的团队！
升级你的AI开发工作流
文中提到的“伪代码思维”、“维护 CLAUDE.md 上下文文件”、“分步拆解任务”，正是规范驱动开发 (SDD) 的核心思想。如果你不想止步于简单的对话，而是渴望掌握一套成体系的、工程化的 AI Agent 协作方法论，让 AI 真正成为你可控的“超级副驾驶”…
那么，我的专栏 《AI原生开发工作流实战》 就是为你量身打造的！
在这个专栏里，我们将深入实战：
扫描下方二维码，拒绝“Vibe”，拥抱“Control”，开启你的 AI 原生工程开发之旅！
你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？
继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！
我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。
目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！
商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。
© 2026, bigwhite. 版权所有.
2026-01-07 08:16:00
本文永久链接 – https://tonybai.com/2026/01/07/go-language-comfort-zone-in-contempt-chain-pyramid
大家好，我是Tony Bai。
最近，一张“编程语言分级图”在技术社区引发大家热议。它没有参考 TIOBE 排名，也不看 GitHub Star 数，而是完全基于一种简单粗暴的价值观：谁最不折腾人？
在这张金字塔中，C 语言高居神坛（The one and only），而 Java、Python、C++ 被踩在最底层的“憎恶（Abomination）”泥潭里。甚至连备受推崇的 Rust，也被归入了“彻底失败（Total failure）”。
** Go 语言则稳稳地站在了 T1 梯队——“No nonsense（拒绝废话）”。**
这张图看似偏激，却也道出了一些资深开发者的心声。它揭示了 Go 语言最大的魅力：在混沌的软件工程世界里，Go 为我们圈出了一块难得的“舒适区”。
这张图从上到下，宛如但丁的《神曲》，描绘了从天堂到地狱的编程世界观。meme图的作者显然是一位厌恶抽象、崇尚掌控机器、鄙视过度设计的硬核程序员。让我们逐层拆解：
塔尖：The one and only（唯一的真神）
T1 梯队：No nonsense（拒绝废话 / 实干家）
T2 梯队：Meme languages（网红/小众神教）
T3 梯队：Necessary evil（必要之恶）
T4 梯队：Total failure（彻底失败 / 认知灾难）
底层：Abomination（憎恶 / 不可名状之物）
在这张图中，C 是唯一的“神”。为什么？因为 C 诚实。它与机器直接对话，没有中间商赚差价。但 C 也是危险的，内存泄漏和野指针是每个 C 程序员的噩梦。
Go 为什么紧随其后？
因为 Go 完美地继承了 C 的“诚实”，同时补上了“安全”的短板。
在“No nonsense”这一层，Go 与 Lua（极简脚本）、ASM（汇编）并列。这说明在作者眼中，Go 的本质不是“简化的 Java”，而是“现代化的 C”。
Go 处于这个位置，是因为它保留了 C 的掌控感，同时剔除了 C 的恐惧感（内存泄漏、野指针）。
再往下看，最底层的“Abomination”包含了 C++、Java、Python 等工业界巨头。这并非说它们不能干活，而是说用它们干活“很不舒服”。
在这个“极简主义”的评价体系里，这些语言代表了“过度设计”的极端：
Go 的舒适区，建立在对这种“复杂性”的拒绝之上。 在 Go 里，你不需要画 UML 图，不需要背诵设计模式，你只需要关注：数据怎么流，逻辑怎么走。
这是最引发争议的一点。Rust 被归为“Total failure”。这显然不是指 Rust 的技术失败，而是指它违背了“No nonsense”的初衷。
Rust 为了追求内存安全和零成本抽象，引入了极高的认知成本（生命周期、借用检查）。这导致写 Rust 代码时，开发者往往在与编译器搏斗，而不是在解决业务问题。
Go 的舒适，是一种“妥协的艺术”。
Go 承认：与其让人脑去计算每一个变量的生命周期（Rust 的做法），不如让 CPU 多跑几毫秒来做 GC（Go 的做法）。
在这个算力过剩而人脑算力稀缺的时代，Go 选择了让人舒服，而不是让机器舒服。
这张图之所以能引起共鸣，是因为它精准地击中了现代软件工程的痛点：我们花了太多时间在对付语言特性、框架和工具链，却忘了我们最初只是想写程序解决问题。
Go 语言处于 No nonsense 这一层，恰恰证明了它的核心价值：
它不追求“纯粹”的完美（像 Haskell），也不追求“极致”的性能（像 Rust），更不追求“大而全”的框架（像 Java）。
Go 只是想让你舒服地、直白地、没有废话地，把代码写出来，然后按时下班。
在当今这个充满焦虑的技术世界里，这难道不是最顶级的“舒适区”吗？^_^
你的“鄙视链”排位
这张图虽然偏激，但确实代表了一些人心中的极简主义的审美。在你心中的编程语言金字塔里，谁是那个“唯一的真神”？谁又是让你痛苦不堪的“不可名状之物”？你认同把 Rust 放在“彻底失败”这一层吗？
欢迎在评论区晒出你的“私房排位表”，或者为你的本命语言辩护！ (请文明交流，勿伤和气~ )
如果这篇文章戳中了你的笑点或痛点，别忘了点个【赞】和【在看】，看看你的朋友圈里有多少“极简主义者”！
还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：
扫描下方二维码，开启你的AI原生开发之旅。
你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？
继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！
我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。
目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！
商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。
© 2026, bigwhite. 版权所有.
2026-01-06 12:15:30
本文永久链接 – https://tonybai.com/2026/01/06/go-sum-is-not-a-lockfile
大家好，我是Tony Bai。
“我需要大家停止查看 go.sum，尤其是别用它来分析依赖图。它不是一个‘锁文件 (lockfile)’，它对版本解析没有任何语义影响。实际上，你根本没有理由去解析它。”
—— Filippo Valsorda, 前 Go 安全团队负责人
在很多其他编程语言的生态中，开发者习惯了“清单文件 (Manifest)”与“锁文件 (Lockfile)”的二元对立（如 package.json vs package-lock.json，Cargo.toml vs Cargo.lock）。这种思维定势很容易让我们误以为 Go 中的 go.sum 就是那个负责锁定版本的 Lockfile。
然而，前Go安全团队负责人Filippo Valsorda 在他最新的文章中大声疾呼：这是一个巨大的误解。
简单来说，go.sum 只是 Go 校验和数据库 (Checksum Database) 的一个本地缓存。
如果你在试图分析项目的依赖关系、排查版本冲突，或者理解构建过程，请忽略 go.sum。它给不了你想要的答案。
在 Go 的设计中，go.mod 承担了其他语言中 Manifest 和 Lockfile 的双重角色，甚至更多。
Filippo 指出，Go 模块系统的设计在简洁性上被大大低估了。与其他生态系统相比，Go 实现了令人惊叹的特性：
下次当你想要了解项目的依赖结构时，请直接查看 go.mod。
或者，使用更专业的工具：
至于 go.sum？就让它静静地呆在那里，做它该做的事——默默守护你的供应链安全，仅此而已。
资料链接：https://words.filippo.io/gosum/
你的 go.sum 烦恼
虽然 go.sum 只是个校验和缓存，但在多人协作中，它依然是冲突的高发区。你在合并代码时，是否也曾被 go.sum 的冲突搞得头大？你现在的团队是如何处理这些冲突的？
欢迎在评论区分享你的“填坑”经历！ 让我们一起更从容地驾驭 Go Modules。
如果这篇文章帮你纠正了一个长期的误解，别忘了点个【赞】和【在看】，并转发给那个还在手动修 go.sum 的同事！
还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：
扫描下方二维码，开启你的AI原生开发之旅。
你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？
继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！
我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。
目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！
商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。
© 2026, bigwhite. 版权所有.
2026-01-06 08:17:16
本文永久链接 – https://tonybai.com/2026/01/06/a-golden-map-to-distributed-architect
大家好，我是Tony Bai。
分布式系统的世界，就像一座没有路标的“黑暗森林”。
当你刚从单体应用的舒适区走出来，踏入这片森林时，很容易感到迷茫：
市面上的资料汗牛充栋，但往往两极分化：要么是晦涩难懂的学院派论文，读完那是“从入门到放弃”；要么是碎片化的工具教程，教你配置了一百个参数，却没告诉你为什么要这么配。
我们缺的不是知识点，而是一条清晰的、能够串联起所有知识的“路径”。
在过去的六个月里，我推翻了无数次草稿，拜读了经典的分布式教程，查阅了大量的经典论文与工程源码，只做了一件事：
为你绘制一张通往“分布式架构师”的黄金学习地图。
这张地图，就是我这次要上线的微专栏——《分布式系统：原理、哲学与实战》的灵魂所在。
这门课不是知识点的堆砌，而是一场目标明确的探险。
我不想教你死记硬背。我要带你回到原点，模拟一个系统从小到大的演进过程，让你亲历那些“不得不做”的架构决策。
这是我为你规划的“黄金路线图”：
沿着这条路线，我们将经历四个关键的里程碑：
我们首先要打破单体思维的幻想。在这个阶段，你将学会“拥抱失败”。
为了让系统活下去并壮大，你需要两把武器：复制与分区。
这是旅途中最艰难、但也最精彩的一段。我们将正面挑战分布式事务与共识。
当你站在山顶，视野将不再局限于数据中心。
既然 AI 已经能帮我们写代码了，为什么还要啃这些硬骨头？
因为 AI 擅长“实现”，但只有你懂“权衡”。
这些关于 “Why” 和 “Trade-off（权衡）” 的智慧，构成了系统的设计哲学。
这就是本专栏最大的特色： 我们不只讲原理（How），更讲哲学（Why），并最终落脚于实战（Code）。
现在启程
这张地图我已经画好了，路标也已插好。
这可能不是一条轻松的路，但我保证，这绝对是一条风景最壮丽、收获最丰厚的路。
耗时六个月的心血之作，现在，我把它交付给你。
扫描下方二维码，订阅专栏，领取你的“架构师地图”
互动话题
在你的分布式开发生涯中，踩过最深的一个“坑”是什么？是数据不一致？是脑裂？还是不知如何选型？欢迎在评论区留言分享，我们在专栏里见！
还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：
扫描下方二维码，开启你的AI原生开发之旅。
你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？
继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！
我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。
目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！
商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。
© 2026, bigwhite. 版权所有.
2026-01-05 12:02:10
本文永久链接 – https://tonybai.com/2026/01/05/how-ken-thompson-developed-go-language-at-google.
大家好，我是Tony Bai。
为什么 Go 语言极其痛恨复杂的特性？为什么 Go 如此执着于编译速度？我们常说 Go 是一门“工程实用主义”的语言，它的设计哲学是“少即是多”。但你是否想过，这种近乎偏执的简洁，究竟是为了对抗什么？
这一切的答案，都藏在 2007 年 Google 内部的一场 C++ 标准委员会汇报演讲中。当图灵奖得主 Ken Thompson 发现自己竟然“看不懂”新的 C++ 特性时，一颗变革的种子就此埋下。
最近，我重温了这段 Ken Thompson（Unix 之父、Go 语言联合创始人）的珍贵访谈。在访谈中，老爷子毫无保留地讲述了 Go 语言诞生的前因后果。 故事的起点，并非某次高瞻远瞩的战略规划，而是一次“听不懂”的 C++ 技术分享，以及 Google 内部那令人绝望的 45 分钟编译时间。
本文基于 Ken Thompson 的访谈实录，带你回到那个决定性的瞬间，还原 Go 语言诞生背后的真实故事。
故事发生在 2007 年左右。当时，Google 内部有一位 C++ 标准委员会（ANSI C++）的代表。
有一天，这位代表刚开完标准会议回来，在 Google 内部做了一场技术分享，向大家介绍 C++ 即将引入的“新特性”（注：推测是指当时的 C++0x，即后来的 C++11 草案）。
Ken Thompson 就在台下。作为发明了 B 语言（C 语言的前身）并重写了 Unix 内核的宗师级人物，他在听完这场一小时的密集分享后，感受到的不是兴奋，而是困惑。
“这所谓的‘新东西’，在我看来比语言本身还要大。”
“那些关于指针的形式，除了指针之外还意味着其他东西……我告诉你，我没听懂。”
想象一下，连 Ken Thompson 都直言自己“没听懂” C++ 的新特性，这说明了什么？
在他看来，这些所谓的“改进”，只是在不断地堆砌复杂度。这场演讲成为了催化剂。Ken 回到办公室，找到了同样对现状不满的 Robert Griesemer 和 Rob Pike。
Ken 的不满在于语言的过度复杂，而 Rob Pike 的痛点则在于 Google 庞大的工程规模。
当时的 Google 面临着一个前所未有的工程挑战：Monorepo（单一代码仓库）的膨胀。
Ken 在访谈中描述了一个令人窒息的场景：
“在 Google，你可以从任何源文件中引用库。你可能只写了一个 10 行的程序，但最终却需要处理 500 万行的编译量。”
这不是夸张。由于缺乏严格的依赖管理和可见性控制，一个微小的依赖引入，可能会像滚雪球一样，将底层的庞大库（如 Protocol Buffers、基础库等）全部卷入编译过程。
更糟糕的是，头文件（Header files）的包含机制导致了严重的重复劳动。
“像最简单的库，可能会被加载和检查成百上千次。”
虽然 Google 拥有当时世界上最强大的分布式编译集群（成百上千个 CPU 并行工作），虽然工程师们发明了各种缓存机制和 ifdef 技巧来避免重复包含，但物理定律是不可违背的。
编译一个简单的程序，需要等待 15 分钟，甚至 45 分钟。
Rob Pike 对此深恶痛绝。这种低效的开发循环，正在扼杀 Google 工程师的创造力。
于是，在 Google 的一间办公室里，Ken Thompson、Rob Pike 和 Robert Griesemer 聚在了一起。
Ken 说出了那句改变历史的话：
“What are we going to do about it? Let’s write a language.”（我们该怎么办？让我们写个语言吧。）
这是一个完美的互补组合：
在设计 Go 语言时，他们制定了一个残酷但有效的规则：全员同意原则。
“我们必须都同意某个特性，它才能被加入。仅仅因为‘我想要这个特性’是不够的。”
这个规则过滤掉了绝大多数“花哨但非必要”的特性。Go 语言之所以能保持如此干净、紧凑，正是因为这三位创始人在最初就把住了关口。
Ken Thompson 在 Go 语言开源并走上正轨后，逐渐淡出了核心开发。但他对 Go 的后续发展给予了极高的评价，特别是对标准库。
“在我离开后，后来的人写了一套极其出色（magnificent）的标准库。”
那之后，这位图灵奖得主在 Google 的工作中，几乎只使用 Go 语言，并且几乎只使用标准库。
他对 Go 的评价朴实无华：
“它很简单。任何人都可以在一小时内学会它。当你写代码时，它运行得足够快，给你即时的反馈。”
重读这段访谈，我们就能理解：
因为 Go 从诞生的那一刻起，就是为了反抗 C++ 的过度复杂，和解决 Google 级别的工程规模问题。
它不是为了在编程语言理论上创新，而是为了让像 Ken Thompson 和 Rob Pike 这样的工程师，不再需要在编译期等待 45 分钟，不再需要去猜测一段代码到底在通过指针玩什么花样。
Go 的诞生，是工程实用主义对无节制复杂性的一次伟大胜利。
资料链接：https://www.youtube.com/watch?v=NTrAISNdf70
你的“编译等待”时刻
45分钟的编译时间催生了Go语言。在你的开发生涯中，是否也经历过类似的“编译噩梦”？或者，你是否也曾被某些语言的“过度复杂”劝退过？
欢迎在评论区分享你的故事！ 让我们一起致敬那些为了“简单”而努力的先驱。
如果这篇文章让你对Go语言的设计哲学有了更深的理解，别忘了点个【赞】和【在看】，并转发给身边还在忍受漫长编译的朋友！
还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：
扫描下方二维码，开启你的AI原生开发之旅。
你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？
继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！
我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。
目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！
商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。
© 2026, bigwhite. 版权所有.
