Golang - Tony Bai

标签 Golang 下的文章

“这段代码是 AI 写的！”—— Go 社区的“AI 辅助编程”第一案

十二月 18, 2025
0 条评论

本文永久链接 – 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技能再上一个新台阶！

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

逃离 Java 的“自行车棚”：Go 语言真的是那片“净土”吗？

十二月 18, 2025
0 条评论

本文永久链接 – https://tonybai.com/2025/12/18/escaping-java-bicycle-shed-is-go-the-pure-land

大家好，我是Tony Bai。

“如果每次我看到‘为什么不这么写？’这种针对完美代码的 PR 评论都能得到一分钱，我现在已经退休了。”

近日，一位在 r/golang 社区发帖的开发者发出了这样的咆哮。他受够了 Java 生态中那种无休止的、关于细枝末节的争论——也就是所谓的“自行车棚效应”(Bike Shedding)。他正在认真考虑转向 Go 语言。

但问题是，换一门语言，真的就能彻底摆脱人性的弱点，找到那份久违的“简单”与“高效”吗？

这篇帖子迅速引发了数百条评论的热议，并形成了一次关于团队文化、工程效率以及如何在代码审查中保持理性的深度反思。

科普小贴士：什么是“自行车棚效应” (Bike Shedding)？

这个概念源自帕金森定律。典故是：一个委员会在审批核电站计划时，对极其复杂的反应堆设计匆匆通过（因为太难懂，大家不敢轻易发言），却为了旁边自行车棚该漆成什么颜色而争论了一个小时（因为每个人都能懂，都想发表意见）。

在软件开发中，它特指团队在无关紧要的琐事（如代码风格、变量命名、语法糖）上浪费大量时间，而忽略了真正重要的系统设计和逻辑问题。

img{512x368}

审视“自行车棚”—— 无效争论的代价

发帖人的痛苦，源于一种许多开发者都深有体会的经历：PR 被琐碎的个人偏好所劫持。

症状：代码逻辑正确、测试通过、符合规范。但审查者依然会问：“为什么不用 Optional.of(…).orElse(…) 而是用 if-else？”
潜台词：“如果是我的话，我会这么写。我要指出这一点，以显示我有在认真看代码，而且我很聪明。”
后果：
- 时间浪费：为了一个不影响功能的改动，需要重新提交代码、等待 CI 跑完（在企业级 Java 项目中可能长达 20-30 分钟）、等待再次审查。
- 士气低落：开发者感到自己的工作不被尊重，变成了为了满足审查者个人喜好而工作的“打字员”。

正如一位评论者尖锐指出的：“这不仅是语言问题，更是‘人’的问题。” 有些开发者倾向于过度工程化，为了使用设计模式而使用设计模式，而忽略了代码的实际价值。

Go 是解药吗？—— “强制统一”带来的自由

为什么发帖人认为 Go 是解药？因为 Go 的设计哲学确实在很大程度上抑制了“自行车棚”的滋生土壤。

1. 极简的语法与“唯一解”

Go 语言的设计哲学是“少即是多”。它没有 Optional，没有复杂的流式操作符，没有十种不同的方式来实现同一个功能。
一位资深 Gopher 指出：“在 Go 中，很少有人会争论‘为什么不这么写’，因为通常只有一种地道的写法。” gofmt 更是从根本上消灭了关于格式化的争论。

2. “Not Invented Here” vs. “Just Copy It”

Java 生态倾向于构建通用的、高度抽象的框架。而 Go 社区更推崇“复制一点代码胜过引入一点依赖”。这种文化鼓励简单、直接的实现，而不是过早的抽象。
评论区有人提到：“在 Go 中，如果你看到重复代码，你可能会选择容忍它；但在 Java 中，你会被要求抽象出一个通用的 Factory 模式。”

3. 工具链的胜利

Go 的工具链（lint, vet）非常强大且统一。如果一个问题可以通过静态分析发现，那就交给机器去阻止，而不是在 PR 中由人来指指点点。

硬币的另一面 —— Go 社区的“新自行车棚”

然而，逃离了 Java，就能彻底摆脱“自行车棚”吗？社区的声音并非一边倒。Go 并不是没有任何争论的乌托邦。

新的争论点：虽然不再争论 Optional，但 Go 社区也有自己的“圣战”：
- “为什么你要用这个第三方库？标准库不够好吗？”
- “这个 struct 应该放在 pkg 目录下吗？”
- “为什么你要定义这个接口？让消费者去定义！”
过度的“地道”追求：有时，对“Idiomatic Go”（地道 Go 代码）的追求也会演变成一种教条主义。一位评论者分享了自己的经历：仅仅因为不想在代码中看到哪怕一点点“Java 味”，审查者就拒绝了一个完美运行的 PR。

由此看来，Go 虽然减少了语法的复杂性，从而减少了语法层面的争论空间，但它也无法消除人类对于微小差异的执着。

给所有团队的“防杠指南”

无论你使用 Java 还是 Go，如何建立一个健康的 Code Review 文化才是根本。社区贡献了许多极具价值的建议：

区分“阻塞”与“建议”：引入明确的前缀，如 nit: (吹毛求疵，不阻塞合并)、suggestion: (建议，可不采纳)、blocker: (必须修改)。这能清晰地传达审查者的意图。
自己动手，丰衣足食：如果审查者对某个非功能性的风格问题非常在意，且有权限，不妨直接提交一个小改动，而不是阻碍原作者的 PR。
规则自动化：凡是能用 Linter (如 Checkstyle, golangci-lint) 解决的问题，绝不在人工审查中讨论。让机器做坏人。
接受“足够好”：Code Review 的目标是保证代码质量、发现 Bug 和分享知识，而不是追求“完美”。完美是完成的敌人。