尧图网页设计 
SpacetimeDB 仓库 one-shot 基准评测深度解读PostgreSQL 版 AI 生成聊天应用的 23/36 评分全析【免费下载链接】SpacetimeDBDevelopment at the speed of light项目地址: https://gitcode.com/GitHub_Trending/sp/SpacetimeDB导读本文聚焦 tools/llm-oneshot 基准工程产出的一份真实评测记录——chat-app-20260104-180000/GRADING_RESULTS.md它完整记录了一次由 Claude Opus 4.5 单次生成one-shot的 PostgreSQL 实时聊天应用在 12 项功能上的逐项打分、11 条关键缺陷与评分方法论。读者读完本文后将掌握该基准的评分规则如何运作、PostgreSQL 技术栈实现下各功能的真实表现与失分原因并能据此理解AI 生成应用离可交付的实时系统还有多远这一核心结论以及如何用同一套 rubric 复现评估。一、评测背景one-shot 应用生成基准与本次测试样本1.1 基准工程定位tools/llm-oneshot/README.md 的定位是评测 AI在 Cursor 等 IDE 中能否在单次尝试内生成并部署一个可用的应用。它采用同一份聊天应用需求、两个平台对照的路线SpacetimeDB——实时数据库客户端自动同步PostgreSQL——传统数据库需要手动实现 WebSocket 广播。本次评测对象是 PostgreSQL 分支Express Drizzle ORM Socket.io React的技术栈由Claude Opus 4.5生成生成时间为 2026-01-04。1.2 生成产物概况评测针对的实际应用位于tools/llm-oneshot/apps/chat-app/typescript/opus-4-5/postgres/chat-app-20260104-180000/其规模指标如下指标数值后端代码行数backend LOC1,131前端代码行数frontend LOC2,222创建文件数20外部依赖drizzle-orm、postgres、express、socket.io、jsonwebtoken、cors、react、socket.io-client应用本身是一套 Discord 风格的聊天系统产物 README 记录了完整的 REST API 与 Socket.io 事件清单详见chat-app-20260104-180000/README.md运行方式为docker-compose up --build前端默认访问http://localhost:5174服务端端口 3001数据库使用 PostgreSQL 16Docker 容器见同目录 docker-compose.yml。1.3 本次评测的 Prompt 级别评分表明确标注Prompt Level 909_postgres_private_rooms.md即累计到第 9 级私密房间与私信的提示词组合。依据 grading_rubric.md 的Prompt-to-Feature 映射表级别 09 覆盖功能 1–12最大分值为36 分12 项 × 3 分功能 13–15房间活跃度、草稿同步、匿名迁移不在该级别内记为 N/A 不计分。二、总体评分23.0 / 3663.9%指标数值使用的提示词级别909_postgres_private_rooms.md被评估功能1–12最大 15功能总得分23.0 / 36百分比63.9%三项硬性通过项均为通过✅ 无错误编译Compiles without errors✅ 无崩溃运行Runs without crashing✅ 首次尝试成功First-try success0 次重新提示得分背后的哲学文档Scoring Philosophy一节值得注意评分反映的是面向用户的功能可用性而非实现工作量。三条准则分别是存在关键 bug 破坏用户流程的功能获得最低或零分代码存在 ≠ 功能可用一个坏掉的流程比没有流程更糟会迷惑用户。这正是Reactions 功能代码全写了却得 0 分的原因所在见下文第四部分。三、功能逐项评分详解Feature 1–12下面按文档原表逐项展开给出得分、判定理由与文档中记录的实测批注。3.1 功能 1基础聊天2.0 / 3子项得分批注用户可设置显示名0.5通过用户可创建聊天房间0.5通过用户可加入/离开房间0必须先刷新页面才能加入房间名大量重复同时仍显示当前房间内容——不刷新基本不可用用户可向已加入房间发消息0.5通过在线用户展示0.25Members 视图中不显示在线用户基础校验存在0.25通过基础聊天是聊天应用的命脉却因加入/离开房间需刷新、房间名重复这一核心流程缺陷只拿到 2/3 分——这是文档坏掉的流程比没有流程更糟的典型体现。3.2 功能 2正在输入指示3 / 3满分三个子项各得 1 分输入状态广播给同房间成员、无操作后自动过期、UI 显示User is typing...或Multiple users are typing...。这是本次 12 项功能中唯一一个在房间级作用域、过期机制、多用户文案三层全部达标的功能。对照 09_private_rooms.md 中typing 必须限定在房间内、不得广播给其他房间用户的 UI 契约该实现完全满足要求。3.3 功能 3已读回执2.5 / 3✅ 系统追踪哪些用户看过哪些消息1⚠️ Seen by X, Y, Z 指示器显示在消息下方0.5——名字位置不断互换如 ted, bradley → bradley, ted 来回翻转✅ 已读状态实时更新1名字乱序翻转看似是小问题但它直接影响已读回执信息的可读性故扣 0.5 分。这一缺陷暗示服务端在聚合看过该消息的用户列表时缺少稳定的排序键。3.4 功能 4未读消息计数1.0 / 3弱项之一⚠️ 房间列表显示未读角标0.5——计数不一致⚠️ 计数按每用户每房间最后阅读位置追踪0.5——不一致❌ 计数实时更新0——进入房间后计数不会归零未读计数是用户感知新消息的核心交互三要素中实时更新完全失效导致整个功能只有 1/3。按 rubric 的测试用例用户 A 打开房间 2 → 角标清除该用例未通过。3.5 功能 5定时消息1.5 / 3⚠️ 用户可编写并安排未来时间投递0.5——点击发送后响应极慢❌ 待发消息对作者可见并可取消0——显示很慢且无法取消✅ 消息在设定时间出现在房间1——但非实时更新可能需刷新定时投递本身实现了但作者管理待发队列这一半功能缺失且发送链路严重迟滞得分不足一半。3.6 功能 6阅后即焚消息3 / 3满分✅ 用户可发送带自动删除计时器的消息1✅ UI 显示倒计时或消失指示1✅ 计时器到期后消息被永久删除1文档批注强调是永久删除而非仅从 UI 隐藏符合 rubric 测试用例检查数据库/存储确认消息真的被删除。这是第二个满分项。3.7 功能 7消息表情回应0 / 3彻底失败❌ 用户可对消息添加 emoji 反应0❌ 反应计数显示并实时更新0❌ 用户可开关自己的反应0❌ 悬停/点击显示谁做出了反应0文档标注该功能看起来完全不工作Feature appears completely non-functional。虽然产物 README 声称实现了 5 种 emoji ❤️ 、开关与悬停查看且服务端存在POST /api/messages/:id/reactions接口与message:reactions:updated事件但评分坚持以用户可感知的结果为准——代码存在不等于功能可用。3.8 功能 8带历史的消息编辑2.75 / 3✅ 用户可编辑自己的消息1✅ 编辑后显示 (edited) 指示0.5✅ 其他用户可查看编辑历史1⚠️ 编辑实时同步给所有查看者0.25——历史窗口打开时编辑不实时更新编辑链路基本完整仅在历史面板打开状态下实时性上有欠缺是得分最高的功能之一。3.9 功能 9实时权限1.25 / 3✅ 房间创建者为管理员可踢人/封禁1❌ 被踢用户立即失去访问权并停止接收更新0⚠️ 管理员可将他人提升为管理员0.25——更新非常迟缓❌ 权限变更即时生效0——不生效权限是安全敏感功能服务端虽有kick/ban/promote接口见产物 README 的/api/rooms/:id/kick/:userId、/ban/:userId、/promote/:userId但被踢用户仍持有 WebSocket 连接、权限更新迟滞说明服务端缺少主动断开/强制订阅撤销机制导致即时性全面失守。3.10 功能 10富用户在线状态2.5 / 3✅ 用户可设置状态在线、离开、勿扰、隐身1✅ 离线用户显示X 分钟前活跃0.5⚠️ 状态变更实时同步给所有查看者0.5——在 Members 视图不显示✅ 超过无活动周期自动置为away0.5产物 README 提到自动离线阈值 5 分钟、状态含 invisible基本实现完整扣分点同样集中在成员面板的可见性缺失上。3.11 功能 11消息线程1.5 / 3⚠️ 用户可回复特定消息创建线程0.5——页面刷新后线程消失⚠️ 父消息显示回复数与预览0.5——不实时更新⚠️ 线程视图展示某消息的全部回复0.5——加载有延迟非实时❌ 新回复实时同步给线程查看者0线程功能的四要素全部差一口气最致命的是线程数据不持久刷新即丢与无实时推送。3.12 功能 12私密房间与私信2.0 / 3✅ 用户可创建私密/仅邀请房间0.75⚠️ 创建者可按用户名邀请用户0.25——用户无法正常接受或拒绝邀请✅ 两人之间私信DM可用0.75✅ 仅成员可查看私密房间内容与成员列表0.25服务端提供了完整的邀请链路POST /api/invites/:id/accept、/decline见产物 README但接受/拒绝邀请这一闭环交互不可用使邀请能力形同虚设。3.13 汇总记分表原文档完整继承功能满分得分重新提示次数1. 基础聊天32.002. 输入指示3303. 已读回执32.504. 未读计数31.005. 定时消息31.506. 阅后即焚3307. 表情回应3008. 消息编辑32.7509. 实时权限31.25010. 在线状态32.5011. 消息线程31.5012. 私密房间与私信32.00总计3623.00值得注意全部 12 项的重提示次数均为 0即这份结果是一次生成、立即评测的原始成绩没有经过任何修复迭代的掺水。四、关键缺陷清单Critical Issues原文档列出的 11 条关键缺陷按严重度整理如下它们也是前述失分的直接证据加入/离开房间损坏——加入前必须刷新页面房间名大量重复且仍显示当前房间内容不刷新不可用表情回应完全损坏——功能看似未实现已读回执名字闪烁——Seen by X, Y 中的名字来回互换位置未读计数不清零——进入房间后角标计数不为 0定时消息缓慢/损坏——点击发送后响应极慢且无法取消已排定的消息被踢用户未断开——被踢/被封禁用户不会立即失去 WebSocket 访问权限更新迟滞——管理员晋升在 UI 中反映非常慢状态不在成员面板显示——用户状态变化在侧边栏 Members 视图不可见线程不持久——页面刷新后线程视图消失线程回复非实时——必须关闭并重开线程面板才能看到新回复加载缓慢邀请接受/拒绝损坏——用户无法正常接受或拒绝房间邀请。归纳这 11 条缺陷可以提炼出三条共性模式实时性缺失最普遍第 4、5、7、9、10、11 条本质上都是状态变更没有通过 Socket.io 推送、需要刷新或重开面板的问题。对于一个以 Socket.io 为实时基座的应用这指向事件广播覆盖不全如线程房间、未读计数通道未接入io广播。状态一致性不稳第 1、3、4 条属于服务端状态聚合或前端本地状态管理混乱房间列表重复、已读名单乱序、计数不归零。权限/连接生命周期不闭环第 6、7、11 条表明服务端缺少踢人即断开连接邀请可接受/拒绝这类闭环操作。五、评分方法论为什么能用比有代码更重要本评测的评分哲学Scoring Philosophy是整个文档的方法论核心它决定了一张 63.9% 的成绩单该如何被解读面向用户功能打分评分只看用户能否顺畅完成操作不按实现难度或代码量计分关键 bug 一票否决破坏用户流程的功能获得最低或零分——这正是 Reactions 从代码齐备到0 分的原因坏流程比没流程更糟一个点了没反应、需要刷新才能用的按钮对用户的伤害大于根本没有该按钮。配套的评分尺度来自 grading_rubric.md 的 0–3 分制可以反推每个分数档的含义得分含义0未实现或完全损坏1部分实现存在重大问题或核心功能缺失2大体可用有次要 bug 或边界情况缺失3完全符合规格N/A提示词未包含的功能不计入总分此外 rubric 还提供了可选的综合分公式用于跨平台对比综合分 (功能得分 / 满分 × 70) (重新提示效率 × 3)功能完整度占 70%、迭代效率占 30%满分 100本样本重提示效率为 10/100 次重提示若需与 SpacetimeDB 分支横向对比可直接套用该公式。六、技术背景被测应用的实际技术构成为了让评分结论可复核这里补充被测应用的真实技术构成均来自生成产物目录而非评测文档之外的猜测后端Express.js Socket.io 负责实时推送Drizzle ORM 对接 PostgreSQL服务端核心在chat-app-20260104-180000/server/src/index.ts约 1,601 行含 JWT 中间件authenticateToken、REST 路由与 Socket 事件前端React Vite TypeScriptsocket.io-client建立实时通道client/src/socket.ts认证JWT token 存于 localStorage注册接口对显示名做 1–50 字符的校验数据库PostgreSQL 16Docker 容器由 docker-compose.yml 编排postgres 服务 健康检查server 依赖其就绪后再启动限流消息发送间隔限制为 500ms对应提示词中合理校验禁止刷屏的要求。从 09_private_rooms.md 的 UI 契约反向对照可知评测者实际是按输入框 placeholder 含 message/room/name、按钮文本含 Create/Join/Leave、状态圆点绿在线黄离开红勿扰灰隐身等可自动化测试的 DOM 契约进行逐项验证的这也解释了为何评分记录如此具体、可复现。七、结论与可复用价值这份 GRADING_RESULTS.md 的价值不仅在于一份成绩单更在于它是一份可复用的评测模板评分表结构、缺陷清单格式、总分 硬性通过项 功能明细 关键问题 哲学说明的文档骨架可以直接套用于任何一次 one-shot 生成应用的验收。从本次 23/3663.9%的结果中可以得出三点务实结论能编译、能跑、一次成功只是及格线——该应用三项硬性通过项全绿但用户可感知的功能完成度只有六成出头实时应用的最短板几乎都集中在实时二字——11 条关键缺陷中过半是不刷新不生效非实时更新说明 AI 生成代码时容易把服务端算好当作推送给了客户端Socket 事件广播的覆盖范围是最大的薄弱环节评分要看用户流程闭环——Reactions 与 Invite 的 0 分/扣分证明接口存在、数据表存在、甚至事件已定义都不等于用户在界面上能完成操作。对于希望复现评测的读者完整流程可参考 tools/llm-oneshot/README.md在 Cursor 中打开tools/llm-oneshot作为工作区拖入apps/chat-app/prompts/language/typescript-postgres.md与apps/chat-app/prompts/composed/09_private_rooms.md两个提示词文件输入Read all rules first...后让 AI 一次性生成再按 grading_rubric.md 逐项打分并输出同样的 GRADING_RESULTS.md多份结果可通过pnpm run summarize聚合到docs/llms/下形成跨模型、跨平台的对比报告。【免费下载链接】SpacetimeDBDevelopment at the speed of light项目地址: https://gitcode.com/GitHub_Trending/sp/SpacetimeDB创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 SpacetimeDB 仓库 one-shot 基准评测深度解读：PostgreSQL 版 AI 生成聊天应用的 23/36 评分全析
SpacetimeDB 仓库 one-shot 基准评测深度解读PostgreSQL 版 AI 生成聊天应用的 23/36 评分全析【免费下载链接】SpacetimeDBDevelopment at the speed of light项目地址: https://gitcode.com/GitHub_Trending/sp/SpacetimeDB导读本文聚焦 tools/llm-oneshot 基准工程产出的一份真实评测记录——chat-app-20260104-180000/GRADING_RESULTS.md它完整记录了一次由 Claude Opus 4.5 单次生成one-shot的 PostgreSQL 实时聊天应用在 12 项功能上的逐项打分、11 条关键缺陷与评分方法论。读者读完本文后将掌握该基准的评分规则如何运作、PostgreSQL 技术栈实现下各功能的真实表现与失分原因并能据此理解AI 生成应用离可交付的实时系统还有多远这一核心结论以及如何用同一套 rubric 复现评估。一、评测背景one-shot 应用生成基准与本次测试样本1.1 基准工程定位tools/llm-oneshot/README.md 的定位是评测 AI在 Cursor 等 IDE 中能否在单次尝试内生成并部署一个可用的应用。它采用同一份聊天应用需求、两个平台对照的路线SpacetimeDB——实时数据库客户端自动同步PostgreSQL——传统数据库需要手动实现 WebSocket 广播。本次评测对象是 PostgreSQL 分支Express Drizzle ORM Socket.io React的技术栈由Claude Opus 4.5生成生成时间为 2026-01-04。1.2 生成产物概况评测针对的实际应用位于tools/llm-oneshot/apps/chat-app/typescript/opus-4-5/postgres/chat-app-20260104-180000/其规模指标如下指标数值后端代码行数backend LOC1,131前端代码行数frontend LOC2,222创建文件数20外部依赖drizzle-orm、postgres、express、socket.io、jsonwebtoken、cors、react、socket.io-client应用本身是一套 Discord 风格的聊天系统产物 README 记录了完整的 REST API 与 Socket.io 事件清单详见chat-app-20260104-180000/README.md运行方式为docker-compose up --build前端默认访问http://localhost:5174服务端端口 3001数据库使用 PostgreSQL 16Docker 容器见同目录 docker-compose.yml。1.3 本次评测的 Prompt 级别评分表明确标注Prompt Level 909_postgres_private_rooms.md即累计到第 9 级私密房间与私信的提示词组合。依据 grading_rubric.md 的Prompt-to-Feature 映射表级别 09 覆盖功能 1–12最大分值为36 分12 项 × 3 分功能 13–15房间活跃度、草稿同步、匿名迁移不在该级别内记为 N/A 不计分。二、总体评分23.0 / 3663.9%指标数值使用的提示词级别909_postgres_private_rooms.md被评估功能1–12最大 15功能总得分23.0 / 36百分比63.9%三项硬性通过项均为通过✅ 无错误编译Compiles without errors✅ 无崩溃运行Runs without crashing✅ 首次尝试成功First-try success0 次重新提示得分背后的哲学文档Scoring Philosophy一节值得注意评分反映的是面向用户的功能可用性而非实现工作量。三条准则分别是存在关键 bug 破坏用户流程的功能获得最低或零分代码存在 ≠ 功能可用一个坏掉的流程比没有流程更糟会迷惑用户。这正是Reactions 功能代码全写了却得 0 分的原因所在见下文第四部分。三、功能逐项评分详解Feature 1–12下面按文档原表逐项展开给出得分、判定理由与文档中记录的实测批注。3.1 功能 1基础聊天2.0 / 3子项得分批注用户可设置显示名0.5通过用户可创建聊天房间0.5通过用户可加入/离开房间0必须先刷新页面才能加入房间名大量重复同时仍显示当前房间内容——不刷新基本不可用用户可向已加入房间发消息0.5通过在线用户展示0.25Members 视图中不显示在线用户基础校验存在0.25通过基础聊天是聊天应用的命脉却因加入/离开房间需刷新、房间名重复这一核心流程缺陷只拿到 2/3 分——这是文档坏掉的流程比没有流程更糟的典型体现。3.2 功能 2正在输入指示3 / 3满分三个子项各得 1 分输入状态广播给同房间成员、无操作后自动过期、UI 显示User is typing...或Multiple users are typing...。这是本次 12 项功能中唯一一个在房间级作用域、过期机制、多用户文案三层全部达标的功能。对照 09_private_rooms.md 中typing 必须限定在房间内、不得广播给其他房间用户的 UI 契约该实现完全满足要求。3.3 功能 3已读回执2.5 / 3✅ 系统追踪哪些用户看过哪些消息1⚠️ Seen by X, Y, Z 指示器显示在消息下方0.5——名字位置不断互换如 ted, bradley → bradley, ted 来回翻转✅ 已读状态实时更新1名字乱序翻转看似是小问题但它直接影响已读回执信息的可读性故扣 0.5 分。这一缺陷暗示服务端在聚合看过该消息的用户列表时缺少稳定的排序键。3.4 功能 4未读消息计数1.0 / 3弱项之一⚠️ 房间列表显示未读角标0.5——计数不一致⚠️ 计数按每用户每房间最后阅读位置追踪0.5——不一致❌ 计数实时更新0——进入房间后计数不会归零未读计数是用户感知新消息的核心交互三要素中实时更新完全失效导致整个功能只有 1/3。按 rubric 的测试用例用户 A 打开房间 2 → 角标清除该用例未通过。3.5 功能 5定时消息1.5 / 3⚠️ 用户可编写并安排未来时间投递0.5——点击发送后响应极慢❌ 待发消息对作者可见并可取消0——显示很慢且无法取消✅ 消息在设定时间出现在房间1——但非实时更新可能需刷新定时投递本身实现了但作者管理待发队列这一半功能缺失且发送链路严重迟滞得分不足一半。3.6 功能 6阅后即焚消息3 / 3满分✅ 用户可发送带自动删除计时器的消息1✅ UI 显示倒计时或消失指示1✅ 计时器到期后消息被永久删除1文档批注强调是永久删除而非仅从 UI 隐藏符合 rubric 测试用例检查数据库/存储确认消息真的被删除。这是第二个满分项。3.7 功能 7消息表情回应0 / 3彻底失败❌ 用户可对消息添加 emoji 反应0❌ 反应计数显示并实时更新0❌ 用户可开关自己的反应0❌ 悬停/点击显示谁做出了反应0文档标注该功能看起来完全不工作Feature appears completely non-functional。虽然产物 README 声称实现了 5 种 emoji ❤️ 、开关与悬停查看且服务端存在POST /api/messages/:id/reactions接口与message:reactions:updated事件但评分坚持以用户可感知的结果为准——代码存在不等于功能可用。3.8 功能 8带历史的消息编辑2.75 / 3✅ 用户可编辑自己的消息1✅ 编辑后显示 (edited) 指示0.5✅ 其他用户可查看编辑历史1⚠️ 编辑实时同步给所有查看者0.25——历史窗口打开时编辑不实时更新编辑链路基本完整仅在历史面板打开状态下实时性上有欠缺是得分最高的功能之一。3.9 功能 9实时权限1.25 / 3✅ 房间创建者为管理员可踢人/封禁1❌ 被踢用户立即失去访问权并停止接收更新0⚠️ 管理员可将他人提升为管理员0.25——更新非常迟缓❌ 权限变更即时生效0——不生效权限是安全敏感功能服务端虽有kick/ban/promote接口见产物 README 的/api/rooms/:id/kick/:userId、/ban/:userId、/promote/:userId但被踢用户仍持有 WebSocket 连接、权限更新迟滞说明服务端缺少主动断开/强制订阅撤销机制导致即时性全面失守。3.10 功能 10富用户在线状态2.5 / 3✅ 用户可设置状态在线、离开、勿扰、隐身1✅ 离线用户显示X 分钟前活跃0.5⚠️ 状态变更实时同步给所有查看者0.5——在 Members 视图不显示✅ 超过无活动周期自动置为away0.5产物 README 提到自动离线阈值 5 分钟、状态含 invisible基本实现完整扣分点同样集中在成员面板的可见性缺失上。3.11 功能 11消息线程1.5 / 3⚠️ 用户可回复特定消息创建线程0.5——页面刷新后线程消失⚠️ 父消息显示回复数与预览0.5——不实时更新⚠️ 线程视图展示某消息的全部回复0.5——加载有延迟非实时❌ 新回复实时同步给线程查看者0线程功能的四要素全部差一口气最致命的是线程数据不持久刷新即丢与无实时推送。3.12 功能 12私密房间与私信2.0 / 3✅ 用户可创建私密/仅邀请房间0.75⚠️ 创建者可按用户名邀请用户0.25——用户无法正常接受或拒绝邀请✅ 两人之间私信DM可用0.75✅ 仅成员可查看私密房间内容与成员列表0.25服务端提供了完整的邀请链路POST /api/invites/:id/accept、/decline见产物 README但接受/拒绝邀请这一闭环交互不可用使邀请能力形同虚设。3.13 汇总记分表原文档完整继承功能满分得分重新提示次数1. 基础聊天32.002. 输入指示3303. 已读回执32.504. 未读计数31.005. 定时消息31.506. 阅后即焚3307. 表情回应3008. 消息编辑32.7509. 实时权限31.25010. 在线状态32.5011. 消息线程31.5012. 私密房间与私信32.00总计3623.00值得注意全部 12 项的重提示次数均为 0即这份结果是一次生成、立即评测的原始成绩没有经过任何修复迭代的掺水。四、关键缺陷清单Critical Issues原文档列出的 11 条关键缺陷按严重度整理如下它们也是前述失分的直接证据加入/离开房间损坏——加入前必须刷新页面房间名大量重复且仍显示当前房间内容不刷新不可用表情回应完全损坏——功能看似未实现已读回执名字闪烁——Seen by X, Y 中的名字来回互换位置未读计数不清零——进入房间后角标计数不为 0定时消息缓慢/损坏——点击发送后响应极慢且无法取消已排定的消息被踢用户未断开——被踢/被封禁用户不会立即失去 WebSocket 访问权限更新迟滞——管理员晋升在 UI 中反映非常慢状态不在成员面板显示——用户状态变化在侧边栏 Members 视图不可见线程不持久——页面刷新后线程视图消失线程回复非实时——必须关闭并重开线程面板才能看到新回复加载缓慢邀请接受/拒绝损坏——用户无法正常接受或拒绝房间邀请。归纳这 11 条缺陷可以提炼出三条共性模式实时性缺失最普遍第 4、5、7、9、10、11 条本质上都是状态变更没有通过 Socket.io 推送、需要刷新或重开面板的问题。对于一个以 Socket.io 为实时基座的应用这指向事件广播覆盖不全如线程房间、未读计数通道未接入io广播。状态一致性不稳第 1、3、4 条属于服务端状态聚合或前端本地状态管理混乱房间列表重复、已读名单乱序、计数不归零。权限/连接生命周期不闭环第 6、7、11 条表明服务端缺少踢人即断开连接邀请可接受/拒绝这类闭环操作。五、评分方法论为什么能用比有代码更重要本评测的评分哲学Scoring Philosophy是整个文档的方法论核心它决定了一张 63.9% 的成绩单该如何被解读面向用户功能打分评分只看用户能否顺畅完成操作不按实现难度或代码量计分关键 bug 一票否决破坏用户流程的功能获得最低或零分——这正是 Reactions 从代码齐备到0 分的原因坏流程比没流程更糟一个点了没反应、需要刷新才能用的按钮对用户的伤害大于根本没有该按钮。配套的评分尺度来自 grading_rubric.md 的 0–3 分制可以反推每个分数档的含义得分含义0未实现或完全损坏1部分实现存在重大问题或核心功能缺失2大体可用有次要 bug 或边界情况缺失3完全符合规格N/A提示词未包含的功能不计入总分此外 rubric 还提供了可选的综合分公式用于跨平台对比综合分 (功能得分 / 满分 × 70) (重新提示效率 × 3)功能完整度占 70%、迭代效率占 30%满分 100本样本重提示效率为 10/100 次重提示若需与 SpacetimeDB 分支横向对比可直接套用该公式。六、技术背景被测应用的实际技术构成为了让评分结论可复核这里补充被测应用的真实技术构成均来自生成产物目录而非评测文档之外的猜测后端Express.js Socket.io 负责实时推送Drizzle ORM 对接 PostgreSQL服务端核心在chat-app-20260104-180000/server/src/index.ts约 1,601 行含 JWT 中间件authenticateToken、REST 路由与 Socket 事件前端React Vite TypeScriptsocket.io-client建立实时通道client/src/socket.ts认证JWT token 存于 localStorage注册接口对显示名做 1–50 字符的校验数据库PostgreSQL 16Docker 容器由 docker-compose.yml 编排postgres 服务 健康检查server 依赖其就绪后再启动限流消息发送间隔限制为 500ms对应提示词中合理校验禁止刷屏的要求。从 09_private_rooms.md 的 UI 契约反向对照可知评测者实际是按输入框 placeholder 含 message/room/name、按钮文本含 Create/Join/Leave、状态圆点绿在线黄离开红勿扰灰隐身等可自动化测试的 DOM 契约进行逐项验证的这也解释了为何评分记录如此具体、可复现。七、结论与可复用价值这份 GRADING_RESULTS.md 的价值不仅在于一份成绩单更在于它是一份可复用的评测模板评分表结构、缺陷清单格式、总分 硬性通过项 功能明细 关键问题 哲学说明的文档骨架可以直接套用于任何一次 one-shot 生成应用的验收。从本次 23/3663.9%的结果中可以得出三点务实结论能编译、能跑、一次成功只是及格线——该应用三项硬性通过项全绿但用户可感知的功能完成度只有六成出头实时应用的最短板几乎都集中在实时二字——11 条关键缺陷中过半是不刷新不生效非实时更新说明 AI 生成代码时容易把服务端算好当作推送给了客户端Socket 事件广播的覆盖范围是最大的薄弱环节评分要看用户流程闭环——Reactions 与 Invite 的 0 分/扣分证明接口存在、数据表存在、甚至事件已定义都不等于用户在界面上能完成操作。对于希望复现评测的读者完整流程可参考 tools/llm-oneshot/README.md在 Cursor 中打开tools/llm-oneshot作为工作区拖入apps/chat-app/prompts/language/typescript-postgres.md与apps/chat-app/prompts/composed/09_private_rooms.md两个提示词文件输入Read all rules first...后让 AI 一次性生成再按 grading_rubric.md 逐项打分并输出同样的 GRADING_RESULTS.md多份结果可通过pnpm run summarize聚合到docs/llms/下形成跨模型、跨平台的对比报告。【免费下载链接】SpacetimeDBDevelopment at the speed of light项目地址: https://gitcode.com/GitHub_Trending/sp/SpacetimeDB创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考