开源项目的「反 AI 赌局」：Zig 的 Contributor Poker 哲学如何重新定义代码贡献的价值

当全世界都在拥抱 AI，Zig 选择了说不

2026 年 4 月，开源编程语言 Zig 在其行为准则（Code of Conduct）中加入了一条堪称"异类"的条款：

Strict No LLM / No AI Policy

• No LLM-generated content, whether it be code or prose.
• No paraphrasing LLM-generated content.
• No LLMs for editing, including fixing spelling or grammatical errors.
• No LLMs for translation.
• No LLMs for brainstorming and then sharing the results of that brainstorming, even if you create the prose.
• No LLMs for finding bugs.
• No talking about use of chatbot/LLM services.

这不是一条温和的"建议"——这是白纸黑字写进行为准则的硬性禁令。连用 AI 修个拼写错误都不行，连用 AI 头脑风暴后再自己写也不行。

当 GitHub Copilot 已经内置进 VS Code，当 Cursor 以 AI-Native IDE 的名义拿到数亿美元融资，当 Linus Torvalds 本人都在个人项目中使用 AI 编程时，Zig 的这条政策看起来简直是逆时代潮流而动。

但如果你深入理解 Zig 团队的逻辑，你会发现这不是保守主义的反抗，而是一个精心设计的博弈论策略——他们称之为 Contributor Poker（贡献者扑克）。

Contributor Poker：一场关于人的长期赌局

扑克的核心法则：你赌的是人，不是牌

Zig Software Foundation 社区副总裁 Loris Cro 在一篇题为《Contributor Poker and Zig's AI Ban》的文章中，首次系统性地阐述了这个概念的底层逻辑。

"The reason I call it 'contributor poker' is because, just like people say about the actual card game, 'you play the person, not the cards'. In contributor poker, you bet on the contributor, not on the contents of their first PR."

这个类比精确到了骨髓。在德州扑克中，新手看牌面，老手看对手。同样，在开源项目中，审阅一个 PR 的真正价值不在于那几行代码，而在于代码背后的那个人能不能成长为长期贡献者。

让我们用具体的数学来理解这个逻辑：

贡献者的价值 = Σ(第i次贡献的价值 × 贡献者持续参与的概率^i)

其中：
- 第1次贡献的价值通常很低（新手不熟悉代码库）
- 贡献者持续参与的概率随时间递增（信任建立后加速）
- 如果贡献者在第3次后离开，总价值 ≈ V1 + V2 + V3（有限）
- 如果贡献者持续参与50次，总价值指数级增长

这就是为什么 Zig 团队愿意花大量时间帮新手修改他们的第一个 PR——那不是在审阅代码，那是在投资一个人。

反面教材：当"完美 PR"变成负资产

假设有两个 PR 提交者：

提交者 A：花了两周时间研究 Zig 的 ABI 稳定性问题，手动写了一个 200 行的修复，代码风格不够 Zig-idiomatic，有两个小 bug。

提交者 B：让 Claude 生成了一个 500 行的 PR，通过了所有 CI 测试，代码风格完美，甚至还附带了详尽的文档。

从纯代码质量的角度，B 的 PR 更好。但从 Contributor Poker 的角度：

提交者 A 的投资价值：
- 理解了 Zig 的 ABI 机制 → 具备独立解决同类问题的能力
- 经历了审阅过程 → 建立了与核心团队的信任关系
- 下次遇到类似问题 → 可以自主修复，无需审阅者大量投入
- 长期价值：可能成为 ABI 子系统的维护者

提交者 B 的投资价值：
- 对 Zig 的 ABI 机制一无所知 → 无法回答审阅者的追问
- 无法对后续发现的问题负责 → AI 生成的代码没有人"拥有"
- 下次遇到类似问题 → 还是得重新问 AI，无法积累领域知识
- 长期价值：接近零

Zig 创建者 Andrew Kelley 在 JetBrains 播客中的表述更加直白：

"有人给我们提交完全没有价值的贡献。它们甚至是负价值，因为会占用团队有限的代码审查时间。"

负价值——这个词很重，但逻辑无可辩驳。当 Zig 有 200 个未处理的 PR 积压时，每花一小时审阅一个 AI 生成的"完美但无人负责"的 PR，就意味着一个真正的人类贡献者的 PR 要多等一小时。而那个人类贡献者可能正因为等待太久而失去兴趣，永远离开项目。

迭代博弈：开源项目的真正经济模型

Contributor Poker 的核心洞察在于：开源贡献是一个迭代博弈（Iterated Game）。

# 开源项目的贡献者价值模型
class ContributorValue:
    def __init__(self, name):
        self.name = name
        self.contributions = 0
        self.trust_level = 0  # 0-100
        self.domain_knowledge = set()
        self.review_investment = 0  # 核心团队投入的审阅时间
    
    def submit_pr(self, pr_quality, used_llm=False):
        self.contributions += 1
        
        if used_llm:
            # AI 辅助的 PR：即使质量高，也无法建立信任
            # 因为贡献者不"拥有"这些代码
            self.trust_level += 0  # 信任不增长
            self.domain_knowledge.add(0)  # 领域知识不增长
        else:
            # 手动 PR：审阅过程本身就是学习
            self.trust_level += min(10, pr_quality * 2)
            self.domain_knowledge.add(pr_quality)
        
        # 迭代价值：信任带来更多自主权，减少审阅负担
        return self.cumulative_value()
    
    def cumulative_value(self):
        if self.trust_level < 20:
            return 0.5  # 新手：价值有限
        elif self.trust_level < 50:
            return 3.0  # 成熟贡献者：高价值
        elif self.trust_level < 80:
            return 10.0  # 核心贡献者：极高价值
        else:
            return 50.0  # 子系统维护者：不可替代

# 模拟：10次迭代后的价值差异
manual_contrib = ContributorValue("Alice")
llm_contrib = ContributorValue("Bob")

for i in range(10):
    manual_contrib.submit_pr(pr_quality=0.7, used_llm=False)
    llm_contrib.submit_pr(pr_quality=0.9, used_llm=True)  # AI 生成质量更高

print(f"手动贡献者累计价值: {manual_contrib.cumulative_value()}")  # → 高信任，高价值
print(f"LLM贡献者累计价值: {llm_contrib.cumulative_value()}")      # → 零信任，极低价值

这个模型解释了为什么 Zig 宁可拒绝一个代码质量更高的 AI 辅助 PR，也要保留一个质量更低但由人手写的 PR——前者是一次性交易，后者是长期投资的起点。

AI 贡献的三大"毒药"效应

Zig 团队将 AI 辅助贡献带来的问题总结为三个层次，从最浅显到最深层：

第一层：噪音洪水

这是最显而易见的问题。LLM 让生成 PR 的成本降到了几乎为零：

# 一个"AI 贡献者"的典型工作流
$ claude-code "Find open issues in ziglang/zig and submit PRs"
# → 10分钟内向10个issue提交了PR
# → 其中8个无法编译
# → 1个通过了CI但逻辑错误
# → 1个看似合理但贡献者无法解释任何设计决策

Andrew Kelley 描述了这种场景的可怕之处：Zig 有 200 个待审阅的 PR，如果其中 150 个是 AI 生成的噪音，那么真正有价值的 50 个 PR 被淹没在噪音中，等待时间从几天变成几周甚至几个月。

这不仅仅是时间浪费——等待本身就在驱赶高质量贡献者。一个花了两周写 PR 的开发者，如果等了一个月都没人审阅，他大概率不会再回来。

第二层：信任侵蚀

比噪音更危险的是"伪装者"——那些声称没有使用 AI，但实际上在偷偷咨询 LLM 的贡献者。

Loris Cro 专门提到了这种情况：

"有些贡献者只是把我们说的话复制粘贴回对话框，并试图通过清洗聊天记录来假装自己没有使用 AI 聊天功能，但我们依然能够看出来，并意识到永远不会有高质量的贡献。"

为什么这比直接的 AI 噪音更危险？因为它破坏了贡献者 Poker 的信任基础。Contributor Poker 的核心假设是：审阅过程能帮贡献者成长。但如果贡献者只是一个"人肉代理"——把审阅者的反馈粘贴给 AI，再把 AI 的回复粘贴回来——审阅者实际上是在给一个 LLM 做 prompt engineering，而不是在培养一个工程师。

# 信任侵蚀的传染效应
def trust_erosion(num_sneaky_contributors, total_review_capacity):
    """
    当伪装者被发现后，审阅者对所有人的信任都会下降
    """
    base_trust = 1.0
    erosion_per_incident = 0.05
    
    # 每发现一个伪装者，审阅者对所有新贡献者的默认信任降低
    effective_trust = base_trust - (num_sneaky_contributors * erosion_per_incident)
    
    # 信任降低导致审阅更谨慎 → 每个PR审阅时间增加
    review_time_multiplier = 1 / effective_trust
    
    # 实际审阅吞吐量下降
    effective_capacity = total_review_capacity / review_time_multiplier
    
    return {
        "effective_trust": effective_trust,
        "review_time_multiplier": review_time_multiplier,
        "effective_capacity": effective_capacity,
    }

# 假设发现10个伪装者
result = trust_erosion(10, 40)  # 原本每周可审阅40个PR
# → effective_trust: 0.5
# → review_time_multiplier: 2.0（每个PR审阅时间翻倍）
# → effective_capacity: 20（吞吐量减半）

信任的崩塌是指数级的。当审阅者变得多疑，每个新贡献者都要接受更严格的审查，这又会导致审阅更慢，PR 积压更严重，形成恶性循环。

第三层：知识真空

这是最深层的危害，也是 Zig 团队最担忧的。

开源项目的真正财富不是代码——代码可以重写，但领域知识不能。一个贡献者对 Zig 的内存安全模型、编译器管线、交叉编译机制的理解，是数月甚至数年积累的结果。这种知识让他们能够：

1. 在后续问题出现时快速定位和修复（因为是他们写的代码）
2. 对相关设计决策提供有价值的意见（因为他们理解全局架构）
3. 帮助新贡献者上手（因为他们经历过相同的学习曲线）

而 AI 生成的代码不附带任何"知识载体"：

// 假设一个 AI 生成了 Zig 编译器中的这段优化代码
// AI 可以生成看起来正确的代码
ZigType *analyze_instruction(CodeGen *g, IrInst *inst) {
    switch (inst->id) {
        case IrInstId_Add:
            return resolve_add_type(g, inst);
        case IrInstId_Mul:
            return resolve_mul_type(g, inst);
        // ... 50 more cases
        default:
            return g->builtin_types.entry_invalid;
    }
}

// 但当6个月后这个函数产生了一个微妙的数据竞争bug
// 谁来修复？AI？不，AI不知道这个函数在并发编译中的上下文
// 贡献者？他从未真正理解过这段代码
// 最终只能由核心团队成员自己修——而他们本来可以直接写这段代码

代码的真正成本不是写它的那段时间，而是维护它的整个生命周期。没有"所有者"的代码，维护成本无限大。

Bun 分叉：当 AI 与 Contributor Poker 背道而驰

Zig 反 AI 政策最戏剧性的注脚，来自它最著名的用户——Bun。

Bun 是一个用 Zig 编写的 JavaScript/TypeScript 运行时，以极致性能著称。2025 年 12 月，Bun 被 Anthropic 收购后，自然地开始大量使用 AI 辅助开发。

2026 年 5 月，Bun 团队宣布了一个惊人的成果：通过给 Zig 编译器后端添加并行语义分析和多代码生成单元，Bun 的编译速度提升了 4 倍。

但 Bun 官方同时表示：

"We do not currently plan to upstream this, as Zig has a strict ban on LLM-authored contributions."

这句话的分量很重。一个 4 倍性能提升的补丁，因为涉及 AI 生成代码而无法回馈上游。

更戏剧性的是，2026 年 5 月 11 日，Bun 创始人 Jarred Sumner 宣布：Bun 正在从 Zig 迁移到 Rust，而这个重写过程由 Claude Code 在 6 天内完成了 96 万行代码的转换。

从 Contributor Poker 的视角，这几乎是必然的结局：

Zig 的策略：投资人类贡献者 → 长期信任和知识积累
Bun 的策略：投资 AI 效率 → 短期产出最大化

两种策略在短期内可以并行（Bun 维护自己的 Zig fork）
但长期来看，Bun 不需要"Zig 社区的贡献者"
它只需要"能运行的 Zig 编译器"
→ 维护一个 fork 的成本 < 培养 Zig 上游贡献者的成本
→ 分道扬镳

一位 Zig 核心贡献者在 Ziggit 论坛上解释了为什么他们不会接受 Bun 的补丁——即使不考虑 AI 禁令：

"Parallel semantic analysis is a long planned feature but has implications for the Zig language itself."

翻译：并行语义分析不只是一个编译器优化——它会改变 Zig 语言本身的语义模型。这种级别的架构变更，需要一个人深度理解 Zig 的语言设计哲学才能正确实施。AI 可以生成代码，但无法参与语言设计层面的讨论。

深度拆解：Zig 的行为准则为什么这么"极端"

仔细读 Zig 的行为准则，你会发现它的极端不仅仅体现在 AI 禁令上。整份文档透露出一种非常"不客气"的治理哲学：

1. 禁止语言提案

"Thank you for your interest in improving the Zig language. However, we are not interested in 'drive-by' suggestions."

想提语言改进建议？先找到一个核心团队成员愿意替你 champion。这和 AI 禁令的底层逻辑是一样的——drive-by 建议和 drive-by PR 一样，是噪音而不是投资。

2. 禁止讨论行为准则本身

"Discussing this Code of Conduct should not take place on Codeberg, IRC, or Zulip because these spaces are for directly working on code, not for meta-discussion."

这意味着你不能在 Zig 的官方空间里争论 AI 禁令是否合理。要讨论？找 Andrew 或 Loris 私聊。这是典型的"治理空间"和"工作空间"分离策略。

3. 引用了阿西莫夫的《Profession》

行为准则底部引用了阿西莫夫 1957 年的短篇小说《Profession》。这个故事讲的是一个未来社会，人们通过脑内植入获得专业技能，而那些无法被植入的人被迫真正学习——结果他们才是真正推动创新的人。

Zig 团队引用这篇小说的暗示很明显：被 AI "植入"的知识和真正理解的知识，有本质区别。

4. 翻译禁令的逻辑

"不能用 LLM 翻译"看起来最不讲理——翻译又不影响代码质量。但 Contributor Poker 的逻辑同样适用：

如果一个贡献者用 LLM 翻译了他们的 issue 报告，当审阅者追问细节时，这个贡献者可能无法用英语准确回应（因为他们不真正"拥有"那段英文表述）。这和代码的情况一样——代理生成的任何内容，在后续互动中都会暴露出所有者缺失的问题。

Zig 的替代方案反而更有趣：直接用你的母语写，让审阅者自己找翻译工具。这确保了贡献者"拥有"自己说的每一句话。

Contributor Poker 的数学模型：为什么短期损失换来长期收益

让我们用更严格的模型来分析 Contributor Poker 的经济逻辑。

基本参数

# 开源项目的审阅资源分配模型
class ProjectEconomics:
    def __init__(self):
        self.review_capacity = 40  # 核心团队每周可审阅的PR小时数
        self.avg_review_time = 2   # 每个PR平均审阅时间（小时）
        self.contributor_retention = {}  # 贡献者留存概率
        
    def contributor_roi(self, contributor_type, iterations=20):
        """
        计算不同类型贡献者的长期投资回报率
        """
        if contributor_type == "manual":
            # 手动贡献者
            # 前3次：高审阅成本（2h/PR），但逐步降低
            # 3次后：审阅成本降至1h，产出质量提升
            # 10次后：可以独立review其他人的PR（变成净正值）
            costs = []
            values = []
            for i in range(1, iterations + 1):
                if i <= 3:
                    cost = 2.0  # 新手需要更多指导
                    value = 1.0  # 产出有限
                elif i <= 10:
                    cost = 1.0  # 熟悉后审阅更快
                    value = 3.0  # 产出质量提升
                else:
                    cost = 0.5  # 可以半自主工作
                    value = 5.0  # 高质量产出
                    if i > 15:
                        value = 8.0  # 子系统专家
                        cost = 0.2  # 几乎不需要审阅
                
                # 留存概率递减但趋于稳定
                retention = 0.7 if i <= 3 else (0.85 if i <= 10 else 0.95)
                costs.append(cost * retention)
                values.append(value * retention)
            
            total_cost = sum(costs)
            total_value = sum(values)
            return total_value / total_cost
            
        elif contributor_type == "llm_assisted":
            # LLM辅助贡献者
            # 每次审阅成本恒定（因为贡献者无法成长）
            # 产出质量可能高，但无长期复利
            costs = []
            values = []
            for i in range(1, iterations + 1):
                cost = 1.5  # 审阅成本不降低（需要验证AI幻觉）
                value = 2.0  # 代码质量可能不错，但无人"拥有"
                retention = 0.3  # AI贡献者很少持续参与
                
                costs.append(cost * retention)
                values.append(value * retention)
            
            total_cost = sum(costs)
            total_value = sum(values)
            return total_value / total_value if total_value > 0 else 0

model = ProjectEconomics()
manual_roi = model.contributor_roi("manual")
llm_roi = model.contributor_roi("llm_assisted")

# 手动贡献者的ROI远高于LLM辅助贡献者
# 因为长期复利效应：一个成熟贡献者 > 100个一次性AI贡献者

临界点分析

Contributor Poker 的关键问题是：在什么条件下，拒绝 AI 辅助 PR 会导致净正面收益？

条件：被拒绝的AI-PR的即期价值 < 审阅资源释放带来的长期价值

设：
- V_ai = AI-PR的即期代码价值
- C_ai = 审阅AI-PR的成本（时间）
- V_manual = 被释放的审阅资源所服务的手动PR的长期价值
- R = 审阅资源每小时产生的长期价值

则拒绝AI-PR的净收益 = V_manual - V_ai = (C_ai × R) - V_ai

当 R > V_ai / C_ai 时，拒绝是合理的

在Zig的案例中：
- V_ai ≈ 低到中（大部分AI PR有隐蔽问题）
- C_ai ≈ 高（需要额外验证AI幻觉）
- R ≈ 高（培养出的贡献者未来产出指数增长）

→ R >> V_ai / C_ai
→ 拒绝AI贡献在数学上是最优策略

社区撕裂：支持者与反对者的核心论点

Zig 的 AI 禁令在开源社区引发了激烈的讨论， Hacker News 上相关帖子获得了 656 个赞，成为当日最高。让我们分析双方的核心论点：

反对禁令的论点

论点 1：不可执行性

"You can't tell if code was written by an LLM or not."

这是最常见的反对意见。但正如 Loris Cro 指出的，这完全误解了政策的意图。Contributor Poker 不需要检测 AI 使用——它只需要让 AI 使用者自我筛选出去。明确禁止 AI 的效果是：

• 诚实的 AI 用户不会提交 PR（遵守规则）
• 不诚实的 AI 用户会提交 PR，但后续互动会暴露（无法解释设计决策）
• 少数"完美伪装者"可能通过，但数量极少，不足以构成系统性风险

论点 2：工具中性论

"AI is just a tool like a linter or autocomplete. Banning it is like banning spell check."

这个类比的问题在于：linter 不会替你思考，AI 会。用 linter 检查代码风格，你仍然理解代码的每一行。用 AI 生成代码，你可能完全不理解它为什么能工作。

更精确的类比是：

linter ≈ 计算器  → 帮你更快地做你已经会做的事
AI code gen ≈ 代写论文  → 替你做了你本应该自己做的事

论点 3：排他性

"This policy excludes developers who rely on AI due to disabilities or language barriers."

Zig 对此的直接回应是行为准则中的翻译条款：你可以用母语参与，不需要 AI 翻译。至于残疾相关的辅助技术，行为准则引用阿西莫夫的《Profession》暗示了一种更深层的态度——真正的无障碍是降低参与门槛（如接受非英语），而不是用 AI 替代参与者的理解。

支持禁令的论点

论点 1：审阅资源的零和博弈

这是最务实的论点。核心团队的审阅时间是零和资源——花在 AI PR 上的每一小时，都是从人类贡献者那里抢来的。

论点 2：维护责任的归属

代码合并后，维护责任归谁？AI 生成的代码没有"所有者"——当 bug 在六个月后出现时，谁负责修复？

// 一个AI生成的Zig标准库函数
pub fn formatBuf(buf: []const u8, comptime fmt: []const u8, out: anytype) !void {
    // AI可以生成看似正确的代码
    // 但当涉及Zig的comptime语义时
    // 细微的错误可能导致编译时行为与运行时不一致
    // 这种bug只有真正理解Zig类型系统的人才能发现和修复
}

论点 3：文化信号效应

明确的 AI 禁令向社区传递了一个信号：这里重视深度理解胜过快速产出。这种文化信号本身就是一种筛选机制——它吸引那些愿意深度学习的人，而赶走那些只想快速提交 PR 的人。

更广阔的图景：开源项目面对 AI 的三种策略

Zig 不是唯一一个面对 AI 贡献问题的项目。整个开源社区正在分化为三种策略：

策略 1：全面禁止（Zig 模式）

适用条件：

• 项目有明确的长期贡献者培养目标
• 核心团队审阅能力有限
• 项目质量 > 项目速度
• 领域知识深度要求高（编译器、操作系统、密码学等）

优势：最大化贡献者投资回报，保持社区文化一致性
风险：可能错过一些高质量的 AI 辅助贡献，在 AI 时代显得"落后"

策略 2：有条件接受（Linux 模式）

Linus Torvalds 本人在使用 AI 编程，但 Linux 内核社区对 AI 贡献的态度是"看质量不看来源"——不问你怎么写的，只问你写得好不好。

适用条件：

• 项目规模极大，有分层审阅机制
• 子系统维护者有足够的审阅经验识别 AI 幻觉
• 项目速度 > 项目文化一致性

优势：不排斥任何贡献来源
风险：审阅成本可能随 AI 贡献比例增加而指数上升

策略 3：全面拥抱（Bun 模式）

Bun 被 Anthropic 收购后，全面拥抱 AI 辅助开发。6 天 96 万行 Rust 重写就是这种策略的极致体现。

适用条件：

• 项目有充足的商业资源支持
• 速度是第一优先级
• 有足够的测试覆盖率来验证 AI 生成代码
• 项目不需要培养外部贡献者（核心团队足够大）

优势：极致的开发效率
风险：知识集中在少数人+AI 的组合中，项目可持续性依赖商业实体

策略对比表

┌─────────────┬──────────────┬──────────────┬──────────────┐
│    维度      │  全面禁止     │  有条件接受   │  全面拥抱     │
├─────────────┼──────────────┼──────────────┼──────────────┤
│ 代表项目     │ Zig          │ Linux        │ Bun          │
│ 核心逻辑     │ 投资人       │ 投资代码     │ 投资速度     │
│ 审阅成本     │ 低（噪音少）  │ 中（需甄别）  │ 高（验证多）  │
│ 贡献者留存   │ 高           │ 中           │ 低           │
│ 知识积累     │ 高           │ 中           │ 低（AI替代）  │
│ 开发速度     │ 慢           │ 中           │ 快           │
│ 可持续性     │ 高（去中心）  │ 中           │ 低（依赖实体）│
│ AI 时代适应性│ 低（表面）    │ 中           │ 高           │
└─────────────┴──────────────┴──────────────┴──────────────┘

代码实战：如何在一个中型开源项目中实施 Contributor Poker

如果你是一个中型开源项目的维护者，想要借鉴 Zig 的 Contributor Poker 策略，但又不想像 Zig 那样完全禁止 AI，这里有一个实用的实施框架。

第一步：定义贡献者层级

# contributor_tier.py — 贡献者分级系统

from enum import IntEnum
from dataclasses import dataclass
from datetime import datetime, timedelta

class ContributorTier(IntEnum):
    DRIVE_BY = 0      # 首次贡献者，无历史记录
    RECURRING = 1      # 有2-5个已合并PR
    TRUSTED = 2        # 有6-20个已合并PR，无重大问题
    MAINTAINER = 3     # 子系统维护者级别
    CORE = 4           # 核心团队成员

@dataclass
class Contributor:
    name: str
    tier: ContributorTier
    merged_prs: int
    first_contribution: datetime
    last_contribution: datetime
    review_hours_invested: float  # 核心团队在ta身上投入的审阅时间
    ai_usage_flags: int  # AI使用嫌疑次数
    
    def upgrade_eligible(self) -> bool:
        """是否满足升级条件"""
        if self.tier == ContributorTier.DRIVE_BY:
            return self.merged_prs >= 2
        elif self.tier == ContributorTier.RECURRING:
            return self.merged_prs >= 6 and self.ai_usage_flags == 0
        elif self.tier == ContributorTier.TRUSTED:
            return self.merged_prs >= 20 and self.ai_usage_flags == 0
        return False
    
    def poker_value(self) -> float:
        """
        Contributor Poker 价值评分
        核心思想：长期参与 + 无AI依赖 = 高价值
        """
        # 时间维度：持续参与时间越长越好
        duration = (datetime.now() - self.first_contribution).days / 365
        time_factor = min(duration, 3) / 3  # 3年封顶
        
        # 产出维度：合并PR数
        output_factor = min(self.merged_prs / 20, 1)  # 20个封顶
        
        # 投资回报维度：团队投入的审阅时间 vs 产出
        if self.review_hours_invested > 0:
            roi = self.merged_prs / self.review_hours_invested
        else:
            roi = 0
        roi_factor = min(roi / 2, 1)  # 2 PR/hour 封顶
        
        # AI 风险折扣
        ai_discount = max(0, 1 - self.ai_usage_flags * 0.3)
        
        # 活跃度
        days_since_last = (datetime.now() - self.last_contribution).days
        activity_factor = max(0, 1 - days_since_last / 90)  # 90天不活跃归零
        
        tier_bonus = self.tier * 0.5  # 层级加成
        
        return (time_factor * 0.2 + output_factor * 0.3 + 
                roi_factor * 0.2 + ai_discount * 0.2 + 
                activity_factor * 0.1) * (1 + tier_bonus)

第二步：审阅优先级调度

# review_scheduler.py — 基于Contributor Poker的审阅调度

from typing import List, Tuple
import contributor_tier as ct

class ReviewScheduler:
    def __init__(self, weekly_capacity_hours: float = 40):
        self.capacity = weekly_capacity_hours
        self.queue: List[Tuple[str, float, ct.Contributor]] = []
    
    def enqueue(self, pr_id: str, contributor: ct.Contributor, 
                estimated_review_hours: float):
        """将PR加入审阅队列"""
        priority = self._calculate_priority(contributor, estimated_review_hours)
        self.queue.append((pr_id, priority, contributor))
        self.queue.sort(key=lambda x: x[1], reverse=True)
    
    def _calculate_priority(self, contributor: ct.Contributor, 
                           est_hours: float) -> float:
        """
        审阅优先级 = Contributor Poker价值 / 审阅成本
        
        高价值贡献者 × 低审阅成本 = 最高优先级
        低价值贡献者 × 高审阅成本 = 最低优先级
        """
        value = contributor.poker_value()
        cost = est_hours
        
        # 新手折扣：第一次PR给额外加成（这是投资机会）
        if contributor.merged_prs == 0:
            value *= 1.5
        
        return value / cost
    
    def schedule(self) -> List[str]:
        """生成本周审阅计划"""
        scheduled = []
        remaining = self.capacity
        
        for pr_id, priority, contributor in self.queue:
            est_hours = 2.0  # 默认估计
            if remaining >= est_hours:
                scheduled.append(pr_id)
                remaining -= est_hours
            else:
                break  # 本周容量已满
        
        return scheduled
    
    def ai_policy_check(self, contributor: ct.Contributor, 
                        declared_ai_use: bool) -> str:
        """
        AI 使用策略检查
        
        可选策略（非Zig式的全面禁止）：
        - "disclose"：允许使用但必须声明
        - "tiered"：根据贡献者层级决定
        - "ban"：全面禁止（Zig模式）
        """
        policy = "tiered"  # 项目可自定义
        
        if policy == "ban":
            if declared_ai_use:
                return "REJECT: 项目禁止AI辅助贡献"
            return "ACCEPT: 需后续验证"
        
        elif policy == "tiered":
            # 新手禁止AI（投资期）
            if contributor.tier <= ct.ContributorTier.RECURRING:
                if declared_ai_use:
                    return "REJECT: 非Trusted贡献者禁止AI辅助"
                return "ACCEPT: 新手建议手动贡献以加速成长"
            # Trusted以上允许AI辅助
            else:
                if declared_ai_use:
                    return "ACCEPT_WITH_REVIEW: Trusted贡献者允许AI辅助，但需额外验证"
                return "ACCEPT: 标准审阅流程"
        
        elif policy == "disclose":
            if declared_ai_use:
                return "ACCEPT_WITH_NOTE: AI辅助已记录，审阅者请注意验证"
            return "ACCEPT: 标准审阅流程"
        
        return "UNKNOWN POLICY"

第三步：贡献者健康度监控

# health_monitor.py — 项目贡献者生态健康度监控

class ContributorHealthMonitor:
    def __init__(self, contributors: List[ct.Contributor]):
        self.contributors = contributors
    
    def ecosystem_score(self) -> dict:
        """
        计算项目贡献者生态的综合健康度
        
        关键指标：
        1. 人力资本密度：高价值贡献者占比
        2. 新鲜血液率：新贡献者流入率
        3. 留存率：贡献者从DRIVE_BY升到TRUSTED的比例
        4. AI依赖率：疑似AI辅助贡献的占比
        """
        total = len(self.contributors)
        if total == 0:
            return {"score": 0, "status": "CRITICAL"}
        
        # 人力资本密度
        high_value = sum(1 for c in self.contributors 
                        if c.tier >= ct.ContributorTier.TRUSTED)
        capital_density = high_value / total
        
        # 新鲜血液率（过去90天的首次贡献者）
        recent_new = sum(1 for c in self.contributors
                        if c.merged_prs <= 1 and 
                        (datetime.now() - c.first_contribution).days <= 90)
        fresh_blood = recent_new / max(total, 1)
        
        # 留存率
        total_ever = sum(1 for c in self.contributors
                        if c.merged_prs >= 1)
        retained = sum(1 for c in self.contributors
                      if c.tier >= ct.ContributorTier.RECURRING)
        retention = retained / max(total_ever, 1)
        
        # AI依赖率
        ai_suspected = sum(1 for c in self.contributors
                         if c.ai_usage_flags > 0)
        ai_rate = ai_suspected / max(total, 1)
        
        # 综合评分
        score = (
            capital_density * 30 +  # 30%权重
            fresh_blood * 20 +      # 20%权重
            retention * 30 +        # 30%权重
            (1 - ai_rate) * 20     # 20%权重（低AI依赖=高分）
        )
        
        status = "HEALTHY" if score > 70 else ("WARNING" if score > 40 else "CRITICAL")
        
        return {
            "score": round(score, 1),
            "status": status,
            "capital_density": round(capital_density, 2),
            "fresh_blood_rate": round(fresh_blood, 2),
            "retention_rate": round(retention, 2),
            "ai_dependency_rate": round(ai_rate, 2),
            "recommendations": self._recommend(score, capital_density, 
                                               fresh_blood, retention, ai_rate)
        }
    
    def _recommend(self, score, capital, fresh, retention, ai_rate):
        recs = []
        if capital < 0.1:
            recs.append("⚠️ 高价值贡献者不足，考虑增加审阅资源投入")
        if fresh < 0.05:
            recs.append("⚠️ 新贡献者流入不足，检查项目文档和onboarding流程")
        if retention < 0.3:
            recs.append("⚠️ 留存率低，检查PR审阅响应时间是否过长")
        if ai_rate > 0.3:
            recs.append("⚠️ AI依赖率过高，Contributor Poker策略受到威胁")
        if not recs:
            recs.append("✅ 贡献者生态健康")
        return recs

现实拷问：Contributor Poker 能否在 AI 时代存活？

Zig 的 Contributor Poker 策略在逻辑上是自洽的，但它面临一个根本性的现实挑战：当 AI 让代码生成成本趋近于零时，"投资人类贡献者"的时间窗口正在关闭。

悖论一：效率与深度的零和博弈

Zig 目前有 200 个未处理的 PR。这个数字本身就是 Contributor Poker 的悖论——正是因为花时间投资新手，所以处理速度慢；但如果不投资新手，贡献者管道会枯竭。

AI 让这个悖论更加尖锐：

传统模式：200个PR → 50个是高质量人类PR → 20个能培养出长期贡献者
AI时代：2000个PR → 50个高质量人类PR被淹没 → 3个能培养出长期贡献者

审阅资源没有增加，但噪音增加了10倍
→ Contributor Poker的"投资命中率"从10%降到0.15%
→ 策略经济性崩溃

悖论二：AI 生成代码的"质量陷阱"

AI 生成的代码质量正在快速提升。当 AI PR 的通过率从 10% 提升到 80% 时，拒绝它们的机会成本越来越高。

Bun 的 4 倍编译性能提升就是一个真实的案例——Zig 因为 AI 禁令而错过了这个补丁。虽然 Zig 有正当的架构层面理由，但从纯性能角度看，这是一个实实在在的损失。

悖论三：人才市场的竞争

如果 Zig 禁止 AI 辅助贡献，而有类似项目允许 AI 辅助，有能力的贡献者可能选择更"友好"的项目。在 AI 已经深度融入许多开发者工作流的 2026 年，"不能用 AI"本身就是一个参与门槛。

可能的出路：混合策略

我认为最有可能的演进方向是一种"分层 Contributor Poker"：

Layer 0: Issue 报告 → 禁止AI（培养问题分析能力）
Layer 1: 文档贡献 → 允许AI辅助（低风险，高产出）
Layer 2: 测试代码 → 允许AI辅助（可验证）
Layer 3: 功能代码 → 禁止AI（核心投资区）
Layer 4: 架构决策 → 绝对禁止AI（最高风险区）

每个Layer有不同的AI策略：
- 低风险+高可验证性 → 允许AI
- 高风险+低可验证性 → 禁止AI

这种策略既保留了 Contributor Poker 的核心价值（在关键领域投资人类贡献者），又不至于完全排斥 AI 带来的效率提升。

从 Zig 看开源项目的未来：人还是代码？

Zig 的 AI 禁令引发的争论，本质上是关于开源项目核心价值的元问题：开源项目到底是在生产代码，还是在培养人？

传统观点认为，开源项目的产出是代码。从这个角度，AI 辅助贡献只要代码质量过关，就不应该被拒绝。

但 Zig 的 Contributor Poker 揭示了一个更深层的真相：成功的开源项目，其核心竞争力从来不是代码，而是人。

Linux 之所以能持续 30 年发展，不是因为它的代码库不可替代，而是因为它培养了几千个深度理解内核子系统的贡献者。如果 Linux 的所有代码今天被删除，那些贡献者可以在几年内重写大部分功能。但如果那些贡献者离开了，即使保留所有代码，Linux 也无法继续演进。

Zig 的 AI 禁令是一种激进的、有代价的、但在逻辑上自洽的选择：在代码和人之间，它选择了人。

这种选择是否正确，可能要到 5 年后才能评判。但无论结果如何，Zig 的 Contributor Poker 框架为我们提供了一个理解开源项目治理的新视角——在这个 AI 正在重新定义"写代码"含义的时代，我们需要重新思考的不只是"怎么写代码"，还有"为什么写代码"和"谁在写代码"。

代码是副产品。人才是产品。这就是 Contributor Poker 教给我们最重要的一课。

参考资源：

• Zig 官方行为准则：https://ziglang.org/code-of-conduct/
• Loris Cro《Contributor Poker and Zig's AI Ban》：https://kristoff.it/blog/contributor-poker-and-ai/
• Simon Willison 的分析：https://simonwillison.net/2026/Apr/30/zig-anti-ai/
• Zig 2025 年度财务报告：https://ziglang.org/news/2025-financials/