阅读视图

发现新文章,点击刷新页面。
🔲 ☆

C++ 社区内部大讨论:新特性到底是“生产力革命”,还是“叠加的复杂性”?

本文永久链接 – 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++98 遗老、C++17 中坚与 C++23 先锋的“平行宇宙”

在这场大讨论中,我仿佛看到了 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++ 的“集市”哲学 vs 团队的“教堂”困境

为什么 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 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 精进营」能成为你学习、进步、交流的港湾。让我们在此相聚,享受技术精进的快乐!欢迎你的加入!

img{512x368}


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

© 2026, bigwhite. 版权所有.

🔲 ⭐

拒绝 Rust 的复杂,跨越 Go 的极简:Zig 会是系统级编程的最终答案吗?

本文永久链接 – https://tonybai.com/2026/02/26/rust-complexity-go-minimalism-vs-zig-ultimate-answer

大家好,我是Tony Bai。

在当前的后端与系统级编程领域,开发者似乎总是面临着一种“非此即彼”的艰难抉择:要么选择 Go 语言,拥抱其极致的极简主义、高效的并发模型和无处不在的垃圾回收(GC),但往往需要在底层内存控制上做出妥协;要么投向 Rust 的怀抱,追求绝对的内存安全和零成本抽象,却不得不常年与“借用检查器(Borrow Checker)”搏斗,忍受陡峭得令人绝望的学习曲线。

然而,在这两大巨头的光环之外,一门名为 Zig 的语言正在悄然崛起。它没有隐式的控制流,没有隐藏的内存分配,甚至没有预处理器和宏,却提供了无与伦比的 C 语言互操作性和强大的编译期计算能力。近日,在Reddit技术社区 r/Zig 上,一位资深 Go 开发者分享了他将一个核心项目从 Go 迁移到即将发布的 Zig 0.16 版本的全过程。他的经历既是一次跨越语言壁垒的技术冒险,更为我们揭示了一个深刻的问题:在拒绝了 Rust 的复杂、看透了 Go 的局限之后,Zig 会是我们苦苦寻找的那个系统级编程的最终答案吗?

在本文中,我们将跟随这位开发者的脚步,深度剖析这次从 Go 到 Zig 的“系统级”降维打击,探讨内存管理、并发演进以及新兴语言的生态阵痛。

语言选择的罗曼史:为什么是 Zig?

对于任何一位有着丰富经验的开发者来说,选择一门新的编程语言绝非心血来潮。在这位开发者长长的技术履历中,我们看到了一条清晰的“硬核化”演进路线:Python -> Rust -> Go -> Odin -> Zig

这条路线背后,折射出的是当代开发者对“开发效率”与“系统控制力”双重渴望的矛盾与挣扎:

  1. 逃离 Python 的脆弱:动态类型的 Python 常常伴随着难以预料的运行时错误,加上令人抓狂的虚拟环境(venv/pip)管理,促使他开始向底层探索。
  2. 被 Rust 劝退的恐惧:开发者坦言,“Rust 是我尝试过的最复杂的语言”。尽管他勉强写出了 Rust 代码,但他自知那是“糟糕的 Rust”。面对陡峭的学习曲线和心智负担,他的结论异常真实:“Rust 可能很容易学,但我不想再哭一次了(don’t want to cry again)”。
  3. Go 语言的温柔乡:在众多高级语言中,Go 成了他最钟爱的归宿。他将 Go 评价为“最低级别的高级语言(lowest of the high level languages)”。对于 Web 服务和后端开发,Go 的极简语法、成熟的生态和开箱即用的特性,使其成为默认的终极选择。他甚至感慨:“我真希望我一开始就是用 Go 学编程的。”
  4. Odin 的中道崩殂:在追求比 Go 更底层的控制力时,他曾短暂尝试过 Odin(一门常与 Zig 齐名的面向数据设计的系统级语言)。Odin 在语法上介于 Go 和 Zig 之间,看似完美的平衡却被糟糕的工具链打破。频繁崩溃的 LSP(Language Server Protocol)、不完善的文档以及诡异的编译器指令,最终将他推开了。
  5. 情定 Zig:最终,Zig 成为了他的驻足之地。Zig 既提供了不输于 C 语言的底层掌控力,又通过创新的语法和工具链,避开了 Rust 复杂的生命周期管理。

从中我们也可以看出当下系统级编程领域的一道缩影:开发者们渴望获得底层控制权,但不想为此付出丧失开发体验的代价。

移植实战:从 1 周到 2 个月的“阵痛与重塑”

纸上得来终觉浅。这位开发者决定动真格:将一个由 Go 编写的基于内存互斥锁(Mutex)的键值对存储(Key/Value Store)及配套的通道预写日志(channel WAL)项目,完整地移植到 Zig 0.16 中(包括使用 LZ4 压缩和导出 Parquet 格式的功能)。

原计划只需要 1 周的迁移工作,最终演变成了一场长达 1.5 到 2 个月的持久战。为什么会这么耗时?

代码规模与表达力:意外的对等

令人惊讶的是,尽管 Zig 需要手动管理内存,但迁移后的代码量(约 750 行)与原先的 Go 代码几乎持平。开发者指出,虽然 Zig 的代码在视觉上“更宽”(得益于其极其丰富的表达能力),但行数并没有膨胀。这归功于 Zig 中 Unions(联合体)、Enums(枚举)、Errors(错误处理)和 Structs(结构体)的完美组合。

拥抱 Comptime:降维打击的“超能力”

在 Go 语言中,泛型(Generics)直到 1.18 版本才姗姗来迟,且其能力受到诸多限制。而在 Zig 中,开发者体验到了真正的震撼——Comptime(编译期执行)。

他将处理结构体类型的泛型能力称为“疯狂的超能力”。在编译期间执行任意 Zig 代码的能力,使得开发者能够以极低的运行时开销,实现高度动态和灵活的类型处理。这种对类型的编译期反射和操作,是 Go 语言开发者难以想象的体验。

代码组织方式的颠覆

Go 语言习惯于将不同的接口、结构体分散在多个文件中,利用包(Package)级别来进行组织。但在 Zig 中,开发者发现了一种全新的心智模型:将所有想法放入一个文件中,并通过结构体(Struct)进行分组。当代码在编辑器中折叠后,这种高度内聚的设计显得极其清晰且易于导航。

内存管理的洗礼:脱离 GC 后的生存法则

从自带垃圾回收(GC)的 Go 语言跨越到需要显式传递分配器(Allocator)的 Zig,是此次移植中最痛苦,也是收获最大的部分。

没有了 Go 运行时的庇护,开发者必须直面内存的生与死。在经历了无数次内存泄漏后,他总结出了针对 Go 开发者转战 Zig 的七条黄金生存法则:

  1. 返回内存的函数,必须接收 Allocator:在 Go 中,函数可以随意返回指针或切片,GC 会负责善后。在 Zig 中,任何产生新内存分配的函数,其签名中必须显式包含一个 Allocator 参数。

  2. 严格区分不可变与可变:[]const u8 表示你绝不会修改这块内存(只读切片),而 []u8 则意味着你承诺你会去修改这块内存。这种显式的意图声明,在 Go 的 []byte 中是缺失的,Go 开发者往往需要通过文档或约定来判断切片是否会被修改。而在 Zig 中,类型系统替你守住了这道防线。

  3. 所有权与复制 (allocator.dupe):在 Go 中,传递指针或切片非常廉价,垃圾回收器(GC)会处理共享引用的生命周期。但在 Zig 中,如果你需要保留传入的数据并在函数返回后继续使用,你必须使用 allocator.dupe 进行深拷贝。

  4. 内存分配失败是常态:任何分配都可能失败。在 Zig 中,这意味着你必须处理 Error Union。而在 Go 中,make 或 new 失败通常意味着程序崩溃(panic),大多数业务代码从不处理 OOM(内存溢出)。

  5. 测试即救赎 (std.testing.allocator):“不写测试,就等着受苦”。Zig 的标准库测试运行器内置了内存泄漏检测功能。使用 std.testing.allocator 运行测试,如果你的代码有泄漏,测试会直接失败并报告。这对于习惯了“分配后即遗忘”的 Go 开发者来说,简直是当头棒喝,但也是养成良好习惯的最佳工具。

  6. 源码即文档:遇到疑问时,直接读标准库源码 (std)。Go 的标准库以清晰著称,但 Zig 的标准库源码同样展示了惊人的可读性。由于没有隐藏的控制流和宏,你看到的即是实际发生的。

并发模型之争:Goroutine 的舒适区 vs Zig 的显式控制

Go 语言最大的护城河无疑是 Goroutine 和 Channel。这种 CSP(通信顺序进程)模型的极简实现,让并发编程变得唾手可得。然而,当这位开发者试图在 Zig 中复刻这一模式时,遭遇了不小的挑战。

误用 std.Thread 的代价

在移植过程中,他试图使用 Zig 的 std.Thread 配合 std.Thread.RwLock 来模拟 Go 的并发模式。然而,一位社区专家指出,这种做法在 Zig 的异步 I/O 体系下是危险且低效的。

Zig 的并发哲学与 Go 不同。Go 将同步(阻塞)代码在运行时自动调度到异步执行,而 Zig 则提供了显式的 async/await(注:Zig 的异步机制在不同版本间变动较大,0.16 预览版中正在重构)和基于事件循环的 IO 模型。

io.Queue 与 Channel 的缺失

为了实现类似 Go Channel 的功能,开发者不得不自己实现了一套基于 Mutex 的通知机制,或者使用第三方库。他坦言:“我不仅想念 Go 的 GC,也想念它的 Channel。”

虽然 Zig 提供了强大的底层原语,但在构建像 Go 那样开箱即用的高并发 Web 服务时,Zig 目前仍缺乏统一且成熟的标准范式(Standard Pattern)。对于习惯了 go func() 的开发者来说,这需要巨大的心智转换。

工具链与生态的阵痛:先行者的代价

如果你已经被 Zig 的性能和控制力打动,那么接下来的内容可能是你需要冷静思考的“劝退”环节。

版本的混沌:0.15 vs 0.16

Zig 尚未发布 1.0 版本,这意味着破坏性更新(Breaking Changes)是家常便饭。该开发者在尝试迁移到 Zig 0.16(开发版)时,遇到了 ZLS(Zig Language Server)的版本兼容性问题。编辑器报错、高亮失效、自动补全崩溃,这些在 Go 这种成熟语言中几乎不存在的问题,在 Zig 的日常开发中却是必须忍受的噪音。

文档的匮乏

“当有疑问时,请检查 Zig 的内置函数(Builtin functions),那里有很多东西。”这句话的潜台词是:不要指望有详尽的官方文档网站。与 Go 丰富且结构化的 pkg.go.dev 相比,Zig 目前更多依赖于阅读源码和社区碎片化的教程。对于习惯了 StackOverflow 复制粘贴的开发者,这无疑是一个巨大的门槛。

“Segmentation Fault” 的回归

正如社区评论所言:“你必须爱上 Segfaults(段错误)。”

Go 语言的运行时捕获了绝大多数底层错误,将其转化为 Panic。而在 Zig 中,尽管有安全模式(ReleaseSafe),但在处理底层指针操作时,你依然可能遇到这一古老的梦魇。开发者回忆道:“我在 2008 年写 C 语言时经常遇到这些,现在我必须重新学会如何调试它们。”

小结:Go 依然是王者,但 Zig 代表了未来?

回到最初的问题:Zig 会是系统级编程的最终答案吗?

通过这次深刻的迁移实战,我们可以得出以下结论:

  1. Go 的地位难以撼动:对于绝大多数 Web 后端、微服务和云原生应用,Go 依然是“性价比之王”。它在开发效率、运行时性能和维护成本之间找到了完美的平衡点。正如作者所说,“Go 是最高级语言中的最底层”,这个定位极其精准。
  2. Rust 并非唯一解:对于那些需要更高性能、更低内存占用,却被 Rust 陡峭的学习曲线和复杂的借用检查器劝退的开发者,Zig 提供了一个极具吸引力的第三选项。它证明了不引入复杂的生命周期注解,依然可以写出安全且高效的系统级代码。
  3. Zig 的甜点区:如果你的项目涉及大量的内存密集型操作、需要极致的启动速度、或者需要与 C 库进行深度交互,Zig 可能比 Go 更合适,也比 Rust 更易上手。

给 Go 开发者的建议:

如果你仅仅是对 Go 的某些性能瓶颈感到不满,不妨先通过 FFI 调用 Zig 编写的库来解决关键路径的性能问题,而不是全面重写。Zig 极其优秀的 C 互操作性,使其成为 Go 语言的最佳“外挂”。

随着 Zig 0.16 及后续版本的发布,特别是异步 IO 模型和包管理器的成熟,我们有理由相信,Zig 将在系统编程领域占据一席之地。它不会取代 Go,但它可能会成为那些追求极致掌控力的极客们手中的那把“光剑”。

资料链接:https://www.reddit.com/r/Zig/comments/1rd0fsz/thoughts_after_porting_a_project_from_go_to_zig/


聊聊你的选择

你会因为 Go 的 GC 开销而考虑尝试 Zig 吗?还是你宁愿忍受 Rust 的编译器也不愿自己管理内存?欢迎在评论区分享你的看法!


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

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

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


你的Go技能,是否也卡在了“熟练”到“精通”的瓶颈期?

  • 想写出更地道、更健壮的Go代码,却总在细节上踩坑?
  • 渴望提升软件设计能力,驾驭复杂Go项目却缺乏章法?
  • 想打造生产级的Go服务,却在工程化实践中屡屡受挫?

继《Go语言第一课》后,我的《Go语言进阶课》终于在极客时间与大家见面了!

我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造!30+讲硬核内容,带你夯实语法认知,提升设计思维,锻造工程实践能力,更有实战项目串讲。

目标只有一个:助你完成从“Go熟练工”到“Go专家”的蜕变! 现在就加入,让你的Go技能再上一个新台阶!


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

© 2026, bigwhite. 版权所有.

🔲 ☆

AMP 宣布砍掉 VS Code 插件:为什么说“人机结对编程”已死?

本文永久链接 – https://tonybai.com/2026/02/09/amp-kills-vscode-plugin-human-ai-pair-programming-is-dead

大家好,我是Tony Bai。

如果一家 AI 编程工具公司,宣布砍掉它最受欢迎、用户量最大的产品入口,你会怎么想?

这听起来像是商业自杀,但这正是 AMP(从 Sourcegraph 孵化出来的 AI 编程 Agent)刚刚做出的决定。

2026 年 2 月的一期播客中,AMP 的创始人 Thorsten 和 Quinn 宣布:将在 60 天后,彻底关停 AMP 的 VS Code 插件和 Cursor 扩展。

要知道,在过去的两年里(2024-2025),IDE 侧边栏(Sidebar)几乎定义了 AI 编程的标准形态。无论是 GitHub Copilot、Cursor 还是早期的 AMP,我们都习惯了在编辑器里写代码,在侧边栏里和 AI “乒乓球”式地对话。

但 AMP 团队认为:这个时代结束了。

“你看着代码,AI 在侧边栏看着你,你们一来一回地对话……这种模式不是未来。对于那 1% 想要活在未来的开发者来说,侧边栏不仅不是助力,反而是枷锁。”

为什么他们敢于“烧掉桥梁”?因为一种全新的开发范式——“AI软件工厂模式(The Factory)”,正在随着 GPT-5.2 和 Claude Opus 4.5的成熟以及新版本编程大模型的发布而全面爆发。

今天,我们深度解读这份极具前瞻性的访谈,看看为什么 IDE 侧边栏必死,以及未来的软件工厂究竟长什么样。

Deep Mode:当 AI 学会了“深思熟虑”

要理解为什么要砍掉侧边栏,首先要理解模型能力的质变。

在 2025 年之前,主流模型(如 Claude 3.5 Sonnet)的特点是“聪明但急躁”。它们非常适合 Smart Mode:你问一个问题,它秒回一段代码;你报错,它秒回修正。这是一种高频的、实时的“结对编程”体验。

但随着 GPT-5.2 Codex 的发布,情况变了。

AMP 推出了一个新的模式:Deep Mode(深度模式)。

  • 特性:这个模型不爱说话,它爱干活。它不是“懒惰”,而是“深沉”。
  • 特工作流:你给它一个模糊但宏大的目标(例如“重构整个鉴权模块并适配新的安全协议”),然后你就可以走开了。
  • 特时延:它可能会运行 45 分钟甚至 60 分钟。它会自主查阅文档、搜索代码、尝试方案、遇到错误、自我修正、运行测试,直到最终交付结果。

“侧边栏”完全无法承载这种体验。

想象一下,如果你在 IDE 侧边栏里发了一个指令,然后 AI 转了 45 分钟圈圈,期间你不敢关窗口,不敢切分支,这是一种多么糟糕的体验?

结论 1:

当 AI 的能力从“秒级补全”进化到“小时级任务”时,它必须脱离 IDE,进入后台,成为一个独立的Worker,而不是依附于编辑器的 Assistant。

惊人的抉择:Agent DX > Human DX

访谈中透露了一个令人细思极恐的细节,揭示了 AI 原生开发时代的价值观重构。

AMP 团队为了优化内部的开发效率,重写了他们的构建工具。

他们用 Zig 语言重写了 svelte-check,将其命名为 zvelt-check。这样做的目的是为了让 Agent 跑得更快,且输出的日志更结构化(便于 Agent 解析)。不过,这个新工具也破坏了 VS Code 对 Svelte 的原生支持(Human DX 下降)。人类开发者在编辑器里看到的错误提示变差了,甚至失去了一些高亮功能。

在“人类体验(Human DX)”和“智能体体验(Agent DX)”发生冲突时,AMP 选择了后者。

甚至有一半使用 NeoVim 的员工表示:“我不在乎 VS Code 体验变差,只要 Agent 跑得快就行。”

这是一个标志性的时刻。

长久以来,所有的开发者工具(CLI、Linter、Log)都是为了“让人类读懂”而设计的。我们需要漂亮的颜色、进度条、友好的报错提示。

但在 AI 时代,90% 的工具调用者将是 Agent。Agent 不需要颜色,不需要进度条,它们需要的是极致的速度、结构化的 JSON 输出、幂等的执行逻辑。

结论 2:

未来的工具链,将优先为 AI 优化。如果一个工具对人类不友好但对 AI 友好,它依然会被采用。我们正在主动劣化人类的开发体验,以换取 AI 生产力的十倍跃迁。

软件的消融:从 SaaS 到 Text

访谈中提到了一个名为 “The Melting of Software(软件的消融)” 的概念。这不仅影响开发工具,更影响我们构建产品的方式。

案例 A:Ryan Florence 的健身教练

Ryan 没有使用任何健身 App。他只是打开了 ChatGPT 的语音模式,说:“我在家里的健身房,指导我锻炼。”

AI 说:“做一组深蹲,好了叫我。”

Ryan 做完说:“好了。”

AI 说:“休息 60 秒。”

没有 UI,没有按钮,没有 App。软件消失了,只剩下服务。

案例 B:购物清单的回归

Torston 本想用 Agent 自动化管理 Todoist(一个著名的待办事项 App)。

但他突然意识到:“我为什么要用 Todoist?我的购物清单只有 15 项。Agent 可以直接在一个纯文本文件里管理它。”

如果 Agent 能读懂文本,能实时更新状态,能通过 CLI 提醒我,那我为什么还需要一个复杂的 SaaS 软件?

这指向了一个终极问题:当 Agent 能够理解非结构化数据,并能通过原子化工具(如Skills)操作一切时,传统的“应用软件”是否会大量消亡?

未来的软件,可能不再是精心设计的 GUI,而是一组 Skills(能力) + Context(上下文文件)。

  • 你不需要 Google Cloud 的网页控制台,你只需要给 Agent 一个 gcloud 的 Skill。
  • 你不需要 Jira 的复杂界面,你只需要一个能读写 Markdown 的 Agent。

结论 3:

软件正在退化为 API 和数据,中间的“交互层”正在被 Agent 接管。

技能(Skills):新的抽象层

既然侧边栏死了,我们靠什么来通过 AI 开发?

答案是:CLI + Skills

AMP 团队展示了他们如何在内部大量使用 Skills。

  • Tmux Skill:教 Agent 如何在终端里正确使用 Tmux,如何杀掉进程(甚至包括“记得按两次 Ctrl-C”这种经验知识)。
  • Google Cloud Skill:赋予 Agent 使用 Google Cloud CLI 的能力。
  • BigQuery Skill:这被描述为“最神奇的体验”。你问:“多少用户用了这个功能?”,Agent 自动写 SQL,查 BigQuery,返回结果。

Skills 是“经验的固化”。

当你教会 Agent 解决一个问题后,让它把过程总结成一个 Skill。下次,它(以及团队里的其他 Agent)就不会再犯错。

这比在 Chat 窗口里一遍遍写 Prompt 要高效得多。

组织哲学:像艺术装置一样自我毁灭

为什么 AMP 敢于砍掉 VS Code 插件?这源于他们独特的公司哲学。

“我们就像一个艺术装置(Art Installation),随时准备自我毁灭和重建。”

在这个技术每 3 个月就迭代一代的疯狂时代,“护城河”是最大的陷阱。

  • GitHub Copilot 曾经是王者,Cursor 出来后它显得老了。
  • Cursor 曾经是王者,Claude Code 和 AMP 出来后,编辑器模式显得老了。
  • 也许 3 个月后,OpenClaw 这样的纯本地 Agent 会让现在的模式也显得老了。

AMP 的 CEO 说:“如果我们因为‘用户习惯’而保留旧功能,我们就会变成哪怕是最好的‘落伍者’。我们必须每 3 个月重新赢得我们的客户。”

“Run towards the fire.”(向着炮火前进。)

如果你看到某个技术趋势正在颠覆你,不要躲避,不要观望,加入它,甚至成为颠覆自己的人。

小结:给 1% 的开发者

这篇文章可能让大家感到不安。

你习惯了 VS Code,习惯了 Copilot 的自动补全,习惯了掌控一切。

但在 2026 年的视野里,“人机结对”只是一个过渡形态

真正的未来属于 Agentic System(智能体系统),属于 Factory(软件工厂)

在那个未来里:

  • 你不再是写代码的人,你是定义 Spec 的人。
  • 你不再在编辑器里工作,你在终端(CLI)里指挥。
  • 你不再管理代码,你管理智能体集群

对于那 1% 愿意走出舒适区、拥抱“Factory Mode”的开发者来说,你们的生产力将不再是线性的增长,而是指数级的爆发。

侧边栏已死,工厂万岁。

资料链接:https://www.youtube.com/watch?v=4rx36wc9ugw


你愿意为效率牺牲体验吗?

AMP 为了 Agent 效率主动劣化人类开发体验(Agent DX > Human DX),这一决定让你感到兴奋还是不安?如果一个工具能让你效率提升 10 倍,但代价是你再也看不清语法高亮,你会接受吗?

欢迎在评论区分享你对“AI 软件工厂”的看法!


提前布局你的“软件工厂”

虽然我们还不能完全抛弃编辑器,但 AMP 倡导的 Agent-Native 开发流,现在就可以开始实践。

在我的极客时间专栏AI 原生开发工作流实战中,我们将深度对齐这种前沿理念:

  • CLI First:如何脱离 IDE,使用 Claude Code 在终端完成全流程开发?
  • Skill Engineering:如何编写高质量的 Skill,让 Agent 掌握你独有的业务知识?
  • Agent DX 优化:如何改造你的项目结构,让它对 AI 更友好?

不要等了。扫描下方二维码,现在就构建你的未来开发流。


你的Go技能,是否也卡在了“熟练”到“精通”的瓶颈期?

  • 想写出更地道、更健壮的Go代码,却总在细节上踩坑?
  • 渴望提升软件设计能力,驾驭复杂Go项目却缺乏章法?
  • 想打造生产级的Go服务,却在工程化实践中屡屡受挫?

继《Go语言第一课》后,我的《Go语言进阶课》终于在极客时间与大家见面了!

我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造!30+讲硬核内容,带你夯实语法认知,提升设计思维,锻造工程实践能力,更有实战项目串讲。

目标只有一个:助你完成从“Go熟练工”到“Go专家”的蜕变! 现在就加入,让你的Go技能再上一个新台阶!


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

© 2026, bigwhite. 版权所有.

❌