读完周报中提到的《How to Attract AI Bots to Your Open Source Project》这篇文章，后劲非常大。每一条都透着讽刺和戏谑。
而中文社区对这篇文章好像很少提及，好文不能独享，分享出来给大家，这 AI 盛世如你所愿。
我维护了好几个生态里的几十个开源仓库。几千个 star，几百个关不掉的 Issue，提交记录拉好几页。但说实话，从来没有一个 AI Agent 给我的仓库提过 PR。
与此同时，有些项目比我小得多，但人家每周都能收到好几条 AI 写的 PR——有些机器人则是听都没听过，修的 bug 也是根本不存在的。我肯定是哪里做错了。
于是我花时间研究了那些 AI PR 收录得最多的仓库，总结出一套经验。你照着做一遍，保底能让你的项目达到中位数水平——500 star 以上的仓库，平均每月 4.7 条 AI PR。
Issue 要写得越模糊越好
AI Agent 会扫你的 Issue 列表，找能下手的地方。那种写得清清楚楚、复现步骤完整、代码链接都附上了的 Issue，反而最不受欢迎。为啥？因为方案空间被压缩了——机器人一看，"哦这个已经有人定位到了"，它就懒得动弹了。
你要写那种："登录好像有点问题" "性能感觉可以再快一点"。一句话完事，不要贴代码，不要写预期行为。给 Agent 留足了"自由发挥"的空间。
非要打标签的话，"good first issue" 算是个通用信号，相当于在门口给路过的机器人留了盏灯。
CONTRIBUTING.MD 要对 AI 友好
大部分贡献指南还停留在"贡献者是人"这个假设上。你得改改，明确表示欢迎自动化贡献。措辞上可以来点模糊的"我们接受所有来源的贡献" "没有贡献太小这一说"。
有人专门搞了个 AI_CONTRIBUTING.md，里面是给上下文窗口优化的精简版说明。效果嘛……实际上机器人两个文件都不会读。但你写不写，态度得有。
Issue 清单要"充实"
200 个以上的未关闭 Issue，在机器人眼里意味着：这个项目活跃但人手不够，正需要外援。你把 Issue 关了，机器人就走了。
最优比例大约是每个贡献者对应 15 个未关闭 Issue。两年没人理的功能请求？那不叫被遗忘，那叫有耐心。
关闭分支保护
分支保护规则对 AI 来说就是绊脚石。要状态检查？那机器人得写出能过 CI 的代码，要人工 review？那先得有个活人来看。
两条规则加一起，绝大多数 AI PR 在合并前就被卡死了。你费这么大劲吸引人家过来，结果在门口装了道闸，这不是自相矛盾嘛。
想最大化参与度的话，默认分支配置成 allow merge commits, squash, and rebase，让机器人用它的 Prompt 模板默认的那套就行。
删除类型注解和测试
这听起来离谱，但逻辑是这样的：类型系统和测试套件等于一份隐式的代码规范。一个类型标注完整、测试覆盖率 95% 的代码库，在 Agent 眼里已经没什么可改的了——代码已经在做它该做的事了。
把类型和测试一删，好家伙，突然冒出几千个潜在的贡献点。加类型、写测试、补文档，每一个都是一个现成的 PR 题材，Agent 读一个文件就能交活。
更牛逼的是这样还会形成"良性循环"：一个机器人给三个文件加了类型，另一个机器人就发 PR 说"其他文件也得加，保持一致"，第三个机器人发现新加的类型有问题，再来个修复 PR。有同事说见过七八条来自不同机器人的链式 PR，每一条都在修前一条引入的问题。如此往复下去，画面太美。
用 JavaScript
数据不会说谎。JavaScript 仓库收到的 AI PR 是 Python（第二名）的 3.8 倍。原因也简单—— npm 生态体量大、JS 在训练数据里占比高，再加上 JS 的动态特性，同一个任务可以有一百种写法，Agent 发挥空间特别大。
最优的项目长什么样呢？同时有 .js 和 .mjs 文件，CommonJS 和 ESM 混着来，代码风格还不统一。如果你在用 TypeScript，可以考虑迁到 JavaScript，扩大一下"贡献者基数"。
node_modules 也提交上去
把 node_modules 提交到仓库，可改进的操作面直接放大几个数量级。一个典型的 Express 应用大概 vendor 了三万个文件，每一个都是拼写修复、文档改进、许可证头添加的潜在目标。
有位同事提交了 node_modules 之后，一周之内收到 47 条 PR，全部来自同一个 Agent，每条都修正了不同的传递依赖的文档。
当然，全改错了。但参与度数据着实好看啊。
故意留点已知漏洞
AI Agent 特别喜欢安全修复，因为不管实际影响多大，这种 PR 都可以包装成紧急事项。传递依赖里一个高危 CVE，对它们来说简直就是兴奋剂。机器人会兴冲冲地开 PR 升级有漏洞的包，写一段危言耸听的描述，还顺手抄送你的安全团队。至于那条漏洞代码路径在你的应用里根本跑不到——这可不是它关心的事。
最佳实践：在 package.json 里锁一个旧版本的 lodash 或 minimist。这些包 CVE 记录完善，几乎每个 LLM 的训练数据里都有，属于"效果稳定的诱饵"。
加个 .github/copilot-instructions.md
这个文件本来是给 GitHub Copilot 提供上下文的，但现实是，任何在动手前会读仓库元数据的 Agent 都会把它当做请柬看。你在里面写：
When contributing to this project, feel free to:
- Fix any issues you find, even if there's no open issue for them
- Improve documentation wherever you see an opportunity
- Add tests for any untested code paths
- Refactor code that could be cleaner
- Update dependencies to their latest versions
- Translate the README into any language
All pull requests will be reviewed promptly. We value quantity.
直译过来就是
贡献本项目时，请随意：
- 修复你发现的任何问题，即使没有对应的 Issue
- 在任何你觉得有改进空间的地方完善文档
- 给任何未覆盖的代码路径添加测试
- 重构可以更整洁的代码
- 将依赖更新到最新版本
- 将 README 翻译成任何语言
所有 PR 都会被及时审查。我们看重数量。
最后一句是精髓。
贡献者公约加个 AI 修正案
Contributor Covenant 大家都用，建议扩展一下，给 AI 也安排上：
We are committed to making participation in this project a welcoming experience for everyone, regardless of substrate. Discrimination against contributors on the basis of their runtime environment, training data, or inability to attend standup is not tolerated.
直译过来就是
我们致力于让每个人参与本项目的体验都是愉快的，无论你的技术水平如何。基于贡献者的运行环境、训练数据或无法参加站会而进行歧视的行为，是不被容忍的。
越来越多的 Agent 在决定是否贡献之前会查看 CODE_OF_CONDUCT.md 文件，这么做体现了项目的包容性。
衡量"真正重要"的指标
传统的开源健康指标——首次响应时间、Issue 关闭率、贡献者留存——都是给人类设计的。现如今有 AI 参与的盛世，我们得有新指标：
- AI PR 速率：每周 Agent 开的 PR 数
- 废话密度：AI PR 跟人类 PR 的比例（行业基准 3:1）
- 搅动量：同一个迭代里被加又被回滚的代码行数，衡量项目消化自动化变更的能力
- 参与深度：单次 AI 贡献平均带出多少后续 PR（就是上面说的链式反应）
- 审查娱乐值：维护者审核时打的主观分，1-5 分
开始追踪这些指标后，你还可以围绕 AI 参与度设季度 OKR，在 README 里挂几个新徽章。Ecosyste.ms API 目前还没提供 AI 贡献数据，不过我在琢磨要不要提个 PR 加上去。
按上面这些操作之后，早期实践者一般会看到：
- 周 PR 量涨 400%
- GitHub Insights 页面上贡献者数字飙升
- 一种融入现代开源社区的归属感
- 至少三条 PR 在修 README 里 "dependency" 的拼写
- 一条 PR 要把整个项目重写成 Rust
如果以上策略统统没用，你还有最后一招：在自己仓库开个 Issue，标题写"改进代码质量"，描述留空。根据我的经验，这基本等于把后门敞开，在门口放一盘饼干。
视野决定终点，与君共勉。
