linux.do

可以不仅仅是主持人：我如何用一些AI技巧打造一个有灵魂的海龟汤平台

当我们谈论 AI 应用时，往往陷入 RAG (检索增强生成) 或 Prompt Engineering (提示词工程) 的单一维度。但在构建出前一汤 —— 一个多人即时海龟汤推理游戏时，我发现单纯依靠实时推理是远远不够的。

这一次，我想聊聊我做AI主持海龟汤的心路历程。

----------------------

什么是海龟汤

在海龟汤中，展现给玩家的是汤面，真相被称作汤底，这个游戏至少 2 个人才能玩：有一个人是主持人，他在知晓汤底的情况下，对玩家的猜测作出判定，给出是/不是/是或不是/无关的回答。

一位船长下船后，去餐厅喝了一碗海龟汤。喝完之后，他痛哭流涕，随后自杀了。请问：为什么？

你可以提问或给出猜测，然后基于得到的反馈，继续猜测，直到找到真相。

正确答案是：

船长多年前曾遭遇海难，和船员在荒岛漂流，即将饿死。当时，一位同伴端来一碗肉汤，说是 “海龟汤” ，船长喝了之后活了下来，但同伴死了。
多年后，他在餐厅喝到了真正的海龟汤，发现味道和当年那碗完全不一样。他瞬间明白了：当年同伴给他吃的根本不是海龟，而是那位死去的同伴自己的肉。出于巨大的愧疚和绝望，他选择了自杀。

从半个小时5美刀到可持续的支出

原本做这个网站，就是为了和女朋友一起玩海龟汤。于是用了谷歌的Gemini免费api，基本能应对几个人玩的需求，后来这个网站被抖音的博主发现后宣传了一波，带来了几百人进入网站。

很显然，这时候免费api无法满足需求。首先我做的是接入到之前搭建好的Gemini key池，但是仍然经不住用户的大量提问。

为了不让第一批用户流失，我果断接入了openrouter取代key池，结果不到半小时立马花了5美元。

这对我这个用爱发电的个人开发者来说，简直是破产倒计时。

痛定思痛，我开始寻找更具性价比的方案。经历了一番漫长的模型“迁徙”——从最初还在实验阶段的 Gemini Thinking Mode，转向了速度极快的 Gemini 2.0 Flash，最后锁定了 DeepSeek V3.2。

最关键的一步是，我利用了 DeepSeek 官方支持的 Context Caching（上下文缓存） 技术。海龟汤的规则、汤面设定动辄几千 token，如果每次对话都重复传输，不仅慢，而且都是冤枉钱。通过缓存技术，只需要支付一次“记忆成本”，后续的对话都能复用这段缓存，直接命中了“降本增效”的靶心。

这一套组合拳下来，成本直接降低了 90% 以上，终于让这个网站能够可持续地运转下去了。

从“人工智障”到“全知全能”的困境

海龟汤（Lateral Thinking Puzzle）的魅力在于信息差。作为主持人，你必须全知全能（知道真相），但又要守口如瓶（只能回答“是/不是”）。

最初，我直接通过 Prompt 把汤面和汤底塞给 AI：

“你是一个主持人，汤面是… 汤底是… 请回答玩家的问题。”

结果是：

1. 如果开启思考模式，主持人反应很慢，而且token消耗翻倍
2. 如果不开思考模式，AI回答的逻辑性很差，很多海龟汤的汤面充满了叙述性诡计。汤底一般都有着复杂的逻辑和人物关系，AI很难在500ms内构建出严谨的逻辑防线

在几十轮的测试后，我意识到：让一个 AI 既要理解复杂的谋杀诡计，又要构建严谨的逻辑防线，还要扮演生动的角色，这太强机所难了。

我们需要把“思考”和“表达”拆开。

----------------------

走过的弯路：向量检索 (RAG) 的“智障时刻”

在设计双层架构之前，我其实先尝试了 RAG (检索增强生成) 方案。

我的设想很完美：做一个“智能缓存层”。

1. 把每一次玩家的提问和 AI 的回答存入向量数据库
2. 通过用户反馈和人工干预，标记出正确的回答
3. 当前 10 次打向LLM的提问积累了足够的数据后，后续玩家如果问了类似的问题，就直接从数据库捞出AI回答最多的答案，或者是人工标记的正确答案，不再消耗 AI Token，还能提高准确度。

但在海龟汤里，这个方案完败。

核心原因在于，向量检索看重的是“语义相似度”，而不是“逻辑精确度”。

在海龟汤中，玩家经常会进行极为细微的试探：

● 玩家 A 问：“他是自杀吗？”
● 玩家 B 问：“他是被杀吗？”

在向量数据库眼中，这两句话的 Embedding（语义向量）极度相似，甚至可能被判定为同一个意图。
如果有一次 AI 回答了“是自杀”，缓存记录了下来。下次有人问“他是被杀吗”，RAG 很可能因为高相似度，直接自信地甩出缓存里的“是”——瞬间导致游戏逻辑崩塌。

海龟汤需要的是字斟句酌的逻辑判定，而不是模棱两可的语义搜索。这次失败让我意识到：不能依赖概率，必须依赖结构化的逻辑。

----------------------

核心技术：双层 AI 架构与 Logic Profile

为了解决这个问题，我设计了一套 双层 AI 架构：

Layer 1: The Architect (架构师) —— 离线深思

这是系统的核心。每当一道新题库入库时（也可以是按需触发），后台会触发一个高算力模型，我们称之为 Architect。

它的任务不是陪玩家聊天，而是进行深度逻辑拆解，生成一份结构化的 Logic Profile (逻辑档案)。

这个过程不需要实时，可以花 30 秒甚至更久。Architect 会思考：

● 这个故事的核心诡计是什么？
● 到底有哪些物理证据？
● 更多我需要的元数据

最终，它会生成一份包含游戏所有元数据的 JSON 存入数据库

Layer 2: The Host (主持人) —— 实时响应

当玩家开始游戏时，面对他们的其实是 Host。

Host 不需要消耗大量算力去推理真相，它只需要读取 Architect 预先生成的 Logic Profile。因为最难的逻辑判断已经被“预缓存”了，Host 运行在响应速度极快的模型上，专注处理玩家的自然语言交互。

这就像游戏开发中的“预渲染”：把最复杂的计算留在离线阶段，把最流畅的体验留给实时阶段。

----------------------

✨️ 预缓存带来的产品质变

这种架构不仅仅是为了省钱/加速/提高准确度，它直接方便了我开发后续的核心功能：

1. 通灵召唤与“认知盲区”技术

在出前一汤中，玩家可以进行通灵召唤，抽卡召唤故事里的人物或物品来对话。

但这有一个巨大的逻辑陷阱：死者知道自己怎么死的吗？

如果是被背后偷袭，死者就不应该知道凶手是谁。如果实时让 AI 判断这一点，很容易露馅。
但在 Logic Profile 中，Architect 已经预先定义好了每个角色的 认知盲区：

基于这份档案，Host 在扮演角色时就有了完美的“剧本”。玩家会发现，召唤的角色只会描述自己视角的事情，像是在上演罗生门。

这种基于视角的叙事碎片，正是推理游戏的精髓。

2. 现场搜证：有序的随机

我们还做了一个类似“刮刮乐”的现场搜证功能。玩家面对 6 个档案袋，需要消耗积分刮开线索。

这 6 个线索不是随机生成的，而是 Architect 精心设计的：

● 1 个核心物证（直接指向凶手）
● 3 个侧面线索（辅助推理）
● 2 个干扰项（专门用来误导玩家）

如果完全依赖实时 AI 生成，它往往编不出高质量的干扰项。只有通过预生成的 Logic Profile，我们才能保证每一局游戏的体验都是经过“设计”的。

----------------------

不仅仅是文字：沉浸式体验的打磨

除了后端的硬核逻辑，作为独立开发者，我也在前端体验上下足了功夫。

调查卷宗与工作台

推理游戏最大的乐趣在于整理线索。我不希望玩家还要拿纸笔记录，所以在游戏里内置了一个完整的“侦探工作台”：

● 案卷 Tab：自动收集解锁的文字/图片线索
● 物证 Tab：通过网格视图管理搜证结果，支持打上「关键」「存疑」「排除」的印章
● 可视化笔记：将关键问答像便利贴一样钉在案情白板上

动态立绘系统

利用 Architect 生成的角色描述（Prompt），我们对接了图像生成模型，为每个召唤角色生成专属立绘。
为了防止剧透（比如死者不能画得太血腥导致直接看出死法），Architect 的生图 Prompt 遵循一套严格的美学与防剧透原则

----------------------

结语：技术服务于沉浸感

出前一汤的开发过程让我明白，AI 原生应用如果不做逻辑分层，很容易变成一个单纯的 Chatbot 壳子。

通过引入 Architect (离线深思) 和 Host (在线快响) 的双层架构，利用 Logic Profile 将非结构化的故事转化为结构化的游戏数据，我们实际上是在用 AI 模拟人类游戏设计师的工作流。

这让 AI 能够驾驭海龟汤这种这种极度依赖逻辑闭环和信息差的游戏。

当然，技术只是手段。当你深夜和朋友在房间里，看着屏幕上“死者”发来的那句充满了遗憾与未知的证词时，那一刻的沉浸感，才是我想带给每一位玩家的礼物。

----------------------

One More Thing

作为一个不需要下载、打开即玩的时候 PWA 应用，出前一汤完美适配了移动端。

欢迎来试玩：出前一汤

同时也欢迎大家在评论区交流 AI 应用开发的心得！

3 posts - 3 participants

Read full topic

via LINUX DO - 最新话题 (author: 有希长门)

Invalid media:
image
image
image
image

20 views06:34