发布与验证
让 AI 审 GitHub Actions 权限：检查和发包分开
检查代码的工作流与发布工作流分开授权。
资料核验2026.11.12 · GitHub Actions · PR 与部署工作流
测试只需要读取仓库，发布任务却可能需要写包。把两个任务都放在同一套写权限里，久了没人知道哪些动作真的有理由写入。GitHub Actions 支持在工作流或任务层设置 permissions。
给 AI 的上下文与边界
给助手一份现有工作流，让它按任务列出读取仓库、上传产物、发布包分别需要的权限。先核对工作流级与任务级配置，再提交最小改动并说明触发事件。
给每个任务列出所需的动作
普通检查先从读取内容开始。发布任务按实际资源补权限，并把额外能力放在对应 job 上。若显式指定部分权限，其余未指定项会变成 none，改完要检查原本依赖的读取动作是否仍能执行。
把权限变化当成工作流行为来验收。在临时分支跑普通 PR 检查，再看发布任务的触发条件和身份来源。
未来增加第三方步骤时，也用同一个问题审查：这个任务需要读取什么，能写到哪里？
可以直接照着做的演练
列两条任务记录，普通 PR 的职责是检出、构建与测试，发布的职责是写包。让助手为每个权限对应一个动作。修改后分别核对普通 PR 结果和发布任务触发条件，避免把更高权限当成读取失败的修复。
检查生成结果
- 普通 PR 仍能检出和跑测试。
- 发布任务只在约定条件触发。
- 显式权限设置后没有遗漏某个必要的读取权限。
复查时追问一层
新增第三方步骤时先确认其运行权限和来源。检查结果可以从低权限任务流向发布任务，但后者应核对本次产物的来源和身份。这里的目标是把发布权限限制在真正负责发布的任务内。
检查提交来源不同的运行是否拥有预期权限。测试阶段只核对读权限和必需操作，不用真实发布令牌做演练。更新第三方步骤版本时，让助手列出它可访问的数据和输出，权限给得太宽会扩大一次依赖变更的影响。
