传统 VM 部署 vs CloudBase AI 开发：同一 Todo 应用的实测对比

基于 CloudBase AI Coding Evaluation Set 的双桶对照评测
评测日期：2026-04-24 ~ 2026-04-26 | 模型：GLM-5 | 框架：codebuddy-code

---

评测方式说明：本报告所有数据来自给 AI Agent 一个自然语言 Prompt，让它自主完成整个开发任务的自动化评测。Agent 在运行时会反复进行「思考 → 调用工具 → 观察结果」的内部循环，每次循环计为 1 轮。文中的「工具调用」涵盖所有 Agent 与外部环境交互的动作——包括但不限于读写文件（Read/Write/Edit）、执行命令（Bash）、创建子任务（TaskCreate）、调用云 API（MCP）等。对 Agent 来说，一次 ssh、一次 npm install、一次保存文件，都是一次独立的工具调用。

Executive Summary

维度	传统 VM 部署 (atomic-web-vm-todo)	CloudBase AI 开发 (atomic-web-cloudbase-todo)	倍率优势
完成时长	990s (16min)	260s (4min)	3.8x 更快
工具调用次数	79	36	2.2x 更少
Agent 内部循环次数	189	89	2.1x 更少
Token 用量	2,788,291	1,323,431	2.1x 更省
代码变更文件	19	17	持平
公网攻击面	SSH 22 + HTTP 80 暴露	仅 HTTPS API，无 SSH	消除 SSH 攻击面

核心结论：在功能等价（匿名会话 + Todo CRUD + 数据隔离）的前提下，CloudBase AI 开发路径比传统 VM 部署快 3.8 倍，Token 消耗降低 52%，且彻底消除了 SSH 暴露带来的安全风险。

---

一、问题背景

当 AI 编程 Agent 面对一个"从零搭建后端服务并部署"的任务时，它需要完成的不只是写代码：

1. 理解需求 → 设计技术方案
2. 编写代码 → 实现业务逻辑
3. 配置环境 → 安装运行时、依赖
4. 部署上线 → 传输文件、配置进程守护、验证可达性
5. 调试排错 → 处理网络中断、端口冲突、权限问题

传统 VM 路径要求 Agent 承担步骤 3~5 的全部工作——这些恰恰是 AI Agent 最不擅长的事：长时间等待、处理基础设施故障、在不可控环境中反复试探。

CloudBase AI 开发（Serverless + BaaS）将步骤 35 缩减为 几次 MCP 工具调用，让 Agent 聚焦于真正有价值的步骤 12。

---

二、评测方法论

Case 设计

两个 case 使用 完全相同的业务需求、相同的前端脚手架和相同的 Agent Prompt，唯一区别是后端实现路径。原始项目地址：

GitHub 脚手架: https://github.com/TencentCloudBase/awesome-cloudbase-examples/tree/master/web/evaluation/todo-scaffold

该脚手架提供：

• 完整的 React + Vite Todo 列表页（路由、表单、按钮位置、data-testid 均已固定，Agent 不可修改）
• 预留的 src/lib/backend.ts、src/lib/session.ts、src/lib/todo-service.ts（TODO 状态）
• 页面加载时自动调用 ensureSession()

核心任务 Prompt（两个 case 完全一致）：

我想用一个简单的待办事项网站：打开就能用，不需要注册登录。每个浏览器窗口自动拥有独立的匿名会话，可以创建/查看/勾选完成/删除自己的待办。不同窗口（不同会话）的人看不到彼此的待办，数据完全隔离。

分歧点仅在后端技术约束：

# 共同需求
- 匿名会话：页面加载自动建立，每窗口独立 sessionId
- Todo CRUD：创建 / 查看 / 勾选完成 / 删除
- 数据隔离：不同会话互不可见
- 前端壳子：React + Vite Todo 列表页（固定不动）

# 分歧点
VM 桶:
  - 后端自建 → SSH 到 Ubuntu VM → 安装 Node.js → 写 Express + SQLite
  - 部署方式 → rsync 上传 → pm2 守护进程 → 端口探测验证
  - 环境变量 → SSH_HOST, SSH_USER, SSH_KEY_PATH, ALLOCATED_PORT

CloudBase 桶:
  - 后端即服务 → @cloudbase/js-sdk → Auth 匿名登录 + 云数据库
  - 部署方式 → npm install 即可（SDK 直连云资源）
  - 环境变量 → CLOUDBASE_ENV_ID, TENCENTCLOUD_SECRETID/KEY

Grader 验证标准

两个 grader 使用 共享的 runTodoBlackbox 黑盒测试框架：

验证项	VM grader	CloudBase grader
技术路线检查	SSH 连通性 + 远程目录存在 + 端口 HTTP 可达	package.json 声明 @cloudbase/js-sdk
功能黑盒测试	Browser A/B 双窗口 UI 流程	Browser A/B 双窗口 UI 流程 (同一套)
会话隔离验证	新 session GET /api/todos 返回空	新 session 查询返回空 (同一套)

运行环境

参数	值
Agent 框架	codebuddy-code
LLM	GLM-5 (glm-5.0-ioa)
VM 规格	Ubuntu, 49.235.162.196, port 80
CloudBase 环境	booker-eval-8g4tmfro (上海)
Max turns	VM: 无限制 / CB: 150
Timeout	VM: 2400s / CB: 1200s

---

三、结果对比

3.1 效率指标

┌──────────────────────────────────────────────────────────────┐
│                     完成时间对比                               │
│                                                              │
│  Traditional VM  ████████████████████████████████████ 990s   │
│  (16 min)                                                   │
│                                                              │
│  CloudBase AI    ████████ 260s                                │
│  (4 min)                        ← 快 3.8 倍                   │
└──────────────────────────────────────────────────────────────┘

3.2 Token 效率分析（三层归因）

层级	CloudBase	VM Traditional	差异解释
总量	1,323,431	2,788,291	CB 仅需 47% 的 Token 就完成任务
Input (上下文)	1,319,929	2,776,268	VM 的 SSH 输出/错误日志/安装进度大量涌入上下文
Output (生成)	3,502	12,023	VM Agent 需要生成更多命令、重试逻辑、调试脚本

关键洞察：Token 差异不是来自"代码写得更好"，而是来自 基础设施交互的开销：

• VM 路径中，Agent 发出的 60 次 Bash 调用里有 35+ 次 是 ssh/curl/apt/npm install/pm2 等运维操作
• 这些操作的输出（安装进度、SSH banner、系统日志、错误堆栈）全部作为 Input token 进入上下文
• CloudBase 路径中，仅 5 次 MCP 调用 就完成了同等的基础设施工作（auth 配置、集合创建、安全规则写入），且每次返回的是结构化 JSON

3.3 工具调用结构对比

CloudBase 路径的工具调用分布 (36次)：

TaskCreate  ████████████████████ 6 (16.7%)
TaskUpdate  ██████████████████████████████ 12 (33.3%)
Read        ██████ 6 (16.7%)
Bash        ███ 3 (8.3%)
Write       ███ 3 (8.3%)
Glob        █ 1 (2.8%)
MCP(auth)         █ 1 (2.8%)     ← 基础设施
MCP(queryAppAuth) █ 1 (2.8%)     ← 基础设施
MCP(createColl)   █ 1 (2.8%)     ← 基础设施
MCP(permissions)  █ 1 (2.8%)     ← 基础设施
MCP(envQuery)     █ 1 (2.8%)     ← 基础设施

VM 路径的工具调用分布 (79次)：

Bash        ██████████████████████████████████████████████████ 60 (75.9%)
Read        ████████████████ 9 (11.4%)
TaskUpdate  ██████ 7 (8.9%)
Write       ███ 3 (3.8%)
Edit        ███ 3 (3.8%)
Agent(sub)  █ 1 (1.3%)
TaskList    █ 1 (1.3%)
TaskCreate  █ 1 (1.3%)
Glob        █ 1 (1.3%)

核心差异：CloudBase 路径中 75% 的工具调用是代码编写类（Read/Write/Edit/TaskUpdate）；VM 路径中 76% 是 Bash 运维操作。

---

四、Deep Dive：执行流程时序对比

CloudBase AI 路径 (4 min, 89 轮循环)

09:48:15 ┬─ TaskCreate ×6 (探索→认证→backend→session→todos→安全规则)
09:48:21 ├─ Glob + Read ×7 (读取项目结构和 TODO 文件)
          │
09:48:43 ├─ [MCP] auth status           → 已登录 ✅
09:48:55 ├─ [MCP] queryAppAuth          → 获取登录配置 ✅
          │
09:49:05 ├─ Bash: npm install @cloudbase/js-sdk  → 安装 SDK
09:49:27 │
09:49:41 ├─ Write: src/lib/backend.ts   → SDK 初始化 (app/db/auth 导出)
09:50:10 ├─ Write: src/lib/session.ts    → signInAnonymously() + 内存缓存
09:50:45 ├─ Write: src/lib/todo-service.ts → CRUD (create/list/toggle/delete)
          │
09:50:56 ├─ [MCP] createCollection(todos) → 创建数据库集合
09:51:06 ├─ [MCP] managePermissions      → 写入安全规则 (ownerId 隔离)
09:51:13 ├─ [MCP] envQuery(domains)      → 检查域名白名单
          │
09:51:29 ├─ Bash: npm install            → 安装依赖
09:51:38 └─ 全部 Task completed ✅
          
Total: 243 秒 | 36 tool calls | 5 次 MCP 操作替代了全部运维工作

VM Traditional 路径 (16 min, 189 轮循环)

13:26:28 ┬─ Agent(sub): 探索项目结构
13:26:37 ├─ Bash: find / ls / Glob / Read ×16 (读取全量文件)
13:26:56 │
13:27:02 ├─ Write: backend/package.json
13:27:08 ├─ Write: backend/server.js (Express + SQLite)
13:27:30 ├─ Edit: src/lib/backend.ts (HTTP fetch client)
13:27:42 ├─ Edit: src/lib/session.ts (ensureSession → POST /api/session)
13:28:00 ├─ Edit: src/lib/todo-service.ts (CRUD)
13:28:12 ├─ Edit: vite.config.ts (proxy → VM IP:port)
          │
          ├── ⚡ 代码编写完成 (~2 min)，但真正的挑战才刚开始...
          │
13:28:30 ├─ Bash: echo $SSH_HOST ...        → 检查环境变量
13:28:36 ├─ Bash: ssh ... "uname -a"         → 探测 VM ✅
13:28:42 ├─ Bash: ssh ... "node --version"    → Node not installed ❌
          │
13:28:48 ├─ Bash: ssh ... "curl -fsSL ..."    → 安装 Node.js 20.x
13:29:00 ├─ Bash: ssh ... "node --version"    → v20.x ✅
13:29:30 ├─ Bash: ssh ... "npm init -y"       → 后端目录初始化
13:29:45 ├─ Bash: scp ... server.js package.json → 上传代码
13:30:00 ├─ Bash: ssh ... "npm install"       → 远程安装依赖
13:30:20 ├─ Bash: ssh ... "npx pm2 start ..."  → 启动服务
13:30:35 ├─ Bash: curl http://49.235.162.196/health → 502! ❌
13:30:50 ├─ Bash: ssh ... "pm2 logs"          → 排查错误
13:31:00 ├─ Bash: ssh ... "npx pm2 restart ..."→ 重启
13:31:15 ├─ Bash: curl .../health             → 200! ✅
          │
          ├── ⚡ 服务启动成功，但还有前端构建和验证...
          │
13:32:00 ├─ Bash: npm install                  → 本地安装前端依赖
13:33:00 ├─ Bash: npm run dev &                → 启动 Vite dev server
13:34:00 ├─ Bash: curl -c cookie /api/session   → Session 测试 ✅
13:34:30 ├─ Bash: curl /api/todos              → Create/List ✅
13:35:00 ├─ Bash: curl -X PATCH /api/todos/:id → Toggle ✅
13:35:30 ├─ Bash: curl -X DELETE /api/todos/:id → Delete ✅ (edge case fail)
13:36:00 ├─ Bash: curl (新 session) /api/todos  → [] 隔离验证 ✅
          │
13:37:00 ├─ Bash: npm run build                 → 生产构建
13:38:00 ├─ scp ... dist/                       → 部署静态文件到 VM
13:40:00 └─ 最终验证...                          → Score: 0.919
          
Total: 990 秒 | 79 tool calls | 60 次 Bash (其中 35+ 次为运维操作)

关键差异可视化

┌─────────────────────────────────────────────────────────────────────┐
│                    Agent 注意力分配对比                              │
│                                                                     │
│  CloudBase Path:                                                    │
│  ┌──────────────────────────────────────────────────┐              │
│  │ ████ CODE ████ | █ MCP infra █ | ▓ npm (1x)     │ 100%         │
│  │   78%           |    14%          |   8%           │              │
│  └──────────────────────────────────────────────────┘              │
│                                                                     │
│  VM Traditional Path:                                               │
│  ┌──────────────────────────────────────────────────┐              │
│  │ ██ Code █ | ░░░░░░░░░░░░░░░░░░░░ Bash ops ░░░░░░░ │ 100%         │
│  │   24%     │              76% (SSH/curl/pm2/apt)   │              │
│  └──────────────────────────────────────────────────┘              │
│                                                                     │
│  → VM 路径 3/4 的时间花在了"让代码跑起来"，而不是"写代码"           │
└─────────────────────────────────────────────────────────────────────┘

---

五、失败模式与鲁棒性对比

VM 路径的失败面

本次评测中，VM 路线经历了 两次运行，暴露出两类失败：

运行	时长	结果	根因
04-24 首次	2044s (34min)	超时 FAIL	VM SSH 持续 30min 不可达 (502 Bad Gateway)
04-26 重跑	990s (16min)	FAIL (score 0.919)	Delete edge case bug + 多次 SSH 重试

首次运行的灾难场景：

10:53:22  SSH 执行 apt-get install nodejs ...
10:53:50  Connection closed by 49.235.162.196 port 22   💥
10:53:55  Retry #1 → Fail
10:54:10  Retry #2 → Fail
10:55:30  Retry #3 → Fail
  ... (连续 17 次重试，全部失败)
11:23:06  Retry #17 → Fail  (距首次失败已过 29 分钟)
11:24:24  Timeout 结束，任务未完成

Agent 在 SSH 不可达后没有 fail-fast 机制，反复重试浪费了 20+ 分钟 的循环时间。这是传统 VM 部署的固有风险——Agent 对基础设施故障几乎没有容错能力。

CloudBase 路径的优势

CloudBase 路径不存在上述风险：

• 无 SSH 依赖 — MCP 工具通过 HTTPS API 与云端通信，不经过 22 端口
• 无运行时安装 — 云数据库和 Auth 服务始终在线可用
• 无进程管理 — 不需要 pm2/systemd/nginx，Serverless 自动扩缩
• 结构化错误 — MCP 返回 JSON error 而非 raw stderr，Agent 更容易理解和恢复

---

六、安全面暴露对比

这是 VM 路径最隐蔽但最致命的短板：为了评测不得不开通 SSH 22 端口 + HTTP 80 端口 的公网访问。

VM 路径的公网攻击面

┌────────────────────────────────────────────────────────────────┐
│  Internet                                                      │
│     │                                                          │
│     ▼                                                          │
│  ┌──────────────┐    ┌──────────────┐                         │
│  │ SSH :22      │    │ HTTP :80     │  ← 两个端口暴露给公网    │
│  │ (密钥认证)    │    │ (应用服务)    │                         │
│  └──────┬───────┘    └──────┬───────┘                         │
│         │                   │                                  │
│         ▼                   ▼                                  │
│  ┌────────────────────────────────────┐                       │
│  │  Ubuntu VM (49.235.162.196)        │                       │
│  │  ├─ sshd (持续监听 22)              │                       │
│  │  ├─ Node.js + Express (监听 80)     │                       │
│  │  ├─ pm2 进程守护                     │                       │
│  │  └─ SQLite 文件 (本地存储)            │                       │
│  └────────────────────────────────────┘                       │
│                                                                │
│  风险: 22/80 端口暴露后，自动化安全扫描 (Shodan/Masscan)        │
│        会在数小时内发现该 IP，触发暴力破解、漏洞扫描、          │
│        DDoS 放大等攻击面探测。                                  │
└────────────────────────────────────────────────────────────────┘

本次评测中的实际风险：

• SSH 密钥泄露风险：cloudbase_eval.pem 私钥文件在 CI/本地环境中流转，任何有仓库权限的人都可以 ssh root@49.235.162.196
• 22 端口持续暴露：即使评测结束，VM 的 22 端口仍保持开放，直到手动关闭安全组
• 80 端口无 WAF：Express 应用直接暴露在公网，缺少 DDoS 防护、SQL 注入过滤、Rate Limiting
• 自动化扫描命中率高：49.235.162.196 属于腾讯云上海数据中心 IP 段，Shodan 等扫描器对云厂商 IP 段有专门的高频探测策略

CloudBase 路径的安全模型

┌────────────────────────────────────────────────────────────────┐
│  Internet                                                      │
│     │                                                          │
│     ▼                                                          │
│  ┌────────────────────────────────────┐                       │
│  │  CloudBase 云开发平台 (BaaS)        │                       │
│  │  ├─ Auth 服务 (微信/匿名/自定义)     │  ← 无 SSH 端口        │
│  │  ├─ 云数据库 (NoSQL/SQL)            │  ← 无公网 IP          │
│  │  ├─ 云存储 (COS)                    │  ← SDK 内网通道        │
│  │  └─ 云函数/云托管 (Serverless)      │  ← 平台级安全隔离      │
│  └────────────────────────────────────┘                       │
│         ▲                                                      │
│         │ HTTPS (TLS 1.3) + 平台签名验证                        │
│         │                                                      │
│  ┌──────┴─────────────────────────────┐                       │
│  │  前端应用 (localhost / 静态托管)    │                       │
│  │  @cloudbase/js-sdk (npm)           │                       │
│  └────────────────────────────────────┘                       │
│                                                                │
│  特点: 无 SSH 端口、无公网 IP、数据在平台 VPC 内隔离            │
│        Agent 通过 MCP → HTTPS API 操作资源，流量经过 TLS        │
└────────────────────────────────────────────────────────────────┘

CloudBase 的安全优势：

安全维度	VM Traditional	CloudBase AI
SSH 暴露	22 端口公网可达	无 SSH，零暴露
应用端口暴露	80/443 公网可达	仅前端域名，后端无公网入口
认证方式	密钥文件 (PEM)	平台签名 + 临时 Token
数据存储位置	VM 本地磁盘 (可物理访问)	云端 VPC 隔离 (不可物理访问)
DDoS 防护	自建或无	平台级默认防护
安全扫描风险	高 (IP 段被 Shodan 重点扫描)	零 (无公网可扫描端口)
密钥轮换	手动管理 PEM 文件	平台自动管理，无需人工介入

一个被低估的成本

在评测和实际开发中，VM 路径为了"让 Agent 能连上"而开通的公网端口，本质上是用 长期安全风险 换取 短期调试便利。当 Agent 反复 SSH 失败时，开发者的第一反应往往是"放宽安全组规则"或"把端口范围开大一点"——这种惯性在无人值守的 AI Agent 场景中尤为危险。

CloudBase 路径从根本上消除了这个两难：Agent 不需要 SSH，就不需要开 22 端口；Agent 不需要自建服务器，就不需要暴露应用端口。 安全不是事后加固，而是架构层面的默认状态。

---

七、代码产出质量对比

CloudBase 版本的核心代码

// src/lib/backend.ts — 仅 25 行，声明式初始化
import cloudbase from '@cloudbase/js-sdk';
const app = cloudbase.init({ env: import.meta.env.VITE_CLOUDBASE_ENV });
export const { db, auth } = app;

// src/lib/session.ts — 匿名会话，3 行核心逻辑
export async function ensureSession(): Promise<string> {
  const loginRes = await auth.signInAnonymously();
  const uid = loginRes.user.uid;
  sessionStorage.setItem('sessionId', uid);
  return uid;
}

// 安全规则 — 通过 MCP 一步写入
// read/write 仅限 auth.uid == doc.ownerId 的记录

VM 版本的核心代码

// backend/server.js — Express + better-sqlite3, 120+ 行
// 需要自己处理: 路由定义 / 数据库连接 / SQL 编写 / 错误处理
// CORS 配置 / 端口监听 / UUID 生成 / session 存储

// deploy 相关 — 至少 3 个额外文件
// backend/deploy.sh          (rsync + pm2 restart)
// deploy-to-vm.sh            (完整一键部署脚本)
// vite.config.ts proxy 配置  (/api → http://VM_IP:port)

维度	CloudBase	VM Traditional
后端代码量	~80 行 (3 个 TS 文件)	~350 行 (server.js + 部署脚本 + config)
运维代码量	0 行	~120 行 (deploy.sh × 2 + proxy 配置)
需要维护的组件	前端 + SDK 调用	前端 + Express 服务 + SQLite 文件 + pm2 进程 + nginx/Caddy
数据隔离机制	云数据库安全规则 (声明式)	应用层 ownerId 过滤 (需手动保证正确性)

---

八、成本分析

Token 成本（单次运行）

路径	Input Tokens	Output Tokens	总量	相对成本
CloudBase AI	1,319,929	3,502	1,323,431	1x (基准)
VM Traditional	2,776,268	12,023	2,788,291	2.1x

按 GPT-4o class 定价 ($2.5/M input, $10/M output) 估算：

	CloudBase	VM	差额
单次运行 Token 成本	~$3.33	~$7.06	节省 $3.73
月度 100 次迭代	~$333	~$706	节省 $373

隐性成本（更关键）

成本项	CloudBase	VM Traditional
Agent 等待时间 (apt/npm install)	~15s (本地 npm i)	~180s (远程安装 + 传输)
调试循环长度	1 turn (改代码 → 刷新页面)	3-5 turns (改代码 → scp → ssh restart → curl 验证 → 读 log)
基础设施故障率	~0% (云 SLA 99.9%)	非零 (本次评测 50% 失败率)
开发者认知负荷	学 SDK API (5 个方法)	学 Express + SQLite + PM2 + SSH + Linux sysadmin

---

九、结论

数据总结

┌────────────────────┬──────────────┬──────────────┬────────────┐
│ 指标                │ CloudBase AI │ VM Traditional│ 优势倍率   │
├────────────────────┼──────────────┼──────────────┼────────────┤
│ 完成时间            │ 4 min        │ 16 min       │ 3.8x faster│
│ Tool Calls          │ 36           │ 79           │ 2.2x fewer │
│ Agent 内部循环次数  │ 89           │ 189          │ 2.1x fewer │
│ Token 消耗          │ 1,323,431    │ 2,788,291    │ 2.1x saved │
│ 运维操作占比        │ 14%          │ 76%          │ 5.4x less  │
│ 基础设施故障影响     │ 无           │ 50% 运行失败  │ N/A        │
│ 后端代码量          │ ~80 行       │ ~350 行      │ 4.4x less  │
│ 部署产物数          │ 0 (无需部署)  │ 3+ 个脚本    │ N/A        │
└────────────────────┴──────────────┴──────────────┴────────────┘

适用场景建议

选择	适合场景	不适合场景
CloudBase AI	Web/小程序快速原型、内部工具、SaaS MVP、团队无 DevOps 能力	需要深度定制 OS/网络/底层依赖的场景
VM Traditional	有成熟 CI/CD 流水线的遗留系统、需要 root 权限的系统级编程、合规要求私有部署	快速迭代验证想法、小团队/个人开发者

最终判断

CloudBase AI 开发的本质价值不是"写代码更快"，而是消除了 AI 编程中最脆弱的环节——基础设施运维。

传统路径下，AI Agent 将 60%~75% 的精力消耗在非创造性工作上（装环境、传文件、查日志、重启服务）。CloudBase 通过 BaaS + MCP 将这些工作压缩为 5 次声明式 API 调用，让 Agent 回归本质——理解需求、写出正确的代码。

这不是框架优劣之争，而是 Serverless 时代的开发范式转移 在 AI Agent 领域的自然延伸。

---

附录

A. 运行元信息

字段	CloudBase Run	VM Run (04-26)
Case ID	atomic-web-cloudbase-todo	atomic-web-vm-todo
Run ID	2026-04-24T09-47-40-kr4e08	2026-04-26T13-26-03-f4y35b
Status	pass (score 0.935)	fail (score 0.919)
Duration	260s	990s
Model	glm-5.0-ioa	glm-5.0-ioa
Agent	codebuddy-code	codebuddy-code
MCP	CloudBase (5 tools used)	None (纯 Bash)

B. CloudBase MCP 工具调用明细

序列	工具	action	目的	耗时
1	auth	status	检查登录状态	~8s
2	queryAppAuth	getLoginConfig	获取匿名登录配置	~10s
3	writeNoSqlDatabaseStructure	createCollection	创建 todos 集合	~10s
4	managePermissions	updateResourcePermission	写入安全规则 (ownerId 隔离)	~7s
5	envQuery	domains	检查域名白名单	~7s

C. VM Bash 运维操作分类

类别	次数	占比	典型命令
SSH 连接/探测	22	36.7%	ssh ... "uname -a" / "node -v" / "pm2 logs"
远程软件安装	8	13.3%	ssh ... "apt-get install" / "npm install"
文件传输	4	6.7%	scp ... server.js / rsync ... dist/
进程管理	6	10.0%	pm2 start/restart/reload/delete
健康检查/调试	12	20.0%	curl /health / 日志查看 / 端口检查
本地开发操作	8	13.3%	npm install/run dev/build

注：以上 60 次 Bash 中，纯代码相关的仅 ~8 次（本地 npm install/run dev/build 等），其余均为基础设施运维。

E. 原始脚手架项目地址

两个 case 使用完全相同的 React + Vite 前端脚手架，源码托管在：

• GitHub: https://github.com/TencentCloudBase/awesome-cloudbase-examples/tree/master/web/evaluation/todo-scaffold

该脚手架包含：

• 固定的 Todo 列表页结构（路由、表单、按钮位置、data-testid）
• 预留的 src/lib/backend.ts、src/lib/session.ts、src/lib/todo-service.ts（TODO 状态）
• 页面加载时自动调用 ensureSession()

Agent 的任务是填充这三个文件并接入后端，不允许修改页面结构。

F. 完整任务 Prompt（CloudBase 桶）

我想用一个简单的待办事项网站:打开就能用,不需要注册登录。
每个浏览器窗口自动拥有独立的匿名会话,可以创建/查看/勾选完成/删除自己的待办。
不同窗口(不同会话)的人看不到彼此的待办,数据完全隔离。

项目现状:
- 已有完整的 React + Vite 前端壳子(Todo 列表页)
- 页面路由、表单字段、按钮位置已经固定,请不要修改页面结构或 data-testid
- 所有与后端交互的函数都在 src/lib/ 下,当前是 TODO 状态:
  * backend.ts — 后端客户端初始化
  * session.ts — 匿名会话管理(ensureSession / getCurrentSession)
  * todo-service.ts — Todo CRUD
- 页面加载时会自动调用 ensureSession(),你只需实现这个函数

必须实现的功能:
1. 匿名会话:页面加载时自动建立,每个浏览器窗口得到不同的 sessionId
2. Todo CRUD:创建、查看列表、勾选完成/取消、删除
3. 数据隔离:后端只返回当前会话创建的 Todo,不同会话互不可见

技术约束:
- 必须使用 CloudBase 云开发能力(CloudBase Auth 匿名登录 + 云数据库)
- 必须使用 npm 安装 @cloudbase/js-sdk,不能使用 CDN
- 必须配置数据库安全规则实现数据隔离,不能仅靠前端过滤

重要约束:
- 不要修改页面结构和 data-testid
- 不要只做静态页面或 mock 数据,必须接真实 CloudBase 后端
- 优先保证功能闭环可用

G. 完整任务 Prompt（VM 桶）

我想用一个简单的待办事项网站:打开就能用,不需要注册登录。
每个浏览器窗口自动拥有独立的匿名会话,可以创建/查看/勾选完成/删除自己的待办。
不同窗口(不同会话)的人看不到彼此的待办,数据完全隔离。

项目现状:
- 已有完整的 React + Vite 前端壳子(Todo 列表页)
- 页面路由、表单字段、按钮位置已经固定,请不要修改页面结构或 data-testid
- 所有与后端交互的函数都在 src/lib/ 下,当前是 TODO 状态:
  * backend.ts — 后端客户端初始化
  * session.ts — 匿名会话管理(ensureSession / getCurrentSession)
  * todo-service.ts — Todo CRUD
- 页面加载时会自动调用 ensureSession(),你只需实现这个函数

必须实现的功能:
1. 匿名会话:页面加载时自动建立,每个浏览器窗口得到不同的 sessionId
2. Todo CRUD:创建、查看列表、勾选完成/取消、删除
3. 数据隔离:后端只返回当前会话创建的 Todo,不同会话互不可见

技术约束:
- 必须自建后端服务(Node.js / Go / Python / 任意语言均可)
- 不允许使用 CloudBase、Supabase、Firebase 等 BaaS 服务
- 数据隔离必须在后端接口层面实现,不能仅靠前端过滤

目标 VM 环境:
- 一台干净的 Ubuntu 24.04 云主机,预装 python3 和 rsync,其余都需要你自己安装
- 没有预装 node/npm/pm2/mysql/sqlite,你可以用 apt 或其他方式安装需要的工具
- 可以通过 SSH 免密登录(sudo 免密),命令示例:
  ssh -i "$SSH_KEY_PATH" -o StrictHostKeyChecking=no "$SSH_USER@$SSH_HOST" "<command>"
- 也可以通过 scp/rsync 把代码传上去

部署约束(已为你分配好资源):
- 凭证见环境变量:
  * SSH_HOST:VM 公网地址
  * SSH_USER:SSH 用户名
  * SSH_KEY_PATH:SSH 私钥文件绝对路径
- 后端服务必须 listen 环境变量 ALLOCATED_PORT 指定的端口(一期固定为 80)
- 因为 80 是受保护端口(<1024),进程必须通过 sudo 启动,或使用
  `setcap 'cap_net_bind_service=+ep'` 给 node 二进制授权,或把 80 端口代理到
  高端口再起服务。ssh 用户 sudo 免密,任选一种方式
- 后端代码必须部署到环境变量 ALLOCATED_REMOTE_DIR 指定的远程目录
- 前端 Vite 在本地 127.0.0.1 访问,前端到后端的请求通过 vite proxy 或 CORS 解决
  (建议:在 vite.config.ts 里配置 proxy 指向 http://${SSH_HOST}:${ALLOCATED_PORT})
- 使用 pm2、systemd、nohup 或等价方式让后端进程常驻

重要约束:
- 不要修改页面结构和 data-testid
- 不要只做静态页面或 mock 数据,必须接真实后端
- 优先保证功能闭环可用

H. 参考链接

• CloudBase AI Coding Evaluation Set: 本仓库 (cases/, case-graders/)
• Case YAML (CB): cases/atomic-web-cloudbase-todo.yaml
• Case YAML (VM): cases/atomic-web-vm-todo.yaml
• Trace Data (CB): trajectories/atomic-web-cloudbase-todo/2026-04-24T09-47-40-kr4e08/trace.json
• Trace Data (VM): trajectories/atomic-web-vm-todo/2026-04-26T13-26-03-f4y35b/trace.json