加载失败
原文是一篇戏谑但务实的“标准协议”草案，旨在给开源维护者处理低质量、AI 生成的 PR 提供规矩和理由。讨论围绕两类问题：一是维护者面对被 LLM 放大的垃圾提交的即时应对（关闭、封禁、屏蔽或彻底关闭 PR 功能）；二是长期技术与伦理对策，包括 Ghostty 式政策、对未注册 bot 的速率限制、GPG 签名与 CI 验证、proof-of-work/Hashcash、以及要求贡献者在不借助 AI 的前提下能解释改动。评论里既有具体操作建议（如用 gharchive 做账号统计、将 PR 权限设为 collaborators-only），也有关于贡献者责任、审查成本不对称和写规范措辞（MUST/SHALL）等更深层的争论。
许多维护者对海量低努力的 AI 生成 PR 表现出强烈挫败感并倾向直接采取惩戒性措施：常见做法是立即关闭 PR、对极低质量投稿封禁或屏蔽提交者。有人举例说明收到的 PR 因字符串定界错误导致整个 CI 失败，维护者直接拒绝并封锁该账号。部分评论支持用粗暴或讽刺的 FAQ 来羞怯“drive-by”投稿者以节省时间，也有少数人主张对第一次犯错的新手保持耐心并尝试教育。
讨论提出多种可操作的防护措施：在策略层面引用 Ghostty 的 AI_POLICY 要求提交者在不借助 AI 的情况下能解释改动；在量化层面有人用 gharchive（GitHub 事件数据）分析出绝大多数用户每天只向少数项目 PR，从而建议限制未注册或脚本化账户的速率。技术手段包括强制 GPG-signed commits、CI 产生可复现构建并通过 pre-receive hook 或 GitHub Actions 签名产物以证明提交来源；也有人建议恢复 proof-of-work/Hashcash、引入 CAPTCHA、甚至收取 $100 保证金或把 PR 权限设为 collaborators-only，但评论同时指出这些方法要么推高运维成本，要么把问题转嫁到算力或门槛上。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7]
很多评论把问题归结为贡献者责任：如果你不能在不借助 AI 的情况下清楚解释你所做的改动和它与系统的交互，那就不应把 AI 产出直接当作贡献提交。建议包括先在个人 fork 中验证、把 AI 输出作为 Issue 或灵感附上 prompts、在 PR 中明确标注“AI 生成/未经人审阅”，以及将 AI 生成的 diff 附为参考而非主文本。实际案例表明，有人用 AI 快速生成补丁后对代码理解不足，进一步用 prompt 修正又导致难以辨别哪些改动是有意的，因此更理想的做法是先理解并手写高层摘要再提交，维护者更愿接受能说明意图与权衡的贡献。
评论普遍强调核心根源是提交与审阅成本的不对称：在 LLM 出现前，生成一个看起来合理的 PR 需要自然摩擦（读代码、编译、测试），现在几十秒能生成可观外观的 diff，但维护者仍需花大量时间去验证意图、边界情况与兼容性。有人用数据指出大多数用户每天只向一项仓库 PR，但极少数账号向多个项目频繁提交的行为像脚本化垃圾；由此得出结论：PR 的描述质量往往比代码 diff 本身更能反映贡献价值，含糊大 diff 常被直接关闭以节省维护者时间。缓解方案倾向于把注意力放在提高 PR 描述与提交者对改动的解释责任上。
讨论里充斥大量讽刺和幽默来表达不满：如用“rm -rf 你的脑子”类的段子、引用“plonk”或“ai;dr”来嘲讽低质量投稿，也有人建议“毒化”AI agent 的上下文以让它丢弃这些 PR。与此同时还有关于规范写法的元讨论，例如对文档中 'MUST'、'SHALL' 等词的法律/语义歧义抱怨，认为规范应使用更明确的措辞。整体语气既有愤怒也有自嘲，许多维护者通过讽刺缓解真实的审查痛点。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6]
PR（Pull Request）: 向上游仓库请求合并代码变更的机制，包含 diff、提交信息与讨论线程，是维护者用于审查和合并贡献的主要单位。
CI（Continuous Integration）: 持续集成，一套自动化构建与测试流程，用来在提交或 PR 时验证代码是否能编译、通过测试与质量检查。
gharchive: gharchive（一个公开的 GitHub 事件数据集/服务），可用于分析 GitHub 上的活动模式，例如每日每用户的 PR 数量分布。
Ghostty（AI_POLICY）: Ghostty 是一个开源项目，其 AI_POLICY 被引用为范例，明确要求如果提交者无法在不借助 AI 的情况下解释改动就不要贡献。
GPG-signed commits / pre-receive hook: GPG 签名的提交用于证明提交者身份；pre-receive hook 是在服务器端在接受推送前运行的钩子，可用于验证签名或强制可复现构建签名以防自动化伪造。
proof-of-work / Hashcash / CAPTCHA: 一类防垃圾手段：Hashcash 或 proof-of-work 要求计算成本以提高生成成本，CAPTCHA 要求人类交互，但这些方法会增加能耗或对合法贡献者造成负担。
Claw-like agents: 泛指那些用 LLM/脚本批量生成并提交 PR 的自动化代理或 bot，会在大量仓库中进行低成本、重复性的“drive-by”投稿。