企业官网建设流程全解析

最近我在整理行星科学资料时，注意到一个很值得讨论的方向：MarsCast。它想解决的问题很直接：把地球上已经训练好的 AI 天气基础模型，通过迁移学习搬到火星等行星大气里用。这个思路之所以吸引人，是因为火星没有地球这么密集的长期实测数据，如果每个任务都从零训练一个大气模型，代价会很高。用迁移学习，至少有机会把地球模型已经学会的“大气运动通用规律”带到火星场景中。

这篇文章更适合两类人看：一类是做行星遥感、大气科学，想尝试用深度学习方法做火星天气预报或气候研究的同学；另一类是已经在做地球 AI 气象模型，想把自己训练好的模型迁移到更多星球或极端环境下的人。文章不会只讲概念，我会把数据准备、网格处理、变量映射、模型微调、验证指标和常见坑点都拆开说一遍。

先给出我的核心判断：MarsCast 这类方向的价值，不在于让火星预报立刻达到地球业务预报的精度，而在于当数据很少、物理过程又复杂时，能不能用较少的样本把预训练模型“改造成”一个会预报火星大气的模型。这个思路值得跑通，但一定要在数据和验证上多做克制，否则很容易变成“看起来合理、实际不可靠”。

1. 先搞清楚 MarsCast 到底要解决什么问题

1.1 火星天气预报为什么难

火星大气和地球大气有很多相似点，也有完全不同的地方。相似点在于，它也有气压、温度、风、尘埃、云和季节变化，也遵循流体力学和热力学方程。不同的是，火星大气非常稀薄，表面平均气压只有地球的百分之一左右，热惯性小，昼夜温差特别大，还有全球性的沙尘暴，随季节变化非常剧烈。

这些特点导致传统数值预报模式在火星上应用时，需要单独开发一套物理参数化方案。但比物理方案更难的是约束数据。地球上做气象预报，有全球密集的观测站、探空气球、卫星遥感、飞机报和大量的再分析数据。火星上只有少数轨道器的遥感数据，以及着陆器和火星车在特定区域、特定时间段的表面测量，数据覆盖度和连续性都很差。

所以火星天气预报的瓶颈，一直不是算法不够多，而是“真值不够用”。训练深度学习模型时，我们需要大量输入输出配对的样本，但在火星上，这样的配对数据非常稀有，通常要依赖数据同化产品或者气候模式模拟结果来充当标签。

1.2 为什么可以借鉴地球的 AI 气象基础模型

地球上的 AI 气象基础模型，近两年发展很快。它们大多使用全球再分析数据做预训练，把从 1979 年甚至更早开始积累的几十 TB 气象数据压缩进一个神经网络里。模型学到的不只是某一个区域的具体天气，而是大气环流、能量输送、冷暖锋、尺度交互这些一般性规律。

这些“一般性规律”不一定只属于地球。火星大气同样是三维流体，同样受太阳辐射、气压梯度力和科里奥利力的影响。虽然气体成分、大气密度、自转速度、季节长度都不同，但很多基础物理约束是相似的。用迁移学习，就是在已经学到这些基础规律的模型上，再去做少量火星数据上的适配。

这也是 MarsCast 最核心的假设：模型参数里已经包含了部分普适的流体动力学知识，迁移到火星时不需要重学，只需要在火星数据上做修正和调整。

但要注意，这个假设本身需要验证。我们没法说“一定会有用”，只能说在样本有限的情况下，这比完全从随机初始化开始训练更合理、更有机会。

2. 迁移学习要过三道关：数据、网格、变量

2.1 火星大气数据从哪里来，长什么样

开始动手前，第一步是确认你能拿到什么数据。目前公开可用的火星数据源大概有几类。

一类是观测数据，比如 NASA 的行星数据系统 PDS，里面保存了火星轨道飞行器、着陆器的原始和标定数据。另一类是再分析/气候模式产品，比如欧洲空间局和多家机构共同发展的火星气候数据库 MCD。MCD 不是直接从观测数据建立的气象记录，而是用火星全球气候模型跑出来的一套气候态和逐日变化数据集。它覆盖的时间很长，但本质是模型模拟，存在系统误差，不能当成真实观测来盲目信任。

还有一类是各地面站的气象数据，比如洞察号、好奇号、毅力号站在地表测到的气压、风、温度等。这些数据精度高，但只覆盖着陆点周边，空间上很稀疏。

在实际工程里，我一般会先用 MCD 这类输出文件练手，因为它能提供全球格点场，方便把地球模型用起来。先不要直接拿稀疏的地表观测做整段迁移训练，否则会让你连输入张量都凑不齐。

常见的数据格式有 NetCDF、HDF5、CSV 和二进制平文件。预处理的第一步是统一格式和坐标。用 xarray、netCDF4 这类 Python 库读取最快，但要注意不同版本的库对压缩格式的支持不一样，报错时优先确认数据文件是不是已经切分、有没有损坏、维度名字是否和原模型一致。

2.2 网格系统不一样，不能直接用

地球模型的输入网格，结构五花八门。有的模型使用等经纬度网格，有的使用立方球网格，有的使用图神经网络格式的非结构化网格。你选定的预训练模型决定了输入张量的组织方式。

火星大气场也一样可以表达成经纬度网格，但分辨率、极地处理、网格覆盖范围都需要确认。最稳妥的方式，是把火星变量统一插值到预训练模型能够接受的空间网格上。这里建议分三步做：

1. 读取火星数据，把坐标系统一成 WGS84 风格或火星标准经纬坐标。
2. 插值到预训练模型使用的网格分辨率，例如 1.5 度、0.25 度或模型原始分辨率。
3. 对边界、极地、缺测区域做掩膜处理，不能让 NaN 或异常值直接进入训练。

如果模型本身是图神经网络，处理非结构化网格会更灵活。但这类模型在迁移时反而要小心图边界的物理含义，不能只改节点特征就结束。

2.3 变量映射和目标变量选择

地球气象模型常输入的变量包括：多层的温度、位势高度、纬向风、经向风、比湿/相对湿度等。压力层级通常从 1000 hPa 到 50 hPa 或更高。

火星大气没有那么多水汽，可以用其他变量代替。常见的候选变量是：

不要把模型所有输入变量都强行套上去，要保持“物理意义一致”的原则。如果地球模型里输入的是海表温度，迁移到火星时没有对应量，就不要硬找一个变量填充，而是要考虑重新设计输入头，或者把该变量替换成新的、有代表性的火星变量。

另外，迁移学习时的目标变量不一定要和地球模型完全一致。你既可以做“温度、气压、风的短期预报”，也可以做“未来 6 小时、24 小时的场演变预测”，甚至可以只做“某区域地表气压的预测”。目标越具体，越容易在小数据集上得到有效结果，也越容易和别人做对比。

3. 一套可以照着跑的迁移学习流程

3.1 选模型和预训练权重

想复现 MarsCast 的工作，第一步是选择一个可用的地球 AI 气象基础模型。目前公开讨论比较多的方向有基于 Transformer 的全球预报模型，有基于图神经网络的预报模型，也有以生成模型或扩散模型为框架的天气生成方法。

对初学者来说，选择标准不一定是“效果最好”，而是“源码和权重是否公开”“输入输出格式是否容易改”“显存需求是否可承受”。我个人建议先选一个结构相对简洁、权重文件小一点、社区资料多的模型做通链路测试，而不是一上来就追求最强精度。

拿到预训练权重后，先不要急着微调。先看两件事：

1. 权重对应的输入变量顺序、标准化参数、网格分辨率。
2. 模型的许可证和适用范围。很多权重只能用于科研，不能直接用于业务或商用。这个要从权重发布的原始网页确认，不要只看博客转述。

3.2 数据预处理与标准化

在火星数据上做预处理时，最容易踩坑的是标准化方式。地球模型预训练时，一般会保存用来归一化训练集的均值和标准差。迁移到火星时，不能直接用这套地球统计量去标准化火星数据。

更合理的做法是：先用火星训练集重新计算均值和标准差，再对输入变量做标准化。这样可以把火星气压实测值和地球气压范围不一致的问题消化掉一部分。

如果某个变量在火星上分布范围很广，比如沙尘光学厚度可以从接近 0 变到几，建议单独做非线性变换，例如取对数后再标准化，避免极值主导梯度。

时间分辨率也要统一。地球再分析数据常见是 6 小时一次，所以预训练模型很可能默认输入间隔是 6 小时。火星数据的输出频率可能是一天多次，也可能是某个季节的日平均。你需要把输入序列插值到模型期望的时间频率，同时要确保预测目标和输入时间之间没有未来信息泄露。

3.3 微调策略：冻结、解冻、再加一层输出头

大多数迁移学习实践，不会一次性把整个地球模型的所有参数都开满训练，否则火星数据量少，很容易把预训练学到的东西破坏掉。常见做法是分阶段微调：

第一阶段，冻结大多数骨干网络参数，只训练输入头、输出头或者额外加的适配层。这个阶段的目的是让模型先适应火星数据的统计分布。

第二阶段，解冻部分高层骨干参数，用小学习率继续训练。选择解冻哪几层，取决于你的显存余量和数据量。数据越少，解的层数就越少。

第三阶段，如果火星数据比较充足，再考虑全量微调。但此时学习率要比普通训练低很多，建议是原学习率的 0.1 倍甚至更低。

如果模型参数量太大，而你只有单张低显存显卡，可以使用适配器或者线性探测方式。也就是在预训练模型中插入若干小参数模块，只更新这些模块，主干参数全部冻结。这样既能够保留地球知识，又不需要太多火星样本。

3.4 一个示例数据流

下面给一个示意性的 PyTorch 风格流程，目的是说明数据流，不是完整工程代码。

# 示意代码，按你使用的模型和数据结构调整 # 1. 读取火星数据 ds = open_mars_data("mcd_output.nc") mars_grid = ds["ta"].values # 温度场，维度 [time, level, lat, lon] # 2. 标准化：重新计算火星数据的均值和标准差 mean = mars_grid.mean(dim=("time", "lat", "lon"), keepdims=True) std = mars_grid.std(dim=("time", "lat", "lon"), keepdims=True) mars_input = (mars_grid - mean) / std # 3. 变量映射，选择输入通道 x = torch.tensor(mars_input).float().unsqueeze(0) # [B, C, T, H, W] # 4. 加载地球预训练模型 model = load_pretrained_earth_weather_model("your_checkpoint.ckpt") # 5. 替换/修改输入输出头，然后按阶段微调 model.input_encoder = new_input_encoder(num_vars=len(selected_vars)) model.output_head = new_output_head(num_pred_vars=num_targets) # 6. 只训练部分参数 for name, param in model.named_parameters(): param.requires_grad = False for name, param in model.output_head.named_parameters(): param.requires_grad = True optimizer = torch.optim.Adam(filter(lambda p: p.requires_grad, model.parameters()), lr=1e-4)

这段示例的重点不是具体 API，而是三个步骤：标准化、变量映射、参数冻结。跑通链路之后，再逐步开放更多层训练。

4. 实验设计与验证方式

4.1 用气候态和传统数据同化结果做参照

火星上缺乏“完美真值”，所以验证不能只看一组预测结果是不是看起来平滑。我们需要找一个相对可靠的参照物。

我建议至少做三组对比：

1. 气候态基线：直接用训练集或气候资料算多年平均，预测未来的“气候平均值”。如果模型的 RMSE 连气候态也打不过，迁移学习就没有意义。
2. 数据同化/气候模式输出：用 MCD 或类似再分析产品的同时间段结果作为参考曲线，看模型输出的空间结构是否合理。
3. 掩模验证：把某些区域或某些时间段从训练数据中留出，用模型对留出区域做预报。如果模型只在训练覆盖到的区域表现好，说明泛化不足，可能是过拟合。

4.2 评估指标别只盯着 RMSE

气象领域常用的 RMSE 和 MAE 能反映平均误差，但在火星场景里，光看这两个指标很容易被“低方差输出”骗到。模型如果可以输出接近气候态的平滑场，RMSE 可能并不难看，但它完全没有把握住沙尘暴、气压骤变等极端过程。

所以建议增加这样的评估项：

• 逐点偏差，看看是不是在极地、峡谷、着陆器所在区域特别大。
• 空间相关性异常 ACC，看预测的异常空间型是否和参考一致。
• 不同季节分别评估，火星南北半球季节差异很大，单一夏季指标可能没有参考价值。
• 对事件样本做单独评估：例如沙尘暴爆发时段、极夜时段、CO₂ 霜层变化时段。

如果模型是概率输出或者集成输出，还要评估概率校准度。不能只输出一个均值就完事，火星数据少，预测不确定性往往很大。

4.3 怎么判断迁移成功还是过拟合

我认为最实用的判断方法，是把自己当成一个“用户”来检验：拿一个训练中没见过的火星时间段，输入过去几天的场，让模型预测未来 1 到 5 天，然后和参考场对比。

如果出现以下情况，说明模型很可能在记忆训练集而不是学习物理：

1. 训练集上的误差很低，验证集上误差迅速反弹。
2. 预测场整体非常平滑，且没有任何移动的小尺度结构。
3. 对不同的初值都会给出一模一样的输出，和初始场无关。
4. 时间序列预测里，如果输入时间越接近训练集末尾，输出越准，越早越差。

这些现象都提示你要减少模型参数、增加正则化、解冻更少的层，或者回去检查数据切分是否严格按时段而非随机洗牌。很多气象迁移任务犯过“随机切数据”的错误，导致相邻时间样本高度一致，模型在验证集上看起来不错，实际预报完全不行。

5. 实际跑起来会遇到的问题

5.1 算力、显存和跑不动

火星迁移学习不会比地球预训练更重，因为通常不需要从头训练大规模模型，但是微调阶段仍可能遇到显存不够的问题。

低显存环境先不要硬上 3D 大张量。建议把空间分辨率降到一个模型能接受的低档，比如在 1.5 度到 2.5 度之间做实验，能跑通后再升分辨率。时间序列长度也可以从 4 个输入帧开始，不要一上来就塞几十帧。

如果 CPU 内存也不够，可以把数据拆成多个子区域，分别做局部微调，然后再合并。但要注意区域切分不能破坏大气物理连续性，至少要让相邻区域有一定重叠。

5.2 训练不稳定、Loss 不降

迁移训练时，典型的失败现象是 Loss 一开始下降，后面突然抖动或者直接崩溃。这种情况通常和标准化、学习率、梯度裁剪有关。

我的排查顺序是先看输入数据里有没有极端值。火星的尘埃、地形、气压在某些格点可能出现非常大的离群值，如果不做处理，就会让模型梯度爆炸。建议设置输入上下限，或者在标准化之后加一个数值截断。

如果数据没问题，再看学习率。迁移学习里的常见误区是沿用地球预训练时的学习率，这是不合适的。预训练阶段可以容忍较大学习率，因为训练数据多；火星微调数据少，学习率太高很容易让模型在局部最优附近反复震荡。

最后可以在优化器里加入 gradient clipping，把梯度范数限制在一个合理范围，比如 1.0。这样做最终效果可能会保守一些，但至少训练过程可控。

5.3 输出结果看起来合理，但逐日预报不靠谱

这是火星天气 AI 项目里最常见的“假成功”。模型输出的气压场、温度场看起来和火星气候模式很像，空间分布也合理，但如果你把它当成逐日天气预报，会发现落地点位根本对不上。

原因往往是模型学会了“输出一个统计上正确的火星气候”，但没有学会“根据当前初始场做预报”。或者更准确说，因为训练数据本身来自气候模式，模型的预测能力被标签噪声限制住了。

要解决这个问题，不能只靠调模型，还要回归到数据构建：

1. 确认训练样本是匹配的“同一时刻”输入输出，而不是不同月份拼凑。
2. 确认输入序列和输出序列之间没有错位。
3. 在预测结果上做订正：用最近一段时间的平均偏差做偏差修正，能显著改善地面站点的预报评分。

我还建议把逐日预报分成“短期趋势预测”和“气候环流模拟”两类任务分开验证，不要用一套指标掩盖两类问题。

6. 这个方向的边界和后续空间

6.1 迁移学习不是万能的

MarsCast 的核心价值是降低火星大气建模的冷启动成本，但它的边界很清楚：迁移学习要求源域和目标域存在一定的共性。地球和火星都是行星大气，共性存在，但差异也不小。

火星大气中含 CO₂ 超过 95%，CO₂ 会在极地季节性地凝华和升华，造成表面气压的全球性变化。这种过程在地球上没有直接对应物，模型如果只迁移地球知识，不太可能天然理解这种机制。想让模型学会这种特殊物理过程，必须给训练数据里加入足够多的含沙尘、极地凝华等样本，或者引入物理约束损失项。

另外，从风格和验证上来说，火星“真值”稀缺会长期存在。迁移模型即使表现好，也容易受到标签来源偏差的影响。训练时如果只对标一个气候模式，那么你学到的实际是这个模式的误差分布，而不是火星真实大气的完整规律。这一点要在论文或项目文档里写清楚，否则很容易在后续应用中过度解读。

6.2 后续可以往哪个方向做

这条路线的延续方向很多。

一个是向更多行星推广。把地球模型迁移到火星成功之后，可以继续尝试金星、木星、土卫六等大气环境。不同行星的大气成分和热力结构差异更大，但迁移学习框架本身可以复用。

另一个方向是把物理约束重新加回来。在损失函数里加入流体运动方程残差、能量守恒约束，或者和数值模式做耦合，都有机会弥补纯深度学习方法在物理一致性上的短板。

还有一个工程方向是做成通用行星预报模型。先在地球数据上预训练，再用多颗行星数据做持续微调，最终形成一套能处理不同星球输入张量、不同目标变量的行星基础模型。这是很自然的技术演进，但难度会比单一 MarsCast 高很多，需要先建立统一的数据接口和评估体系。

如果只是做入门复现，我的建议很直接：先复现一个地球气象模型的预训练-微调链路，把数据读取、网格插值、变量映射和指标评估这四块跑通，再换成火星数据。不要一上来就挑战超大模型，也不要一开始就追求“精确预报火星每一个点的温度”。

火星大气的迁移学习，最终能不能稳定用于实际科学任务，还需要更长时间验证。但至少从当前技术趋势看，它是一条值得投入的方向，因为我们有太多没有充足数据覆盖的行星，需要靠已知规律去推断未知环境。把这套流程记录清楚，会比单纯发一个“精度很高”的结果更有长期价值。