四种团队，四条流水线

1. 提交代码

   在 Windows 上完成开发，将确定的提交推送到代码仓库。依赖锁文件随代码一起提交，避免远端解析出另一套依赖。

2. 生成归档

   东京节点拉取代码，安装项目所需依赖，执行 flutter build ipa。签名证书、描述文件及其访问权限由你配置。

3. 上传分发

   检查版本号与构建号后，用 fastlane pilot 上传 TestFlight；将 ipa、日志与对应提交标识保存到自己的产物存储。

前提：用于 TestFlight 分发的有效开发者资格、签名材料和 App Store Connect API Key 仍需自行准备。远端节点不能替代这些条件。

1. 登记 runner

   在新加坡节点安装 GitHub Actions self-hosted runner，用标签将 macOS 作业定向到该节点，并限制可触发任务的仓库与分支。

2. 区分优先级

   main 合并执行构建与基础检查；发布分支保留独立任务；nightly 执行耗时的模拟器 UI 测试。

3. 隔离工作目录

   按分支或任务分开工作目录与 DerivedData。记录峰值内存、磁盘增长和排队时间，再决定是否增加并发或增租节点。

区域选择先比较仓库拉取、依赖下载与产物上传路径，不只看团队所在地。跨区域协作也应先以自己的工程试跑。

1. 核对兼容性

   确认推理框架支持 Apple Silicon 与所需算子。根据模型权重、上下文长度和运行时开销估算内存，不只看模型文件大小。

2. 固定评测输入

   下载获授权使用的模型，记录版本、量化参数和提示集。让每次运行使用相同输入，区分首次加载与后续推理的耗时。

3. 保存实验记录

   导出吞吐、峰值内存与质量评测结果，并同步到自己的存储。验证模型可运行后，再判断是否按月保留这套环境。

这是计算工作流示例，不提供预设模型速度或效果保证。试跑时同时测内存、首轮加载和持续推理，避免只看单次结果。

1. 传输与抽样

   上传获授权处理的素材，先选短片段验证编码格式、色彩设置与导出参数。将上传时间算进整批任务的交付预算。

2. 安排导出队列

   用脚本或应用的批处理能力组织任务。逐步增加并行数，观察内存与磁盘读写，避免多个导出任务互相拖慢。

3. 回传并清理

   抽检音画同步、时长和文件完整性；回传成片及任务日志。确认备份后清理中间文件，为下一批任务释放空间。

先用自带 2TB SSD 核算源素材、缓存和导出文件的峰值占用；确实需要更多空间时，再加购 +2TB SSD，而不是默认叠加。