解读 AI 生成实时聊天应用的评分报告以 Claude Opus 4.5 的 PostgreSQL 聊天应用评测为例【免费下载链接】SpacetimeDBDevelopment at the speed of light项目地址: https://gitcode.com/GitHub_Trending/sp/SpacetimeDB本文基于 SpacetimeDB 仓库中tools/llm-oneshot基准评测框架的一份真实评分结果完整剖析 LLM 一次性生成实时聊天应用Chat App的评分机制、12 项功能的得失明细、11 个已知缺陷的根因以及如何阅读这类评分报告并据此改进提示词Prompt设计。读完本文你将理解「提示词级别 → 功能范围 → 逐项评分」的完整评测链路掌握从评分数据反推功能实现质量的方法并能在自己的 AI 应用生成评测中复刻这套方法论。评测背景一次针对「提示词级别 9」的 AI 应用生成考核这份评分结果对应的是一次LLM 一次性one-shot生成实时聊天应用的基准测试。被测应用存放于 chat-app-20260104-160000 目录采用的技术栈为PostgreSQL Express Drizzle ORM Socket.io React由Claude Opus 4.5生成评分日期为 2026-01-04。在展开细节前先明确评测的整体框架。整个基准评测由 tools/llm-oneshot 目录承载其目标是在相同提示词下对比两种平台SpacetimeDB自带客户端同步的实时数据库与PostgreSQL需手动实现 WebSocket 广播的传统数据库从而评估 Cursor 规则能否引导 AI 一次性地生成可工作的应用。Chat App 的提示词文件位于 apps/chat-app/prompts其中composed/目录按累进式组织功能级别09_private_rooms.md就对应本次评测使用的「提示词级别 9」。本次评测的关键事实如下项目值提示词级别909_private_rooms.md被评功能范围1-12共 15 个功能中的前 12 个总分27.25 / 3675.7%后端代码行数1,004前端代码行数2,285创建文件数21外部依赖drizzle-orm、postgres、express、socket.io、jsonwebtoken、cors、react、socket.io-client编译 / 运行 / 首次成功全部通过关于「提示词级别」的说明评分并非评估全部 15 个功能而是只评估当前提示词级别包含的功能。根据 grading_rubric.md 中的「Prompt-to-Feature Mapping」表级别 9 包含功能 1-12理论满分 36 分级别 12全量提示词才覆盖 15 个功能、满分 45 分。这正是本报告“Features Evaluated 1-12 (max 15)”的含义也是阅读任何一份 GRADING_RESULTS 前必须先确认的前提——脱离提示词级别谈分数没有意义。评分方法论从 0-3 分制到「功能即用户可见行为」理解这份报告的价值首先需要吃透其评分哲学。评测细则定义于 grading_rubric.md核心规则如下每个功能 0-3 分0 分表示未实现或完全损坏1 分表示部分实现、存在重大问题2 分表示基本可用、有轻微缺陷3 分表示完全符合规格。不在提示词内的功能标记为 N/A不参与总分。评分只看用户可见行为不看实现工作量报告「Scoring Philosophy」一节明确写道——“Code exists ≠ feature works”代码存在不等于功能可用带有破坏用户流程关键缺陷的功能只能获得最低甚至零分一个损坏的流程比没有流程更糟糕会迷惑用户。按 0.5 分粒度打分对于部分满足的标准允许四舍五入到最近的 0.5 分。配套的 grading_checklist.md 提供了打分时的操作化标记方式[x]表示零重试即工作[1]/[2]/[3]表示经过 1/2/3 次重提示reprompt后才工作[ ]表示未工作或未实现。本次评测全部功能的重提示次数为 0见 Summary Score Sheet 的 Reprompts 列说明所有已得分项都是一次性生成、零修复达标的——这与「First-try success」勾选相符。此外rubric 还定义了Reprompt 评分重提示效率满分 10 分0 次重提示得 10 分完美首次即工作并给出从 1 次9 分到 16 次0 分的递减表。可选的综合分公式为Combined Score (Feature Score / Max Score × 70) (Reprompt Efficiency × 3)功能完整度占 70%、迭代效率占 30%。本次 0 重提示意味着该项拿到满分档位。整体得分概况75.7% 背后的高达成与集中失分报告「Overall Metrics」给出的总分是27.25 / 3675.7%。横向拆解各功能得分来自 Summary Score Sheet功能满分得分达成度1. 基础聊天 Basic Chat32.0中2. 输入指示 Typing Indicators33满3. 已读回执 Read Receipts33满4. 未读数 Unread Counts31.5低5. 定时消息 Scheduled Messages32.0中6. 阅后即焚 Ephemeral Messages33满7. 消息表情 Reactions33满8. 编辑历史 Message Editing32.75高9. 实时权限 Real-Time Permissions31.5低10. 丰富在线状态 Rich Presence32.5高11. 消息线程 Message Threading31.5低12. 私密房间与私信 Private Rooms DMs31.5低总计3627.2575.7%一眼可得的规律4 项功能拿到满分输入指示、已读回执、阅后即焚、消息表情而失分最重的是涉及「实时同步链路」与「权限/成员状态一致性」的复杂功能未读数、实时权限、线程、私密房间。从实现角度这四类满分功能的共同点是有明确的单点状态且通过 Socket.io 事件广播即可覆盖而低分功能几乎都依赖跨实体的一致性成员表、邀请表、阅读位置与实时的双向同步。逐项功能解读哪项真正达标哪项只是「看起来实现了」下面按评分报告逐项展开并结合被测应用源码印证「得分/失分」背后的实现事实。被测服务端源码位于 server/src/index.ts1,318 行数据模型位于 server/src/schema.ts。功能 1基础聊天2.0 / 3达标项设置显示名0.5、向已加入房间发消息0.5、在线用户展示0.5、基础校验0.5。失分项创建房间0与加入/离开房间0。实现证据源码中确实有创建房间路由POST /api/rooms创建者会自动以admin身份写入roomMembersindex.ts但评分指出创建的房间在列表中重复出现且不持久room appears twice, not persistent即GET /api/rooms返回的公共房间与成员房间存在去重失败破坏了创建房间的用户流程。失分教训这是「代码存在 ≠ 功能可用」的典型样本——插入逻辑正确但读取列表时公共房间 成员房间的合并去重有缺陷导致用户视角的「创建房间」体验是坏的。功能 2输入指示3 / 3达标项输入状态广播给同房间成员、5 秒无操作自动过期、UI 显示 “User is typing...” / “Multiple users are typing...”。实现证据服务端定义了TYPING_TIMEOUT 5000毫秒并有一个每秒运行的cleanupTypingIndicators()后台任务扫描typingIndicators表中过期的记录并删除、同时向房间广播typing:stoppedindex.ts。该功能在 schema.ts 中有独立表typing_indicatorsroomId userId 唯一。满分原因过期机制、房间隔离、多用户文案三要素齐备且实时生效。功能 3已读回执3 / 3达标项系统追踪哪些用户看过哪些消息、消息下方显示 “Seen by X, Y, Z”、已读状态实时更新。实现证据read_receipts表以 messageId userId 唯一约束记录阅读事实schema.tsREST 层提供GET /api/messages/:id/receipts读取回执、POST /api/rooms/:id/read标记已读。功能 4未读消息数1.5 / 3三项各得 0.5但全部标注“very inconsistent”非常不稳定房间列表徽标计数不可靠、每人每房间的已读位置跟踪不稳定、实时更新不稳定。实现证据room_members表设计了lastReadAt字段schema.tsGET /api/unread接口也存在但「按房间切换视图时清空徽标」「新消息到达实时 1」等端到端联动在测试中表现不一致。失分教训未读计数的正确性依赖“最后阅读位置”与“消息到达事件”的严格配对任何一端丢失或时序错乱都会让计数失真。它是典型的跨实体状态一致性功能。功能 5定时消息2.0 / 3达标项可撰写并定时发送1、作者可见待发送消息并可取消1。失分项消息在定时点出现在房间0——标注 “errors on arrival; needs refresh — real-time broken”到达时报错需要刷新实时链路损坏。实现证据服务端有processScheduledMessages()后台任务每秒扫描scheduledFor已到期且isScheduled true的消息置为非定时后向房间广播message:createdindex.ts。失分教训后台任务正确地把消息“放行”并广播但到达时刻的客户端处理出错——说明定时链路数据库扫描 → 事件广播 → 前端增量渲染在最后一环断裂用户必须刷新页面才能看到消息。这再次印证后台逻辑正确不等于端到端功能可用。功能 6阅后即焚3 / 3达标项可发送带自动删除计时器的消息1、UI 显示倒计时1、到期后从数据库永久删除1。实现证据messages表含isEphemeral与expiresAt字段schema.tsprocessExpiredMessages()每秒扫描过期消息并执行db.delete真删除非隐藏随后广播message:deletedindex.ts。README 中可选的删除时长预设为 1、5、15、30 分钟。满分原因删除是物理删除且实时广播完全满足「permanently deleted」标准。功能 7消息表情3 / 3达标项emoji 反应 ❤️ 、计数实时更新、可切换自己的反应、悬停查看谁点了反应四项各 0.75。实现证据reactions表以 messageId userId emoji 三重唯一约束天然支持“切换”重复点击即 upsert/删除REST 提供POST /api/messages/:id/reactionsSocket 事件有reaction:added/reaction:removed。功能 8编辑消息与历史2.75 / 3达标项编辑自己的消息1、显示 “(edited)” 标记0.5、历史可被他人查看1。失分项编辑实时同步0.25——标注 “history window doesnt update in realtime”历史窗口打开时不实时更新。实现证据message_edits表保存每次编辑前的previousContentschema.tsREST 提供PATCH /api/messages/:id与GET /api/messages/:id/history主消息文本的编辑通过message:updated事件实时同步但已打开的历史弹窗不会自动刷新。功能 9实时权限1.5 / 3达标项房主是管理员可踢人/封禁0.5标注 “kick exists but doesnt disconnect”踢人存在但未断开连接、可提升管理员0.5、权限变更即时生效0.5。失分项被踢用户立即失去访问权限并停止接收更新0——标注 “completely broken”完全损坏。实现证据REST 提供了POST /api/rooms/:id/kick、/ban、/promote等端点但被踢用户只是从roomMembers移除或标记其已建立的 WebSocket 连接仍在房间频道内依然能持续收到message:created等广播。这正是报告 Known Issues 第 7 条“Kicked users still connected”的根因。失分教训权限功能的本质是服务端在广播链路入口强制校验成员资格而不是只在数据库里改标记。这也是 SpacetimeDB 这类“权限内置于数据库订阅层”的架构在对比中更具优势的场景。功能 10丰富在线状态2.5 / 3达标项四档状态online / away / do-not-disturb / invisible1、离线用户显示 “Last active X minutes ago”0.5、自动设置 away0.5。失分项状态变更实时同步0.5——标注 “not shown in Members view”成员面板中不显示。实现证据users.statuslastActive字段PATCH /api/users/status校验四档状态并通过io.emit(user:status, ...)全局广播index.tsAWAY_TIMEOUT 3000005 分钟配合heartbeat心跳事件实现自动 away。失分教训服务端广播正确但成员侧栏Members 面板没有订阅/渲染该事件用户可见状态未同步——再次落在“后端有、前端没接住”这一模式上。功能 11消息线程1.5 / 3达标项可回复特定消息创建线程0.5标注主视图无视觉标识、父消息显示回复数与预览0.5、线程视图展示全部回复0.5标注非实时、需重新打开。失分项新回复实时同步给线程查看者0。实现证据messages.parentMessageId自引用字段 messages_parent_id_idx索引支撑线程schema.tsREST 提供GET /api/messages/:id/replies。失分教训线程的四个评分点中三个受同一个根因拖累——回复在数据上确实是“消息”但在 UI 上没有被当作线程实体对待主消息流未标识、线程面板打开后不增量接收新回复。功能 12私密房间与私信1.5 / 3达标项可创建私密/仅邀请房间0.75、两人私信 DM 可用0.75。失分项按用户名邀请特定用户0与仅成员可见私密内容与成员列表0——邀请链路“可以接受邀请但进不了房间邀请毫无用处”。实现证据room_invitations表roomId invitedUserId 唯一、status 默认 pending与POST /api/rooms/:id/invite、GET /api/invitations、POST /api/invitations/:id/respond端点齐备GET /api/rooms会合并“公共房间 当前用户是成员的私密房间”。但评分指出接受邀请后用户并未被正确写入roomMembers导致既看不到房间也进不去直接摧毁了“仅成员可见”的隔离保证。DM 端点POST /api/rooms/dm实现了“查重已有 DM → 建 isDm 房间 → 双方自动入会并定向通知”index.ts因此 DMs 部分得分。功能 13-15未纳入评测级别 9 提示词不包含房间活跃度指示、草稿同步、匿名到注册迁移三个功能均标记 N/A不参与总分。对应提示词文件为 composed/10_activity.md、11_drafts.md、12_anon_migration.md。已知缺陷全梳理11 个关键问题的根因归类报告将全部扣分点汇总为 11 条 Known IssuesCritical值得逐条对照功能得分#缺陷对应功能根因归类1创建的房间在列表中重复出现1 基础聊天列表合并去重缺陷2房间持久化不可靠1 基础聊天数据/状态一致性问题3只有非管理员能离开房间离开后房间从列表消失1 基础聊天权限分支与列表刷新逻辑缺陷4未读徽标计数不可靠4 未读数跨实体状态一致性5定时消息到达时报错、需刷新5 定时消息实时推送链路末端断裂6历史弹窗不随编辑实时更新8 编辑历史前端未订阅增量事件7被踢用户仍保持 WebSocket 连接9 实时权限广播入口缺少强制校验8成员面板不反映状态变更10 在线状态前端未渲染已广播事件9回复在主视图无线程视觉标识11 消息线程线程实体未在 UI 建模10线程回复非实时需重开面板11 消息线程线程视图未增量订阅11私密房间邀请可接受但进不去12 私密房间邀请接受未写成员关系11 条缺陷可归纳为三大模式列表与状态合并/一致性缺陷#1、#2、#3、#4集中在房间列表、成员列表、未读计数等“多数据源合并”场景典型如公共房间与成员房间重复、离开后列表不刷新。“后端正确、前端没接住”的实时断链#5、#6、#8、#10服务端事件已广播但前端对应视图没有订阅或未做增量渲染必须刷新/重开才能看到。权限在广播链路未强制#7、#9、#11成员资格、线程实体、房间可见性停留在“数据库标记”层面没有在事件投递路径上做实时强制导致被踢仍收消息、私密房间可见性失效。值得强调11 条缺陷与 0 次重提示并不矛盾——评测以“生成后首次运行即通过编译、不崩溃”为 First-try success 标准而缺陷是在逐功能人工测试中暴露的这正体现了“编译通过”与“功能可用”之间的巨大鸿沟也是该评测刻意区分两者的原因。源码佐证数据模型与后台任务如何支撑这 12 项功能为了让分数与实现一一对应这里把被测应用的数据模型与运行机制作一个系统化梳理源码见 server/src/schema.ts 与 server/src/index.ts。表结构Drizzle ORM 定义9 张表表关键字段支撑功能usersdisplayName(≤50)、status、lastActive注册、在线状态roomsname(≤100)、isPrivate、isDm、createdBy房间、私密房间、DMroom_membersroomIduserId 唯一、role(admin/member)、isBanned、lastReadAt成员资格、权限、未读位置room_invitationsroomIdinvitedUserId 唯一、status(pending/accepted/declined)私密房间邀请messagescontent(≤2000)、parentMessageId、isScheduled/scheduledFor、isEphemeral/expiresAt、isEdited消息、线程、定时、阅后即焚、编辑message_editspreviousContent、editedAt编辑历史reactionsmessageIduserIdemoji 唯一消息表情read_receiptsmessageIduserId 唯一、readAt已读回执typing_indicatorsroomIduserId 唯一、expiresAt输入指示后台定时任务每秒执行一次见 index.tsprocessScheduledMessages()将到期的定时消息置为非定时并广播message:created功能 5 的“最后一环”在此断裂。processExpiredMessages()物理删除过期阅后即焚消息并广播message:deleted功能 6 满分的关键。cleanupTypingIndicators()清理过期输入指示并广播typing:stopped功能 2 满分的关键。其他关键实现细节认证JWT 存于 localStorageREST 用Authorization: Bearer token中间件Socket.io 握手阶段在io.use()中校验socket.handshake.auth.tokenindex.ts。限流RATE_LIMIT_MS 500以内存 Map 记录每个用户上次动作时间500ms 内重复发送被拒绝README 中 “Rate limiting: 500ms between message sends” 即指此。订阅可见性getUserRooms()按isBanned false过滤成员关系房间列表接口把公共房间与成员私密房间合并去重——缺陷 #1 就发生在这个合并逻辑上。从评分反推改进这份报告能指导什么GRADING_RESULTS 的价值不仅在于打分更在于把“未达标的验收点”映射回提示词与实现。基于 11 条缺陷的根因可以总结出几条对同类实时应用生成评测可复用的改进方向把“实时同步”作为显式验收项写进提示词本次失分最重的功能未读数、定时到达、线程回复、状态同步全都败在“实时”二字上。提示词可增加类似“打开的面板/列表必须随事件增量更新不允许刷新才能看到新内容”的约束。权限必须下沉到事件投递层被踢用户仍收消息、邀请接受后无成员资格说明提示词需明确“每次广播前校验成员资格”“接受邀请即写入成员关系”。这类约束恰好是 SpacetimeDB 将权限内置到数据库订阅层的设计动机也是该基准对比两平台的观察点。为“多源合并”场景预置测试用例房间列表重复、未读计数漂移都源于合并/状态同步缺陷。rubric 中每项功能的 Test Cases如 grading_rubric.md 功能 4 的“新消息到达 1、打开清空、切换回来 1”正是为了捕捉此类问题评测时可优先执行。区分“编译成功”与“功能可用”本报告用 0 重提示 编译通过 12 项功能 75.7% 的组合证明一次通过的代码也可能在功能层大面积扣分发布 AI 生成应用前必须按用户旅程逐项人工验收。如何在仓库中复现与扩展这套评测如果你想亲自复现或扩展这套评测仓库 tools/llm-oneshot/README.md 提供了完整流程准备环境安装 Cursor IDEPostgreSQL 场景需 Docker数据库容器SpacetimeDB 场景需安装 SpacetimeDB CLI。构造提示词将语言文件如 language/typescript-postgres.md与功能级别文件如 composed/09_private_rooms.md拖入 Cursor Agent 对话并附带指令 “Read all rules first. Do not reference AI-generated apps in apps/ for guidance. Execute these prompts.”——隔离历史应用是为了保证结果是提示词本身能力的真实体现。运行与部署生成完成后选择 Local 部署本应用也支持 Docker 一键启动docker-compose.ymlPostgreSQL 16 在 5432 端口、服务端在 3001、客户端 nginx 在 5174。打分按 grading_rubric.md 逐项执行测试用例把结果写入该应用目录下的 GRADING_RESULTS.md。聚合在tools/llm-oneshot下执行pnpm install pnpm run summarize会输出到docs/llms/oneshot-summary.md与docs/llms/oneshot-grades.json便于横向比较不同模型opus-4-5、grok-code、gemini-3-pro、gpt-5-2与不同平台spacetime vs postgres的表现。结语一份评分报告的读法回到这份报告本身27.25 / 3675.7%、编译通过、首次即运行、0 次重提示是一份“工程骨架合格、实时细节失分”的成绩单。4 个满分功能证明 Claude Opus 4.5 在“单点状态 事件广播”这类模式上表现可靠而 11 条关键缺陷则集中指向所有实时应用共有的三块硬骨头——多源列表一致性、前端增量订阅、权限的广播链路强制。这正是该基准评测存在的意义用可复现的提示词、可量化的评分与可追溯的缺陷清单把“AI 能否一次性生成可用的实时应用”这个问题拆解成了一份可阅读、可改进、可横向对比的证据链。对于读者而言无论你是要构建自己的 AI 应用生成评测还是在开发实时聊天类产品都可以从这份报告中学到同一件事实时系统的验收标准永远以用户可见行为为准而“代码写了”与“功能可用”之间隔着一整条需要端到端验证的实时链路。【免费下载链接】SpacetimeDBDevelopment at the speed of light项目地址: https://gitcode.com/GitHub_Trending/sp/SpacetimeDB创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考