[ SECTION_01 ] 结论先行：芯片发布不是生产验收
Apple 于 2026 年 9 月 22 日宣布新款 Mac mini 开始供货；这能确认产品已发布，不能证明某个团队的 Xcode CI 工作负载已通过验收。Apple 新闻稿：新款 Mac mini 已开始供货
结论：M6 Mac mini 可以承担 Xcode CI，但必须先核对 Xcode 与 macOS 支持条件，再用真实项目验收后台执行、测试隔离、安全和重启恢复。性能与容量结论只看同一工作负载下的实测，不能从芯片型号或发布会描述直接推出。
个人开发者：准备把新款 Mac mini 用作持续运行的 Apple 平台构建节点，需要确认它能否稳定完成自己的项目任务。
DevOps 工程师：负责接入自托管 Mac Runner，并验证无人值守执行、任务隔离和故障恢复。
研发平台负责人：需要决定新节点能否进入共享 CI 池，以及是否要用远程 Mac 补充临时测试或扩容。
最后更新于 2026 年 9 月 24 日；产品供货信息与 Xcode 支持范围核实自 Apple Newsroom 和 Apple Developer，Runner 行为核实自 GitHub 官方文档。
[ SECTION_02 ] CI 管理者：先确认系统与工具链兼容
M6 Mac mini 的 Xcode CI 节点准入条件
可以，但“能安装并启动 Runner”不等于“适合生产”。Apple 的产品公告只确认新款 Mac mini 已开始供货；实际准入还要看目标 macOS、Xcode、项目依赖和流水线所需测试目标能否同时满足。
截至本文核实日期，Apple 的 Xcode 系统要求页面列出 Xcode 27 需要 macOS Tahoe 26.6 或更高版本。发布前仍应重新检查该页面，因为系统要求会随 Xcode 更新而变化；如果团队项目依赖的 Xcode 与节点可安装的 macOS 不匹配，应先暂停接入，而不是用空项目构建成功来绕过兼容问题。Apple Developer：Xcode 系统要求
上线前，CI 管理者应逐项记录：
- 目标 macOS 与 Xcode 的准确版本，以及版本来源。
- 项目使用的 SDK、编译器、依赖管理工具和第三方脚本。
- 必需的构建目标、部署目标、签名方式与产物格式。
- 系统升级或 Xcode 更新后，谁负责重新验收及回退。
把这些信息固化成节点准入记录。版本不匹配、支持范围未确认或依赖只能在交互桌面中手动修复时，评分为 ❌ 暂缓上线；全部有证据且变更责任明确，才进入任务验收。
[ SECTION_03 ] 构建工程师：用真实项目跑完整流水线
自托管 Mac Runner 接入前的验收内容
不要只看 Runner 页面是否显示在线。选择团队实际维护的项目，从干净检出开始，依次运行依赖解析、构建、测试和产物归档。每一步都保留任务日志、退出状态、提交标识及产物位置；只成功启动 Runner 或编译空工程，最多说明通信和基础工具可用。
Apple 将 xcodebuild、simctl 等列为随 Xcode 提供的命令行工具，并说明需安装 Xcode、将其设为活动开发者目录后才能调用。Apple Developer：Xcode 命令行工具参考 因此要在 Runner 的实际执行身份下核对开发者目录，而不是只在管理员登录的终端中确认：
whoami
xcode-select -p
xcodebuild -version
xcodebuild -list -workspace YourApp.xcworkspace
将占位工程名替换为团队项目实际名称。随后在 CI 工作流中执行与团队任务一致的构建、测试和归档命令，并确认环境变量、证书访问方式、缓存目录及归档路径都符合流水线预期。Apple 说明 xcodebuild 可驱动命令行测试，测试失败会返回非零状态；因此还要确认流水线确实会把失败状态传递给调度系统，而不是只保存一段看似成功的日志。Apple Developer：使用 Xcode 自动化测试
⚠️ 构建通过只证明特定提交、特定配置和特定目标完成了构建。它不自动证明 Simulator、发布签名、桌面会话或重启后的任务都可用。
[ SECTION_04 ] 测试负责人：区分构建与 Simulator 任务
构建节点和 Simulator 测试节点需要分开吗？
不一定。先按任务实际依赖决定，而不是按硬件型号划分：不需要图形会话的命令行构建可以单独验收；依赖 Simulator、UI 自动化、图形桌面或特定测试运行环境的任务，则必须在计划生产使用的拓扑里执行并留存结果。
| 验收对象 | 通过证据 | 评分与处置 |
|---|---|---|
| 命令行构建 | 真实项目检出、构建、测试及归档日志完整，失败状态能传回 CI | ✅ 通过：可声明已验证的构建任务 |
| Simulator 测试 | 指定测试目标在目标环境启动、运行并生成可检查的测试结果 | ✅ 通过：仅声明已测目标；未验证则 ⚠️ 限用 |
| 桌面或 UI 任务 | 实际工作流所需的图形会话、权限与任务结果均有记录 | ✅ 通过：明确适用边界；无法复现则 ❌ 不纳入能力声明 |
这是一份证据评分表，不是性能跑分。 同一台机器可能通过命令行构建验收，却未通过 Simulator 或桌面任务验收。不要将“构建节点通过”扩大成“所有 iOS 测试都通过”。
测试负责人应先挑选流水线中真实使用的测试目标，再执行并保存目标设备或 Simulator 标识、测试日志、失败记录和产物。若某类任务尚未验证，在调度标签、节点说明和团队文档中明确排除；确认任务负载不同后，再决定是否拆分构建与图形测试。
[ SECTION_05 ] 安全管理员：把代码、凭据和目录权限分开审查
自托管 Runner 不是天然隔离的沙箱。它可能访问代码仓库、网络服务、用户目录、缓存和签名材料；如果多个团队或信任级别不同的工作流共用同一环境，一个不可信任务就可能留下影响后续任务的状态。
GitHub 明确提醒，自托管 Runner 不保证运行在干净的一次性虚拟环境中，不可信工作流代码可能持续影响 Runner；公开仓库的拉取请求尤其需要谨慎处理。GitHub 文档：自托管 Runner 安全使用 因此，安全验收不应只检查证书是否能被 CI 读取，还要逐项回答：
- 哪些仓库、分支和工作流可以把任务调度到该节点？
- Runner 能访问哪些内部网络、服务和共享目录？
- 构建密钥、令牌与签名材料是否仅对必要任务开放？
- 任务完成后，工作区、缓存、临时文件和凭据由谁清理？
- 发布签名是否有单独授权、审批记录及可追溯日志？
GitHub 的自托管 Runner 文档也说明，Runner 组和仓库访问限制可用于收窄调度范围；对于敏感发布操作，应单独验收授权链路，不能把“交互账户能看到证书”当成 CI 任务隔离。GitHub 文档：自托管 Runner 参考
🔒 如果同一节点要执行不同信任级别的代码，先确定隔离和清理责任，再开放任务调度。没有明确边界时，评分应为 ⚠️ 限用，而不是默认共享。
[ SECTION_06 ] 平台维护者：把断线、重启和恢复纳入验收
在线状态是瞬时信号，不是可恢复性证明。平台维护者需要在计划好的维护窗口内，实际重启主机，然后观察 Runner 是否重新注册、是否能领取任务，以及真实构建是否完成。保留重启前后的服务状态、Runner 日志、调度记录、失败原因和人工介入点。
GitHub 文档说明，任务找不到匹配的在线 Runner 时会保持排队；超过 24 小时仍未执行，任务会失败。持久 Runner 关闭期间的调度也存在边界，因此单纯看到节点重新上线，不足以证明整个恢复链路可靠。GitHub 文档：自托管 Runner 参考
可照着执行这套恢复验证：
- 选定维护窗口，暂停可能受影响的生产任务，并记录当前 Runner 状态。
- 在节点完成计划内重启后，检查系统服务或启动项是否恢复。
- 确认 Runner 重新注册、标签与组别正确，且没有残留旧任务状态。
- 提交团队的真实构建任务，检查领取、执行、测试与归档全过程。
- 模拟任务未领取或失败的情况，记录告警、人工处置和重新运行路径。
- 将证据、回退条件、值班责任人与允许的维护边界写入节点记录。
GitHub 还要求停用自动更新的 Runner 仍要及时维护；官方文档指出，禁用自动更新时，Runner 版本需要在新版本发布后 30 天内更新，否则服务可能不再向其排队任务。GitHub 文档：自托管 Runner 更新要求 把 Runner 软件更新纳入维护责任表，不要只关注 macOS 补丁。
[ SECTION_07 ] 技术负责人：按证据决定上线、限用或补充节点
最终评审应汇总各角色留下的证据，而不是给整台机器打一个脱离任务的“性能分”。可按以下规则签字：
- ✅ 上线：目标工具链兼容；真实项目构建、声明范围内的测试、权限审查和重启恢复均已验证。
- ⚠️ 限用：核心构建通过，但某些 Simulator、桌面任务或恢复场景尚未验证。只开放已通过的工作流，并写明限制。
- ❌ 暂缓：系统支持未确认、真实任务失败、敏感凭据边界不清，或重启后无法可靠恢复。修复并重新验收后再准入。
Apple 新闻稿中的性能描述不能替代团队实测。对 M6 Mac mini 的构建时间、并发容量或队列表现，必须固定项目提交、依赖缓存状态、构建目标和测试范围，再与现有节点对照；没有记录就不对外宣称性能提升。若现有节点无法覆盖临时并发、备用执行环境或跨地域访问，可以把远程 Mac 作为补充路线评估，但要先核实具体交付方式、工具链支持和任务恢复边界，不能把“云端可用”当作已验证。
如果决策仍在“长期持有实体 Mac”与“按需补充远程环境”之间，可参考Mac mini 长期使用与购买边界；若考虑临时构建、备用节点或远程访问，再查看 NOVAKVM 可访问的 Mac 环境选项，并逐项确认可用环境与交付条件。实体 Mac 更适合需要固定本地设备、持续稳定重负载或物理接口的团队；远程方案则适合先补足短期测试和临时并发，但若服务配置、恢复能力或兼容性无法核实，就不应替代已验收的生产节点。比起直接把未验证的新机器放进共享 CI 池，先按这份清单确认边界，再决定是否租用 NOVAKVM 的 Mac 作为补充测试或备用执行环境，会更容易控制上线风险。