“下载影像、算 NDVI、出一张图”适合由 QGIS 对话助手协助，但它涉及外部数据、空间分析与地图发布，不能把一段自然语言直接变成不可见的后台行为。GeoGenie 的 README 描述了一种更可审查的路线：用户提出请求后，插件先给出计划，获得批准后才执行；每次运行写出独立的 PyQGIS 流水线和上下文文件，方便重跑、修改与审核。
可核查事实
- GeoGenie README 将项目称为 QGIS 的 AI 驱动 GIS 自动化插件。
- README 说明，一次对话产生一个计划和一次运行，插件在执行前展示准确计划并等待用户批准。
- 插件可下载 Copernicus Data Space 的 Sentinel-1、Sentinel-2，USGS EarthExplorer 的 Landsat，以及 NASA Earthdata 的 ASTER 数据。
- 它可拉取 OpenStreetMap 的建筑、道路、水体和边界数据。
- README 列出 NDVI、NDWI 与基于前后 Sentinel-1 对的基础 SAR 洪水检测等空间分析能力。
- 每次运行保存独立 Python 脚本和上下文文件；脚本不依赖插件自身，可独立重跑、修改或调度。
- README 强调无自动安装、无后台服务、无静默网络调用；凭据保存在 QGIS 设置命名空间，不写入生成脚本或上下文文件。
核心机制：先展示计划，再产生可复跑的流水线
对话是入口，不是执行授权。GeoGenie 将用户请求转为计划并在执行前展示；这种分界使用户能发现 AOI、时间窗、数据源、分析方法和输出格式是否符合预期。对遥感任务而言，这比“结果生成后再解释”更重要，因为下载何种影像、使用哪些波段和如何裁剪都会改变结论。
运行后的独立脚本同样是关键产物。它将一次对话驱动的操作变成可读、可重跑、可改的 Python 流水线；即使不再使用插件或 QGIS，也能审查所做的步骤。这样，自动化不再是会话历史中的一次性魔法，而是一份可纳入版本管理和质检的工程资产。
GIS 场景：从试验性对话到受控生产任务
在部门试点中，建议将“影像获取—预处理—指数计算—图层输出—地图布局”拆为计划卡上的明确步骤，并要求用户确认数据源、日期、AOI、云量或前后时相、计算方法和输出位置。完成后，地图、日志和独立脚本应一同归档，供复查或下次更新使用。
对于洪水、生态或土地覆盖任务，基础 SAR 差分与 NDVI/NDWI 只能生成候选信息。平台应在输出中标明方法边界、影像日期和数据质量，不让自动生成布局掩盖分析假设。生成的调度脚本也应由运维人员显式注册，不能由插件自行常驻运行。
技术路径
- 将自然语言请求解析为可编辑计划：数据源、范围、时间、分析、输出和风险提示。
- 执行前显示计划并获取用户批准；任何网络下载和外部服务调用都在批准后发生。
- 将每次运行输出为独立脚本、上下文、日志、空间图层和地图文件。
- 在脚本开头检查路径、磁盘空间和网络连通性，并将失败原因写入进度记录。
- 将凭据仅从受控设置或环境变量读取，禁止写入脚本、上下文和交付包。
- 对重复运行由操作系统调度器显式注册，并为高影响任务保留人工签核点。
检查清单
- 用户是否在任何下载或分析前看到了完整计划并明确批准？
- 影像、指数、裁剪和制图步骤是否生成可独立执行的脚本？
- 输出能否回链到数据源、日期、参数、日志与地图图层？
- 凭据和访问令牌是否完全排除在脚本与产物之外？
- 低复杂度洪水检测等结果是否被标记为候选，而非正式灾情结论？
风险边界
GeoGenie README 描述的能力不等于某次影像分析的准确性。外部数据服务、免费账户、云量、传感器差异和基础阈值方法都会限制结果；SAR 差分洪水检测不等同于校准的水文产品。计划审批和可复跑脚本能提高可审计性，却不能替代专业分析、数据许可审查和现场验证。
资料依据
本文依据 GeoGenie GitHub README 撰写。计划批准、影像与 OSM 数据来源、NDVI/NDWI/SAR 功能、独立脚本、无后台服务和凭据处理说明均来自 README；试点与审批流程为 GIS 部署建议。
结论
QGIS 对话自动化的可信度不在于它能否一键出图，而在于用户能否在执行前批准、执行后重跑，并对每个数据与分析步骤负责。把这三件事留在流程里，AI 才能成为可控的 GIS 助手。