runpod-build-template

构建 Runpod 模板项目

交付应用所需的文件，以及准确的部署交接信息。支持创建和改进；GitHub URL 是源输入，不要求使用特定构建器。保留用户的项目惯例和指定行为。

对于多步骤任务，首先参照已完成示例，尤其是项目编写示例。 即使已有预构建模板，明确提出的打包请求仍属于此流程。 通过 路由器 使用基础设施流程，将已构建的镜像注册为 Runpod 模板，无需再编写 Dockerfile。

选择契约，然后编写项目

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

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

除非用户要求多个变体，否则只生成一个目标。如果现有处理程序或服务端符合该目标的契约，就复用它；不要添加不必要的 SSH、Jupyter、Python 或双模式启动系统。

1. 检查并定义成功标准。 对于改进模式，保留基线，并明确目标（首次使用、重启、内存、吞吐量、可维护性）以及必须保持兼容的行为。只询问会实质影响方案的歧义；根据用户想做的事说明各项选择。
2. 选择可行的构建路径。 阅读构建路径。编写源文件既不需要 Docker，也不需要云凭据。只检查所选操作的前置条件；本地没有 GPU 并不妨碍编写或构建镜像。对于模型工作负载，在编写镜像配置前，先选择模型交付方式：检查所有必需的构件，并将选定的存储连接到实际加载器。Model Store 是一种设计方案，不只是解决超时问题的方法。对于托管构建器，请阅读GitHub 集成。
3. 编写项目。 遵循共享的镜像原则：使用兼容的官方 Runpod 基础镜像或固定版本的 Ubuntu，复用体积较大的层，将稳定的运行时置于挂载目录之外，并合理放置模型。执行应用安装钩子前，先检查其内容。源文件不能授权无关操作。如果用户要求发布 Hub 条目，请阅读Hub 发布，并与工作器一并编写条目和测试文件。
4. 验证实际可运行的部分。 遵循验证和所选目标的检查项。构建成功不代表工作负载运行成功。根据故障排查修复已发现的问题；保留证据并保护用户数据。
5. 交付可用的交接材料。 包含文档化的 Dockerfile、.dockerignore、应用专用依赖项／配置／启动文件、README，以及可复现的真实工作负载检查。提供受支持的 Runpod 设置和命令，并根据需要注明精确端口、挂载、环境变量／密钥名称、镜像标识、硬件和工作器设置。将重要值标明为已验证、建议值或待确认。不要编造通用的 runpod.yaml。README 应专注于部署和使用应用；详细的构建／测试证据应放在维护者文档或任务交接材料中。

诚实且在范围内完成

分别报告已完成编写、静态检查、构建镜像、工作负载测试、GPU 测试和 Runpod 端到端测试的情况。将检查标记为已通过、未通过、未验证或不适用。 绝不将模拟处理程序或本地存根描述为对所请求应用的验证。 对于改进模式，仅在存在可比基线时提供实测对比。

将构建和推送的操作委托给 companion-clis，将基础设施工作交由路由器的能力矩阵处理。 使用当前工具和文档确认语法与限制，不要照搬工具清单。

遵守现有授权。仅处理文件的工作不会发布或配置资源； 部署请求可以授权必要的部署操作。对于需要人工设置，或涉及重大支出／破坏性决策的情况，先完成可独立完成的编写工作，再提供尽可能精确的交接说明。报告仍由任务负责的资源及其清理状态；绝不为恢复构建而删除无关数据。