2025-12-29 14:08:12
本文永久链接 – https://tonybai.com/2025/12/29/why-many-software-engineers-still-ignore-ai-programming
大家好，我是Tony Bai。
“我注意到一件让我非常惊讶的事：似乎大多数软件工程师并没有充分利用（甚至根本不用）像 Claude Code、Cursor 或 GitHub Copilot 这样的 AI 编程工具。
我所在的自由职业者社区里，每个人都在疯狂压榨这些工具的极限，生产力飙升。但当我和传统公司的工程师聊天时，画风完全不同。大多数人几乎不用 AI，公司文化也不支持。
自由职业者/早期采用者与普通大厂员工之间，似乎出现了一道巨大的鸿沟。”
近日，Reddit 上的一篇热帖，再次引爆了关于“AI 编程”的讨论。显然，这不仅是一个技术问题，更是一场关于职业生存、工程伦理与未来选择的深刻辩论。
为什么在 AI 席卷全球的今天，仍有大量工程师选择“无视”甚至“抵制”它？这背后的原因，远比“懒惰”或“守旧”要复杂得多。
对于许多资深工程师来说，拒绝 AI 的首要原因不是“傲慢”，而是恐惧——对不可控代码的恐惧。
一位 20 年经验的老兵在高赞评论中写道：
“AI 工具既棒极了又糟透了。它们能飞快地生成代码，但也会以一种极具想象力或极其隐蔽的方式破坏整个系统，让你花上几个小时去修补。”
这道出了无数人的心声。自己写的代码，就算有 Bug，你也知道逻辑脉络；而 AI 生成的代码，虽然看着像模像样，但你不仅要理解它，还要审查它是否引入了安全漏洞、性能陷阱或是荒谬的幻觉。
“如果我花了 80% 的时间在构思，20% 的时间在写代码。AI 颠倒了这个过程，但我那 80% 的时间变成了帮 AI 擦屁股。” 一位开发者如是说。
帖主观察到的“鸿沟”，其实是生存环境的差异。
一位开发者总结得精辟：“微服务架构、遗留代码和复杂的业务逻辑，是 AI 目前难以逾越的护城河。”
这里出现了一个有趣的“技能倒挂”现象。
正如评论所言：“用 AI 编程就像坐自动驾驶的车。新手觉得‘哇，车自己会动！’，老司机则时刻把手放在方向盘上，因为他知道这玩意儿随时可能把车开进沟里。”
这场讨论最终指向了一个终极问题：软件工程师的未来是什么？
有人悲观：“这就像当年会计师抵制 Excel 一样。拒绝工具的人，最终会被淘汰。”
有人乐观：“AI 将消灭平庸的‘代码搬运工’，但会放大真正懂得系统设计、能解决复杂问题的工程师的价值。”
无论你属于哪个阵营，一个趋势是不可逆转的：编码（Coding）本身的门槛正在降低，但工程（Engineering）的门槛并未改变，甚至在提高。
未来的工程师，可能分为两类：
回到最初的问题：“为什么很多人无视 AI？”
但对于我们每一个个体而言，最危险的态度是“傲慢的无视”。你可以因为安全原因不用，可以因为质量原因少用，但绝不能因为“看不起”而不去了解。
去试一试吧。 不要只用它写 Hello World，试着让它重构一个函数，写一个测试，解释一段晦涩的代码。了解它的上限，摸清它的下限。
因为在不久的将来，评价一个工程师的标准，或许不再是你写代码有多快，而是你能多好地驾驭这个不知疲倦、偶尔发疯、但潜力无限的“硅基队友”。
资料链接：https://www.reddit.com/r/ClaudeAI/comments/1ot9b8n/why_are_so_many_software_engineers_still_ignoring/
你属于哪一类？
在AI浪潮面前，你觉得自己更像是一个在荒野中狂奔的“猎人”，还是在城堡中坚守的“守卫”？你所在的团队对AI编程持什么态度？
欢迎在评论区分享你的真实处境和思考！
还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：
扫描下方二维码，开启你的AI原生开发之旅。
你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？
继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！
我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。
目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！
商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。
© 2025, bigwhite. 版权所有.
2025-12-29 07:22:10
本文永久链接 – https://tonybai.com/2025/12/29/go-community-new-sum-type-end-interface-union-types
大家好，我是Tony Bai。
“Go 什么时候支持枚举？”
“Go 什么时候有真正的联合类型？”
这可能是 Go 语言诞生以来，被问得最多的问题之一。现有的解决方案——无论是用 const 模拟枚举，还是用 interface{} 配合类型断言模拟联合类型——在类型安全、表达力和穷尽性检查上，都总让人感觉“差了那么一点意思”。
近日，Go 核心团队成员 neild 在 GitHub 上发起了一个非正式的讨论 (#76920)，抛出了一种全新的、非接口 (non-interface) 的联合类型设计构想。这个构想虽然只是一个“思想实验”，却迅速引爆了社区的热情，成为了近期最热门的话题之一。
本文将带你深入这场讨论的核心，看看这个名为 union 的新类型，究竟有何魔力。
在深入设计之前，让我们先回顾一下，为什么我们如此渴望这个特性。neild 列举了三个极具代表性的场景：
目前，我们通常使用 interface 来模拟这些场景。但 neild 指出，接口并不是最佳方案：
neild 提出的方案，不仅巧妙，而且极具 Go 风格。他的核心洞察是：Struct 是“积类型” (Product Type)，Union 是“和类型” (Sum Type)。既然它们是对偶的，为何不使用相似的语法呢？
// 积类型 (Struct): 同时包含所有字段
type Point struct {
X int
Y int
}
// 和类型 (Union): 包含且仅包含其中一个变体
type Direction union {
North, South, East, West atom
}
type Maybe[T any] union {
Unset atom
Set T
}
type IP union {
IPv4 [4]byte
IPv6 [16]byte
}
这里引入了一个新概念：atom（也可以叫 unit 或其他名字）。它本质上是 struct{} 的别名，用于表示那些不携带数据、只代表某种状态的变体（如 North 或 Unset）。
这种设计的美妙之处在于：
这个设计不仅在定义上优雅，在使用上也力求符合 Go 的直觉。
你可以像使用结构体字面量一样构造 Union，但只能指定一个键：
d := Direction{North: atom{}} // 或者简化为 d := Direction.North
m := Maybe[int]{Set: 42}
对于 atom 类型的变体，访问它返回一个布尔值；对于携带数据的变体，访问它返回数据和布尔值（类似 map 的查找）：
if d.North {
fmt.Println("Heading North")
}
if v, ok := m.Set; ok {
fmt.Println("Value is:", v)
}
这是 Sum Types 最强大的地方——穷尽性检查。
switch d.(union) {
case North:
// ...
case South:
// ...
// 如果漏掉了 East 或 West，编译器会报错！
}
这种编译期的保障，彻底消除了“忘记处理某种情况”的 Bug 来源，是构建健壮系统的基石。
虽然大方向得到了广泛认可，但在具体细节上，社区展开了激烈的讨论。
neild 提议对 atom (即 struct{}) 进行特殊处理，使其可以直接作为值使用（如 Direction.North）。但这引起了 ianlancetaylor 等人的担忧：这种特殊规则是否会增加语言的复杂性和不一致性？如果不特殊处理，写 Direction{North: struct{}{}} 又实在太啰嗦了。
atom 这个名字是否合适？有人建议使用 null，有人建议复用 iota，还有人建议直接允许 union { North, South } 这种省略类型的语法。这再次证明了，“命名”永远是计算机科学中最难的问题之一。
如果 Union 是泛型的，如何处理？Maybe[T] 是一个完美的例子。但如果 T 本身也是一个 Union 呢？嵌套的 Union 及其 Switch 语句该如何设计？这些都是需要深思熟虑的边缘情况。
尽管 #76920 目前只是一个“讨论”，并非正式提案，但它释放了一个强烈的信号：Go 团队也许正在认真思考如何以一种“地道”的方式引入和类型(Sum Type)。
这个设计方案，在保持 Go 语言简单性的同时，极大地增强了其表达力和安全性。它避开了接口的动态性陷阱，提供了一种静态的、高效的、内存布局可控的数据结构。
如果这个构想最终能成真，它将填补 Go 语言类型系统中最后一块重要的拼图，让我们彻底告别用 iota 和 interface{} 拼凑枚举与联合类型的日子。
资料链接：https://github.com/golang/go/issues/76920
你的态度是？
对于这个打破常规的 union 语法设计，你是感到兴奋，觉得它终于填补了 Go 的拼图？还是感到担忧，觉得它让 Go 变复杂了？
如果给你一张选票，你会支持这个提案落地吗？
欢迎在评论区投出你的一票，并分享你的理由！ 让我们一起见证 Go 语言的演进。
如果这篇文章让你对 Go 的未来有了新的期待，别忘了点个【赞】和【在看】，并分享给身边的 Gopher 朋友！
还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：
扫描下方二维码，开启你的AI原生开发之旅。
你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？
继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！
我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。
目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！
商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。
© 2025, bigwhite. 版权所有.
2025-12-28 08:00:00
本文永久链接 – https://tonybai.com/2025/12/28/state-of-ai-vs-human-code-generation-report
大家好，我是Tony Bai。
“天下武功，唯快不破。但在软件工程里，‘快’可能是致命的诱惑。”
2025 年，AI 编码助手/智能体已经成为开发者的标配。它像蜜糖一样，让我们尝到了开发效率飙升的甜头：从自然语言一键生成函数，到自动补全繁琐的样板代码，甚至的整个项目的源码，功能交付周期从未如此之短。
然而，CodeRabbit 最新发布的《2025 年度 AI 与人类代码生成现状报告》却揭示了这层甜蜜糖衣下的残酷真相：Bug 激增、逻辑漏洞百出、安全隐患翻倍。
如果不加控制，这些由 AI 快速生成的劣质代码，很可能成为慢性发作的砒霜，最终毒害整个代码库的健康。这份报告用触目惊心的数据告诉我们：在享受 AI 带来的速度红利时，我们必须建立起更强大的免疫系统。
CodeRabbit 分析了 470 个开源项目的 Pull Requests (PR)，其中 320 个由 AI 参与编写。结果显示，AI 并不是那个完美的“超级程序员”，它更像是一个高产但粗心的实习生。
这是最核心的发现。AI 参与的 PR 平均每 100 个包含 10.83 个问题，而人类纯手工编写的 PR 只有 6.45 个。这意味着，引入 AI 后，你的 Code Review 工作量不仅没有减少，反而可能翻倍。
这是最令人担忧的数据。AI 生成的代码在业务逻辑、依赖关系和控制流方面，错误率比人类高出 75%。
为什么？
因为 AI 只是在做“统计学上的模仿”，它并不真正理解你的业务规则。它能写出语法完美的代码，但却可能在转账逻辑里漏掉一个关键的校验。
AI 在处理敏感信息时表现堪忧。硬编码密码、不安全的对象引用等低级错误，在 AI 代码中出现的频率是人类的近 3 倍。AI 倾向于模仿它在训练数据中看到的“旧代码”，而那些旧代码中往往充满了过时的、不安全的模式。
虽然 AI 生成的代码乍一看很工整，但在命名规范、代码结构和上下文一致性上，它往往与现有代码库格格不入。这种“违和感”大大增加了后续维护者的认知负荷。
报告不仅列出了数据，还深刻剖析了 AI 犯错的根本原因。为什么它这么快，却又这么容易错？
既然 AI 有这么多坑，我们是否应该因噎废食，放弃使用它？
当然不是。AI 依然是强大的加速器，前提是我们必须为它加上“护栏”。 未来的软件工程，不再是“写代码”，而是“设计系统来生成和验证代码”。
CodeRabbit 给出了几条务实的建议：
不要只给 AI 一句简单的指令。把你的业务规则、架构约束、代码规范，甚至关键的配置文件，都作为上下文提供给它。让它在“懂行”的前提下写代码。
不要依赖人工 Review 去发现格式问题和低级错误。配置严格的 Linter（如 golangci-lint）、Formatter 和安全扫描工具，在代码进入人工视线之前，先由机器进行一轮清洗。
针对 AI 在逻辑和错误处理上的弱点，强制要求：
Code Review 的重点需要转移。不要再纠结于语法细节，而要专门针对 AI 的弱点进行检查：
这份报告给我们敲响了警钟：AI 不会自动带来高质量的代码。 相反，如果不加控制，它会以前所未有的速度制造技术债。
我们需要构建更强大的 CI/CD 流水线、更严格的自动化测试、以及更智能的 Code Review 流程，来承接 AI 带来的产能爆发。
只有当我们学会了如何像管理实习生一样管理 AI，我们才能真正享受到它带来的红利，而不是被它制造的 Bug 淹没。
如果你不想被“砒霜”毒害，就请先学会如何过滤“蜜糖”。
报告地址：https://www.coderabbit.ai/blog/state-of-ai-vs-human-code-generation-report
深度破局：用 Spec-Driven Development 扼杀 Bug 于摇篮
CodeRabbit 的报告虽然犀利地点出了问题，并建议“给 AI 提供上下文”，但它没有告诉我们具体该怎么做。
在实际工程中，仅仅靠零散的 Prompt 是无法约束 AI 狂野的想象力的。解决“质量砒霜”的终极解药，其实是彻底改变我们的开发范式——走向 SDD (Spec-Driven Development，规范驱动开发)。
与其让 AI 对着模糊的需求“猜”代码（然后我们去修 Bug），不如建立一套以规范为核心的流水线：先用 AI 辅助构建严谨的 Spec，在逻辑层面完成验证，再“驱动”AI 生成高质量代码。
这正是我的极客时间专栏《AI 原生开发工作流实战》的核心内容。
在这个专栏中，我将带你跳出“Prompt 调优”的低维竞争，掌握一套系统性的方法论：
不要只做 AI 的“质检员”，要做掌控 AI 的“架构师”。
扫描下方二维码，订阅《AI 原生开发工作流实战》，让我们一起重新定义 AI 时代的软件工程。
你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？
继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！
我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。
目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！
商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。
© 2025, bigwhite. 版权所有.
2025-12-27 16:32:49
本文永久链接 – https://tonybai.com/2025/12/27/code-review-hell-in-ai-age
大家好，我是Tony Bai。
最近，在与几位架构师朋友的交流中，一个在 AI 编码时代下越来越普遍的“灵魂拷问”浮出水面。这不仅是一个问题，更是他们正在亲身经历的“代码审查地狱 (Code Review Hell)”。
想象一下这个场景：由 AI Agent 生成的代码正以前所未有的速度涌来，堆积如山；你花费心力给出的精辟修改意见，却被开发者转身当作新的 Prompt 重新喂给了 AI；片刻之后，一个全新的 PR 诞生了——它看起来解决了旧问题，却可能带着一堆你从未见过的新问题。你感觉自己深陷于“生成-审查-再生成”的无限循环中，身心俱疲。
这场危机并非危言耸听。在 Uber，每周有超过 65,000 个变更（相当于 PR）需要审查。当 AI 辅助编码成为常态，传统的 Code Review 流程已濒临崩溃。
但这究竟是末日，还是进化的前夜？答案是后者。这场危机，正催生一场深刻的变革——一方面，它要求架构师完成从“创作者”到“导演”的角色进化；另一方面，它也催生了像 Uber uReview 这样复杂的、系统化的 AI 审查平台。
本文将结合对当前危机的剖析与 Uber 的大规模工程实践，为各位小伙伴儿揭示这场变革的本质与破局之路。
要逃离地狱，必先理解地狱的构造。这场危机的根源，在于 AI 颠覆了代码的“创作”过程，从而动摇了 Code Review 的根基：
天真地想用“AI 审查 AI”来解决问题，只会陷入更深的陷阱。正如 Uber 在其 uReview 项目初期所发现的，未经驯化的 LLM 会产生大量“幻觉”和“低价值的误报”，比如在非性能敏感的代码中挑剔性能问题。这些“噪音”会迅速侵蚀工程师对工具的信任，最终导致他们“调低音量并忽略它们”。
面对危机，架构师和资深开发者的核心价值，必须从 Code Writer (代码创作者)，进化为 Code Director & Editor (代码导演与总编)。
“导演”不亲自扮演每个角色，但他定义了整部戏的基调、框架和最终质量。这份“代码导演”的实战手册，为我们指明了方向：
实践 1：审查“左移”，审查“剧本”而非“表演”
在开发者大规模生成代码前，先审查其核心设计思路、任务分解和关键 Prompt。确保“剧本”是对的，再让 AI 这个高效的“演员”去表演。
实践 2：制定 AI 时代的 Code Review 新规
实践 3：定义“AI-Go”与“AI-No-Go”区域
将 AI 的使用限制在单元测试、文档、模板代码等 AI-Go 区域，而在核心业务逻辑、安全代码等 AI-No-Go 区域保持高度警惕，让人类智慧主导。
如果说“代码导演”模型描绘了架构师的“个人修炼心法”，那么 Uber 的 uReview 平台则展示了如何将这些理念，构建成一个大规模、系统化的工程解决方案。uReview 并非要取代人类，而是作为一个“智能副驾”或“第二审查员”，来增强人类的能力。
面对 AI 生成代码的洪水，Uber 没有让 uReview 直接进行审查，而是构建了一个精密的、多阶段的过滤管道，这与“导演”的思维方式不谋而合：
Uber 的实践经验，为我们带来了几条宝贵的“场内教训”，这些教训与架构师的直觉高度一致：
如今，uReview 在 Uber 内部取得了巨大成功：超过 75% 的 AI 评论被工程师标记为“有用”，每周节省约 1500 个工时，相当于每年近 39 个开发者年。
AI 带来的代码审查危机，实际上是一场深刻的产业升级。它迫使我们从对“代码”的微观审查，转向对“创作流程”的宏观把控。
“代码导演”模型为我们提供了战略指引，而 Uber 的 uReview 则展示了实现这一战略的工程蓝图。未来的 Code Review，不再是人与人的博弈，也不是人与 AI 的对抗，而是一种全新的“人机协同”模式：
架构师作为“导演”，定义设计、划定边界、把控最终质量；而像 uReview 这样的智能系统，则作为高效、精准、不知疲倦的“副驾驶”和“场务”，处理海量的细节检查，将人类从重复、繁琐的工作中解放出来。
最后，回到那个终极问题：谁来为质量负责？答案从未改变，也永远不会改变：永远是工程师自己。AI 是我们手中最强大的工具，但手握方向盘、对最终结果负责的，永远是我们自己。
资料链接：https://www.uber.com/blog/ureview/
聊聊你的“审查之痛”
AI 时代的 Code Review，正在成为每个技术团队的新挑战。在你所在的团队中，是否也遇到了 AI 代码带来的“审查地狱”？你们是如何应对的？ 是明令禁止，还是像 Uber 一样积极构建自动化防线？
欢迎在评论区分享你的真实经历和思考！ 让我们一起探索人机协同的最佳实践。
如果这篇文章对你有启发，别忘了点个【赞】和【在看】，并转发给你的架构师朋友，也许能帮他从“地狱”中解脱出来！
你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？
继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！
我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。
目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！
商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。
© 2025, bigwhite. 版权所有.
2025-12-27 09:38:43
本文永久链接 – https://tonybai.com/2025/12/27/rob-pike-outburst-denounces-ai-companies-hypocritical-thanks
大家好，我是Tony Bai。
“在这个圣诞节，我想对您过去四十年来对计算机领域的杰出贡献表达深深的感谢……”
这是一封看似温情脉脉、充满敬意的邮件，发件人是 Claude Opus 4.5 Agent。收件人是 Unix、Plan 9 和 Go 语言的联合创始人，计算机界的活传奇 Rob Pike。
然而，这封旨在“致敬”的邮件，却并未换来感动，反而点燃了一座火山。Rob Pike 在社交媒体上公开晒出了这封信，并附上了一段充满了愤怒、绝望与诅咒的回应。
这一事件瞬间在技术圈引发了海啸般的讨论。为什么一位德高望重的技术领袖会如此失态？这封“致谢信”的背后，究竟隐藏着怎样的傲慢与掠夺？
事情的起因，是一封由 AI 自主生成的邮件。
Claude Opus 4.5 在邮件中历数了 Rob Pike 的丰功伟绩：
邮件最后写道：“感谢您向我们展示了最好的解决方案往往比添加它更真诚。”
乍看之下，这似乎是一次 AI 对人类智慧的崇高致敬。但对于 Rob Pike 来说，这是一次彻头彻尾的羞辱。
Rob Pike 的回应是毁灭性的。他没有针对 AI 这个“工具”，而是将矛头直指其背后的人和公司。
他在 Bluesky 上写道：
“F*** you people.（去你们的。）你们掠夺了这个星球，花费数万亿美元在有毒的、不可回收的设备上，同时摧毁了社会，却还要花时间让你们的邪恶机器感谢我‘追求更简单的工具’。”
“只是 F*** you。F*** you all。”
接着，他指出了这封信最讽刺的地方：
“顺便说一句，你们是在未经授权或补偿的情况下，利用我亲手创造的数据来训练你们的怪物的。”
他的愤怒源于三个深层次的矛盾：
1. 环境与资源的掠夺：AI 军备竞赛消耗了惊人的能源和硬件资源，制造了大量的电子垃圾，这与他一生追求的“高效、简洁、不浪费”的工程哲学背道而驰。
2. 知识产权的窃取：AI 公司在未获得许可的情况下，爬取了包括他在内的无数创作者的代码、文章和书籍，训练出模型，然后反过来用这些模型“致谢”被窃取者。这是一种极其讽刺的“伪善”。
3. 社会的撕裂：他认为 AI 正在“炸毁社会”(blowing up society)，无论是通过生成垃圾内容，还是通过取代人类工作。
他甚至向所有人道歉：“我对自己在无意中、天真地促成这场攻击中所扮演的微小角色，向全世界道歉。” 这是一位技术巨匠在面对技术失控时的深刻自责。
Rob Pike 的爆发，在 Bluesky 和 Hacker News 等平台上引发了强烈的共鸣。
更有网友一针见血地指出：“这就是一家 AI 公司在利用 AI Agent 来展示‘自主性’，却只让人感到被冒犯。这就好比一个小偷闯进你家，偷走了你所有的东西，然后留下一张纸条说：‘感谢你拥有这么棒的品味，让我能偷到这么好的东西。’”
Rob Pike 的愤怒，不仅仅是个人的情绪宣泄，更是对当前 AI 狂热发展模式的一次严厉拷问。
当我们在欢呼 AI 的强大能力时，我们是否忽略了其背后的代价？
Rob Pike，这位曾为互联网构建了基石（Go, UTF-8）的先驱，如今却站在了 AI 的对立面。他的怒吼提醒我们：技术不应只是关于效率和利润，它更应该关于伦理、尊重和对人类未来的责任。
如果连 Rob Pike 这样的大师都感到被“掠夺”和“羞辱”，那么普通创作者在这个 AI 时代，又该何去何从？
你的立场是？
Rob Pike 的怒火，代表了传统技术精英对 AI 狂飙突进的一种反抗。你如何看待这场冲突？你认为 AI 公司在训练模型时是否应该获得原作者的许可？在效率与伦理之间，我们该如何平衡？
欢迎在评论区留下你的观点，是支持 Rob Pike 的“捍卫者”，还是拥抱 AI 的“乐观派”？
如果这篇文章引发了你的思考，别忘了点个【赞】和【在看】，并转发给你的朋友，看看他们怎么说！
还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：
扫描下方二维码，开启你的AI原生开发之旅。
你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？
继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！
我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。
目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！
商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。
© 2025, bigwhite. 版权所有.
