18 贡献者门禁 默认关闭所有新人的 issue 和 PR——在 agent 时代，这可能是理性的

先记住这一句

这看起来很不友好，但它回应的是一个新问题：agent 让「生成一个看起来很专业的 issue」的成本降到接近零，而「判断这个 issue 是否真实、是否值得投入」的成本没有下降。

当提交成本崩塌而审阅成本不变时，任何「默认打开、事后过滤」的机制都会被压垮。pi 的应对是把默认值从「打开」改成「关闭」，并把开门的权限做成一个可以逐步授予的二级许可。

规则原文

All issues and PRs from new contributors are auto-closed by default.

Maintainers review auto-closed issues daily and reopen worthwhile ones. Issues that
do not meet the quality bar below will not be reopened or receive a reply.

两级授权，靠回复里的关键词触发

命令必须出现在维护者回复的开头（可以在若干 @username 提及之后）或结尾。CONTRIBUTING.md:34 这条位置约束不是形式主义——它防的是维护者在正文里写「this lgtm」被误判为授权。

实现是两个正则：

const approvalAtStartPattern = /^[\s.]*(?:@[A-Za-z0-9](?:[A-Za-z0-9-]{0,37}[A-Za-z0-9])?(?:\s*,\s*|[.:]\s*|\s+))*(lgtmi|lgtm)(?=$|[\s]|[^\p{L}\p{N}_\s])/iu;
const approvalAtEndPattern = /(?:^|[\s.])(lgtmi|lgtm)\s*(?:[^\p{L}\p{N}_\s])?\s*$/iu;
const approvalMatch = commentBody.match(approvalAtStartPattern) ?? commentBody.match(approvalAtEndPattern);

授权结果写进一个纯文本文件 .github/APPROVED_CONTRIBUTORS，格式是 <username> <capability>。APPROVED_CONTRIBUTORS:2 快照时共 240 条：238 条 pr、2 条 issue。

这个比例本身是个发现：拿到 lgtmi（只开 issue）的人几乎没有——维护者一旦决定开门，基本直接给全权。两级设计在实践中退化成了一级。

关闭时说了什么

自动关闭的回复不是模板化的敷衍，它解释了机制并给出可行动的下一步：issue-gate.yml:100 并附上 CONTRIBUTING.md 的链接与「不符合质量标准的不会被重开也不会收到回复」的明确预期。issue-gate.yml:102

质量标准与「唯一规则」

**You must understand your code.** If you cannot explain what your changes do and how
they interact with the rest of the system, your PR will be closed.

Using AI to write code is fine. Submitting AI-generated slop without understanding it is not.

issue 的标准同样具体：放不下一屏就太长了；用自己的话写（非要用 LLM 生成，就补一条明确标注 AI 的评论）。CONTRIBUTING.md:42

还有一条明码标价的封禁规则：忽视本文件两次，或用自动化灌大量 issue，GitHub 账号永久拉黑。CONTRIBUTING.md:52

周末降级

周五到周日提交的 issue 不保证被审阅；紧急问题去 Discord。CONTRIBUTING.md:25 FAQ 里的解释很直白：我们在工作时间做 triage。

把「维护者也有作息」写进贡献指南，是这份文件里最不常见、也最诚实的一条。

为什么这在 agent 时代是理性的

传统开源的隐含契约是：提交 issue 需要一定成本（复现、写清楚），这个成本本身就是过滤器。agent 把这个成本消灭了——现在任何人可以在 30 秒内产出一个格式完美、措辞专业、可能完全基于幻觉的 bug 报告。

而 FAQ 里点出了更麻烦的一点：「打磨得很漂亮的 AI 生成 issue 仍然可能是错的、误导性的，或者调查起来很昂贵。」CONTRIBUTING.md:93 质量信号和真实性脱钩了——过去「写得好」是「认真做过功课」的代理指标，现在不是了。

所以自动关闭真正改变的不是「谁能提 issue」，而是时间的所有权：从「issue 一来就欠一个回应」变成「维护者按自己的节奏批量处理」。关闭一个 issue 不消耗注意力；让它开着会。

他们没有把 triage 交给 AI

FAQ 里专门有一问：为什么不让 AI 全权 triage？回答是——AI 可以帮忙归并重复、做摘要、指出缺失信息，但不被信任做最终的维护者决定；人的审阅仍是最后一道关。CONTRIBUTING.md:93

这个立场值得注意，因为它出自一个做 agent 的团队。他们在自己最熟悉的技术上划了一条界：用 AI 做归并与摘要（降低成本），不用 AI 做取舍（那是判断）。仓库里确实有 issue-analysis.yml 与 issue-triage-labels.yml 两个 workflow 承担前者。

代价：把偶然的好贡献一起挡掉

自动关闭是无差别的。一个路过的资深工程师发现真 bug、写了个精准的三行 issue——他也会被关闭，也要等到某天被重开。而一个被自动关闭的 issue 给人的第一印象是「不受欢迎」，很多人不会等。

pi 的对冲有三条：承诺每日审阅、把规则和理由写得极其清楚、以及给 Discord 作为快速通道。但这三条都要求提交者先读 CONTRIBUTING.md——而被自动关闭的人里，最不可能读它的恰恰是那些随手扔个 issue 的人。这个机制筛掉的是低投入者，其中混着一部分高价值的低投入者。

240 人这个数字说明什么

门禁不是「只有核心团队能提 PR」。240 个已批准的账号，配上 286 位历史提交者（第 01 章），说明这道门确实在开，只是要先敲。

把它理解成「默认关闭 + 一次性人工准入」比理解成「封闭开发」更准确：你只需要通过一次，之后就是正常贡献者。

• 依赖维护者真的每天看。整个机制的正当性建立在「每日审阅被关闭队列」这个承诺上。承诺一旦不兑现，它就退化成「静默拒绝所有外部输入」，而外部无从分辨这两者。
• 两级授权在实践中退化成一级。240 条里 238 条是 pr。lgtmi 这一级几乎没被用过——多一级的设计成本没有换来对应的收益。
• 规模不可迁移。这套做法之所以可行，是因为 pi 有活跃维护者、有 Discord、有明确的产品方向。一个维护者已经倦怠的项目照抄这套，得到的只是一个自动拒绝机器人。
• 对首次贡献者的观感成本是真实的。「issue 被自动关闭」在多数人的经验里等于「被无视」。文档解释得再清楚，也要人先点进去看。
• 门禁保护的是注意力，不是质量。它不提高被接受的 PR 的质量，只减少需要看的数量。质量仍然靠「你必须理解你的代码」这条人工判据。

检查过并确认：lgtm/lgtmi 的位置约束在 workflow 里有真实实现（两个正则，开头/结尾各一），不是只写在文档里的口头规矩。approve-contributor.yml:35

• 当提交成本崩塌而审阅成本不变时，改默认值，而不是加过滤规则。过滤规则要逐条判断（仍然消耗注意力），改默认值不用。 适用条件：你的 issue 队列已经超出团队处理能力。队列健康时这么做纯粹是自伤。
• 自动关闭必须配一个明确的时间承诺，并把它写进文档。「每日审阅并重开值得的」把「拒绝」变成「排队」。没有这句，机制就是关门。 适用条件：你真的能兑现。兑现不了就别写——写了又做不到比不写更糟。
• 判据定成「你能否解释你的代码」，而不是「是否用了 AI」。后者不可验证也不该验证；前者在 review 中天然可测。 适用条件：所有接受外部贡献的项目。这是全章最该直接抄的一条。
• 用 AI 做归并和摘要，别用 AI 做取舍。pi 是做 agent 的团队，他们在自己最熟的技术上划了这条线，值得当作一个信号。 适用条件：triage 量大到需要自动化。并且你能承受「AI 判错并静默关掉一个真 bug」的后果——不能就别自动化取舍。