当我们谈论 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：
"你是一个主持人，汤面是... 汤底是... 请回答玩家的问题。"
结果是：
- 如果开启思考模式，主持人反应很慢，而且 token 消耗翻倍
- 如果不开思考模式，AI 回答的逻辑性很差，很多海龟汤的汤面充满了叙述性诡计。汤底一般都有着复杂的逻辑和人物关系，AI 很难在 500ms 内构建出严谨的逻辑防线
在几十轮的测试后，我意识到：让一个 AI 既要理解复杂的谋杀诡计，又要构建严谨的逻辑防线，还要扮演生动的角色，这太强机所难了。
我们需要把“思考”和“表达”拆开。
走过的弯路：向量检索 (RAG) 的“智障时刻”
在设计双层架构之前，我其实先尝试了 RAG (检索增强生成) 方案。
我的设想很完美：做一个“智能缓存层”。
- 把每一次玩家的提问和 AI 的回答存入向量数据库
- 通过用户反馈和人工干预，标记出正确的回答
- 当前 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 应用开发的心得！
目前尚无回复
Select Language