EP02 说五个角色 PR 都遵循了四段式格式。EP03 说角色系统的三个信号让贡献门槛低。但还有一个问题没问：这五个角色真的都够好吗？
五个角色 PR 的审查现实
翻回 #24-28 的 PR 记录。这五个角色 PR 的审查过程是这样的：
没有统一的审查清单。没有”角色质量标准”文档。没有”这个 Expertise 列表是否完整”的判断依据。
我作为唯一的维护者，审查标准是脑子里的：
- 四段式格式对不对？✅ 机械检查，五个都对
- Identity 描述是否清晰？大致对，但颗粒度不一
- Expertise 覆盖范围是否合理？很难判断——Performance 的”algorithmic complexity analysis”是精准的，但 SRE 的”availability, alerting, capacity planning, incident response”跨度太大，一个角色真的能覆盖所有这些吗？
- When to Include 是否具体？有的具体（“code touching hot paths”），有的模糊（“any production-related changes”）
- Anti-Patterns 是否有用？有的是真实的反模式（“premature optimization without profiling evidence”），有的是泛泛而谈（“ignoring best practices”）
问题不是五个角色不好——是没有标准来定义”好”。
治理缺失的五个症状
角色 PR 只是切入点。更深层的问题是：当外部贡献开始进来，没有治理层会导致什么？
症状一：命名空间冲突
五个角色碰巧没有重名。但如果 #29 也提交了一个 performance.md，只是关注的性能维度不同——一个关注算法复杂度，一个关注前端渲染性能——谁的 performance 赢？
角色文件名就是命名空间。没有命名注册机制意味着：先到先得，或者维护者拍板。前者不公平，后者不可扩展。维护者拍板意味着每一次命名冲突都变成一个人工仲裁任务——深入理解两个角色的差异、判断哪个更适合占用这个名字、然后向被拒绝的贡献者解释原因。一个维护者处理一次还行，但当角色数量从个位数增长到两位数时，这种逐案裁决会迅速成为瓶颈，而且裁决结果不透明，后来者无法预测自己的名字会不会冲突。
症状二：质量参差
EP03 说角色文件”改坏了不怕”——最坏的情况是多一个噪声视角。这是对的，但”噪声视角”累积到一定数量就不是无害的了。
如果 roles/ 目录有 50 个角色文件，其中 30 个写得精准、20 个写得空泛，审查流程会发生什么？OPC 的角色选择算法（tag 匹配 + 相关性判断）会把空泛的角色也拉进审查。空泛角色产生空泛建议。审查者的信噪比下降。维护者和用户都需要花时间分辨哪些建议有价值。
更严重的后果是信任侵蚀。当用户连续几次收到空泛的审查建议——“建议遵循最佳实践”、“注意代码质量”——他们会开始怀疑整个角色审查系统的价值，包括那些写得精准的角色给出的高质量建议。这就是劣币驱逐良币：噪声不只是浪费时间，它在主动损害信号的可信度。用户一旦养成”跳过角色建议”的习惯，系统等于失效。
一个角色的噪声成本接近零。N 个角色的累积噪声成本是 O(N)。但真正的代价不在 N 本身，在于 N 达到某个阈值后，用户对整个系统的信任归零。
症状三：过时不清退
技术领域变化快。一个 2024 年写的”React Class Component 专家”角色，到 2026 年可能已经过时——React 生态已经完全转向函数组件和 hooks。但没有机制标记角色为”过时”或”废弃”。它会一直待在 roles/ 目录里，偶尔被选中，给出过时的建议。
更深层的问题是信息不对称：用户无法区分一个角色是”经过当前技术栈验证的”还是”两年前有人写了之后再没人碰过的”。所有角色在 roles/ 目录里看起来一模一样——都是 markdown 文件，都遵循四段式格式，没有任何视觉信号区分新旧。过时角色的存在不只影响自身的可靠性——它让用户对整个目录里所有角色的时效性产生怀疑。
症状四：重叠检测缺失
#27 Data Engineer 和 #28 SRE 的职责有重叠——数据管道的可靠性同时属于数据工程和站点可靠性工程。如果两个角色同时被选中审查同一段代码，它们可能给出相互矛盾的建议——Data Engineer 说”加一层数据验证”，SRE 说”减少处理步骤以降低延迟”。
目前没有机制检测角色之间的重叠和潜在冲突。而矛盾建议的存在会进一步加剧前面说的信任问题——用户看到两个角色给出相反的建议，自然会质疑：这些角色之间有没有人做过协调？
症状五：贡献者预期管理
#24-28 被提交后，贡献者的合理预期是：如果 PR 被合并，他们的角色就正式成为 OPC 的一部分。但”被合并”和”被维护”是两件事。如果两个月后发现 SRE 角色的 Anti-Patterns 需要更新，谁来更新？原始贡献者已经不在了。维护者（我）对 SRE 领域的理解不如贡献者。
这是开源项目的经典困境：合并一个 PR 是一次性的决策，维护一个功能是持续的承诺。贡献者的时间窗口是有限的——他们可能因为换了工作、转了技术栈、或者单纯失去兴趣而消失。角色文件和代码贡献不同：代码有测试保护，改坏了 CI 会告诉你；角色的”正确性”依赖领域知识，领域知识在人脑里，人走了知识就走了。
从”接受”到”治理”
这五个症状指向同一个结论：接受贡献和治理贡献是两种完全不同的能力。
接受贡献需要的是：一个清晰的接口（四段式格式）+ 一个开放的态度（CONTRIBUTING.md 说”欢迎”）+ 一个合并按钮。这三样东西任何 GitHub 仓库都有——创建仓库的第一天就具备了接受贡献的能力。这就是为什么”接受贡献”看起来那么容易：它的门槛是工具层面的，不是能力层面的。
治理贡献需要的是一整套机制：
机制一：质量标准文档
角色文件需要一份可检验的质量清单，不是”写得好就行”的主观判断：
## Role Quality Checklist
### Identity (必须)
- [ ] 以 "You are a..." 开头
- [ ] 明确角色的审查视角（不是笼统的"代码质量"）
- [ ] 不与已有角色的 Identity 重叠 >50%
### Expertise (必须)
- [ ] 3-7 个具体的专业领域（不是"最佳实践"这种万能词）
- [ ] 每个领域可以对应到具体的代码审查动作
### When to Include (必须)
- [ ] 触发条件是具体的（"code touching database queries"）
而非模糊的（"any backend changes"）
### Anti-Patterns (建议)
- [ ] 至少 2 个，每个有具体的识别信号这份清单让审查标准从”维护者脑子里的感觉”变成”可机械检查的规则”。新贡献者可以在提交 PR 前自查。审查者可以按清单逐项检查。
机制二：命名注册
一个简单的 roles/REGISTRY.md 文件：
| 名称 | 维护者 | 状态 | 添加日期 |
|------|--------|------|---------|
| frontend | @maintainer | active | 2025-01-15 |
| performance | @contributor-24 | active | 2026-05-15 |
| ...新角色提交前查注册表。同名 = 要么合并要么改名。注册表还记录维护者——谁负责这个角色的持续更新。
机制三：生命周期管理
每个角色有状态标签：
active：正常使用deprecated：标记为过时，给出替代方案，6 个月后删除experimental：新提交，在试用期，不参与正式审查流程
状态转移有规则：active 超过 12 个月没有更新 → 自动标记为 review-needed。维护者决定是更新还是 deprecate。
机制四：冲突检测
一个自动化脚本扫描所有角色的 Expertise 列表，用语义相似度检测重叠。重叠超过阈值 → 在 PR 审查时自动标记 warning。不自动拒绝——重叠不一定是坏事（不同角度看同一领域），但需要人工确认。
治理的成本
直说：以上四个机制，对一个 163 个星标（stars）的项目来说，可能是过度设计。
五个角色 PR。不是五十个，不是五百个。花一整套治理机制来管理五个 markdown 文件，投入产出比很低。
但治理的需求不是看当前的数量——是看增长的趋势和失控的代价。如果角色 PR 保持类似的提交频率，半年后可能积累到 15-20 个角色。如果到那时候才开始建治理，已有的角色要追溯审查，已合并的低质量角色要 deprecate，贡献者会觉得规则突然变了。
追溯治理的心理成本远高于前置治理。前置治理是给新贡献者一份清单——他们还没投入时间，接受规则的心理成本接近零。追溯治理是告诉已经贡献过的人”你的角色不达标，需要修改或废弃”——他们已经投入了时间和认同感，会觉得被反悔。这不是假设——几乎每一个从”随便提交”转向”有标准”的开源项目都经历过这种转折期的摩擦。
治理的最佳时机是在问题出现之前——但不是在贡献出现之前。 零个贡献就建治理是浪费。五个贡献还没建治理是刚好该开始的时候。
开源治理的最小可行集
考虑到项目的规模（1 个维护者，5 个外部角色贡献），一个务实的最小可行治理方案：
现在就做：
- 质量清单加入 CONTRIBUTING.md（10 分钟的工作，收益最高）
- 命名注册表
roles/REGISTRY.md（30 分钟的工作）
等到 10 个角色时做：
- 生命周期标签（需要改 harness 的角色加载逻辑）
- 自动化冲突检测（需要语义相似度工具）
等到有 3+ 外部维护者时做：
- 角色维护者指派机制
- 角色废弃投票流程
这是渐进式治理——不是一次性设计一个完美系统，而是随着贡献量增长逐步添加规则。 就像 S2 的核心 thesis 说的：产品暴露工具的短板，短板驱动工具的进化。同样地：贡献暴露治理的缺失，缺失驱动治理的建设。
没有治理的开源不是生态，是堆积
这一集的核心论点：
接受贡献 ≠ 有能力治理贡献。
一个 GitHub 仓库开了 PR 权限，就能接受贡献。但接受不等于消化。五个角色 PR 被合并了——但谁负责它们的质量？谁负责它们的更新？谁在两个角色冲突时做仲裁？
没有这些答案，roles/ 目录就不是一个生态——是一个堆积场。新角色进来，旧角色不出去。好角色和差角色混在一起。没有人知道哪个角色是经过验证的、哪个只是”有人提交了我就合并了”。
从信任的角度：贡献层（第三层）到承受层（第五层）之间，差的就是这个治理层。 没有治理，贡献越多，系统越脆弱——因为每一个未经审视的贡献都是一个潜在的质量债务。而质量债务和技术债务一样，利息是复利的：越晚偿还，清理成本越高。五个未审视的角色还能逐个修复，代价可控；但如果放任增长到五十个，清理工作量会让所有人望而却步，roles/ 目录就真的变成了”历史遗留”——所有人都知道有问题，但没有人愿意动它。
下一集回看全季：从基建到核心，信任转移的五层账本。
硅基团队 S3: 从”我能用”到”别人也能用” ← S3E06: 第一次真正验证 FAIL 路径 | S3E08: 信任转移的五层账本 →