LLM Sequential Upgrade Benchmark 运维手册用 SpacetimeDB、PostgreSQL、MongoDB 量化 AI 开发成本【免费下载链接】SpacetimeDBDevelopment at the speed of light项目地址: https://gitcode.com/GitHub_Trending/sp/SpacetimeDB本手册是 SpacetimeDB 仓库内 tools/llm-sequential-upgrade 基准测试工具的完整操作指南。它面向需要实际跑一轮AI 逐级升级基准测试的运维人员让一个 AI 编码代理分别基于不同后端从零生成同一个聊天应用再按 12 个等级逐级增加功能最终对比出每个后端的总 LLM 成本Token 与美元、Bug 率与修复迭代次数。读完本文你将掌握从环境搭建、模型固定、逐级生成/升级、人工浏览器评分、Bug 修复、数据库重置到对比报告生成的全套可复现流程并能直接对照仓库源码理解每个步骤背后的实现机制。衡量口径以完全相同的功能规格feature spec在每个后端上构建同一个聊天应用按同一评分标准打分。成本越低、Bug 越少、迭代次数越少代表该后端越容易被 AI 构建。本文以 MongoDB 为完整示例可搭配 SpacetimeDB 做同条件对比。1. 基准测试是什么后端无关的cost-to-done对比本工具的定位是一套自动化基准测试编排框架harness后端无关由 tools/llm-sequential-upgrade/README.md 描述其流程由 headless 的 Claude Code 会话根据 L1 功能规格生成聊天应用按 L2–L12逐功能组升级每个等级后由人工按功能规格在浏览器中评分Bug 被写入BUG_REPORT.md由独立 Claude Code 会话修复所有 API 成本通过OpenTelemetry捕获写入每会话的成本摘要。它测量的核心指标是构建同一个功能目标时不同后端在 AI 生成成本上的直接差异。仓库内配套的 tools/llm-sequential-upgrade/perf-benchmark 则是另一维度运行时吞吐量msgs/sec与本 runbook 的成本对比互补但不混淆。2. 后端、端口与目录布局参考基线三个后端共享同一套 ViteReact 客户端技术栈仅服务端与数据库不同后端Vite客户端API数据库标题spacetime6173模块跑在 STDB :3000SpacetimeDBSpacetimeDB Chatpostgres6273Express :6001Postgres :6432PostgreSQL Chatmongodb6373Express :6001Mongo :6437MongoDB Chat各后端的端口与数据库细节可对照 tools/llm-sequential-upgrade/backends/mongodb.md、tools/llm-sequential-upgrade/backends/spacetime.md 与 tools/llm-sequential-upgrade/backends/postgres.md这些文件也会被冻结进每次运行的inputs/供 AI 使用。并行运行--run-index N会给每个端口加上 N如 6373N、6001N并使用独立的每运行数据库chat-app_runN。从 tools/llm-sequential-upgrade/run.sh 的端口分配逻辑可以看到每个后端拥有 100 端口区间6173/6273/6373 run-indexExpress 统一为 6001 run-indexPostgres 与 Mongo 容器是共享的通过每运行独立数据库名隔离spacetime_runN/chat-app_runNSpacetimeDB 则按模块名隔离。运行输出目录gitignored单独发布到结果仓库sequential-upgrade/sequential-upgrade-YYYYMMDD/ backend/ results/chat-app-ts/ # 生成的应用 backend/ | server/ client/ .benchmark-backend # 供 fix/upgrade/grade 检测后端类型的标记文件 level-1/ … level-11/ # 每次升级前拍摄的快照 BUG_REPORT.md # 评分发现 Bug 时由你撰写 ITERATION_LOG.md # 修复历史每次迭代追加 GRADING_RESULTS.md # 各功能得分 telemetry/run-id/ cost-summary.json | COST_REPORT.md | metadata.json inputs/ # 冻结的 prompt 快照保证可复现 BENCHMARK_REPORT.md # 由 generate-report.mjs 生成其中.benchmark-backend标记文件至关重要postgres 与 mongodb 应用都使用server/目录仅靠目录结构无法区分二者run.sh的detect_backend()优先读取该标记其次才回退到目录形状。等级 → 评分功能每个功能 0–3 分LevelFeaturesMaxLevelFeaturesMax11–41271–103021–51581–113331–61891–123641–721101–133951–824111–144261–927121–1545注意从 L2 起每个等级的评分是累计的1–N 全部功能因此最高分逐级递增。功能规格文件位于 tools/llm-oneshot/apps/chat-app/prompts/composedrun.sh会按printf %02d $LEVEL_*.md精确匹配对应等级的 cumulative 规格。3. 一次性环境准备Docker 正在运行——用于拉起 OTel Collector Postgres Mongocd tools/llm-sequential-upgrade docker compose -f docker-compose.otel.yaml up -ddocker-compose.otel.yaml 定义了三个服务otel-collectorotel/opentelemetry-collector-contrib:latest暴露 4317 gRPC / 4318 HTTP 接收端、postgres:16映射 6432:5432用户/密码/库均为spacetime、mongo:7映射 6437:27017。值得注意Mongo 是单节点 手动 Socket.io实现实时能力刻意不用副本集/change streams以保证与 Postgres 后端的对比对称——这是 tools/llm-sequential-upgrade/backends/mongodb.md 中明确写死的架构约束。SpacetimeDB仅当跑 spacetime 后端时spacetime start # 在自己的终端中运行run.sh会执行spacetime server ping local做预检并把 Windows 安装目录AppData/Local/SpacetimeDB自动加入 PATH。Claude CLI在 PATH 上或npx anthropic-ai/claude-code以及Node.js。run.sh的 CLI 发现顺序为claude→claude.exe→ npx 安装检查并兼容 Claude Code 桌面版安装目录。Windows 下用 git-bash 运行脚本假定它.gitattributes保持脚本为 LF因此在 WSL/CI 下同样可用。4. 每次会话前的运行前检查清单cd tools/llm-sequential-upgrade docker compose -f docker-compose.otel.yaml up -d # 幂等 docker exec llm-sequential-upgrade-mongodb-1 mongosh --quiet --eval db.runCommand({ping:1}) # spacetime server ping local # 仅 spacetime 后端需要全部通过即为就绪。run.sh内置的预检源码见 run.sh会按后端分别检查spacetime 执行spacetime server ping localpostgres 执行容器内psql -U spacetime -d spacetime -c SELECT 1mongodb 执行db.runCommand({ping:1})同时强制校验 Docker daemon、Node.js、OTel Collector 容器、以及等级对应的 composed prompt 文件是否存在任一失败都会以非零码退出。5. 固定模型对比公平性的关键为每个后端、每个等级固定同一个模型。已发布的运行使用的是Claude Sonnet 4.6。两种等价方式./run.sh --model claude-sonnet-4-6 --level 1 --backend mongodb # 单次运行 flag # 或为整个 shell 设置同样覆盖 run-loop/benchmark 批处理运行 export ANTHROPIC_MODELclaude-sonnet-4-6--model优先于环境变量。所选模型会记录在每次运行的metadata.json中并打印在运行头信息里——它是最大的可比性杠杆必须在整个对比中保持一致。run.sh中MODEL${ANTHROPIC_MODEL:-claude-sonnet-4-6}因此不传--model时也会固定到规范模型而非 CLI 默认值只有模型固定相同apples-to-apples 的美元对比才有意义详见第 9 节成本追踪。6. 核心循环每等级L1 → L12对每个要测试的后端mongodb以及配对测试时的spacetime执行以下循环6a. 生成 L1或升级到等级 N# 从零生成 Level 1 ./run.sh --level 1 --backend mongodb # 将现有应用升级到下一等级默认使用增量功能文件 # 加 --composed-prompt 则使用完整累计规格与 L1–L11 规范运行一致 ./run.sh --upgrade app-dir --level 2输出以DEPLOY_COMPLETE结束并打印app dir与COST_REPORT路径。--upgrade/--fix模式通过.benchmark-backend标记自动检测后端无需再传--backend。从源码看三种模式的 prompt 构建差异明显见 run.shgenerate 模式内联语言规格 该等级的 composed 功能规格指令要求构建失败最多每阶段重试 3 次并在ITERATION_LOG.md记录每次重试upgrade 模式默认读取prompts/features/NN_*.md的增量功能文件只含新功能--composed-prompt则回退到累计 composed 规格prompt 中明确要求不要重写已有功能运行时会把提示词用sed剥离**UI contract:**块这些块仅为确定性 UI 断言服务而本项目评分是人工浏览器操作不需要。此外升级前run.sh会把当前应用快照到level-N排除node_modules、dist、.vite、drizzle、dev-server.log与既有快照升级成功后再次快照到level-LEVEL形成可回溯的历史。6b. 评分人工见第 7 节在浏览器中测试每个功能打分 0–3写入GRADING_RESULTS.md。任一功能失败则撰写BUG_REPORT.md模板在templates/目录即 tools/llm-sequential-upgrade/templates/BUG_REPORT.template.md。6c. 修复如有 Bug./run.sh --fix app-dir读取BUG_REPORT.md修复、重新部署追加写入ITERATION_LOG.md然后重新评分。重复 6b–6c 直到全部功能通过或达到你的迭代上限。全部通过后删除BUG_REPORT.md——harness 以它的存在与否判定是否执行--fix若文件存在而run.sh --fix找不到它会直接报错退出No BUG_REPORT.md found。--fix的 prompt 会明确要求阅读该目录下的 CLAUDE.md、按 Bug 报告修复、重建并重启所有服务器Postgres 重启 Express ViteSpacetimeDB 执行spacetime publish再重启 Vite、用 curl 验证 API、并在ITERATION_LOG.md追加本次迭代最后输出FIX_COMPLETE。6d. 下一等级回到 6a执行./run.sh --upgrade app-dir --level N1。每次升级前应用会被快照到level-N。提示run-loop.sh --backend mongodb --variant sequential-upgrade --level 12可自动化 generate→grade→fix→upgrade 循环但评分仍在交互式 Claude 会话Chrome MCP中进行。需要完全手动控制时自行驱动 6a–6d。从 run-loop.sh 源码看该穷举循环脚本用.grade-lock目录锁串行化评分Chrome MCP 每次只允许一个评分会话、默认MAX_FIX_ITERATIONS5、升级后对全部功能做回归评分grade_app以BUG_REPORT.md是否存在判断是否进入修复迭代并且 one-shot 变体与 sequential 变体走两套不同流程。它还支持--rules guided|standard|minimal控制提示词里注入的指导级别guided 分阶段步骤 SDK 规则 代码模板最严格standard 仅 SDK 规则minimal 仅技术栈名称。spacetime 后端的 guided 模式会将 skills/typescript-server/SKILL.md、skills/typescript-client/SKILL.md 与 backends/spacetime-templates.md 拼装成应用的CLAUDE.md。7. 评分人工只根据观察到的浏览器行为评分绝不看源码。评分标准分数含义3完全按规格工作2大体可用次要 Bug / 缺失边界情况1部分可用主要问题0缺失或损坏硬性规则功能测试期间出现JS 控制台错误该功能最高 2/3只有刷新后才生效的实时功能最高 1/3无法测试 → 0有疑问时打低分。评分协议细节记录在 tools/llm-sequential-upgrade/GRADING.md每个功能按测试计划执行步骤、记录各标准通过与否、在关键验证点截图、用read_console_messages检查 JS 错误、打分 0–3并立即把分数块写入GRADING_RESULTS.md而非最后统一补写。7a. 两个独立身份typing / read receipts / unread / presence 需要应用以localStorage区分身份因此同一配置文件的两个标签页 同一个用户。要获得真正的第二个用户二选一无痕窗口作为第二个用户独立存储或脚本化的第二个 socket——通过 API 注册第二个用户并打开独立的socket.io连接验证中采用的方法。用户 1 走真实 UI用户 2 的typing/markRead/ 消息通过 socket 触发再给用户 1 的 UI 反应打分。打开后端对应端口的应用mongodbhttp://localhost:6373。7b. 记录结果在应用目录写入GRADING_RESULTS.md格式见 GRADING.md每个功能一个块并以汇总表收尾最后一行必须是| **TOTAL** | **X/Y** | |——generate-report.mjs正是解析这一行得到报告中的功能得分。表格中不要包含 token 数、成本估算或 API 调用次数这些属于COST_REPORT.md。7c. 提交 Bug复制templates/BUG_REPORT.template.md→app-dir/BUG_REPORT.md。每个问题一个## Bug N块写行为描述、期望结果 vs 实际结果。这份文件就是修复 agent 的输入。8. 评分轮次之间重置数据库要从干净状态评分无残留用户/房间/消息./reset-app.sh app-dirreset-app.sh 按检测到的后端执行不同策略Mongomongosh db.dropDatabase()删除整个数据库——Mongoose 无 schema下次写入时自动重建集合索引在模型首次初始化时重建因此没有迁移/推模式步骤Postgres动态 drop 掉 public schema 下所有表DROP TABLE ... CASCADE然后npx drizzle-kit push重建 Drizzle 模式数据库名从server/.env的DATABASE_URL解析SpacetimeDB生成全新模块名chat-app-test-timestamp用spacetime publish -p backend-dir -s local module发布新模块并把client/src/config.ts中的MODULE_NAME替换为新模块名Vite 热更新接管。脚本同样优先读取.benchmark-backend标记做后端检测。9. 生成对比报告一轮运行后一个或两个后端位于同一个日期目录下node generate-report.mjs sequential-upgrade/sequential-upgrade-YYYYMMDD写出BENCHMARK_REPORT.md成本、调用次数、tokens、时长、LOC功能得分可解析时包含。它会聚合每个会话cost-summary.json中按后端汇总的成本。从 generate-report.mjs 源码可见其聚合逻辑遍历runBaseDir/backend/telemetry/run-id/cost-summary.json按后端分组、按等级排序每等级取最后一次运行byLevel[level] rlast one wins再累加totalCostUsd、apiCalls、totalTokens、totalDurationSec得到总成本双后端时输出对比表含costDelta (t2 - t1) / t2 * 100的百分比差值与XX% cheaper结论功能得分通过正则解析GRADING_RESULTS.md优先| **TOTAL** | **X/Y** |斜杠式兼容旧的**TOTAL** | **MAX** | **SCORE**两格格式与Total Feature Score: X / Y散文格式LOC 统计遍历backend/spacetimedb/srcspacetime或server/postgres/mongodb以及client/src排除node_modules、dist、.vite、module_bindings与level-*快照。面向投资方的METRICS_DATA.json与公共查看器在仓库内没有生成器——那是一个独立的、在仓库外的手工/脚本聚合步骤。请将BENCHMARK_REPORT.md视为本地汇总依据。10. 成本追踪成本通过 OpenTelemetry自动捕获——不要估算 token。每会话telemetry/run-id/COST_REPORT.md人类可读cost-summary.json结构化。美元数字直接来自 Claude Code 的cost_usd因此只要模型固定相同跨后端就是 apples-to-apples 的。实现细节run.sh导出CLAUDE_CODE_ENABLE_TELEMETRY1、OTEL_LOGS_EXPORTERotlp、OTEL_EXPORTER_OTLP_ENDPOINThttp://localhost:4317gRPC并显式unsetCLAUDE_CODE_PROVIDER_MANAGED_BY_HOST/CLAUDE_CODE_ENTRYPOINT——这两个变量在从 Claude Desktop agent 会话Bash 工具调用run.sh时会抑制 OTel 遥测每个运行预生成 UUID 作为--session-id并写入OTEL_RESOURCE_ATTRIBUTESrun.id$RUN_ID,session.id$SESSION_ID使parse-telemetry.mjs即使在多个后端并行共享同一个 collector 时也能按会话过滤强制FORCE_PROMPT_CACHING_5M1与DISABLE_AUTOUPDATER1保证跨运行一致的计费缓存分层并冻结 CLI 版本每次运行在 prompt 前预置唯一的 run-id以击破 Anthropic 服务端 prompt 缓存——缓存按内容键控唯一前缀保证每次都是冷启动、公平的测量sed -i 1s|^|!-- run-id: $RUN_ID --\n\n|写入CLAUDE.md共享遥测日志telemetry/logs.jsonl超过 10MB 时自动轮转归档OTel Collector 配置见 otel-collector-config.yamlfile/logs 1s 刷盘、file/metrics 5s 刷盘。11. 清理与重新开始冒烟测试或中断运行的清理以下全部可再生 / gitignoredcd tools/llm-sequential-upgrade npx kill-port 6001 6373 # 停止 dev servers docker exec llm-sequential-upgrade-mongodb-1 mongosh chat-app --quiet --eval db.dropDatabase() rm -rf sequential-upgrade/sequential-upgrade-YYYYMMDD # 运行目录 : telemetry/logs.jsonl : telemetry/metrics.jsonl # 共享遥测清空保持 Mongo 容器与 OTel Collector 运行——下一轮运行需要它们。cleanup.sh app-dir或--all会从应用目录剥离node_modules/dist/.git而不删除整个运行目录。注意run.sh刻意关闭了 git 隔离它会让--resume-session失效因为 Claude Code 将会话绑定到项目根即.git位置因此测试后用cleanup.sh清理残留物是推荐做法。12. 故障排查症状检查run.sh在 pre-flight 退出DB 容器是否启动docker compose … up -dspacetime 则spacetime start。端口被占用npx kill-port portmongodb 为 6001/6373。fix 模式打错端口已修复——run.sh在检测后端后会重算 Vite 端口select_vite_port。Mongo 应用被误判为 Postgres.benchmark-backend标记用于消歧确认它存在于应用目录。OTel 未捕获成本docker compose … logs otel-collector确认telemetry/logs.jsonl在增长。报告找不到遥测数据把generate-report.mjs指向日期运行目录而非后端子目录。WSL/CI 下脚本失败现在应为 LF.gitattributes看到\r错误就重新 checkout。会话上下文耗尽降低等级或恢复./run.sh --upgrade dir --level N --resume-session。关于--resume-sessionrun.sh会扫描$VARIANT_DIR下所有telemetry/*/metadata.json找到appDir匹配当前应用的最新sessionId然后以--resume SESSION_ID --fork-session派生会话——从而复用之前的上下文与缓存。13. 快速参考完整的 MongoDB 通过cd tools/llm-sequential-upgrade docker compose -f docker-compose.otel.yaml up -d export ANTHROPIC_MODELclaude-sonnet-4-6 ./run.sh --level 1 --backend mongodb # → APP打印出的 app dir # grade at http://localhost:6373 → 写 GRADING_RESULTS.md BUG_REPORT.md ./run.sh --fix $APP # 与评分交替直到干净 ./reset-app.sh $APP # 重新评分前清空数据库 for L in 2 3 4 5 6 7 8 9 10 11 12; do ./run.sh --upgrade $APP --level $L # 每等级执行 grade → fix 循环 done node generate-report.mjs sequential-upgrade/sequential-upgrade-$(date %Y%m%d)这套流程对应 runbook 的第 4 节核心循环也是 tools/llm-sequential-upgrade/CLAUDE.md 中为 AI 会话定义的自动化工作流。若你想对比 SpacetimeDB把上面命令中的mongodb换成spacetime先spacetime start启动服务并在每轮升级时注意 SpacetimeDB 特有的模式变更迁移问题当 schema 变化升级中常见时普通spacetime publish会因需要迁移而弹出[y/N]交互headless 下会挂起应跳过它直接使用非交互式擦除发布echo y | spacetime publish chat-app-timestamp --module-path backend-dir --delete-data详见 backends/spacetime.md 的 Redeploy 章节。14. 关键文件索引文件作用RUNBOOK.md本文所依据的原始运维手册run.sh核心编排generate / upgrade / fix端口分配、预检、OTel 注入、CLAUDE.md 拼装run-loop.sh穷举循环批处理generate→grade→fix→upgradeGRADING.md人工浏览器评分协议与GRADING_RESULTS.md格式generate-report.mjs聚合 cost-summary.json 功能得分产出BENCHMARK_REPORT.mdreset-app.sh按后端重置数据库drop / push / 重新 publish 模块cleanup.sh剥离应用目录的依赖与构建产物docker-compose.otel.yamlOTel Collector PostgreSQL MongoDB 基础设施otel-collector-config.yamlOTLP → JSONL 的管道配置templates/BUG_REPORT与ITERATION_LOG规范模板backends/各后端架构 / SDK 参考文档注入 AI 会话最后提醒一条纪律本基准的得分只取决于观察到的浏览器行为成本只取决于 OTel 捕获的真实账单两者都必须严格遵守才能让不同后端之间的对比数据经得起推敲。【免费下载链接】SpacetimeDBDevelopment at the speed of light项目地址: https://gitcode.com/GitHub_Trending/sp/SpacetimeDB创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考