POC 评估窗和「短租到岗首绿」有什么本质差别？

到岗首绿关注四小时或一天内能否编译通过；POC 评估窗要验证在目标负载曲线与科目假设下，磁盘、出口、身份与区域策略能否稳定支撑至少一个完整迭代周期，并把扩容触发线写成可审批数字。

什么时候应该从日租升级到周租或月租？

当连续满载当量小时、队列深度或磁盘月环比超过预设阈值，且财务已接受把该机写入基线科目时，应升级固定租期；具体矩阵见正文对照表，并应与多地区节点与租期指南同页评审。

2026 年 Mac 云租赁从 POC 到扩容：评估窗验收 KPI、租期升级决策矩阵与六国落地 Runbook

技术负责人第一次推动 Mac 云租赁时，最容易把 POC 做成「演示能编译」，却没法回答财务：何时从日租切到月租、什么指标触发加第二台、磁盘与出口科目会不会在第二周爆掉。本文面向要在新加坡、日本、韩国、香港、美国东部、美国西部落地独占远程 Mac 的团队，给出评估窗与短租到岗的差异、六类 POC 失败信号、验收 KPI 与生产基线对照表、扩容触发线与租期升级矩阵、可复制 YAML 台账字段与六步 Runbook；并与站内《多地区节点与租期指南》、《专用租赁 vs 云 Mac 实例》、《小团队预算治理》互补——前序篇讲区域与交付形态，本篇只讲如何把两周评估窗写成可签字验收材料。

Mac 租赁 POC 最常见的六类「看似成功、实则不可规模化」信号

只验首绿、不验队列形态：POC 周里工程师手工串行跑 job，上线后并发一打开，xcodebuild 与 pod install 争用统一内存与磁盘 IO，P95 墙钟突然翻倍，却被误报为「代码变慢」。
把「能 SSH」当成「能无人值守」：评估窗内每次都有人盯着解锁钥匙串或点系统弹窗；生产夜跑时 LaunchAgent 与交互会话脱节，失败被清晨人工重试掩盖。
出口与制品链路未入账：POC 只拉小仓库；正式联调后跨区拉镜像与 DerivedData 同步把 egress 推到账单外科目，FinOps 与工程对同一台机得出相反结论。
区域叙事停留在 ping：未把 Git 托管、容器 Registry、ASC 上传与会话同区约束写进假设；扩容时才发现「加机」解决不了「机在对区、链路在错区」。
身份与租期未绑定：在短租机上生成长期 PAT 或静态部署密钥，POC 结束镜像一快照，秘密半径扩散到备份链；与凭证拓扑文描述的红线同构。
变更窗口与供应商 SLA 未对齐：大版本 Xcode 或系统安全更新落在发布周，却没有书面扩容或冻结窗，导致「能跑」无法过渡到「敢签」。六类信号的本质是：评估窗缺少数值化验收与科目映射。

与《短租到岗首绿》相比，POC 更关心负载曲线能否在固定大区上重复两周，并把结论映射到日租 / 周租 / 月租与加机触发线；前者解决「四小时窗内交付」，后者解决「财务敢批下一季度基线」。

组织上建议指定单一「POC 主责人」维护台账 YAML（见下文），任何口头「再观察一周」都必须回写为字段变更，否则复盘会沦为印象流。

维度	POC 评估窗（建议 10–14 个工作日）	生产基线（月租及以上）
成功定义	在目标并发下关键流水线 P95 稳定；磁盘与出口有日粒度采样；身份路径可 revoke 演练	同上，外加变更窗书面化、容量告警进 on-call、科目与成本中心绑定
并发假设	显式写出「同时 N 条 job + M 个 Simulator」；允许低于生产峰值但不得单串行粉饰	按队列深度与发布窗上调 N、M；与混合 CI 路由表一致
磁盘与缓存	记录 `DerivedData`、Pods/SPM 缓存、制品目录的日峰值占用与清理策略是否可脚本化	把清理策略固化到 LaunchAgent/CI 前置步；扩容存储或拆机构建前可复盘曲线
网络与出口	至少一周含「重依赖日」样本；区分同区与跨区拉取字节	对跨区拉取有节流或镜像；与egress FinOps科目对齐
租期档位	默认日租/周租承载探索；禁止在短租镜像内冻长期 PAT（见凭证文）	月租/季租承载基线；峰值用短租或加机，与错峰表同页

info

提示：上表可直接粘进架构评审附件；数字阈值（P95 秒数、磁盘 GB、日 egress GB）请替换为你们现网采样，但字段名不要删，否则第二周无法同比。

六步 Runbook：从立项到「可签字的扩容结论」

冻结 POC 假设三元组：目标大区（六国之一或多）、并发上限、依赖日清单（含一次全量 pod install / swift package resolve）。
搭最小观测面：磁盘 df、构建墙钟、队列等待、出口字节（可用简单 cron + 日志，不必一上来上大监控栈）。
跑满至少两个「类生产」周：其中一周必须覆盖你们真实最重的合并窗或发布彩排。
做 revoke 与重启演练：验证无人值守路径不依赖某人桌面会话；与 SSH/VNC 分工文一致。
对照扩容触发线决策：若连续满载当量小时（CBEH，见专用 vs 云实例文）突破内部阈值，优先升租期或加串行出口机而非盲目加并行编译机。
输出一页决策纪要：含 YAML 快照、阈值、签字人、下一复盘日期；未达阈值则明确「不扩容」的原因与残留风险。

yaml

# POC 台账最小字段（键名可按采购模板调整）
poc_id: MAC-POC-2026-05-11
region_primary: SG   # 六国代码：SG/JP/KR/HK/US-E/US-W
lease_tier_start: daily
concurrency_target: { parallel_jobs: 3, simulators: 2 }
kpi:
  build_p95_seconds: { target: 900, measured_day_max: null }
  disk_peak_gb: { target: 400, measured: null }
  egress_daily_gb: { target: 80, measured_peak: null }
scale_triggers:
  upgrade_to_weekly_if: "CBEH > 120h in rolling 14d"
  upgrade_to_monthly_if: "CBEH > 500h in rolling 30d OR disk_peak_gb > 0.85*provisioned"
  add_second_node_if: "mutex_wait_p95_s > 600 on signing lane"

三条应写进评审纪要的量化口径（示例阈值需按组织基线替换）

构建关键路径 P95（秒）：在 POC 窗内按 job 类型拆分（unit / ui / archive）；若周环比上升超过 35% 且代码变更率未同步上升，优先查磁盘与锁竞争而非加 CPU。
磁盘水位峰值比：以供应商配置总容量为分母；若连续三日峰值超过 85%，必须在升级租期前先落地自动化清理或扩容存储档，否则月租只会把「爆盘」推迟到月底。
互斥链（签名 / notary）等待 P95（秒）：若超过 600 且队列深度上升，扩容应优先「第二台串行出口机」而非第三台并行编译机——与签名机 vs 构建机拆分矩阵一致。

为什么「办公室闲置 Mac + 远程桌面凑合」或「只靠按小时云实例弹缩」常常撑不住正式评估窗

办公室闲置机缺公网拓扑、固定大区出口与可审计 SLA：夜间休眠、家用上行抖动、无外网静态路由，会让两周曲线出现不可复现的断崖，POC 结论无法迁移到生产。纯按小时云实例若在评估窗内频繁销毁重建，则冷启动与镜像漂移会把大量墙钟消耗在环境准备上，财务看到的「便宜小时价」与工程感受到的「有效构建小时」严重偏离——这一点在专用租赁与云实例对照表里已有工程化表述。

当你需要把 POC 结论写成可签字、可进采购附件、且与六国区位策略一致的基线时，MACCOME 的 Mac 云主机通常更易同时满足独占 Apple Silicon、弹性日/周/月/季租期、以及可按项目拆分的成本叙事：节点覆盖新加坡、日本、韩国、香港、美国东部、美国西部，便于把上文 YAML 里的 region_primary 与公开价格字段对齐，而不是在「办公室机器」与「按小时账单」之间反复横跳却无法复盘。

收束：把 POC 定义成「可拒绝扩容」的权力，而不是演示文案

好的评估窗应能在数据不足时明确写出不通过：例如出口样本未覆盖重依赖日、或 revoke 演练失败——这比含糊的「再试试」更能保护下一季度预算。与买租 TCO并联时，POC 纪要应能回答：若通过，月租基线对应哪条折旧曲线替代假设；若不通过，是区域、链路还是身份面阻断。

若你已跑完多地区延迟与租期组合，仍卡在「何时签字扩容」，请回到本文对照表，把POC KPI 与生产 KPI 的差集逐项划掉，直到只剩可执行的财务字段。