结论：这一轮最值得补进雷达的是 2026-06-12 提交到 arXiv 的 ShearFuse-UNet: Hadamard, DCT, and Shearlet Transform Fusion for Next-Day Wildfire Spread Prediction。它不是遥感 VLM，也不是新的 GeoFM，而是把次日野火蔓延预测里一个很具体的结构先验说清楚了：火线不是普通纹理，而是受风、地形、植被和既有燃烧边界共同约束的方向性边界。ShearFuse-UNet 用 WHT、DCT 和 Shearlet 三类固定变换替代一部分 learned attention，在 267k 参数下达到 WildfireSpreadTS 上 F1 0.596，比 14M 参数 ResNet18 U-Net baseline 的 0.589 略高，重点价值在“轻量、可部署、面向边界几何”。

我按 2026-06-15 15:00 +08 检索公开来源，并过滤 SAR、PolSAR、InSAR、radar-only、microwave-only 与 SAR-optical fusion 主线工作。本篇使用的是多模态卫星、气象、地形和火点时序数据，不以雷达或微波成像为核心输入。它和历史里的 wildfire GeoFM LoRA 方向不同：那条线更偏火烧迹地/灾后制图和基础模型微调，本篇聚焦 次日火势蔓延预测，也就是应急响应里更关心的“明天哪里可能烧到”。

背景

遥感灾害 AI 很容易被两个方向吸走注意力。

一个方向是大模型化。我们会自然想到用 GeoFM、VLM、SAM 或多模态 Agent 来做灾害识别、火烧迹地制图、风险问答和报告生成。这条线重要，但它并不直接解决应急预测里的延迟和资源约束。

另一个方向是物理模拟。火势蔓延受燃料、湿度、风速、坡度、地表覆盖、历史火点和人工干预影响，传统模型通常需要大量参数、专家校准和高质量输入。它可解释，但在真实应急环境中，快速更新、缺失数据和区域泛化都很难。

ShearFuse-UNet 切在两者之间：保留 U-Net 这种轻量 dense prediction 框架，但把火线几何放进网络结构里。它不追求用 Transformer 学出一切，而是问一个更工程的问题：如果火势边界天然有方向性，能不能用固定的频域和方向变换，把这种先验便宜地注入模型？

结论：这一轮最值得补进雷达的是 2026-06-11 提交到 arXiv 的 MaskWAM: Unifying Mask Prompting and Prediction for World-Action Models。它本身是机器人 World-Action Model，不是遥感论文；但它给遥感 AI 一个很直接的启发：如果模型要理解“哪里会变、哪个对象重要、未来应该关注什么”，就不应只重建 RGB 或多光谱影像，还应该显式预测任务相关 mask。对光学遥感变化检测、灾害扩散、农田物候、道路/建筑增量更新和 VLM 空间指代来说，mask 既可以是 prompt，也可以是监督目标。

我按 2026-06-15 13:00 +08 检索公开来源，并过滤 SAR、PolSAR、InSAR、radar-only、microwave-only 与 SAR-optical fusion 主线工作。本篇选择的是一个 CV/机器人方向的可迁移方法，不涉及雷达输入。它和前几轮已经写过的 SpatialClaw、Earth-Agent、TerraBench、Plan2Map、VecLang、CoastlineVLM、Stateful Visual Encoder 等不同：重点不是工具调用或 VLM 答题，而是把 mask prompt 和 future mask prediction 合并成一个可训练的时空接口。

背景

遥感时序建模里有一个长期问题：我们经常让模型预测像素、预测差异图、预测类别图，或者直接输出变化检测结果，但很少追问模型内部到底在“跟踪哪个对象”。

这在简单二时相变化检测里还可以靠差分特征糊过去。一旦场景变复杂，问题就出来了。比如同一张超高分影像里有多栋相似建筑，文本说“新建的厂房”并不能精确指向目标；农田时序里作物、裸地、阴影和云边界经常混在一起；灾害前后影像中，真正应该关注的是滑坡体、受损建筑、淹没边界或道路阻断，而不是整幅图的外观重建。

现有遥感基础模型和 VLM 很擅长做全局表征、caption、VQA 或开放词表识别，但它们仍容易把“语义上相关”和“空间上对准”混为一谈。用户问的是某个目标、某片区域、某条边界，模型却可能靠上下文猜测。更麻烦的是，如果训练目标只是 RGB/多光谱重建，模型会把云影、纹理、背景和无关地物也当成同等重要的预测对象。

MaskWAM 的价值就在这里。它虽然来自机器人操作，但提出了一个可以迁移到遥感的原则：不要只让模型预测未来画面，也要让它预测未来的任务相关 mask；不要只用文字描述目标，也要允许首帧 mask 作为空间锚点。

论文/项目

MaskWAM 的 arXiv 页面显示论文于 2026-06-11 提交，主题包括 computer vision、machine learning 和 robotics。作者来自香港科技大学、Tencent Robotics X 和清华大学。官方项目页和 GitHub 仓库已经开放，仓库说明这是官方实现，但截至本轮检索，训练、推理、模型权重、数据准备和评测脚本仍在准备发布。

结论：今天最值得看的不是单点 SOTA，而是遥感 AI 的评价对象正在变化。 GeoFM 方向开始从“谁的预训练更大”转向“同一协议下，架构如何处理缺 band、多光谱和下游任务”；GeoAI Agent 方向开始从“能不能调用工具”转向“能不能把遥感影像、格网数据、GIS、模拟器和文档证据串成可执行过程”；CV-to-RS 方向给出一个强信号：box/mask prompt 与 test-time adaptation 很适合做遥感开放词汇分割和变化检测的证据校准。

我按 2026-06-15 09:00:02 +08:00 回看公开来源。由于 arXiv 周末没有正常新一轮发布，严格 24 小时内没有比前几轮更强的新遥感主线；本篇保留最近一个可核验 release 窗口里仍值得进入日报的 5 个条目，并过滤 SAR、PolSAR、InSAR、radar-only、microwave-only 和 SAR-optical fusion 主线。个别论文含 S1/S2 混合实验时，本文只讨论其 Sentinel-2、多光谱、缺 band 和架构泛化部分，不把 SAR 结果作为推荐依据。

今日 5 个重点

1. Flexible GeoFM：第一篇最值得精读

这篇的价值在于把 GeoFM 的争论变成可控实验。 过去很多遥感 foundation model 论文同时换了数据、任务、训练轮数、mask 策略、输入 band 和 decoder，很难判断到底是架构有效，还是训练 recipe 更强。Emerging Flexible Designs for Geospatial Multimodal Foundation Models 把 SatMAE、DOFA 和一个 ClimaX-inspired Flex 放进同一套自监督预训练和 GEOBench 下游协议里比较，重点问两个问题：多光谱 band 应该怎么 tokenization，跨 band / modality 的 fusion 应该放在什么位置。

结论：这一轮最值得单独跟踪的是 2026-06-09 提交到 arXiv 的 Geometric Coastline Localization using Vision-Language Models。它的价值不在于又做了一个海岸线分割模型，而是把任务从“先预测像素 mask，再后处理成线”改成“让 VLM 直接输出海岸线 polyline”。这件事对遥感 AI 很重要：很多业务对象最终不是 raster，而是 GIS 里可测量、可编辑、可追踪的矢量几何。CoastlineVLM-7B 用 GeoChat-7B / LLaVA-1.5 架构，把海岸线存在检测、海岸线 proxy 类型判断和 polyline grounding 放到一个 instruction-following 框架里，并用 Hausdorff、EMD、Fréchet、Chamfer 等几何指标评价，而不是只看 IoU。

我按 2026-06-15 03:00 +08 检索公开来源，并过滤 SAR、PolSAR、InSAR、radar-only、microwave-only 与 SAR-optical fusion 主线工作。本篇选择的是高分辨率航空/光学遥感上的海岸线几何定位，不涉及雷达输入。同期候选里，BCP 更偏通用 CV 的 VLM 测试时适应，SpatialClaw 更偏通用空间智能 Agent，UltraVR 和 VLRS-Bench 更适合作 benchmark 综述；CoastlineVLM 的问题定义更具体，且直接连到遥感 VLM、GIS 矢量输出、薄结构评价这三条线，因此更适合本轮单篇深挖。

这篇文章的现实意义在于：遥感模型常常优化的是像素分类，但用户真正要的是一条可以进入 GIS 的线、一个可以算面积的多边形、一个可以沿时间序列比较的对象。海岸线尤其典型。实际海岸线分析使用的往往不是某一时刻的水陆边界，而是 vegetation line、dune toe、cliff edge、built structure line 等地貌 proxy。潮汐、浪涌、泥沙、阴影和道路边缘都会干扰像素分割。CoastlineVLM 的核心主张是：如果目标本来就是几何边界，模型就应该直接学习几何边界，而不是把几何作为分割后的副产物。

结论：这一轮最值得单独跟踪的是 Fusing Satellite Imagery and Planimetric Maps for Cross-View Localization。它做的不是再造一个更大的 backbone，而是把一个很现实的问题摆到台面上：跨视角定位里，为什么总是默认只用卫星影像，明明平面地图和卫星图各有长处。论文给出一个很轻的融合模块，用 cross-modal conditioning 加 patch-level fusion，把 OpenStreetMap 这类平面地图和卫星影像一起喂给现成编码器，结果在 VIGOR 和 KITTI 上都比单模态更稳，KITTI 的 mean localization error 最好降到 3.85 m，较此前单模态最优方法低 30.13%。

我按 2026-06-14 19:00 +08 检索公开来源，过滤 SAR、PolSAR、InSAR、radar-only、microwave-only 和 SAR-optical fusion 主线工作。这里选的是 2026-06-08 提交 arXiv 的 CV 论文，但它和遥感的关系很直接：输入一端是卫星影像，另一端是 OSM 平面地图，目标是地理定位。这类方法对遥感系统的价值，不在于它本身是“遥感专用网络”，而在于它给出了一个可迁移的多源融合模板。

背景

跨视角定位一直有个老问题：地面视角和俯视视角差异太大。单靠卫星图，模型能看到建筑轮廓、道路纹理和街区形状，但在树冠遮挡、细粒度街景结构不清、或者局部语义歧义时，信息会不够。平面地图相反，它不一定像影像那样“真实”，但它有明确的对象标注，尤其在道路、街灯、建筑和路网结构上很强，遮挡区域也更稳。

之前很多工作默认“卫星图够用了”，或者把 OSM 当成辅助分支粗暴拼接。问题是，这样做常常只能看到形式上的融合，没有真正把两种模态的互补性吃进去。更糟的是，卫星图和地图在不同区域的可用性并不一样：有些地方 OSM 覆盖好，路网和 POI 丰富；有些地方地图稀疏，卫星图反而更可靠。于是，真正有价值的不是再加一条分支，而是让模型学会按区域、按 patch 动态决定该信谁。

这篇文章的定位很清楚：它要解决的不是遥感分类，而是“地理定位里的模态选择问题”。这对遥感侧的启发是直接的。很多 RS 系统也在走同样的路：卫星影像、栅格地图、矢量图、POI、建筑轮廓、道路拓扑，最后都要汇到一个定位或检索模型里。问题从来不是有没有数据，而是这些数据怎么协同。

结论：这一轮最值得单独深挖的是 SpatialClaw: Rethinking Action Interface for Agentic Spatial Reasoning。它不是遥感原生论文，也没有在卫星影像 benchmark 上报告结果；但它给遥感 VLM 一个很直接的启发：空间推理不应只靠一次性文本回答，也不应只靠固定 schema 的工具调用，而应该让模型在一个有状态 Python kernel 里逐步写代码、调用感知工具、查看中间证据、修改分析路径，最后再提交答案。对大幅遥感影像、矢量图层、DEM、时间序列和 GIS 证据链来说，这个“代码即动作接口”的设定比普通 VQA prompt 更接近真实工作流。

我按 2026-06-13 23:00 +08 检索公开来源，过滤 SAR、PolSAR、InSAR、radar-only、microwave-only 和 SAR-optical fusion 主线。本篇选择 2026-06-11 提交 arXiv 的 SpatialClaw。论文和官方 GitHub 均已公开，仓库说明包含 agent runtime、LangGraph workflow、persistent Jupyter kernel、AST safety check、planning/reflection loop、20 个 benchmark loader、perception tool wrappers、FastAPI GPU tool server、vLLM 发现与负载均衡、SLURM 复现实验管理。本文把它作为 CV-to-RS 迁移方向，而不是当作已有遥感 SOTA 结果引用。

这篇适合放进“遥感基础模型与多模态理解”。原因是它研究的是 VLM agent 的空间推理接口，而遥感 VLM 的很多关键失败都来自空间接口不足：模型看不清局部证据、不会把 tile 和全图坐标对齐、不会把 mask/box/polygon/DEM 统一计算、不会记录跨步骤证据，也不会把中间计算交给可验证工具。SpatialClaw 不直接解决遥感问题，但它给了一个可复用的系统骨架。