一个项目可以开始工作，需要成员能访问正确的工作空间，AI 能调用可用模型，执行环境能获取代码并运行所需服务。本篇按首次接入项目的顺序，说明这些配置由谁完成、在哪里操作，以及怎样检查是否可用。
软件工厂中的组织也称为“租户”。租户管理员管理当前组织的成员和配置；平台管理员负责系统层面的运行服务。菜单会根据账号权限显示，两类管理员的操作范围不同。
先确认配置分工
下面的配置需要在目标租户中完成。开始前，准备工作空间名称、成员名单、代码来源、环境分支、模型接入资料和可用的执行资源。
第一步：创建或配置工作空间
进入工作空间列表，选择 “新建工作空间”。已有项目可从对应工作空间的 “编辑” 入口检查配置。
在 “基本信息” 中填写名称、标识和简介。标识在租户内唯一，以小写字母开头，只包含小写字母和数字。名称应让团队能够区分业务系统或项目。
选择应用与代码来源
在 “代码仓库” 中选择 “应用与代码来源”：
创建新应用或关联已有应用时，环境分支来自租户统一配置，工作空间不能单独修改。加载失败或分支不符合预期时，先由配置负责人检查租户设置与应用接入。
关联外部代码库时，按仓库要求填写 “用户名” 和 “访问令牌（Token）”。凭据需支持本项目实际需要的仓库操作；能够读取代码，不代表已经具备推送、合并或部署权限。
如果页面提示自动创建服务未启用，先确认项目应使用哪种接入方式，再选择关联已有应用或外部代码库。
配置执行资源
进入 “Worker 调度”，填写 “Worker Tags”。这些标签用于选择项目使用的执行资源，应与平台管理员提供的可用标签一致；多个值用逗号分隔，当前表单要求至少填写一个标签。
表单可能预填 pool:default，但保存该值不代表环境中已经存在对应资源。先确认相应 Worker 已就绪，再完成创建或保存。
保存成功后，重新打开工作空间，检查应用关联、仓库及分支。若应用或代码库仍在准备中，应继续查看准备结果，出现失败时根据错误处理原工作空间。
第二步：添加成员并分配访问范围
进入 “租户设置 → 成员”。可以添加已有用户，也可以处理通过邀请加入的申请。
添加已有用户
- 点击 “新建成员”，输入邮箱、用户名或手机号。
- 点击 “查找用户”，核对返回的用户身份。
- 选择角色，并配置 “授权工作空间”。
- 点击 “确认添加”，再检查成员列表中的角色与授权范围。
角色可以多选，当前提供：
非租户管理员至少需要选择一个授权工作空间。为成员分配 IT 角色后，仍需确认其项目授权；切换页面视角不会改变账号持有的权限。
找不到用户时，是否能直接创建账号取决于租户配置。当前租户未开启账号创建时，按页面提示联系系统管理员处理。
处理邀请与已有成员
成员接受邀请后，如果申请进入 “待审核”，管理员需要核对人员，再选择 “审核通过” 或填写原因后 “驳回”。通过后检查其角色和工作空间范围。
调整已有成员时，点击该成员所在行的 “编辑”，在 “工作空间授权” 对话框中修改角色和工作空间，再点击 “保存授权”。成员重新加载页面后，应确认目标项目及所需功能可见。
第三步：确认模型可用
进入 “租户设置 → 模型密钥”，页面分为 “平台默认模型” 和 “自定义模型”。
平台默认模型由平台维护，租户页面只读。如果团队使用平台提供的模型，先确认页面有可用模型，再通过实际会话验证。页面提示“平台尚未配置默认模型”时，可联系平台管理员，或按组织安排配置自定义模型。
添加自定义模型
在 “自定义模型” 中：
- 点击 “新建提供商”，填写名称、接入类型、Base URL，以及服务要求的 API Key。
- 确认提供商处于启用状态，保存配置。
- 点击该提供商上的 “＋ 模型” 按钮，在 “添加模型” 对话框中填写 “模型 alias” 和 “上游模型 ID”。
- 按模型实际支持情况配置 “并行工具调用”、“推理能力”、“多模态输入”，启用并保存模型。
模型 alias 用于标识平台内配置的模型；上游模型 ID 应与模型服务接受的标识一致。接入类型、地址和模型能力应使用服务提供方确认的信息，勾选能力不会让上游模型自动获得该能力。
已创建提供商的名称和模型 alias 在编辑时不可修改。编辑已有提供商时，API Key 留空会保留原密钥。
密钥和仓库令牌应填写在相应配置表单中，不放入需求对话、文档或代码仓库。排查时提供配置名称和脱敏错误即可。
验证实际调用
配置保存后，在目标工作空间发起一次简短会话，确认本次使用的模型并检查响应。保存成功说明配置已被接受，实际调用还依赖地址可达、凭据有效及上游服务可用。
需要追踪调用时，可进入 “租户设置 → 调用记录”，结合会话发生时间查看相关记录。平台模型的问题交给平台管理员；自定义模型的问题由租户配置负责人核对。
第四步：检查运行环境与项目依赖
Worker 提供任务执行资源，沙箱提供具体工作的运行环境。由平台管理员检查运行服务，由研发人员检查其中的项目能否实际工作。
平台管理员可以在 “系统设置 → Workers 运维” 查看在线 Worker、版本和共享服务状态，并核对项目使用的资源标签。涉及具体交付批次时，也可以通过 “Wave Sandbox 运维” 定位其环境。
首次接入项目时，按以下顺序验证：
- 环境准备：目标工作空间能够启动所需会话或批次环境，没有资源分配或连接错误。
- 仓库访问：环境内能够读取本项目代码，当前分支和项目目录正确。
- 依赖与配置：安装所需依赖，准备项目要求的数据库、接口地址及环境配置。
- 启动与构建：按仓库说明启动应用、执行构建，确认页面或服务可以访问。
- 测试执行：运行本次工作需要的检查，确认测试工具、账号和数据可用。
- 目标环境：需要独立 TEST 或正式发布时，分别核对部署权限、目标和访问方式。
如果团队使用沙箱 Public Access 提供预览，应先确认应用实际监听的端口及访问要求，再由有权限的成员配置对应入口。预览查看方式见查看预览、测试结果并完成业务验收。
第五步：确认交付流程和人工分工
首次创建交付批次前，与流程负责人确认已有可用的已发布工作流，并明确哪些环节由 AI 执行、哪些环节需要人工确认，以及谁负责验收和发布。
工作流实例按创建时采用的已发布版本执行。后续修改流程定义，不应被理解为已经改写正在进行的批次。具体阶段、操作和恢复路径以该实例页面为准。
采用标准交付流程时，还需确认实际发布方式：“确认上线”记录人工对上线结果的确认，本身不执行部署。 仓库关联、预览可用和业务验收通过，各自只说明对应环节已完成。
配置完成后，做一次项目验证
建议管理员与项目负责人共同记录以下结果，作为团队开始工作的依据：
某一项尚未通过时，记录具体错误和负责人，处理后重新验证该项。任务已创建但没有继续执行时，参考任务没有继续执行时如何排查。