开源项目通常把 Issue 当作默认入口：报告缺陷、提出需求、讨论设计，再由维护者决定是否实施。但“禁止 Issue，只用 PR”反过来设计协作流程——项目不再维护一个不断膨胀的愿望清单，贡献者需要用可审查的改动表达问题和方案。
这不是适合所有仓库的规则，却值得维护者认真评估。它减少了分类、追问和关闭陈旧 Issue 的成本，也把社区互动从“提出任务”推向“提交可验证结果”。代价同样明显：贡献门槛会升高，一些尚未形成补丁的重要反馈可能因此消失。
PR 不只是代码提交
只接受 PR，并不意味着每次讨论都必须附带完整实现。PR 可以修改不同类型的仓库内容：
- 用测试用例复现缺陷，即使暂时没有修复；
- 修改设计文档，提出可逐行评论的方案；
- 补充基准测试，证明某个性能问题；
- 修正文档中的歧义或缺失步骤；
- 提交最小实现，让讨论围绕真实差异展开。
关键变化是：讨论对象从一段自然语言描述，变成了仓库中的具体差异。维护者可以运行测试、检查文件影响范围，也可以针对某一行提出意见。方案被拒绝后，讨论记录仍然与代码上下文绑定，而不是留下一条难以执行的待办事项。
不过，这套方法不应被误解为“没有补丁就不要说话”。对安全漏洞、行为不明确、跨模块设计和新贡献者求助，仓库仍需提供明确入口，例如安全邮箱、讨论区或维护者联系方式。
把协作规则写进仓库
如果团队决定试行，可以这样实践：先关闭仓库的 Issues 功能，再通过贡献指南和 PR 模板说明可接受的提交形式。以下示例假设项目托管在 GitHub，并已安装 GitHub CLI。
将 OWNER/REPO 替换为实际仓库：
gh repo edit OWNER/REPO --enable-issues=false
随后创建 .github/pull_request_template.md：
## 这次改动解决什么问题？
请描述当前行为、期望行为，以及为什么需要修改。
## 改动类型
- [ ] 缺陷修复
- [ ] 测试或缺陷复现
- [ ] 文档改进
- [ ] 设计提案
- [ ] 功能实现
## 如何验证？
请提供可重复执行的命令和预期结果。
```bash
# 例如：npm test
范围检查
- [ ] 改动保持最小范围
- [ ] 已补充或更新测试
- [ ] 已说明不兼容行为
还可以增加一个轻量级 GitHub Actions 检查，要求 PR 描述包含验证信息。保存为 `.github/workflows/pr-description.yml`：
```yaml
name: Check PR description
on:
pull_request:
types: [opened, edited, synchronize, reopened]
permissions:
pull-requests: read
jobs:
validate:
runs-on: ubuntu-latest
steps:
- name: Require verification section
env:
BODY: ${{ github.event.pull_request.body }}
run: |
if ! printf '%s' "$BODY" | grep -q '## 如何验证？'; then
echo 'PR 描述必须包含“## 如何验证？”章节。'
exit 1
fi
这段工作流只检查章节是否存在，不判断内容质量。更复杂的规则容易诱导贡献者填写模板化文字，反而增加噪声，因此自动检查应保持克制。
哪些项目更适合
这种模式更适合范围清晰、测试完善、维护者数量有限的工具型项目。贡献者能够快速复现行为，并用小型补丁说明问题，PR 就会成为高密度的沟通媒介。
以下场景则要谨慎：
- 面向非开发者的软件，用户没有能力提交 Git 补丁；
- 产品需求依赖大量前期调研，无法先写代码再讨论；
- 安全问题需要私密报告渠道；
- 大型项目需要公开路线图和跨团队任务跟踪；
- 仓库尚无自动化测试，维护者无法低成本验证 PR。
另一个风险是重复劳动。没有公开 Issue 列表后，多位贡献者可能同时修复同一问题。可以保留 Discussions、公开项目看板或短期的 Draft PR，作为“我正在处理”的信号。
先试行，再决定是否长期采用
不要把关闭 Issue 当成价值判断。它只是把维护成本从问题队列转移到补丁审查，同时把一部分成本转移给贡献者。一个务实的试行周期可以关注四项指标：首次响应时间、PR 合并率、重复提交数量，以及外部贡献者的流失情况。
采用前可以检查：
- README 是否清楚说明反馈入口；
- 是否接受仅包含失败测试或设计文档的 PR；
- 是否提供安全漏洞的私密通道；
- CI 是否能让贡献者自行验证改动；
- 维护者是否会及时关闭范围外的 PR；
- 是否为不会编程的用户保留替代渠道。
“只用 PR”的真正目标不应是拒绝问题，而是让问题更快变成可验证、可审查、可合并的改动。如果它只是减少了公开反馈，却没有缩短交付周期，那么这项规则就需要重新评估。