SpacetimeDB LLM One-Shot 基准中的 MongoDB 聊天应用提示词base_mongodb.md 详解与用法【免费下载链接】SpacetimeDBDevelopment at the speed of light项目地址: https://gitcode.com/GitHub_Trending/sp/SpacetimeDBSpacetimeDB 仓库的tools/llm-oneshot目录内置了一套「一次性生成完整应用」的 LLM 基准其中apps/chat-app应用以「实时聊天室」为统一题目用不同数据库后端对比各模型的真实代码生成能力。本文以该基准中面向 MongoDB 后端的入口提示词 base_mongodb.md 为主体完整拆解它的任务定义、目录与命名约定、约束条件、UI 要求和功能注入机制并结合同目录的语言提示词、组合功能提示词与评分规则说明这份提示词如何被组装、执行与评分。读完后你可以复现该基准的完整工作流并理解每条约定背后的设计意图。一、base_mongodb.md 在 One-Shot 基准中的定位llm-oneshot 的 README 说明了该工具的目标基准化测试 AI 能否在单次尝试内生成并部署一个可运行的应用并通过在不同平台生成等价应用来做横向比较。官方主对比的两类平台是SpacetimeDB—— 带客户端自动同步的实时数据库PostgreSQL—— 需要手动实现 WebSocket 广播的传统数据库。在apps/chat-app/prompts/目录下共有三个数据库基线的「基础提示词」三者构成同一套基准的平行入口文件后端基线base_spacetime.mdSpacetimeDBbase_postgres.mdPostgreSQLbase_mongodb.mdMongoDBbase_mongodb.md的开篇一句话直接定义了任务Create me areal-time chat appusingMongoDB as the backend.即用MongoDB 作为后端生成一个实时聊天应用。注意这份文件是「任务总纲」具体的功能清单并不写在文件里而是由后文第 2.5 节讲的组合功能提示词注入。从目录结构看当前仓库中apps/chat-app/typescript/下保留的生成产物以postgres与spacetime两类平台为主如typescript/opus-4-5/postgres、typescript/opus-4-5/spacetime等MongoDB 变体作为第三种传统数据库基线提供与另两条线共用同一套功能提示词与评分规则。二、基础提示词逐段拆解下面按 base_mongodb.md 原文顺序把每一段的内容与设计动机讲清楚。2.1 任务定义与项目根目录原文件开头声明项目根目录为apps/chat-app/这是相对tools/llm-oneshot工作区根的路径后续所有目录约定都以它为起点。2.2 带时间戳的隔离目录与数据库命名原文要求把项目创建在带时间戳的文件夹下apps/chat-app/mongodb/chat-app-YYYYMMDD-HHMMSS/时间戳目录YYYYMMDD-HHMMSS保证每次生成运行拥有独立目录多次运行、不同模型之间互不污染便于事后按时间归档对比MongoDB 的数据库名固定为chat-app与 base_postgres.mdPostgreSQL 数据库名和 base_spacetime.mdSpacetimeDB 模块名使用同名资源保持跨平台对比的一致性三个基线把生成物分别放在mongodb/、postgres/、spacetime/子目录下平台隔离一目了然。2.3 约束Constraints原文约束逐条如下Workentirely insideyour timestamped folder. Do not touch any other existing code.完全在你的时间戳目录内工作不碰其他既有代码Only create/modify code under:apps/chat-app/mongodb/chat-app-YYYYMMDD-HHMMSS/server/服务端 TypeScriptapps/chat-app/mongodb/chat-app-YYYYMMDD-HHMMSS/client/客户端 TypeScript/ReactKeep it minimal and readable.保持最小且可读这三条各自承担不同的基准职能目录隔离是基准「干净性」的核心。llm-oneshot README 的执行指令还要求模型「不要参考apps/下已生成的 AI 应用作为指导」目的就是排除「抄旧代码」的可能让成功与否只能归因于规则与提示词本身前后端边界固定为server/Node 服务端与client/React 客户端两个目录且限定使用 TypeScript使不同模型产出的结构可比**「最小且可读」**限制了堆砌式代码让评分时统计的代码行数LOC与外部依赖数量这些指标有意义。2.4 UI 要求UI Requirements原文给出五条 UI 基线要求完整继承如下Dark theme with consistent color palette深色主题、一致的色彩体系Clear visual hierarchy — active states, hover effects, focus indicators清晰视觉层级激活态、悬停效果、焦点指示Responsive layout that works on desktop (mobile optional)桌面端可用的响应式布局移动端可选Loading and empty states for all>cd tools/llm-oneshot pnpm install pnpm run summarize汇总各应用目录下的GRADING_RESULTS.md输出到 docs/llms/oneshot-summary.md含功能得分的合并摘要与 docs/llms/oneshot-grades.json供网站展示的结构化数据。五、适用前提与注意事项环境前提跑 MongoDB 基线需要可用的 MongoDB 实例与 Node 环境SpacetimeDB 基线则需要 SpacetimeDB CLI见 llm-oneshot README 的前置条件清单。base 文件是「模板壳」base_mongodb.md本身不含任何功能清单Features段必须拼接composed/功能文件后任务才完整单独使用会生成无功能定义的应用。两套路径约定并存base 提示词写的是apps/chat-app/mongodb/...一级路径而语言文件给出apps/chat-app/staging/typescript/LLM_MODEL/mongodb/...。执行时以模型实际收到的提示词为准归档结构最终对齐 README 的{language}/{model}/{platform}层级。引用范围以仓库实际文件为准prompts/README.md 的栈对照表目前只列出 typescript-spacetime、typescript-postgres、rust-spacetime、csharp-spacetime 四种语言文件MongoDB 语言文件typescript-mongodb.md是文件树中实际存在的扩展项组装提示词时直接引用该文件即可。难度表是定性先验README 的「Easy/Hard」难度对比是基准作者的设计估计用于解释两条技术路线的差异不是实测数据引用时应保留这一限定。小结base_mongodb.md的价值在于「统一任务壳」设计一个 40 行左右的文件固定了任务定义、时间戳隔离目录、数据库命名、前后端目录边界、五条 UI 基线并把功能细节整体委托给composed/组合提示词、把具体技术栈与品牌色委托给language/typescript-mongodb.md。由此SpacetimeDB、PostgreSQL、MongoDB 三条基线可以在同一功能集、同一 UI 契约、同一评分细则下被公平比较度量 LLM 一次性生成不同后端实时应用的能力差异。想动手复现时按第四节的 Cursor 工作流组装「语言文件 组合提示词」并执行再用评分细则记录结果即可。【免费下载链接】SpacetimeDBDevelopment at the speed of light项目地址: https://gitcode.com/GitHub_Trending/sp/SpacetimeDB创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考