如何使用Next.js、AWS以及沙箱环境来构建属于自己的、类似于Lovable这样的AI应用开发工具

以下是我测量得到的结果，这些数据是直到预览页面真正加载完成为止所记录的：

这速度差不多快了8倍，真是太厉害了！😎

代理循环

代理循环是整个系统的核心。每当用户发送一个提示时，就会启动这个循环。

虽然实现过程可能比较复杂，但原理其实很简单：你给大语言模型设定一个目标，并提供一些工具让它使用，然后收集结果并重复这个过程，直到任务完成。

代理可以使用的工具包括：

• list_files、read_file、write_file、edit_file和delete_file

• run_command，用于执行像npx tsc --noEmit这样的简单命令

• install_packages，用于安装npm包

• get_dev_server_logs和get_browser_errors，用于辅助调试

• finish，当代理完成任务时就会调用这个函数

这些工具实际上都只是包含Zod数据结构定义和run函数的简单脚本文件。以edit_file为例：

export const editFile = defineTool({
  name: "edit_file",
  description:
    "用于替换文件中某个特定的文本片段。`search`参数必须能够精确匹配目标内容，并且该内容在文件中只能出现一次。",
  schema: z.object({
    path: z.string(),
    search: z.string().min(1),
    replace: z.string(),
  }),
  async run({ path, search, replace }, { sandbox }) {
    const text = await sandbox.readFile(path);
    const count = text.split(search).length - 1;
    if (count !== 1) {
      return {
        isError: true,
        content: `目标文本在${path}中出现了${count}次`,
      };
    }
    await sandbox.writeFile(
      path,
      text.replace(search, () => replace),
    );
    return { content: `文件${path}已修改`, changedFiles: [path] };
  },
});

Zod模式在这里发挥了双重作用：首先，它会被转换为JSON格式，以便供大语言模型使用（通过z.toJSONSchema实现）；其次，在任何数据进入沙箱环境之前，它会验证模型返回的数据是否有效。如果输入数据无效，错误信息会直接返回给模型，而不会导致整个运行流程崩溃。

接下来是实际的循环执行部分：

while (true) {
  if (signal.aborted) return result("cancelled");

  const res = await llm.chat({
    system: SYSTEM_PROMPT,
    messages,
    tools,
    signal,
    onText,
  });
  messages.push(res.message);

  const results = [];
  for (const call of res.message.toolCalls) {
    const out = await executeTool(call.name, call.input, ctx); // 验证数据并执行相应操作
    results.push({
      type: "tool_result",
      toolCallId: call.id,
      content: out.content,
      isError: out.isError,
    });
    if (out.finish) finishCalled = true;
  }

  if (!finishCalled) {
    messages.push({ role: "user", content: results });
    continue;
  }

  // 当代理表示任务已完成时，我们进行最终检查。（见下一节）
}

llm.chat这个调用函数是我专门编写的一个封装层，它可以使用相同的接口同时支持Anthropic和OpenAI模型，因此用户可以通过界面中的下拉菜单轻松切换使用不同的模型。

在Anthropic模型中，提示语缓存功能是开启的。说实话，这一功能在大幅降低计算成本方面发挥了关键作用——通常一次对话会消耗超过120,000个标记，而其中几乎所有的数据都直接来自缓存。

保护文件路径的安全性

这个问题的存在有点隐蔽，我也是在仔细检查代码时才发现的。沙箱环境中的文件API会拒绝处理包含..路径成分的请求，但它却会“顺利地”跟随符号链接进行操作。因此，如果生成的代码创建了一个指向/etc/passwd的leak.txt文件，那么读取这个文件就会直接获取到密码文件的内容，这显然是非常危险的。

为了解决这个问题，所有的文件处理操作都会在进入沙箱环境之前先解析出实际的路径：

async safePath(relPath: string) {
  const abs = resolveProjectPath(relPath); // 拒绝包含“..”的路径以及绝对路径、空字节
  const r = await this.sb.run("realpath", { args: ["-m", "--", abs] });
  const real = r.stdout.trim();
  if (!isInsideApp(real)) throw new SandboxPathError(relPath, "路径位于项目文件夹之外");
  return real;
}

realpath -m这个命令会跟随所有的符号链接，最终确定路径的实际指向位置。如果路径位于项目文件夹之外，该命令就会失败。

保持上下文信息的简洁性

在处理新的请求时，系统不会重新执行之前所有的操作步骤，而是会基于以下信息开始新一轮对话：

• 前面每次交互的简要总结（用户提出了什么要求，代理做出了哪些响应）

• 文件结构以及已安装的包列表

• 当前的src/App.tsx文件内容

让代理自行检查其工作结果

大语言模型们非常自信。当构建过程出现严重问题时，它们也会欣然告诉你一切正常。因此，当代理调用finish方法时，我们并不会仅仅相信它的说法。我们会在沙箱环境中执行三项检查：

export async function runChecks(sandbox: ProjectSandbox) {
  const tsc = await sandbox.exec("npx tsc --noEmit -p . 2>&1", {
    timeoutSecs: 120,
  });
  const build = await sandbox.exec(
    "npx vite build --outDir /tmp/build --emptyOutDir --logLevel error 2>&1",
    { timeoutSecs: 180 },
  );
  const render = await renderCheck(sandbox); // 在虚拟DOM中渲染一次应用程序

  return {
    ok: tsc.exitCode === 0 && build.exitCode === 0 && render.ok,
    typecheck: { ok: tsc.exitCode === 0, output: tsc.stdout },
    build: { ok: build.exitCode === 0, output: build.stdout },
    render,
  };
}

前两项检查非常直观。第三项检查才真正有趣——很多错误只有在运行时才会显现出来，比如Cannot read properties of undefined (reading 'map')这样的错误。通常人们会使用无头浏览器来进行这类测试，但在小型沙箱环境中，这种方法既繁琐又效率低下，所以我并不想采用这种方式。

因此，我们使用了另一个方案：模板中包含了一段小程序码，该代码会利用happy-dom（专为Node.js设计的虚拟DOM框架）以及Vite的ssrLoadModule功能来渲染一次应用程序：

GlobalRegistrator.register({ url: "http://localhost:5173/" });
document.body.innerHTML = '
<>/div>';
console.error = (...args) => errors.push(args.join(" "));

await server.ssrLoadModule("/src/main.tsx"); // 运行实际的应用程序入口文件
await new Promise((r) => setTimeout(r, 1500)); // 等待React完成渲染

const rendered = document.getElementById("root").innerHTML.trim().length > 0;
console.log(
  JSON.stringify({ ok: rendered && errors.length === 0, rendered, errors }),
);

这个过程只需要大约2秒钟，就能检测出undefined.map导致的错误，并准确指出出错所在的App.tsx文件行号。真是太棒了！

如果任何一项检查失败，错误信息会立即被发送回代理端，代理就会再次尝试修复这些问题：

lastCheck = await runChecks(sandbox);
if (lastCheck.ok) return result("succeeded");
if (healRounds >= maxHeal)
  return result("failed", { error: describeFailures(lastCheck) });

healRounds++;
messages.push({
  role: "user",
  content: [
    ...results,
    {
      type: "text",
      text: `验证失败。请修复这些问题，然后再调用finish方法。\n${describeFailures(lastCheck)}`,
    },
  ],
});

默认情况下，这个流程会进行3轮检查。如果经过3轮检查后问题仍未解决，系统就会向用户明确告知“无法完成这项任务”，并同时提供具体的错误信息。

向浏览器发送流式处理进度信息

代理程序在后台工作线程中运行，但用户是通过浏览器来查看处理进度的。因此，每一个处理步骤（如“编写了src/App.tsx文件”、“执行了npx tsc --noEmit命令”、“检查通过”等）都必须能够在两者之间实时传递。

后台工作线程会将每个处理步骤作为一条记录存储到run_events表中，然后通过Postgres发送NOTIFY通知：

export async function appendEvent(
  db: Db,
  e: { projectId: string; runId?: string; type: string; payload: unknown },
) {
  const [row] = await db
    .insert(runEvents)
    .values(e)
    .returning({ id: runEvents.id });
  await db.$client.notify(
    "events",
    JSON.stringify({ projectId: e.projectId, id: row.id }),
  );
  return row.id;
}

在Web端，Next.js的路由处理程序会利用“服务器发送事件”功能将这些信息实时传输给浏览器。当浏览器连接上后，它会首先重新播放当前正在进行的处理流程的所有步骤，之后就会持续监听新的更新信息：

const pump = async () => {
  const rows = await db
    .select()
    .from(runEvents)
    .where(and(eq(runEvents.projectId, project.id), gt(runEvents.id, cursor)))
    .orderBy(asc(runEvents.id));

  for (const r of rows) {
    cursor = r.id;
    send(`id: ${r.id}\ndata: ${JSON.stringify(r)}\n\n`);
  }
};

bus.on(project.id, pump); // 每个进程都会通过一个单独的监听连接来触发这个函数
pump(); // 先重新播放之前的所有步骤

由于所有的处理信息都存储在数据库中，因此在处理流程进行到一半时刷新页面也不会丢失任何数据。浏览器会重新连接并重新执行已完成的步骤，然后从上次停止的地方继续处理。点击“停止”按钮的效果也是一样的，只不过进程会反向终止。

注意：来自大语言模型的流式文本是按一个个令牌的形式传输的，如果将每个令牌都保存下来，那么每次更新就会在数据库中生成数百条记录。因此，后台工作线程会先将这些令牌暂存起来，每隔250毫秒才向数据库写入一条记录。我之前还发现了一个小问题：由于每次写入操作都是独立的异步操作，导致事件记录的顺序发生了混乱。后来通过将所有的写入操作纳入同一个异步处理链中，这个问题得到了解决。

实时预览网关

生成的应用程序的开发服务器运行在沙盒环境中，端口为5173，而提供者会通过类似https://5173-<sandbox-id>>.sandbox.example这样的URL将这个开发服务器暴露出来。虽然可以直接将这个URL放入iframe中使用，但这样做存在两个问题：

1. 浏览器要加载这个页面，就需要我们的沙盒API密钥。显然，用户是无法直接获取到这个密钥的。

2. 如果我们将这个URL公开，那么任何知道这个地址的人都可以访问它，我们就无法控制哪些人能够看到哪些内容了。

因此，我们在前面添加了一个自己的小型网关。该网关会将<project-id>>.preview.localhost:4000这样的请求路由到正确的沙盒环境，并在服务器端添加API密钥进行身份验证：

const proxy = createProxyServer({ changeOrigin: true, secure: true, ws: true });

const server = http.createServer(async (req, res) => {
  const projectId = HOST_RE.exec(req.headers.host ?? "")?.[1];
  const target = await resolve(projectId); // 将项目ID解析为对应的沙箱地址，该地址会被缓存几秒钟
  if (!target.sandboxId) return send(res, noPreviewPage());

  delete reqheaders.cookie; // 绝不转发访问者的身份凭证
  delete req.headersauthorization;
  proxy.web(req, res, {
    target: previewUrlFor(target.sandboxId),
    headers: { authorization: `Bearer ${API_KEY}` },
  });
});

// Vite的热重载功能是通过WebSocket来实现的，因此升级操作也会通过这个代理机制进行。
server.on("upgrade", async (req, socket, head) => {
  const target = await resolve(HOST_RE.exec(req.headers.host ?? "")?.[1];
  proxy.ws(req, socket, head, {
    target: previewUrlFor(target.sandboxId).replace (^https/, "wss"),
    headers: { authorization: `Bearer ${API_KEY}` },
  });
});

正是这个upgrade处理程序让预览功能具备了实时更新的能力。每当代理服务器编辑某个文件时，Vite会通过WebSocket将更改内容发送过去，这样预览页面就能自动更新，而无需用户重新加载页面。

设置这样一个代理服务器还有另一个原因，不过这个原因很容易被人们忽略。预览版本是在一个不同的域名下运行的（地址为*.preview.localhost），而主应用程序则运行在localhost:3000上。因此，生成的预览版本根本无法读取主应用程序的cookie信息，也无法以登录用户的身份调用其API接口。另外，由于在现代浏览器中，*.localhost会解析为127.0.0.1，所以甚至不需要修改系统的hosts文件就能实现这种隔离效果。

注意：模板还会在预览页面中插入一段小程序代码，这段代码会监听window.onerror事件，并将错误信息发送到父窗口。随后，工作区会将这些错误信息转发给后端服务器，而代理程序中的get_browser_errors工具就是从后端获取这些运行时错误的。

使用Git进行版本控制

每当用户完成一次开发操作，就会生成一个新的版本。因此，用户可以随时恢复到之前的某个具体版本，这有点类似于使用git reset命令。

对于这种需求来说，在沙箱环境中使用普通的Git工具就完全足够了。初始状态下的代码库中已经包含了模板文件作为第一个提交内容，而在每次开发操作完成后，工作进程都会将所有更改提交到代码库中：

export async function commitAll(ps: ProjectSandbox, message: string) {
  const out = await git(
    ps,
    `git add -A
if git diff --cached --quiet; then
  echo NOCHANGE
else
  git commit -q -m "$MSG"
  git rev-parse HEAD
  git show --name-only --format= HEAD
fi`,
    { MSG: message },
  );
  if (out.trim() === "NOCHANGE") return null;
  const [sha, ...files] = out.trim().split("\n");
  return { sha, files };
}

注意：你可能会疑惑为什么这里没有exit 0这条命令。实际上，这些命令是在bash -l环境下运行的，而在登录 shell环境中直接使用exit命令会执行~/.bash_logout脚本，而在这个脚本中如果最后一条命令失败了，就会导致退出代码变为错误码。这个问题确实花了我好长时间才弄明白。😭

恢复操作并不会改写历史记录。它只是让文件内容与之前的提交版本完全一致，然后将其作为一个新的版本进行提交。因此，“恢复版本1”实际上会生成版本5，而你仍然可以随时回到版本4。没有任何数据会被丢失。

保持历史记录的持久性（无需在沙箱中使用令牌）

虽然沙箱环境中的Git功能非常实用，但它存在的时长仅与沙箱本身相同。因此，在每个版本更新后，相关历史记录也会被推送到一个托管的Git仓库中。

最直接的做法是为沙箱分配一个Git令牌，然后直接执行`git push`命令。但我能够使用的那些令牌是针对整个项目而言的，并不是针对某个单独的仓库。将这样的令牌用于包含不可信代码的沙箱中？显然，这是不可取的。

因此，沙箱本身并不会直接执行推送操作。它会创建一个`git bundle`文件（实际上就是将整个仓库内容压缩成一个文件），然后由其他进程读取这个文件并完成推送操作：

export async function pushToHostedGit(
  ps: ProjectSandbox,
  repo: string,
  dataDir: string,
) {
  await git(ps, "git bundle create -q /tmp/repo.bundle main");
  const bundle = await ps.sb.readFile("/tmp/repobundle");

  const mirror = join(dataDir, "git", `${repo}.git`); // 在工作进程中创建一个空的Git仓库
  writeFileSync(join(mirror, "incoming.bundle"), bundle);
  await run("git", [
    "-C",
    mirror,
    "fetch",
    "-q",
    "--force",
    "incomingbundle",
    "+refs/heads/main:refs/heads/main",
  });

  const cred = await repos.credential(repo); // 在工作进程中使用的临时令牌
  await run("git", [
    "-C",
    mirror,
    "-c",
    `http.extraHeader=Authorization: Basic ${basic(cred)}`,
    "push",
    "-q",
    "--force",
    url,
    "main",
  ]);
}

这种做法还有一个很好的副作用，那就是它也能够支持remix功能。当有人复制了一个共享项目时，工作进程会从托管仓库中读取源项目的文件内容，并将其放入一个新的沙箱中，而原来的沙箱甚至不需要被重新启动。

沙箱的暂停、唤醒与共享

即使没有人正在使用一个处于运行状态的沙箱，它仍然会消耗资源。因此，系统会每隔一分钟执行一次检查任务，如果某个沙箱已经10分钟没有被任何进程访问过，就会将其暂停。这样就可以节省内存资源，确保开发服务器能够保持之前的状态。

沙箱的唤醒过程是在网关中完成的。当有人尝试查看一个处于暂停状态的项目时，网关会显示一个“正在唤醒您的应用…”的提示页面，该页面会不断更新内容，并在后台恢复沙箱的运行：

if (isPage && target.status === "suspended") {
  const outcome = wake(projectId, target, log); // 每个项目都会单独处理
  const done = await Promise.race([outcome, timeout(4000, "pending")]);
  if (done === "busy") return send(res, busyPage());
  if (done !== "running") return send(res, wakingPage()); // 页面会自动更新
}

在我的测试中，一个处于休眠状态的沙箱在大约3秒后就被唤醒了，应用程序也随之立即加载完成。🎊

共享有限数量的沙箱

大多数沙箱提供商都会限制用户同时可以运行的沙箱数量，尤其是在免费套餐中。因此，我添加了一个简单的并发检查机制，所有这些操作都是在Postgres数据库中通过 advisory lock机制来实现的，这样就能确保两个进程永远不会同时做出相同的决策：

async function decide(db: Db, projectId: string) {
  return db.transaction(async (tx) => {
    await tx.execute(sql`select pg_advisory_xact_lock(${LOCK_KEY})`);
    
    const live = await runningSandboxesOldestFirst(tx);
    if (live.some((s) => s.projectId === projectId)) return { kind: "ok" };
    if (live.length < concurrencyLimit()) return { kind: "ok" };

    // 如果所有沙箱都已被占用，就暂停使用最久未使用的沙箱来释放一个空位。
    const victim = live.find((s) => !busyProjects.has(s.projectId));
    if (victim) return { kind: "evict", sandboxId: victim.sandboxId };

    return { kind: "wait", position }; // 如果所有沙箱都占用了，就等待空位释放...
  });
}

为了验证这一机制，我将并发限制设置为1，然后向其中一个项目发送请求，而另一个项目的沙箱则处于闲置状态。处于闲置状态的沙箱会被唤醒并占用一个空位，随后我又向第一个项目发送请求，此时系统会显示“正在等待空闲沙箱，当前排队顺序为第1位”，直到有沙箱空出来为止。如果你使用的是更高配的套餐，只需在.env文件中调整并发限制数值即可，其他设置都不会发生变化。

发布应用程序

在开发过程中使用预览版本固然不错，但你肯定不希望发布的正式应用程序依赖于一个每10分钟就会进入休眠状态的沙箱系统。🫩

因此，在发布应用程序时，系统会将其构建结果转换成普通的静态文件：

export async function publish(project: Project) {
  const ps = await projectSandbox.project.id); // 如有需要，会唤醒该沙箱
  const build = await ps.exec(
    "rm -rf dist && npx vite build --outDir dist --emptyOutDir 2>&1",
    { timeoutSecs: 180 },
  );
  if (build.exitCode !== 0)
    throw new HttpError(422, `构建失败:\n${build.stdout.slice(-1500)}`);

  const files = await listFiles(ps, "dist");
  const prefix = `published/${slug}/${versionId}/`;

  for (const f of files) {
    const bytes = await ps.readBytes(`dist/${f}`);
    await storage.put(prefix + f, bytes, contentTypeFor(f), cacheControlFor(f));
  }

  await savePublishedSite({ projectId: project.id, slug, s3Prefix: prefix });
  return { url: publishedUrlslug) };
}

之后，网关会通过S3服务器提供这些文件，访问地址为http://.app.localhost:4000。Vite工具会对某些文件进行哈希处理，因此这些文件的路径会变为类似assets/index-CScgwd68.js的形式，这样的文件会被永久缓存；而index.html文件则会定期重新验证，这样更新内容就能立即显示出来。对于那些没有文件扩展名的路径，系统会自动回退到index.html，因此客户端路由功能也能正常工作。

被发布的网站通常会特意使用独立的子域名。如果这些网站使用主应用程序的域名，那么被发布的应用程序所使用的JavaScript代码就可以利用当前访问该页面的用户所拥有的cookie来调用你的API，而这是你绝对不希望发生的。😺

在我的测试中，发布一个应用程序大约需要6秒钟的时间，而当沙盒环境处于关闭状态时，该网站在4毫秒内就能加载完成，因为这些代码根本不会接触到沙盒环境。

应用构建工具的实际使用效果

下面是一个关于这个应用构建工具实际使用效果的快速演示：

出于好奇，我还进行了一项小规模的测试。我向两个不同的模型发送了相同的三个请求内容（一个习惯追踪工具、一个看板系统以及一个带有图表的费用管理界面），这两个模型都运行在全新的沙盒环境中：

这六个应用程序在第一次测试时就都成功完成了构建和渲染过程，而且根本不需要进行任何修改，这一点真的让我感到有些惊讶。使用Claude模型来构建这些应用程序，每個应用程序的开发成本大约在0.15美元到0.20美元之间。

结论

那么，你们对这个项目有什么看法呢？自从人工智能技术开始取代传统的编码工作以来，这确实是我参与过的最有趣的项目之一了。🤦‍♂️

当你使用像Lovable这样的工具时，很容易认为整个开发过程主要取决于提示语和模型本身。但一旦你自己亲自尝试构建一个应用程序，你就会意识到，实际上大部分工作都集中在与模型相关的一些细节上，比如代码应该在什么地方运行、启动速度如何、如何向用户展示最终结果，以及如何防止它做出一些不应该做的事情。

如果让我让你们从这次体验中带走一个关键点的话，那就是沙盒环境的重要性。对于人工智能生成的代码，我们应该将其视为不可信任的代码；应该为它们创建独立的、没有隐藏设置且几乎无法访问外部网络的运行环境。通过使用内存快照功能以及暂停/恢复机制，我们可以确保这些代码的运行速度足够快，同时开发成本也相对较低。

这个系统还有很大的扩展空间。例如，我们可以在模板中添加一个简单的后端服务（比如使用Hono和SQLite），这样用户就可以构建完整的栈式应用程序；也可以让用户点击预览界面中的某个元素来直接编辑该组件，或者针对同一个提示语生成多种不同的设计版本进行对比查看。不过目前我实在是太累了，暂时没有精力去实现这些功能了，就留给你们来完成了吧。✌️

基础框架已经搭建好了，后续的工作只需要在此基础上进一步扩展即可。

完整的源代码可以在这里找到：shricodev/lovable-build-tensorlake-aws

这就是这篇文章的全部内容了。非常感谢大家的阅读！下次再见吧。🫡