用 ChatGPT 生成 5K 与 10K 跑步路线的一次实验

一位开发者尝试让 ChatGPT Work 调用 GPT-6 Astra（Max）为自己生成从家门口出发、最终回到家的 5K 与 10K 跑步环线。提示词大意是：

我住在某个地址。请基于 OSM 数据，为我规划从家出发并回到家的 5K 和 10K 跑步路线。

这次任务运行了 27 分钟，最终产出包括：

• 嵌入式地图可视化
• 可下载的 GPX 文件
• 可下载的 GeoJSON 文件

其中一条 5K 路线被命名为 “El Granada harbor loop”，距离约 5.1 公里。路线从港口附近出发，沿若干街道与海岸步道形成闭环。

它是如何生成路线的？

当用户询问生成过程时，ChatGPT 的回答是：

使用 Nominatim 定位地址，使用 Overpass 下载本地 OpenStreetMap 道路和步道数据，然后在本地计算环线。

也就是说，这个过程大致包含三步：

1. 将地址解析为地理坐标；
2. 拉取附近道路、步道等开放地图数据；
3. 在本地计算满足距离要求的闭环路线。

从结果看，代理式工具链已经可以把地理编码、开放地图数据、路径计算、文件导出和可视化串联起来，形成一个相对完整的个人路线规划工作流。

问题：执行过程不可见

这次实验也暴露了一个关键问题：实际运行的代码和具体执行细节并没有在 ChatGPT 界面中展示。

用户后来想要索取当时使用的 Python 代码，但 ChatGPT 已无法提供。看起来原因是对话线程已经被压缩，压缩前的上下文和工具执行痕迹没有被完整保留下来，或者至少没有暴露给后续工具调用。

这带来一个值得讨论的问题：如果 LLM 系统使用上下文压缩机制，是否应该：

• 保留压缩前的完整文本；
• 保留代理执行过的代码、参数和中间结果；
• 允许后续通过工具调用访问这些历史记录；
• 明确区分“模型推断出的过程”和“实际执行过的过程”。

否则，用户很难复现结果，也难以审计代理到底做了什么。

地图可视化是如何嵌入的？

这次地图展示使用了 ChatGPT 的可视化能力。系统创建了一个 HTML 文件，并直接嵌入到界面中展示。

HTML 内部包含：

• 路线名称与距离；
• 地图容器；
• 样式定义；
• 一个 application/json 类型的脚本块，用于存放路线和地图渲染所需的完整几何数据；
• D3 脚本，用于在页面中绘制路线和地图。

其中 JSON 片段包含类似这样的结构：

{
  "route": {
    "type": "LineString",
    "coordinates": [
      [-122.467425, 37.4997753]
    ]
  }
}

值得关注的启示

这次案例的亮点不只是“AI 生成跑步路线”，而是展示了代理式 AI 在真实任务中的几个能力组合：

• 调用地理编码服务；
• 拉取开放地图数据；
• 进行本地路径计算；
• 输出 GPX 与 GeoJSON 等标准格式；
• 生成可直接嵌入界面的交互式或半交互式可视化。

但它也提醒我们：当 AI 系统开始长时间执行任务、调用外部工具并生成文件时，可追溯性会变得非常重要。用户不仅需要结果，也需要知道结果是如何产生的，尤其是在涉及路线、安全、地理位置或自动化决策时。