Simon Willison用GPT-5.5+Codex修复Datasette地图Bug全过程

一个地图显示Bug引出的连环问题

Datasette 创始人 Simon Willison 近日发布了一个新插件 datasette-referrer-policy 0.1，用于自定义 HTTP Referrer-Policy 头。这个看似简单的插件背后，是一段有趣的连环 Bug 排查经历，同时也展示了 GPT-5.5 和 Codex 在实际插件开发中的表现。

Datasette 是一个开源的 Python 工具，用于将 SQLite 数据库快速发布为可交互的 Web 界面和 API。Simon Willison 作为 Django 框架的联合创始人之一，在设计 Datasette 时采用了高度插件化的架构，通过钩子（hooks）机制允许开发者在不修改核心代码的情况下扩展功能，目前已有超过 100 个社区插件覆盖可视化、认证、导出等各类场景。

事情的起因是 Datasette 官方的 global-power-plants 演示页面 上，OpenStreetMap 瓦片地图突然无法正常显示。经过排查，Simon 发现背后藏着两个相互独立的 Bug。

Bug #1：Cloudflare CAPTCHA 误拦截 JSON 请求

第一个问题出在 Simon 几周前为网站添加的 Cloudflare Turnstile CAPTCHA 验证上。地图插件在加载时需要通过 .json 接口获取数据，而 CAPTCHA 机制错误地拦截了这些 JSON 请求。由于返回的不是 HTML 页面，用户根本没有机会完成验证，请求就直接失败了。

Cloudflare Turnstile 是一种无感验证方案，旨在区分人类用户和自动化机器人。与传统 CAPTCHA 不同，Turnstile 通常在后台完成验证，不需要用户手动识别图片。但其验证流程依赖于返回 HTML 页面来嵌入验证脚本——当请求的是 JSON 等非 HTML 资源时，验证流程无法正常完成，请求就会被直接阻断，而前端 JavaScript 收到的是一个无法解析的错误响应。

这是一个典型的「安全机制与功能冲突」案例——添加安全防护时未充分考虑所有请求类型。Simon 通过调整 CAPTCHA 配置，将 JSON 请求排除在验证范围之外，解决了这个问题。

Bug #2：Referrer-Policy 导致 OpenStreetMap 拒绝瓦片请求

第二个问题更加隐蔽。OpenStreetMap 有一项合理的安全策略：拒绝来自设置了 Referrer-Policy: no-referrer 头的网站的瓦片请求。OSM 需要通过 Referer 头追踪瓦片的使用情况，防止资源被滥用。

要理解这个问题，需要了解 HTTP Referrer-Policy 的工作机制。这是一个安全响应头，用于控制浏览器在发起跨站请求时是否携带 Referer 头信息。Referer 头会告诉目标服务器用户是从哪个页面发起的请求。该策略有多个级别：no-referrer（完全不发送来源信息）、origin（只发送域名）、strict-origin-when-cross-origin（跨域时只发送域名，HTTP 降级时不发送）等。no-referrer 是最严格的隐私保护级别，但也意味着第三方服务完全无法知道请求来自哪里。

OpenStreetMap 作为全球最大的开源地图项目，其瓦片服务器为大量网站提供免费地图底图。但 OSM 的瓦片使用政策明确要求使用者必须允许发送有效的 HTTP Referer 头，以便运维团队追踪瓦片使用来源、识别滥用行为并进行容量规划。如果检测到请求缺少 Referer 信息，OSM 服务器会返回 403 错误或空白瓦片。这一策略帮助 OSM 在有限的服务器资源下维持对全球用户的免费服务。

而 Datasette 默认正是使用 Referrer-Policy: no-referrer 这一最严格的隐私策略。从 Datasette 页面发出的所有请求都不会携带来源信息，OpenStreetMap 服务器因此直接拒绝了瓦片请求。

为什么不直接修改 Datasette 默认值？

Simon 的考虑很周到：no-referrer 是一个注重隐私的默认设置，贸然修改可能影响现有用户的安全预期。许多 Datasette 用户选择这个工具正是因为其对隐私的重视——例如在内部数据分析场景中，管理员不希望内部页面的 URL 结构通过 Referer 头泄露给外部服务。因此他选择了更稳妥的方案——开发一个独立的 Datasette 插件，让需要调整 Referrer-Policy 的用户自行配置。

GPT-5.5 + Codex 开发 Datasette 插件的实战表现

这个插件是 Simon 使用 Codex + GPT-5.5 协作完成的。他公开分享了完整的 AI 辅助开发过程，从中可以看到 AI 编程工具在实际项目中的具体表现。

GPT-5.5 是 OpenAI 于 2025 年中期发布的模型，相比 GPT-4o 在推理深度和上下文理解方面有显著提升。Codex 则是 OpenAI 专门面向代码生成和软件工程任务优化的 Agent 产品，能够在沙箱环境中自主执行代码、运行测试并迭代修复。两者配合使用时，GPT-5.5 提供高质量的代码生成和架构设计能力，Codex 负责端到端的工程执行流程——包括创建项目结构、编写测试用例、运行验证并根据结果自动修复问题。

这是一个非常适合 AI 辅助开发的场景：

• 需求明确：设置一个 HTTP 响应头
• 模式清晰：Datasette 插件有标准的开发模式和钩子机制（如 asgi_wrapper 钩子用于修改 HTTP 响应）
• 规模可控：功能单一，代码量小

从 Simon 的实践来看，GPT-5.5 配合 Codex 在处理这类「明确需求 + 成熟框架」的任务时效率很高。开发者只需描述需求和约束条件，AI 就能生成结构完整、可直接使用的插件代码，包括 setup.py 配置、插件钩子实现、测试文件和 README 文档。

对开发者的几点启示

这个案例有几点值得关注：

1. 安全策略需要全局视角：添加 CAPTCHA 或修改 HTTP 头时，要考虑对页面内所有类型请求的影响，包括 AJAX 调用、资源加载等非页面请求。现代 Web 应用中，一个页面可能同时发起数十个不同类型的请求，安全策略的影响范围远超页面本身。
2. 留意第三方服务的隐性要求：使用 OpenStreetMap 等外部服务时，需要注意其对 HTTP 头的特殊要求，这些信息往往不在最显眼的文档位置。类似的隐性要求在 CDN、字体服务、分析工具等第三方集成中也很常见。
3. 插件化优于改默认值：当默认行为有其合理性时，通过插件提供可选配置是对用户更负责任的做法。这也是 Unix 哲学中「做好一件事」原则在现代软件架构中的体现。
4. AI 辅助编程的最佳切入点：边界清晰、模式成熟的小型工具和插件开发，是当前 AI 编程助手最能发挥效率的领域。当需求模糊、架构未定或涉及复杂业务逻辑时，AI 的表现会显著下降，仍需要开发者主导设计决策。

核心要点

• Datasette 地图演示页面因 CAPTCHA 误拦截 JSON 请求和 Referrer-Policy 头被 OSM 拒绝两个 Bug 导致瓦片无法显示
• OpenStreetMap 会拒绝设置了 no-referrer 策略的网站的瓦片请求，这与 Datasette 的默认隐私设置冲突
• Simon Willison 使用 GPT-5.5 + Codex 快速开发了 datasette-referrer-policy 插件来解决问题
• 选择开发插件而非修改默认值，体现了对现有用户安全预期的尊重
• 该案例展示了 AI 辅助编程在明确需求、成熟框架场景下的高效表现