语义无关，地理致命：AI Agent 自动化 GIS 流程中的 CRS 与重采样硬门禁设计

一、问题的提出：当“参数”变成“事故”

1.1 一个被反复复现的失败模式

设想这样一个任务描述：“把这份省级行政区划数据裁剪到研究区范围，统一到投影坐标系，然后统计各区县面积。”对人类 GIS 工程师而言，这句话里藏着至少五个必须显式确认的决策点：源数据 CRS 是否可信、目标 CRS 选哪个投影带、裁剪前是否需要先重投影、面积统计用平面坐标还是椭球面、栅格重采样用最近邻还是双线性。而对一个由 LLM 编排的 Agent 来说，这句话在语义上是“完整”的——它没有歧义、没有缺词、没有语法错误，模型完全可以在不追问任何问题的前提下生成一段看起来专业的 Python 代码。

这正是危险的来源。自然语言的“完整性”与地理计算的“正确性”之间不存在等价关系。CRS 的 EPSG 编码、轴序（axis order）、基准面（datum）、投影参数，以及重采样的核函数与像元对齐规则，在句子里往往只是一个变量名或一个默认值，语义权重极低；但它们在数值结果上的影响却可能是数量级的。笔者把这类参数称为“语义无关、地理致命”参数——它们在语言层面近乎透明，在计算层面却是一票否决。

本文的核心命题是：对这类参数，正确性不能交给概率模型去“记住”，只能交给确定性代码去“强制”。LLM 可以决定“要做什么”，但不能决定“参数对不对”。

1.2 为什么现在必须讨论这个问题

过去两年，GIS 领域的 Agent 化进展明显加速。一方面，GDAL/OGR、PROJ、Rasterio、GeoPandas、Shapely 等库的 Python API 已经足够稳定，使得 LLM 生成可执行地理处理代码的门槛大幅降低；另一方面，QGIS 的 Processing 框架、ArcGIS 的 ArcPy、以及一批云端地理计算服务都开始提供自然语言接口或 MCP（Model Context Protocol）式的工具调用封装。2024 年以来，围绕“LLM + 地理空间工具调用”的研究与工程实践密集出现，GeoAI 社区开始系统讨论基础模型在地理空间推理上的可靠性问题（相关综述可参考 Janowicz 等人在 IJGIS 上关于 GeoAI 与基础模型的系列讨论，以及 2023—2025 年间多篇关于 LLM 空间推理评测的论文）。

与此同时，评测结果并不乐观。多项针对 LLM 空间推理与地理知识基准的评测显示，模型在“地理常识问答”上表现尚可，但在需要精确坐标变换、拓扑判断、单位换算的任务上错误率显著上升；尤其当任务涉及“默认值选择”时，模型倾向于输出训练语料中高频出现的参数，而非当前数据条件下正确的参数。笔者认为，这一现象的根源不是模型“不够聪明”，而是这类任务的正确性信号根本不在语言分布里，而在数据本身的元数据与坐标几何里。指望通过 prompt 工程把“永远检查坐标系”变成模型的稳定行为，本质上是在用一个概率性约束去替代一个确定性约束，其可靠性上限受限于模型的指令遵循稳定性，而非任务本身的难度。

1.3 本文的分析主线与结构

本文不打算泛泛讨论“AI 会不会取代 GIS 工程师”，而是聚焦一个可证伪、可工程化的具体问题：在自动化流程中，CRS 一致性检查与重采样方法选择，应当做成不可绕过的硬门禁，还是可以依赖 LLM 在 prompt 中被教会？围绕这条主线，第二节拆解误差机制，说明“致命”到底致命在哪里、量级如何；第三节评估 LLM 的能力边界，给出“为什么教不会稳定”的机制性解释；第四节提出硬门禁的分层架构；第五节给出可落地的检查清单、代码与验证方法；第六节讨论代价、边界与反模式；第七节收束结论并展望演进方向。

二、误差机制解剖：CRS 与重采样为何“语义无关、地理致命”

2.1 CRS 误配的三种典型形态

坐标参考系（Coordinate Reference System, CRS）是对“坐标数值如何映射到地球表面位置”的完整定义，包含基准面、椭球、投影方法、参数、单位与轴序。工程实践中，CRS 误配并非单一错误，而是至少三种性质不同的形态，其后果也各不相同。

第一种是“缺失定义”：数据本身带有坐标数值，但元数据中 CRS 为空或被错误标注为 WGS84。此时若直接按经纬度处理，数值可能“看起来合理”（例如落在 100—120 之间），但实际可能是某个投影坐标系下的米制坐标，量级完全错位。这类错误在 Shapefile 时代极为常见——.prj 文件缺失或被随意替换，是 GIS 数据交换中的经典顽疾。

第二种是“投影选择不当”：数据 CRS 定义正确，但目标投影与研究区不匹配。等积投影、等角投影、等距投影各有其保真属性，选错类别会导致系统性偏差。以中国区域为例，常用的 Albers 等积投影需要针对研究区设置中央经线与标准纬线；若直接套用全国参数去计算一个地级市的面积，边缘区域的面积变形虽不至于夸张，但在跨带、跨纬度的大范围统计中会累积成可观误差。Web Mercator（EPSG:3857）则是另一个高频陷阱：它在低纬度地区面积变形尚可接受，但在中高纬度会急剧放大，把 EPSG:3857 下的面积当作真实面积使用，是自动化脚本中最常见的“静默错误”之一。

第三种是“基准面/轴序错配”：不同大地基准面之间的转换需要七参数或网格移位文件，缺失时 PROJ 会退化为近似转换，误差可达米级；而轴序问题（例如 EPSG:4326 官方定义为纬度在前、经度在后）在手工调用底层库时极易颠倒，导致点位“镜像”或落在错误半球。这类错误的特点是局部看起来完全正常、全局统计彻底失真，非常难以通过肉眼抽查发现。

关于“40% 面积偏差”这个量级，需要做一个严谨的说明：它不是一个普适常数，而是特定条件下的结果。以 Web Mercator 为例，其面积放大因子近似为 1/cos²(φ)，在纬度 30° 处约为 1.33（即偏大 33%），在纬度 40° 处约为 1.70（偏大 70%），在纬度 50° 处约为 2.42。也就是说，“40% 偏差”大致对应中纬度地区使用 Web Mercator 计算面积的典型情形，这一估算可由上述解析式直接验证，属于可复现的数学结论而非经验臆测。读者可用任意投影库对同一多边形在 EPSG:3857 与等积投影下分别求面积进行交叉验证。

2.2 重采样：核函数选择如何“制造”假高程

重采样（resampling）是把栅格从一种网格（分辨率、范围、投影、对齐方式）映射到另一种网格的过程，其本质是对像元值做局部加权估计。常见方法包括最近邻（nearest）、双线性（bilinear）、三次卷积（cubic）、面积平均（average）、众数（mode）等。方法选择不是“精度高低”的单调排序，而是与数据类型和后续用途强耦合的匹配问题。

对于分类栅格（土地利用、地表覆盖、行政区划栅格化结果），最近邻是唯一不引入新类别的方法；双线性或三次卷积会在类别边界处产生“中间值”，把类别 3 和类别 5 插值成 4，制造出原本不存在的类别。对于连续栅格（DEM、温度、降水），最近邻虽然保真于原始值，但会引入块状伪影并在坡面上产生阶梯状高程，进而影响坡度、流向、汇流累积量等派生计算；双线性在平滑区域表现良好，但在陡崖、河道等高频区域会低估极值。对于 DEM 这类数据，用错核函数产生的不是“精度损失”，而是“结构失真”——坡度被系统性低估、河网被错误连通，这类误差会沿着水文分析链条逐级放大。

“假高程”这个说法需要精确化。严格来说，重采样不会凭空创造超出原始值域的高程（双线性与三次卷积是加权平均，结果落在局部极值之间；三次卷积在特定核下可能出现轻微过冲，但通常有截断处理）。真正的问题在于：重采样后的像元值不再对应原始观测，而是对应一个“被平滑过的、位置偏移的”估计值，而下游流程往往把它当作真实观测使用。当重采样与投影变换叠加时，像元中心发生位移，双线性插值会在坡面上产生与真实地形不符的平滑面；当重采样用于多源 DEM 融合时，不同核函数引入的系统性偏差会在拼接缝处形成“台阶”或“脊线”，这些结构在后续的坡度、曲率计算中会被放大为虚假地形特征。笔者认为，把这一现象称为“结构性假信号”比“假高程”更准确，但工程语境下“假高程”这个说法更直观，本文两者混用，特此说明。

2.3 误差传播：为什么单点错误会变成系统性失效

GIS 流程的典型特征是“链式依赖”：裁剪依赖 CRS 对齐，重投影依赖源 CRS 正确，重采样依赖目标网格定义，统计依赖前三步全部正确。这意味着误差不是独立叠加，而是沿链条单向传播并可能被放大。一个在第一步被忽略的 CRS 缺失，会在重投影时被默认值“填补”，在重采样时被网格错位“固化”，最终在统计结果里表现为一个看似合理、实则错误的数字。更麻烦的是，这条链上的中间产物往往不会被人工检查——Agent 输出的是一段代码和一份最终报表，中间 GeoTIFF 和 GeoPackage 被写入临时目录后即被清理。

笔者认为，这正是 Agent 化流程与人工流程在风险结构上的根本差异。人工流程中，工程师在每一步都会“看一眼”，这种非正式的、低成本的检查实际上承担了大量错误拦截；而 Agent 流程把这些检查点全部省略了，只保留了输入和输出。如果没有显式的门禁，Agent 流程的可靠性不会高于“无检查的批处理脚本”，而后者在 GIS 工程中早已被证明是不可靠的。

三、LLM 的能力边界：它到底能“记住”多少地理常识

3.1 三类任务，三种可靠性

要回答“能不能靠 prompt 教会”，首先要区分 LLM 在 GIS 任务中承担的三种不同职能。第一类是意图解析：把“统计各区县面积”翻译成“读取矢量、按行政编码分组、计算几何面积、汇总输出”。这类任务依赖语言理解与工具调用编排，LLM 表现良好，且错误通常可被后续步骤暴露。第二类是知识检索：回答“中国常用的等积投影是哪个”“EPSG:4490 是什么坐标系”。这类任务依赖训练语料中的地理知识密度，模型在常见概念上尚可，在冷门投影、地方坐标系、历史基准面上错误率明显上升。第三类是参数决策：在当前数据的具体条件下，选择正确的目标 CRS、正确的重采样方法、正确的轴序处理方式。这类任务的正确性取决于数据元数据与几何特征，而非语言分布，LLM 缺乏可靠的信息来源。

本文评述：三类任务中，第一类是 LLM 的强项，第二类是“看起来能用但不可靠”，第三类是“结构性不可靠”。问题在于，在自然语言接口下，用户往往把三类任务混在一句话里交给 Agent，而 Agent 也不会主动区分。一个负责任的架构应当明确：第一类交给 LLM，第二类交给知识库检索（RAG）并标注置信度，第三类交给确定性规则引擎。把第三类也交给 LLM，等于用语言模型去猜数据，这在工程上是不可接受的。

3.2 为什么“在 prompt 里写死规则”不可靠

一个常见的反驳是：只要在系统提示里写清楚“每次操作前必须检查 CRS 是否一致、必须根据数据类型选择重采样方法”，模型就会照做。这个推理在简单任务、短上下文、单轮交互下有一定效果，但在真实工程条件下会迅速失效，原因有四。

其一是指令衰减。随着对话轮次增加、工具返回结果变长、上下文被中间产物填满，系统提示的约束力会被稀释。这是长上下文模型的已知行为特征，在多步 Agent 流程中尤为明显。即便模型“记得”规则，也可能在生成具体代码时把规则简化为一个注释而非实际检查。

其二是规则与数据的脱节。“检查 CRS 是否一致”这句话本身不包含“不一致时怎么办”的完整决策树。是报错终止、自动重投影、还是询问用户？如果自动重投影，目标 CRS 怎么选？这些分支需要数据条件驱动，而 prompt 只能给出抽象原则。模型在具体分支上仍然要做概率性选择。

其三是无法验证。即使模型在代码里写了 if src_crs != dst_crs: 这样的检查，这个检查是否正确、是否覆盖了轴序、是否处理了 None 值，仍然需要人来审查。换句话说，prompt 约束把“检查参数”变成了“检查模型有没有写检查”，问题只是被转移了，没有被消除。

其四是不可审计。监管与科研场景要求结果可复现、决策可追溯。依赖 prompt 的行为约束无法给出“为什么这一步选择了这个参数”的确定性证据，只能给出模型的自然语言解释，而解释本身也可能是事后编造的。这在需要质量保证的工程交付中是硬伤。

笔者认为，prompt 约束的本质是“用自然语言表达的程序逻辑”，它继承了自然语言的全部模糊性，却失去了程序语言的确定性。对于“语义无关、地理致命”的参数，这种交换是不划算的。

3.3 一个可操作的判据：参数是否“可从数据推导”

为了把上面的讨论变成可操作的工程判据，笔者提出一个简单的二分法：如果一个参数的正确值可以从数据本身（元数据、几何、值域、分布）确定性地推导出来，那么它就不应该由 LLM 决定；如果一个参数的正确值依赖于用户意图、业务规则或外部知识，那么它可以由 LLM 辅助解析，但仍需人工或规则确认。

按此判据，源数据 CRS 属于第一类（从元数据读取，读不到就报错，不能猜）；目标 CRS 属于第二类（依赖研究区与用途，可由规则库给出候选，LLM 辅助选择但需确认）；重采样方法属于第一类与第二类的混合（数据类型可从元数据与值域分布判断，用途需用户确认，但“分类数据不能用双线性”这条是硬规则）。这个判据的价值在于，它把“要不要信任 LLM”这个模糊问题，转化成了“这个参数的信息来源在哪里”这个可核查的问题。

四、硬门禁架构：把正确性从概率模型手里拿回来

4.1 分层设计：LLM 做编排，门禁做裁决

硬门禁（hard gate）在这里的定义是：一段确定性代码，在流程的关键节点对关键参数做强制校验，校验不通过则流程终止或降级，且该代码路径不可被 LLM 绕过或修改。它与“在 prompt 里提醒模型”有本质区别：前者是执行环境的约束，后者是模型行为的期望。

一个可落地的分层架构包含四层。第一层是意图层，由 LLM 负责，把用户自然语言解析为结构化的任务描述（操作类型、输入数据、期望输出、业务约束），输出必须是 schema 校验过的 JSON，而不是自由文本。第二层是参数解析层，由确定性代码负责，从数据元数据、规则库、配置文件中解析出所有“语义无关、地理致命”参数，LLM 不得直接写入这些字段。第三层是门禁层，在每次地理操作前后执行检查，包括 CRS 一致性、轴序、单位、重采样方法与数据类型的匹配、输出范围合理性等。第四层是执行与审计层，调用 GDAL/PROJ 等底层库执行，并记录完整的参数快照与检查结果，供复现与追责。

这个架构的关键设计是“LLM 只能写意图，不能写参数”。LLM 可以决定“要重投影到等积投影”，但不能决定“EPSG 编码是多少”；可以决定“要重采样”，但不能决定“用哪个核函数”。后两者由规则引擎根据数据类型、研究区范围、用户显式指定的约束来确定。这样做的代价是灵活性下降，收益是正确性从“概率保证”变成“确定性保证”。

4.2 门禁的三种强度与触发时机

门禁不是越严越好，过严会导致流程频繁中断、用户体验下降，最终被使用者绕过。笔者建议按后果严重性设置三档强度。阻断级（block）：参数缺失、CRS 无法解析、分类数据被要求用插值重采样、目标 CRS 与数据范围明显不匹配。这类问题一旦放过必然产生错误结果，必须终止并给出修复建议。告警级（warn）：源 CRS 存在但置信度低（例如从文件名推断而非元数据读取）、目标投影与数据范围跨带、重采样方法为默认值而非显式指定。这类问题可能正确也可能错误，需要记录并提示用户确认。记录级（log）：所有参数快照、库版本、PROJ 数据版本、检查结果。这一档不中断流程，但为事后审计与问题复现提供依据。

触发时机同样重要。门禁应当放在数据读取之后、任何几何操作之前（前置门禁），以及输出写入之前、结果返回之后（后置门禁）。前置门禁拦截“输入有问题”，后置门禁拦截“处理过程引入了问题”。两者缺一不可：只有前置门禁，无法发现重投影过程中的轴序错误；只有后置门禁，错误已经发生，只能事后补救。

4.3 与 Agent 框架的集成方式

在工程实现上，门禁不应作为“建议”塞进 prompt，而应作为工具调用的强制中间件。具体做法是：不向 LLM 暴露原始的 GDAL 或 Rasterio 函数，而是暴露封装后的“安全工具”，这些工具内部先执行门禁，再执行实际操作。LLM 看到的工具描述是“重投影矢量数据（自动校验 CRS）”，它无法选择跳过校验，因为校验不在它的控制范围内。

这种设计在 MCP（Model Context Protocol）风格的工具体系中尤其自然：工具的实现方（服务端）负责正确性，调用方（模型）负责意图。笔者认为，这是当前 Agent 工程中最被低估的一条原则——把正确性下沉到工具实现，而不是上浮到模型提示。GIS 领域尤其适合这样做，因为底层库（PROJ、GDAL）本身已经提供了丰富的校验能力，只是过去没有人把它们组织成门禁。

延伸阅读方面，PROJ 官方文档对坐标变换与轴序有详细说明，GDAL 的 gdalwarp 文档对重采样方法有完整列表与适用场景说明，QGIS 文档的“Coordinate Reference Systems”章节对工程实践中的常见陷阱有清晰梳理。这些都是一手资料，建议直接阅读而非依赖二手总结：PROJ 投影与变换文档、GDAL gdalwarp 文档、QGIS CRS 入门。

五、工程落地路径：检查清单、代码与验证方法

5.1 CRS 一致性检查清单

下面这份清单是笔者在实际项目中反复打磨的版本，按“读取—校验—决策”三段组织。每一条都对应一个可执行的代码检查，而不是一句原则性描述。

读取段：① 从数据元数据读取 CRS，而非从文件名或目录结构推断；② 检查 CRS 是否为 None 或空字符串，是则阻断；③ 检查 CRS 是否为“本地坐标系”或自定义 WKT，是则要求用户提供权威定义；④ 记录 CRS 的 EPSG 编码、名称、轴序、单位，写入审计日志。

校验段：⑤ 检查坐标范围是否与 CRS 类型匹配（地理坐标系应在 -180~180 / -90~90 内，投影坐标系应在合理米制范围内）；⑥ 检查轴序是否与库的默认约定一致，必要时显式指定 always_xy=True；⑦ 检查基准面转换是否需要网格文件，缺失时降级为告警并记录；⑧ 检查多图层叠加时 CRS 是否一致，不一致则阻断并要求显式指定目标 CRS。

决策段：⑨ 面积/距离统计必须使用等积/等距投影，禁止在 EPSG:3857 或 EPSG:4326 下直接计算平面面积；⑩ 目标投影的选择应基于研究区范围与用途，由规则库给出候选，LLM 仅可辅助排序；⑪ 跨带数据必须分带处理或使用覆盖全区的自定义投影；⑫ 所有决策连同依据写入审计日志。

5.2 重采样方法选择规则

重采样方法的选择应当由“数据类型 + 后续用途”两个维度共同决定，且第一条规则是硬性的：分类数据禁止使用任何会产生新值的插值方法。数据类型可以从元数据（波段类型、值域、唯一值数量）与用户标注中判断；后续用途需要用户显式说明或从任务描述中解析。当两者冲突时（例如用户要求对分类数据做双线性重采样），门禁应阻断并解释原因，而不是顺从用户。

对于连续数据，还需要考虑“是否用于派生计算”。如果重采样后的 DEM 要用于坡度、流向计算，最近邻的阶梯伪影会污染结果，应优先双线性或三次卷积；如果用于极值统计（如最高点海拔），则应避免任何平滑，必要时用最近邻并接受块状伪影。这个决策无法由 LLM 从一句话中可靠推断，必须由用户显式指定或由规则库根据下游任务类型给出。

5.3 参考实现片段

下面是一段简化的门禁实现，用 Python 与 Rasterio/PyProj 演示核心逻辑。它不是一个完整库，而是展示“门禁如何嵌入工具”的最小骨架。

from pyproj import CRS
import rasterio

BLOCK, WARN, LOG = "block", "warn", "log"

def check_crs(src_path: str) -> list:
    issues = []
    with rasterio.open(src_path) as ds:
        crs = ds.crs
        if crs is None:
            issues.append((BLOCK, "CRS 缺失，禁止继续"))
            return issues
        c = CRS.from_wkt(crs.to_wkt())
        if c.is_geographic:
            b = ds.bounds
            if not (-180 <= b.left <= 180 and -90 <= b.bottom <= 90):
                issues.append((BLOCK, f"地理坐标系范围异常: {b}"))
        elif c.is_projected:
            if abs(ds.bounds.left) < 1000 and abs(ds.bounds.bottom) < 1000:
                issues.append((WARN, "投影坐标量级异常，疑似 CRS 误标"))
        issues.append((LOG, f"CRS={c.to_string()}, axis={c.axis_info}"))
    return issues

def choose_resampling(dtype: str, purpose: str) -> str:
    if dtype == "categorical":
        return "nearest"          # 硬规则，不可覆盖
    if dtype == "continuous":
        if purpose in ("slope", "flow", "hydrology"):
            return "bilinear"
        if purpose == "extremum":
            return "nearest"
        return "bilinear"
    raise ValueError("未知数据类型，阻断")

这段代码的关键不在实现细节，而在结构：检查函数返回的是“问题列表 + 严重级别”，而不是布尔值。这样上层可以按级别决定阻断、告警还是记录，而不是一刀切。另外，choose_resampling 中分类数据的分支直接返回，不提供任何参数覆盖入口——这是刻意的设计，目的是让“错误选择”在代码层面不可能发生。

5.4 验证方法：如何证明门禁有效

门禁本身也需要验证，否则只是增加了复杂度而没有增加可靠性。笔者建议三种验证手段并用。其一是故障注入测试：构造一批“已知错误”的数据（CRS 缺失、轴序颠倒、分类数据、跨带范围），验证门禁能否在正确的位置以正确的级别拦截。这是一套可自动化的回归测试，应当纳入 CI。其二是对照实验：对同一批数据，分别用“无门禁的 LLM 直出代码”和“带门禁的安全工具”处理，比较结果差异与错误率。这类实验可以用公开数据集（如 Natural Earth、OpenStreetMap 导出、Copernicus DEM 样本）进行，结果可复现。其三是审计回溯：定期抽查审计日志，检查是否存在“告警被忽略”“阻断被人工绕过”的情况，评估门禁的实际执行率。

关于数据集与预处理，需要说明的是：本文引用的公开数据源（Natural Earth 矢量、Copernicus DEM 30m 样本、ESA WorldCover 分类栅格）在使用前均需做统一预处理——矢量数据应检查 .prj 完整性并统一到 EPSG:4326 作为中间格式；DEM 样本应裁剪到研究区并检查 NoData 值；分类栅格应确认类别编码表与值域一致。这些预处理步骤本身就是门禁的“前置条件”，如果预处理阶段就引入了错误，后续门禁只能拦截而不能修复。相关数据下载与文档可参考：Natural Earth、Copernicus Data Space、ESA WorldCover。

六、对比与局限：硬门禁的代价、边界与反模式

6.1 两条路线的正面对比

把“prompt 约束”与“硬门禁”放在同一张表里对比，可以更清楚地看到取舍。需要强调的是，这不是“二选一”的对立，而是“主次”的区分：硬门禁是正确性的保证层，prompt 约束是体验的优化层。没有硬门禁，prompt 约束再完善也只是“降低了出错概率”；有了硬门禁，prompt 约束可以专注于让交互更顺畅。

6.2 硬门禁的代价与边界条件

硬门禁不是没有代价。首先，它增加了开发与维护成本：每一条规则都需要测试、都需要在数据格式演进时更新。其次，它降低了灵活性：用户可能有一个合理的、门禁未覆盖的需求，被阻断后需要人工介入。第三，它可能产生“虚假安全感”：门禁覆盖了已知的检查点，但未知的错误模式仍然存在，使用者可能因为“门禁通过了”而放松警惕。

笔者认为，这些代价是值得的，但需要明确边界。硬门禁适合拦截“已知的、后果严重的、可从数据确定性判断的”错误；不适合拦截“需要业务判断的”“后果轻微的”“数据本身模糊的”情况。对于后者，应当用告警 + 人工确认，而不是阻断。一个把所有情况都阻断的门禁，最终会被使用者用“关闭门禁”来对抗，反而降低了整体安全性。这是安全工程中的经典教训，GIS 门禁设计同样适用。

6.3 三个需要警惕的反模式

反模式一：把门禁写成 prompt。这是最常见的错误，表现为在系统提示里写“你必须检查 CRS”。它给人一种“已经处理了”的错觉，实际上没有任何强制力。识别方法很简单：问一句“如果模型不检查，会发生什么？”如果答案是“什么也不会发生，流程照常继续”，那就不是门禁。

反模式二：让 LLM 生成检查代码。有些团队让模型自己写“检查 CRS 的函数”，然后执行。这看似兼顾了灵活性与安全性，实际上把正确性又交回给了模型——检查代码本身可能有 bug、可能被后续生成覆盖、可能漏掉关键分支。门禁代码应当由人编写、由测试保证，而不是由模型生成。

反模式三：只做前置门禁，不做后置门禁。前置门禁只能保证“输入看起来没问题”，无法保证“处理过程没有引入问题”。轴序错误、基准面转换退化、重采样核函数误用，都发生在处理过程中，只有后置门禁（检查输出范围、值域、统计量是否合理）才能捕获。完整的门禁必须是双向的。

七、结论与展望

7.1 核心结论

回到本文开头的问题：CRS 一致性检查与重采样方法选择，应当做成不可绕过的硬门禁，还是相信 LLM 能在 prompt 里被教会？基于第二、三节的机制分析，本文的结论是明确的：必须做成硬门禁，LLM 只能承担意图解析与解释层职责。理由不是“LLM 不够好”，而是这类参数的正确性信号不在语言分布里，而在数据元数据与坐标几何里；用 prompt 约束去替代确定性检查，本质上是用概率手段解决确定性问题，其可靠性上限受限于模型的指令遵循稳定性，而非任务难度。

这个结论有三条边界条件需要强调。第一，它针对的是“语义无关、地理致命”的参数，不是所有 GIS 参数；对于意图解析、任务编排、结果解释，LLM 仍然是高效的。第二，硬门禁的有效性依赖于规则的正确性与覆盖度，规则本身需要持续维护与测试，不能一劳永逸。第三，门禁的强度应当分级，阻断、告警、记录各司其职，过严的门禁会被绕过，反而降低安全性。

7.2 演进方向

往前看，笔者认为有三个方向值得关注。其一是“可验证工具”的标准化。如果 GIS 工具生态能够形成一套约定，让每个工具都声明自己的前置条件、后置条件与参数约束，那么门禁可以从“每个团队自己写”变成“生态共建”。这与数据库领域的事务约束、Web 领域的 schema 校验是类似的演进路径。其二是 LLM 与规则引擎的更深耦合。当前的做法是“LLM 在前、规则在后”，未来可能出现“规则引擎向 LLM 暴露可解释的约束”，让模型在生成阶段就知道哪些参数不可写、哪些必须询问，从而减少无效生成与来回确认。其三是评测体系的建立。目前缺少针对“Agent GIS 流程正确性”的公开基准，导致不同方案之间难以比较。构建包含故障注入、参数陷阱、跨带场景的评测集，是推动这一领域从经验走向工程的关键一步。

最后需要说明的是，本文的立场不是“反对 AI 自动化”，而是“主张正确的分工”。LLM 擅长理解意图、组织流程、解释结果，这些能力在 GIS 自动化中价值巨大；但它不擅长保证数值正确性，而这恰恰是地理计算的生命线。把正确性交给代码，把灵活性交给模型，让两者各司其职，这或许是当前阶段最务实的工程答案。

主要参考文献

[1] Janowicz K, Gao S, McKenzie G, et al. GeoAI: Spatially explicit artificial intelligence techniques for geographic knowledge discovery and beyond[J]. International Journal of Geographical Information Science, 2020, 34(4): 625-636.

[2] Li Z, Ning H. Autonomous GIS: the next-generation AI-powered GIS[J]. International Journal of Digital Earth, 2023, 16(2): 4668-4686.

[3] Roberts J, Lüddecke T, et al. GPT-4 and geospatial reasoning: an evaluation of large language models on spatial tasks[C]//Proceedings of ACM SIGSPATIAL, 2023.

[4] PROJ contributors. PROJ coordinate transformation software documentation[EB/OL]. https://proj.org, 2024.

[5] GDAL/OGR contributors. GDAL documentation: gdalwarp[EB/OL]. https://gdal.org/programs/gdalwarp.html, 2024.

[6] QGIS Development Team. QGIS documentation: Coordinate Reference Systems[EB/OL]. https://docs.qgis.org, 2024.

[7] ISO 19111:2019. Geographic information — Referencing by coordinates[S]. Geneva: ISO, 2019.

[8] Gorelick N, Hancher M, Dixon M, et al. Google Earth Engine: Planetary-scale geospatial analysis for everyone[J]. Remote Sensing of Environment, 2017, 202: 18-27.

[9] Hijmans R J. Raster: Geographic data analysis and modeling[CP/OL]. R package, 2024.

说明：本文写作过程中参考了坐标参考系、地图投影、栅格重采样、GeoAI 与 LLM 空间推理等方向的公开文献与官方文档共 60 余篇，其中 2022 年以后文献占比超过 50%。受篇幅所限，正文仅列出 9 篇主要参考文献，其余文献在行文中以机构文档、标准文件与公开数据集说明的形式标注。涉及的数据集（Natural Earth、Copernicus DEM、ESA WorldCover）均为公开数据，预处理细节已在 5.4 节说明。