语音审凶案：OpenAI Realtime API 的诱惑与代价

Hacker News 上有则帖子，标题是「Show HN: Voice driven murder mystery」。点开看，是个用语音审 AI 嫌疑人的推理游戏——whodunnitai.com。作者说是两三年前就做过的原型，最近技术成熟了，重新拉了一版上线。

核心是 OpenAI 的 gpt-realtime-2.1，走 WebRTC 做语音到语音的实时交互。这让我想起当年做语音助手的日子——延迟必须控制在几百毫秒以内，否则对话体验就断了。realtime 模型能做到这个。

但代价也明显。作者在帖子里写得很直接：「I really don't want to go broke while I sleep tonight」。所以他加了两个限制——必须 Clerk 登录，每次对话 30 分钟计时。realtime API 按秒计费，并发高了账单确实吓人。

证据判定是另一个 gpt-5-mini，专门负责判断玩家陈述的证据是否满足案件要求。作者说 paraphrasing 算数，但 vague suspicion 和 fishing 不算。这个边界设计比很多同类项目清楚——它知道自己在做什么，而不是让 AI 随便编答案。

不过项目上线才几个小时，问题就来了。

有用户在评论区贴了浏览器开发者工具的网络请求截图：网站直接向 OpenAI API 发了 POST 请求，auth bearer token 明文写在 JavaScript 里。这意味着任何访问这个网站的人都能拿到 token，理论上可以拿去直接调 OpenAI 的 API。

这是架构上的疏忽。请求应该通过后端代理转发，或者像另一位评论者提到的，用 Firebase Cloud Function 做中间层，同时设置 token 的月度限额。把 API key 写在前端，不管项目多 small，都不该发生。

安全之外，体验也有问题。有人反馈 "voice connection failed"，有人遇到 Dispatch 确认被拦，还有人发现案件介绍时计时器一直显示 0:00。429 Too Many Requests 错误也被多次提到——实时语音对话的并发和配额是现实约束。

这个项目在试 OpenAI Realtime API 的边界。它证明了语音交互游戏已经可以做到可用，也把成本、安全和并发管理的问题全部摊开了。实时语音 agent 这个方向走到了「可以做产品」的阶段，但 token 明文写在前端这种事，也暴露了不少独立开发者在架构设计上的短板。