“这段代码是 AI 写的！”—— Go 社区的“AI 辅助编程”第一案
本文永久链接 – 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技能再上一个新台阶！
商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。
© 2025, bigwhite. 版权所有.
Related posts:
评论