企业官网建设流程全解析

1. 这不是选“最好”的算法，而是选“最不拖后腿”的算法

在地球观测领域干了十多年，我经手过从Landsat到Sentinel再到国产高分系列的上百个遥感项目，也带过不少刚毕业的硕士生做地表覆盖分类、作物长势监测、城市热岛分析这些活儿。每次开项目启动会，总有人一上来就问：“老师，这个任务用ResNet还是ViT？要不要上SAM做分割？”——这种问题问得我直摇头。不是技术不重要，而是地球观测从来不是算法竞赛，而是一场和数据缺陷、物理约束、业务时效、算力现实死磕的持久战。你手里那张20米分辨率的Sentinel-2影像，云遮了35%，边缘有辐射畸变，大气校正参数是默认值，训练样本只有87个农田地块，标注还混进了几块刚翻耕的裸土……这时候讨论Transformer层数，就像给一辆漏油的拖拉机换碳纤维方向盘。

“Deciding What Algorithm to Use for Earth Observation”这个标题，表面看是技术选型，实则是一套完整的工程决策链：它必须同时回答五个硬问题——这数据到底“干净”到什么程度？要解决的物理问题有没有明确的数学表达？业务方能等几天出结果？现有服务器能不能跑得动？最后出来的图，基层农技员能不能一眼看懂？我见过太多团队花三个月调参把U-Net的mIoU从78.3%刷到79.1%，结果交付时发现乡镇平台连GeoTIFF都打不开，最后全靠手动截图发微信。所以这篇不是教你怎么调参，而是带你走一遍我们团队在云南咖啡种植区做病害早期识别、在内蒙古草原做退化评估、在长三角做工业用地动态监测时，真正踩着泥巴做出来的算法决策路径。核心关键词就三个：数据可信度、物理可解释性、部署可行性。适合两类人细读：一是手握真实遥感数据却卡在“不知从何下手”的一线工程师；二是正被导师催着写“算法创新点”却对业务落地毫无概念的研究生。别急着抄代码，先搞清你面对的到底是“一道数学题”，还是一堆需要经验判断的现场约束。

2. 算法决策不是技术比武，而是五维约束下的生存博弈

2.1 数据维度：当影像质量成为第一道生死线

地球观测数据从来不是理想化的矩阵。我拿手头正在做的长江中游洪涝淹没监测项目举例：卫星过境时间固定，但6月长江流域云量平均达72%。我们拿到的Sentinel-1 SAR影像虽能穿透云层，但存在严重的斑点噪声（speckle noise），信噪比（SNR）实测仅8.3dB。这时候如果直接上深度学习模型，相当于让一个近视500度的人去辨认显微镜下的细胞结构——再好的网络架构也救不了输入端的先天不足。我们做过对比实验：同一组SAR影像，用Lee滤波预处理后输入U-Net，IoU提升12.7个百分点；而若跳过滤波直接训练，模型很快过拟合噪声，验证集loss曲线像心电图一样乱跳。

更致命的是辐射一致性问题。去年在东北做大豆种植面积统计，客户提供了2023年5-9月共14景Landsat 8 OLI影像。乍看数据很全，但仔细检查元数据发现：其中3景的太阳天顶角超过75°，导致阴影区辐射值严重偏低；另2景因传感器增益调整，DN值整体偏高15%。如果强行拼接训练，模型学到的不是“大豆光谱特征”，而是“不同拍摄角度下的阴影模式”。我们最终放弃端到端训练，改用辐射定标+归一化后的NDVI时序曲线作为输入，配合随机森林分类，准确率反而比盲目上CNN高4.2%。这里的关键逻辑是：当数据质量波动幅度超过算法鲁棒性阈值时，任何复杂模型都是在拟合噪声。我的经验法则是：先用ENVI或Google Earth Engine跑一遍基础质检——云覆盖率＞30%、辐射校正失败标记＞5%、空间配准误差＞1.5个像素，这三类数据必须先隔离，别想着“数据增强能解决”。

2.2 物理维度：脱离地学机理的算法就是空中楼阁

遥感本质是物理反演过程。植被指数NDVI之所以百年不衰，不是因为计算简单，而是它直接关联叶绿素吸收与近红外反射的物理机制（Lambert-Beer定律）。而很多新算法恰恰忘了这点。比如用Transformer做土地利用分类，注意力权重图显示模型重点关注影像边缘的纹理，但实地核查发现：那些“关键纹理”其实是田埂上的灌溉渠阴影，与土地类型毫无关系。这暴露了纯数据驱动的风险——模型在学“怎么猜”，而不是“为什么这样”。

我们团队在青藏高原冻土退化监测中吃过亏。初期用3D-CNN处理多时相Sentinel-2影像，想捕捉地表形变趋势。模型在训练集上表现惊艳，但部署到羌塘无人区新数据时，误报率飙升。后来带着光谱仪去现场采样才发现：模型把春季融雪形成的浅水洼（反射率类似水体）和真正的热融湖塘（指示冻土退化）混淆了。根本原因在于，3D-CNN只学到了“某类像素随时间变暗”的统计规律，却没嵌入“水体在短波红外波段具有强吸收”的物理约束。痛定思痛，我们重构了流程：先用物理模型计算地表温度日较差（ΔT），再将ΔT作为特征图输入轻量级网络。结果不仅精度提升，更重要的是——当某区域ΔT异常升高时，系统能直接输出“该处可能存在热融湖塘扩张”，而非冷冰冰的“类别3概率0.87”。物理可解释性不是学术装饰，而是业务方信任的基石。下次选算法前，务必自问：这个模型的决策依据，能否用一句初中地理知识说清楚？

2.3 时效维度：当“快”比“准”更救命

在应急响应场景，“算法精度”必须向“响应速度”让路。2022年四川泸定地震后，我们接到任务：2小时内给出震中20公里内道路中断评估。当时手头只有震后3小时获取的0.5米WorldView-3影像，但云量18%，且灾区地形起伏大，阴影严重。如果按常规流程做正射校正+语义分割，光预处理就要4小时。最后我们采用了一条“野路子”：用OpenCV快速提取影像梯度幅值图（强调边缘），结合已知道路矢量做缓冲区分析，再用形态学操作填充断裂。整个流程在笔记本电脑上11分钟跑完，虽然精度只有82%（专业解译员可达95%），但关键道路中断点全部命中，为救援队节省了黄金3小时。事后复盘，这个方案胜在三点：① 梯度图对云影干扰不敏感；② 缓冲区分析天然适配道路线状特征；③ 形态学操作比深度学习推理快两个数量级。

这种“降维打击”思维在业务中极其实用。比如做城市建筑高度反演，激光雷达点云精度最高，但获取成本高、周期长。我们给某市规自局做的方案是：用Google Earth历史影像+公开建筑轮廓矢量，通过阴影长度反推高度（利用太阳高度角公式h = L × tanα）。虽然单体误差±2.3米，但全市10万栋建筑的宏观分布特征完全可用，且成本为零。算法选型的终极标准，不是论文里的SOTA指标，而是业务场景的时间价值函数。画个简单的决策树：若任务窗口＜1小时→优先考虑传统图像处理；1小时~3天→可接受轻量级深度学习；＞3天→才值得投入复杂模型训练。

2.4 算力维度：服务器不是云厂商的宣传PPT

很多团队在GPU服务器上跑模型，却忘了看机房空调的制冷功率。我们曾接手一个省级林业局项目：用U-Net做松材线虫病枯死木识别。训练时用4块V100，batch size=16，一切顺利。但交付到地方林场时，对方只有一台旧工作站（GTX 1060 6GB + i5-6500）。模型直接OOM。重新裁剪网络后，推理速度仍需23分钟/平方公里，而林场要求单日处理全县2000平方公里——意味着机器要连续运转16天。最后解决方案是：把U-Net的编码器换成MobileNetV2，解码器简化为双线性插值+CRF后处理，精度损失1.8%，但单图推理从47秒压到1.2秒，整套系统在GTX 1060上稳定运行。

这里的关键洞察是：云端训练环境和边缘部署环境存在代际鸿沟。V100的Tensor Core对FP16计算加速明显，但GTX 1060连FP16都不支持。我们整理了一份实战算力对照表：

提示：永远在目标硬件上实测！我们曾因忽略T4的INT8加速特性，在未开启TensorRT时，模型推理慢了7倍。

2.5 业务维度：甲方爸爸要的不是热力图，是能钉钉打卡的结论

技术人常陷入“算法完美主义”，但业务方真正需要的是可行动的结论。去年帮某农业保险公司做玉米倒伏识别，他们不要“倒伏概率热力图”，而要“XX村XX地块倒伏面积≥3亩，建议启动理赔”。这意味着算法输出必须结构化：地块ID、经纬度、倒伏面积、置信度、时间戳。我们最初用Mask R-CNN输出掩膜，再叠加矢量边界，但保险公司的理赔系统只认Excel表格。最后妥协方案是：在模型后端加一层规则引擎——当掩膜面积＞3亩且置信度＞0.85时，自动生成标准理赔单（含地块照片、坐标、面积、时间水印），直接推送至保险公司OA系统。

这种“最后一公里”设计往往决定项目成败。另一个案例：某环保局要做工业园区排污口识别。深度学习模型能精准定位排污口，但环保执法需要的是“疑似排污口+周边企业名录+环评文件链接”。我们不得不把算法输出接入天眼查API和生态环境部公开数据库，构建了一个“识别-关联-溯源”流水线。算法只是链条中的一环，而业务闭环才是价值终点。所以选型时务必确认：你的算法输出格式，能否无缝对接下游业务系统？如果答案是否定的，要么改造算法输出，要么说服甲方升级系统——但后者成功率低于5%。

3. 实操决策框架：一张表、三步走、五验证

3.1 决策起点：用“地球观测算法选择表”锁定候选范围

我们团队内部用一张动态更新的决策表（见下表），它不追求理论完备，只解决“第一步该往哪走”。表格基于近五年37个真实项目复盘，按数据源、任务类型、精度要求三维交叉，给出推荐算法及关键限制条件。注意：所有推荐都标注了“适用前提”，这是血泪教训的结晶。

这张表的核心价值在于“排除法”。比如你手头是国产高分二号影像做水稻识别，看到“禁用RGB三通道输入”这条限制，就立刻明白：别费劲调ResNet的预训练权重了，老老实实去借一台野外光谱仪。算法选择的第一步，永远是看清数据的物理边界，而非挑战算法的理论上限。

3.2 三步验证法：用最小成本证伪错误方向

在正式训练前，我们坚持做三轮低成本验证，每轮不超过2小时，却能筛掉80%的无效尝试：

第一步：数据可分性验证（15分钟）
不用模型，只用PCA降维+散点图。取各类别样本各50个像元，提取所有波段值，PCA降到2维后画散点图。如果不同类别点团严重重叠（如水稻和池塘在PC1-PC2平面上混成一团），说明当前数据源和波段组合根本无法区分目标——此时上任何复杂算法都是徒劳。我们曾因此放弃用Sentinel-2做冬小麦/油菜分类，转而采购无人机多光谱数据。

第二步：基线模型验证（45分钟）
用sklearn一行代码跑RandomForest（n_estimators=100），输入特征为经典指数（NDVI、EVI、NDWI、SAVI）。记录OA（Overall Accuracy）。如果RF能达到85%以上，说明问题本质是可解的，后续可尝试深度学习；若RF＜75%，大概率是样本质量问题（标注错误/类别定义模糊），必须返工。

第三步：硬件可行性验证（20分钟）
在目标设备上跑一个简化版模型。例如计划用U-Net，就先用1/4通道数、1/2分辨率的mini-U-Net测试。重点监控：① 显存占用是否超限；② 单图推理时间是否满足SLA；③ 输出结果是否出现明显伪影（如边缘锯齿、块效应）。我们曾发现某ViT模型在T4上推理时，因CUDA版本不匹配，输出全是灰色块——这种坑必须在早期踩。

注意：这三步验证必须用真实业务数据，而非公开数据集。Kaggle上的EuroSAT数据再漂亮，也救不了你手头那批云遮了40%的影像。

3.3 五维交叉验证：确保算法在真实世界站得住脚

模型训练完成后，我们拒绝只看验证集指标，而是进行五维交叉验证，每维对应一个现实约束：

① 时间维度验证：用训练期外的数据测试。例如训练用2022年数据，必须用2023年同区域新影像测试。我们发现某水稻分类模型在训练年份OA=92.3%，但在2023年骤降至76.1%——原因是当年气候异常导致水稻生育期推迟12天，模型学到的“抽穗期光谱特征”完全失效。

② 空间维度验证：跨区域迁移测试。在A省训练的模型，必须在B省同类型地貌（如都是平原水田）测试。某次在江苏训练的模型，到湖南测试时精度暴跌，根源是两地土壤背景反射率差异大，模型过度依赖土壤-作物混合光谱。

③ 传感器维度验证：换数据源测试。用Landsat训练的模型，必须用Sentinel-2同区域影像测试。我们发现NDVI计算公式差异（Landsat用R/NIR，Sentinel-2用NIR/R）会导致0.05~0.12的系统性偏差，必须做辐射归一化。

④ 业务维度验证：请最终用户盲测。把模型输出图和专家解译图混在一起，让县农业局技术员标注“哪个更准”。曾有模型IoU达89%，但技术员反馈：“模型把灌溉渠标成河流，我们没法按这个发通知”。这直接推动我们在损失函数中加入“水系拓扑约束”。

⑤ 部署维度验证：全流程压力测试。从原始影像下载→预处理→模型推理→结果导出→GIS平台加载，记录每个环节耗时。某次发现90%时间耗在GDAL重投影上，最后改用rasterio的Warp API，整体提速3.2倍。

这五维验证不是形式主义，而是把实验室成果拽回泥土里的安全绳。每次项目结题报告，我们都会附上五维验证结果表，让甲方看到：这不是纸上谈兵，而是真刀真枪扛过现实考验。

4. 典型场景拆解：从云南咖啡园到长三角工厂的算法抉择实录

4.1 场景一：云南普洱咖啡园病害早期识别（小目标+弱信号）

业务需求：在叶片出现肉眼可见病斑前7-10天，识别炭疽病早期感染，以便精准喷药，减少农药用量30%以上。

数据现状：无人机多光谱影像（5cm分辨率），含绿、红、红边、近红外4波段；单景覆盖10亩，共采集23景；病害样本仅47个（因早期症状极不明显）。

算法抉择过程：

• 数据维度：5cm分辨率下，单片病叶仅占3-5个像素，属典型小目标。传统滑动窗口CNN感受野不足，易漏检。
• 物理维度：炭疽病早期导致叶绿素降解，红边波段反射率异常升高（文献证实+田间光谱仪验证）。
• 时效维度：农户需当天获取结果，无人机下午作业，系统需在次日早8点前推送报告。
• 算力维度：部署在县农技推广站的旧服务器（Xeon E5-2620 + GTX 1070）。
• 业务维度：输出需包含具体植株编号、感染概率、建议用药剂量（与当地农技手册联动）。

最终方案：放弃端到端分割，采用“物理引导+轻量检测”双轨制：

1. 先用红边波段与红波段比值（RENDVI）生成异常指数图，阈值设为1.8（经田间标定）；
2. 在异常区域用YOLOv5s检测病斑（输入为RGB+RENDVI四通道图，模型参数量压缩至1.2M）；
3. 后端关联GIS数据库，输出带坐标的Excel报告。

实测效果：单景处理时间8.3分钟（达标），早期识别准确率81.4%（专家评估），农药减量34%。关键心得：小目标检测的突破口不在网络结构，而在物理特征增强。我们试过ViT，虽mAP高2.1%，但推理慢17倍，且对光照变化更敏感——田间上午拍的影像，下午模型就失效。

4.2 场景二：内蒙古锡林郭勒草原退化评估（长时序+低信噪比）

业务需求：评估2015-2023年草原退化趋势，划分轻/中/重度退化区，支撑生态补偿资金发放。

数据现状：Landsat系列（TM/ETM+/OLI）30m影像，共127景；云量15%-65%不等；部分年份影像缺失；地面验证点仅32个（稀疏且分布不均）。

算法抉择过程：

• 数据维度：长时序但质量参差，深度学习需大量高质量标签，此处不可行。
• 物理维度：退化核心指标是植被覆盖度（FVC）和生物量，可通过NDVI时序曲线的振幅、积分值、变异系数量化。
• 时效维度：年度评估，无严格时限，但需保证结果可追溯。
• 算力维度：在阿里云ECS（8核16G）上离线运行，可接受较长计算时间。
• 业务维度：结果需符合《草原资源调查技术规程》，输出必须是栅格图+统计报表（各等级面积、变化率）。

最终方案：构建“物理模型驱动+统计验证”流水线：

1. 用Google Earth Engine批量计算每年最大NDVI（MaxNDVI）、生长季NDVI积分（IntNDVI）、NDVI标准差（StdNDVI）；
2. 将三指标输入随机森林（训练样本为32个验证点+专家知识规则生成的合成样本）；
3. 对分类结果用马尔可夫随机场（MRF）平滑，消除椒盐噪声；
4. 输出符合国标的退化等级栅格图（1:轻度，2:中度，3:重度）。

实测效果：与2023年地面普查结果对比，总体精度89.7%，Kappa系数0.82。关键心得：当样本稀缺时，用物理模型生成“软标签”，比硬凑深度学习更可靠。我们曾尝试用CycleGAN填补缺失年份影像，结果导致趋势误判——GAN生成的“假数据”放大了噪声，而物理指标计算天然抗噪。

4.3 场景三：长三角某市工业用地动态监测（高精度+强监管）

业务需求：每月监测全市工业用地变化，识别新增厂房、拆除地块、违规硬化地面，误差≤0.5亩，结果用于自然资源执法。

数据现状：国产高分一号（2m）+高分六号（16m）融合影像；月度更新；存在大量相似干扰（如停车场vs厂房屋顶、水泥路vs违规硬化）。

算法抉择过程：

• 数据维度：2m分辨率下，厂房轮廓清晰，但需区分材质（金属顶vs彩钢顶反射率差异小）。
• 物理维度：工业用地核心特征是几何规则性（长方形/正方形）+光谱稳定性（金属顶近红外反射率高且稳定）。
• 时效维度：每月10日前完成，允许3天处理窗口。
• 算力维度：市级大数据中心GPU集群（A100×4），算力充足。
• 业务维度：结果需对接“国土调查云”系统，输出必须为带属性的矢量面（含变化类型、面积、时间）。

最终方案：“多尺度特征融合+规则后处理”：

1. 用HRNet提取多尺度特征（捕获厂房轮廓+材质细节）；
2. 解码器输出三类：新增建筑、拆除地块、硬化地面；
3. 后处理强制注入规则：① 新增面必须邻接道路（缓冲区分析）；② 面积＜0.5亩自动过滤；③ 硬化地面需满足“近红外波段反射率＞0.25且变异系数＜0.08”。

实测效果：变化图斑召回率94.2%，虚警率6.3%（执法部门接受阈值为8%），矢量面平均偏移0.8米（满足0.5亩精度）。关键心得：在强监管场景，算法必须接受业务规则的“硬约束”，而非追求纯粹数据拟合。我们曾去掉规则后处理，虚警率升至15.7%，大量把大型广告牌误判为新增厂房——而规则引擎一句“广告牌不邻接市政道路”就解决了。

5. 血泪教训总结：那些让我们彻夜难眠的算法陷阱

5.1 “数据增强幻觉”陷阱：当旋转翻转创造的不是鲁棒性，而是虚假自信

新手最爱用Albumentations做数据增强：随机旋转、水平翻转、亮度抖动……我们团队曾在一个山地果园分类项目中，把训练集增强10倍，模型验证集IoU飙到91.3%。交付时，甲方用新采集的影像测试，精度断崖式跌到63.2%。排查三天才发现：增强时用了“随机旋转”，但果园梯田是沿等高线修建的，真实影像中果树行列永远平行于坡度方向。模型学到的不是“果树光谱特征”，而是“某类纹理在特定角度下的排列模式”。当新影像因飞行姿态微小偏差导致角度偏移2°，模型就彻底懵圈。

避坑指南：

• 山地场景禁用旋转增强，改用“沿坡向裁剪+高程图融合”；
• 城市场景禁用随机缩放，因建筑高度导致的透视畸变有固定规律；
• 所有增强操作必须有物理依据：比如SAR影像可加Speckle噪声（模拟真实斑点），但绝不能加高斯模糊（真实SAR没有此噪声）。

5.2 “预训练权重依赖症”陷阱：当ImageNet的猫狗，成了遥感解译的绊脚石

很多团队直接加载ResNet50的ImageNet预训练权重，认为“迁移学习万能”。我们在黄河三角洲湿地鸟类栖息地识别项目中栽过大跟头。用ImageNet权重初始化的模型，在训练集上收敛极快，但泛化极差。可视化特征图发现：模型重点关注影像中的“纹理粗糙度”，而湿地鸟类栖息地的关键判据是“水深梯度”和“挺水植物密度”——前者需NDWI指数，后者需红边波段。ImageNet权重学到的“纹理感知”能力，反而抑制了模型学习水体光谱特征。

避坑指南：

• 遥感专用预训练：用大规模无标签遥感影像（如EuroSAT、UC Merced）自监督预训练；
• 波段适配：ImageNet是RGB三通道，遥感常为4-10波段，必须重写第一层卷积（如将3通道扩展为4通道，权重按比例分配）；
• 宁可从零训练小模型，也不用错位的大模型。我们后来改用EfficientNet-B0从头训练，虽收敛慢，但最终精度高出3.7%。

5.3 “端到端迷思”陷阱：当执着于“一张图输入，一张图输出”，却忘了中间过程才是业务价值

某次做城市热岛效应分析，客户明确要求“输出地表温度分布图”。团队花了两个月开发端到端网络：输入RGB影像，输出温度栅格。结果交付时，气象局专家指着图说：“这温度值没经过物理反演，不能用于科研”。原来，业务方真正需要的是“温度反演算法的中间产品”——大气透过率、地表发射率、辐射定标系数，这些参数才能支撑后续气候模型。而我们的端到端模型把这些全黑箱化了。

避坑指南：

• 强制模型输出物理可解释中间变量：如热红外反演中，让网络同时输出“大气水汽含量估计值”和“地表发射率图”；
• 用物理损失函数约束：在温度预测损失外，增加“发射率应在0.92-0.98区间”的L1约束；
• 永远问一句：业务方是否需要调用中间结果？如果答案是肯定的，端到端就是毒药。

5.4 “开源即正义”陷阱：当GitHub明星项目，成了生产环境的定时炸弹

我们曾引入一个Star 2.1k的遥感变化检测库（ChangeFormer），文档写得天花乱坠。实际部署时发现三大坑：① 依赖PyTorch 1.12，而生产环境是1.10（升级会崩坏其他系统）；② 默认用FP16推理，但某些老旧GPU不支持；③ 作者把“云检测模块”写死在代码里，而我们用的是SAR影像，根本不需要云检测。为修这些坑，团队耗时11人日，远超自研一个简化版ChangeNet。

避坑指南：

• 开源项目引入前，必须做“三查”：查依赖兼容性、查硬件支持列表、查核心模块可替换性；
• 所有开源代码必须封装为Docker镜像，并在目标环境完整测试；
• 生产环境宁用“丑但稳”的自研代码，不用“美但脆”的明星项目。我们现在的标准是：若开源项目修改量＞30%，直接重写。

5.5 “指标至上主义”陷阱：当验证集上的99%准确率，掩盖了业务场景的致命缺陷

最讽刺的案例发生在某港口集装箱识别项目。模型在验证集上达到99.2%准确率，交付后第一天就出事：把一艘停泊的货轮识别为“新增集装箱堆场”，触发错误预警。原因是验证集全是白天影像，而港口24小时作业，夜间红外影像中，货轮甲板与集装箱堆场的热辐射特征几乎一致。模型学到的“高亮矩形区域=集装箱”，在夜间完全失效。

避坑指南：

• 验证集必须覆盖全时段、全天气、全季节；
• 关键业务指标必须单列：如“夜间识别准确率”、“雨雾天召回率”、“小目标（＜10像素）检测率”；
• 永远用业务失败案例反向构造测试集。我们后来专门收集了500张夜间/雨雾影像，组成“灾难测试集”，任何模型未在此集上达标，一律否决。

6. 经验沉淀：我的个人算法选型检查清单

干了十多年地球观测，我给自己定了一个铁律：任何算法在进入训练环节前，必须通过这份清单的全部12项审查。它不是理论框架，而是用无数个通宵和甲方投诉换来的生存法则。现在分享给你，少走三年弯路。

数据可信度审查（4项）
□ 是否完成基础质检？云量、辐射校正状态、配准误差已量化记录（非“目视检查”）
□ 训练样本是否覆盖全时空维度？（如水稻分类需包含早稻/晚稻、旱作/水田、不同肥力水平）
□ 是否存在系统性偏差？（如某传感器批次的红波段响应率整体偏低，需单独校准）
□ 数据增强是否符合物理规律？（禁止对SAR影像加高斯模糊，禁止对多光谱影像随机丢波段）

物理可解释性审查（3项）
□ 模型决策依据能否用一句初中地理/物理知识描述？（如“水体在短波红外波段吸收强”）
□ 是否嵌入了领域先验知识？（如城市建筑高度反演中，强制加入太阳高度角约束）
□ 中间特征图是否可被领域专家解读？（如NDVI时序曲线比Transformer注意力图更易懂）

部署可行性审查（3项）
□ 是否在目标硬件上实测单图推理时间？（非“理论计算FLOPs”）
□ 显存占用是否留有20%余量？（避免因系统进程占用导致OOM）
□ 输出格式是否与下游系统API完全兼容？（字段名、坐标系、时间戳格式逐项核对）

业务闭环审查（2项）
□ 最终输出能否直接驱动业务动作？（如“倒伏面积＞3亩”触发理赔，“新增厂房”触发执法巡查）
□ 是否有机制应对模型失效？（如当置信度＜0.7时，自动转人工审核并告警）

这份清单没有高大上的术语，每一条都指向一个可能让你凌晨三点被电话叫醒的具体风险。我建议你打印出来，贴在显示器边框上。每次想跑python train.py前，先拿起笔，一项项打钩。地球观测的魅力，不在于算法有多炫，而在于你能让卫星看见的真相，真正改变脚下这片土地。最后分享个小技巧：当所有条件都满足却还在纠结时，就选那个文档最全、社区最活跃、issue里最多人在吐槽“我遇到同样问题”的方案——因为真实世界的坑，永远比论文里的多。