在接触“GIS 大模型”这类需求时很多人的第一反应是能不能把这些问题全部丢给 LLM地址转经纬度可以问它点围栏匹配可以问它坐标判断也可以问它。但真实工程里这种做法往往会在上线后带来三件麻烦事结果不可复现、推理成本不可控、安全边界模糊。我的判断很明确地理工具的绝大部分核心链路不依赖 LLM 也能跑而且应该跑得更稳定。所谓Geo Tool with No LLM Run不是“反对 AI”而是一种务实的架构选择用确定性的空间算法处理确定性的问题只在真正需要语义理解的地方引入 LLM。如果你正在做风控围栏、轨迹分析、设备位置管理、园区监控这类系统这篇文章会告诉你怎样用一套纯规则和空间计算工具把地理判断跑通并且给出可以直接改造成生产服务的代码示例。文章会分成三个层面先说清楚为什么地理工具要先走 No LLM 路线再给出一个不依赖 LLM 的地理工具最小实现最后聊生产落地时最常见的坑、排查方式和最佳实践。读完你可以得到一套完整的、可运行的 Python 项目也可以据此判断业务里的哪些地理需求应该交给算法哪些才值得交给大模型。1. 想清楚Geo Tool 到底需不需要 LLM 在线推理先看一个典型场景。业务方给你一批设备经纬度需要判断每台设备当前是否在某一个电子围栏内。这个需求经常被描述成“智能地理功能”于是产品经理的第一反应是引入大模型。但你仔细拆解后会发现它并不需要模型在线推理只需要两个确定性步骤将输入的经纬度规范化、校验范围。把点坐标与围栏多边形做空间关系判断。这类任务如果上了 LLM反而会暴露几个致命问题首先是结果不稳定。LLM 不是专门用来做空间拓扑计算的同一个点在不同上下文里可能得到不同结论。哪怕它只是输出一个“在不在围栏内”的 JSON也可能出现坐标小数位丢失、经度和纬度写反、多输出一段解释文字等问题。工程里的异常处理成本反而变高。其次是成本和延迟不可控。每次推理都会消耗 Token在线服务还会受网络波动影响。而一张静态围栏表完全可以加载进内存后用空间索引毫秒级完成查询。生产环境里成本差异可能是一个数量级。再次是审计困难。地理判定往往涉及订单、设备、人员等线下行为。如果判决过程是一个不可解释的模型出了问题很难复盘。空间计算则不同输入的点、围栏多边形、使用的坐标系、采用的算法都可以复现。所以一个值得反复强调的观点是不要把所有“带地理属性”的需求都当成“需要 AI 的需求”。LLM 有价值但它的价值通常发生在“非结构化输入”和“自然语言交互”层而不是确定性的空间计算层。任务类型是否适合接入 LLM原因经纬度范围校验完全不需要范围判断是纯数值问题点是否在多边形内完全不需要空间拓扑算法更准确停车场距离计算完全不需要球面距离公式即可解决非标准地址文本转经纬度可以辅助文本混乱时规则解析成本高“帮我查附近 3 公里门店”可以辅助需要理解用户自然语言日常业务中真正需要 LLM 的场景通常集中在地址文本清洗、对话式问数这一类。而底层的坐标计算、空间查询、围栏判断依然要被封装成确定性接口。2. “No LLM Run” 是什么意思确定性优先于大模型先给一个清晰定义。Geo Tool在这里指负责地理空间数据处理的基础工具链包括坐标转换、坐标校验、点面关系、距离计算、地理围栏匹配、空间数据导出等能力。它和百度地图、高德地图这类在线地图服务不同它更关注“程序如何处理空间对象”。No LLM Run指的是一个地理工具的执行链路中不包含任何 LLM 推理步骤。也就是说运行时不会请求外部模型接口也不会在代码里动态加载一个大模型。所有输入经过确定性的规则、公式和空间索引后直接得到输出。这里要区分两件事开发阶段用 LLM 辅助写代码这是工程效率问题。运行阶段依赖 LLM 完成决策这是架构可靠性问题。很多项目说“用了 AI”其实只是在离线阶段让 AI 帮忙生成了多边形数据、转换脚本或代码片段。真正给用户提供服务的进程始终是一条无 LLM 的确定路径。这是完全合理的设计甚至可以说是最佳实践。用“No LLM Run”的方式做地理工具还意味着几个隐含优势可以离线运行。只要安装了 Python 依赖和基础空间数据就不需要外部网络。对于内网部署、私有化交付、现场运维的客户这几乎是硬需求。测试非常方便。输入一组坐标输出应当是稳定且唯一的。自动化测试可以断言“点 A 必须在园区围栏内”“点 B 必须不在围栏内”运行一万次结果都一样。便于性能优化。不依赖外部 API 之后吞吐量完全由本地 CPU 内存和算法决定。你的服务可以从“每请求一次外部调用”变成“启动时建索引查询时走空间索引”QPS 很容易提升几个量级。权限和合规边界更好控制。坐标数据属于敏感位置数据。请求外部大模型意味着要把位置数据发到第三方服务这在很多企业的合规评审里很难通过。用本地确定性计算可以做到数据不出内网。这也就是为什么越是真实的商业项目越倾向把“LLM 能力”放在入口层把“地理判断能力”放在核心处理层。入口层负责把用户的模糊表达变成结构化参数核心层继续使用无 LLM 的规则和空间计算保证结果的正确与可控。3. 环境准备与项目结构下面进入实操。我采用 Python 技术栈因为生态里 GeoPandas、Shapely、PyProj、GeoPy 这些库非常成熟基本覆盖了从数据处理到空间计算的完整链路。建议环境Python 3.9 或更高版本。独立虚拟环境避免和系统依赖冲突。pip 安装常用空间处理库。先创建项目目录和虚拟环境mkdir geo-tool-no-llm cd geo-tool-no-llm python -m venv .venvLinux/macOS 激活虚拟环境source .venv/bin/activateWindows PowerShell 激活虚拟环境.\.venv\Scripts\Activate.ps1然后在项目根目录创建requirements.txt# 文件路径requirements.txt geopandas shapely pandas geopy版本不强制写死以你当前环境的兼容版本为准。安装命令pip install -r requirements.txt如果安装较慢可以换成国内镜像源例如pip install -r requirements.txt -i https://pypi.tuna.tsinghua.edu.cn/simple装完之后建议先验证一次导入python -c import geopandas, shapely, geopy; print(deps ok)能正常打印deps ok说明环境没问题。下面是项目最终需要的目录结构geo-tool-no-llm/ ├── requirements.txt ├── demo_data.py ├── main.py └── geo_tool/ ├── __init__.py ├── coords.py └── fence.py其中__init__.py可以为空文件作用是把geo_tool变成一个 Python 包。接下来逐个文件实现。4. 核心流程拆解从坐标到结论的四步在写代码之前先梳理一条工具应当遵循的核心处理流程。很多人拿到需求就写结果往往是因为坐标序错误、多边形不闭合、范围没校验这类低级问题反复返工。以下几步能帮你少走弯路。第一步输入坐标规范化。原始数据可能是116.3100,39.9600可能是116.3100E,39.9600N也可能是从 Excel 里粘贴出来的带空格字符串。第一步应该先把“字符串”解析成“浮点数”并且明确坐标顺序为“经度, 纬度”。这一层不需要大模型。经纬度范围非常明确经度应在 -180 到 180 之间纬度应在 -90 到 90 之间。超范围的数据应该直接标记异常而不是硬算。第二步把空间对象建模成统一结构。为了做点面判断需要把围栏多边形构建成统一的空间数据格式。这里用 GeoPandas 的 GeoDataFrame。每条记录包含区域 ID、区域名称以及一个 Shapely Polygon 几何对象。开发时容易出错的一点是经纬度顺序。GeoJSON 和 Shapely 的 Point 都采用(经度, 纬度)也就是先 x 后 y。如果你把纬度写在前工具不会立刻报错但它会把一个位于中国北方的点判定到海上或者直接匹配错误围栏。第三步执行确定性空间判断。一个点和一个多边形的拓扑关系可以用 Shapely 里的空间方法完成。根据业务需求可能用到以下判断点是否在多边形内部用contains。点是否与多边形边界相交用intersects。缓冲半径查询用 buffer。距离计算使用球面距离或投影坐标系距离。本示例中会实现两个最常用的能力点所在围栏定位以及离点最近的锚点查询。第四步输出结构化结果。最终输出应当是一个稳定、可读的结构例如 CSV、JSON 或数据库记录。不要在输出里夹杂大段解释性文本否则下游系统对接会很难受。判断是否在围栏内返回值就应该是区域 ID不在就返回空。整套流程的关键在于每一步都不需要模型猜测结果可复算异常可追溯。5. 完整示例代码实现现在开始逐个文件实现。5.1 坐标规范化模块坐标模块放在geo_tool/coords.py。它负责把常见的坐标字符串解析成浮点数并校验范围。# 文件路径geo_tool/co