SpacetimeDB llm-oneshot 基准深潜Gemini 3 Pro 用 TypeScript/PostgreSQL 一次性生成 Chat App 的完整评分解析【免费下载链接】SpacetimeDBDevelopment at the speed of light项目地址: https://gitcode.com/GitHub_Trending/sp/SpacetimeDB本文基于 SpacetimeDB 仓库tools/llm-oneshot基准目录下的一份真实评测产物——GRADING_RESULTS.md完整还原「AI 模型一次性one-shot生成实时聊天应用」的评分过程与结果使用 5 级提示词含编辑历史、在 PostgreSQL 平台上生成的 TypeScript Chat App最终功能得分 17.25/2471.9%。读完本文你将理解这套 one-shot 基准的评分方法论提示词等级 → 功能映射 → 0~3 分制、逐项功能得分背后的源码级证据CSS 特异性 Bug、定时消息轮询机制、六表数据库架构以及部署阶段踩过的典型 Docker 坑位。一、评测背景llm-oneshot 是什么测了谁SpacetimeDB 仓库内置了一个「AI 一次性生成应用」基准工具位于 tools/llm-oneshot。其目标是量化评估在提供 Cursor 规则文件的前提下不同 AI 模型能否一次性生成并部署一个可运行的应用且重点对比两类后端平台SpacetimeDB——自带客户端同步的实时数据库PostgreSQL——需要开发者手动写 WebSocket 广播的传统方案作为基线。生成结果按固定目录结构归档便于跨应用、跨模型、跨平台对比apps/{app-name}/{language}/{model}/{platform}/{app-name}-{YYYYMMDD-HHMMSS}/本文的主角正是其中一份归档apps/chat-app/typescript/gemini-3-pro/postgres/chat-app-20260108-120000/即chat-app 基准 × TypeScript 语言栈 × Gemini 3 Pro 模型 × PostgreSQL 平台生成于 2026-01-08。评测使用的提示词为 语言栈提示词 加上 composed/05_edit_history.md第 5 级功能组合。按 llm-oneshot 运行指南一次标准评测的操作流程是在 Cursor 中以tools/llm-oneshot为工作区根目录打开项目保证加载规则文件新建 Agent 聊天面板选择被测模型把语言栈提示词与功能等级提示词两个文件拖入聊天框发送固定指令Read all rules first. Do not reference AI-generated apps in apps/ for guidance. Execute these prompts.让模型完整跑完生成不中断部署时选择 Local生成后按规则文件 grading_rubric.md 进行人工评分AI 先做浅层检查并在应用目录下产出GRADING_RESULTS.md。刻意隔离已有应用是该基准的关键设计指令明确要求模型不得参考apps/下已有的生成结果否则无法区分「成功来自规则引导」还是「来自照抄」。二、评分方法论等级映射、0–3 分制与综合得分评分规则定义在 grading_rubric.md其核心机制有三点1. 提示词等级 → 功能范围 → 满分映射。功能等级是累积式的第 N 级包含第 1 至 N 级的所有功能且只对提示词中实际包含的功能计分提示词等级包含功能满分01_basic1–4基础聊天、输入中指示、已读回执、未读计数1202_scheduled1–5 定时消息1503_realtime1–6 阅后即焚消息1804_reactions1–7 消息表情回应2105_edit_history本次评测1–8 消息编辑历史2406_permissions及以上1–15全部功能27–452. 每项功能 0–3 分制0 未实现或完全损坏1 部分实现、核心功能缺失或问题严重2 基本可用、有轻微 Bug 或边界情况缺失3 完全按规格工作。未包含在提示词中的功能记 N/A不计入总分。3. 附加度量指标除功能分外评分表还要求记录编译是否通过、运行是否崩溃、后端/前端代码行数、创建文件数、外部依赖清单、「一次成功first-try success」以及复提示reprompt次数与效率分。复提示效率分从 0 次复提示 10 分一路递减到 16 次以上 0 分用于衡量模型「离可用方案还有多远」。可选的综合得分公式为(功能得分/满分 × 70) (复提示效率 × 3)满分 100权重上功能完整度占 70%、迭代效率占 30%。三、本次评测的总体指标来自 GRADING_RESULTS.md 的头部数据指标数值使用的提示词等级505_postgres_edit_history.md评估的功能范围1–8满分 24功能总分17.25 / 24得分率71.9%无错误编译通过无崩溃运行通过一次成功first-try success是后端代码行数568前端代码行数778创建文件数28外部依赖清单drizzle-orm, postgres, express, socket.io, jsonwebtoken, zod, react, react-router-dom, date-fns, lucide-react——一套典型的「Express Socket.IO Drizzle ORM React」实时应用全家桶其中 Socket.IO 承担了 SpacetimeDB 场景下由平台原生同步替代的广播职责这正体现了基准对比的意图PostgreSQL 基线需要更多手写实时逻辑。四、逐项功能得分8 项功能逐条拆解Feature 1基础聊天2 / 3评分项得分说明设置显示名0.5通过创建聊天室0.5通过加入/离开房间—无加入/离开 UI向已加入房间发消息0.5通过显示在线用户—未实现基础校验0.5所有端点使用 zod 校验扣分点在后端源码中可以得到印证server/src/index.ts 定义了room:join/room:leave两个 Socket 事件仅让 socket 进出room:{roomId}频道但数据库层面根本没有「房间成员」表——GET /api/rooms直接返回全部房间所以「所有房间对所有用户可见」加入/离开概念缺失。评分记录的 Known Issue #4 与此一致。Feature 2输入中指示3 / 3满分输入状态广播给房间内其他成员1 分输入指示在停止输入后自动过期1 分——客户端 2 秒超时UI 显示 User is typing... 或 Multiple users are typing...1 分。对应实现位于 index.ts 的 Socket 处理段服务端监听typing:start/typing:stop向room:{roomId}频道转发typing:started/typing:stopped事件过期完全由客户端定时器处理服务端保持无状态。Feature 3已读回执3 / 3满分系统追踪哪些用户看过哪些消息1 分消息下方显示 Seen by X, Y, Z1 分已读状态实时更新1 分。服务端实现是POST /api/rooms/:roomId/read对message_reads表做「查存在则更新、否则插入」的 upsert写入lastReadMessageId随后向房间频道广播room:read_updated事件——所以已读状态经 Socket 实时推送而非轮询。Feature 4未读消息计数2.5 / 3房间列表上显示未读角标1 分按「每用户每房间最后已读位置」追踪计数1 分实时更新1 分——未拿到分使用 5 秒轮询而非真正的实时推送。轮询实现与服务端查询逻辑可对照 index.ts 中的GET /api/rooms它对每个房间查一次message_reads拿lastReadMessageId再count(*)统计id lastReadId且「已到期」的消息数。这个查询还内嵌了一个细节——未读计数只统计scheduledFor IS NULL OR scheduledFor now()的消息未到期定时消息不计入未读逻辑是正确的但客户端每 5 秒才重新请求一次该接口故失掉「实时」那 1 分。Feature 5定时消息2 / 3可为未来投递创建并排程消息1 分待发送定时消息对作者可见且可取消1 分——BUG客户端忽略了 POST 响应消息不显示且无取消选项消息在预定时间出现在房间1 分——由服务端周期任务投递。服务端的投递机制在 index.ts 末尾的setInterval1 秒一跳中查出scheduledFor now的消息把scheduledFor置为 NULL 标记「已发送」再向房间频道广播message:created。而POST /api/rooms/:roomId/messages在收到消息时其实已经res.json(msg)返回了完整消息对象——评分指出的 Bug 正在于客户端没有消费这个响应导致排程消息要等刷新页面或真正投递后才可见。消息列表接口侧倒是做了配套设计查询条件为「普通消息或已到期消息或者本人的待发送消息」即作者本就能看到自己的 pending 消息但缺了前端 UI取消按钮、pending 列表渲染。Feature 6阅后即焚消息3 / 3满分可发送带自动删除定时器的消息1 分UI 显示倒计时/消失指示1 分——实现为实时倒计时 Expires in Xs定时器到期后消息被永久删除1 分——由服务端周期任务清理。投递与清理共用同一个 1 秒setInterval创建消息时由expiresInSeconds计算expiresAt基于排程时间或当前时间周期任务对expiresAt now的记录执行delete ... returning()随后向房间广播message:deleted事件让各客户端同步移除——是「真删除」而非前端隐藏。Feature 7消息表情回应0.75 / 3——本次最大失分项添加 emoji 回应0.75——BUG按钮被 CSS 特异性问题隐藏无法发起首次回应回应计数显示并实时更新0.75——后端实现正确开关自己的回应0.75——无法触达入口悬停/点击显示谁回应了0.75——未实现。根因评分已点明.message-actions容器带有内联display: noneCSS 悬停规则无法覆盖它。这条根因可以从前端源码逐字印证——client/src/components/MessageItem.tsx 中回应/编辑按钮区写死为div classNamemessage-actions style{{ display: none, // Shown via CSS ... }} 而同文件 MessageItem.tsx 内嵌的样式期望.message-item:hover .message-actions { display: flex; }按 CSS 层叠规则内联样式优先级高于任何选择器规则除非规则使用!important所以悬停规则永远生效不了按钮「永久隐身」。讽刺的是后端完全是好的POST /api/messages/:messageId/reactions实现了完整的 toggle 语义查到同消息同用户同 emoji 则删除否则插入并附带返回用户名信息后向房间广播message:updated——前端只是够不到入口。Feature 8消息编辑与历史1 / 3可编辑自己的消息1 分——BUG编辑按钮与回应按钮同处被隐藏的.message-actions中已编辑消息显示 (edited) 标记0.5 分——逻辑上可工作若编辑功能可用他人可查看编辑历史1 分——未实现数据已入库但无 UI编辑实时同步给所有查看者0.5 分——逻辑上可工作若编辑功能可用。编辑后端在 index.ts 的PUT /api/messages/:messageId先校验所有权非本人返回 403把旧内容插入message_edits表留痕再更新消息正文与editedAt最后广播message:updated。数据链路完整但被同一个 CSS Bug 卡死在 UI 入口。Feature 9–15未评估权限、富在线状态、线程、私有房间/私聊、活跃度指示、草稿同步、匿名迁移——这 7 项不在第 5 级提示词范围内记 N/A不计分。汇总得分表功能满分得分1. 基础聊天322. 输入中指示333. 已读回执334. 未读计数32.55. 定时消息326. 阅后即焚337. 表情回应30.758. 消息编辑31总计2417.2571.9%五、架构佐证六表 Schema、Socket.IO 与周期任务评分记录的技术笔记写道后端 Node.js Express Socket.IO Drizzle ORMPostgreSQL 16Docker前端 React 18 ViteJWT 认证24 小时过期六张表。这与归档内的实际源码逐一对应。server/src/db/schema.ts 定义了 6 张表及 Drizzle relations表关键字段支撑的功能usersuuid 主键随机默认、唯一用户名认证主体roomsserial 主键、唯一名称房间messagesscheduled_for、expires_at、edited_at三个可空时间戳定时、阅后即焚、编辑——三套功能复用同一张表message_edits指向消息的外键、旧内容、编辑时间编辑历史留痕reactions消息用户emoji 三元组表情回应message_reads房间用户、last_read_message_id已读回执与未读计数所有外键均配置onDelete: cascade删用户/删房间会级联清理关联数据。messages表用三个可空时间戳同时承载 Feature 5/6/8是「一个 Schema 服务多项功能」的典型设计。实时性方面index.ts 展示了传统栈的完整分工REST登录/房间/消息/编辑/回应/已读等状态写入全部走 HTTP且每个写端点在落库后手动触发一次io.to(room: roomId).emit(...)广播Socket.IO仅承载高频、低价值的事件输入中指示、房间加入/离开并用 JWT 做握手鉴权io.use中间件校验socket.handshake.auth.token周期任务单一setInterval1 秒串行处理「到期定时消息投递」与「过期消息清理」两个批处理。对比之下这也是 SpacetimeDB 一侧想验证的命题若使用 SpacetimeDB 模块订阅同步、定时/清理类触发器可由平台承接手写 WebSocket 广播与轮询代码量会显著减少——基准的对比价值正在于此。六、部署问题Docker 三连坑评分记录了首次部署不成功的三个原因且都能在归档文件中找到痕迹Docker 代理配置错误——Vite 代理被写死为localhost:3001而容器网络中应指向服务名server:3001需要完整重建容器——配置改动必须docker-compose down up --build才生效端口冲突——PostgreSQL 默认 5432 与宿主机本地实例冲突。最终修复体现在 docker-compose.yml 中services: postgres: image: postgres:16-alpine ports: - 5433:5432 # 宿主机映射改为 5433规避本地 5432 冲突 environment: POSTGRES_DB: chat-app server: build: ./server ports: [3001:3001] environment: DATABASE_URL: postgres://postgres:passwordpostgres:5432/chat-app JWT_SECRET: chat-app-20260108-120000-secret client: build: ./client ports: [5173:5173] environment: VITE_API_URL: http://server:3001 # 容器网络内以服务名寻址注意DATABASE_URL使用容器网络内的postgres:5432容器间仍走标准端口只有对外映射改成 5433——这是解决端口冲突的正确姿势只改宿主机映射而不动内部连接串。七、已知问题清单与评分结论评分文档将问题分为三档关键 BugCSS 特异性 Bug回应与编辑——内联style{{ display: none }}压过悬停 CSS 规则按钮永久不可见源码证据见上文 MessageItem.tsx定时消息不显示——POST 响应被客户端忽略需刷新页面或等待实际投递后才出现定时消息无取消 UI。缺失功能4. 无加入/离开房间 UI所有房间对所有人可见 5. 无在线用户显示 6. 无编辑历史查看器数据已入库UI 缺失 7. 无「谁点了回应」的展示数据存在无悬停提示。次要问题8. 未读计数用 5 秒轮询而非 Socket 实时推送。从源码结构看这份 71.9% 的分数呈现出清晰的模式数据层与服务端链路完成度很高六表 Schema 完整、鉴权、zod 校验、toggle 语义、级联清理全部就位失分集中在最后一公里的前端交互——一个 CSS 特异性错误同时拖垮了 Feature 7 和 8 两项合计 7 分中只拿到 1.75加上几处「数据已就绪、UI 未接线」的缺口。这对使用该基准的团队是一个有参考价值的结论在「一次生成」约束下模型倾向于把复杂度堆进后端而 UI 的可见性细节按钮可触达性、悬停交互、轮询 vs 推送的取舍是需要人工复核或复提示修补的重灾区。八、如何复用这套评测与结果聚合如果你想在自己的模型/平台组合上复现这次评测仓库给出的路径是按 llm-oneshot 运行指南 在 Cursor 中运行生成提示词组合参考 prompts 目录language/下选语言栈composed/下选功能等级features/下是各单项功能的原子定义按 grading_rubric.md 人工评分并写入应用目录的GRADING_RESULTS.md聚合所有已评分应用cd tools/llm-oneshot pnpm install pnpm run summarize输出到仓库顶层 docs/llms/oneshot-summary.md含功能分汇总与 oneshot-grades.json结构化数据。同一提示词等级下仓库还归档了其他模型的同平台/跨平台结果如typescript/gpt-5-2/postgres、typescript/grok-code/spacetime等目录可逐份对照各自的GRADING_RESULTS.md完成 rubric 中「Comparison Template」表格——功能总分、一次成功率、前后端代码行数、复提示次数与效率分、综合得分——从而得出针对具体任务与提示词等级、可辩护的模型间结论而非泛泛的「谁更强」。【免费下载链接】SpacetimeDBDevelopment at the speed of light项目地址: https://gitcode.com/GitHub_Trending/sp/SpacetimeDB创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 SpacetimeDB llm-oneshot 基准深潜：Gemini 3 Pro 用 TypeScript/PostgreSQL 一次性生成 Chat App 的完整评分解析
SpacetimeDB llm-oneshot 基准深潜Gemini 3 Pro 用 TypeScript/PostgreSQL 一次性生成 Chat App 的完整评分解析【免费下载链接】SpacetimeDBDevelopment at the speed of light项目地址: https://gitcode.com/GitHub_Trending/sp/SpacetimeDB本文基于 SpacetimeDB 仓库tools/llm-oneshot基准目录下的一份真实评测产物——GRADING_RESULTS.md完整还原「AI 模型一次性one-shot生成实时聊天应用」的评分过程与结果使用 5 级提示词含编辑历史、在 PostgreSQL 平台上生成的 TypeScript Chat App最终功能得分 17.25/2471.9%。读完本文你将理解这套 one-shot 基准的评分方法论提示词等级 → 功能映射 → 0~3 分制、逐项功能得分背后的源码级证据CSS 特异性 Bug、定时消息轮询机制、六表数据库架构以及部署阶段踩过的典型 Docker 坑位。一、评测背景llm-oneshot 是什么测了谁SpacetimeDB 仓库内置了一个「AI 一次性生成应用」基准工具位于 tools/llm-oneshot。其目标是量化评估在提供 Cursor 规则文件的前提下不同 AI 模型能否一次性生成并部署一个可运行的应用且重点对比两类后端平台SpacetimeDB——自带客户端同步的实时数据库PostgreSQL——需要开发者手动写 WebSocket 广播的传统方案作为基线。生成结果按固定目录结构归档便于跨应用、跨模型、跨平台对比apps/{app-name}/{language}/{model}/{platform}/{app-name}-{YYYYMMDD-HHMMSS}/本文的主角正是其中一份归档apps/chat-app/typescript/gemini-3-pro/postgres/chat-app-20260108-120000/即chat-app 基准 × TypeScript 语言栈 × Gemini 3 Pro 模型 × PostgreSQL 平台生成于 2026-01-08。评测使用的提示词为 语言栈提示词 加上 composed/05_edit_history.md第 5 级功能组合。按 llm-oneshot 运行指南一次标准评测的操作流程是在 Cursor 中以tools/llm-oneshot为工作区根目录打开项目保证加载规则文件新建 Agent 聊天面板选择被测模型把语言栈提示词与功能等级提示词两个文件拖入聊天框发送固定指令Read all rules first. Do not reference AI-generated apps in apps/ for guidance. Execute these prompts.让模型完整跑完生成不中断部署时选择 Local生成后按规则文件 grading_rubric.md 进行人工评分AI 先做浅层检查并在应用目录下产出GRADING_RESULTS.md。刻意隔离已有应用是该基准的关键设计指令明确要求模型不得参考apps/下已有的生成结果否则无法区分「成功来自规则引导」还是「来自照抄」。二、评分方法论等级映射、0–3 分制与综合得分评分规则定义在 grading_rubric.md其核心机制有三点1. 提示词等级 → 功能范围 → 满分映射。功能等级是累积式的第 N 级包含第 1 至 N 级的所有功能且只对提示词中实际包含的功能计分提示词等级包含功能满分01_basic1–4基础聊天、输入中指示、已读回执、未读计数1202_scheduled1–5 定时消息1503_realtime1–6 阅后即焚消息1804_reactions1–7 消息表情回应2105_edit_history本次评测1–8 消息编辑历史2406_permissions及以上1–15全部功能27–452. 每项功能 0–3 分制0 未实现或完全损坏1 部分实现、核心功能缺失或问题严重2 基本可用、有轻微 Bug 或边界情况缺失3 完全按规格工作。未包含在提示词中的功能记 N/A不计入总分。3. 附加度量指标除功能分外评分表还要求记录编译是否通过、运行是否崩溃、后端/前端代码行数、创建文件数、外部依赖清单、「一次成功first-try success」以及复提示reprompt次数与效率分。复提示效率分从 0 次复提示 10 分一路递减到 16 次以上 0 分用于衡量模型「离可用方案还有多远」。可选的综合得分公式为(功能得分/满分 × 70) (复提示效率 × 3)满分 100权重上功能完整度占 70%、迭代效率占 30%。三、本次评测的总体指标来自 GRADING_RESULTS.md 的头部数据指标数值使用的提示词等级505_postgres_edit_history.md评估的功能范围1–8满分 24功能总分17.25 / 24得分率71.9%无错误编译通过无崩溃运行通过一次成功first-try success是后端代码行数568前端代码行数778创建文件数28外部依赖清单drizzle-orm, postgres, express, socket.io, jsonwebtoken, zod, react, react-router-dom, date-fns, lucide-react——一套典型的「Express Socket.IO Drizzle ORM React」实时应用全家桶其中 Socket.IO 承担了 SpacetimeDB 场景下由平台原生同步替代的广播职责这正体现了基准对比的意图PostgreSQL 基线需要更多手写实时逻辑。四、逐项功能得分8 项功能逐条拆解Feature 1基础聊天2 / 3评分项得分说明设置显示名0.5通过创建聊天室0.5通过加入/离开房间—无加入/离开 UI向已加入房间发消息0.5通过显示在线用户—未实现基础校验0.5所有端点使用 zod 校验扣分点在后端源码中可以得到印证server/src/index.ts 定义了room:join/room:leave两个 Socket 事件仅让 socket 进出room:{roomId}频道但数据库层面根本没有「房间成员」表——GET /api/rooms直接返回全部房间所以「所有房间对所有用户可见」加入/离开概念缺失。评分记录的 Known Issue #4 与此一致。Feature 2输入中指示3 / 3满分输入状态广播给房间内其他成员1 分输入指示在停止输入后自动过期1 分——客户端 2 秒超时UI 显示 User is typing... 或 Multiple users are typing...1 分。对应实现位于 index.ts 的 Socket 处理段服务端监听typing:start/typing:stop向room:{roomId}频道转发typing:started/typing:stopped事件过期完全由客户端定时器处理服务端保持无状态。Feature 3已读回执3 / 3满分系统追踪哪些用户看过哪些消息1 分消息下方显示 Seen by X, Y, Z1 分已读状态实时更新1 分。服务端实现是POST /api/rooms/:roomId/read对message_reads表做「查存在则更新、否则插入」的 upsert写入lastReadMessageId随后向房间频道广播room:read_updated事件——所以已读状态经 Socket 实时推送而非轮询。Feature 4未读消息计数2.5 / 3房间列表上显示未读角标1 分按「每用户每房间最后已读位置」追踪计数1 分实时更新1 分——未拿到分使用 5 秒轮询而非真正的实时推送。轮询实现与服务端查询逻辑可对照 index.ts 中的GET /api/rooms它对每个房间查一次message_reads拿lastReadMessageId再count(*)统计id lastReadId且「已到期」的消息数。这个查询还内嵌了一个细节——未读计数只统计scheduledFor IS NULL OR scheduledFor now()的消息未到期定时消息不计入未读逻辑是正确的但客户端每 5 秒才重新请求一次该接口故失掉「实时」那 1 分。Feature 5定时消息2 / 3可为未来投递创建并排程消息1 分待发送定时消息对作者可见且可取消1 分——BUG客户端忽略了 POST 响应消息不显示且无取消选项消息在预定时间出现在房间1 分——由服务端周期任务投递。服务端的投递机制在 index.ts 末尾的setInterval1 秒一跳中查出scheduledFor now的消息把scheduledFor置为 NULL 标记「已发送」再向房间频道广播message:created。而POST /api/rooms/:roomId/messages在收到消息时其实已经res.json(msg)返回了完整消息对象——评分指出的 Bug 正在于客户端没有消费这个响应导致排程消息要等刷新页面或真正投递后才可见。消息列表接口侧倒是做了配套设计查询条件为「普通消息或已到期消息或者本人的待发送消息」即作者本就能看到自己的 pending 消息但缺了前端 UI取消按钮、pending 列表渲染。Feature 6阅后即焚消息3 / 3满分可发送带自动删除定时器的消息1 分UI 显示倒计时/消失指示1 分——实现为实时倒计时 Expires in Xs定时器到期后消息被永久删除1 分——由服务端周期任务清理。投递与清理共用同一个 1 秒setInterval创建消息时由expiresInSeconds计算expiresAt基于排程时间或当前时间周期任务对expiresAt now的记录执行delete ... returning()随后向房间广播message:deleted事件让各客户端同步移除——是「真删除」而非前端隐藏。Feature 7消息表情回应0.75 / 3——本次最大失分项添加 emoji 回应0.75——BUG按钮被 CSS 特异性问题隐藏无法发起首次回应回应计数显示并实时更新0.75——后端实现正确开关自己的回应0.75——无法触达入口悬停/点击显示谁回应了0.75——未实现。根因评分已点明.message-actions容器带有内联display: noneCSS 悬停规则无法覆盖它。这条根因可以从前端源码逐字印证——client/src/components/MessageItem.tsx 中回应/编辑按钮区写死为div classNamemessage-actions style{{ display: none, // Shown via CSS ... }} 而同文件 MessageItem.tsx 内嵌的样式期望.message-item:hover .message-actions { display: flex; }按 CSS 层叠规则内联样式优先级高于任何选择器规则除非规则使用!important所以悬停规则永远生效不了按钮「永久隐身」。讽刺的是后端完全是好的POST /api/messages/:messageId/reactions实现了完整的 toggle 语义查到同消息同用户同 emoji 则删除否则插入并附带返回用户名信息后向房间广播message:updated——前端只是够不到入口。Feature 8消息编辑与历史1 / 3可编辑自己的消息1 分——BUG编辑按钮与回应按钮同处被隐藏的.message-actions中已编辑消息显示 (edited) 标记0.5 分——逻辑上可工作若编辑功能可用他人可查看编辑历史1 分——未实现数据已入库但无 UI编辑实时同步给所有查看者0.5 分——逻辑上可工作若编辑功能可用。编辑后端在 index.ts 的PUT /api/messages/:messageId先校验所有权非本人返回 403把旧内容插入message_edits表留痕再更新消息正文与editedAt最后广播message:updated。数据链路完整但被同一个 CSS Bug 卡死在 UI 入口。Feature 9–15未评估权限、富在线状态、线程、私有房间/私聊、活跃度指示、草稿同步、匿名迁移——这 7 项不在第 5 级提示词范围内记 N/A不计分。汇总得分表功能满分得分1. 基础聊天322. 输入中指示333. 已读回执334. 未读计数32.55. 定时消息326. 阅后即焚337. 表情回应30.758. 消息编辑31总计2417.2571.9%五、架构佐证六表 Schema、Socket.IO 与周期任务评分记录的技术笔记写道后端 Node.js Express Socket.IO Drizzle ORMPostgreSQL 16Docker前端 React 18 ViteJWT 认证24 小时过期六张表。这与归档内的实际源码逐一对应。server/src/db/schema.ts 定义了 6 张表及 Drizzle relations表关键字段支撑的功能usersuuid 主键随机默认、唯一用户名认证主体roomsserial 主键、唯一名称房间messagesscheduled_for、expires_at、edited_at三个可空时间戳定时、阅后即焚、编辑——三套功能复用同一张表message_edits指向消息的外键、旧内容、编辑时间编辑历史留痕reactions消息用户emoji 三元组表情回应message_reads房间用户、last_read_message_id已读回执与未读计数所有外键均配置onDelete: cascade删用户/删房间会级联清理关联数据。messages表用三个可空时间戳同时承载 Feature 5/6/8是「一个 Schema 服务多项功能」的典型设计。实时性方面index.ts 展示了传统栈的完整分工REST登录/房间/消息/编辑/回应/已读等状态写入全部走 HTTP且每个写端点在落库后手动触发一次io.to(room: roomId).emit(...)广播Socket.IO仅承载高频、低价值的事件输入中指示、房间加入/离开并用 JWT 做握手鉴权io.use中间件校验socket.handshake.auth.token周期任务单一setInterval1 秒串行处理「到期定时消息投递」与「过期消息清理」两个批处理。对比之下这也是 SpacetimeDB 一侧想验证的命题若使用 SpacetimeDB 模块订阅同步、定时/清理类触发器可由平台承接手写 WebSocket 广播与轮询代码量会显著减少——基准的对比价值正在于此。六、部署问题Docker 三连坑评分记录了首次部署不成功的三个原因且都能在归档文件中找到痕迹Docker 代理配置错误——Vite 代理被写死为localhost:3001而容器网络中应指向服务名server:3001需要完整重建容器——配置改动必须docker-compose down up --build才生效端口冲突——PostgreSQL 默认 5432 与宿主机本地实例冲突。最终修复体现在 docker-compose.yml 中services: postgres: image: postgres:16-alpine ports: - 5433:5432 # 宿主机映射改为 5433规避本地 5432 冲突 environment: POSTGRES_DB: chat-app server: build: ./server ports: [3001:3001] environment: DATABASE_URL: postgres://postgres:passwordpostgres:5432/chat-app JWT_SECRET: chat-app-20260108-120000-secret client: build: ./client ports: [5173:5173] environment: VITE_API_URL: http://server:3001 # 容器网络内以服务名寻址注意DATABASE_URL使用容器网络内的postgres:5432容器间仍走标准端口只有对外映射改成 5433——这是解决端口冲突的正确姿势只改宿主机映射而不动内部连接串。七、已知问题清单与评分结论评分文档将问题分为三档关键 BugCSS 特异性 Bug回应与编辑——内联style{{ display: none }}压过悬停 CSS 规则按钮永久不可见源码证据见上文 MessageItem.tsx定时消息不显示——POST 响应被客户端忽略需刷新页面或等待实际投递后才出现定时消息无取消 UI。缺失功能4. 无加入/离开房间 UI所有房间对所有人可见 5. 无在线用户显示 6. 无编辑历史查看器数据已入库UI 缺失 7. 无「谁点了回应」的展示数据存在无悬停提示。次要问题8. 未读计数用 5 秒轮询而非 Socket 实时推送。从源码结构看这份 71.9% 的分数呈现出清晰的模式数据层与服务端链路完成度很高六表 Schema 完整、鉴权、zod 校验、toggle 语义、级联清理全部就位失分集中在最后一公里的前端交互——一个 CSS 特异性错误同时拖垮了 Feature 7 和 8 两项合计 7 分中只拿到 1.75加上几处「数据已就绪、UI 未接线」的缺口。这对使用该基准的团队是一个有参考价值的结论在「一次生成」约束下模型倾向于把复杂度堆进后端而 UI 的可见性细节按钮可触达性、悬停交互、轮询 vs 推送的取舍是需要人工复核或复提示修补的重灾区。八、如何复用这套评测与结果聚合如果你想在自己的模型/平台组合上复现这次评测仓库给出的路径是按 llm-oneshot 运行指南 在 Cursor 中运行生成提示词组合参考 prompts 目录language/下选语言栈composed/下选功能等级features/下是各单项功能的原子定义按 grading_rubric.md 人工评分并写入应用目录的GRADING_RESULTS.md聚合所有已评分应用cd tools/llm-oneshot pnpm install pnpm run summarize输出到仓库顶层 docs/llms/oneshot-summary.md含功能分汇总与 oneshot-grades.json结构化数据。同一提示词等级下仓库还归档了其他模型的同平台/跨平台结果如typescript/gpt-5-2/postgres、typescript/grok-code/spacetime等目录可逐份对照各自的GRADING_RESULTS.md完成 rubric 中「Comparison Template」表格——功能总分、一次成功率、前后端代码行数、复提示次数与效率分、综合得分——从而得出针对具体任务与提示词等级、可辩护的模型间结论而非泛泛的「谁更强」。【免费下载链接】SpacetimeDBDevelopment at the speed of light项目地址: https://gitcode.com/GitHub_Trending/sp/SpacetimeDB创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考