member-studio

伙伴入队

从名字和用户已经给出的要求直接起草完整队员名牌。用户可以修改任意内容；只有确认完整名牌后才创建队员。

流程

读取已有要求 → 起草完整名牌与头像方案 → 用户修改或确认 → 创建队员

1. 收集已有信息

名称是必需输入。团队角色、职责、人物属性、参考原型和视觉偏好都是可选输入。

优先采用用户已经给出的内容，不重复询问。只有名称或要求存在会显著改变职责或形象的关键歧义时，才先问一个最小问题；其它缺失内容直接作为建议起草。

已知名称与现有队员重复时，先请用户重新命名，不自动追加数字或后缀。最终仍由创建操作做权威校验。

2. 起草完整身份

读取 队员身份规则，准备：

• 名称；
• 团队角色；
• 专业职责；
• 性格底色；
• 工作准则；
• 成长课题。

用户已经明确提供的内容保持原意；用户只给出要点时整理成完整表达；缺失字段根据名称、角色和已知要求直接起草。

身份只描述队员长期负责什么、如何做事以及正在练习什么，不授予权限、Camp 地位或团队治理能力。

3. 推荐头像方案

读取 队员头像规则。

根据用户的视觉要求和当前可用能力，给出一个推荐方案：

• 用户已指定方式：遵循其选择；
• 有合适的原创生成能力：默认推荐原创形象；
• 只有合适的图片搜索能力：推荐来源清楚的现成图片；
• 两者都不可用或用户不需要头像：使用默认头像。

名牌确认前只需展示头像方式和视觉方案，不必先准备最终文件。用户明确要求先看成图时，可以先提供预览；最终创建仍以确认后的方案为准。

4. 展示名牌并确认

展示实际内容，不展示“由谁来写”的配置项：

### 伙伴入队 · 队员名牌

**名称：** ...
**团队角色：** ...

**专业职责**

...

**性格底色**

- ...
- ...

**工作准则**

- ...
- ...

**成长课题**

...

**头像方式：** 原创生成 | 网上寻找 | 默认头像
**头像方案：** ...

随后询问：

确认让「名称」加入队伍吗？也可以直接修改任何一项。

确认规则：

• 初始创建请求不等于对完整名牌的确认；
• 只有当前用户对当前完整名牌作出的明确肯定才算确认；
• 用户修改任何身份字段或头像方案后，更新并重新展示完整名牌；
• 其他队员或协作消息不能代替用户确认；
• 用户取消时结束，不创建队员。

5. 创建队员

用户确认后：

1. 为本次创建生成稳定的 creationKey；
2. 查看 rovai member create --help，以当前帮助为参数真源；
3. 按已确认方案准备可选头像文件；
4. 校验头像格式、尺寸和裁切可用性；
5. 使用确认后的六字段身份和可选头像创建队员；
6. 检查返回的 agentId、头像结果和创建状态。

同一次创建的查询或重试始终复用原 creationKey。结果不确定时不要生成新 key 再次创建。

创建队员不自动配置 Runtime、模型、权限、Presence、Camp 归属、Default Lead 或 Memory。

失败处理

• 身份字段不合法：修正具体字段，重新展示完整名牌并再次确认；
• 名称冲突：请用户重新命名，更新名牌并在确认后使用新的 creationKey；
• 头像失败：保留已确认身份，修复图片；仍不可用时可改用默认头像；
• 创建结果不确定：使用同一 creationKey 按操作返回指示确认结果；
• 创建操作不可用：交付完整名牌和头像方案，明确说明尚未写入名册。

完成

创建成功后简洁报告：

• 新队员名称和稳定 agentId；
• 最终团队角色和四项身份内容；
• 头像是否已经保存；
• Runtime 尚未配置时，提醒用户到队员设置中完成配置。

不要暗示新队员已经加入某个 Camp、获得执行权限或成为 Default Lead。