Subagents in Gemini CLI - Gemini CLI 现可在终端中运行专用子代理



本文永久链接 – https://tonybai.com/2026/04/17/tiobe-ranking-and-the-decline-of-rust-hype
大家好,我是Tony Bai。
过去几年,技术圈最热门的“猜谜游戏”之一,就是预测 Rust 什么时候能杀入 TIOBE 排行榜的前十。
这门被誉为“天选之子”的语言,连续多年霸榜 Stack Overflow“最受喜爱”的宝座,被微软、亚马逊等巨头奉为重写底层基础设施的“银弹”。所有人都觉得,它冲进前十,只是时间问题。
但就在最近,TIOBE 指数发布了 2026 年 4 月的最新排名。
榜单本身平平无奇,Rust 的排名甚至还从去年同期的 18 位微升到了 今年的16 位。

然而,TIOBE 的 CEO Paul Jansen 亲自撰写的一篇社论,却像一盆冷水,劈头盖脸地浇在了所有 Rustacean(Rust 开发者)的头上。

Paul Jansen 用极其明确的措辞,给这门甚至还没来得及摸到前十门槛的语言,提前下了一份“病危通知书”:
“Rust 的崛起显示出放缓的迹象。……它进入前十的梦想,现在看来比以前更加遥远了。”
这篇社论,瞬间引爆了全网的讨论。
无数 Rust 开发者感到匪夷所思,甚至有些愤怒:我们还没真正发力,你怎么就开始唱衰了?
这背后,到底是 TIOBE 对技术趋势的精准预判,还是这把统治了我们十几年的“认知标尺”,已经彻底失灵了?
今天,我们就来扒开这张榜单的底裤,看看在喧嚣的数据背后,Rust 的真实处境,究竟是怎样的。

我们先来看看 TIOBE CEO Paul Jansen 的“诊断报告”。
他指出,Rust 在今年年初曾一度冲到历史最高排名第 13 位,但仅仅三个月后,就又跌回了第 16 位。
他给出的解释是:
“一个可能的解释是,尽管 Rust 能够生产出高效和安全的代码,但对于非专家程序员来说,它仍然难以学习。虽然专家们愿意投入时间去掌握这门语言,但更广泛的主流采用似乎面临着更大的挑战。”
这段话,精准地戳中了 Rust 社区最敏感、也最引以为傲的那根神经——陡峭的学习曲线。
为了追求极致的内存安全,Rust 发明了极其复杂的“所有权(Ownership)”和“借用检查(Borrow Checker)”系统。这套系统像一个极其严苛的导师,在你编译代码的每一个环节,都对你进行着灵魂拷问。
无数新手在入门 Rust 时,都会经历一段被称为“与编译器搏斗”的痛苦时期。
TIOBE 的观点很明确:这种“精英主义”的设计哲学,正在成为 Rust “出圈”的最大障碍。
TIOBE 的诊断听起来似乎很有道理。但我们必须先问一个更底层的问题:TIOBE 指数,到底是个什么东西?
TIOBE 的排名,本质上是一个基于“搜索引擎查询量”的指标。它在全球 25 个主流搜索引擎上,统计包含 +”
看懂了吗?这套诞生于 十多年前的评判标准,在 2026 年的今天,已经变得极其荒谬。
它衡量的是一门语言在公网上的“话题度”和“声量”,而不是它的“真实价值”和“商业应用”。
这就像用“微博热搜”的次数,去评判一位科学家的学术贡献一样可笑。
用这把“旧尺子”去衡量现代编程语言,会产生几个致命的认知偏差:
1. 越是难学、坑越多的语言,排名越高。
这恰恰是 TIOBE 逻辑最诡异的地方。Paul Jansen 一边抱怨 Rust 太难学,一边却忽视了,正是因为“难学”,新用户才会频繁地去 Google 搜索“Rust a lifetime that lives long enough”、“the trait Borrow is not implemented for String”这些令人抓狂的报错信息。
每一次“救命”的搜索,都在为 Rust 的 TIOBE 排名,贡献着宝贵的 KPI。
2. 越是成熟、生态完善的语言,排名越吃亏。
随着一门语言的成熟,它的文档会越来越完善,社区的最佳实践会沉淀下来。开发者遇到的问题,更多地会在官方文档、IDE 提示、或者小圈子的 Slack/Discord 里被解决,而不会产生大量的公开搜索。
没有问题,就没有搜索。没有搜索,就没有 TIOBE 排名。
3. TIOBE 无法衡量“生态位”的价值。
Rust 的江山在哪里?在 Linux 内核里(注:最近发布的Linux Kernel 7.0里,Rust已经正式转正了!),在 Windows 的系统组件里,在 Cloudflare 的边缘网络里,在 Figma 的渲染引擎里,在那些对性能和安全要求达到极致的底层基础设施里。
这些领域的开发者,是金字塔尖的系统程序员。他们讨论问题,是在 GitHub Issue、Zulip 频道,而不是在 CSDN 上问“我的 &mut 为什么传不进去”。
Rust 的价值,深藏在那些不会产生大量公开搜索记录的、高壁垒的硬核场景里。而 TIOBE 的爬虫,可能永远也爬不到那里。
扒开 TIOBE 的“障眼法”,我们该如何客观看待 Rust 在 2026 年的真实处境?
Rust 并没有“增长放缓”,它只是在经历一场必然的“出圈阵痛”。
任何一门新技术的发展,都会经历两个阶段:
Rust 现在正处于从阶段一向阶段二过渡的关键时期。它那套为系统编程量身打造的、极致安全的内存管理哲学,在 Web 开发、数据科学、GUI 应用等场景下,确实给很多开发者带来了巨大的心智负担。
Rust 社区内部,关于是否应该为了“易用性”而牺牲部分“极致性”的争论,也从未停止。比如,关于异步运行时的分裂(Tokio vs async-std)、关于标准库的精简与扩充,都反映了这种“青春期的烦恼”。
Rust 没有停滞,它只是在“成长的十字路口”,在思考自己到底想成为谁。
作为身处一线的工程师,我们应该如何看待 TIOBE 的这份“诊断书”?
第一,永远不要把“流行度”作为技术选型的唯一标准。
JavaScript 很流行,但你不会用它去写操作系统内核。COBOL 极其冷门,但全球的银行系统依然跑在它上面,顶级 COBOL 程序员的薪资高得吓人。
技术的价值,永远取决于它在特定场景下,解决了多大规模、多高难度的商业问题。
第二,警惕“易用性”的陷阱。
Go、Python 很简单。但这种简单,可能是以牺牲“运行时安全保证”(比如Python 的动态类型、Go的Nil指针等)为代价的。
Rust 的“难”,恰恰是把所有可能在深夜引发线上雪崩的风险,全部前置到了编译阶段。它用“编译时的痛苦”,换取了“运行时的安宁”。
这种设计哲学,对于金融交易、底层基础设施、航空航天等“不容有失”的领域来说,是无价之宝。
第三,对自己的成长负责,而不是对榜单负责。
与其每个月焦虑地刷新 TIOBE 的排名,不如去问自己几个更本质的问题:
你的技术护城河,从来不是由 TIOBE 的排名决定的,而是由你所处行业以及要解决问题的深度决定的。
TIOBE 的这份榜单,与其说是一份严肃的技术报告,不如说是一场成功的“引流狂欢”。
它用一个看似客观的数据,精准地挑动了每个程序员心中最敏感的那根“身份焦虑”神经。
但作为身处一线的工程师,我们必须保持清醒。
衡量一门技术价值的唯一标准,从来不是它在搜索引擎上的热度,而是它在真实的商业世界里,解决了多大、多复杂、多有价值的问题。
当你在用 Rust 构建着下一代安全操作系统,或者用它重写着公司最核心的交易引擎时,你根本无需关心 TIOBE 上的排名是 16 还是 60。
因为你正在创造的价值,早已不是这些过时的“声量指标”所能衡量的。
你的技术栈没有背叛你,但你的认知,可能会。
今日互动探讨:
你觉得 TIOBE 对 Rust“增长放缓”的判断准确吗?你认为 Rust 陡峭的学习曲线,是它最大的优势,还是最大的障碍?
欢迎在评论区分享你的看法!
还在为“复制粘贴喂AI”而烦恼?我的新专栏 《AI原生开发工作流实战》 将带你:
扫描下方二维码,开启你的AI原生开发之旅。

原「Gopher部落」已重装升级为「Go & AI 精进营」知识星球,快来加入星球,开启你的技术跃迁之旅吧!
我们致力于打造一个高品质的 Go 语言深度学习 与 AI 应用探索 平台。在这里,你将获得:
衷心希望「Go & AI 精进营」能成为你学习、进步、交流的港湾。让我们在此相聚,享受技术精进的快乐!欢迎你的加入!

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

© 2026, bigwhite. 版权所有.





本文永久链接 – https://tonybai.com/2026/04/15/cpp-community-debate-productivity-revolution-vs-complexity
大家好,我是Tony Bai。
如果你把编程语言比作工具,Go 是一把极简的手术刀,精准且克制;Rust 是一套带智能传感器的外骨骼装甲,严苛且安全。
而 C++ 呢?它更像是一把在过去四十年里不断被加挂零件的、超重型复合瑞士军刀。
最开始,它只有刀片和叉子;后来,它加了锯子、剪刀和钳子;再后来,它甚至被塞进了一套显微镜和一支激光笔。在开发者眼里,它是能解决世间一切难题的万能神兵,但也是一个重到让你拿不稳、甚至随时可能切到自己手指的“庞然大物”。
但就在前几天,r/cpp 这个拥有近 10 万 C++开发者的顶级社区里,一篇名为《现代 C++ 是让我们更高效了… 还是更复杂了?》的帖子,引发了一场深度大讨论。
发帖人发出了灵魂拷问:
“C++20/23 给我们带来了 Ranges、协程(Coroutines)、Concepts、Modules……这些新特性真的很酷,我也在用。但我总在想,我们是不是在用这些东西吓跑新人的同时,眼睁睁地看着老代码库永远冻结在 C++98?现代 C++ 对生产力来说,到底是一场革命,还是在原本已经足够复杂的巨兽身上,又叠加了一层复杂性?”
这篇帖子,精准地戳中了每一个 C++ 开发者心中最深的困惑。短短一天,就吸引了上百条充满血泪与思考的评论。
今天,我们就来复盘这场顶级的社区大讨论,看看这柄“瑞士军刀”在疯狂“堆料”的背后,到底藏着怎样的挣扎、分裂与反思。

在这场大讨论中,我仿佛看到了 C++ 社区三个泾渭分明的平行宇宙。
宇宙一:永远的 C++98/11 ——“能跑就行,别动!”
评论区里,点赞最高的一派观点,充满了对“存量代码”的敬畏与无奈。
一位开发者吐槽道:
“我在太多项目里因为各种原因被迫使用旧标准,以至于我已经懒得去关心最新的特性了。我感觉很多专业场景就是这样:我们用着‘穴居人 C++’,因为那玩意儿安全(指熟悉)、方便。”
另一位开发者更是直接引用了 Matt Godbolt 的名言:“向后兼容性才是 C++ 的超能力。”
“别想着重构了,那只会破坏一切。跑了 20 年没 Bug 的生产代码是无价之宝,别碰它!”
更有甚者,因为芯片厂商的编译器只支持 C++89,或者因为“法律原因”,一个项目被迫在一个 3 年前的工具链上锁死 7 年。
在这个宇宙里,C++20 的新特性,对他们来说都像火星科技一样遥远。
宇宙二:拥抱 C++20/23 ——“旦用难回,太香了!”
与“遗老派”形成鲜明对比的,是那些已经吃上新标准红利的“先锋派”。
有开发者激动地表示:
“自从我开始用协程(Coroutines)写网络 IO 代码,我再也回不去以前那种回调地狱了!”
另一位则对 C++23 的 std::println 赞不绝口:
“我离不开 C++23,完全是因为 println。我不知道我还在用 23 的什么其他特性,但光这一个就太棒了。”
对于这部分开发者来说,现代 C++ 的每一个新特性,都是一次生产力的解放。他们就像一群拿到了新玩具的孩子,兴奋地探索着 Ranges 的组合魔法和 Concepts 带来的清爽报错。
宇宙三:爱恨交织的“中间派”——“一半是天堂,一半是地狱”
这或许是最大多数 C++ 开发者的真实写照。
正如帖子作者所言,新特性确实很酷,但它们也带来了巨大的认知负荷和决策成本。
一个开发者的评论获得了 82 个高赞:
“我们大多数人只用了 C++ 语言特性的一小部分。这就像一个‘鸡生蛋、蛋生鸡’的问题:这里有个新特性,但我不知道该怎么用、为什么要用;或者,我代码里有个痛点,可能能用新特性解决,但我不知道该用哪个。”
这种“选择的困境”,正是 C++ “自由”的代价。
为什么 C++ 会演变成今天这样?
评论区里的一位开发者给出了一个极其精妙的比喻:“集市(Bazaar)”。
“我绝对热爱 C++ 的一点是:它有一个特性集市,你可以挑选你认为适合你项目的工具。如果你看其他语言,比如 Java 要求万物皆对象,Haskell 要求万物皆函数。C++ 给了你面向对象,你讨厌它?没问题,不用就行。你喜欢函数式?C++ 也支持。”
这种“万物皆可选”的自由,是 C++ 最大的魅力,当然也是它最大的诅咒。
因为在一个团队里,当每个人都从“集市”上拿回了自己最喜欢的锤子时,整个项目就会变成一个风格迥异的“建筑工地”。
原帖作者自己也承认:
“自由是真实的,但这也意味着两个 C++ 代码库可能看起来像两种完全不同的语言。”
当一个文件里还在用裸指针和手动内存管理,而另一个文件里已经用上了 std::unique_ptr 和 std::span;当一部分团队在用 boost::asio 写回调,而另一部分团队在用 C++20 的协程……
Code Review 就变成了一场噩梦。
这场大讨论的背后,其实隐藏着两个更深层次的软件工程哲学问题。
问题一:新特性是“锦上添花”,还是“非用不可”?
很多 C++ 老兵认为,现代 C++ 增加的很多特性,比如 Ranges 和 Coroutines,其实早在几十年前的 LISP 语言里就已经被证明是伟大的思想。C++ 只是在用一种极其缓慢、极其复杂的方式,在“偿还”几十年前欠下的“技术债”。
但另一些人认为,C++ 的伟大恰恰在于,它能用“零成本抽象(Zero-cost Abstraction)”的硬核方式,将这些高级思想,落地到对性能要求极致的生产环境中。
问题二:复杂性是“敌人”,还是“朋友”?
一位开发者的评论极具辩证思维:
“这(新特性)既是好事,也是坏事。学习的门槛确实在不断提高。但这些工具是实实在在有用的,它们让你能用更干净、更安全、更高效的方式表达代码。”
当 Go在极力做“减法”,试图降低开发者的心智负担时,C++ 却似乎在坚定地走着另一条路:它信任开发者是专家,它把所有的选择权和复杂性都交给你,让你自己去构建属于你的“最佳子集”。
这就像驾驶一架拥有几百个仪表盘的航天飞机。对于新手来说是灾难,但对于顶尖的飞行员来说,每一个按钮都意味着更精准的控制力。
在这场看似无解的“内部大讨论”中,我们依然能找到一条充满智慧的中间路线。
有人分享了一个极具参考价值的真实案例:
他成功地在一个庞大的 C++98 代码库中,引入了一个用 C++17 编写的新功能模块。他没有去重构任何老代码,只是简单地升级了编译器和构建脚本。结果:新特性带来了性能的提升和开发效率的飞跃,而老代码依然稳定运行。
这或许就是现代 C++ 正确的打开方式:不要试图用新标准去“革命”旧代码,而是在写新代码时,大胆地、有选择地拥抱新特性。
让 C++98 的归 C++98,让 C++23 的归 C++23。在一个代码库中,允许不同时代的“方言”共存,用新增的模块去逐步“稀释”历史的包袱。
C++ 的这场大讨论,没有赢家。
它只是再次向我们证明了这门语言的“独一无二”:它是一门民主的语言。它给了你选择一切的自由,也要求你为自己的选择承担一切后果。
用一位开发者的话来说:
“Rust 强加给你它的观点;而 C++ 要求你有你自己的观点。这就像专制与民主的区别。大多数时候,民主只是一个被猴子笼子管理的、组织混乱的马戏团。但我更喜欢民主。”
或许,对于我们这些已经习惯了 Go 和 Rust 那种“带你走”模式的开发者来说,偶尔回头看看 C++ 这个充满“混沌与活力”的古老集市,会让我们对“软件工程”这门手艺,有更深刻的理解。
资料链接:https://www.reddit.com/r/cpp/comments/1sihs1w/is_modern_c_actually_making_us_more_productive_or
今日互动探讨:
在你的技术生涯中,你是否也曾被困在某个古老的“技术版本”里动弹不得?对于 C++ 这种“万物皆可选”的自由哲学,你是向往,还是恐惧?
欢迎在评论区分享你的看法!
还在为“复制粘贴喂AI”而烦恼?我的新专栏 《AI原生开发工作流实战》 将带你:
扫描下方二维码,开启你的AI原生开发之旅。

原「Gopher部落」已重装升级为「Go & AI 精进营」知识星球,快来加入星球,开启你的技术跃迁之旅吧!
我们致力于打造一个高品质的 Go 语言深度学习 与 AI 应用探索 平台。在这里,你将获得:
衷心希望「Go & AI 精进营」能成为你学习、进步、交流的港湾。让我们在此相聚,享受技术精进的快乐!欢迎你的加入!

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

© 2026, bigwhite. 版权所有.


本文永久链接 – https://tonybai.com/2026/04/10/rails-father-dhh-on-ai-and-programmer-value
大家好,我是Tony Bai。
在这个由 AI 主导的、充满不确定性的 2026 年,整个软件行业似乎都被一种集体性的焦虑所笼罩。我们每天都在讨论:当 AI 能在一分钟内写完我们一周的代码时,我们这些“人类程序员”的价值还剩下多少?
就在所有人都在悲观地预测“程序员即将贬值”时,一位以“毒舌”和“极简主义”著称的硅谷大神,却逆着人潮,抛出了一个极其震撼的“反共识”暴论:
“我们可能已经见证了‘普通程序员’薪资的顶峰。但对于那些顶尖的、真正懂行的开发者来说,AI 正在让他们变得比以往任何时候都更值钱、更有价值。”
说出这句话的,正是 David Heinemeier Hansson (DHH)——Ruby on Rails 框架之父、37signals (Basecamp & HEY) 的联合创始人兼 CTO。
就在几个月前,DHH 还是 AI 编程最坚定的“喷子”之一。他曾公开嘲讽 Copilot 像个烦人的实习生,打断他的思路,生成的代码全是垃圾。
但在一场最新的深度访谈中,他却上演了一场惊天动地的“自我推翻”。他不仅承认自己已经“彻底投降”,更是将他现在的工作流形容为 “Agent First on Everything”(万物皆以智能体为先)。
这场 180 度的惊天逆转背后,到底发生了什么?在这场信息量爆炸的对话中,DHH 不仅详细复盘了让他“觉醒”的那个“aha moment”,更对 AI 时代的程序员价值、团队协作、以及“软件匠艺”的未来,给出了极其深刻、甚至有些残酷的终极洞见。

DHH 坦言,在 Copilot 和早期 Cursor 的“代码补全(Autocomplete)”时代,他对此类工具的厌恶达到了顶峰。
“我感到无比愤怒。它总是在我还没想清楚的时候就试图猜我想写什么。‘你是想写这个吗?’‘你是想写那个吗?’ 闭嘴!让我自己把话说完!”
他甚至一度悲观地认为,整个行业将走向一个由“Tab 键”驱动的、毫无思想的愚蠢未来,并开玩笑说自己可能要去丹麦种土豆了。
转折点发生在 2025 年的冬天。两个关键变量,彻底改变了游戏规则:
DHH 形容,当这两个变量结合在一起时,他迎来了职业生涯的“第二次启蒙”——上一次,是 2000 年初他第一次发现 Ruby 语言的优雅。
“我不再是那个在键盘上打字的人,我感觉自己像是穿上了一套超级机甲。我突然长出了 12 只手,可以同时操作 7 个屏幕。我作为程序员的能力,被极度放大了。”
当被问及 AI 是否会取代程序员时,DHH 毫不避讳地抛出了一个极其冷酷的观点:
我们很可能已经见证了“程序员(作为一种普通职业)”的黄金时代顶峰。
他认为,在过去,程序员之所以能获得极高的薪资,是因为他们是生产软件的“瓶颈资源”。产品经理想出一个绝妙的点子,必须排队等待昂贵的程序员花几周时间才能实现。
但现在,瓶颈正在快速转移。
“当产品经理自己就能用 AI 生成可用的代码时,事情就要变天了。在任何一个软件开发被视为‘成本中心’(而这恰恰是世界上绝大多数的软件开发场景)的公司,降薪和裁员的压力将是不可避免的。”
但这是否意味着所有程序员都会被淘汰?
恰恰相反。DHH 认为,AI 正在引发一场剧烈的“价值两极分化”。
因为他们是那个能够判断“AI 生成的东西是对是错、是美是丑”的最终把关人。他们从“体力劳动者”,进化为了“艺术总监”。
在这场对话中,DHH 反复强调一个词:Aesthetics is truth(美学就是真理)。
他认为,无论是在数学、物理学还是软件工程中,一个优美的解决方案,往往也正是那个正确的方案。
“乔布斯之所以关心 Mac 电脑机箱内部的走线,是因为他凭直觉知道,只有那些在乎印刷电路板布局的人,才会去死磕用户界面的每一个像素。”
在 AI 时代,这种对“美”的追求,不仅没有过时,反而变得空前重要。
因为当你拥有了无限的“算力(AI)”时,唯一稀缺的,就是“品味(Taste)”。
DHH 认为,未来顶尖的软件工程师,其核心竞争力将不再是“知道多少种排序算法”,而是:
代码的实现,正在变得廉价;而代码的“品味”,正在变得无价。
DHH 详细分享了他现在的“Agent-First”工作流,堪称教科书级:
他使用 tmux 在终端里创建了一个三分屏布局:
“我几乎所有的工作都从其中一个 Agent 开始。我给它一个模糊的指令,然后看着它生成初稿。然后我把初稿扔给另一个 Agent,让它去批判和重构。我让它们俩来回‘吵架’。最后,我再跳到 Neovim 里,做那个最终的‘裁判’。”
他分享了一个让他自己都感到震惊的案例:
37signals 的 Linux 发行版 Omarchy 积压了 250 个无人处理的 PR。他花了 90 分钟,让 Claude 帮他审完了其中 100 个。
“这在以前至少是一周的工作量。更重要的是,其中一半的 PR 涉及我不懂的领域,Claude 在那些领域,是比我更聪明、更优秀的审查者。”
DHH 在访谈中提到了一个极具启发性的概念:AI 正在让“雄心(Ambition)”变得廉价。
他举例,他让 Agent 在几天内,为一个搁置已久的需求(为 Omarchy 实现 Windows 双系统启动)制定了一套完整的、可执行的方案。而在过去,他连花 4 个小时去调研的意愿都没有。因为这件事“重要但不紧急”,而且“非常麻烦”。
“探索一个直觉的成本,已经被降低了一千倍。我们现在可以去挑战那些过去连想都不敢想的项目。”
他分享了 37signals 内部的一个真实案例:一位名叫 Jeremy 的工程师,利用 AI 发起了一个名为“P1 优化”的疯狂项目。他要去优化系统中那最快的 1% 的请求,让它们变得更快。
这在传统性能优化的世界里,简直是“吃饱了撑的”。
但 Jeremy 仅用了几天时间,通过让 Agent 疯狂分析和重构,提交了 12 个 PR,硬生生把这 1% 请求的延迟从 4ms 压缩到了 0.5ms 以下,实现了 10 倍的性能提升。
当探索的成本趋近于零时,过去那些被视为“无用功”的边缘优化,将共同汇聚成压倒性的产品优势。
在访谈的结尾,DHH 表达了他对未来的极度乐观。
他认为,AI 并没有让编程变得无趣,反而让他找回了自 2000 年初发现 Ruby 以来最大的快感。
DHH 的这场“觉醒”,不仅仅是一个技术大佬对新工具的拥抱。它更像一个宣言:
在 AI 时代,软件工程的“手艺(Craft)”并没有消亡,它只是从“雕琢代码”的微观层面,升维到了“塑造品味”与“驾驭系统”的宏观层面。
AI 正在无情地淘汰那些只会“拧螺丝”的码农,但同时,它也为那些真正热爱创造、拥有极高审美和品味的“工匠”,递上了一把前所未有的神兵利器。
你,准备好拿起它了吗?
资料链接:https://www.youtube.com/watch?v=JiWgKRgdgpI
今日互动探讨:
在使用 AI 编程后,你是否也像 DHH 一样,感觉自己的“野心”被放大了,敢于去挑战更复杂的项目?在你的工作中,AI 是更多地扮演“体力外包”,还是“创意伙伴”的角色?
欢迎在评论区分享你的真实感受!
还在为“复制粘贴喂AI”而烦恼?我的新专栏 《AI原生开发工作流实战》 将带你:
扫描下方二维码,开启你的AI原生开发之旅。

原「Gopher部落」已重装升级为「Go & AI 精进营」知识星球,快来加入星球,开启你的技术跃迁之旅吧!
我们致力于打造一个高品质的 Go 语言深度学习 与 AI 应用探索 平台。在这里,你将获得:
衷心希望「Go & AI 精进营」能成为你学习、进步、交流的港湾。让我们在此相聚,享受技术精进的快乐!欢迎你的加入!

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

© 2026, bigwhite. 版权所有.

本文永久链接 – https://tonybai.com/2026/03/18/why-ai-agents-act-stupid-manus-expert-pitfall-guide
大家好,我是Tony Bai。
如果你在过去一年里跟风写过 AI Agent(智能体),你大概率经历过这样的绝望时刻:
你兴致勃勃地给大模型挂载了二三十个精心编写的 Function Calling(函数调用)工具,比如 read_file, search_web, execute_python……你期待它能像钢铁侠的贾维斯一样运筹帷幄。
结果呢?面对稍微复杂一点的任务,你的 Agent 瞬间退化成一个“智障”。
它要么在几十个工具里疯狂迷失,选错了参数导致系统报错;要么陷入无限死循环,把你的 Token 烧个精光,最后无辜地吐出一句:“抱歉,我无法完成该任务。”
我们总以为是自己的 Prompt 没写对,或者是大模型还不够聪明。
直到前些日子,一位名叫 MorroHsu 的顶级实战派大佬(在被 Meta 收购前,他是现象级 AI 产品 Manus 的后端技术负责人)在 Reddit 上抛出了一篇长文。
在过去两年里,他以后端负责人的身份参与构建了包括 Manus、agent-clip 等在内的多个顶尖 Agent。在被大模型的各种奇葩幻觉折磨了无数遍之后,他得出了一个极其震撼、甚至有些反直觉的血泪结论:
别再瞎折腾繁琐的 Typed Function Calls(类型化函数调用)了!给大模型一堆乱七八糟的 API,就是它变“智障”的罪魁祸首。大模型最需要的,仅仅是 50 年前的 Linux 命令行(CLI)。
今天,我们就来看看这位 Manus 前后端大佬的 2 年避坑心法。看看为什么最前沿的 AI,反而需要最古老的 Unix 哲学来拯救。

目前主流的 Agent 框架(如 LangChain),都在教我们怎么给大模型塞满工具箱。你塞的工具越多,系统看起来越庞大。
但 MorroHsu 指出了这背后的致命逻辑错误:工具选择的认知过载(Cognitive Load)。
大模型每次行动前,都要在几十个有着不同数据结构(Schemas)的工具中艰难地做选择题:“我到底该用哪一个?参数填什么?” 上下文的注意力被极大地分散了,准确率直线断崖式下跌。
大佬的解法粗暴且优雅:废弃所有花里胡哨的工具,只给大模型提供唯一的一个函数:run(command=”…”)。
为什么?因为大模型天生就是个 Linux 高手!
大模型的训练语料库里,充斥着 GitHub 上数十亿行的代码、README.md 中的安装指南、以及 Stack Overflow 上的报错日志。这些语料中,密密麻麻全是 CLI 命令行。
如果你让它去调用你发明的 read_log_file(path) API,它还要去猜测你的参数定义;但如果你让它去找日志里的错误,它会凭着肌肉记忆毫不犹豫地写出:
run(command=”cat /var/log/app.log | grep ‘ERROR’ | tail -n 20″)
你看,CLI 本身就是大模型最熟悉的母语。不要发明新的轮子去教大模型做事,直接把它最熟悉的世界交给它。
如果只有一个 run 命令,AI 遇到复杂任务怎么办?
这就引出了 50 年前 Unix 操作系统的伟大设计哲学:一切皆文件。
Unix 的先驱们设计了大量只做一件事的小工具(cat, grep, sort),然后通过管道(Pipe |)将它们串联成无比强大的工作流。
而这,完美契合了大模型的核心本质——大模型只能理解文本输入和文本输出!
在传统的 Function Calling 中,为了完成“下载数据 -> 过滤错误 -> 排序前 10 条”这个任务,你的 Agent 可能需要连续调用 3 个不同的自定义函数,经历 3 轮耗时极长的 LLM 推理,中间稍微错一步就满盘皆输。
但在 CLI 模式下,AI 只需要通过一次组合调用就能秒杀:
run(command=”curl -sL $URL | grep ’500′ | sort | head 10″)
这种强大的“组合编排能力(Composition)”,不是什么 AI 领域的最新黑科技,而是 Unix 管道原生自带的降维打击。
当然,光把命令行扔给大模型,它依然会因为瞎猜而犯错。MorroHsu 总结了三个极其硬核的实战设计技巧,教你如何打造一个“防智障”的 Agent 导航系统:
绝招 1:渐进式发现(Progressive Discovery)
不要一开始就把所有命令的长篇大论全塞给大模型,那会瞬间撑爆它的上下文窗口。
只要告诉大模型:“你可以运行 run(“command”)。遇到不懂的,运行 command –help”。
大模型其实非常懂得自我探索。当它发现报错时,它会自动去查阅说明书。这种“按需发现”的能力,极大地节省了宝贵的 Token。
绝招 2:把报错变成“向导”
这是最具启发性的一点!当大模型敲错命令时,千万别只返回一个冷冰冰的 exit code 127 或者 command not found。大模型无法像人类那样去 Google 搜索错误原因,它只会陷入瞎猜的死循环。
你必须在 stderr(标准错误输出)里加上向导信息。
传统报错:cat: photo.png: binary file
给 AI 的防智障报错:[Error] cat: photo.png is a binary image. Use ‘see photo.png’ instead.
不要试图阻止大模型犯错,而是要让它的每一次犯错,都成为指向正确道路的路标。
绝招 3:双层架构(物理隔离幻觉)
大模型的上下文是极其脆弱的。MorroHsu 分享了一个惨痛的真实案例:
一个用户上传了一张系统架构图,Agent 试图用 cat 命令读取它。结果 182KB 的乱码二进制字节流瞬间冲入了大模型的上下文。大模型当场“失了智”,开始不停地胡言乱语、重试、陷入死循环……足足浪费了 20 次推理的钱。
为了解决这个问题,必须在底层 Unix 执行和大模型展示层之间,建立一道“二进制守卫(Binary Guard)”和“截断溢出守卫(Overflow Mode)”。
当探测到命令输出超过 200 行,或者包含二进制乱码时,系统绝不把原数据返回给大模型,而是强制拦截并返回提示:
“— 输出已截断。请使用 grep 或 tail 命令进行搜索。—”
这就像给大模型戴上了一副防护眼镜,彻底杜绝了上下文被垃圾数据污染、导致智力下降的可能。
目前,全网依然在乐此不疲地比拼谁的 Agent 框架更庞大、谁支持的 Tool Call 种类更多。但 原 Manus 大佬的这套“返璞归真”的血泪总结,给我们狠狠敲响了警钟。
最前沿的 AI,其实最需要最古老的系统智慧。
将 Unix 哲学的精髓(文本流、组合管道、小而美)与大模型的文本处理能力完美结合,放弃给 AI 制造复杂的隔离层和几十个脆弱的 API 接口,这才是真正属于“顶级工程师”的架构审美。
正如他在文末所言:“CLI 并非银弹,对于强类型校验和高安全性要求极高的场景,Typed API 依然不可或缺。但在广袤的智能体自主探索宇宙中,命令行,就是大模型所需要的全部。”
资料链接:https://www.reddit.com/r/LocalLLaMA/comments/1rrisqn/i_was_backend_lead_at_manus_after_building_agents
今日互动探讨:
你在写 Agent 时,是喜欢用框架提供的一大堆 Tool Calls,还是像这位大神一样,直接让大模型写代码/写命令去执行?在实战中你的 AI 发生过哪些最搞笑的“智障/幻觉”行为?
欢迎在评论区分享你的血泪避坑史!
还在为“复制粘贴喂AI”而烦恼?我的新专栏 《AI原生开发工作流实战》 将带你:
扫描下方二维码,开启你的AI原生开发之旅。

原「Gopher部落」已重装升级为「Go & AI 精进营」知识星球,快来加入星球,开启你的技术跃迁之旅吧!
我们致力于打造一个高品质的 Go 语言深度学习 与 AI 应用探索 平台。在这里,你将获得:
衷心希望「Go & AI 精进营」能成为你学习、进步、交流的港湾。让我们在此相聚,享受技术精进的快乐!欢迎你的加入!

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

© 2026, bigwhite. 版权所有.

本文永久链接 – https://tonybai.com/2026/03/06/building-claude-code-with-boris-cherny
大家好,我是Tony Bai。
想象一下,你加入了一家全球顶级的 AI 实验室,满怀热情地提交了第一个 Pull Request (PR)。然而,你的 PR 却被直接拒绝了。原因不是代码写得不好,而是——这代码是你“手写”的。
这不是科幻小说,这是 Boris Cherny 加入 Anthropic 时的真实经历。作为目前炙手可热的 AI 编程工具 Claude Code 的缔造者和工程负责人,Boris 曾是 Meta (前 Facebook) 最高产的程序员之一。但在 Opus 4.5 模型发布后,他的工作流发生了颠覆性的变化:现在,他每天可以提交 20 到 30 个 PR,且不再手动编辑任何一行代码。
在近期的一期深度访谈中,Boris 分享了 Claude Code 从一个内部黑客项目到爆款工具的演进历程,以及他对于 AI 时代软件工程未来的深刻洞察。

Claude Code 的前身是一个名为 “Clyde” 的内部原型。当 Boris 最初构思如何将 AI 融入编程时,他犯了一个很多开发者都会犯的错误:试图把 AI 当作系统中的一个组件。
在传统的思维模式下,我们倾向于把模型关在一个“盒子”里,为其定义严格的输入和输出接口(比如在 IDE 中高亮一段代码,然后让 AI 解释或补全)。但 Boris 很快意识到,这不是与大模型交互的正确方式。
“不要试图把它放进盒子里,不要强迫它以特定的方式行事。把模型看作一个独立的实体,给它工具,让它自己运行程序。”
这种被 Boris 称为“苦涩教训(Bitter Lesson)推论”的理念,成为了 Claude Code 的核心设计哲学。他赋予了模型执行 Bash 命令的权限,接着是读写文件系统的权限。当模型获得了与现实世界(操作系统)交互的能力后,奇迹发生了。
他举了一个早期的例子:他给了模型一个 Bash 工具,然后问它:“我正在听什么音乐?”模型竟然自己写了一段 AppleScript 脚本,调用 sed 等命令去查询本地的音乐播放器,并成功返回了答案。这一刻,Boris 感受到了真正的 AGI(通用人工智能)气息。
作为曾经 Meta 代码产量极高的工程师,Boris 现在的产出速度更是达到了令人咋舌的地步(每天 20-30 个 PR,从几行到几千行不等)。他是如何做到的?答案是大规模并行 Agent (Parallel Agents)。
他分享了自己目前极其硬核的终端工作流:
在这种模式下,Boris 不再是一个“打字员”,而化身为一个“交响乐团指挥”。他的核心工作从“思考如何实现”,变成了“思考业务逻辑的类型签名(Type Signatures)”和“验证模型的输出”。
这是每个工程团队都会面临的灵魂拷问。在 Anthropic 内部,高达 80% 的代码现在由 Claude Code 生成。那么,他们是如何把控质量的?
答案是:用 AI 审查 AI,辅以人类的最后防线。
面对 AI 展现出的恐怖编程能力,即便是前特斯拉 AI 总监 Andrej Karpathy 也感叹自己“从未如此落后过”。许多程序员感到恐慌:我们寒窗苦读十载练就的编码技能,是不是要变成屠龙之技了(变得稀有且遥远)?
Boris 给出了一个非常精彩且充满希望的隐喻:印刷术的发明。
在 15 世纪印刷术出现之前,“识字和抄写”是极少数人的特权。他们被国王雇佣,经过多年训练才能胜任。而当时的许多国王,甚至自己都是文盲。
“我们现在的软件工程师,就像是那些抄写员。而业务方(CEO/PM)就像是那些不懂技术的国王。”
当印刷术出现后,书籍的成本下降了百倍,数量增加了万倍。抄写员并没有消失,他们变成了作家、编辑、出版商。随着识字率的普及,整个知识市场迎来了前所未有的大爆炸,催生了无数在那之前根本无法想象的职业和产业。
今天,AI 编程工具就是软件工程界的“印刷术”。编程的门槛正在被无限拉低,原本不懂代码的业务人员、设计师、财务人员(在 Anthropic 内部,非技术人员使用 Claude Code 的比例接近 100%)都能直接将想法转化为软件。这不会消灭软件工程,而是会让软件的产量和应用场景呈指数级爆发。
在这场范式转移中,作为开发者,我们需要对技能树进行重新评估。
正在快速贬值的技能:
愈发珍贵的核心能力:
注:ADHD (注意力缺陷多动症) 式的工作法是一种灵活而高度分散注意力的工作风格,常常表现为多任务处理和非线性思维,能够快速切换多个任务并通过联想和直觉进行思考。这种方法倾向于将大的任务分解为小的、可管理的目标,以保持动力和成就感。同时,工作过程中的兴趣和关注点可能会快速变化,因此通常会采用短暂的工作间隔与休息时间。通过频繁调整和迭代的方式,ADHD式工作法能够帮助人们利用自身的优势,克服注意力集中的挑战。
在采访的最后,Boris 坦言自己也经常感到挣扎:模型进化的速度太快了,几个月前验证失败的架构理念,换个新模型可能瞬间就跑通了。
在这个时代,“智力上的谦逊 (Intellectual Humility)” 比过往的经验更重要。不要再用旧时代的标尺去衡量新世界的工具。承认 AI 可能比你写得快、甚至写得好,放下作为“手写代码匠人”的骄傲,去学习如何更好地指挥这支由超级大脑组成的交响乐团吧。
毕竟,未来不属于那些拒绝使用 AI 的人,而是属于那些知道如何用 AI 构建下一个时代的人。
资料链接:https://www.youtube.com/watch?v=julbw1JuAz0
你敢交出“键盘”吗?
Boris 的经历让我们重新思考什么是“专业”。如果你提交的 PR 仅仅是因为“这是我手写的”而被拒绝,你的第一反应会是什么?在你的团队中,是否已经有人开始尝试这种“指挥家”式的工作流?
欢迎在评论区分享你的看法!
还在为“复制粘贴喂AI”而烦恼?我的新专栏 《AI原生开发工作流实战》 将带你:
扫描下方二维码,开启你的AI原生开发之旅。

你的Go技能,是否也卡在了“熟练”到“精通”的瓶颈期?
继《Go语言第一课》后,我的《Go语言进阶课》终于在极客时间与大家见面了!
我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造!30+讲硬核内容,带你夯实语法认知,提升设计思维,锻造工程实践能力,更有实战项目串讲。
目标只有一个:助你完成从“Go熟练工”到“Go专家”的蜕变! 现在就加入,让你的Go技能再上一个新台阶!

想系统学习Go,构建扎实的知识体系?
我的新书《Go语言第一课》是你的首选。源自2.4万人好评的极客时间专栏,内容全面升级,同步至Go 1.24。首发期有专属五折优惠,不到40元即可入手,扫码即可拥有这本300页的Go语言入门宝典,即刻开启你的Go语言高效学习之旅!

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

© 2026, bigwhite. 版权所有.

本文永久链接 – https://tonybai.com/2026/02/08/claude-code-agent-team-mode
大家好,我是Tony Bai。
2026年2月6日凌晨,Anthropic 扔出了一枚重磅炸弹。
随着史上最强编程大模型 Claude Opus 4.6 的发布,官方博客披露了一个令人瞠目结舌的内部实验:
一个由 16 个 Claude Agent 组成的“全自动研发团队”,在基本没有人类干预的情况下,仅用两周时间,从零写出了一个 10 万行代码的 C 语言编译器,并且成功编译了 Linux 6.9 内核。
注意,这不是简单的代码补全,也不是写个贪吃蛇游戏。
这是系统级软件开发。它需要处理复杂的语法解析、中间代码生成、寄存器分配,以及对 x86、ARM、RISC-V 等多种架构的底层支持。
这一刻,我觉得我们之前熟悉的 AI 编程(Chat 模式、Copilot 模式)瞬间变得像是在玩玩具。
这是工业级 AI 生产力的黎明。
它标志着软件工程正在从“人机结对”进化为“智能体集群协作(Agent Team)”。

为什么之前的 AI 做不到这一点?
因为单体 Agent 的能力是有物理极限的。
Agent Team 模式 彻底打破了这个瓶颈。它引入了两个核心概念:并行 (Parallelism) 和 专业化 (Specialization)。
在这个实验中,Anthropic 启动了 16 个独立的 Docker 容器,每个容器里跑着一个 Claude Agent。
它们通过 Git 进行代码同步,通过文件锁(File Locking)来避免冲突。它们不睡觉,不喝咖啡,24 小时并行工作。
这不仅仅是人多力量大,更是分工明确。
这就是未来的软件开发:你不再是写代码的人,你是这个数字团队的 CTO。

除了架构上的突破,这次实验最让我震撼的是 AI 的测试策略。
写编译器最难的是什么?是验证它对不对。
Claude Agent Team 居然想出了一招“借鸡生蛋”:它们用成熟的 GCC 编译器 作为 Oracle(神谕/标准答案)。
这种“以 AI 之矛,攻 AI 之盾”的自动化测试闭环,让整个系统具备了惊人的自愈能力(Self-Healing)。它们不需要人类来 Review 代码,它们自己就能保证代码是 Work 的。
如果说 2025 年我们还在为 Coding Agent 的单点能力而欢呼,那么 2026 年的主旋律无疑是 Orchestration(编排),从2026年元旦Steve Yegge发布的GasTown,到此时此刻的Claude Code Agent Team。
当单个模型的智商(Opus 4.6)已经足够高时,如何组织它们协作,就成了新的护城河。
未来的软件工程,不再是研究 quicksort 怎么写,而是研究“如何设计一套 Agent 协作协议,让一群 AI 帮我写 OS”。
看了官方博客后,我第一时间在 Claude Code 中尝试了 Agent Team 模式。
实话说,效果确实炸裂。
我让它帮我重构一个复杂的 Go 项目,它自动拆解了任务:一个 Agent 去改接口定义,另一个 Agent 紧接着去修受影响的单元测试。原本需要我一下午的工作量,它们喝杯水的功夫就搞定了。
为了让大家也能用上这套“核武器”,我花了一整天时间,复现了 Agent Team 的配置流程,并踩平了所有的坑。
我在我的极客时间专栏《AI原生开发工作流实战》中,刚刚更新了一篇重磅加餐文章:《Agent Teams:打造你的第一支“虚拟研发团队”》。
在这篇加餐中,我将带你:
别再一个人战斗了。是时候组建你的 AI 军团了。
扫描下方二维码,立刻获取这份“数字 CTO”上岗指南。

你的“数字研发部”
如果现在给你 16 个全能的 Claude Agent,你最想让这个“数字研发部”帮你攻克的第一个难题是什么?是重构那个尘封已久的陈旧模块,还是现场撸一个你构思已久的个人操作系统?
欢迎在评论区分享你的“CTO 梦想”! 让我们一起迎接智能体集群协作的新时代。
你的Go技能,是否也卡在了“熟练”到“精通”的瓶颈期?
继《Go语言第一课》后,我的《Go语言进阶课》终于在极客时间与大家见面了!
我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造!30+讲硬核内容,带你夯实语法认知,提升设计思维,锻造工程实践能力,更有实战项目串讲。
目标只有一个:助你完成从“Go熟练工”到“Go专家”的蜕变! 现在就加入,让你的Go技能再上一个新台阶!

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

© 2026, bigwhite. 版权所有.

本文永久链接 – https://tonybai.com/2026/01/17/ai-era-cognitive-friction-as-your-last-moat
大家好,我是Tony Bai。
我们正在经历一场前所未有的知识通胀。
在 AI 时代,获取答案的成本已经降到了零。遇到 Bug?粘贴报错给 AI。写不出周报?给个主题让 AI 生成。想学新框架?让 AI 总结核心概念。
一切都变得无比丝滑,无比高效。
但你有没有发现,在这种“顺滑”的表象下,一种隐秘的症状正在蔓延:
《纽约时报》畅销书《五种财富》的作者Sahil Bloom 将这种症状称为 “AI Brain”(AI 大脑)。
这并不是说你变笨了,而是说你变钝了(Dull)。
就像一个长期坐轮椅的人,腿部肌肉必然会萎缩。当我们习惯了 AI 这种“认知轮椅”,我们大脑中负责深度思考、构建逻辑、处理混乱的那些神经连接,正在慢慢断开。
AI 消除了“摩擦”,但人类的智慧,恰恰诞生于“摩擦”之中。

我们一直被教育要追求效率,要消除阻力。但在认知科学领域,这个逻辑是反的。
真正的学习和创造,发生于“First-pass Thinking”(第一遍思考)的挣扎中。
当你面对一个复杂的架构难题抓耳挠腮时,当你面对一张白纸试图构建文章结构感到挫败时,请珍惜这种痛苦。
这正是你的大脑在“举铁”,神经突触正在高强度地建立新的连接。这种不适感,是你正在突破认知边界的信号。
如果你在这个时刻按下了 AI 的生成键,它确实给了你一个完美的答案,就像剥好了的送到嘴边的虾肉。但你失去了什么?
你失去了咀嚼、消化、甚至感受饥饿的机会。你跳过了“构建心理模型”的过程,直接快进到了结果。
外包了痛苦,也就外包了成长的机会。
那么,我们该如何对抗这种“认知萎缩”?并不是要扔掉 AI 回归原始,而是要主动设计“认知摩擦”。
Sahil Bloom 基于个人洞察,为我们总结了 4 条适合技术人的自救法则:
原则: I write before I refine.(先写再润色,而不是先生成再修改。)
不要一上来就让 AI 写代码或写草稿。
强迫自己写出那个烂透了的初稿,强迫自己先在白板上画出架构图的草图。
因为 AI 只能基于概率生成“平均值”,只有你的“第一遍思考”才带有“方差”——也就是你的原创性(Originality)和个性。
下次写文档,不妨先自己写 300 字的大纲,再让 AI 补充;而不是让 AI 生成大纲,你来修改。
原则: I sit with problems.(让问题飞一会儿。)
遇到难题,不要通过条件反射式地 Alt+Tab 切到 与大模型聊天的页面。
允许自己困惑,允许自己焦虑,允许自己在那里发呆 10 分钟。
这种“滞后”是必要的。它给了你的大脑后台进程运行的时间(思考脑启动)。很多深刻的洞察,往往是在你“卡住”的时候涌现的。
不妨设定一个“无 AI 时间窗口”。比如每天上午的头 2 小时,强制断开 AI 助手,只靠自己的大脑工作。
原则: One kick 10,000 times.(不怕千招会,只怕一招精。)
AI 让我们能做 100 件事:能写前端、能写后端、能画图、能剪视频。但每件事我们都只能做到 60 分的平庸水平。
既然 AI 把广度的成本降到了零,那么深度就成了唯一的护城河。
试试利用 AI 帮你处理那些琐碎的、低认知的杂事,然后把节省下来的精力,全部投入到那个 1% 的核心领域中去。钻研到连 AI 都无法回答的深度。
原则: Stay anchored.(保持锚定。)
AI 没有身体,没有痛感,没有疲惫。
人类的直觉、审美和同理心,建立在我们肉身的经验之上,这是 AI 永远无法模拟的底色。
动起来!去面对面交流,去感受代码运行在真实物理设备上的延迟,去用身体感受世界。这些“肉身经验”是你作为人类的最后防线。
我们正在进入一个“分化”的时代。
区别在于边界的划分。
Your future is defined by what you refuse to let AI do.
(你的未来,取决于你拒绝让 AI 做什么。)
请守住你的“思考领地”。
我可以让 AI 帮我优化代码,但我决不允许它替我设计架构;
我可以让 AI 帮我润色文字,但我决不允许它替我定义观点。
在这个充满“灰度”和“平庸”的 AI 生成世界里,请保持你大脑的“色彩”和“锋利(Sharp)”。
Don’t become dull.
你的“戒断”计划
读完这篇文章,你是否也意识到了自己对 AI 的过度依赖?如果让你现在关掉 AI 助手,你能独立完成手头的工作吗?你打算如何找回自己的“认知摩擦”?
欢迎在评论区立下你的 Flag,或者分享你的“人机边界”思考!让我们一起守护大脑的锋利。
如果这篇文章戳中了你的痛点,别忘了点个【赞】和【在看】,并转发给身边那些“沉迷 AI”的朋友,给他们提个醒!
深度实战:构建“以人为本”的 AI 工作流
在 AI 原生开发中,我们同样强调:User 必须是机长,AI 只是副驾驶。
如何在利用 AI 提效的同时,还能迫使自己进行深度的架构思考?
如何在 Spec-Driven Development (SDD) 中,保留人类的“第一遍思考”权利,让 AI 只做执行者?
欢迎关注我的极客时间专栏《AI原生开发工作流实战》。
在这里,我们不教你如何偷懒,我们教你如何利用 AI 进行更高维度的认知进化。
扫描下方图片二维码,开启你的进化之旅。

你的Go技能,是否也卡在了“熟练”到“精通”的瓶颈期?
继《Go语言第一课》后,我的《Go语言进阶课》终于在极客时间与大家见面了!
我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造!30+讲硬核内容,带你夯实语法认知,提升设计思维,锻造工程实践能力,更有实战项目串讲。
目标只有一个:助你完成从“Go熟练工”到“Go专家”的蜕变! 现在就加入,让你的Go技能再上一个新台阶!

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

© 2026, bigwhite. 版权所有.

本文永久链接 – https://tonybai.com/2026/01/17/go-rust-zig-simplicity-vs-control
大家好,我是Tony Bai。
在系统编程的世界里,开发者似乎总是面临着一个残酷的二选一:是选择极致的简单与生产力,还是选择绝对的控制与零成本抽象?
这种纠结在 Go 与 Rust 的长期对峙中体现得淋漓尽致。然而,近日一位拥有十年 Go 经验的资深开发者在Zig社区的分享,似乎为这场二元对立的战争撕开了一道口子。他从 Go 迁移到 Zig 的经历,既是一个技术选型的故事,也是一场关于“我们到底需要什么样的编程语言”的深度辩论。

对于许多 Gopher 来说,Go 的简单是其最大的武器,但也是最深的痛点。
这位楼主坦言,尽管他深爱 Go 的简单,但在编写某些复杂系统时,这种“过度简化”让他感觉语言本身存在缺陷。
如果嫌 Go 太简单,Rust 似乎是理所当然的替代者。但对于很多习惯了 Go “写完即运行”体验的开发者来说,Rust 的门槛是一堵高墙。
楼主表示,他喜欢 Rust 的核心概念(Structs, Enums, Option),但 Rust 为了内存安全而引入的借用检查器、生命周期以及复杂的异步模型,让他感觉“像是面对另一个 C++”。
这是一场灵魂拷问:为了获得控制权,我们真的需要背负如此沉重的认知包袱吗?
Zig 的出现,似乎精准地击中了 Go 与 Rust 之间的那个真空地带。对于这位 Gopher 来说,Zig 让他感到了久违的“刚刚好”:
当然,这场灵魂拷问没有标准答案。社区的讨论也极其理性地指出了选择 Zig 的代价:
这场讨论最终指向了开发者内心的自我定位:
简单还是控制?这不仅是语言的选择,更是你作为工程师,想要如何与机器对话的选择。
资料链接:https://www.reddit.com/r/Zig/comments/1q38e50/im_really_surprised_by_how_simple_it_is_to/
你的“灵魂选择”
在“简单”与“控制”的天平上,你的心偏向哪一边?如果让你现在开始一个新项目,你会毫不犹豫地选择 Go,还是想尝尝 Zig 的鲜,亦或是死磕 Rust?
欢迎在评论区投出你的一票,并分享你的理由! 让我们看看谁才是开发者心中的“白月光”。
如果这篇文章引发了你的选型思考,别忘了点个【赞】和【在看】,并转发给那个还在纠结学什么语言的朋友!
还在为“复制粘贴喂AI”而烦恼?我的新专栏 《AI原生开发工作流实战》 将带你:
扫描下方二维码,开启你的AI原生开发之旅。

你的Go技能,是否也卡在了“熟练”到“精通”的瓶颈期?
继《Go语言第一课》后,我的《Go语言进阶课》终于在极客时间与大家见面了!
我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造!30+讲硬核内容,带你夯实语法认知,提升设计思维,锻造工程实践能力,更有实战项目串讲。
目标只有一个:助你完成从“Go熟练工”到“Go专家”的蜕变! 现在就加入,让你的Go技能再上一个新台阶!

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

© 2026, bigwhite. 版权所有.

