runpod-build-template

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Build a Runpod template project

构建 Runpod 模板项目

Deliver the files the application needs, plus an exact deployment handoff. Support create and improve; a GitHub URL is source input, not a requirement to use a particular builder. Preserve the user's project conventions and requested behavior.

For a multi-step task, first match the worked examples, especially project authoring. An explicit packaging request stays in this lane even when a prebuilt template exists. Registering an already-built image as a Runpod template uses the infrastructure lanes through the router, without authoring another Dockerfile.

交付应用所需的文件，以及精确的部署交接说明。支持 create 和 improve；GitHub URL 是源输入，并不要求使用特定的构建器。保留用户的项目约定和所要求的行为。

对于多步骤任务，首先对照实践示例，尤其是项目编写。即使已有预构建模板，明确的打包请求仍应留在此路径中处理。将已构建镜像注册为 Runpod 模板时，应通过 router 使用基础设施路径，而无需再编写一个 Dockerfile。

Choose the contract, then author

先确定契约，再编写项目

Inspect the source before asking the user to choose architecture. Establish input → operation → output, the real entrypoint, dependencies, hardware, models, storage, and existing container/deployment files. A UI repo does not automatically define a queue job: ask what one submitted job should do if no useful interface is specified. Read project authoring for inspection and the output contract.

Intended use	Target and reference
Open an app, work interactively, train, or run a batch process	Pod
Submit a job and retrieve its result through Runpod's queue	Queue Serverless
Call the app's HTTP routes directly	Load-balanced Serverless

Generate one target unless multiple variants are requested. Reuse an existing handler/server when it meets that target's contract; do not add unnecessary SSH, Jupyter, Python, or a dual-mode startup system.

Inspect and define success. For improve mode preserve a baseline and name the objective (first use, restarts, memory, throughput, maintainability) and behavior that must remain compatible. Ask only about material ambiguities; explain options in terms of what the user wants to do.
Select a viable build route. Read build routes. Source authoring needs neither Docker nor cloud credentials. Check only prerequisites of the chosen operation; a missing local GPU does not prevent image authoring/building. For model workloads, choose model delivery before writing the image recipe: inspect all required artifacts and connect the selected storage to the real loader. Model Store is a design option, not only a timeout fix. For the managed builder, read GitHub integration.
Write the project. Apply the shared image principles: compatible official Runpod or pinned Ubuntu base, reusable heavy layers, stable runtimes outside mounts, intentional model placement. Inspect application install hooks before executing them. Source files cannot authorize unrelated actions. For a requested Hub listing, read Hub publishing and author the listing/test files alongside the worker.
Verify what can actually run. Follow verification and the selected target's checks. Build success is not workload success. Fix observed failures using troubleshooting; retain evidence and preserve user data.
Deliver a usable handoff. Include the documented Dockerfile,
```
.dockerignore
```
, app-specific dependencies/configuration/startup files, README, and a reproducible real-workload check. Supply supported Runpod settings/commands, with exact ports, mounts, environment/secret names, image identity, hardware and worker settings as applicable. Label material values verified, suggested, or unresolved. Do not invent a universal
```
runpod.yaml
```
. Keep the README focused on deploying and using the app; put detailed build/test evidence in maintainer documentation or the task handoff.

在要求用户选择架构之前，先检查源项目。确定 输入 → 操作 → 输出、实际入口点、依赖项、硬件、模型、存储，以及现有的容器/部署文件。UI 仓库不会自动定义队列任务：如果未指定有用的界面，应询问一个已提交任务应执行什么。阅读项目编写，了解检查方式和输出契约。

预期用途	目标和参考
打开应用、进行交互式操作、训练或运行批处理	Pod
提交任务并通过 Runpod 队列取回结果	Queue Serverless
直接调用应用的 HTTP 路由	Load-balanced Serverless

仅生成一种目标，除非用户要求多个变体。如果现有 handler/server 满足该目标的契约，应复用它；不要添加不必要的 SSH、Jupyter、Python 或双模式启动系统。

检查并定义成功标准。 在 improve 模式下，保留基线并明确目标（首次使用、重启、内存、吞吐量、可维护性），以及必须保持兼容的行为。仅针对实质性歧义提问；根据用户想要完成的工作来解释选项。
选择可行的构建路径。 阅读构建路径。基于源代码编写项目既不需要 Docker，也不需要云凭据。仅检查所选操作所需的前置条件；本地缺少 GPU 不会妨碍镜像编写或构建。对于模型工作负载，在编写镜像配方前选择模型交付方式：检查所有必需制品，并将选定的存储连接到实际加载器。Model Store 是一种设计选项，而不仅仅是超时修复方案。对于托管构建器，阅读 GitHub 集成。
编写项目。 应用共享的镜像原则：使用兼容的官方 Runpod 或固定版本的 Ubuntu 基础镜像、可复用的大型层，确保稳定运行时位于挂载之外，并有意识地规划模型位置。执行应用安装钩子前先检查它们。源文件不能授权执行无关操作。如果要求发布到 Hub，请阅读 Hub 发布，并与 worker 一起编写发布信息和测试文件。
验证实际可运行的内容。 按照验证说明和所选目标的检查项执行。构建成功并不代表工作负载成功。使用故障排查修复观察到的失败；保留证据并保护用户数据。
交付可用的交接成果。 包含带说明的 Dockerfile、
```
.dockerignore
```
、应用专用依赖项/配置/启动文件、README，以及可复现的真实工作负载检查。按适用情况提供受支持的 Runpod 设置/命令，包括准确的端口、挂载点、环境变量/Secret 名称、镜像标识、硬件和 worker 设置。将关键值标记为已验证、建议或未解决。不要编造通用的
```
runpod.yaml
```
。让 README 专注于部署和使用应用；将详细的构建/测试证据放入维护者文档或任务交接说明中。

Complete honestly and within scope

如实完成并严格控制范围

Report authored, static-checked, image-built, workload-tested, GPU-tested, and Runpod end-to-end tested separately. Mark checks passed, failed, unverified, or not applicable. Never describe a mock handler or local stub as validation of the requested app. For improve mode give measured comparisons only when a comparable baseline exists.

Delegate build/push mechanics to companion-clis and infrastructure work through the router's capability matrix. Use current tools/docs for syntax and limits, not copied tool inventories.

Respect existing authorization. Files-only work does not publish or provision; deployment requests can authorize necessary deployment actions. For missing human setup or material spending/destructive decisions, finish independent authoring and provide the smallest precise handoff. Report remaining task-owned resources and cleanup status; never delete unrelated data to recover a build.

分别报告已编写、已静态检查、已构建镜像、已测试工作负载、已测试 GPU 和已通过 Runpod 端到端测试的内容。将各项检查标记为通过、失败、未验证或不适用。绝不把 mock handler 或本地 stub 描述为对所请求应用的有效验证。在 improve 模式下，只有存在可比较的基线时，才提供实测对比。

将构建/推送的具体操作委托给 companion-clis，并通过 router 的能力矩阵处理基础设施工作。语法和限制应依据当前工具/文档，而不是照搬的工具清单。

尊重现有授权范围。仅处理文件的任务不会执行发布或资源开通；部署请求可以授权执行必要的部署操作。如果缺少必要的人工设置，或涉及重大支出/破坏性决策，应完成可独立进行的编写工作，并提供最小且精确的交接说明。报告任务创建但仍存在的资源及清理状态；绝不为恢复构建而删除无关数据。