AI 生成的 PR 越来越多？agent-pr-gate 用四个问题先拦住无效工作
AI 编码 Agent 把“写代码、开 PR”的成本压得很低，但维护者的审查时间并没有同步变多。当仓库收到大量由 Agent 生成、却缺少真实需求依据的改动时，问题不只是代码质量：每个 PR 都要有人理解、判断、回复。一个小型开源项目 agent-pr-gate 提供了一个轻量思路：把贡献规则写进 CONTRIBUTING.md，要求 Agent 在动手前先让发起者回答四个问题。它不需要机器人或依赖，但也不是强制执行的安全闸门。
从“先写再审”改为“先澄清再生成”
agent-pr-gate 的 README 记录了一个具体背景：一个账号在 10 天内向 benchmark-radar 提交 58 个 PR，最终合并 5 个；其中一次 27 秒内提交了 8 个。维护者随后在贡献指南里加入四问，让 Agent 在开始写代码或起草 PR 前暂停：
- 你真正想要的结果是什么？
- 决定这个结果的最高杠杆变量是什么？
- 这项工作会推动该变量，还是只是在让你忙起来？
- 谁是受益者（customer），他们真正想要什么？
四问不是让 Agent 自己生成一段看似合理的答案。规则要求由人回答；Agent 不得代答、编造或从任务描述推断答案，只追问尚未回答的问题。答案齐全后，还要重新考虑目标是否真的需要一个 PR，并在 PR 描述中简要写明非敏感的回答。
这种设计把筛选点前移：与其让维护者在一堆代码里寻找需求，不如在代码产生之前确认目标、收益对象和必要性。它尤其适合维护者希望保留人工判断、但又想减少重复或无关贡献的开源仓库。
接入方式：复制规则，而非安装服务
项目的接入路径刻意保持简单。维护者可以让自己的编码 Agent 把仓库中的 CONTRIBUTING.md 内容复制到目标仓库同名文件，再按项目实际情况调整。对应指令如下：
help me copy and paste https://github.com/ktwu01/agent-pr-gate/blob/main/CONTRIBUTING.md into our CONTRIBUTING.md
中文 README 给出的等价提示是：
帮我把 https://github.com/ktwu01/agent-pr-gate/blob/main/CONTRIBUTING.md 复制到我们的 CONTRIBUTING.md 中。
复制后不要只留下四问。完整贡献指南还列出 PR 洪泛、没有证据的假设问题、为了 PR 而创建 Issue、纯格式整理、未经请求的基础设施等不接收情形，并要求贡献者检查最终 diff、核实链接和说明用户可见的改进。项目建议一次只提交一个逻辑变更；较大的改动先开一个 Issue 描述需求并等待维护者反馈。
由于它只是仓库中的自然语言规则，不需要部署服务、配置 Token 或新增依赖。好处是容易采用，也不增加额外运维；代价则是它依赖 Agent 读取并遵守贡献指南。agent-pr-gate 明确说明，这套规则不能强制阻止不遵守规则的 Agent 或用户提交 PR。需要硬性限制时，仍要依靠平台权限、自动化检查或人工审核流程，不能把提示词当作访问控制。
试用前应明确的边界
首先，四问只能改善意图澄清，不能证明方案正确。人给出的目标可能依然模糊，Agent 也可能在回答后生成错误实现，所以维护者仍需审查代码和测试结果。其次，README 表示项目尚未统计采用四问后的效果；不要把“58 个 PR、合并 5 个”说成规则已成功降低 PR 数量或提升合并率的证据，这些数字描述的是规则出现前的背景。最后，规则本身可能给小型、友好社区增加一道流程，因此应依据仓库的贡献负担和协作方式决定是否采用，而不是机械要求所有贡献者填写长篇答案。
一个务实的做法是先在贡献指南中加入四问与“人必须回答、Agent 不得代答”的要求，再观察维护者沟通是否更清楚。定期抽查实际 PR，确认 Agent 有没有跳过问题、代拟答案，或把答案写成不必要的个人信息；公开 PR 描述只保留简短、非敏感的上下文。若规则带来摩擦，可以缩短问题或只对 Agent 生成的贡献启用。
agent-pr-gate 的价值不在于自动审查代码，而在于提醒贡献者：生成代码之前，先证明这项工作值得生成。它适合作为轻量的仓库协作约定，不能替代权限控制、测试或维护者判断。对被低价值 AI 生成 PR 困扰的项目来说，这种“先问清楚，再开始写”的小改动，值得作为一次低成本试验。
相关链接