团队治理与准入
第四道闸是准入：先问你在防什么 —— 防没人看得懂、防没人认领、还是防安全事故，对应的规矩不同。vibe coding 上瘾的解法不是禁用，是披露政策（哪些代码是 AI 写的、谁负责）、可维护性门槛与验证税的显式分配。
也叫：团队治理 · 准入 · 披露政策 · 可维护性 · 管理向
闸四：准入——先问你在防什么出自 T7-2
立规矩之前必须先回答一个问题：你防的是许可风险，还是质量风险？ 防的东西不同，规矩完全不同。2026 年几个开源组织的政策正好构成两极：
| 组织 | 在防什么 | 规矩 |
|---|---|---|
| GCC 指导委员会（2026-07 新政） | 许可链 | 拒收含 LLM 生成内容的「有法律意义的」贡献，沿用约 15 行的老阈值；唯独给测试用例开口子 |
| Fedora（2025-10） | 质量与追责 | 提交打 Assisted-by: 标记；贡献者永远是作者且负全责，必须自己 review、测试、理解；禁止提交未验证的产物；AI 不得单独决定一个 PR 是否被接受 |
| Apache | 许可 + 可追溯 | 提交信息打 Generated-by: [工具名] |
| Linux 基金会 | 许可 | 工具条款不得与开源定义冲突；不强制披露 AI 生成 |
企业侧的硬约束也已经落到平台上，最典型的两条：某代码托管平台的 coding agent 开的 PR，触发者本人的批准不计入必需审批数；agent 推送之后 CI 默认不自动运行，必须人工点一下「批准并运行」——理由是流水线能读到密钥。这两条设计的共同逻辑是：不让发起动作的人同时成为放行的人。
以上节选自T7-2 AI 协作的工程纪律——规格、验证、回滚、治理这四道闸，读全文能看到前后语境。