核心冲突：代码量 vs. 人成长
最近，开源项目 Zig 干了一件让圈子里炸锅的事：他们直接禁止用大模型（LLM）生成的代码或注释来提交贡献。
这背后的逻辑其实挺有意思。当生成式 AI 已经能帮人写出几千行代码时，Zig 的维护者 Simon Willison 却选择了“反其道而行之”。这不是因为恨 AI，而是因为他们更担心：如果大家都忙着让机器写代码，谁来学习怎么自己写？
重新定义“贡献”：要的是人，不是代码
维护者们现在的想法很直接：开源项目的终极价值，不在于仓库里堆了多少行现成的代码，而在于能不能识别并培养出一批真正靠谱的贡献者。
以前我们觉得，只要代码能跑、逻辑通顺就是好 PR（Pull Request）。但现在看来，审查代码的过程其实是一种沟通。维护者通过 Review 指出问题，新人需要去理解“为什么这么改”，这个过程能建立信任，也能帮新人摸清技术门槛。
一旦引入 AI，这套逻辑就崩了
如果允许开发者用 AI 生成代码，整个“导师制”的玩法就玩不转了。
- 你根本不知道他懂不懂：AI 生成的代码看着挺漂亮，语法都没错，但维护者根本没法判断提交者是不是真的理解底层原理。这就像你请个代写论文的人，你没法确认里面的观点是不是他自己的想法。
- 审查变得没意义：这里有个尴尬的逻辑死循环。如果新人发来的 PR 全是 AI 写的，维护者花几个小时去审查这些代码，其实是在帮新人“白忙活”。不如直接拿维护者自己用 AI 生成的代码来修，速度快得多的多。
这就导致了一个怪圈：要么你自己写，要么别来。
拿其他项目说事：Bun 也试过
Zig 这个决定不是歧视 AI，而是基于对社区健康的考量。看看高性能 JS 运行时 Bun 就是个活生生的例子。
Bun 团队为了效率，早就开始大量用 AI 辅助开发了。结果呢？虽然代码写得飞快，质量也不错，但他们的上游提交标准里，根本不接受这种“纯 AI 生成”的补丁。
原因很简单：代码写得好没用，关键是得证明这是人写的，是人思考过的。
结论：我们在保护什么？
Zig 的这条禁令，其实是在保护开源社区最核心的东西——人与人的连接。
- 速度 vs. 理解：AI 写代码的速度是人类的几百倍。如果大家都追求快，那维护者就没时间教新人了。大家更愿意把精力花在那些愿意花时间一点点敲代码、愿意被骂、愿意反复改错的人身上。
- 信任是攒出来的：通过 Review 的争论、解释和妥协，新人能感受到社区的温度。AI 给不了这种情感共鸣，它只能给你冷冰冰的正确答案。
- 押注于人：这其实是一场赌博。Zig 选择赌人类的学习曲线，赌那个“笨拙”但真实的成长过程。在 AI 能瞬间生成完美代码的时代，这种坚持显得有点“笨”，但也正是这种笨拙，保留了人类开发者理解逻辑、建立信任的最后一块阵地。
说到底，Zig 禁止的不是 AI，而是走捷径。他们宁愿要一个慢一点的、充满摩擦的社区，也不要一个快得让人无处着力的流水线。
