SpacetimeDB 仓库 LLM 编码基准PostgreSQL 实时聊天应用 12 项功能评测结果深度解析76.4% 得分与 6 处已知缺陷【免费下载链接】SpacetimeDBDevelopment at the speed of light项目地址: https://gitcode.com/GitHub_Trending/sp/SpacetimeDB导读本文基于 SpacetimeDB 仓库中tools/llm-oneshot基准测试框架产出的评分报告完整还原 Claude Opus 4.5 在 Prompt Level 9Private Rooms提示词下、使用 PostgreSQL 技术栈生成的 Discord 风格实时聊天应用的评测全过程总得分 27.5/3676.4%、0 次重试、12 项功能中 8 项满分、6 处已知 BUG 被逐一定位。读者可以借此掌握该基准的评分体系0–3 分制、Prompt 等级映射、重试效率折算、每项功能做到什么程度才能拿满分以及从数据库表结构与 Socket 事件设计中反推功能实现与缺陷成因的方法。一、评测背景llm-oneshot 基准如何量化 LLM 编码能力这份评分报告是仓库tools/llm-oneshot工具链含apps/chat-app、apps/chat-app/prompts/、apps/chat-app/prompts/composed/、apps/chat-app/prompts/features/等目录产出的标准化评测结果。评测思路是用逐级叠加的提示词驱动 LLM 在沙箱目录内生成完整可运行的实时聊天应用再用固定的评分细则grading_rubric.md逐项打分。1.1 Prompt 等级与功能映射提示词按功能编号从 1 到 15 逐级累加每一级在上一级基础上追加一个新功能等级越高要求越苛刻Prompt 等级包含功能满分01 基础聊天1–4基础、输入状态、已读回执、未读数1202 定时消息1–51503 实时消息1–6阅后即焚1804 表情回应1–72105 编辑历史1–82406 实时权限1–92707 在线状态1–103008 消息线程1–113309 私密房间1–12私密房间与私信3610 房间活跃度1–133911 草稿同步1–144212 匿名迁移1–1545本次评测使用09_private_rooms组合提示词对应 composed/09_private_rooms.md因此只对功能 1–12 打分13–15 不参与计分。这也是总分基数为 36 而非 45 的原因。1.2 单功能 0–3 分制每个功能按 0–3 分四级评价总分可精确到 0.5分数含义0未实现或完全不可用1部分实现存在重大缺陷或缺少核心功能2大体可用有次要缺陷或缺失边界情况3完全按规格实现N/A提示词未包含该功能不计入总分评测还记录了编译、运行、代码规模、依赖清单、首次即成功与重试次数等元指标用于横向对比不同模型、不同技术栈PostgreSQL / MongoDB / SpacetimeDB的实现质量。二、总体指标一次成功、零重试、76.4% 功能得分评分报告开篇给出了完整的总览数据指标数值Prompt 等级9私密房间评估功能范围1–12功能总分27.5 / 36百分比76.4%重试次数Reprompts0无错误编译✅无崩溃运行✅首次尝试成功无需人工修复✅后端代码行数1,689前端代码行数2,849创建文件数23外部依赖drizzle-orm、postgres、express、socket.io、jsonwebtoken、node-cron、react、socket.io-client三项✅意味着本次生成无需任何人工介入即可编译并运行且重试次数为 0——按评分细则中的重试效率表0 次重试对应满分 10 分首次即完美。这套元指标设计grading_rubric.md本意就是量化 LLM 第一次就接近正确的能力重试越少说明模型对需求的理解与实现的一次性成功率越高。2.1 技术栈与部署形态从同目录下的 README.md 可以确认实现的完整技术栈PostgreSQL 16 Node.js Express Socket.io Drizzle ORM后端React Vite TypeScript前端JWT 认证。服务划分与端口约定PostgreSQL5432后端 API / WebSocket3001前端开发服务器5174本地开发启动流程见 README 与 docker-compose.yml# 1. 启动 PostgreSQLDocker docker run -d --name postgres -e POSTGRES_PASSWORDpostgres -e POSTGRES_DBchat-app -p 5432:5432 postgres:16-alpine # 2. 启动后端先建表再起服务 cd server npm install npm run db:push # 通过 drizzle-kit 将 schema 推送到数据库 npm run dev # tsx watch src/index.ts端口 3001 # 3. 启动前端 cd client npm install npm run dev # 端口 5174 # 或一键使用 Docker Compose docker-compose up --build -ddocker-compose.yml 中postgres服务配置了健康检查pg_isreadyserver通过depends_on: condition: service_healthy等待数据库就绪DATABASE_URL、JWT_SECRET、PORT均通过环境变量注入。三、逐功能评分分析8 项满分、2 项失分、2 项零分3.1 满分项8 项实时链路完整闭环以下功能均获得满分 3 分说明它们在用户可见功能层面全部按规格工作功能关键验收点2. 输入状态指示状态广播给同房间成员、无活动自动过期、单/多用户两种文案5. 定时消息可预定未来发送、作者可见待发列表并可取消、到点准时入房6. 阅后即焚带自动删除计时器、UI 有倒计时/消失提示、到期后从数据库彻底删除7. 消息表情回应加回应、计数实时更新、可对自己回应切换开关、悬停显示回应者10. 在线状态online/away/dnd/invisible 四态、离线显示最后活跃 X 分钟前、状态实时同步、无操作自动置 away11. 消息线程可对指定消息回复开线程、父消息显示回复数与预览、线程视图完整、新回复实时同步12. 私密房间与私信可建邀请制私密房、按用户名邀请、双人私信可用、仅成员可见房间内容与成员列表其中功能 10、11、12 在评测备注中还标注了实现特征回复会同时出现在主视图Discord 风格、在线用户仅在私密房间显示这是功能 1 失分点见下。3.2 失分项功能 1、8、9 的扣分细节功能 1基础聊天2.0/3扣 1 分——6 个验收点中 4 个通过2 个被标注 BUG✅ 设置显示名0.5⚠️ 创建聊天室0.5——BUG房间在列表中重复出现两次⚠️ 加入/离开房间0.5——注意只有非管理员可以离开✅ 向已加入房间发送消息0.5⚠️ 在线用户展示0.5——BUG仅在私密房间中显示✅ 基础校验存在0.5功能 8消息编辑与历史2.5/3扣 0.5 分——编辑、(edited)标记、历史查看均通过但编辑历史弹窗在打开状态下不会实时刷新需要重新打开才能看到新版本因此实时同步一项只拿到 0.5 分中的一半。功能 9实时权限2/3扣 1 分——这是扣分最伤的一项✅ 房主即管理员可踢人/封禁0.5——备注踢人存在但不会强制断开被踢者的 socket 连接❌ 被踢者立即失去访问并停止接收更新0 分——客户端只是把房间从 UI 移除socket 仍然订阅着房间频道✅ 管理员可提拔他人为管理员0.5✅ 权限变更即时生效0.5报告给出的代码审查结论非常明确room:kicked事件在客户端只是移除 UI 中的房间没有发送room:leave来退出 socket.io room因此被踢用户会持续收到新消息直到刷新页面。这是权限在数据库层已生效、但在实时通道层失效的典型缺陷。3.3 零分项功能 3 与 4 的完整失败路径功能 3已读回执0/3——三个验收点全部未通过且失败模式一致不是实时只在重新进入房间时才会更新。❌ 系统追踪哪些用户看过哪些消息1 分未得——非实时仅在重新进入房间时更新❌ 消息下显示已由 X、Y、Z 查看指示器1 分未得——非实时❌ 已读状态实时更新1 分未得——不工作功能 4未读消息计数0/3——房间列表上的未读角标、按用户按房间追踪最后阅读位置、实时更新三个验收点全部未实现。从数据模型看这两个功能其实具备实现基础schema.ts 中room_members.last_read_at字段用于记录每用户每房间的最后阅读时间read_receipts表message_iduser_id唯一约束 read_at用于记录逐消息已读状态。README 中也定义了POST /api/rooms/:id/read标记已读与GET /api/rooms/unread获取未读数两个 REST 端点。也就是说存量数据能算出来但缺少将已读/未读变化实时推送到客户端的 Socket 事件链路导致只能进入房间时算一次无法实时刷新——这正是 0 分的根因。四、六个已知 BUG 的成因与修复方向评分报告将全部缺陷汇总为 6 条其中 5 条与实时性直接相关1 条与数据一致性相关| # | BUG | 类别 | 修复方向基于源码推断 | | -- | --- | ---- | ------------------------ | | 1 | 新建房间在房间列表重复出现 | 数据/状态 | 排查POST /api/rooms后前端本地追加 socketroom:created广播双写导致去重缺失可在客户端以 room id 做合并去重 | | 2 | 在线用户仅显示在私密房间 | 功能缺陷 | 公共房间缺少成员在线状态的订阅/广播链路 | | 3 | 已读回执非实时仅在重进房间时更新 | 实时链路缺失 | 已读标记写入read_receipts后需广播messages:read事件README 已声明该事件需确认服务端在已读 API 中真正 emit | | 4 | 未读计数不工作 | 未实现 | 未读角标需基于last_read_at与消息时间差计算并订阅新消息事件实时刷新 | | 5 | 编辑历史弹窗打开时不刷新 | 实时链路缺失 | 打开弹窗期间应订阅message:updated增量插入新版本 | | 6 | 被踢用户仍连接持续收消息直到刷新 | 权限/实时安全 | 服务端踢人时应socket.leave(roomId)或断开其 socket客户端收到room:kicked时应主动调用room:leave如 socket.ts 所示仅为单向连接管理缺少房间级订阅管理 |4.1 BUG 6 的源码佐证以 BUG 6 为例可以完整还原评分报告的代码审查结论与仓库源码的对应关系。客户端连接逻辑集中在 client/src/socket.tsconnectSocket仅负责用 JWT token 建立 socket 连接auth: { token }、transports: [websocket]并没有封装房间级订阅管理。当客户端收到room:kicked后移除 UI 中的房间却没有任何socket.emit(room:leave, roomId)调用服务端 socket.io room 中的订阅关系仍然保留——被踢者因此继续收到该房间的message:created广播。这与评分报告中直到页面刷新前仍持续接收消息的观察完全吻合。4.2 缺陷的共同模式REST 数据完整、实时通道断层从 server/src/index.ts1,818 行含 REST API、JWT 中间件、基于users.lastActionAt的 500ms 限流、以及 Socket.io 广播逻辑可以看出写数据库 → emit 事件是服务端的主流程例如注册成功后io.emit(user:online, { user })、改名后io.emit(user:updated, ...)、状态变更后io.emit(user:status, ...)。已读回执、未读计数、踢人这三个失败点恰恰落在事件链路没有打通的环节上。结合功能 2/5/6/7/10/11/12 全部满分可以推断模型对广播型实时功能谁都能收到实现稳定对个性化/条件型实时功能按用户、按权限筛选后再推送的链路容易遗漏。五、数据模型与 API 设计全景功能落地的仓库证据5.1 九张表的职责划分评分报告中 12 项功能的实现证据大部分可以直接映射到 server/src/db/schema.ts 的 Drizzle 表定义表支撑的功能关键字段users基础聊天、在线状态、限流display_name50 字符、statusonline/away/dnd/invisible、last_active_at、last_action_atrooms基础聊天、私密房间、私信is_private、is_dm、created_by级联删除room_members权限、未读数is_admin、is_banned、last_read_at(room_id, user_id)唯一约束room_invitations私密房间邀请statuspending/accepted/declined(room_id, invited_user_id)唯一约束messages消息、定时、阅后即焚、线程scheduled_for、expires_at、reply_to_id分别建索引message_edits编辑历史previous_content逐版本追加message_reactions表情回应(message_id, user_id, emoji)唯一约束实现切换开关read_receipts已读回执(message_id, user_id)唯一约束typing_indicators输入状态(room_id, user_id)唯一约束保证一人一房一条记录几个值得注意的设计细节定时消息通过scheduled_for字段 索引落地由node-cron定时任务扫描到期消息并投递依赖清单中的node-cron即服务于功能 5 与功能 6 的过期清理。阅后即焚的expires_at索引配合定时任务删除且评分要求从数据库彻底删除而非仅隐藏messages表上onDelete: cascade的设计让级联清理编辑历史、回执、回应成为可能。输入状态单独建表而非纯内存缓存意味着多节点部署时也能查询谁在输入。5.2 REST API 与 Socket 事件全景根据同目录 README.md应用对外暴露了完整的 REST WebSocket 双通道接口认证POST /api/auth/register用户GET/PATCH /api/users/me、PATCH /api/users/me/status、GET /api/users、GET /api/users/search?q房间GET/POST /api/rooms、POST /api/dms、POST /api/rooms/:id/join|leave、GET /api/rooms/:id/members、POST /api/rooms/:id/invite|kick/:userId|ban/:userId|promote/:userId邀请GET /api/invitations、POST /api/invitations/:id/accept|decline消息GET/POST /api/rooms/:id/messages、PATCH /api/messages/:id、GET /api/messages/:id/history|replies、GET /api/rooms/:id/scheduled、DELETE /api/messages/:id/scheduled回应POST /api/messages/:id/reactions切换、GET .../reactions已读POST /api/rooms/:id/read、GET /api/rooms/unreadSocket 事件分为两个方向客户端发送room:join、room:leave、typing:start、typing:stop、activity服务端广播user:online/offline/status/updated、room:created、room:member:joined/left/kicked/banned/promoted、room:kicked/banned、message:created/updated/deleted、thread:reply、reaction:added/removed、messages:read、typing:start/stop、invitation:received。将事件清单与六个 BUG 对照可以发现messages:read事件在协议层已经声明但实际评分显示已读状态无法实时更新——事件名存在 ≠ 事件被正确触发这正好呼应评分哲学中代码存在 ≠ 功能可用的核心观点。六、评分哲学面向用户功能而非实现工作量评分报告在末尾明确给出了打分原则这也是理解 27.5/36 这个数字的关键分数反映用户可见的功能表现而不是实现工作量——即使代码规模很大、表结构设计再完整用户流程走不通就不给分。代码存在不等于功能可用——功能 3、4 的失败正是数据结构与 REST 端点都在、但实时链路没打通。一个断裂的流程比没有流程更糟——例如功能 9 中踢人后 UI 消失但消息仍在收这种半实现状态会直接误导用户因而被判定为整项 0 分。这套哲学决定了评测的严格性满分功能必须端到端实时可用而不是看起来实现了。它同样解释了为什么功能 1 中两个 BUG房间重复、在线用户仅在私密房显示会各扣 0.5 分——它们虽然不影响主流程但属于用户可直接感知的错误状态。七、评测结果的工程启示综合评分表与缺陷分布可以提炼出对LLM 生成实时应用最有价值的四条结论1. 实时功能的成败在事件链路不在数据模型。九张表 完整 REST 端点说明模型在静态数据层几乎没有失误失分全部集中在事件是否实时推送这一动态环节。构建此类应用时应先为每个写操作明确写入后要 emit 哪些事件、推给哪些用户再实现业务逻辑。2. 个性化推送per-user/per-room 过滤是最高风险区。广播型功能输入状态、定时消息、阅后即焚、回应、状态、线程、私信全部满分而需要按用户计算并定向推送的已读回执、未读计数、踢人全部失分或零分。3. 权限变更必须穿透实时通道。功能 9 的教训是数据库里的is_banned置位了但如果服务端不把被踢者移出 socket.io room权限就形同虚设。权限相关的功能必须做通道层强制失效验证。4. 0 次重试与 76.4% 的组合极具参考价值。按评分细则中的综合分公式功能分/满分 × 70重试效率 × 3估算本次实现约为27.5/36 × 70 10 × 3 ≈ 83.5对应良好75–89区间。它表明当前模型在长提示词Level 9 叠加 12 个功能 UI 契约下一次成型的稳定性已相当高剩余差距集中在实时一致性与权限边界处理上——这也正是 LLM 编码基准中把失败点收敛到可复现、可度量的价值所在。若要在本地复现或继续验证本评测可参考 apps/chat-app/prompts/ 下的base_postgres.md、grading_rubric.md、composed/09_private_rooms.md与features/目录完整代码与部署文件位于 chat-app-20260104-120000 目录按 README 中的步骤即可启动并逐项复测。【免费下载链接】SpacetimeDBDevelopment at the speed of light项目地址: https://gitcode.com/GitHub_Trending/sp/SpacetimeDB创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
SpacetimeDB 仓库 LLM 编码基准：PostgreSQL 实时聊天应用 12 项功能评测结果深度解析（76.4% 得分与 6 处已知缺陷）
SpacetimeDB 仓库 LLM 编码基准PostgreSQL 实时聊天应用 12 项功能评测结果深度解析76.4% 得分与 6 处已知缺陷【免费下载链接】SpacetimeDBDevelopment at the speed of light项目地址: https://gitcode.com/GitHub_Trending/sp/SpacetimeDB导读本文基于 SpacetimeDB 仓库中tools/llm-oneshot基准测试框架产出的评分报告完整还原 Claude Opus 4.5 在 Prompt Level 9Private Rooms提示词下、使用 PostgreSQL 技术栈生成的 Discord 风格实时聊天应用的评测全过程总得分 27.5/3676.4%、0 次重试、12 项功能中 8 项满分、6 处已知 BUG 被逐一定位。读者可以借此掌握该基准的评分体系0–3 分制、Prompt 等级映射、重试效率折算、每项功能做到什么程度才能拿满分以及从数据库表结构与 Socket 事件设计中反推功能实现与缺陷成因的方法。一、评测背景llm-oneshot 基准如何量化 LLM 编码能力这份评分报告是仓库tools/llm-oneshot工具链含apps/chat-app、apps/chat-app/prompts/、apps/chat-app/prompts/composed/、apps/chat-app/prompts/features/等目录产出的标准化评测结果。评测思路是用逐级叠加的提示词驱动 LLM 在沙箱目录内生成完整可运行的实时聊天应用再用固定的评分细则grading_rubric.md逐项打分。1.1 Prompt 等级与功能映射提示词按功能编号从 1 到 15 逐级累加每一级在上一级基础上追加一个新功能等级越高要求越苛刻Prompt 等级包含功能满分01 基础聊天1–4基础、输入状态、已读回执、未读数1202 定时消息1–51503 实时消息1–6阅后即焚1804 表情回应1–72105 编辑历史1–82406 实时权限1–92707 在线状态1–103008 消息线程1–113309 私密房间1–12私密房间与私信3610 房间活跃度1–133911 草稿同步1–144212 匿名迁移1–1545本次评测使用09_private_rooms组合提示词对应 composed/09_private_rooms.md因此只对功能 1–12 打分13–15 不参与计分。这也是总分基数为 36 而非 45 的原因。1.2 单功能 0–3 分制每个功能按 0–3 分四级评价总分可精确到 0.5分数含义0未实现或完全不可用1部分实现存在重大缺陷或缺少核心功能2大体可用有次要缺陷或缺失边界情况3完全按规格实现N/A提示词未包含该功能不计入总分评测还记录了编译、运行、代码规模、依赖清单、首次即成功与重试次数等元指标用于横向对比不同模型、不同技术栈PostgreSQL / MongoDB / SpacetimeDB的实现质量。二、总体指标一次成功、零重试、76.4% 功能得分评分报告开篇给出了完整的总览数据指标数值Prompt 等级9私密房间评估功能范围1–12功能总分27.5 / 36百分比76.4%重试次数Reprompts0无错误编译✅无崩溃运行✅首次尝试成功无需人工修复✅后端代码行数1,689前端代码行数2,849创建文件数23外部依赖drizzle-orm、postgres、express、socket.io、jsonwebtoken、node-cron、react、socket.io-client三项✅意味着本次生成无需任何人工介入即可编译并运行且重试次数为 0——按评分细则中的重试效率表0 次重试对应满分 10 分首次即完美。这套元指标设计grading_rubric.md本意就是量化 LLM 第一次就接近正确的能力重试越少说明模型对需求的理解与实现的一次性成功率越高。2.1 技术栈与部署形态从同目录下的 README.md 可以确认实现的完整技术栈PostgreSQL 16 Node.js Express Socket.io Drizzle ORM后端React Vite TypeScript前端JWT 认证。服务划分与端口约定PostgreSQL5432后端 API / WebSocket3001前端开发服务器5174本地开发启动流程见 README 与 docker-compose.yml# 1. 启动 PostgreSQLDocker docker run -d --name postgres -e POSTGRES_PASSWORDpostgres -e POSTGRES_DBchat-app -p 5432:5432 postgres:16-alpine # 2. 启动后端先建表再起服务 cd server npm install npm run db:push # 通过 drizzle-kit 将 schema 推送到数据库 npm run dev # tsx watch src/index.ts端口 3001 # 3. 启动前端 cd client npm install npm run dev # 端口 5174 # 或一键使用 Docker Compose docker-compose up --build -ddocker-compose.yml 中postgres服务配置了健康检查pg_isreadyserver通过depends_on: condition: service_healthy等待数据库就绪DATABASE_URL、JWT_SECRET、PORT均通过环境变量注入。三、逐功能评分分析8 项满分、2 项失分、2 项零分3.1 满分项8 项实时链路完整闭环以下功能均获得满分 3 分说明它们在用户可见功能层面全部按规格工作功能关键验收点2. 输入状态指示状态广播给同房间成员、无活动自动过期、单/多用户两种文案5. 定时消息可预定未来发送、作者可见待发列表并可取消、到点准时入房6. 阅后即焚带自动删除计时器、UI 有倒计时/消失提示、到期后从数据库彻底删除7. 消息表情回应加回应、计数实时更新、可对自己回应切换开关、悬停显示回应者10. 在线状态online/away/dnd/invisible 四态、离线显示最后活跃 X 分钟前、状态实时同步、无操作自动置 away11. 消息线程可对指定消息回复开线程、父消息显示回复数与预览、线程视图完整、新回复实时同步12. 私密房间与私信可建邀请制私密房、按用户名邀请、双人私信可用、仅成员可见房间内容与成员列表其中功能 10、11、12 在评测备注中还标注了实现特征回复会同时出现在主视图Discord 风格、在线用户仅在私密房间显示这是功能 1 失分点见下。3.2 失分项功能 1、8、9 的扣分细节功能 1基础聊天2.0/3扣 1 分——6 个验收点中 4 个通过2 个被标注 BUG✅ 设置显示名0.5⚠️ 创建聊天室0.5——BUG房间在列表中重复出现两次⚠️ 加入/离开房间0.5——注意只有非管理员可以离开✅ 向已加入房间发送消息0.5⚠️ 在线用户展示0.5——BUG仅在私密房间中显示✅ 基础校验存在0.5功能 8消息编辑与历史2.5/3扣 0.5 分——编辑、(edited)标记、历史查看均通过但编辑历史弹窗在打开状态下不会实时刷新需要重新打开才能看到新版本因此实时同步一项只拿到 0.5 分中的一半。功能 9实时权限2/3扣 1 分——这是扣分最伤的一项✅ 房主即管理员可踢人/封禁0.5——备注踢人存在但不会强制断开被踢者的 socket 连接❌ 被踢者立即失去访问并停止接收更新0 分——客户端只是把房间从 UI 移除socket 仍然订阅着房间频道✅ 管理员可提拔他人为管理员0.5✅ 权限变更即时生效0.5报告给出的代码审查结论非常明确room:kicked事件在客户端只是移除 UI 中的房间没有发送room:leave来退出 socket.io room因此被踢用户会持续收到新消息直到刷新页面。这是权限在数据库层已生效、但在实时通道层失效的典型缺陷。3.3 零分项功能 3 与 4 的完整失败路径功能 3已读回执0/3——三个验收点全部未通过且失败模式一致不是实时只在重新进入房间时才会更新。❌ 系统追踪哪些用户看过哪些消息1 分未得——非实时仅在重新进入房间时更新❌ 消息下显示已由 X、Y、Z 查看指示器1 分未得——非实时❌ 已读状态实时更新1 分未得——不工作功能 4未读消息计数0/3——房间列表上的未读角标、按用户按房间追踪最后阅读位置、实时更新三个验收点全部未实现。从数据模型看这两个功能其实具备实现基础schema.ts 中room_members.last_read_at字段用于记录每用户每房间的最后阅读时间read_receipts表message_iduser_id唯一约束 read_at用于记录逐消息已读状态。README 中也定义了POST /api/rooms/:id/read标记已读与GET /api/rooms/unread获取未读数两个 REST 端点。也就是说存量数据能算出来但缺少将已读/未读变化实时推送到客户端的 Socket 事件链路导致只能进入房间时算一次无法实时刷新——这正是 0 分的根因。四、六个已知 BUG 的成因与修复方向评分报告将全部缺陷汇总为 6 条其中 5 条与实时性直接相关1 条与数据一致性相关| # | BUG | 类别 | 修复方向基于源码推断 | | -- | --- | ---- | ------------------------ | | 1 | 新建房间在房间列表重复出现 | 数据/状态 | 排查POST /api/rooms后前端本地追加 socketroom:created广播双写导致去重缺失可在客户端以 room id 做合并去重 | | 2 | 在线用户仅显示在私密房间 | 功能缺陷 | 公共房间缺少成员在线状态的订阅/广播链路 | | 3 | 已读回执非实时仅在重进房间时更新 | 实时链路缺失 | 已读标记写入read_receipts后需广播messages:read事件README 已声明该事件需确认服务端在已读 API 中真正 emit | | 4 | 未读计数不工作 | 未实现 | 未读角标需基于last_read_at与消息时间差计算并订阅新消息事件实时刷新 | | 5 | 编辑历史弹窗打开时不刷新 | 实时链路缺失 | 打开弹窗期间应订阅message:updated增量插入新版本 | | 6 | 被踢用户仍连接持续收消息直到刷新 | 权限/实时安全 | 服务端踢人时应socket.leave(roomId)或断开其 socket客户端收到room:kicked时应主动调用room:leave如 socket.ts 所示仅为单向连接管理缺少房间级订阅管理 |4.1 BUG 6 的源码佐证以 BUG 6 为例可以完整还原评分报告的代码审查结论与仓库源码的对应关系。客户端连接逻辑集中在 client/src/socket.tsconnectSocket仅负责用 JWT token 建立 socket 连接auth: { token }、transports: [websocket]并没有封装房间级订阅管理。当客户端收到room:kicked后移除 UI 中的房间却没有任何socket.emit(room:leave, roomId)调用服务端 socket.io room 中的订阅关系仍然保留——被踢者因此继续收到该房间的message:created广播。这与评分报告中直到页面刷新前仍持续接收消息的观察完全吻合。4.2 缺陷的共同模式REST 数据完整、实时通道断层从 server/src/index.ts1,818 行含 REST API、JWT 中间件、基于users.lastActionAt的 500ms 限流、以及 Socket.io 广播逻辑可以看出写数据库 → emit 事件是服务端的主流程例如注册成功后io.emit(user:online, { user })、改名后io.emit(user:updated, ...)、状态变更后io.emit(user:status, ...)。已读回执、未读计数、踢人这三个失败点恰恰落在事件链路没有打通的环节上。结合功能 2/5/6/7/10/11/12 全部满分可以推断模型对广播型实时功能谁都能收到实现稳定对个性化/条件型实时功能按用户、按权限筛选后再推送的链路容易遗漏。五、数据模型与 API 设计全景功能落地的仓库证据5.1 九张表的职责划分评分报告中 12 项功能的实现证据大部分可以直接映射到 server/src/db/schema.ts 的 Drizzle 表定义表支撑的功能关键字段users基础聊天、在线状态、限流display_name50 字符、statusonline/away/dnd/invisible、last_active_at、last_action_atrooms基础聊天、私密房间、私信is_private、is_dm、created_by级联删除room_members权限、未读数is_admin、is_banned、last_read_at(room_id, user_id)唯一约束room_invitations私密房间邀请statuspending/accepted/declined(room_id, invited_user_id)唯一约束messages消息、定时、阅后即焚、线程scheduled_for、expires_at、reply_to_id分别建索引message_edits编辑历史previous_content逐版本追加message_reactions表情回应(message_id, user_id, emoji)唯一约束实现切换开关read_receipts已读回执(message_id, user_id)唯一约束typing_indicators输入状态(room_id, user_id)唯一约束保证一人一房一条记录几个值得注意的设计细节定时消息通过scheduled_for字段 索引落地由node-cron定时任务扫描到期消息并投递依赖清单中的node-cron即服务于功能 5 与功能 6 的过期清理。阅后即焚的expires_at索引配合定时任务删除且评分要求从数据库彻底删除而非仅隐藏messages表上onDelete: cascade的设计让级联清理编辑历史、回执、回应成为可能。输入状态单独建表而非纯内存缓存意味着多节点部署时也能查询谁在输入。5.2 REST API 与 Socket 事件全景根据同目录 README.md应用对外暴露了完整的 REST WebSocket 双通道接口认证POST /api/auth/register用户GET/PATCH /api/users/me、PATCH /api/users/me/status、GET /api/users、GET /api/users/search?q房间GET/POST /api/rooms、POST /api/dms、POST /api/rooms/:id/join|leave、GET /api/rooms/:id/members、POST /api/rooms/:id/invite|kick/:userId|ban/:userId|promote/:userId邀请GET /api/invitations、POST /api/invitations/:id/accept|decline消息GET/POST /api/rooms/:id/messages、PATCH /api/messages/:id、GET /api/messages/:id/history|replies、GET /api/rooms/:id/scheduled、DELETE /api/messages/:id/scheduled回应POST /api/messages/:id/reactions切换、GET .../reactions已读POST /api/rooms/:id/read、GET /api/rooms/unreadSocket 事件分为两个方向客户端发送room:join、room:leave、typing:start、typing:stop、activity服务端广播user:online/offline/status/updated、room:created、room:member:joined/left/kicked/banned/promoted、room:kicked/banned、message:created/updated/deleted、thread:reply、reaction:added/removed、messages:read、typing:start/stop、invitation:received。将事件清单与六个 BUG 对照可以发现messages:read事件在协议层已经声明但实际评分显示已读状态无法实时更新——事件名存在 ≠ 事件被正确触发这正好呼应评分哲学中代码存在 ≠ 功能可用的核心观点。六、评分哲学面向用户功能而非实现工作量评分报告在末尾明确给出了打分原则这也是理解 27.5/36 这个数字的关键分数反映用户可见的功能表现而不是实现工作量——即使代码规模很大、表结构设计再完整用户流程走不通就不给分。代码存在不等于功能可用——功能 3、4 的失败正是数据结构与 REST 端点都在、但实时链路没打通。一个断裂的流程比没有流程更糟——例如功能 9 中踢人后 UI 消失但消息仍在收这种半实现状态会直接误导用户因而被判定为整项 0 分。这套哲学决定了评测的严格性满分功能必须端到端实时可用而不是看起来实现了。它同样解释了为什么功能 1 中两个 BUG房间重复、在线用户仅在私密房显示会各扣 0.5 分——它们虽然不影响主流程但属于用户可直接感知的错误状态。七、评测结果的工程启示综合评分表与缺陷分布可以提炼出对LLM 生成实时应用最有价值的四条结论1. 实时功能的成败在事件链路不在数据模型。九张表 完整 REST 端点说明模型在静态数据层几乎没有失误失分全部集中在事件是否实时推送这一动态环节。构建此类应用时应先为每个写操作明确写入后要 emit 哪些事件、推给哪些用户再实现业务逻辑。2. 个性化推送per-user/per-room 过滤是最高风险区。广播型功能输入状态、定时消息、阅后即焚、回应、状态、线程、私信全部满分而需要按用户计算并定向推送的已读回执、未读计数、踢人全部失分或零分。3. 权限变更必须穿透实时通道。功能 9 的教训是数据库里的is_banned置位了但如果服务端不把被踢者移出 socket.io room权限就形同虚设。权限相关的功能必须做通道层强制失效验证。4. 0 次重试与 76.4% 的组合极具参考价值。按评分细则中的综合分公式功能分/满分 × 70重试效率 × 3估算本次实现约为27.5/36 × 70 10 × 3 ≈ 83.5对应良好75–89区间。它表明当前模型在长提示词Level 9 叠加 12 个功能 UI 契约下一次成型的稳定性已相当高剩余差距集中在实时一致性与权限边界处理上——这也正是 LLM 编码基准中把失败点收敛到可复现、可度量的价值所在。若要在本地复现或继续验证本评测可参考 apps/chat-app/prompts/ 下的base_postgres.md、grading_rubric.md、composed/09_private_rooms.md与features/目录完整代码与部署文件位于 chat-app-20260104-120000 目录按 README 中的步骤即可启动并逐项复测。【免费下载链接】SpacetimeDBDevelopment at the speed of light项目地址: https://gitcode.com/GitHub_Trending/sp/SpacetimeDB创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
