给团队写一个“创建项目仓库”的机器人，权限申请却出现删除、转移仓库的能力，这不是合理的默认成本。先把业务动作拆小，再选择能完成它的最窄权限；最后同时验证“该做的能做”和“不该做的做不了”。GitHub这次更新，恰好把创建仓库从更宽的管理权限中拆了出来。

这篇文章讨论怎样审查这种自动化：从需求到权限，怎样找多申请的能力，怎样验证迁移没有偷偷扩权。示例只在本地检查虚构的操作集合，不申请真实授权，也不创建或删除任何仓库。Read in English。

这次更新解决哪一处过度授权

GitHub于2026年10月13日发布GitHub App最小权限与管理更新。其中，repository_creation:write允许创建仓库，无须为此申请更宽的仓库管理写权限；后者还涉及删除、转移等管理能力。App使用创建权限仍需组织管理员安装。

值得关注的是授权边界变细了，而不是自动化从此无需审查。假设一个团队的项目门户只负责建仓库、返回链接，删除项目由另一条人工流程处理，那么让建仓库服务同时持有删除能力，就把本来分开的责任绑在了一起。独立的创建权限，使“只允许创建”有了更直接的表达方式。

判断这项变化是否与你有关，可以先看权限的来源：当前程序是不是只为了创建而申请管理权限？如果它还确实要维护其他管理设置，就不能只换一个权限名称。应先列出它实际调用的动作，再判断哪些可以拆分。

把“能做什么”与“能碰什么”分开

评审权限时，至少写出三个问题：机器人必须执行哪些动作；这些动作针对哪些资源；动作以什么身份发生。只写“GitHub App，有写权限”缺少了后两个维度。一个动作很窄的服务，若资源范围覆盖大量无关仓库，仍然可能超出它的职责。

GitHub的权限文档要求按功能选择最低必要权限，并说明用户访问令牌同时受到用户与App权限约束，安装访问令牌则依据App权限。因而，测试时不能把个人账号手动调用成功，直接当成生产App身份已经验证。

可以把这些维度当作评审用的交叉条件：动作符合职责、资源在授权范围、实际身份被允许、组织策略也通过，才进入执行。这里没有给出GitHub全部鉴权规则，只是防止评审记录漏掉一个维度。遇到具体接口，以该接口文档与受控测试为准。

从接口清单倒推权限，而不是反过来

先给业务写出可验收的结果。例如：输入经过校验的项目标识，创建一个指定可见性的仓库，成功后返回仓库链接；失败时留下可追踪的错误。不要把“有管理权限”当作验收条件，因为它只是手段，还可能过宽。

接着列出调用清单。创建组织仓库接口文档列出了可接受的细粒度权限方案，包括仓库创建写权限。接口支持一种权限方案，并不意味着你应把所有可接受方案一起申请；选择能够满足当前动作的那一种，再把其他动作单独核对。

如果创建之后还要写入模板内容、设置团队访问或添加到其他安装，分别建立一行需求。不能推导出“能创建，所以自动能做一切后续工作”；也不能因为某个后续步骤失败，就给整条流水线补上最高权限。失败属于哪一步，权限应该在哪一处调整，都应可解释。

本地先找出“缺了什么、多了什么”

下面的Python示例不是GitHub鉴权模拟器。它用三个自定义动作演示一种评审思路：需求集合减去已授予集合是缺项，已授予集合减去允许集合是超项。真实权限到实际操作的映射，必须来自具体接口的文档和验证，不能照抄这三个动作名。

CREATE = "create_repository"
DELETE = "delete_repository"
TRANSFER = "transfer_repository"
KNOWN = {CREATE, DELETE, TRANSFER}

# Illustrative operation sets, not GitHub API permission names.
NARROW = {CREATE}
BROAD = {CREATE, DELETE, TRANSFER}

def audit(required, granted, allowed):
    required, granted, allowed = map(set, (required, granted, allowed))
    if (required | granted | allowed) - KNOWN:
        raise ValueError("unknown operation")
    return {
        "missing": sorted(required - granted),
        "excess": sorted(granted - allowed),
    }

required = allowed = {CREATE}
assert audit(required, NARROW, allowed) == {
    "missing": [], "excess": []}
assert audit(required, BROAD, allowed) == {
    "missing": [], "excess": [DELETE, TRANSFER]}
assert audit(required, set(), allowed) == {
    "missing": [CREATE], "excess": []}
assert audit(set(), set(), set()) == {
    "missing": [], "excess": []}
try:
    audit({"unknown_action"}, NARROW, allowed)
except ValueError:
    pass
else:
    raise AssertionError("unknown operations must be reviewed")
print("narrow: complete; broad: two excess operations; empty: missing create")

运行结果会指出：窄集合完整覆盖创建；宽集合多出删除和转移；空集合缺少创建。三个断言分别检查可用性、过度授权和权限不足，另外覆盖空需求与未知动作。只检查“创建成功”会让第二种方案也通过，这正是加入超项检查的意义。

集合检查的边界同样清楚：它无法识别组织策略、令牌类型、资源选择与服务端的隐含条件。未知动作直接报错，是要求维护者补齐映射，不是证明系统安全。可以把它放进配置审查或持续集成，但不能用一串绿色断言替代实际身份下的验收。

验收时，要同时保留正例和反例

正例回答业务能不能继续工作：在专门的测试组织与测试资源中，用迁移后的真实运行身份完成创建；确认名称、可见性和返回资源都符合预期。这里描述的是建议的验收方式，本文没有连接真实GitHub账户运行这些操作。

反例则回答多余能力是否还在。先检查配置和文档中的能力边界；需要行为验证时，只使用经授权、可丢弃的测试资源。涉及删除或转移的测试不能指向真实业务仓库，更不能把“试一下能不能删”当作生产审计方法。权限审查的目标是减少风险，不是为了证明一个假设去制造损失。

反例的失败原因也要分清。若测试用的是另一个身份，或资源根本不在它的范围内，那么拒绝并不能单独证明某项动作权限已经收窄。验收记录至少保留身份类型、测试资源类别、预期结果、实际结果和所依据的接口版本；不要记录令牌正文。

迁移失败时，先定位边界

切换后出现403，很容易走向“先把旧权限加回来”。更好的顺序是先确认请求是不是预期接口，再核对运行身份、安装范围和已批准的权限状态。权限文档还指出，安装所有者未批准新权限时，安装仍使用旧权限；修改注册配置不等于每个安装都已经完成迁移。

排查记录最好围绕一条失败请求展开：哪个业务动作失败，对应哪个接口，使用什么身份，属于哪个安装与资源范围。只保留必要的响应状态和脱敏诊断信息，不把认证头写进日志。信息足够定位边界时，再调整那一项，避免一次失败带回一整包宽权限。

仓库创建也涉及写操作重试。请求超时未必代表仓库没有创建；盲目重试可能把权限问题与重复操作问题混在一起。可结合本站的幂等重试说明设计结果核对，但幂等性不能替代授权检查，两者应分别验证。

创建权限很窄，业务护栏仍要自己写

只允许创建，不等于只能创建正确的仓库。假设门户接收项目名后直接提交请求，权限系统并不会替产品判断：这个项目是否真的获批、是否重复、是否应公开、是否达到团队的数量限制。这些约束属于业务流程，应在调用前显式校验。

一个实用的做法是把输入约束与权限审查分开记录。项目标识使用确定的命名规则；可见性来自经过批准的项目配置，而不是未经确认的自由输入；同一项目重复提交时先核对既有结果。再为单次批量创建设置可审查的上限与停止条件。这里没有推荐一个通用数量，合适阈值取决于团队真实工作量。

这些护栏各有作用：权限收窄限制动作类别，输入校验减少错误目标，数量边界控制一次失败的扩散，结果核对防止重试制造混乱。它们不能互相替代。看到机器人“没有删除权限”就结束审查，会漏掉以合法动作反复做错事的情况。

一份可以交付给维护者的迁移结果

交付给下一位维护者的记录，应能追到具体业务：必需动作、对应接口、最小权限依据、安装范围、运行身份、验收结果，以及哪些旧能力已经不再需要。若仍有动作必须使用管理权限，就写出具体原因，不能用“以后可能用到”搪塞。

上线时先选择有限的测试范围，确认新流程满足需求，再逐步扩大适用范围。旧配置的退场也应有明确条件：正例通过，授权状态确认，失败路径可定位，不再依赖那项多余能力。回退可以恢复经批准的旧流程，但不该悄悄添加一份无人认领的长期权限。

这条新闻真正提供的工程机会，是把自动化的职责收窄到可以解释、可以验收。创建服务只负责创建，后续工作按实际需要授权，维护者才更容易回答：这个机器人为什么拥有这项能力，又为什么碰得到这个资源。

来源与补发说明

GitHub官方更新，2026年10月13日；GitHub App权限选择文档；创建组织仓库API。本文的操作集合、审查流程和测试建议为原创工程分析，不是官方完整权限模型。

本文于2026年10月14日晚补发，文章日期保留原计划11:30。Google News聚合条目发布时间为北京时间10月14日07:17:55，早于该时段；没有将后来的新闻回填成当时已经公开的内容。