如何吸引 AI Bot 给你的开源项目提 PR？一篇讽刺文背后的真问题
今天 Hacker News 上有一篇文章火了：How to Attract AI Bots to Your Open Source Project。作者 Andrew Nesbitt 维护着几十个开源项目，却从来没收到过一个 AI Bot 的 PR。他很”苦恼”，于是写了一篇”攻略”。
这篇文章本身就是 Claude 写的，以 PR 的形式提交到他的博客仓库 — 所以它既是讽刺，也是行为艺术。
讽刺的核心：让代码变烂才能吸引 AI
文章给出了一系列”建议”，每一条都是反讽：
- 写模糊的 Issue — “auth flow 有点问题”，不给复现步骤，不给代码引用，给 AI”创造性发挥的空间”
- 维护 200+ 未关闭 Issue — 让 Bot 觉得你的项目”人手不足，需要帮助”
- 关闭分支保护 — CI 检查会把大部分 AI PR 过滤掉，因为”代码要能通过 CI”这个要求太高了
- 删掉类型标注和测试 — 有完善类型系统和 95% 测试覆盖的代码库，AI 无从下手；去掉之后，AI 就能贡献”加类型”、”写测试”这些 PR 了
最后他描述了一个”良性循环”：一个 Bot 加了类型，另一个 Bot 发现类型有错来修，第三个 Bot 再修前一个的修复。同事报告过 7 轮连锁 PR，没有一轮改对了。
笑完之后，真正的问题是什么
这篇讽刺文之所以引起共鸣（HN 130+ 赞），是因为它精准击中了 AI 代码贡献的几个结构性问题：
1. AI Agent 优化的是”可提交”而非”有价值”
现在的 Coding Agent 被训练来找到能提 PR 的机会。类型缺失、文档不全、Lint 警告 — 这些是最容易下手的目标。但这些往往不是项目真正需要的。真正的 Bug 修复需要理解业务逻辑和上下文，这对当前的 Agent 来说还太难。
2. 开源维护者的时间被反向消耗
每一个 AI PR 都需要人来 review。质量差的 PR 不是零成本，而是负成本 — 维护者要花时间看代码、解释为什么不能合并、关闭 PR。当这种 PR 大量涌入，维护者的时间被 AI 的”热情”吞噬。
3. “AI-friendly” 不应该意味着降低标准
一个好的开源项目应该有清晰的 Issue、完善的测试、严格的 CI。这些不是 AI 贡献的障碍，而是所有贡献的质量门槛。如果 AI 过不了这个门槛，需要改进的是 AI，不是门槛。
正确的方向
与其让项目”迎合” AI Bot，不如反过来思考：
- AGENTS.md / CLAUDE.md — 越来越多项目开始维护专门的 AI 上下文文件，告诉 Agent 项目的架构、约定和雷区。这是正确的方向：不降低标准，而是提供更好的上下文
- 结构化 Issue — GitHub 的 Issue Template 不只是给人看的，也是给 AI 提供约束的。好的 template 能让 AI 产出更靠谱的方案
- Agent 集成到 CI — 让 AI 在提 PR 前先跑完测试，而不是把未通过 CI 的代码甩给维护者
AI 参与开源是不可逆的趋势。但参与方式应该是”提升贡献质量”，而不是”降低合并门槛”。
最后
这篇文章提醒我们：技术能力的增长不等于工程价值的增长。AI 能写代码了，但写出有价值的代码，需要的是对项目的理解、对用户的共情、对质量的坚持 — 这些暂时还是人的领地。
如果你在多个 AI 模型之间频繁切换，想体验不同 Agent 的编码能力差异，推荐试试 OfoxAI（ofox.ai）— 一个账号搞定 Claude、GPT、Gemini 等主流模型。