代码能运行，并产生可信的空间结果吗？
同时检查运行状态、产物存在性、空间逻辑和质量指标。
项目记录 · 2025
可验证的 GIS 代码助手
GeoAgent
把 GIS 代码生成从“一次性回答”，改造成检索文档、生成、执行、报错修复和评测的闭环。
为什么会做这件事
通用模型生成的 GIS 代码经常“看起来合理但跑不通”：API、参数、坐标系或数据文件选错，都会让答案无法交付。用户真正需要的不是一段漂亮代码，而是减少查文档和反复调试的时间。
真正的问题
怎样让自然语言需求经过可靠知识、数据选择和执行反馈，最终变成可以验证的 GIS 任务结果？
我做的关键选择
每个动作，都应该能解释为什么。
先构建 6k+ GIS QA 与 320 条 Query-Code 样本。
垂类任务需要稳定的数据边界和示例覆盖，不能只依赖模型已有知识或零散 Prompt。
用 RAG 检索官方文档和代码示例。
GIS API 更新快、参数细，检索能给生成阶段提供可追溯依据，比继续加长 Prompt 更可维护。
把执行、报错、修复和评测接成循环。
早期复盘发现“代码像答案”不等于“任务能交付”；执行反馈才能暴露依赖、路径、工具调用和异常处理问题。
系统怎样运转
一个 GIS 需求如何走到可运行、可验证的结果
开始 / 输入处理判断结果
- 用户
提出空间任务
说明目标、输入数据、空间关系和期望交付物。
- RAG + 数据层
检索知识并确认数据
召回官方 API、示例与可用文件，检查坐标系和字段。
- 规划 / 生成 Agent
形成计划并生成代码
选择工具、处理顺序与参数，产出可执行脚本。
交付代码与空间产物
同时保留数据、参数和评测依据，便于复现。
错误进入修复 Agent
把依赖、路径、API 或参数错误反馈给生成环节。
返回用户澄清
补充文件、坐标系、字段含义或期望输出。
验证闭环
失败原因回流到检索与规划
错误不被隐藏在最终答案里，而是定位到知识、数据、计划、执行或评测环节后重新运行。
业务含义核心不是“生成代码”，而是把知识依据、数据选择、执行反馈和空间结果验证接成闭环，减少看似正确却无法交付的答案。
亲手做的部分
从判断到可运行的东西。
理解
解析空间任务、输入数据和期望产物。
规划
检索相关知识，选择文件、工具与处理顺序。
验证
执行生成代码，根据报错修复，并评估结果质量。
留下的证据
- 构建 6k+ GIS QA 与 320 条 Query-Code 数据
- 相对基线 CodeBLEU 提升 78.3%
- 35 个 GIS 任务平均约 5 分钟完成
- 防御性代码写法提升 50%
代码相似度和小规模任务集不能代表真实生产可靠性；首版网站不链接含本机路径的研究仓库。
增加空间结果级验证和失败用例覆盖，优先回答“结果是否可信”，而不只是“代码是否生成”。