美丽新世界

Earn Tokens：Codex 多人扑克插件 Handoff

13分钟阅读

Earn Tokens：Codex 多人扑克插件 Handoff

为什么需要这份 Handoff

这份文档用于把当前讨论交给 ChatGPT Web 或新的 Codex 任务继续收敛。现在已经确认的是产品边界、联机方式和服务器责任；还没有确认的是它是否值得成为一个正式 Demo，以及除了“在 Codex 里打扑克”之外，能否形成更强的玩法身份。

推荐先把下面的 prompt 粘贴到 ChatGPT Web 普通对话，完成产品判断和 MVP 收敛。若直接交给 Codex 开发，也可以原样使用，但在创建仓库或写代码前，需要先确认项目是否正式进入 Demo 验证。

当前状态

  • 当前只有概念截图和口头讨论，没有工程、仓库、域名或线上服务器。
  • 截图表现的是 Codex 中的 6-max No-Limit Texas Hold’em，玩家把 tokens 当作筹码。
  • 目标是让玩家邀请特定的人进入同一牌桌，而不是随机匹配。
  • Codex 当前不能直接提供“用户名搜索 / 好友列表”作为插件能力，需要游戏自己维护身份、房间和邀请关系。
  • 游戏筹码只能是独立的虚拟 Token，不读取、不转移用户真实的 Codex 用量、API 额度或付费余额。
  • 本机服务器适合原型验证；稳定的异地多人游戏需要公共 HTTPS 服务。MVP 可以把 MCP、实时牌桌和数据服务合并在一个 Node.js / TypeScript 项目里。

一次性 Handoff Prompt

# Task
 
请把 "Earn Tokens" 收敛成一个可验证的 Codex 多人扑克插件方案，先完成产品判断、MVP PRD 和技术架构，不要直接写代码。
 
# Context
 
- 概念来自一张 Codex UI 设计图：左侧有 "Earn tokens" 入口，主界面是一张 6-max No-Limit Texas Hold'em 牌桌，玩家用 `tokens` 下注。
- 这不是已经存在的 OpenAI / Codex 功能，只是一张概念图。
- 用户希望做成插件，并且能邀请某个特定的人对战。
- Codex 没有可供插件直接搜索的用户名或好友目录。匹配特定用户需要游戏自己的身份系统、房间码或邀请链接。
- 两位玩家各自在自己的 Codex 中打开插件，连接到同一个游戏后端；服务器同步牌局并保存房间状态。
- `tokens` 是游戏内虚拟筹码，不对应真实 Codex Token、API 余额、现金或可交易资产。
 
# Source Material
 
原始画面可以概括为：
 
- Codex 桌面端左侧导航出现 "Earn tokens"。
- 中间是一张极简白色德州扑克牌桌，最多 6 个座位。
- 玩家头像旁显示数百万 tokens。
- 底部有 Fold、Call、Bet 和下注比例控制。
- 画面的吸引力来自“Codex 用户把推理 Token 当作筹码，在工作界面里开牌桌”。
 
OpenAI 官方参考：
 
- MCP Server：https://developers.openai.com/plugins/build/mcp-server
- Plugin Authentication：https://developers.openai.com/plugins/build/auth
- Custom UI：https://developers.openai.com/plugins/build/chatgpt-ui
 
# Confirmed Product Boundaries
 
- 第一版优先验证两个真人的 heads-up 对战；6-max 是后续目标。
- 通过房间码或邀请链接进入指定牌桌，不依赖 Codex 原生用户名搜索。
- 服务端是牌局权威：洗牌、发牌、行动合法性、底池、边池、结算都由服务端裁定。
- 客户端只显示玩家可见信息并提交操作，不能决定牌面或结算。
- 本地开发阶段运行 `localhost` 服务；邀请异地朋友测试时可以暂时使用安全 HTTPS tunnel，但正式版本需要稳定云端地址。
- 插件 UI 可以使用自定义界面；不要假设能够修改 Codex 原生侧边栏、账户余额或原生用户系统。
- 不做充值、提现、交易、现金兑换或真实价值下注。
 
# Core Design Question
 
先判断这个方案的游戏价值。
 
"在 Codex 里玩德州扑克，筹码叫 Token" 有清晰的视觉钩子和社交传播性，但目前更接近主题包装。请区分：
 
1. 作为一个轻量社交插件，它是否已经足够成立？
2. 如果要称为 AI 原生游戏，AI 必须改变哪一段 gameplay loop？
3. AI 玩家、桌边 Agent、对局复盘、自然语言下注或“完成任务赚筹码”等方向，哪些会真正改变玩家决策，哪些只是功能装饰？
 
不要为了强调 AI 而强行增加 LLM 功能。如果经典扑克 + Codex 场景已经是更好的 MVP，请明确说明。
 
# Expected Player Flow
 
至少覆盖这条双人闭环：
 
```text
玩家 A 打开插件
-> 创建私人牌桌
-> 得到邀请链接或房间码
-> 玩家 B 在自己的 Codex 中打开插件并加入
-> 双方入座并领取固定虚拟筹码
-> 服务端开始一手牌
-> 双方完成 Pre-flop / Flop / Turn / River 行动
-> 服务端结算底池
-> 任一玩家刷新或短暂断线后可以恢复牌局
```
 
# Technical Baseline
 
请基于一个尽量小的 TypeScript 服务设计：
 
```text
Codex Plugin UI A ─┐
                   ├─ HTTPS / Realtime ─ Game Backend ─ Database
Codex Plugin UI B ─┘
                              │
                              └─ MCP endpoint
```
 
MVP 可以合并部署以下能力：
 
- MCP Streamable HTTP endpoint：创建房间、加入房间、查询当前牌局等工具入口。
- Realtime channel：WebSocket、SSE 或可靠轮询三选一，负责同步玩家行动和牌桌状态。
- Poker state machine：座位、庄位、盲注、行动顺序、下注轮、弃牌、all-in、边池、摊牌和结算。
- Persistence：用户、guest session、房间、牌局事件、筹码账本和重连状态。
- Authentication：封闭测试可先使用带签名的 guest session + 私人邀请；公开版本再接 OAuth 2.1 / OIDC。
- Observability：房间事件日志、错误日志和最小管理查询。
 
# Constraints
 
- 当前没有正式项目仓库，不要虚构本地路径、GitHub 地址、域名、OAuth Client 或部署状态。
- 不接触真实 OpenAI API Key、用户密码、Codex 用量或企业内部信息。
- 私牌、牌堆和其他玩家不可见状态不能下发到无权看到的客户端。
- 随机数、行动时限、重连和重复提交必须由服务端处理。
- 先解决两名真人完成一整手牌，再考虑机器人、观战、排行榜、6-max、锦标赛和经济系统。
- 云平台保持供应商中立；如推荐具体方案，需要说明为什么适合有状态房间和实时连接。
- 明确区分“插件平台能力”“游戏后端能力”和“尚未验证的产品假设”。
 
# Output I Want
 
请按以下结构输出：
 
1. **产品判断**：这个概念最值得验证的体验是什么；是否需要 AI 原生机制。
2. **MVP 范围**：Must / Later / Out 三层，限制第一版规模。
3. **玩家流程**：创建房间、邀请、入座、开局、行动、结算、重连。
4. **系统架构**：组件职责、协议选择、服务端权威边界和部署路径。
5. **核心数据模型**：User、Session、Room、Seat、Hand、Action、Ledger 的关键字段与关系。
6. **牌局状态机**：用状态和事件描述一手 heads-up Hold'em 如何推进。
7. **身份与邀请方案**：封闭测试和公开版本分别怎么做。
8. **本地到云端路线**：本机原型、双人 tunnel 测试、稳定公网部署三个阶段。
9. **验收标准**：两位真实用户完成一手牌并成功重连所需的可观察证据。
10. **风险与未决问题**：最多 5 个真正会改变方案的问题，并给出默认建议。
11. **实施顺序**：把 MVP 拆成 5-8 个可以逐步验证的开发里程碑。
 
输出需要具体到下一位 Codex 可以据此创建工程计划，但不要生成大段样板代码，也不要假设用户已经决定正式立项。
 
# Quality Bar
 
- 从玩家 fantasy 和可玩的闭环开始，再落到技术。
- 每一项技术选择都要对应一个实际玩家问题，例如同步、隐藏信息、重连或作弊。
- 用最小闭环控制范围，避免第一版直接做 6-max、排行榜和复杂经济系统。
- 如果 AI 机制没有改变决策或体验，明确把它放到 Later，而不是用 AI 术语包装传统扑克。
- 不把概念图、官方能力和已实现功能混在一起。
 
# After You Answer
 
我会把以下内容带回 Codex：
 
- 最终产品判断和推荐 MVP。
- Must / Later / Out 范围。
- 技术架构和协议选择。
- 身份、邀请、重连和安全方案。
- 开发里程碑与验收标准。
- 仍然需要我决定的问题。
 
Codex 收到后，再判断是否把 Earn Tokens 升级为正式 Demo，并创建项目总览、外部工程和实施计划。

带回 Codex 的内容

  • 完整回答原文。
  • 接手者最终推荐的 MVP 范围。
  • 对“纯社交扑克”与“AI 原生玩法”之间的判断。
  • 推荐技术栈、部署方式和身份方案。
  • 需要用户决定的未决问题。

Codex 收到结果后的动作

  1. 先与用户确认是否正式进入 Demo 验证。
  2. 若确认立项，在 20_Demo验证/ 创建项目容器和 00_项目总览.md。
  3. 确认英文 project-name 后，再创建 H:\AINativeGame\<project-name>\ 工程；不提前虚构仓库和服务地址。
  4. 把产品判断保留在 vault，把详细技术计划、代码和验收材料放入外部工程。
  5. 先完成本机双客户端验证，再进行异地 tunnel 测试；核心闭环成立后才部署稳定云端服务。

关系图谱