Vouch：Mitchell Hashimoto 用一张"担保名单"挡掉 AI 垃圾 PR
阅读时间: 大约 8 分钟
Vouch：Mitchell Hashimoto 用一张”担保名单”挡掉 AI 垃圾 PR
过去二十年，开源社区靠”信任并验证”运转：理解一个代码库、改出一个 PR 的门槛足够高，天然过滤掉了低质量贡献者。但 AI 工具让”看上去像模像样、实则毫无理解”的垃圾 PR 可以被批量生产，门槛崩塌了。Vagrant、Terraform、Ghostty 的作者、原 HashiCorp CEO Mitchell Hashimoto 为此新开了一个项目 Vouch：把开源从”隐含信任”切换到”显式信任”——必须有人担保过你，你才能在这个项目里提 Issue/PR。
一、它的核心规则
官方 README 写得很直白：一个人必须被”担保（vouched for）“之后，才能与项目的特定部分互动（具体哪些部分可配置）；也可以被显式”公开谴责（denounced）“，从而被拉黑。谁来担保、担保谁、担保后能干什么——这些策略完全由接入项目自己定。
这套系统不是凭空发明的。Mitchell 明确说它提炼自 Pi 项目（badlogic/pi-mono）已经跑通的做法，再泛化成通用系统，并做了一些改动。而 Vouch 自己现在正在 Ghostty（他的另一个项目）上自用验证。
二、一个纯文本文件就是信任数据库
整个信任列表存在一个扁平文件里，默认查找路径是 VOUCHED.td 或 .github/VOUCHED.td，格式极简到”用任何 POSIX 工具和任何语言都能解析、不需要外部库”：
# 注释以 # 开头
username
platform:username
-platform:denounced-user
-platform:denounced-user 谴责理由规则只有几条：一行一个 handle（不带 @），按字母排序；可选 平台:用户名 前缀；谴责一个用户就在前面加 -；handle 后可空格跟理由。
.td 这个后缀官方解释为 “Trustdown”——故意和 “Markdown” 玩梗。Mitchell 说他打算把它正式化成一个”信任列表”规范（只管列表本身，不管怎么产生、怎么用），但要等 Vouch 本身用法稳定后才会发布规范。这是一个需要记住的口径：Trustdown 目前只是 README 里的一个想法，尚非正式标准。
三、七种 GitHub Actions + 一个 Nushell CLI
集成进 GitHub 项目靠官方提供的一组 Actions，选择用哪些就完全控制了”谁能被担保、能做什么”：
| Action | 触发时机 | 作用 |
|---|---|---|
| check-issue | issues | 开/重开 Issue 时检查作者是否被担保，可选自动关闭未担保者 |
| check-pr | pull_request_target | 开/重开 PR 时检查作者，可选自动关闭 |
| check-user | 任意 | 查某用户状态，默认未担保则失败 |
| manage-by-discussion | discussion_comment | 协作者在 Discussion 评论里担保/谴责/取消 |
| manage-by-issue | issue_comment | 协作者在 Issue 评论里担保/谴责 |
| sync-codeowners | 任意 | 把 CODEOWNERS 里的 owner 自动补进担保名单 |
| setup-vouch | 任意 | 在 PATH 上装好 vouch CLI |
CLI 本身是一个 Nushell 模块，只依赖 Nushell，没有其他外部依赖。查状态的退出码被刻意做成机器可读：0 = vouched、1 = denounced、2 = unknown。协作者在 Issue 里发 vouch、vouch @user、denounce、denounce @user <理由> 等评论即可操作，关键词还能自定义。
四、客观分析：优势与局限
优势：
- 门槛前置、可自动执行：未担保者的 Issue/PR 被自动关闭，维护者不必再人工逐条拒绝 AI 垃圾；
- 信任可跨项目传递：
sync-codeowners与纯文本名单让一个项目的可信贡献者能被另一个项目”抄作业”，形成信任网络； - 极简、可审计：一个 git 跟踪的文本文件，谁担保了谁一目了然，review 和回滚成本极低；
- 谴责而非封禁：保留理由记录，其他项目可以”继承”这份坏 actor 名单，比平台拉黑更可移植。
局限与口径（官方自己强调的）：
- 仍是实验系统：README 顶部 WARNING 明确写着”这是一个实验系统，正在 Ghostty 使用中，会根据反馈持续改进”——不要当成生产级成熟治理框架；
- 冷启动悖论：第一个被担保的人从哪来？项目必须先有一群可信的 maintainer，这套机制才能运转，新项目很难直接套用；
- 可能误伤善意新手：把”提交 PR”这件事也变成门槛，对小项目降低了贡献多样性；是否把 require-vouch 关掉、只谴责坏分子，需要项目自己拿捏；
- 依赖 Nushell 运行 CLI：对没用过 Nushell 的团队是额外学习成本；
- 规模数字来自第三方：约 5.1k stars（官方仓库页）、约 150 个仓库采用
VOUCHED.td是第三方研究站在 2026 年 6 月的统计，官方未自报采用量。
五、适合谁
- 被 AI 批量低质 PR 淹到、维护者疲于审核的成熟开源项目；
- 已经有一批可信核心贡献者、愿意把贡献门槛”显式化”的社区；
- 想跨项目共享一份坏 actor 名单的组织。
对还在求 star、求贡献的早期项目，Vouch 可能是把双刃剑：它挡得住 AI 垃圾，也可能挡掉下一个未来的核心开发者。