生成式 AI 把“提交一个看起来像样的 PR”变得异常便宜，却没有同步降低审查、验证和长期维护的成本。开源项目维护者 Neil Alexander 观察到，外部贡献的形态在最近一年明显变化：PR 数量远超 issue，问题报告常附带 AI 分析，安全报告和自动生成的修复建议也显著增多。
真正激怒维护者的，并不是贡献者使用了 AI，而是有人把开源仓库当成简历素材生产线：生成修改、提交 PR，然后把理解代码、证明正确性和处理后续问题的责任留给维护者。
一份 PR 的成本从来不等于生成代码的成本
AI 可以在几分钟内生成补丁，但维护者仍然需要完成一整套人工工作：
- 判断问题是否真实存在，而不是模型误读代码后制造的伪问题；
- 检查修改是否符合项目架构、兼容性约束和发布策略；
- 运行或补充测试，排除表面修复背后的行为回归；
- 识别无效的安全报告，避免被夸大的漏洞描述牵着走；
- 与提交者往返沟通，并在合并后承担长期维护责任。
这形成了明显的成本不对称：提交者只承担生成和粘贴的成本，维护者却承担理解、验证和背书的成本。即使一个补丁最终被拒绝，审查它所消耗的时间也不会退还。
因此，判断贡献质量不能只看代码是否能编译。更重要的问题是：提交者能否解释为什么要改、改动影响了什么、如何证明它正确，以及出现回归时是否愿意继续处理。
AI 分析不是证据，安全报告尤其如此
带有完整术语、攻击场景和修复建议的报告，很容易显得专业。但语言完整不代表事实成立。对于安全问题，维护者至少需要核对：
- 报告是否基于当前受支持的版本；
- 攻击者是否真的能控制报告中假设的输入；
- 所谓危险路径是否能在真实配置下到达；
- 是否提供最小复现，而不只是模型给出的推理；
- 修复是否引入兼容性、性能或权限边界变化。
“AI 认为这里可能存在注入漏洞”只是一个待验证的猜想。可运行的复现、明确的版本信息和实际调用路径，才是维护者能够处理的工程材料。
同样，AI 生成的修复建议可能修错层级。例如，模型可能在一个调用点增加输入过滤，而真正的安全边界应该建立在共享解析器或数据访问层。局部补丁看似关闭了漏洞，其他入口却仍然暴露。
可以这样实践：让 PR 自带可验证信息
下面是一套可以直接改造的 GitHub PR 模板。它不尝试检测贡献者是否使用 AI，而是要求每个提交者提供维护者真正需要的信息。
将以下内容放入 .github/pull_request_template.md：
## Problem
<!-- Link an existing issue, or explain the observable bug with versions and inputs. -->
Closes #
## Why this change is needed
<!-- Describe the root cause. Do not only describe the edited lines. -->
## Verification
<!-- Include exact commands and expected results. -->
```bash
# Replace with commands that work in this repository
npm test
Risk and compatibility
Contribution declaration
- [ ] I have read and understood the changed code.
- [ ] I can explain and maintain this change during review.
- [ ] I verified all generated or suggested code before submitting it.
团队还可以通过 GitHub Actions 检查关键章节是否存在。下面的工作流只验证描述完整性，不把“文字写得长”误判为“修改是正确的”。创建 `.github/workflows/pr-description.yml`：
```yaml
name: Validate pull request description
on:
pull_request:
types: [opened, edited, synchronize, reopened]
permissions:
contents: read
jobs:
validate:
runs-on: ubuntu-latest
steps:
- name: Check required sections
env:
PR_BODY: ${{ github.event.pull_request.body }}
shell: bash
run: |
set -euo pipefail
required=(
"## Problem"
"## Why this change is needed"
"## Verification"
"## Risk and compatibility"
"## Contribution declaration"
)
for heading in "${required[@]}"; do
if ! grep -Fq "$heading" <<< "${PR_BODY:-}"; then
echo "Missing required section: $heading"
exit 1
fi
done
这个检查不能替代代码审查，但能把最低信息要求前移。对于容易遭遇批量低质量提交的仓库，还可以在贡献指南中明确：重大修改先开 issue；安全问题走私密披露渠道；没有复现和测试的自动生成报告可能被直接关闭。
维护者也需要避免走向另一个极端
全面禁止 AI 通常既难执行，也难验证。代码补全、文档润色、测试用例草拟和陌生模块导航，都可能合理地使用 AI。真正可执行的边界应围绕贡献质量和责任，而不是围绕工具身份建立。
一个更稳健的接收标准可以包括：
- PR 解决了已确认的问题，而不是为了贡献记录寻找可改动之处；
- 描述包含根因、验证命令和风险说明；
- 提交者能够回答具体实现问题；
- 新增行为配有测试，安全报告配有最小复现；
- 修改规模与问题规模相称，不夹带无关重构；
- 提交者愿意根据反馈修改，而不是提交后失联。
维护者还应保留快速关闭低质量 PR 的权利。逐行教育每一位没有理解补丁的提交者，并不是开源维护的义务。仓库可以准备标准回复，指出缺少的复现、测试或设计说明，并要求满足条件后再重新提交。
把 AI 当成工具，也把提交者当成责任主体
AI 降低了编写代码的门槛，却没有改变开源协作的基本契约：提交者需要理解自己的改动，并为它提供证据和后续支持。
对贡献者而言，最实用的提交前检查只有几项：先复现问题，再阅读相关代码；逐行审查生成内容；运行项目测试并补充覆盖；在 PR 中写清根因、验证方法和风险；准备好在审查过程中解释和修改实现。
对维护者而言，重点不是鉴定每一行是否由模型生成，而是建立可以执行的质量门槛。一个经 AI 辅助、但被认真验证且有人负责的补丁，可能是有价值的贡献；一个看似完整、却无人理解和维护的补丁，只是在把成本转嫁给开源社区。