2026/9/13 18:28:47
FEATURED · 精选文章 
SpacetimeDB llm-oneshot 聊天基准Mentions 与实时通知中心的规格设计与实现路径【免费下载链接】SpacetimeDBDevelopment at the speed of light项目地址: https://gitcode.com/GitHub_Trending/sp/SpacetimeDB本文围绕 SpacetimeDB 仓库中 llm-oneshot 聊天应用基准的功能规格块15_mentions.mdMentions and Notification Feed展开完整解读其 7 条功能需求与配套的 UI 契约说明该规格在「语言文件 累积功能提示词」基准体系中的位置并结合仓库内已有的示例应用与评分体系给出在 SpacetimeDB 上实现「消息内 提及 实时通知流」的表结构、reducer 与客户端订阅的设计参考。读完本文你可以独立复述该功能的完整验收标准并按仓库给出的工程模式落地一个带实时通知铃的聊天应用。规格来源chat-app 提示词体系中的功能块该规格文件 15_mentions.md 属于tools/llm-oneshot/apps/chat-app目录下的模块化提示词系统。按 prompts/README.md 的说明这套系统用于「以不同功能集测试 SpacetimeDB 与 PostgreSQL 的表现差异」目录结构分为三层features/独立的功能构建块building blocks15_mentions.md就是其中之一全文仅 7 条要点逐条描述「Mentions and Notification Feed」的期望行为composed/语言无关的累积式提示词composed/15_mentions.md是包含全部前序功能加本功能的完整规格标题为 Chat App - Full Features (18)并附带 UI Style Guidelanguage/语言/后端特定的小型约束文件如 typescript-spacetime.mdTypeScript SpacetimeDB 后端、React Vite 客户端。使用方式是把一个语言文件与一个 composed 提示词按序拼接后交给模型执行例如language/typescript-spacetime.md composed/15_mentions.md execute。仓库当前features/与composed/目录下均已扩展到 19 个层级编号 01–1915即本功能功能集是累积的编号越高的层级包含此前所有功能。README 中的--level映射表目前列到 12 级超出该表的层级如 15在仓库中没有额外的显式映射说明这一点在使用时需要注意。功能需求Mentions 与通知流的七条核心规则features/15_mentions.md 的原始内容共 7 条要点是本文的规格主体逐条继承如下输入 username 即可提及用户可以在消息中输入username来提及他人。这隐含两条实现约束解析必须发生在服务端或客户端可控的位置消息文本是自由文本且需要与「用户名」表做匹配以确定提及对象。被提及的用户名必须高亮/样式化消息文本中username片段要视觉上区别于普通文本加粗、变色或包裹样式化span而不是原样输出纯文本。被提及时创建通知每当一条消息提到某用户就要为该用户生成一条通知记录——通知是持久化数据而非纯客户端事件这是「通知面板可回溯历史通知」的前提。通知铃显示未读数侧边栏/头部有一个铃铛图标实时显示未读通知数量数字徽标。点开通知面板点击铃铛打开面板列出全部通知且每条通知要能追溯到源消息文本与所在频道。标记已读用户可以逐条标记已读也可以「全部已读」两种粒度都要支持。实时更新新提及要即时反映到铃铛计数无需手动刷新——这一条在 SpacetimeDB 技术栈下由客户端订阅subscription自然满足。此外累积版规格 composed/15_mentions.md 在功能段落中补充了第 8 条点击某条通知会跳转到其所在频道的源消息且通知面板明确覆盖「mentions、invites 等」多类通知。composed 版本还规定了 UI Style Guide 中与通知直接相关的两条通用约束徽标样式「Badges: small pill-shaped with count, contrasting color (e.g., unread count on rooms)」——未读计数用带对比色的小药丸形徽标呈现与房间未读徽标同一视觉语言交互与键盘支持面板/弹窗支持 Escape 关闭、状态变化带平滑过渡fade/slide错误反馈必须内联或 toast禁止静默失败。UI 契约为自动化测试预留的接口约束composed 规格中有一个关键机制每个功能都附带 UI contract 小节定义自动化测试所依赖的 DOM 属性并明确要求「这些是用户可见接口的定义必须遵守而架构、状态管理与后端设计完全自由」。Mentions 功能的 UI 契约共 5 条完整摘录如下契约项要求Mention highlighting消息中的username文本必须视觉上可区分加粗、着色或包裹在样式化span内Notification bell侧边栏或头部存在文本为 或aria-label含 notification 的buttonUnread count铃铛旁有显示未读通知数量的数字徽标Notification panel点击铃铛后出现通知列表每条含消息文本与频道名Mark read面板内存在文本为 Mark Read 或 Mark All Read 的button这套契约是「功能实现」与「评分器」之间的接口评分测试Playwright 驱动的 harness只检查契约中的选择器/文本不关心你用什么状态管理或表结构。实现时的直接推论是铃铛按钮务必带 字面量或规范aria-label已读按钮的文案必须是 Mark Read/Mark All Read而非 Read 等近义词否则自动化判分会失败。在 SpacetimeDB 上的实现模式设计参考仓库中已有的生成示例例如 opus-4-5/spacetime/chat-app-20260102-162918 的 README展示了该基准应用的标准后端形态TypeScript 模块里以schema.ts定义表、index.ts定义 reducers客户端由spacetime generate生成绑定后通过 React Vite 消费。需要说明从仓库当前状态看mention/notification字样仅出现在提示词规格文件中现有示例应用均基于 12 级及以下的功能集生成尚未落地本功能。因此以下设计是从既有示例的表/reducer 模式推断出的参考方案而非仓库中的既有实现。后端一张通知表 复用发消息 reducer参照示例应用中read_receipt、typing_indicator等「按用户维度存行、客户端按当前用户过滤订阅」的既有模式通知功能的核心是一张通知表// 示意notification 表字段名仅为设计建议 table export class notification { id: i32; // 自增主键 user_id: i32; // 被提及的用户通知接收者 room_id: i32; // 源消息所在房间 message_id: i32; // 源消息 id支撑「跳转到源消息」 read: bool; // 是否已读未读计数 订阅内 read false 的行数 }配套的行为变化有三处均可落在既有 reducer 的职责边界内send_message或reply_to_message在插入消息行时解析文本按 UI 契约提及语法就是字面的username服务端按用户表匹配用户名为每个被提及者insert一行notification。由于通知是表行而非广播事件天然满足「通知面板列出历史通知」与「实时推给本人」两个要求。mark_notification_read(notification_id)与mark_all_notifications_read()分别对应 UI 契约的逐条已读与「Mark All Read」。在 SpacetimeDB 中后者可以是「按当前用户更新多行」的一个 reducer调用后所有订阅该表的客户端会收到行变更。未读计数不需要独立状态客户端订阅notification表按user_id过滤即可在客户端做或从源码结构看也可以由 reducer 侧保证只写入相关行本地统计read false的行数即为铃铛徽标数字——这与示例应用中未读房间数、读回执「订阅 客户端聚合」的做法一致。从 prompts/README.md 的特性难度对比表可以看到这类「每用户维度、需实时同步给客户端」的状态正是 SpacetimeDB 相对 PostgreSQL 方案的结构性优势场景PG 侧通常要额外搭 WebSocket/订阅清理设施而 PostgreSQL 对照组在 typescript-postgres.md 下被要求用 Express Socket.io 自行搭建同一条实时链路。客户端订阅驱动的通知铃与面板按 composed 规格的 Layout 约定左侧约 220px 侧边栏、右侧滑入/覆盖式面板通知功能的前端落点是消息渲染把消息文本按username切分命中用户表的片段包进样式化span满足 Mention highlighting 契约铃铛 徽标侧边栏button 未读计数药丸徽标未读数来自上述订阅的本地聚合通知面板点击铃铛打开右侧滑入面板列出通知消息文本 频道名每项带 Mark Read 按钮面板头部带 Mark All Read 按钮点击条目则导航到对应频道的源消息composed 规格第 8 条。视觉上可复用语言文件给定的品牌色主色#4cf490SpacetimeDB 绿用于强调与 focus ring#ff4c4c红适合未读徽标这类对比色背景/表面/边框分别为#0d0d0e/#141416/#202126这些约束来自 typescript-spacetime.md 的 Branding Styling 小节也是自动评测时人工比对视觉一致性时的基准。基准流程把该规格投喂给模型并评分复现一次完整的「生成 验收」流程按仓库文档给出的步骤组装提示词选择语言文件如typescript-spacetime.md与composed/15_mentions.md拼接模块名固定为chat-app代码只允许落在backend/spacetimedb/与client/src/两处生成应用模型按提示词产出后端模块与 React 客户端工程骨架遵循语言文件的约束运行与示例应用一致的标准链路——spacetime start启动节点spacetime publish chat-app --module-path .发布模块spacetime generate --lang typescript --out-dir ../../client/src --module-path .生成客户端绑定再npm install后npm run dev启动客户端步骤取自 示例应用 README 的 Deployment 章节自动化评分进入 test harness 后安装依赖并安装 Chromium再按被测应用的级别运行基准cd ../test-harness npm install npx playwright install chromium CLIENT_URLhttp://localhost:5173 npm run benchmark -- ../staging/typescript/LLM_MODEL/spacetime/chat-app-YYYYMMDD-HHMMSS/ --levelN评分侧由 grading_checklist.md 与 grading_rubric.md 定义每项功能满分 3 分按子项给分如基础聊天 6 个子项各 0.5 分并记录「一次成功 / 需 N 次 reprompt」的重试成本。需要指出现行 checklist 的 15 项列表仍对应早期版本其第 15 项是「匿名迁移」与features/目录第 15 号「Mentions」并不同名同项说明该提示词体系处于持续扩展中——新增功能块后评分清单与--level映射会逐步跟上引用时应以实际文件内容为准。小结与延伸阅读15_mentions.md虽然只有 7 行但它与 composed 版 UI 契约、语言约束文件、评分清单共同构成了一个完整的「规格 → 生成 → 验收」闭环功能条目定义行为UI 契约定义可测接口语言文件定义技术栈与视觉基准harness 与 checklist 负责量化结果。要在 SpacetimeDB 上落地该功能关键路径是「消息 reducer 解析 username → 通知表落行 → 客户端订阅聚合未读数 → 面板/徽标满足 UI 契约」而通知作为持久化表行、实时性由订阅天然提供正是这套技术栈处理「每用户维度实时状态」的典型形态。延伸阅读均为仓库内相对路径15_mentions.md功能块composed/15_mentions.md累积规格 UI 契约prompts/README.md提示词体系与难度对比language/typescript-spacetime.md技术栈与品牌色约束grading_checklist.md评分清单示例应用 README表/reducer/部署链路参考【免费下载链接】SpacetimeDBDevelopment at the speed of light项目地址: https://gitcode.com/GitHub_Trending/sp/SpacetimeDB创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
SpacetimeDB llm-oneshot 聊天基准：@Mentions 与实时通知中心的规格设计与实现路径
SpacetimeDB llm-oneshot 聊天基准Mentions 与实时通知中心的规格设计与实现路径【免费下载链接】SpacetimeDBDevelopment at the speed of light项目地址: https://gitcode.com/GitHub_Trending/sp/SpacetimeDB本文围绕 SpacetimeDB 仓库中 llm-oneshot 聊天应用基准的功能规格块15_mentions.mdMentions and Notification Feed展开完整解读其 7 条功能需求与配套的 UI 契约说明该规格在「语言文件 累积功能提示词」基准体系中的位置并结合仓库内已有的示例应用与评分体系给出在 SpacetimeDB 上实现「消息内 提及 实时通知流」的表结构、reducer 与客户端订阅的设计参考。读完本文你可以独立复述该功能的完整验收标准并按仓库给出的工程模式落地一个带实时通知铃的聊天应用。规格来源chat-app 提示词体系中的功能块该规格文件 15_mentions.md 属于tools/llm-oneshot/apps/chat-app目录下的模块化提示词系统。按 prompts/README.md 的说明这套系统用于「以不同功能集测试 SpacetimeDB 与 PostgreSQL 的表现差异」目录结构分为三层features/独立的功能构建块building blocks15_mentions.md就是其中之一全文仅 7 条要点逐条描述「Mentions and Notification Feed」的期望行为composed/语言无关的累积式提示词composed/15_mentions.md是包含全部前序功能加本功能的完整规格标题为 Chat App - Full Features (18)并附带 UI Style Guidelanguage/语言/后端特定的小型约束文件如 typescript-spacetime.mdTypeScript SpacetimeDB 后端、React Vite 客户端。使用方式是把一个语言文件与一个 composed 提示词按序拼接后交给模型执行例如language/typescript-spacetime.md composed/15_mentions.md execute。仓库当前features/与composed/目录下均已扩展到 19 个层级编号 01–1915即本功能功能集是累积的编号越高的层级包含此前所有功能。README 中的--level映射表目前列到 12 级超出该表的层级如 15在仓库中没有额外的显式映射说明这一点在使用时需要注意。功能需求Mentions 与通知流的七条核心规则features/15_mentions.md 的原始内容共 7 条要点是本文的规格主体逐条继承如下输入 username 即可提及用户可以在消息中输入username来提及他人。这隐含两条实现约束解析必须发生在服务端或客户端可控的位置消息文本是自由文本且需要与「用户名」表做匹配以确定提及对象。被提及的用户名必须高亮/样式化消息文本中username片段要视觉上区别于普通文本加粗、变色或包裹样式化span而不是原样输出纯文本。被提及时创建通知每当一条消息提到某用户就要为该用户生成一条通知记录——通知是持久化数据而非纯客户端事件这是「通知面板可回溯历史通知」的前提。通知铃显示未读数侧边栏/头部有一个铃铛图标实时显示未读通知数量数字徽标。点开通知面板点击铃铛打开面板列出全部通知且每条通知要能追溯到源消息文本与所在频道。标记已读用户可以逐条标记已读也可以「全部已读」两种粒度都要支持。实时更新新提及要即时反映到铃铛计数无需手动刷新——这一条在 SpacetimeDB 技术栈下由客户端订阅subscription自然满足。此外累积版规格 composed/15_mentions.md 在功能段落中补充了第 8 条点击某条通知会跳转到其所在频道的源消息且通知面板明确覆盖「mentions、invites 等」多类通知。composed 版本还规定了 UI Style Guide 中与通知直接相关的两条通用约束徽标样式「Badges: small pill-shaped with count, contrasting color (e.g., unread count on rooms)」——未读计数用带对比色的小药丸形徽标呈现与房间未读徽标同一视觉语言交互与键盘支持面板/弹窗支持 Escape 关闭、状态变化带平滑过渡fade/slide错误反馈必须内联或 toast禁止静默失败。UI 契约为自动化测试预留的接口约束composed 规格中有一个关键机制每个功能都附带 UI contract 小节定义自动化测试所依赖的 DOM 属性并明确要求「这些是用户可见接口的定义必须遵守而架构、状态管理与后端设计完全自由」。Mentions 功能的 UI 契约共 5 条完整摘录如下契约项要求Mention highlighting消息中的username文本必须视觉上可区分加粗、着色或包裹在样式化span内Notification bell侧边栏或头部存在文本为 或aria-label含 notification 的buttonUnread count铃铛旁有显示未读通知数量的数字徽标Notification panel点击铃铛后出现通知列表每条含消息文本与频道名Mark read面板内存在文本为 Mark Read 或 Mark All Read 的button这套契约是「功能实现」与「评分器」之间的接口评分测试Playwright 驱动的 harness只检查契约中的选择器/文本不关心你用什么状态管理或表结构。实现时的直接推论是铃铛按钮务必带 字面量或规范aria-label已读按钮的文案必须是 Mark Read/Mark All Read而非 Read 等近义词否则自动化判分会失败。在 SpacetimeDB 上的实现模式设计参考仓库中已有的生成示例例如 opus-4-5/spacetime/chat-app-20260102-162918 的 README展示了该基准应用的标准后端形态TypeScript 模块里以schema.ts定义表、index.ts定义 reducers客户端由spacetime generate生成绑定后通过 React Vite 消费。需要说明从仓库当前状态看mention/notification字样仅出现在提示词规格文件中现有示例应用均基于 12 级及以下的功能集生成尚未落地本功能。因此以下设计是从既有示例的表/reducer 模式推断出的参考方案而非仓库中的既有实现。后端一张通知表 复用发消息 reducer参照示例应用中read_receipt、typing_indicator等「按用户维度存行、客户端按当前用户过滤订阅」的既有模式通知功能的核心是一张通知表// 示意notification 表字段名仅为设计建议 table export class notification { id: i32; // 自增主键 user_id: i32; // 被提及的用户通知接收者 room_id: i32; // 源消息所在房间 message_id: i32; // 源消息 id支撑「跳转到源消息」 read: bool; // 是否已读未读计数 订阅内 read false 的行数 }配套的行为变化有三处均可落在既有 reducer 的职责边界内send_message或reply_to_message在插入消息行时解析文本按 UI 契约提及语法就是字面的username服务端按用户表匹配用户名为每个被提及者insert一行notification。由于通知是表行而非广播事件天然满足「通知面板列出历史通知」与「实时推给本人」两个要求。mark_notification_read(notification_id)与mark_all_notifications_read()分别对应 UI 契约的逐条已读与「Mark All Read」。在 SpacetimeDB 中后者可以是「按当前用户更新多行」的一个 reducer调用后所有订阅该表的客户端会收到行变更。未读计数不需要独立状态客户端订阅notification表按user_id过滤即可在客户端做或从源码结构看也可以由 reducer 侧保证只写入相关行本地统计read false的行数即为铃铛徽标数字——这与示例应用中未读房间数、读回执「订阅 客户端聚合」的做法一致。从 prompts/README.md 的特性难度对比表可以看到这类「每用户维度、需实时同步给客户端」的状态正是 SpacetimeDB 相对 PostgreSQL 方案的结构性优势场景PG 侧通常要额外搭 WebSocket/订阅清理设施而 PostgreSQL 对照组在 typescript-postgres.md 下被要求用 Express Socket.io 自行搭建同一条实时链路。客户端订阅驱动的通知铃与面板按 composed 规格的 Layout 约定左侧约 220px 侧边栏、右侧滑入/覆盖式面板通知功能的前端落点是消息渲染把消息文本按username切分命中用户表的片段包进样式化span满足 Mention highlighting 契约铃铛 徽标侧边栏button 未读计数药丸徽标未读数来自上述订阅的本地聚合通知面板点击铃铛打开右侧滑入面板列出通知消息文本 频道名每项带 Mark Read 按钮面板头部带 Mark All Read 按钮点击条目则导航到对应频道的源消息composed 规格第 8 条。视觉上可复用语言文件给定的品牌色主色#4cf490SpacetimeDB 绿用于强调与 focus ring#ff4c4c红适合未读徽标这类对比色背景/表面/边框分别为#0d0d0e/#141416/#202126这些约束来自 typescript-spacetime.md 的 Branding Styling 小节也是自动评测时人工比对视觉一致性时的基准。基准流程把该规格投喂给模型并评分复现一次完整的「生成 验收」流程按仓库文档给出的步骤组装提示词选择语言文件如typescript-spacetime.md与composed/15_mentions.md拼接模块名固定为chat-app代码只允许落在backend/spacetimedb/与client/src/两处生成应用模型按提示词产出后端模块与 React 客户端工程骨架遵循语言文件的约束运行与示例应用一致的标准链路——spacetime start启动节点spacetime publish chat-app --module-path .发布模块spacetime generate --lang typescript --out-dir ../../client/src --module-path .生成客户端绑定再npm install后npm run dev启动客户端步骤取自 示例应用 README 的 Deployment 章节自动化评分进入 test harness 后安装依赖并安装 Chromium再按被测应用的级别运行基准cd ../test-harness npm install npx playwright install chromium CLIENT_URLhttp://localhost:5173 npm run benchmark -- ../staging/typescript/LLM_MODEL/spacetime/chat-app-YYYYMMDD-HHMMSS/ --levelN评分侧由 grading_checklist.md 与 grading_rubric.md 定义每项功能满分 3 分按子项给分如基础聊天 6 个子项各 0.5 分并记录「一次成功 / 需 N 次 reprompt」的重试成本。需要指出现行 checklist 的 15 项列表仍对应早期版本其第 15 项是「匿名迁移」与features/目录第 15 号「Mentions」并不同名同项说明该提示词体系处于持续扩展中——新增功能块后评分清单与--level映射会逐步跟上引用时应以实际文件内容为准。小结与延伸阅读15_mentions.md虽然只有 7 行但它与 composed 版 UI 契约、语言约束文件、评分清单共同构成了一个完整的「规格 → 生成 → 验收」闭环功能条目定义行为UI 契约定义可测接口语言文件定义技术栈与视觉基准harness 与 checklist 负责量化结果。要在 SpacetimeDB 上落地该功能关键路径是「消息 reducer 解析 username → 通知表落行 → 客户端订阅聚合未读数 → 面板/徽标满足 UI 契约」而通知作为持久化表行、实时性由订阅天然提供正是这套技术栈处理「每用户维度实时状态」的典型形态。延伸阅读均为仓库内相对路径15_mentions.md功能块composed/15_mentions.md累积规格 UI 契约prompts/README.md提示词体系与难度对比language/typescript-spacetime.md技术栈与品牌色约束grading_checklist.md评分清单示例应用 README表/reducer/部署链路参考【免费下载链接】SpacetimeDBDevelopment at the speed of light项目地址: https://gitcode.com/GitHub_Trending/sp/SpacetimeDB创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
