本文永久链接 – 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 擦屁股。” 一位开发者如是说。

环境的枷锁：大厂的围墙 vs. 荒野的求生

帖主观察到的“鸿沟”，其实是生存环境的差异。

• 自由职业者/创业者：他们是荒野猎人。每一分钟的节省都直接转化为收入。他们往往处理的是从 0 到 1 的新项目，没有历史包袱。AI 在这种场景下是神兵利器，能让他们以一当十。
• 大厂员工：他们是城堡守卫。面对的是数百万行、有着 10 年甚至更长历史的“屎山”代码。这里充满了复杂的业务逻辑、诡异的依赖关系和严苛的安全合规要求。
  • 复杂的上下文：AI 很难理解一个庞大、老旧代码库的全部上下文。
  • 安全与合规：正如许多评论指出的，很多公司出于数据泄露的恐惧，直接封禁了 AI 工具，或者只允许使用“阉割版”或“内部部署的大模型”。
  • 激励机制：在大厂，多干活往往不意味着多拿钱，甚至可能因为引入了 AI 生成的 Bug 而背锅。既然工资照发，为什么要冒险去改变工作流？

一位开发者总结得精辟：“微服务架构、遗留代码和复杂的业务逻辑，是 AI 目前难以逾越的护城河。”

技能的诅咒：新手狂欢，高手叹息？

这里出现了一个有趣的“技能倒挂”现象。

• 初级开发者：往往对 AI 趋之若鹜。因为 AI 能帮他们写出自己原本写不出来的代码，填补了能力的空白。
• 高级开发者：态度两极分化。
  • 抵制者：他们以此为荣，认为编程是一门精密的艺术，容不得 AI 的“大概差不多”。他们享受对每一行代码的掌控感。
  • 驾驭者：他们把 AI 当作“超级实习生”。他们不让 AI 做架构决策，只让它写单元测试、生成样板代码、转换数据格式。他们深知 AI 的局限，所以只在 AI 擅长的领域使用它。

正如评论所言：“用 AI 编程就像坐自动驾驶的车。新手觉得‘哇，车自己会动！’，老司机则时刻把手放在方向盘上，因为他知道这玩意儿随时可能把车开进沟里。”

未来的分岔路：你是工匠，还是操作员？

这场讨论最终指向了一个终极问题：软件工程师的未来是什么？

有人悲观：“这就像当年会计师抵制 Excel 一样。拒绝工具的人，最终会被淘汰。”
有人乐观：“AI 将消灭平庸的‘代码搬运工’，但会放大真正懂得系统设计、能解决复杂问题的工程师的价值。”

无论你属于哪个阵营，一个趋势是不可逆转的：编码（Coding）本身的门槛正在降低，但工程（Engineering）的门槛并未改变，甚至在提高。

未来的工程师，可能分为两类：

1. AI 操纵者：利用 AI 快速交付产品，关注的是“结果”而非“过程”。
2. 系统守望者：负责审查 AI 的产出，解决 AI 无法处理的极端边界情况，维护系统的架构与安全。

小结：打破“傲慢与偏见”

回到最初的问题：“为什么很多人无视 AI？”

• 也许不是无视，而是审慎。
• 也许不是傲慢，而是负责。
• 也许不是懒惰，而是受限。

但对于我们每一个个体而言，最危险的态度是“傲慢的无视”。你可以因为安全原因不用，可以因为质量原因少用，但绝不能因为“看不起”而不去了解。

去试一试吧。 不要只用它写 Hello World，试着让它重构一个函数，写一个测试，解释一段晦涩的代码。了解它的上限，摸清它的下限。

因为在不久的将来，评价一个工程师的标准，或许不再是你写代码有多快，而是你能多好地驾驭这个不知疲倦、偶尔发疯、但潜力无限的“硅基队友”。

资料链接：https://www.reddit.com/r/ClaudeAI/comments/1ot9b8n/why_are_so_many_software_engineers_still_ignoring/

你属于哪一类？

在AI浪潮面前，你觉得自己更像是一个在荒野中狂奔的“猎人”，还是在城堡中坚守的“守卫”？你所在的团队对AI编程持什么态度？

欢迎在评论区分享你的真实处境和思考！

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

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

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

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

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

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

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

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

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

本文永久链接 – 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 的新类型，究竟有何魔力。

核心痛点：为什么我们需要 Sum Types？

在深入设计之前，让我们先回顾一下，为什么我们如此渴望这个特性。neild 列举了三个极具代表性的场景：

1. Direction 类型 (Enum)：一个类型只能是 North, South, East, West 四者之一。
2. Option/Maybe (Sum Type)：一个类型要么包含一个值 T，要么什么都没有（None）。
3. IP 地址 (Variant)：一个类型要么是 IPv4 ([4]byte)，要么是 IPv6 ([16]byte)。

目前，我们通常使用 interface 来模拟这些场景。但 neild 指出，接口并不是最佳方案：

• 零值问题：接口的零值是 nil。这迫使我们必须处理一个额外的、可能毫无意义的 nil 状态，这在很多时候（如 Direction）是不合理的。
• 定义繁琐：你需要为每一个变体定义一个单独的类型，这在变体较多时显得非常啰嗦。
• 语义混淆：接口本质上是关于行为的抽象，而和类型本质上是关于数据结构的定义。强行用接口来表达数据结构，是一种概念上的错位。

大胆构想：像定义 Struct 一样定义 Union

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）。

这种设计的美妙之处在于：

1. 语法一致性：它看起来就像我们熟悉的结构体，只是关键字变成了 union。
2. 明确的零值：Union 的零值就是其第一个变体的零值。例如 Direction 的零值就是 North，IP 的零值就是 IPv4{0,0,0,0}。没有额外的 nil 状态！
3. 内聚性：所有变体都定义在同一个类型内部，不需要像接口那样定义一堆散落的类型。

使用体验：类型安全与穷尽性检查

这个设计不仅在定义上优雅，在使用上也力求符合 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)
}

Union Switch：杀手级特性

这是 Sum Types 最强大的地方——穷尽性检查。

switch d.(union) {
case North:
    // ...
case South:
    // ...
// 如果漏掉了 East 或 West，编译器会报错！
}

这种编译期的保障，彻底消除了“忘记处理某种情况”的 Bug 来源，是构建健壮系统的基石。

社区激辩：细节中的魔鬼

虽然大方向得到了广泛认可，但在具体细节上，社区展开了激烈的讨论。

struct{} 的特殊待遇

neild 提议对 atom (即 struct{}) 进行特殊处理，使其可以直接作为值使用（如 Direction.North）。但这引起了 ianlancetaylor 等人的担忧：这种特殊规则是否会增加语言的复杂性和不一致性？如果不特殊处理，写 Direction{North: struct{}{}} 又实在太啰嗦了。

命名之争：atom vs unit vs iota

atom 这个名字是否合适？有人建议使用 null，有人建议复用 iota，还有人建议直接允许 union { North, South } 这种省略类型的语法。这再次证明了，“命名”永远是计算机科学中最难的问题之一。

与泛型的纠葛

如果 Union 是泛型的，如何处理？Maybe[T] 是一个完美的例子。但如果 T 本身也是一个 Union 呢？嵌套的 Union 及其 Switch 语句该如何设计？这些都是需要深思熟虑的边缘情况。

小结：Go 语言演进的新曙光？

尽管 #76920 目前只是一个“讨论”，并非正式提案，但它释放了一个强烈的信号：Go 团队也许正在认真思考如何以一种“地道”的方式引入和类型(Sum Type)。

这个设计方案，在保持 Go 语言简单性的同时，极大地增强了其表达力和安全性。它避开了接口的动态性陷阱，提供了一种静态的、高效的、内存布局可控的数据结构。

如果这个构想最终能成真，它将填补 Go 语言类型系统中最后一块重要的拼图，让我们彻底告别用 iota 和 interface{} 拼凑枚举与联合类型的日子。

资料链接：https://github.com/golang/go/issues/76920

你的态度是？

对于这个打破常规的 union 语法设计，你是感到兴奋，觉得它终于填补了 Go 的拼图？还是感到担忧，觉得它让 Go 变复杂了？

如果给你一张选票，你会支持这个提案落地吗？

欢迎在评论区投出你的一票，并分享你的理由！ 让我们一起见证 Go 语言的演进。

如果这篇文章让你对 Go 的未来有了新的期待，别忘了点个【赞】和【在看】，并分享给身边的 Gopher 朋友！

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

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

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

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

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

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

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

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

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