用通用大模型当棋牌机器人：可行性与边界

用通用大模型直接出牌的方案，在演示视频里惊艳，在生产环境里翻车。根本原因是大模型是文本概率模型：它从语料中学到的是“关于斗地主的描述”，不是可优化的策略函数；它不维护对局状态，不保证输出合法，也不承诺延迟。演示可以挑样本，生产必须处理每一手牌。

需要先说清边界：这不是否定大模型的价值，而是否定“用LLM替代决策引擎”这条路径。大模型在棋牌产品里有正确的位置——聊天、文案与陪伴层，在那个位置上它几乎是不可替代的。分清这个边界，预算和技术路线才不会走偏。

把LLM直接接到牌桌上，会先撞上四个结构性问题。这四个问题都不是“提示词写得更好”或“换更大的模型”能解决的，而是文本概率模型与牌桌决策之间的架构级错配——它们决定了这条路的天花板，而不只是目前的工程短板。

• 状态管理：LLM没有持久记忆，每一手都要把牌河、余牌、对手行为重新序列化进上下文，长局截断后行为漂移，甚至记不住自己上一轮说过的话
• 牌型合法性：模型可能生成手里已不存在的牌，必须外挂校验层兜底重试，失败率不可控且重试会进一步推高延迟
• 延迟：出牌体验要求秒级稳定响应，LLM推理常见数秒且波动大，而棋牌AI的口径是决策P95<50ms，两者相差约三个数量级
• 成本：按token计费，每手牌数千token的上下文，一局数十手累计下来，单局成本比专用决策API高出一到两个数量级

即便上述四项都能工程化硬扛，还有一个无解的问题：可控性。运营需要胜率区间配置、难度分档、情绪响应与审计留痕，这些能力在专用棋牌AI里是决策层的原生接口（我们的控制台直接配置胜率区间与审计），而LLM的输出分布无法被这样精确约束——等于把决策层最难的部分留给了自己。

换个角度看这件事：棋牌AI真正的壁垒不在“知道怎么打”，而在每一手牌都稳定、合法、低延迟、可配置地输出。这正是专用决策引擎靠十年运营数据磨出来的部分，也是通用模型短期内无法替代的部分。

大模型在棋牌产品里的强项恰恰在决策之外：AI角色的互动聊天、开局问候与被炸吐槽、赛事播报、战报生成、新手引导话术。这些任务对延迟宽容（1-3秒可接受）、对合法性无要求、对创造性要求高，是LLM的主场，值得单独留一笔LLM预算。

因此推荐的架构是混合式：垂直棋牌AI API负责全部出牌决策与情绪调度，LLM消费同一份对局事件流生成聊天文案。两层解耦后，决策层可以独立压测与验收，文案层可以随时更换模型而不影响牌局——模型层随时可替换，是这套架构最大的长期红利。

// 决策层：专用棋牌AI API（P95<50ms，牌型100%合法）
POST /v1/games/ddz3/sessions          // 创建AI对局
WS   /v1/sessions/{session_id}/stream // 出牌、叫分、情绪事件流

// 文案层：LLM订阅同一事件流，只生成聊天，不参与决策
事件 {"type": "bomb", "by": "robot_2"}
  → LLM 生成：“这手炸得好，我这点牌真跟不动了…”

最后给一个可以直接执行的选型判断：先明确你要的是“会打牌”还是“会聊天”，再决定要不要为LLM付钱——顺序反了，预算就会花在错误的层上。以下三档覆盖了我们见到的绝大多数需求形态，逐档对号入座即可。

• 只要“会打牌”：直接用垂直棋牌AI API，不需要LLM，成本与延迟最优
• 要“会打牌也会聊天”：混合架构，决策走专用API、文案走LLM，两层分别验收
• 全LLM方案（决策也用大模型）：不建议进入生产，只适合做交互原型与技术演示