Room 多人协作 | Nexus 文档

用 Room 组织一次协作

Room 适合需要多个成员共享目标、分工、复核和汇总的任务。开始前确定参与成员、各自职责和最终汇总者。

请一起完成这份产品需求的评审。
研究成员核对用户问题，工程成员检查实现约束，复核成员列出缺口。
先各自给出结论与依据，再由工程成员汇总为 review.md。
没有依据的判断标为待确认；不要修改代码。

创建或管理 Room 时可以选择群主，并决定未提及成员的消息是否由群主接管。未使用 @ 且没有可接管成员时，消息可能被记录但不会启动工作。

群主自动接管处理新消息；主动跟进处理安静后的单聊，两者不同。Room 还可以控制是否允许成员私信协作，以及暂停或恢复成员参与。

以方案评审为例，先规定三个产物，避免成员各写一份相似结论。

人数少时，整理成员也可负责最终汇总。关键是把独立检查安排在汇总前，而不是要求每个成员重复阅读后自由发言。

先发布共同要求，再提及实际执行者。交接消息应包含文件位置、已完成范围、未解决问题和下一位成员的任务。

对照表已保存为 comparison.md。
报价口径与交付范围已整理，方案乙的验收条件仍缺少依据。
请复核成员逐项核对原文，交付 review-notes.md，不直接覆盖对照表。

公开消息用于共享这些状态。私下沟通形成的判断需要带回公开区，其他成员才有明确的接手依据。

公开区用于共同目标、已确认事实、阻塞、交接和最终交付。定向问题或尚未整理的中间意见可以私下沟通，但私下结果不会自动成为所有成员都知道的事实。

汇总者应把必要结论带回公开区，同时保留来源和未解决问题。交付时附上文件或结果位置，便于其他成员检查。

@成员 用于唤醒或交接，不会自动创建任务负责人和验收记录。临时配合可以直接沟通；需要检查任务依赖、负责人和验收状态时使用工作图。

在“网站更新评审”Room 中，文档助手整理行动清单，复核助手检查遗漏信息。图中任务使用教学材料。

Room 公共区保留共同进展，某条回复的详细执行在对应 Thread 查看。排查“成员是否真的读了材料”时，应展开过程检查工具和结果，不仅看公共区一句完成声明。

在 Thread 继续讨论时，明确针对哪份产物修订。需要影响整个协作流程的变更，例如暂停汇总或替换原始方案，应回到公共区说明。

同一轮只让一个成员负责写某个最终文件，其他成员提供问题清单或独立文件。共享工作区不是版本控制系统，成员分工也不提供自动冲突合并。

如果已经出现互相覆盖，先停止对冲突文件的写入，保留可用版本，再由指定成员合并。需要长期追踪负责人、依赖和验收状态时，使用工作图，@成员 本身不创建这些记录。

先看被提及的成员是否仍在 Room、模型是否可用、是否等待审批，以及前置材料是否已交付。缺少材料或决定时，在原任务中补充信息后再继续。

如果大家都完成了自己的部分却没有总结果，补上汇总负责人和交付文件名。若多名成员同时修改同一文件，先划分各自负责的文件或步骤，再继续执行。

在房间管理中暂停成员参与，会影响后续协作，不等于删除这个 Agent。暂停前把尚未交付的部分和接手者写入公开消息；恢复后先核对当前材料，避免继续使用暂停前的旧版本。

更换方案文件时，说明哪些产物受影响。例如只更新方案乙的报价，就要求整理者修改对应行，再请复核者检查该行及相关结论。已经验证且不受影响的部分可以保留。

若没有成员被提及且群主不能接管，公开消息可能已记录却没有启动执行。先检查实际接手者，再排查模型与审批，避免通过重复发送同一任务制造多份交付。

要求汇总者给出最终文件、验证结果和仍未解决的问题。逐一打开文件，确认复核意见已处理，缺失依据没有被写成结论。没有明确最终交付的 Room 仍可能继续讨论，应把结束标准写进共同任务或 Room Skill。

验证成功后，可以用Room Skill保存分工、公开/私下沟通和停止规则。需要复用结构化任务关系时，阅读工作图与运行图。