一句话定义
CODEOWNERS 是放在代码仓库里的一个普通文本文件，用「路径 + 负责人」的配对写明哪部分代码由谁把关。它本身不拦人，一旦和分支保护规则（branch protection）绑在一起，就变成一条硬性约束：没有负责人点头，这次改动就无法合入。
怎么写
一行一条规则，左边是路径通配符，右边是负责人，可以是个人账号、团队或邮箱：
```
/src/payments/ @acme/payments-team
*.sql @acme/dba
/docs/ @acme/docs-team
```
多数平台按「最后一条匹配的规则生效」处理，所以把兜底的 * 写在最上面、把具体路径写在下面，是常见写法。文件放在哪个目录、语法细节各平台略有差别，以官方文档为准。
打个比方
仓库像一栋写字楼，CODEOWNERS 是贴在每层电梯口的「钥匙保管人名单」：这层换锁必须保管人到场。名单贴在那儿本身不挡人，真正上锁的是分支保护规则。规则说「只要有 code owner 没批准，就不许合」，名单说「这层归谁」。
和相邻概念的区别
| 概念 | 回答的问题 |
|---|---|
| 仓库权限（write / maintain / admin） | 你能不能推代码、能不能点合并按钮 |
| 分支保护规则 | 满足什么条件才放行（几人批准、CI 是否通过） |
| CODEOWNERS | 具体到这批被改的文件，谁的意见必须被征得 |
| 代码评审（code review） | 人与人之间沟通技术和设计的过程 |
一句话：权限管「能不能动手」，保护规则管「什么时候放行」，CODEOWNERS 管「谁的意见不能跳过」。
智能体时代，这条规则为什么变重要
过去写 CODEOWNERS，主要是让对的人收到通知、防止改数据库迁移的人顺手改了支付逻辑。现在提 PR 的可能是自动化智能体：它能读代码、改代码、跑测试、开 PR，甚至在你授权后能点合并。于是这份名单从「礼貌的提醒」变成了「权限边界」：
- 智能体一般用机器人账号，通常不在负责人名单里，所以它的角色是「准备好改动」，不是「批准改动」。
- 平台一般也不允许 PR 作者批准自己的 PR；就算把机器人列进名单，仍需要另一个人批准。
- 所以想让智能体真正「自己合进去」，得同时满足好几件事：它在名单里、分支保护放行、平台允许自批。多数团队反过来用：故意把智能体排除在名单外，让它必须停在人工审批这一步。
实践建议
把 CODEOWNERS 当作「AI 能碰哪里」的白名单：支付、鉴权、密钥、数据库迁移、基础设施配置这些路径明确挂到人类团队；给智能体分支留小口子，限制可改路径；再加一条「智能体提交的 PR 必须人工批准」。注意文件本身不强制执行任何事，要配合分支保护一起检查才生效。