Simon Willison 昨天发的这个小实验，我第一眼看标题也差点被带偏。 Python ASGI app 跑进浏览器。 这句话太容易写成“后端要没了”“Python Web 可以全静态部署了”。 先别急。 我更想把它当成一个 AI 编程案例来看。 说人话，这个实验最有意思的地方，不是 Python 终于能在浏览器里跑。 而是 Claude Code 帮 Simon 把一个卡了很多年的架构缝隙，推进成了 demo、PR、测试和边界说明。 这比“AI 又写了很多代码”更值得普通开发者看。 我会先看 Simon 到底做了什么 Simon 原文发布在 2026 年 5 月 30 日。他说当天早上把这个任务交给 Claude Opus 4.8 / Claude Code for web，然后做出了两个 demo。 一个是 FastAPI demo。 另一个是 Datasette 1.0a31 demo。 对应的 GitHub 目录也写得很清楚，这是一个 AI-generated research report。核心机制是 Service Worker 拦截 `/app/` 下面的同源请求，把请求转给 shell page，再交给长期运行的 Pyodide Web Worker，最后由浏览器里的 Python ASGI app 返回响应。 翻译成人话，就是浏览器里不只是有一段 Python。 它还模拟了一段“请求进来、应用处理、响应回去”的 Web 后端路径。 这个点很关键。 以前你想分享一个 Python Web demo，经常要别人先装环境、起服务、配依赖。Datasette Lite 之前也已经能在浏览器里跑，但 Web Worker 包装方案有一个限制，返回 HTML 里的 `<script>` 不会正常执行，很多交互会坏。 这次实验试的是另一条路。 让 Service Worker 接住请求，再把它桥接到浏览器里的 Python ASGI 应用。 Claude Code 真正做对的是这一步 AI 编程的价值，是把旧限制推进成可验证实验。如果只是写一段代码，这件事没那么值得讲。 真正有价值的是，PR 里能看到一条比较完整的探索链。 Claude 先做 ASGI-in-browser 和 FastAPI demo，再把 Datasette 接到同一套 bridge 上，然后继续补 root 登录、fullscreen、hash routing、测试和边界修复。 仓库 README 里还记录了 27 个测试通过，包括 Python 单元测试和 Playwright + Chromium 端到端测试。 这就是我觉得 AI 编程最值得用的地方。 不是让它替你喊一个大结论。 而是把一个“我一直想试，但一直没空试”的技术缝隙，推到能打开页面、能看 PR、能跑测试、能列限制的状态。 这个状态不一定能上生产。 但它已经足够让你判断：这条路有没有继续走的价值。 普通开发者可以怎么借这个思路 拿一个旧限制做 15 分钟实验，不要直接改生产代码。你可能不会写 Pyodide，也不一定用 Datasette。 没关系。 这篇对普通开发者真正有用的，不是照抄 Simon 的 bridge。 而是这个用 AI 做工程探索的方法。 你可以找一个自己项目里卡了很久的小问题。 比如： • 一个老工具能不能做成静态 demo • 一个后端能力能不能离线演示 • 一个复杂流程能不能跑在浏览器沙盒里 • 一个原本需要环境配置的教程，能不能变成打开即用 然后不要一上来让 AI 改主项目。 先给它一个很窄的任务： 先做一个实验 demo，不要改生产代码。必须留下 README、限制说明、测试命令和一个能打开的页面。 这个提示的重点不是“写得快”。 重点是把 AI 产物限制在实验盒子里。 你要的不是它一次成功，而是它留下足够多证据，让你决定下一步要不要继续。 别把它写成后端终结者 Pyodide + Service Worker 很有想象力，但边界必须讲清。这类文章最容易夸过头。 所以边界要先说清楚。 这个实验不是说所有 Python Web 应用都能无改动跑进浏览器。 Datasette demo 里有路径前缀、root auth、HTML rewrite、frame header stripping 等专门处理。README 也列了限制，比如不支持 WebSocket、请求不是 streaming、一个 Pyodide worker 单线程，适合 demo，不是高并发生产方案。 还有一个安全点。 为了让某些页面能在 iframe 里工作，demo 会处理 frame-busting headers。这个在实验里可以解释，但不能变成“随手移除安全头”的建议。 所以我不会把它写成“服务器没用了”。 更准确的判断是： 对一些教学、数据工具、离线演示、可分享 demo 来说，AI + Pyodide + Service Worker 让 Python Web 应用多了一种可验证的静态分发路线。 这已经很有价值了。 我真正想学的是这种 AI 用法现在很多人用 AI 写代码，最容易卡在两个极端。 要么让它补一小段函数。 要么直接让它接一个大需求。 Simon 这个例子给了中间路线。 把 AI 放到一个独立实验里，让它探索、产出、测试、说明边界。你最后看的不是它说“完成了”，而是看 demo 能不能打开，PR 改了什么，README 有没有说清限制，测试有没有覆盖关键路径。 这比单纯问“Claude Code 强不强”实用很多。 如果你现在也有一个一直想试但没空试的技术点，今天可以先拿一个小时做小实验。 不要碰生产主干。 建一个 research 目录，让 AI 只在里面工作。要求它交付 4 样东西：一个 demo 页面、一份 README、一个测试命令、一段不适合场景说明。 它能做到这一步，这个想法才值得继续投时间。 感谢阅读，也感谢关注艾瑞壳，我们继续拆 AI 编程里那些不是简单“更快”，而是能改变工程探索方式的案例。 | 
