开源编程语言Zig，向AI代码说「不」

Zig项目封杀AI代码：为人类工程师守门

2026年4月，Zig编程语言项目发布了一项引发热议的政策：禁止使用任何大型语言模型（如GitHub Copilot、ChatGPT等）生成的代码进行贡献。核心维护者明确表示：“Zig是为人类工程师设计的，不是为了人工智能。”所有贡献者必须保证提交的代码是个人独立编写的，否则将被拒收。这一声明在Hacker News上获得数百点赞，支持者认为这是对开源“原创性”和“责任感”的坚决捍卫，反对者则担忧会限制新人参与。

政策背后的三重考量：版权、文化与质量

Zig团队列出三大理由，解释为何对AI代码说“不”：

• 版权与许可证的灰色地带：AI模型的训练数据来自互联网上的公开代码，但大部分开源许可证要求署名和相同方式共享。AI生成的代码既不标注来源，也不公开训练数据，可能引发侵权诉讼。一旦项目接受这类代码，整个代码库的法律风险将被放大。
• 社区文化的侵蚀：Zig社区的核心价值观是学习、理解和贡献。许多贡献者通过提交代码加深对语言的理解。AI生成代码的流行可能导致：
  • 贡献者变成“代码搬运工”，丧失解决问题的能力。
  • 社区讨论减少，代码审查流于形式。
  • 长期贡献者的培养链断裂，项目沦为代码仓库而非知识共同体。
• 代码质量隐患：Zig拥有独特的概念（如comptime、error union、optional type），AI在生成代码时频繁误用。例如用递归实现comptime斐波那契函数，忽略了编译期计算需用循环；错误地使用std.math.isNan而非std.math.isNaN；缺少类型转换导致编译失败。这些细节暴露出AI对语言深层语义的“无知”。

具体缺陷：AI代码在Zig中的“常见病”

根据Zig社区审查发现，AI生成的Zig代码往往存在三类典型错误：

• 命名与风格不一致：Zig社区偏好描述性命名（如calculate_average），而AI常生成短小模糊的变量名（如calcAvg）。zig fmt虽能统一格式，却无法修复命名逻辑。
• 测试覆盖不全：AI通常只生成基础用例，忽略边界情况。例如计算平均值的测试中，AI仅检查正数输入，缺少对负数、浮点精度、空数组等场景的覆盖，导致expect(std.math.isNan(result))这类断言直接编译失败。
• 误用Zig特有概念：comptime是Zig的核心编译期计算机制，但AI生成的递归函数可能无限循环（编译期递归栈溢出）；error union类型未正确处理错误返回值；optional type被当作普通指针使用。这些错误即便通过编译，也往往在执行时引发未定义行为。

从GitHub迁移至Codeberg：对微软和AI的“用脚投票”

几乎在同一时间，Zig项目宣布全面告别GitHub，迁移至开源平台Codeberg。这一决定直指微软旗下GitHub对AI工具的过度投入，导致其核心代码托管服务品质下滑。项目维护者表示：“我离开了GitHub，因为人工智能和平台质量下降，以及对微软的信任在削弱。”Codeberg作为非盈利社区平台，不集成AI辅助功能，更符合Zig“为人类工程师设计”的理念。这一迁移同样引发广泛讨论，不少开发者表示支持，认为这是对科技巨头垄断和AI侵蚀开源基础的抗议。

争议与未来：开源灵魂的保卫战

Zig的反AI政策并非孤立事件。支持者认为，开源的本质是培养长期可信的贡献者，而非追求代码量的增长。AI工具可能加剧“精英化”——能负担高价AI订阅的开发者获得不公平优势，而新手更难以通过实际贡献深入理解项目。反对者则担心这是对技术进步的排斥，会阻碍“民主化”。Zig社区并未完全否定AI，鼓励将其作为“结对编程伙伴”而非“代笔人”，并建议贡献者建立自己的代码风格指南、积极参与代码审查以学习前辈经验。这场争论本质上是对原创性与责任的坚守：在效率至上的时代，编程的本质依然是解决问题，而不是生成代码。