周末写了一篇用 pi + DeepSeek 做 Codex 备用方案的文章。
写完之后，我又顺手翻了翻 pi 这个项目的其他内容，结果发现，真正有意思的地方不只是工具本身，而是它背后的一套协作方式。
尤其是它的 AGENTS.md 和 CONTRIBUTING.md，读完之后我有点意外。
这个项目的很多规则，和我们平时理解的开源社区几乎是反着来的。
- 新贡献者的 issue 和 PR 默认关闭。
- 周末提交的 issue 不处理。
- 如果你不理解自己提交的代码，PR 会直接被关掉。
这些规则看起来很硬，但结合 Mario Zechner 最近那篇文章一起看，就会发现它不是单纯的「不欢迎贡献者」，而是在认真思考一件事：
AI 时代，开源项目到底该怎么可持续地维护下去。
从 Mario 的那篇博客说起#
4 月 8 日，pi 的作者 Mario Zechner 发了一篇博客：I’ve sold out。
标题有点自嘲，内容却很真诚。
他在文章里回顾了自己从 2009 年开始做开源的经历。先是 libGDX，一个跨平台游戏开发框架，曾经是 Android 上很流行的游戏引擎，Ingress 和《杀戮尖塔》（Slay the Spire）都用过它。
后来他参与了一家叫 RoboVM 的创业公司，做 JVM 到 iOS 的 AOT 编译器。再后来，RoboVM 被 Xamarin 收购，Xamarin 又被微软收购，微软最终关掉了 RoboVM。
作为当时的「OSS guy」，Mario 不得不去写那篇「抱歉，不再开源了」的公告。结果可以想象，他在社交网络和邮件里被骂得很惨。
问题是，这个决定并不是他能控制的。
这段经历让他对 VC、创业公司和开源之间的关系有了非常清醒的认识。说得更直白一点，就是他被现实教育过。
所以当 pi 因为 OpenClaw 爆火，被越来越多 VC、大厂和潜在投资人关注时，他面对的不是一个简单的「要不要变现」问题，而是一个他以前已经踩过坑的问题：
如果一个开源项目突然有了商业价值，接下来该怎么办？
他最后的选择不是自己出来开公司，而是加入 Earendil。
原因也很简单：他有一个四岁的孩子。他想陪孩子长大。
如果自己做 CEO，接下来的就是找 co-founder、找 PMF、搭团队、搞企业文化、处理各种人和钱的问题，然后慢慢停止写代码，变成一个他不喜欢的「管理者」。
加入 Earendil 之后，他可以继续写代码，继续维护 pi，同时也有一个团队来帮他处理商业化的事情。
Mario 在文章里也说：pi 的核心代码会继续保持 MIT 协议，可以 fork，可以使用，可以基于它做产品。真有一天方向不对，fork 按钮还在那里。
因为他当年亲眼看过 libGDX 社区在 RoboVM 闭源之后 fork 出 MobiVM，所以他知道这件事真的会发生。
Armin Ronacher 的加入#
Mario 加入 Earendil 的另一个关键原因，是 Armin Ronacher。
如果你写过 Python Web，大概率见过这个 ID @mitsuhiko。他是 Flask 的创建者，也写过 Jinja2、Click、Werkzeug 等这些 Python 生态里非常重要的项目。同时，他也是 Sentry 的联合创始人，对「开源项目如何商业化」这件事有实际经验。
Armin 也写了一篇文章，欢迎 Mario 加入 Earendil：Mario and Earendil。
他对 pi 的评价：pi 并不是靠喊得最大声、跑得最快来吸引人的，而是能看出来作者很在意软件质量、设计感、可扩展性和长期维护。
现在很多 AI coding 工具给人的感觉是：先发出来，先占坑，先把声量打起来。至于设计是不是统一，代码是不是干净，长期能不能维护，反而经常被放到后面。
pi 给人的感觉不太一样。
它不是最会宣传的那个，但你越往仓库里看，越能感觉到作者对工程细节是有要求的。
Mario 和 Armin 认识已经十几年了。最早是在 Reddit 的 r/austria 版块互相辩论，后来在线下见面，慢慢成了朋友。2025 年 AI 编码工具爆发之后，Steinberger、Mario 和 Armin 经常交流、实验、互相 review 博客文章，后来还被人调侃成「维也纳编码代理学派」。
这个背景也挺重要。
很多商业合作看起来是突然发生的，其实背后往往是长期信任的结果。尤其是开源项目，一旦涉及所有权、商标、协议和未来路线，只靠一份合同是不够的。
你得相信一起做事的人不会乱来。
AGENTS.md：给 AI agent 的项目入职手册#
pi 仓库里有一个 AGENTS.md 文件。
我一开始只是随便点进去看了一眼，结果发现它写得非常细。
里面规定了 AI agent 参与 pi 开发时要遵守的规则，包括：
- 回复要简洁，不要表情符号，不要废话
- 不要随便使用
any类型 - 不要使用内联
import - 不要为了绕过类型错误而删除或降级代码
- 修改代码之后要跑
npm run check - 不要在没理解的情况下删除看起来「没用」的代码
- 新增 LLM Provider 要改哪些文件、补哪些测试
- 多个 agent 并行工作时，不能用
git add -A - 不能用
git stash - 不能用
git reset --hard - 发布流程该怎么走
这些规则看起来很细，甚至有点啰嗦，但如果你真的用过 coding agent，就会知道它们很有必要。
现在的 agent 不缺能写多少代码，缺的是写出高质量代码。
有些规则不是靠 prompt 临时补充，这样很容易漏掉。AGENTS.md 的价值就在这里：它把项目里的工程习惯写成了一份固定的上下文。
这样就给 AI agent 一个「操作手册」。
如果你的项目也已经开始大量使用 AI 编码工具，可以认真参考一下 pi 的做法，给自己的项目也写一份 AGENTS.md。
不用一上来写得很复杂。先把最容易出错的几件事写进去，就已经能减少很多无效修改和 Token 浪费了。
CONTRIBUTING.md：先把你的 PR 关掉#
如果 AGENTS.md 写给机器，CONTRIBUTING.md 就是写给人的——措辞直接，不讲客气。
一、不懂就别提。 用 AI 写代码可以，但如果你解释不了自己的 PR 做了什么、怎么跟系统交互，直接关掉。你用 AI 省下的时间，不该变成 maintainer 替你兜底的成本。
二、新人默认关闭。 所有新贡献者的 issue 和 PR 自动关闭。想「转正」？靠 maintainer 在 issue 下回复的信任标记——不是 GitHub label，是评论内容：回复 lgtmi，未来 issue 不再自动关闭；回复 lgtm，issue 和 PR 都不再自动关闭。每天 maintainer 会浏览被关闭的 issue，有价值的挑出来重新打开并给出标记。pi 不是拒绝新贡献者，是要求你先证明自己的提交值得 review——agent 让制造 issue/PR 的成本越来越低，门槛就越来越重要。
三、周末不受理。 周五到周日提交的 issue 自动关闭，不进入周一 review 队列。着急就去 Discord。FAQ 里的解释很直白：“Maintainers need uninterrupted time away from the issue tracker.”
四、两次无视规则封禁。 如果两次无视 CONTRIBUTING.md，或用 agent 向 issue tracker 批量灌水，会被 Pi 项目永久封禁。
这些规则背后的逻辑#
表面上看 pi 的规则让人觉得它不欢迎贡献者，不欢迎社区参与。
但继续读 CONTRIBUTING.md 的 FAQ，就能看到它真正想解决的问题。
pi 收到的 issue 数量已经超过了维护者能实时认真 review 的范围。很多 issue 没有达到质量要求，也没有遵守 CONTRIBUTING.md。更麻烦的是，有些内容是被 agent 没怎么思考就直接丢到仓库里的。
这就是现在很多项目会越来越头疼的问题。
AI 降低了写代码和写 issue 的成本，但没有自动提高提交质量。
甚至很多时候，它会让低质量内容变得更像高质量内容。格式完整，语气礼貌，文字通顺，但问题可能是错的、重复的、不可复现的，或者需要 maintainer 花大量时间去验证。
这对开源维护者来说很危险。
因为每一个看起来「还行」的 issue，背后都可能是一笔隐藏成本。
- 你要读。
- 你要判断。
- 你要复现。
- 你要回复。
- 你要解释为什么不接受。
这些都是维护成本。所以 pi 的自动关闭机制，本质上是在给 maintainer 创造缓冲区。
不是所有东西都立刻进入正式 review 流程，而是先被挡在外面，再由维护者按自己的节奏挑出真正值得处理的内容。
这和 Mario 在博客里讲的生活选择是连在一起的。
他不想再过那种孩子哭着说「daddy isn’t here」的生活。Earendil 团队里很多人也都有孩子，公司文化上也重视这一点。
这就解释了为什么 pi 的规则会这么强调边界。
它不是单纯为了控制贡献者，也不是为了显得高冷，而是在保护两件事：
- 维护者的生活质量。
- 项目的代码质量。
这两件事如果保不住，开源项目表面再热闹，最后也很容易走向 burnout。
对你的项目有什么参考价值#
pi 的做法不一定适合所有项目。
如果项目很小，贡献者也不多，这个门槛就是在自嗨。
但如果你的项目已经开始受到 AI 生成 issue、AI 生成 PR、低质量自动化提交的影响，那 pi 的做法确实值得参考。
但不管项目大小，以下可以直接借鉴的点：
- 写一份 AGENTS.md
如果你的项目里已经开始使用 AI coding agent，就不要只依赖临时 prompt。
把项目规则写下来。
比如测试怎么跑、哪些命令不能跑、代码风格是什么、哪些目录不能随便改、提交前必须检查什么。
这些内容写进 AGENTS.md，比每次重新解释更稳定。
- 把质量要求写具体
不要只写「欢迎高质量贡献」。
应该写清楚什么样的 issue 会被处理，什么样的 issue 会被关闭。
比如：
- 必须使用 issue template
- 必须说明问题是什么
- 必须解释为什么重要
- bug 必须提供复现方式
- 大需求先讨论，不要直接上 PR
规则越具体，maintainer 的解释成本越低。
- 保护维护者的时间
开源维护不是客服。
不是所有时间都应该是响应时间。
可以明确写出来：自测通过了再找 maintainer review，低质量问题不保证回复。
这听起来有点冷，但比长期消耗到不想维护要好得多。
- 建立信任机制
pi 对于新贡献者的 issue 和 PR 默认关闭，但通过了 maintainer 的回复之后就可以解锁。然后这个人的 ID 就会被记录下来，后续提交就不会再被自动关闭了。
最后#
我看完 pi 的这些规则，最大的感受是：
热门开源项目的稀缺资源可能不再是贡献者，而是 maintainer 的时间。
尤其是 AI Agent 爆发后，贡献的数量可能会越来越多，质量却未必同步提高。
这时候，一个项目真正需要保护的可能不是「欢迎更多人来贡献」，只是「欢迎更多有价值的贡献」。
pi 的规则看起来反直觉，但它至少诚实地面对了这个问题。
- 它没有假装所有贡献都是好贡献。
- 也没有假装 maintainer 的时间是无限的。
AI 时代的开源项目，可能需要更多这样的思考和设计，让项目真正保持可持续的维护和高质量的发展。
