create-upstash-software-factory

创建 Upstash 软件工厂

你正在帮助他人构建一个小型系统，它只有一项工作：有人在 GitHub issue 上添加 ready 标签，编码 Agent 就会在 Upstash Box 中实现该需求，并提交一个拉取请求，供对方审核和合并。本技能包含可运行的实现（位于 assets/template/）以及构建过程中的经验教训，让你可以借鉴经过验证的代码，而不是从头摸索。

构建内容

• 一个工厂仓库（新建，通常为私有），用于存放配置、协调代码、工作流和工作器镜像定义。
• 每个应用仓库中都有一个精简的触发工作流。获准人员添加 ready 标签时，它会通过 repository_dispatch 将仓库名称和 issue 编号发送到工厂仓库。
• 工厂仓库中的 Factory 工作流。它会认领一个空闲工作器，在该工作器的 Box 中运行 Agent，运行仓库的检查，推送分支并创建拉取请求。issue 上的标签会显示状态：ready、factory:running、factory:review、factory:needs-attention。
• 一组工作器。一个工作器就是一个命名的 Upstash Box。空闲的 Box 会暂停。工作器的 Agent 类型决定了该 Box 中使用的登录方式、命令、模型和工作量设置。

用户之后可能想要更改的内容，几乎都位于 factory.config.json 中。references/config.md 列出了所有键。

更改任何代码前，请先阅读 references/architecture.md。其中解释了认领协议和标签状态，以及这样设计的原因。

工作方式

分阶段进行，每个阶段结束后暂停。每个阶段都应交付用户可以看到并运行的成果。先构建所有内容再一起调试，很容易出问题：原始构建中的几个错误，只有在每个阶段单独测试时才会显现。

适用于每个阶段的规则：

• 所有登录操作和密钥创建都由用户完成。 你不需要查看任何密钥的值。请让他们自行将值填入 .env。如果他们还是在聊天中粘贴了密钥，就将它保存到 .env，不要复述，并建议他们在项目完成后轮换密钥。
• 对本文件夹以外的任何更改，先预览再执行。 创建或更改云资源的脚本（smoke-test、provision-workers、build-snapshot、apply-box-settings、install-trigger、set-secrets、create-demo-issues、delete-workers）会打印预览，并且需要 --yes 才会执行。请先展示预览。check-setup、status、list-boxes 和 plan 只会读取信息。box-exec 和 release-worker 会立即执行操作，且只针对一个 Box。
• 永久删除由用户负责。 删除 Box、issue 或包含其数据的快照无法撤销。请提供命令，让用户自行运行。清理你几分钟前创建且不包含任何内容的 Box 或快照则没有问题。
• 对应用仓库的更改必须通过拉取请求进行，以便所有者审核最终合入的内容。
• 说明你验证了什么，以及没有验证什么。 “已推送但尚未运行”和“已测试”是不同的说法。
• 保留简明记录。 每个阶段结束后，在工厂仓库的 docs/ 下添加一份简短文件，记录构建内容、准确命令以及包含实际结果（包括失败）的测试日志。人们会用这些记录来跟进、录制视频和之后调试。

用户的机器需要具备什么

Node 20.6 或更高版本、git 和 GitHub CLI gh；并且已登录的账号能够创建工厂仓库、在工厂仓库和应用仓库中设置机密和变量（这需要每个仓库的管理员权限），以及推送工作流文件（需要 workflow 权限范围）。项目完成脚手架搭建后，scripts/check-setup.mjs 会检查其中大部分要求。

阶段 0：确保你掌握的是最新文档

Upstash Box SDK、Claude Code 和 Codex 都经常更新。模板编写时是正确的，但在依赖相关内容之前，请先对照最新文档进行核实。

如果用户已经表示不想安装 Context7 或任何额外内容，请直接跳到第 3 步。

1. 查找 Context7：查看当前会话中是否有 Context7 MCP 服务，或者检查是否已安装 ctx7 命令。任意一种都可以。
2. 如果没有，请询问用户是否允许使用。最轻量的方式是运行 npx ctx7@latest library "Upstash Box" "create a box and run shell commands"，该命令会即时下载 CLI，轻度使用无需登录。如需正式安装，请遵循 Context7 自己的最新说明（https://context7.com 和 https://github.com/upstash/context7），不要依赖记忆中的命令，并让用户完成任何登录操作。运行 npx ctx7@latest login 或设置 CONTEXT7_API_KEY 可以提高配额。使用 Context7 时，Box 文档的库路径为 /websites/upstash_box。
3. 如果不使用 Context7，请直接阅读以下官方页面：
   • Box 快速入门：https://upstash.com/docs/box/overall/quickstart
   • 运行 shell 命令：https://upstash.com/docs/box/overall/shell
   • 快照：https://upstash.com/docs/box/overall/snapshots
   • 生命周期、暂停和恢复：https://upstash.com/docs/box/overall/how-it-works
   • Claude Code：https://code.claude.com/docs
   • Codex：https://developers.openai.com/codex 和 https://github.com/openai/codex

查阅 Box 的创建、shell 命令、快照、暂停和恢复；之后再查阅用户选择的各个 Agent CLI 的无头模式、登录和模型设置。references/upstash-box.md 列出了已核实的内容以及模板使用的 SDK 调用，方便你知道要对照哪些内容。

阶段 1：访谈

开始编写任何内容之前，先询问以下问题。大多数问题都有合理的默认选项，因此请提供默认选项后继续。先自行查看仓库（gh repo view、README、package.json 或其同类文件、.gitignore、现有工作流），并提出建议答案，不要直接让用户从零回答。

1. 应用仓库。 哪些仓库？对于每个仓库：
   • 默认分支，以及工厂拉取请求应以哪个分支为目标（baseBranch）。两者可以不同。触发工作流必须位于默认分支上，install-trigger.mjs 会处理这一点。
   • 设置命令（安装依赖）和必须在拉取请求创建前通过的检查命令（测试、构建、lint）。允许仓库没有检查，但要明确说明，此时唯一的检查就是人工审核。
   • 语言和工具链及其版本。标准 Box 自带 Node、npm、pnpm、yarn、bun、git 和 Python 3.11，但没有 pip 或 venv（references/upstash-box.md）。任何其他工具，包括可用的 Python，都意味着需要工作器镜像，而且必须在首次实际运行前（阶段 6）准备好该镜像。
   • 测试所需的条件：数据库等服务、环境变量，以及大致所需时间。设置和检查各自使用 factory.commandTimeoutMinutes（默认值为 20）。
   • 测试所需的密钥，例如测试数据库 URL。它们放在仓库的 secrets 中，可供设置、检查和 Agent 使用，但绝不会进入镜像。
   • 设置过程或 Agent 自带工具在仓库文件夹中留下、且仓库 .gitignore 未涵盖的文件：虚拟环境、缓存、浏览器工具的截图文件夹。将它们列在仓库的 exclude 下，否则它们会进入拉取请求。
2. Agent。 Claude Code、Codex、两者兼用，还是其他？每种 Agent 使用订阅登录还是 API 密钥？参见 references/agents.md。只用一种 Agent 完全可以构成一个工厂。此处不必确定模型；下面会有专门的时机来讨论这个问题。
3. 工作器。 每种 Agent 类型需要多少个工作器？先检查 Upstash 方案的 Box 上限（Upstash 控制台会显示方案，scripts/list-boxes.mjs 会显示当前已有的 Box）。免费方案当时总共限额为 10 个 Box，暂停的 Box 也计入。为冒烟测试留一个名额。将方案限额填入 factory.boxLimit，check-setup.mjs 会计算，包括同一账号下其他项目的 Box。如果有多种 Agent 类型，还要询问未标记问题应优先分配给哪种类型。如果没有答案，任务会平均分配；当一种类型是固定费率订阅、另一种按 token 计费时，这就不合适。答案会成为 Agent 类型上的 priority。
4. 谁可以启动工厂。 为 allowedActors 填入真实的 GitHub 用户名。运行会消耗用户的 Agent 配额或 API 预算，因此这个列表很重要。还要询问谁拥有工厂仓库的写入权限，因为他们可以查看其 Actions 日志。
5. 工厂仓库及所有权。 名称、私有或公开，以及所有者。所有者必须与拥有应用仓库的账号或组织相同，因为一个细粒度 GitHub token 只能覆盖一个所有者。确认仓库名称尚未被占用，也没有旧尝试遗留下来的内容（旧工厂仓库、应用仓库中的旧触发工作流、Upstash 账号上的旧 Box）。原始构建中的遗留内容曾造成严重混乱。
6. 工作署谁的名。 拉取请求和评论会显示为 GitHub token 所有者发布，提交则会使用 gitAuthor。询问应使用哪位真实人士的身份。他们必须是任何预览托管团队的成员（参见提交作者陷阱），并且如果分支要求审核，他们不能批准自己的拉取请求。使用专用机器用户可以避免这两个问题。使用该用户的 noreply 地址；较新的账号地址格式为 [email protected]。
7. 组织规则（如果仓库属于组织）：组织是否允许细粒度 token？是否需要审批？是否使用 SSO？是否有会拒绝推送 factory/issue-N 的分支规则（要求提交签名、分支名称模式）？是否有 Actions 允许列表？Actions 分钟数是否计费？一次运行会在整个运行期间占用一个 runner。
8. 工作器镜像。 现在就确定镜像中包含什么，不要等到有 Box 后再决定，因为镜像会先构建，工作器则基于它创建。之后才发现需要添加内容，就意味着必须删除并重新创建工作器。除了工具链，还包括：技能、MCP 服务、浏览器工具、其他 Agent CLI？每个 Box 默认都启用浏览器访问（factory.browser）。要告知用户这一点，并说明只能在创建 Box 时选择。它会为 Box 提供由 Upstash 运行并在其控制台中显示的 Chromium。Agent 仍需要镜像中的工具来驱动它，例如 agent-browser。经常编辑的项目说明文件，例如 CLAUDE.md 或 AGENTS.md，通常不应放入镜像中。它们会成为 jobFiles（references/config.md）。使用这类文件前，应与用户一起阅读：文件会存放在 GitHub 仓库中，并在 Linux Box 上运行，因此应删除私人笔记、本地路径，以及对仅在用户机器上存在的工具的引用；与工厂规则（提交、推送、创建拉取请求）冲突的规则，应以工厂的提示词为准。参见 references/worker-image.md。
9. 托管平台的特殊情况。 应用仓库是否会部署预览环境（Vercel、Netlify），或运行审核机器人？这些工具会响应工厂提交的内容。

创建任何 Box 或快照之前：询问模型和推理力度

工作者使用的模型和推理力度存储在 Box 中，具体来说，是它的 CLI 读取的设置文件里，因此也会成为从该 Box 创建的任何快照的一部分。它们不是工厂添加的命令行标志。正因如此，一个工厂可以容纳不同类型的工作者：一组廉价、快速的工作者，以及一组用于处理高难度工程任务的工作者。

模板为每种 Agent 类型都设置了 "boxSettings": "ask"。配置会以这种方式加载，因此前期步骤可以正常进行，但任何创建 Box 或快照的脚本都会拒绝这种设置。因此，第一次准备为某种 Agent 类型创建 Box 或构建快照时（通常是第 4 阶段的冒烟测试；每次添加新类型的工作者时也一样），请停下来询问用户：

“对于 Claude Code 工作者：使用 Claude Code 自带的默认模型和推理力度，还是指定模型和推理力度？”（对其他每种执行框架也同样询问）

• 如果他们想使用默认值，就将该 Agent 类型的 "boxSettings" 设为 []。空列表表示他们选择了默认值。
• 如果他们指定了模型或推理力度，请查阅该执行框架支持的选项（references/agents.md 中有经过验证的 Claude Code 和 Codex 配置方法，当前文档中则有模型名称），并填写 boxSettings。
• 询问他们是否想在同一执行框架上使用不止一种类型的工作者，例如，用较小的模型处理快速杂务，用较大的模型并采用较高推理力度处理难题。每种类型都是独立的 Agent 类型，具有相同的 auth 和 command，但 boxSettings 不同，并拥有自己的工作者、自己的 agent:<name> 标签；如果使用镜像，也会有自己的快照。Agent 名称最多 14 个小写字符。
• 一次性告知他们其中的取舍：较大的模型和较高的推理力度会更快耗尽订阅限额或 API 预算，而并行工作者会使消耗成倍增加。

smoke-test.mjs、provision-workers.mjs 和 build-snapshot.mjs 的预览会打印 Box 将使用的模型和推理力度。在添加 --yes 之前，先向用户展示这一行。

之后如需更改：编辑 boxSettings，对现有 Box 运行 scripts/apply-box-settings.mjs --yes，如果该 Agent 类型有快照，也要重新构建。

同时确定浏览器访问权限

工厂创建的每个 Box 都会获得浏览器访问权限，因为 factory.browser 默认为 true。除非用户明确表示不要，否则请保持开启。与模型不同，已创建的 Box 无法更改这项设置：Box.create({ browser: true }) 是唯一的开关。因此有两点需要注意，而在最初的构建中，若要更改这项设置，两者都会让你必须删除并重新创建所有工作者：

• Box.fromSnapshot 会忽略 browser: true。SDK 不会发送该参数。
• 从快照创建的 Box 是否具有浏览器访问权限，完全取决于创建该快照时所用的 Box 是否具有此权限。因此，镜像必须在启用了浏览器访问权限的 Box 中构建。build-snapshot.mjs 会对此进行检查，否则会拒绝执行。

同样的预览也会打印浏览器相关信息。provision-workers.mjs 和 smoke-test.mjs 会测试它们创建的每个 Box，并在遇到第一个没有浏览器访问权限的 Box 时停止。详情请参阅 references/upstash-box.md。

第 2 阶段：搭建工厂仓库

1. 将 assets/template/ 中的所有内容复制到项目文件夹中，包括点文件和 .github/。
2. 根据访谈填写 factory.config.json。加载器会拒绝占位符，因此必须替换所有 OWNER。选择一个 Upstash 账户中其他内容尚未使用的 boxNamePrefix 和 boxLabel（第 3 阶段会检查这一点）。移除用户不会使用的 Agent 类型。将 boxSettings 保持为 "ask"。
3. 运行 npm install，并提交 package-lock.json。工作流会运行 npm ci，没有该文件就会失败。
4. 运行 git init，确认 .env 已被忽略，然后提交；接着运行 gh repo create OWNER/NAME --private --source . --push（或使用 --public）。

模板使用原生 Node ES 模块，且只有一个依赖：@upstash/box。除非用户另有要求，否则请保持这种结构。该模板旨在由其所有者阅读和修改。

阶段 3：账号和密钥

请用户：

• 在 Upstash 控制台中创建一个 Box API key，并将其放入 .env，变量名为 UPSTASH_BOX_API_KEY。
• 创建一个细粒度 GitHub token。资源所有者：拥有这些仓库的账号或组织。仓库访问权限：工厂仓库和每个应用仓库。权限：Contents、Pull requests 和 Issues，全部设为读写。将其放入 .env，变量名为 FACTORY_GITHUB_TOKEN。必须包含工厂仓库，因为每个应用仓库中的触发器都会使用此 token 向该仓库发送 dispatch 事件。在组织中，token 可能需要所有者批准后才能使用。
• 按照 references/agents.md 中的说明，让每个 Agent 登录，并将生成的密钥放入 .env（如果配置中有 localFile，也可以将其留在本地文件中）。对于 API key，建议使用专为此项目创建并设有支出限额的 key。

然后运行 node --env-file=.env scripts/check-setup.mjs。它会检查工具和配置、哪些密钥已设置（绝不会显示密钥值）、token 是否能访问所有仓库、Box key 是否有效，以及 Upstash 账号中已有的内容。继续之前，请修复报告的问题。

阶段 4：为每种 Agent 类型进行一次 Box 烟雾测试

先询问模型和推理力度，因为这是第一个 Box。然后，对每种 Agent 类型：

node --env-file=.env scripts/smoke-test.mjs claude

显示预览，然后使用 --yes 运行。它会创建一个 Box，打印 Box 中包含哪些工具链，确认 Box 可以访问浏览器，写入该 Agent 类型的默认设置，完全按照工厂将采用的方式让 Agent 登录，让它回复 BOX OK，然后删除 Box。这能验证最可能出错的环节：Box key、Agent CLI 是否已安装、登录方式以及摘要文件。

烟雾测试创建 Box 的方式与工作进程创建 Box 的方式相同：如果该 Agent 类型有对应镜像，就从该镜像创建。因此，如果某个 Agent 的 CLI 不在标准 Box 中，顺序应为：先构建镜像（阶段 6），再运行烟雾测试；此时测试会从该镜像启动。要提前找到正确的安装命令，请使用 --keep 运行烟雾测试，然后通过 scripts/box-exec.mjs <box name> "<command>" 手动尝试命令。

如果创建 Box 时出现限额错误，说明账号已满。已暂停的 Box 也计入数量。由用户决定删除哪些 Box。

阶段 5：通过试运行验证触发器

1. 先启用试运行模式，这样在接线配置期间不会启动实际任务：gh variable set FACTORY_DRY_RUN --body true --repo OWNER/FACTORY-REPO。
2. 先运行 node --env-file=.env scripts/set-secrets.mjs（预览），用户同意后再运行 --yes。这会更改仓库设置，因此请先征求同意。
3. 先运行 node scripts/install-trigger.mjs（预览），然后再运行 --yes。它会创建 issue 标签，并为每种在用的 Agent 类型创建一个 agent:<name> 标签；还会向每个应用仓库的默认分支发起一个 PR，以添加触发器工作流。由用户合并这些 PR。
4. 用户在一个应用仓库中创建测试 issue，并添加 ready 标签。
5. 在工厂仓库的 Actions 选项卡中查看运行记录。“Show the plan”步骤应打印该 issue、所有工作进程以及将会被选中的工作进程。每个标签应恰好对应一次运行。

在工作进程可以处理实际任务之前，保持试运行模式开启。

如果没有运行记录，请按以下顺序检查：触发器 PR 是否已合并到默认分支；添加标签的人是否在 allowedActors 中；应用仓库是否有 FACTORY_GITHUB_TOKEN 密钥；该 token 是否能写入工厂仓库；两个仓库是否都允许运行 Actions。

阶段 6：构建工作器映像（当工作器需要时）

如果任何仓库的设置或检查需要标准 Box 所不具备的内容（冒烟测试会显示 Box 中已有的内容）、缺少 Agent CLI，或用户需要技能、MCP 服务或浏览器，请现在执行此步骤。否则跳过。之后也可以再添加。

1. 编辑 worker/setup.sh。先阅读 references/worker-image.md。该文档介绍了映像中应包含的内容，以及决定脚本编写方式的 Box 特性。
2. 只创建一个工作器的 Box：node --env-file=.env scripts/provision-workers.mjs <worker id> --yes。其他工作器要等映像就绪后再创建。此 Box 会通过 factory.browser 获得浏览器访问权限，并由映像将该权限传递给每个工作器。
3. 构建：node --env-file=.env scripts/build-snapshot.mjs <worker id>，展示预览，然后使用 --yes。它会检查 Box 是否能访问浏览器，在该 Box 中运行设置脚本，为 Agent 类型写入 boxSettings，移除机密信息和旧工作区，扫描磁盘以查找疑似机密的信息，创建快照并将其 ID 保存为 agents.<name>.snapshotId。提交配置。
4. 对每种需要映像的 Agent 类型重复步骤 2 和 3。使用 --shared 时，脚本会为所有 Agent 类型构建一个仅包含工具的映像，并将其保存为 factory.snapshotId。
5. 使用 scripts/box-exec.mjs 在 Box 中验证：检查工具版本，并使用每个工具执行一次实际操作。

此后创建的 Box 都会从该映像启动。你已经构建映像的那个 Box 已具备所有内容，因此无需删除任何内容。只有之前已存在的 Box 需要重新创建（由用户运行 delete-workers.mjs，然后运行 provision-workers.mjs）。

阶段 7：首次实际运行

关闭试运行模式：gh variable delete FACTORY_DRY_RUN --repo OWNER/FACTORY-REPO。让用户在测试 issue 上重新添加 ready（先移除，再重新添加）。观察运行过程，然后检查以下每一项，因为它们在最初构建时都至少失败过一次：

• issue 的状态依次从 ready 变为 factory:running，再变为 factory:review，并附有一条提及工作器名称的评论。
• PR 已创建，写有 Closes #N，且其描述中包含 Agent 自己撰写的摘要，而不是“（Agent 未提供摘要。）”。
• 日志显示仓库的设置和检查均已运行并通过。
• PR 上的预览部署和其他机器人检查均为绿色。部署被阻止通常意味着提交作者不正确。
• 工作器已释放：node --env-file=.env scripts/status.mjs 显示工作器空闲，且其 Box 已暂停。
• 没有遗留凭据：node --env-file=.env scripts/box-exec.mjs <worker> "ls -d ~/.git-credentials /workspace/home/.factory" --pause 不应找到任何内容。

为每种 Agent 类型各用一个 issue 重复上述流程。先在 issue 上添加 agent:<name>，再添加 ready，即可指定类型。

阶段 8：规模测试

1. 运行 node --env-file=.env scripts/provision-workers.mjs 并向用户展示预览。预览会列出每个 Box 及其映像、模型和推理力度。然后使用 --yes 运行。该命令会为每个工作器创建一个已暂停的 Box，避免多个运行同时创建同一个 Box。
2. 根据 demo-issues.example.json 编写 scripts/demo-issues.json，内容为适合用户仓库的小型、互不依赖的功能。issue 数量应多于工作器数量，以便部分 issue 需要等待。
3. node scripts/create-demo-issues.mjs --yes 会创建这些 issue，但不添加标签，用户可以自行安排添加标签。--ready 会同时启动所有 issue，并要求 gh 已登录为 allowedActors 中的用户。
4. 之后检查：每个 issue 都对应一次运行；每个 issue 最终状态均为 factory:review 或 factory:needs-attention；所有工作器都重新空闲；没有速率限制导致的失败。使用 API 密钥时，让用户查看提供商的用量页面。

事先提醒用户：同一个小型仓库中的并行 PR 可能会修改相同文件。每个 PR 单独处理时都能正常工作，但之后合并时可能会发生冲突。这是并行工作的特性，不是工厂的 bug。

阶段 9：交接

• 编写工厂仓库的 README：说明它的用途、如何添加仓库、工作器或 Agent 类型、如何解读标签，以及 references/architecture.md 中的图示。
• 列出设置期间暴露过的密钥（粘贴到聊天中的、在屏幕上显示的），并建议轮换它们。注明 GitHub 令牌和任何 Agent 令牌的过期时间。
• 明确说明一次：Agent 运行时会关闭自身的权限提示，在整个任务期间保持登录状态，并读取问题文本。若有浏览器或网页访问权限，它也会读取网页。allowedActors 控制谁可以添加标签，而不是谁编写了问题。因此，添加标签前请先阅读问题，尤其是在公开仓库中。
• 展示日常使用的命令：scripts/status.mjs、用于处理取消运行后仍卡在忙碌状态的工作器的 scripts/release-worker.mjs，以及用于更改模型的 scripts/apply-box-settings.mjs。

更改现有工厂

• **添加仓库：**将其添加到 repos，扩展 GitHub 令牌的访问权限，运行 install-trigger.mjs --yes 和 set-secrets.mjs --yes。
• **添加工作器：**在 workers 中添加条目，检查 Box 限额；如果是新类型的工作器，询问模型和工作量设置，然后运行 provision-workers.mjs --yes。
• **添加 Agent 类型：**阅读 references/agents.md，将其添加到 agents，并设置 "boxSettings": "ask"；询问模型设置，运行冒烟测试，然后运行 install-trigger.mjs --yes 添加其标签，并运行 set-secrets.mjs --yes 添加其密钥。
• **更改模型或工作量设置：**编辑 Agent 类型的 boxSettings，运行 apply-box-settings.mjs --yes；如果该 Agent 类型有快照，还要重新构建其快照。
• **为现有工作器启用浏览器访问：**对于已存在的 Box，无法开启此功能；在没有此功能的 Box 中构建的镜像也不会继承此功能。设置 "browser": true，从配置中移除 snapshotId 值，让用户删除工作器（delete-workers.mjs --yes），创建一个普通 Box，在其中重新构建镜像，然后创建其余工作器。参见 references/worker-image.md。
• **更改谁可以启动它：**编辑 allowedActors，运行 install-trigger.mjs --yes，然后合并 PR。
• **出现故障：**先阅读 references/pitfalls.md。目前遇到的大多数故障及其原因都列在其中。

参考文件

• references/architecture.md：组件、任务流程、标签状态、工作器认领协议、文件索引和 README 图示。
• references/config.md：factory.config.json 中的所有键。
• references/agents.md：Claude Code 和 Codex 使用订阅或 API 密钥时的登录方式、命令行、模型和工作量设置，以及如何添加其他 Agent。
• references/upstash-box.md：模板使用的 SDK 调用、标准 Box 的内容，以及文档所在位置。
• references/worker-image.md：构建和使用快照。
• references/pitfalls.md：原始构建过程中遇到的所有错误和意外情况，以及原因和修复方法。调试前请先阅读。