本文永久链接 – https://tonybai.com/2025/12/18/go-community-first-case-ai-assisted-programming

大家好，我是Tony Bai。

近日，一场在 Go 官方 GitHub Issue 中爆发的公开“对峙”，将一个长期悬而未决的问题，以一种极具戏剧性的方式，推到了所有 Gopher 的面前：我们应该如何对待 AI 生成的代码？

这场“冲突”的主角，一方是开发者 @kolkov 及其号称性能远超标准库的 coregex 项目；另一方则是 Go 社区备受尊敬的 GoAWK 作者 Ben Hoyt。当 Ben Hoyt 以详尽的 benchmark 数据，公开质疑 coregex 的性能声明，并犀利地指出“大部分工作似乎是由机器人/AI 代理完成的，而且未经充分检查”时，这场关于性能的讨论，瞬间升格为一次关于 AI 辅助编程伦理与实践的“灵魂拷问”。

巧合的是，在这之前不久，另一位前Go社区大神、HashiCorp 的创始人 Mitchell Hashimoto，发表了一篇长文，详细记录了他如何“大量使用 AI”来开发其 ghostty 终端的一个非平凡功能。

这两起事件，如同两面镜子，从正反两方面，映照出 AI 生成代码在 Go 社区所面临的机遇、挑战与深刻陷阱。

coregex 的“高光”与“翻车”

故事始于一个长达七年的“老大难”问题：Go 标准库 regexp 包的性能，长期以来都显著落后于 Rust 等语言的同类实现。开发者 @kolkov 带着他的 coregex 项目横空出世，声称通过 SIMD 加速、Lazy DFA 等多种优化，实现了比标准库 3-192 倍的性能提升。

他雄心勃勃地向 Go 官方提交了提案（#76818），希望探讨将 coregex 的优化成果，以某种形式贡献给标准库 (upstreaming) 的可能性。

然而，剧情很快急转直下。

GoAWK 的作者 Ben Hoyt 站了出来，他将 coregex 集成到自己的项目中进行真实世界测试，却得出了一个截然相反的结论：

“在所有情况下，标准库都比 coregex 更快……这些都是非常普通的正则表达式，并非奇怪的边缘情况。”

Ben Hoyt 进一步指出了 coregex 项目的几个“危险信号”：

• Benchmark 误导：coregex 的性能声明，是在特定的、微观的 benchmark 中得出的，并未反映真实世界负载下的性能。
• 正确性存疑：项目甚至没有完整地运行标准库 regexp 的测试套件。
• AI 辅助开发的“原罪”：Ben Hoyt 最终将矛头指向了 coregex 的开发流程：“大部分工作似乎是由机器人/AI 代理完成的，而且未经充分检查，这一点表现得很明显。”

这场公开的“对峙”，最终以 @kolkov 承认其 benchmark 的局限性，并关闭提案告终。但它留下了一个深刻的、令整个社区警醒的问题：一个由 AI 大量参与、但缺乏足够人类监督的项目，其可靠性是否值得信赖？

Mitchell Hashimoto 的“人机协同”之道

而在 coregex 争议发酵的前不久，Mitchell Hashimoto 在其博客上，以一种极其坦诚和透明的方式，分享了他利用 AI 开发 ghostty 新功能的完整、未经编辑的交互记录。

他的文章，并非一篇 AI 的“赞美诗”，而是一部关于如何驾驭 AI 这个强大但并不可靠的“副驾驶”的“最佳实践手册”。

核心原则一：人类负责“规划”，AI 负责“执行”

Hashimoto 在使用 AI 之前，会先进行“Pre-AI Planning”。他会自己研究文档、制定一个粗略的技术方案，然后给 AI 的第一个指令，往往是“为我创建一个计划，不要写任何代码”。

核心原则二：小步迭代，持续清理

他从不要求 AI 一次性构建整个功能。相反，他将任务分解成极小的部分，并在每个 AI 生成的步骤之后，立即进行手动的“清理工作” (Cleanup Sessions)。

“清理步骤非常重要。为了有效地清理，你必须对代码有很好的理解，这迫使我不会盲目地接受 AI 写的代码。”

核心原则三：当 AI “撞墙”时，人类必须接管

在他的交互记录中，他清晰地展示了 AI 在面对一个棘手的 Bug 时，是如何“进入了胡言乱语区 (slop zone)”，反复尝试却无法修复的。此时，他的选择是：“AI 不再是解决方案，它是一个负债。”

核心原则四：绝不提交自己不理解的代码

这是 Hashimoto 在整篇文章中反复强调的“铁律”。

“如果 AI 解决了问题，但我不理解它的解决方案，我会把它撤销掉。我不会提交我不理解的代码。”

冲突的本质 —— Go 社区准备好迎接 AI 贡献者了吗？

coregex 的争议，表面上是关于性能和 AI，但其更深层次的矛盾，在于开源协作的模式。

Ben Hoyt 发难的真正导火索，并非单纯因为 coregex 使用了 AI，而是 @kolkov 在提案中探讨了“改进标准库”的可能性。Go 社区（乃至所有严谨的开源社区）对“上游贡献”(upstreaming) 有着极高的标准：代码必须清晰、可维护、经过充分测试，并且贡献者需要深度参与社区讨论。

coregex 以其“AI 辅助、快速迭代”的开发模式，与 Go 社区传统的、审慎的、人类主导的协作模式，发生了文化上的激烈碰撞。@mvdan (Go 核心团队成员) 在评论中也暗示了这一点：“这份提案读起来更像一则广告”，并且“Was this proposal written by AI?”。

这引出了一个更尖锐的问题：

一个由 AI 大量生成的 PR，即使它能通过所有的 CI 检查，Go 项目的维护者们是否应该、又是否有能力去审查和接纳它？

小结：Go 社区的“AI 门槛”——是挑战，更是机遇

coregex 的故事，是一个警示录。它告诉我们，将 AI 作为“黑盒”代码生成器，并缺乏严格的人类监督和真实世界测试，其结果可能是灾难性的。

而 Mitchell Hashimoto 的故事，则是一个启示录。它向我们展示了 AI 辅助编程的正确姿势：AI 并非程序员的替代品，而是一个强大的“灵感缪斯”和“体力劳动加速器”。

“我相信，优秀的 AI 驾驭者，是其所在领域的专家，他们利用 AI 作为助手，而非替代品。” —— Mitchell Hashimoto

对于我们 Gopher 而言，这场风波的最终教训并非“AI 代码不可信”，也不是“Go 语言特别适合 AI 生成”。真正的、悬而未决的问题是：

Go 社区和项目，对于如何定义、审查和接纳 AI 生成的贡献，是否已经有了一个明确的态度和标准？

目前看来，答案是否定的。我们还没有一套成熟的方法论，来区分一个“由专家引导的、高质量的 AI 辅助贡献”，和一个“由 AI 主导的、缺乏深思熟虑的‘代码倾倒’”。

这既是一个巨大的挑战，也是一个重要的机遇。Go 语言以其简洁、清晰和显式的特性，为“人类审查 AI 代码”提供了得天独厚的优势。如何将这种语言优势，转化为一套行之有效的“人机协同”开源协作规范，将是 Go 社区在 AI 时代必须回答的核心问题。

资料链接：

• https://github.com/golang/go/issues/26623
• https://github.com/golang/go/issues/76818

还在为“复制粘贴喂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/01/proposal-sync-v2

大家好，我是Tony Bai。

当 Go 核心团队前成员、著名 Gopher、net/http包的设计者 Brad Fitzpatrick 在 GitHub 上留下上图中的这句评论并甩出一个自己移植的库时，我们知道，sync/v2 的到来不仅仅是一个提案，更是一种迫切的刚需。

随着 math/rand/v2 在 Go 1.22, json/v2 在 Go 1.25 中的成功落地，Go 标准库的 v2 化进程似乎已经按下了加速键。今年1月份，Go 核心团队成员 Ian Lance Taylor 就提交了sync/v2 的提案 (#71076)。

这可不仅仅是一次简单的版本号升级，它标志着 Go 语言最核心的并发原语包，也终于要拥抱泛型，告别 interface{} 时代了。

在本文中，我们将深入剖析这份提案的核心内容，探讨它将如何重塑 Go 的并发编程体验，以及社区为此展开的激烈辩论。

核心痛点：any 的原罪

目前的 sync 包，特别是 sync.Map 和 sync.Pool，设计于 Go 支持泛型之前。它们被迫使用 any (即 interface{}) 来处理各种类型的数据。这带来了两个无法忽视的问题：

1. 类型安全缺失：编译器无法阻止你往一个本该只存字符串的 sync.Map 里塞进一个整数，或者从 sync.Pool 里取出一个你以为是 []byte 实际上是 *bytes.Buffer 的东西。所有的错误只能在运行时通过 panic 暴露。
2. 性能损耗：将非指针类型（如 int、string）存入 any 类型的容器，必须进行装箱（boxing），这不仅增加了 CPU 开销，更重要的是会产生额外的内存分配，加重 GC 负担。对于追求极致性能的并发场景，这是不可接受的。

sync/v2 的提案，就是要通过泛型彻底解决这些问题。

sync/v2 的新面貌：类型安全与 API 进化

根据提案，sync/v2 将不仅是 sync 的泛型翻版，它还趁机对 API 进行了现代化的打磨。

Map[K, V]：终于等到了你

新的 sync.Map 将拥有两个类型参数 K (comparable) 和 V (any)。

// sync/v2
type Map[K comparable, V any] struct { ... }

// 方法签名变得清晰且类型安全
func (m *Map[K, V]) Load(key K) (value V, ok bool)
func (m *Map[K, V]) Store(key K, value V)

此外，提案还计划顺应时代潮流，移除了老旧的 Range 方法，取而代之的是返回迭代器的 All 方法：

func (m *Map[K, V]) All() iter.Seq2[K, V]

Pool[T]：更安全的资源复用

sync.Pool 的改造稍微复杂一些。目前的 Pool 有一个导出的 New 字段，这很容易被误用。v2 版的提案曾经历过一次修改，最终方案倾向于移除导出的 New 字段，转而通过构造函数来设定：

type Pool[T any] struct { ... }

// 通过构造函数传入创建新对象的逻辑
func NewPool[T any](newf func() T) *Pool[T]

func (p *Pool[T]) Get() T
func (p *Pool[T]) Put(x T)

社区的激辩：v2 真的必要吗？

提案虽然诱人，但也引发了社区关于 Go 语言演进哲学的激烈讨论。

反方：分裂生态的担忧

有声音质疑：sync 包的大部分类型（如 Mutex, WaitGroup, Once）并不需要泛型。如果为了 Map 和 Pool 而引入整个 sync/v2，会不会导致生态分裂？以后我们是不是要在同一个项目里同时维护 v1 和 v2 的锁？

对此，Ian Lance Taylor 及其支持者给出的方案是：sync/v2 将包含 sync 包的所有类型。对于不需要泛型的类型（如 Mutex），通过类型别名 (Type Alias) 将其指向 v1 版本，或者保持 API 完全一致。这样，用户可以平滑迁移，最终完全切换到 v2，而无需混用。

正方：性能与体验的刚需

支持者们（包括 Brad Fitzpatrick）则指出，泛型带来的性能提升和开发体验改善是巨大的。特别是对于 Pool[[]byte] 这样的高频场景，避免每次 Put/Get 时的切片头分配，是实打实的性能红利。

小结：不仅是代码的升级，更是理念的升级

sync/v2 的提案目前仍在活跃讨论中，尚未尘埃落定。但它释放了一个明确的信号：Go 团队正在审慎而坚定地推动标准库的现代化。

对于我们 Gopher 而言，这意味着：

1. 拥抱泛型：这不再是尝鲜，而很可能是未来的标准范式。
2. 关注性能：标准库的升级将带来免费的性能提升，特别是对于重度依赖 sync.Map 和 sync.Pool 的项目。
3. 准备迁移：虽然 Go 承诺兼容性，但 v2 包的引入意味着我们需要开始思考如何优雅地过渡。

Brad Fitzpatrick 的“等不及”或许代表了许多资深开发者的心声。让我们拭目以待，看 sync/v2 将如何重塑 Go 的并发编程体验。

你的选择是？

面对 sync/v2 带来的泛型红利和潜在的迁移成本，你更倾向于第一时间拥抱它，还是持观望态度？在你的项目中，sync.Map 或 sync.Pool 的性能瓶颈是否真的困扰过你？

欢迎在评论区留下你的看法，让我们一起探讨 Go 标准库的未来！