Zig 创建者 Andrew Kelley 在 JetBrains 的一次访谈中，进一步解释了两个容易引发争议的决定：项目正式禁止 AI 生成的贡献，以及将代码托管从 GitHub 迁移到 Codeberg。两件事看似分别属于代码质量和基础设施选择，背后却指向同一个问题：开源项目需要的不只是更多代码，还需要可追责的判断、稳定的协作工具，以及参与者之间持续建立的信任。
禁止的重点不是工具，而是无人负责的产出
按照访谈中的观点，自动生成并提交的代码会降低代码库质量，也会削弱开源参与者之间的社会关系。这里的风险不只是模型偶尔写错一个条件判断。
维护者审核补丁时，通常默认提交者理解自己的修改，能够解释设计选择，并在合并后继续处理回归问题。如果贡献者只是把模型输出转交给项目，这条责任链就会断裂：
- 提交者可能无法解释代码为何采用某种算法或抽象；
- 审阅成本从“验证一个方案”变成“重新理解并证明整份输出”；
- 生成代码可以批量制造，但维护者的注意力无法批量扩容；
- 讨论不再发生在两个理解问题的人之间，社区关系也随之变弱。
因此，AI 贡献政策不宜只写成“禁止某个产品”。真正需要界定的是作者责任、披露义务和可维护性。自动补全、文档润色与整段代码代写可能带来不同风险，项目应明确自己的边界，而不是指望维护者逐个猜测。
从 GitHub 迁往 Codeberg，是基础设施也是治理选择
访谈将迁移原因归结为持续出现的 GitHub 故障，以及项目对平台激励机制不一致的判断。这说明代码托管平台并非中性的硬盘：议题追踪、补丁评审、通知、身份系统和平台规则，都会塑造项目的工作方式。
对开源维护者而言，迁移平台通常要评估三层问题：
- Git 数据能否完整迁移：分支、标签和提交历史相对容易复制。
- 协作数据如何处理：Issue、Pull Request、评论、里程碑和附件不一定包含在 Git 仓库中。
- 项目入口是否同步更新：文档、包管理元数据、CI 密钥、机器人和旧仓库提示都可能仍指向原平台。
Zig 的决定不能简单概括成“哪个平台功能更多”。更关键的是，平台的可靠性、治理方式和激励方向是否与项目的长期需求一致。
可以这样实践：迁移仓库并写清贡献规则
下面是一个通用的 Git 镜像迁移示例，并非 Zig 实际迁移过程的复现。运行前将两个地址替换为自己的旧仓库和 Codeberg 仓库地址：
#!/usr/bin/env bash
set -euo pipefail
OLD_REMOTE='https://your-old-forge.example/team/project.git'
NEW_REMOTE='git@codeberg.org:YOUR_ORG/YOUR_REPO.git'
WORKDIR='project-mirror.git'
git clone --mirror "$OLD_REMOTE" "$WORKDIR"
cd "$WORKDIR"
git remote set-url --push origin "$NEW_REMOTE"
git push --mirror
echo 'Verify fetch and push destinations:'
git remote -v
--mirror 会复制所有 Git 引用，能力比普通 git clone 更完整，但它不会自动搬运 Issue、评审评论、附件、Webhooks 或平台密钥。迁移后至少还应执行这些检查：
# 在新仓库的普通工作副本中执行
git remote set-url origin git@codeberg.org:YOUR_ORG/YOUR_REPO.git
git remote -v
git ls-remote --heads origin
git ls-remote --tags origin
贡献政策则可以放进 CONTRIBUTING.md。下面是一个可改造的最小版本；它表达的是一种可选治理方案，并不代表 Zig 政策的逐字内容：
## Authorship and automated tools
Contributors must understand, review, and take responsibility for every submitted change.
Do not submit code or prose generated primarily by an AI system. If an automated tool was used for limited assistance, disclose that use in the pull request and explain how the result was verified.
A contributor must be able to:
- explain the design and implementation;
- reproduce relevant tests;
- respond to review comments without delegating the discussion to a model;
- maintain or revise the change after submission.
Maintainers may close submissions that create disproportionate verification work or whose authors cannot explain the proposed change.
不建议用所谓“AI 检测器”自动拒绝贡献。这类判断容易误伤，也无法验证作者是否真正理解代码。更可靠的办法是要求小而聚焦的补丁、测试结果、设计解释和持续回应，让责任通过协作过程体现出来。
项目采用前的检查清单
对其他项目来说，Zig 的选择不必被照搬，但值得转化为几个具体问题：
- 维护者能否要求提交者解释并长期负责其修改？
- 自动生成内容是否正在把成本从贡献者转移给审阅者？
- AI 使用边界是否已经写入贡献指南，而不是临时口头裁决？
- 当前托管平台发生故障时，项目是否有镜像和恢复方案？
- Issue、评审记录和发布流程是否被平台锁定？
- 迁移之后，旧地址是否保留只读说明，避免社区分裂？
禁止 AI 贡献会减少一部分潜在提交，也可能引发“辅助使用”和“主要生成”如何区分的争议；迁离主流平台则可能牺牲曝光度、账号便利性和现成集成。相应收益是更明确的责任边界，以及对项目基础设施更主动的选择。真正重要的不是采取最激进的立场，而是让规则可解释、可执行，并与维护者实际能够承担的审核成本相匹配。