这三个阶段回答的不是同一个问题。把其中一个当成另一个的证据，是未经检查就发布页面的常见原因。
| 阶段 | 命令或动作 | 能证明什么 | 不能证明什么 |
|---|---|---|---|
| 本地验收 | arc blocklet run . 加浏览器 | 当前机器能服务并检查指定本地 blocklet | 它已正式发布，或 DID Space 用户可访问 |
| build | arc blocklet build . | ARC 能从当前目录组装可分发 artifact | 读者已看到预期页面，或生产部署成功 |
| 正式发布 | 遵循项目批准的 release 路径 | 一次单独授权的生产交付已经发生 | 可以跳过本地直跑测试 |
先本地运行
arc blocklet run <path> 会验证目标目录、复用或启动本地 daemon、为本次进程注册 blocklet 的父目录，并打印一个 subdomain URL 和一个通用 query URL。浏览器应使用命令实际打印的 URL；host 和 port 取决于机器。要让源在重启后还在具名实例上，用 arc service start --instance <name> --blocklet <path>。
这才是正常的 Web Device 验收路径，不是 DID Space 部署。分别在宽窄视口打开页面，跟随至少一个内部链接；编辑后若结果看起来陈旧，应 reload 再查。
有意识地 build
arc blocklet build [dir] 会在 <dir>/dist 下创建打包用 build material，包括 AFS manifest 与 blocklet distribution metadata。build 命令会管理该输出目录，因此不要把手工维护的 source 放在那里；除非仓库 release 流程明确要求，否则也不应提交它。
blocklet 暴露 Web route 时通常启用静态预渲染。但页面 cache/output 的行为与打包 dist 是两件事；package build 成功不能代替实际打开渲染后的页面。
把发布保留为单独、经授权的路径
生产发布有它自己的 identity、authorization 与 release 问题。本地验收与 artifact 核验之后也许适合做，但不能只为了发现一个本地 layout 是否工作就去部署。日常文档和站点工作，应先直接本地运行。
本地 watcher 可以为已注册父目录失效 cache，通常忽略生成/build 目录。watcher 无法启动时可以降级而失去自动刷新。因此预览陈旧时，应显式 reload 并核查 source/path，而不是自动部署。