发布与验证
审 AI 生成的 CI：依赖缓存和发布包各走哪条路
安装加速和跨任务传包是两件事。
资料核验2026.11.12 · GitHub Actions · PR 与部署工作流
构建任务生成了发布包，助手建议用缓存把它传给发布任务。缓存以匹配键查找，可能缺失，也可能按恢复规则找到别的键。对你要发出去的那一份包，这种不确定性很难接受。
交给编码助手的任务
给助手两项独立目标：缓存依赖下载目录，以及让发布任务收到本次运行的压缩包。要求画清缓存键、产物名称和缺失时各自的行为，再改工作流。
先问下游需要的是哪一份
依赖下载目录用缓存。缓存键至少纳入锁文件和会影响产物的环境信息，恢复失败就按锁文件重新安装。需要发布或复查的压缩包用工作流产物，并让下游下载本次运行上传的明确名字。
把缓存清掉再跑一次，构建仍应成功。对发布包则反过来测试，删除本次产物后下游应明确失败，不能悄悄拾取上次的文件。
把两条规则写进工作流说明，新同事看到目录名就能知道缺失是否可以容忍。
先准备一个对照样例
让助手写一张清单，区分 依赖下载目录 → 缓存 与 app.tar.gz → 本次工作流产物。清空缓存跑构建，再故意不上传压缩包跑下游。前者应正常重建，后者应停止并指出缺哪个产物。
用这些结果验收
- 清空缓存依然可以按锁文件安装。
- 改变锁文件后能观察到缓存键变化。
- 缺少本次产物时发布任务失败，不拿前一次产物替代。
审查时容易漏掉什么
如果方案通过缓存传发布包，追问匹配键和恢复键会取到哪份文件。下游应能把上传包对应到这次运行及提交，缓存则应随时可以重建。
同时核对缓存键是否纳入平台和锁文件。缓存命中可节省安装工作，运行时仍应检查输入与锁文件一致。发布任务应能说明取到哪个运行的产物，至少在报告中记录提交 SHA，方便事后追溯交付内容。
