开发者工具作者Simon Willison在8月15日用一天时间，借助GPT-5.6-Sol xhigh写出一个纯浏览器端聊天工具CORS Chat，可以直连任何支持CORS的OpenAI Responses兼容API接口。他用这个工具测试了本地跑在M5 MacBook Pro和NVIDIA DGX Spark上的Qwen 3.8 27B模型，也顺手验证了OpenRouter可用。
这听起来像一个很典型的极客周末故事，但拆开看，里面至少有两处容易被读者忽略的坑：这个"一天造成"的工具其实没那么简单，而"两台机器都测过"这句话，很容易被误读成一次性能对比。
1800行代码里的真实工程量
CORS Chat的源码托管在Willison的tools仓库里，cors-chat.html文件本身约1800行，不依赖任何前端框架，纯HTML、CSS和原生JS写成。它对接的是OpenAI的Responses API，支持GET /models拉模型列表、POST /responses发对话，JSON响应和SSE流式两种模式都兼容，可配置reasoning.effort、text.verbosity这些新一代接口才有的细粒度参数。
更值得一提的是安全细节：Markdown渲染用markdown-it配合DOMPurify做净化，SVG预览放进带严格CSP、空sandbox属性的iframe里，脚本和网络访问都被禁掉。流式生成SVG时，工具会自动修复还没闭合的标签，大约每110毫秒刷新一次预览，用双iframe交替避免画面闪烁。
这些不是装饰性的工程细节，而是决定这个工具能不能安全地拿去用的关键。一天写出这种量级的东西，说明当前的AI辅助编程工具在这类中等复杂度的前端任务上，已经能把流式解析、内容净化这些容易出错的环节处理对。
CORS能开门，不能加速
原文那句"在M5 MacBook Pro和DGX Spark上都测过"，很容易让人以为这是一次跨平台性能验证。其实不是。CORS只是浏览器跨域访问的许可开关，跟模型跑多快没有任何关系。LM Studio的--cors参数解决的是"网页JS能不能访问本地服务器"，真正决定推理速度的是量化格式、后端runtime、内存带宽这些变量，CORS Chat这次完全没有触及这一层。
DGX Spark官方规格是128GB统一内存、273GB/s内存带宽、最高1 PFLOP FP4稀疏算力。此前社区有人测过Qwen3-30B-A3B NVFP4在DGX Spark上单请求约75 tokens/秒——但这是完全不同的模型，套不到Qwen 3.8 27B头上。目前没有人拿M5 MacBook Pro、DGX Spark、OpenRouter三个环境跑同一版本Qwen 3.8 27B做过严格对比。
- 提醒.想靠这次"两边都测过"判断该买哪台硬件跑本地模型，目前拿不到答案，它验证的是接口兼容，不是速度高低。
把密钥放进浏览器，业内已经栽过跟头
CORS Chat把端点、自定义请求头和API密钥编码进URL片段，同时存进localStorage，图的是省事和可分享。这是BYOK（自带密钥）浏览器工具的常见做法，但localStorage和URL片段都有被XSS脚本、浏览器扩展、日志或截图意外捕获的可能。
这不是纸上谈兵的假设。今年4月，本地AI代理项目cc-switch被发现CORS配置过当，任意网页可以在用户毫不知情的情况下消耗其AI账号额度，后来修复并关闭了这个issue。7月，又有社区报告称聊天工具Chatbox的兼容模式会把原始授权头和请求体转发经过其运营的代理，隐私政策是否充分披露还在讨论——这条目前只是社区反馈，没被坐实为恶意行为，需要审慎看待。
- 风险.把生产环境的API Key粘进浏览器工具之前，先想清楚它存在哪、能被谁读到。
CORS Chat本身是个人工具，代码开源、逻辑可审查，风险等级跟商业化产品不在一个量级。但"浏览器直连+CORS+自定义头"这套架构已经不是理论上的安全担忧，而是有真实先例的攻击面。愿意用本地模型省心测试的开发者，享受便利的同时，最好留意密钥别跟着URL片段到处跑。