发布与验证
让 AI 给 PR 加并发组：只等最新一轮检查
用并发组清理过期的 PR 检查，部署另设组。
资料核验2026.11.12 · GitHub Actions · PR 与部署工作流
提交刚推上去，你又修了一个拼写错误。两份 CI 都排队，后一份才是你准备合并的内容。GitHub Actions 的 concurrency 可以让同组运行互斥，启用取消进行中任务后，还能终止前一次运行。
让助手从这一步开始
把现有工作流名、触发事件和发布环境提供给助手，要求只给普通 PR 检查加并发分组。用工作流名与 PR 身份区分组，部署任务另设组，检查是否支持中断。
把组的边界写成你想取消的范围
PR 检查用工作流名加 PR 编号做组键，避免不同 PR 或不同工作流互相取消。用一个临时 PR 连推两次，确认旧检查结束、新检查能报告结果。
部署用另一套分组。中途取消发布可能留下半完成的迁移或上传，让部署按目标环境互斥，并先看实际步骤能否安全中断。
也别把并发组当成保证每个提交都执行的队列。检查最终状态应以准备合并的提交为准。
把问题变成可重跑的样例
把测试 PR A 连推两次，同时让 PR B 也跑一个检查。证据表至少有 PR、提交、运行编号和最终状态。只有 A 的旧运行应被取消。若 B 也被取消，检查分组是否只用了公共分支名。
核对这几项输出
- 同一 PR 连推两次时旧检查取消。
- 另一份 PR 的任务仍在跑。
- 最新提交返回稳定的必需检查结果。
怎么判断改动能不能收
并发组属于实际调度行为，用真实测试 PR 验证比只看 YAML 更准。部署可能包含迁移或上传，不能把普通检查的取消策略直接复制过去。
可以让助手把运行编号、PR 编号、提交 SHA 放进同一份验收记录。两个运行虽然同组，触发和调度顺序仍要以实际结果为准。流程中若有不可中断的上传或部署动作，把它划进自己的工作流或并发组，再独立验证。
