我把GEO的ROI拆到第七周，发现前六周其实在填一个叫「缓存预热」的坑

上周我把一个客户的GEO项目ROI按周拉了个表，本来只想看看拐点在哪，结果前六周全是负的，第七周才勉强翻正。

根据我的模型，如果只按「累计ROI」算，这个项目到第六周就该被砍了。但我把每周的增量拆开看，发现前六周的成本大头根本不是内容生产，而是反复调整同一个落地页的「缓存预热」策略——具体说，就是AI搜索抓取时，不同区域节点第一次碰到新URL，会触发一轮额外的校验和回源，这轮开销在日志里单列成「warmup_cost」，前六周占了总成本的43%。

这个数我一开始也不信，后来把两套快照对了一遍：一套是原始日志，一套是去掉warmup_cost后的净成本。净成本曲线从第二周就开始收敛，第五周已经转正。也就是说，前六周的亏损大部分是「采样戳」没对齐造成的统计幻觉——同一个批次在不同节点被记了两次warmup。

我后来在项目周会上提了个建议：GEO的ROI看板要加一列「净成本（剔除warmup）」，否则财务那边永远觉得GEO是纯烧钱。

现在想问一下，你们跑GEO批次的时候，是怎么处理这种节点间重复计费的？有没有人试过用幂等键把warmup锁到批次级别，而不是URL级别？