Simon Willison用AI从零造出GeoJSON地图查看器的完整过程

一个真实需求催生的小工具

知名开发者 Simon Willison 最近分享了一个颇具代表性的 AI 辅助开发案例。Simon 是 Django Web 框架的联合创始人之一，也是数据探索工具 Datasette 的作者，近年来尤其活跃于 AI 辅助开发实践的前沿，频繁在博客中记录自己使用大语言模型构建工具的完整过程。这次的起因很简单：他在帮朋友 Natalie 整理本地行政边界地图——具体是 Granada Community Services District（格拉纳达社区服务区）和 Midcoast Community Council（中海岸社区委员会）的政治边界。

需求也很直接：需要把一些 GeoJSON 文件显示在地图上，并导出为 PNG 图片。GeoJSON 是一种基于 JSON 的开放标准地理空间数据格式（由 IETF 在 RFC 7946 中正式规范），能够表示点、线、多边形等几何对象以及它们的属性信息。相比传统的 Shapefile 格式，GeoJSON 以纯文本形式存储、可直接在浏览器中解析，因此在 Web 地图应用中被广泛采用，也是 GitHub、Mapbox、Leaflet 等平台和工具的原生支持格式。Simon 面对的是一个非常典型的"小而具体"的工程需求——市面上或许有现成方案，但要么功能过重，要么不够趁手。

于是 Simon 做了一件如今越来越普遍的事：他没有去搜索现成工具，而是直接让 AI 帮他构建一个。

AI 主动构建了一个完整的地图查看器

有意思的是整个开发流程。Simon 向 GPT-5.6-Sol 询问工具建议，而模型不仅给出了建议，还"主动"构建了一个工具原型。随后他借助 Claude Code for web 和 Fable 5.1 进行了多轮迭代，最终打磨出了这款成品——GeoJSON Map Viewer。

值得注意的是，这个案例中 Simon 使用了多个 AI 工具协同工作，这反映了当前 AI 辅助开发的一个重要趋势——开发者不再依赖单一 AI 工具，而是根据不同工具的优势在开发流程的不同阶段灵活切换。例如，某些模型擅长系统设计和架构建议，另一些模型在代码生成的精确性和前端细节调优方面表现更好。这种"多模型协作"的工作流正在成为高效开发者的新常态，类似于过去开发者在不同 IDE、调试器和部署工具之间切换，只不过现在 AI 模型本身成了工具链的一部分。

这一流程折射出当前 AI 编程工具链的成熟度。过去开发一个带地图渲染、多图层叠加、样式控制和导出功能的 Web 应用，即便对熟练开发者也需要数小时到一天的工作量。而现在，从"提出需求"到"可用成品"的路径被大幅压缩，AI 甚至能在对话中主动识别出"你需要一个工具"并直接动手实现。

你可能没注意到，Simon 强调这款工具遵循了隐私优先的设计——界面上明确标注"Your GeoJSON stays in this browser"（你的 GeoJSON 数据留在浏览器本地），所有处理都在客户端完成，无需上传服务器。在技术上，这意味着整个应用的计算逻辑完全在用户的浏览器端执行，依赖现代浏览器的 JavaScript 引擎、Canvas API 等能力来完成数据解析、地图渲染和图片导出。与传统的服务器端处理模式不同，用户数据完全不离开本机，消除了数据泄露和隐私合规风险；应用可以作为静态页面部署，无需后端服务器维护成本。对于处理可能包含敏感地理边界或行政信息的场景，这种设计尤为重要。

GeoJSON 查看器的核心功能

从截图可以看到，这款查看器的功能设计相当完整：

• 多图层支持：可添加多个 Shape 图层（Shape 1、Shape 2……），每个图层独立配置
• 灵活的数据加载：既支持通过 URL 直接加载 GeoJSON，也支持在文本框中粘贴原始数据
• 样式定制：每个图层可单独设置填充颜色（如蓝色 #028FC3、红色 #E4572E）和透明度（Opacity 滑块）
• OpenStreetMap 底图：基于 Leaflet 渲染，叠加在真实地理底图上
• PNG 导出：满足最初"导出为图片"的核心需求

这里值得展开说一下底层的地图渲染技术。Leaflet 是目前最流行的开源 JavaScript 交互式地图库之一，由乌克兰开发者 Vladimir Agafonkin 创建。它仅约 42KB（gzip 后），却提供了完整的地图渲染能力，包括瓦片图层加载、矢量图形绘制、弹出窗口、缩放控制等功能。Leaflet 的设计哲学是"简洁、高性能、可扩展"——核心库只包含最必要的功能，其余通过丰富的插件生态补充。它支持 OpenStreetMap 等多种瓦片源作为底图，并能原生加载 GeoJSON 数据在地图上渲染多边形、线段等矢量要素，非常适合这类需要快速构建地图可视化应用的场景。

在示例中，两个半透明多边形分别覆盖了 Montara、Moss Beach 一带以及 El Granada、Quarry Park 区域，叠加显示在 Half Moon Bay 沿岸的真实地图上，直观清晰。

AI 不只造工具，还能生成地理空间数据

如果说 AI 造工具已经足够惊艳，那么 Simon 分享的另一个细节更值得琢磨——GeoJSON 边界数据本身也是 AI 生成的。

他发现，只要向 ChatGPT（他提到的是 ChatGPT Work）请求几乎任何区域的边界，模型就会从不同的政府开放数据源中提取、组合文件，最终构建出你需要的边界数据。

要理解这为什么了不起，需要了解传统地理空间数据获取的难度。在 GIS（地理信息系统）领域，获取精确的行政边界数据历来是一项专业性很强的工作。美国各级政府通过不同的开放数据平台发布地理边界文件——比如美国人口普查局的 TIGER/Line 数据库、各州和县的 GIS 开放数据门户——但这些数据往往分散在不同网站上，格式各异（Shapefile、KML、GeoJSON、GDB 等），坐标参考系统也可能不同（如 NAD83、WGS84）。要获取特定社区服务区这样的小型行政单元的精确边界，开发者通常需要：识别正确的数据源和管辖机构、理解数据的元数据与属性字段、使用 QGIS 或 ArcGIS 等专业工具进行坐标转换和几何裁剪。这一流程对非 GIS 专业人员来说门槛很高。

Simon 给出的两个提示词非常朴素：

I want a polygon that represents the exact boundary of the El Granada GCSD （给我一个表示 El Granada GCSD 精确边界的多边形）

Get me a GeoJSON file for the boundary (or boundaries if that makes sense) for the MCC - Midcoast Community Council - that operates near Half Moon Bay CA （给我 MCC——中海岸社区委员会，位于加州 Half Moon Bay 附近——的边界 GeoJSON 文件）

结果 AI 真的从公开政府数据源中拼出了可用的边界多边形。这意味着地理空间数据的获取门槛正在被显著拉低——过去你需要懂得去哪个政府网站、下载哪种格式、如何做坐标转换与合并，现在一句自然语言描述就能触发整个流程。AI 通过整合检索和数据处理能力，正在将这个多步骤的专业流程压缩为一次自然语言对话。

这个案例揭示了哪些趋势

这个看似不起眼的小工具，实际上浓缩了当下 AI 辅助工作方式的几个重要变化。

从"搜索工具"到"按需构建"的思维转变

过去遇到具体需求，我们的第一反应是搜索现成方案；现在越来越多开发者的第一反应是"让 AI 帮我做一个"。当构建成本降到足够低，为一次性或小众需求定制专属工具变得完全合理。这是一种工作范式的根本转变。软件行业长期以来遵循"构建通用工具、服务广泛用户"的经济逻辑，因为开发成本高昂，只有足够多的用户分摊才划算。而当 AI 将构建成本压缩到接近于零，"为一个人的需求造一个工具"不再是奢侈，而是理性选择。

数据获取与工具开发的双重门槛降低

Simon 的案例中，AI 同时降低了"工具开发"和"数据获取"两个环节的门槛。地理空间领域历来专业性强、数据分散，如今普通用户也能通过对话完成过去需要 GIS 专家才能做的事。这种变化不仅限于地理空间领域——在法律文件检索、医学文献综述、金融数据分析等许多专业领域，AI 正在扮演类似的"知识中介"角色，将分散的专业数据源整合为普通人可以直接使用的结果。

隐私优先设计不应因效率而妥协

即便是 AI 快速生成的工具，Simon 依然坚持了本地处理、数据不出浏览器的设计。这提醒我们，AI 加速开发不等于放弃工程质量与隐私原则——好的默认设计在任何时候都很重要。事实上，随着 AI 降低了开发门槛，越来越多非专业开发者开始构建和分享工具，隐私安全的默认设计变得比以往更加关键。当工具的创建变得容易，确保每个工具都遵循正确的安全实践反而成为更大的挑战。

结语

GeoJSON Map Viewer 本身或许只是一个小工具，但它背后的故事更有启发性：一个真实、具体的需求，通过 AI 主动构建工具、AI 生成数据、多工具协同迭代，在很短时间内被完整解决。对于开发者和知识工作者而言，这种"随需而造"的能力，正在悄然重塑我们解决问题的方式。