近日，在Go语言的官方GitHub仓库中，一场围绕性能与代码来源的公开讨论，将“如何对待AI生成的代码”这一议题，推向了社区前台。事件的中心是一个名为coregex的正则表达式库项目，其作者声称性能远超Go标准库，并提交了改进标准库的提案。然而，经过社区资深开发者审查后，该项目不仅性能声明被推翻，其开发过程也被指大量依赖AI且缺乏充分检查，最终提案被关闭。
这一案例与另一位知名开发者Mitchell Hashimoto公开分享的、成功运用AI辅助开发的经验形成了鲜明对比，共同揭示了AI辅助编程在效率与质量之间的深刻矛盾。
coregex项目：性能宣称与AI辅助开发陷阱
故事的起因是Go标准库regexp包长期存在的性能争议。开发者@kolkov推出了coregex项目，宣称通过SIMD加速、Lazy DFA等多种优化手段，实现了相比标准库3到192倍的性能提升。基于此，他向Go团队提交了提案（NO.76818），探讨将其优化贡献给标准库的可能性。
转折点来自于GoAWK的作者Ben Hoyt的介入。他通过将其集成到自己的项目中进行实际测试，得出了相反的结论：“在所有情况下，标准库都比coregex更快”。他进一步指出了项目的几个关键问题：
- 基准测试误导：
coregex宣称的性能提升基于高度特化的微基准测试，无法反映真实场景下的负载情况。
- 正确性缺失：项目甚至没有完整运行标准库
regexp的测试套件，代码正确性无法保证。
- AI开发的“原罪”：Ben Hoyt尖锐地指出，“大部分工作似乎是由机器人/AI代理完成的，而且未经充分检查”，这直接导致了代码质量低下。
这场交锋最终以提案关闭告终，但它抛出了一个核心问题：一个严重依赖人工智能生成但缺乏深度人类监督的代码库，其可靠性能否支撑起对核心库的贡献？
对比案例：Mitchell Hashimoto的人机协同“最佳实践”
在coregex事件之前，HashiCorp联合创始人Mitchell Hashimoto详细公开了他使用AI开发终端项目ghostty一个新功能的完整记录。他的方法提供了截然不同的范本：
- 人类主导规划，AI执行细节：在让AI写代码前，他会先进行“预AI规划”，亲自研究并制定技术方案。他给AI的第一个指令往往是：“为我创建一个实现计划，先不要写代码。”
- 小步快跑，即时清理：他将大任务拆解为极小的步骤，每次AI生成代码后，都会立即进行手动“清理会话”，确保自己完全理解每一行代码。“清理步骤至关重要，它强迫你不会盲目接受AI的产出。”
- 识别AI局限，及时接管：当AI在调试复杂问题时陷入“胡言乱语区”并反复失败时，Hashimoto会果断停止让其生成代码，转为完全由自己手动解决。
- 绝不提交不理解代码：这是他的核心原则。“如果AI解决了问题，但我不理解其解决方案，我会把它回退。我绝不提交自己不懂的代码。”
冲突本质：开源协作模式与AI生成代码的碰撞
coregex事件的深层矛盾，远不止于性能优劣，而在于开源协作的文化冲突。Ben Hoyt提出质疑的关键背景，是coregex作者意图“改进标准库”。像Go这样的成熟开源社区，对向上游贡献代码有着极高要求：代码需清晰、可维护、测试完备，且贡献者需深度参与技术讨论。
coregex所代表的“AI快速生成、人类轻度复核”的模式，与传统开源社区审慎、人类主导的协作模式格格不入。Go核心团队成员@mvdan的评论也侧面印证了这一点，他暗示提案“读起来像广告”，甚至直接问“这份提案是AI写的吗？”。
这引出了一个更尖锐的问题：当一个大量由AI生成的Pull Request（即使通过了CI）提交时，项目的维护者是否有责任、又有能力对其进行有效的审查和接纳？
小结：Go社区的挑战与机遇
coregex是一个警示：将AI视为“黑盒”代码生成器，缺乏严格的人类监督与真实场景测试，结果可能是灾难性的。
Mitchell Hashimoto的实践则是一个启示：AI应是专家的“副驾驶”和“加速器”，而非替代品。优秀的AI使用者是其领域的专家，他们利用AI放大能力，而非外包思考。
对于Gopher和整个开源社区而言，当前的核心问题并非“是否使用AI”，而是“如何建立一套方法论，来区分高质量的、由专家引导的AI辅助贡献，和低质量的、由AI主导的‘代码倾倒’”。
Go语言以其简洁、显式的设计哲学，或许为“人类审查AI代码”提供了天然优势。如何将这种语言特性转化为可操作的“人机协同”开源协作规范，将是社区在AI时代必须面对和解答的关键命题。
参考资料：
| 
发表于 5 天前
|
查看: 16|
回复: 0
