Prisma Compute
指导 agents 完成 Prisma Compute 应用创建、部署、运维以及特定框架的部署就绪准备。
Prisma Compute CLI 功能范围
使用 Prisma Platform CLI 执行 Compute 应用工作流:
bunx @prisma/cli@latest app deploy --help
bunx @prisma/cli@latest app --help
bunx @prisma/cli@latest build logs --help
bunx create-prisma@latest --help
使用 @prisma/cli@latest 部署 Compute 应用。使用 create-prisma@latest 搭建新项目脚手架。
发送反馈并报告 CLI 问题
CLI 内置反馈渠道。每当命令崩溃(UNEXPECTED_ERROR)、故障经排查仍未解决,或用户要求向 Prisma 团队发送反馈时,请使用该渠道:
bunx @prisma/cli@latest feedback "app deploy crashed: <first error line>"
bunx @prisma/cli@latest feedback "love the deploy flow" --email you@example.com
崩溃输出本身会指向这里:--json 崩溃封装会将准确的预填充命令作为 nextActions 中的 recover 条目(请原样运行),而人类可读的崩溃输出以 Tell us what happened: 提示结尾。除非传入 --email,否则反馈是匿名的,并且仅附带 CLI 版本、node 版本和 OS 平台/架构。禁止在消息中包含密钥、连接 URL 或用户数据。
事实来源优先顺序
在决定要编辑或运行哪些内容时,请按以下顺序采用依据:
- 项目生成的脚本和配置,尤其是
prisma.compute.ts、compute:deploy、框架配置和package.json。 - 来自
create-prisma和@prisma/cli的 CLI 帮助输出。 - 本地已安装的软件包代码、生成的制品和类型定义。
- 官方文档。
适用场景
此 skill 适用于:
- 创建可部署到 Prisma Compute 的新应用
- 将现有 TypeScript 应用部署到 Prisma Compute
- 创建或更新带类型的
prisma.compute.ts部署配置 - 判断框架是否已可用于 Compute 部署
- 调试
create-prisma --deploy、compute:deploy或app deploy - 管理 Compute 应用日志、部署、环境变量和域名,以及列出平台分支(
branch list;不存在创建/移除分支的命令) - 检查 GitHub/控制台构建日志和 GitHub 推送即部署状态
- 通过浏览器身份验证、存储的多个工作区或 Prisma 服务令牌运行非交互式部署
- 为
@prisma/cli切换、选择、列出或注销本地 Prisma Platform 工作区 - 使用
@prisma/cli feedback发送有关无法解决的 Compute CLI 故障的反馈 - 使用
@prisma/compute-sdk进行程序化部署,或进行 Management API 集成
决策树
- 部署或重新部署现有项目:
阅读 [references/app-deploy-cli.md](references/app-deploy-cli.md)。
- 带类型的 Compute 配置、单体仓库、部署目标、应用根目录或构建/环境默认值:
阅读 [references/compute-config.md](references/compute-config.md)。
- 特定框架的构建/运行时工作:
阅读 [references/frameworks.md](references/frameworks.md)。
- 通过脚手架创建新项目:
阅读 [references/create-prisma.md](references/create-prisma.md)。
- 程序化部署、SDKs、APIs 或底层应用/部署概念:
阅读 [references/sdk-api.md](references/sdk-api.md)。
- 构建、身份验证、环境、部署或运行时故障:
阅读 [references/troubleshooting.md](references/troubleshooting.md)。
按优先级排列的规则
| 优先级 | 类别 | 影响 | 前缀 | |----------|----------|--------|--------| | 1 | 命令验证 | 关键 | verify- | | 2 | 身份验证和工作区选择 | 关键 | auth- | | 3 | 框架就绪情况 | 关键 | framework- | | 4 | 运行时主机和端口绑定 | 关键 | runtime- | | 5 | 带类型的 Compute 配置 | HIGH | config- | | 6 | 分支、环境和数据库连接配置 | HIGH | env- | | 7 | 部署操作 | HIGH | deploy- | | 8 | SDK 和 API 自动化 | MEDIUM | sdk- |
快速规则
1. 命令验证
verify-help-first- 工作期间,使用 CLI 帮助输出确认命令语法。verify-prisma-vs-platform-cli- 不要假定prisma app deploy存在于 ORM CLI 中;请确认任务是否应使用@prisma/cli。verify-generated-scripts- 当项目已有生成的compute:deploy脚本时,优先使用该脚本。verify-public-url- 完成实际部署后,应获取公共部署 URL,而不是依赖本地检查或仅就绪性检查的结果。verify-config-support- 将prisma.compute.ts视为类型化 Compute 配置;编辑或部署前,先检查项目配置和生成的脚本。verify-auth-workspace-support- 使用@prisma/cli auth workspace命令执行本地工作区的列出、切换和退出登录流程。
2. 身份验证和工作区选择
auth-source-precedence- 非空的PRISMA_SERVICE_TOKEN是命令的当前身份验证来源,执行命令时会忽略本地 OAuth 工作区。如果已设置该变量但值为空,CLI 应执行失败,而不是回退到已存储的 OAuth。auth-multi-workspace-auth login可在同一台机器上存储多个工作区的 OAuth 会话。活动工作区指针决定普通命令使用哪个已存储的 OAuth 授权。auth-list-before-switch- 使用auth workspace list --json检查本地会话。由于名称可能存在歧义,Agents 应优先使用 JSON 中的工作区 ID,而不是名称。auth-switch-explicitly- 使用auth workspace use <id-or-name>进行非交互式切换。仅当使用交互式选择器,或本地恰好存在一个 OAuth 工作区时,才可不带参数使用auth workspace use。auth-no-fallthrough- 如果活动 OAuth 工作区已退出登录或刷新失败,CLI 不应静默转而使用另一个缓存的工作区。运行auth workspace use <id>选择下一个工作区。auth-single-workspace-logout- 使用auth workspace logout <id-or-name>或auth logout --workspace <id-or-name>移除一个本地 OAuth 工作区会话。直接运行auth logout会清除所有本地 OAuth 工作区会话。auth-service-token-switching- 设置PRISMA_SERVICE_TOKEN后,由于服务令牌是当前身份验证来源,auth workspace use将不可用;如需切换本地 OAuth 工作区,请取消设置该环境变量。工作区退出登录仍只会清理本地 OAuth 状态。auth-storage-awareness- 本地 OAuth 凭据存放在平台身份验证文件中,工作区元数据则存放在配套的上下文文件中。项目固定信息存放在.prisma/local.json中;如果存在prisma.compute.ts,CLI 应用/项目状态会存放在其附近的.prisma/cli/state.json中。
3. 框架就绪性
framework-cli-first- 以@prisma/cli app deploy为依据评估部署就绪性,而不是以create-prisma能搭建的内容为依据。framework-supported-cli-deploy- Compute 部署支持nextjs、nuxt、astro、hono、nestjs、tanstack-start、custom和bun。framework-create-prisma-defaults-only-create-prisma可提供生成的默认配置和compute:deploy,但它不是现有应用的通用部署入口。framework-build-output- Compute 需要服务器入口点或框架制品,而不能只有静态输出。
4. 运行时主机和端口绑定
runtime-bind-all-interfaces- 部署后的服务器必须绑定到所有网络接口(0.0.0.0或框架中的等效配置),不得硬编码为localhost或127.0.0.1。runtime-match-http-port- 应用必须监听部署使用的 HTTP 端口:应尽可能读取process.env.PORT,否则传入匹配的--http-port。runtime-readiness-port-only- Compute 就绪性检查会监控正在监听的端口;仅绑定回环地址的监听器可能看似已就绪,但公网 Ingress 无法访问它。runtime-respond-within-60s- Ingress 会给应用 60 秒的时间开始响应,随后返回504 Gateway Time-out并取消请求。处理程序应先返回响应,再通过waitUntil或队列执行耗时较长的工作,严禁在请求内执行此类工作。
5. 类型化 Compute 配置
config-optional-simple-app- 部署普通的单一应用无需prisma.compute.ts;没有需要持久化的配置时,请使用标志。config-init-formalizer- 使用bunx @prisma/cli@latest init生成全新配置:该命令会检测框架,固定名称、框架和 httpPort(对于 Bun/Hono 还包括入口点),并提供项目关联选项。--format json则会写入无依赖的prisma.compute.json。已有任何配置时,init都会拒绝执行;它从不生成代码脚手架,也从不执行部署。config-use-prisma-compute-ts- 通过defineComputeConfig将可复用的部署默认值放入prisma.compute.ts,而不是prisma.config.ts。config-app-vs-apps- 单一部署目标使用app,单仓库或多应用仓库使用apps;必须恰好定义其中一个。config-monorepo-roots- 对于单仓库项目,使用prisma.compute.ts声明应用目标、根目录、框架默认值、入口点、端口和环境变量输入。config-targets- 在多应用配置中,@prisma/cli app deploy web会选择apps.web目标。未指定[app]时,命令可以从当前目录推断目标;否则,部署可以运行所有目标,而构建/运行要求指定一个目标。config-region-new-app-only- 配置中的region仅作为新建应用的默认值;部署到现有应用时会保留该应用当前的区域。config-custom-artifact- 对于预构建或自定义构建的制品,请将framework: "custom"与build.outputDirectory和build.entrypoint配合使用。config-no-project-branch-secrets- 不得在prisma.compute.ts中提交工作区、项目、分支、生产部署意图、服务令牌或机密值;应将这些内容保存在标志、.prisma/local.json、环境变量存储或 CI 密钥中。region、root、framework、entry、httpPort等应用级默认值以及非敏感环境变量文件路径应放在配置中。config-flags-win- 显式指定的部署标志(如--framework、--entry、--http-port、--region和--env)会覆盖相应的配置值。
6. 分支、环境和数据库
env-do-not-leak-secrets- 严禁输出完整的DATABASE_URL、服务令牌或机密值。env-deploy-loads-dotenv- 生成的部署脚本可能通过prisma.compute.ts或--env .env加载环境变量;重新部署前,请检查实际脚本/配置。env-migrations-separate- 重新部署脚本不会执行迁移或填充种子数据。请另行运行相应的 Prisma 数据库脚本。env-cli-token-name-@prisma/cli使用PRISMA_SERVICE_TOKEN进行服务令牌身份验证。env-branch-scope- 分支部署、分支环境变量和分支数据库必须使用同一分支名称;以预览分支为目标时,必须显式传入--branch <git-name>。env-production-vs-preview- 生产环境使用--role production,预览模板环境使用--role preview,分支级覆盖使用--branch <git-name>。env-db-explicit- 通过数据库命令和项目环境变量命令明确配置数据库与环境变量关联;部署示例不应添加数据库设置,并且部署不会执行迁移、填充种子数据,也不会自动为每个应用创建一个数据库。
7. 部署操作
deploy-prod-intent- 仅当用户打算进行生产部署时,才使用--prod --yes。应用的首次生产部署无需--prod即会自动提升;后续生产分支部署受该标志约束。deploy-no-promote- 使用app deploy --no-promote进行先构建后验证:该命令会构建一个可通过其专属 URL 访问的候选版本,且不会改动当前线上部署;之后可使用app promote <deployment-id>将其提升为线上版本。deploy-github-default-branch- 当 Compute 应用已接入 GitHub 推送即部署功能时,合并到默认分支就是生产部署路径;应查看部署记录或 GitHub 检查运行记录,而不是让用户重新部署已合并的 PR 分支,或对默认分支执行预览部署。deploy-build-logs- 使用@prisma/cli build logs <build-id>查看 GitHub/控制台构建输出。使用app logs查看运行时部署日志;二者的 ID 不同。deploy-noninteractive-auth- 非交互式部署需要使用正确的、已存储且处于活动状态的 OAuth 工作区,或受支持的服务令牌环境变量;严禁打印该令牌。deploy-json-for-agents- 对于脚本和 agent 可读输出,使用--json --no-interactive。deploy-create-project- 仅当用户希望部署过程创建并关联新项目时,才使用--create-project <name>;它与--project和PRISMA_PROJECT_ID冲突。deploy-ops-targets- 应用的 show/open/logs/list-deploys/promote/rollback/remove 命令和域名命令也可以接受prisma.compute.ts中的[app]目标。deploy-report-cli-bugs- 出现UNEXPECTED_ERROR或无法解决的故障时,使用反馈命令进行报告;请参阅上文的“发送反馈和报告 CLI 问题”。
8. SDK 和 API
sdk-use-cli-first- 应用工作流优先使用@prisma/cli app deploy;除非用户正在构建更底层的自动化,否则create-prisma仅用于搭建新应用脚手架。sdk-result-handling-@prisma/compute-sdk返回Result值;应检查isOk()/isErr(),而不是依赖异常。sdk-snapshot-detection- 对于未签出到磁盘的仓库快照,使用detectComputeApp;请自行枚举工作区,并针对每个候选应用根目录调用一次该函数。
推荐工作流
- 检查项目:包管理器、模板/框架、
package.json脚本、Prisma 版本、Prisma 客户端位置、prisma.compute.ts和现有的compute:deploy。 - 核验实际所用软件包的 CLI 帮助输出。
- 在变更项目/应用前验证身份验证上下文:
auth whoami --json;如果可能存在多个本地会话,还要使用auth workspace list --json。 - 选择路径:
- 现有应用部署:配置中定义的目标(如有)、生成的
compute:deploy或@prisma/cli app build/run/deploy参数 - 新应用脚手架:先使用
create-prisma,然后使用生成的compute:deploy,或使用@prisma/cli app deploy - 底层自动化:
@prisma/compute-sdk或管理 API
- 检查框架就绪情况以及主机/端口/环境/运行时要求,包括项目和分支作用域。
- 可行时,在部署前执行本地构建或
app build。 - 自动化部署时使用 JSON 输出,然后请求获取公开 URL,并汇总应用 URL、应用 ID、部署 ID、项目 ID、工作区 ID 和后续步骤。
- 对于 GitHub/控制台构建,在猜测构建失败原因前,查看
Prisma Compute Deploy检查运行记录或build logs <build-id>。
避免
- 不得将 Compute 部署指南埋没在通用的
prisma-cliskill 中。 - 不得仅为部署现有应用而在其中运行
create-prisma;应使用生成的compute:deploy脚本或@prisma/cli app deploy。 - 不得告诉用户所有
create-prisma模板都能自动部署。 - 不得使用
DATABASE_URL的占位值进行部署。 - 不得假设
next start是 Compute 的运行时路径;Next.js 部署需要独立输出。