2026/9/20

手搓一个多人在线2048对战平台——AGI 1.0 时代的产品开发体验

从一场校园 2048 挑战赛的需求出发，记录与 AI 一起做原型、开发比赛房间、修复问题和调整需求的过程。

AIVibe Coding产品开发2048

8月底，某学校领导提了个大要求，要在 1024 节全校开展 2048 小游戏挑战赛。任务就自然落到了某 vibe coder 身上。

2048小游戏，听起来很简单。一个四乘四的棋盘，上下左右滑动，相同数字合并。玩法现成，规则清楚，似乎加个学校名字，就可以交差了。

“全校”和“挑战赛”很快带来一串要求。学生要登录，老师要组织，个人可以练习，还要两人对抗、三人组队。比赛要限时，老师要看实况，结束后要有成绩。手机、iPad、触屏笔记本，都得能玩。

这就是本文所说的“AGI 1.0 时代的产品开发体验”：一个人借助 AI，把产品、设计、前后端和测试串起来。

从 8 月 26 日的第一个 commit，到 9 月 20 日的战绩改版，仓库留下了这段经历。

第一批 commit 是一个只有九行的 README 和第一版界面原型。

README 列出了登录、房间、练习、对抗、组队、排行榜和比赛实况等初始项目目标。

原型是AI YOLO出来的，深色导航、比分卡片、赛事倒计时、房间大厅、团队贡献，桌面和手机都有设计。打开 HTML 就能演示，棋盘也能玩。原型相当热闹。观战人数、对局动态、服务健康、异常复核、通知待办，都摆上去了。

不完全对，但是先有可见的页面作为靶子，比较容易让人类和 AI 的想法形成共识。

讨论随之具体起来：谁维护，谁能看，数据从哪来，出错怎么办？

8 月 26 日，我提交 PR #2，整理了 V1 需求和技术设计。先确认范围，再写业务代码。

正式版删掉赛事宣传、公共观战、动态流、通知和服务健康，暂缓排行榜。教师和学生各有自己的导航，1v1 和组队赛统一从房间进入。

老师管理学生和团队，建房、开赛、看实况、查成绩。学生练习、组队、加入房间、参加比赛。第一轮就围绕这些动作来做。

AI 补页面和接口很快，“这轮做到哪里”就得写清楚。一句“再完善一下”，可能带出新的页面、数据表和权限，后面还要测试和维护。

需求文档成了人与 AI 的共同约定：这一轮做什么，做到什么程度，怎样算完成。

比赛房间的设计经过了一番讨论。不同于线上棋牌室，比赛是线下的，谁加入，什么时候算满，谁来开始，中途怎么退，掉线怎么办，成绩谁确认。有些问题需要系统线上处理，有些问题有明确的线下责任人，这时，系统就可以退后，把状态仿真度大大降低。

最后形成的V1 流程很直接。老师填写房间名，选择 1v1 或 3v3，设置一到十分钟的时长，创建房间。学生加入，满员后老师点开赛。倒计时三秒，比赛开始。结束后保存成绩，房间转为只读。Keep It Simple, Stupid.

同一天，PR #3 做出了首版全栈应用：页面、登录、业务接口、数据库、实时房间和部署流程都有了。

测试环境的页面和接口放在一个 Cloudflare Worker 中，D1 保存数据，每个房间由一个 Durable Object 管理。前后端共用 2048 引擎。可以把它理解成：每个房间都有一个服务端裁判，负责记状态、掌握时间、确认成绩。

PR 的验证记录覆盖六人线上 3v3、触控和键盘、限时结束、结算、成绩导出。之后又修正部署流程，绑定域名。

8 月 26 日的提交包含原型导入、需求文档和首版实现，线上测试无bug，只有前端效果缺陷修改了一轮。

接下来，开始每周一轮测试收集意见。

触屏笔记本的方向键失灵了。代码发现设备支持触摸，就跳过了键盘监听。修复很简单：键盘和滑动同时支持。

iPad 全屏时，棋盘可能被浏览器工具栏和屏幕边缘遮住，退出按钮也要补上。布局需要按实际可用高度调整，再用真机检查。

候场页每两秒闪一下。原因是每次取数据都把整页换成加载提示，取完再显示回来。改成首次加载、后续原地更新，闪屏就解决了。

老师开赛后，学生还停在候场页。于是让房间推送开始状态，学生页面收到后自动进入比赛，并保留定时查询作为备用。

这些细节问题是不经过真实场景测试无法发现的。

测试多人实时比赛时，发现在真实不理想网络环境下，websocket传输延迟明显，玩家按下方向键，棋盘不能立即响应，做了动作后，服务器端的同步状态会把刚做的动作还原回去。

这轮讨论聚焦在实时性 x 防作弊的双重边界上。只有人类才能拍板，我们对选手动作的同步观看要求其实没有那么高，我们对防作弊技术也不需要追求上限。

Issue #11 和 PR #23 确定了这次的减法：学生端上传方向和序号。服务器用相同引擎和随机种子执行操作计算正式成绩。一条消息只有“向左，第 127 步”，服务端处理重复、缺步、重连、标签页接管，以及截止后到达的操作。

产品继续增加功能。

测试也随着修复增加。首版 PR 记录了 30 项端到端测试，权威同步版本有 120 项，战绩改版有 162 项。发现过的问题逐步加入自动检查，后续改动就多了一层保障。

个人练习榜、团队榜上线。学生可以创建团队、选择预设徽标，也可以在符合条件时删除自己创建的团队。

9 月 10 日，学生导航里的“房间列表”被删掉。首页直接展示可加入的房间，点击就进候场或比赛，少走一层。

迭代就是这样有加有减。用途清楚的功能补进来，重复的页面撤下去。

9 月 20 日合并的 PR #29，把练习最好五局、正式 1v1 和正式 3v3 分开展示。比赛有本期和历史统计，胜平负对应 3/1/0 积分。三人队在同一个房间只计一场。

房间增加了正式和友谊用途字段，为后续区分做准备。学生自建房留到以后，资格排名规则继续讨论。

截至 9 月 20 日，教师 3v3 大屏改造和 V2 需求仍在讨论和待办中。1024 节还在前面，项目也在继续。

回头看，和上个月的开发过程的跌宕起伏相比，这个项目的开发过程称得上梦幻，说是AGI 1.0 应该不算夸张。

有一种感觉，从此以后，应用开发的典型场景，就是‘每个人都在现场，人人都是FDE’。

本文依据 2026-08-26 至 2026-09-20 的提交、原型、需求文档及 Issue、PR 讨论整理。主要记录：首个提交、V1 需求与架构、首版实现、权威同步、V2 讨论、战绩改版。开发体验部分为回顾与思考。