当我们谈论 AI 应用时，往往陷入 RAG (检索增强生成) 或 Prompt Engineering (提示词工程) 的单一维度。但在构建 出前一汤 —— 一个多人即时海龟汤推理游戏时，我发现单纯依靠实时推理是远远不够的。
这一次，我想聊聊我做 AI 主持海龟汤的心路历程。
在海龟汤中，展现给玩家的是汤面，真相被称作汤底，这个游戏至少 2 个人才能玩：有一个人是主持人，他在知晓汤底的情况下，对玩家的猜测作出判定，给出是/不是/是或不是/无关的回答。
一位船长下船后，去餐厅喝了一碗海龟汤。 喝完之后，他痛哭流涕，随后自杀了。 请问：为什么？
你可以提问或给出猜测，然后基于得到的反馈，继续猜测，直到找到真相。
正确答案是：
船长多年前曾遭遇海难，和船员在荒岛漂流，即将饿死。 当时，一位同伴端来一碗肉汤，说是 “海龟汤” ，船长喝了之后活了下来，但同伴死了。
多年后，他在餐厅喝到了真正的海龟汤，发现味道和当年那碗完全不一样。 他瞬间明白了：当年同伴给他吃的根本不是海龟，而是那位死去的同伴自己的肉。 出于巨大的愧疚和绝望，他选择了自杀。
原本做这个网站，就是为了和女朋友一起玩海龟汤。于是用了谷歌的 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：
"你是一个主持人，汤面是... 汤底是... 请回答玩家的问题。"
结果是：
在几十轮的测试后，我意识到：让一个 AI 既要理解复杂的谋杀诡计，又要构建严谨的逻辑防线，还要扮演生动的角色，这太强机所难了。
我们需要把“思考”和“表达”拆开。
在设计双层架构之前，我其实先尝试了 RAG (检索增强生成) 方案。
我的设想很完美：做一个“智能缓存层”。
但在海龟汤里，这个方案完败。
核心原因在于，向量检索看重的是“语义相似度”，而不是“逻辑精确度”。
在海龟汤中，玩家经常会进行极为细微的试探：
在向量数据库眼中，这两句话的 Embedding （语义向量）极度相似，甚至可能被判定为同一个意图。
如果有一次 AI 回答了“是自杀”，缓存记录了下来。下次有人问“他是被杀吗”，RAG 很可能因为高相似度，直接自信地甩出缓存里的“是”——瞬间导致游戏逻辑崩塌。
海龟汤需要的是字斟句酌的逻辑判定，而不是模棱两可的语义搜索。这次失败让我意识到：不能依赖概率，必须依赖结构化的逻辑。
为了解决这个问题，我设计了一套 双层 AI 架构：
这是系统的核心。每当一道新题库入库时（也可以是按需触发），后台会触发一个高算力模型，我们称之为 Architect。
它的任务不是陪玩家聊天，而是进行深度逻辑拆解，生成一份结构化的 **Logic Profile (逻辑档案)**。
这个过程不需要实时，可以花 30 秒甚至更久。Architect 会思考：
最终，它会生成一份包含游戏所有元数据的 JSON 存入数据库
当玩家开始游戏时，面对他们的其实是 Host。
Host 不需要消耗大量算力去推理真相，它只需要读取 Architect 预先生成的 Logic Profile 。因为最难的逻辑判断已经被“预缓存”了，Host 运行在响应速度极快的模型上，专注处理玩家的自然语言交互。
这就像游戏开发中的“预渲染”：把最复杂的计算留在离线阶段，把最流畅的体验留给实时阶段。
这种架构不仅仅是为了省钱/加速/提高准确度，它直接方便了我开发后续的核心功能：
在 出前一汤 中，玩家可以进行通灵召唤，抽卡召唤故事里的人物或物品来对话。
但这有一个巨大的逻辑陷阱：死者知道自己怎么死的吗？
如果是被背后偷袭，死者就不应该知道凶手是谁。如果实时让 AI 判断这一点，很容易露馅。
但在 Logic Profile 中，Architect 已经预先定义好了每个角色的 认知盲区：
基于这份档案，Host 在扮演角色时就有了完美的“剧本”。玩家会发现，召唤的角色只会描述自己视角的事情，像是在上演罗生门。
这种基于视角的叙事碎片，正是推理游戏的精髓。
我们还做了一个类似“刮刮乐”的现场搜证功能。玩家面对 6 个档案袋，需要消耗积分刮开线索。
这 6 个线索不是随机生成的，而是 Architect 精心设计的：
如果完全依赖实时 AI 生成，它往往编不出高质量的干扰项。只有通过预生成的 Logic Profile ，我们才能保证每一局游戏的体验都是经过“设计”的。
除了后端的硬核逻辑，作为独立开发者，我也在前端体验上下足了功夫。
推理游戏最大的乐趣在于整理线索。我不希望玩家还要拿纸笔记录，所以在游戏里内置了一个完整的“侦探工作台”：
利用 Architect 生成的角色描述（ Prompt ），我们对接了图像生成模型，为每个召唤角色生成专属立绘。
为了防止剧透（比如死者不能画得太血腥导致直接看出死法），Architect 的生图 Prompt 遵循一套严格的美学与防剧透原则
出前一汤 的开发过程让我明白，AI 原生应用如果不做逻辑分层，很容易变成一个单纯的 Chatbot 壳子。
通过引入 Architect (离线深思) 和 Host (在线快响) 的双层架构，利用 Logic Profile 将非结构化的故事转化为结构化的游戏数据，我们实际上是在用 AI 模拟人类游戏设计师的工作流。
这让 AI 能够驾驭海龟汤这种这种极度依赖逻辑闭环和信息差的游戏。
当然，技术只是手段。当你深夜和朋友在房间里，看着屏幕上“死者”发来的那句充满了遗憾与未知的证词时，那一刻的沉浸感，才是我想带给每一位玩家的礼物。
One More Thing
作为一个不需要下载、打开即玩的时候 PWA 应用，出前一汤 完美适配了移动端。
欢迎来试玩：出前一汤
同时也欢迎大家在评论区交流 AI 应用开发的心得！
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。