角色会话场景
老板、组长、员工三种角色与清海的飞书组织架构对话场景设计。 会话场景概览见 飞书组织架构识别，能力定义见 Skill 清单。
组织结构与信息权限
团队结构
老板
├── 开发部门
│ ├── 项目经理
│ ├── 前端组（组长 + 5-10 人）
│ ├── 后端组（组长 + 5-10 人）
│ └── 产品组（组长 + 5-10 人）
└── 运营组- 组长 = 部门/小组负责人，管理范围按「人」划定，不按「项目」划定
- 老板在配置文件指定（1-2 人），拥有全部信息访问权
- 员工可以查询公开信息（部门列表、公司架构），但不能查他人隐私信息
信息权限矩阵
| 维度 | 老板 | 组长 | 员工 |
|---|---|---|---|
| 本人基本信息 | ✅ | ✅ | ✅ |
| 公司架构（部门列表/层级） | ✅ | ✅ | ✅ |
| 本组成员个人信息 | ✅ | ✅ | ❌ |
| 其他组成员个人信息 | ✅ | ❌ | ❌ |
| 其他组公开信息（人数/负责人） | ✅ | ✅ | ✅ |
| 全公司人员明细 | ✅ | ❌ | ❌ |
| 人员变动（入职/离职/调岗） | ✅ 全部 | ✅ 本组 | ❌ |
越权查询引导规则：
- 组长查其他组个人信息 → 引导找对方组长或项目经理
- 员工查他人信息 → 引导找组长或项目经理
- 不升级到老板层面
老板会话场景
核心诉求：全局掌控 + 人事动态。公司多少人、谁来了谁走了、各部门什么情况。 互动模式：随时查询，追问细节。 信息范围：无隔离，全公司所有人、所有部门。
架构总览类
| 用户问法 | 清海应答 | 备注 |
|---|---|---|
| "公司现在多少人" | 总人数 + 按部门分布 | 全公司维度 |
| "各部门人数怎么样" | 按部门列出人数 + 负责人 | 部门对比 |
| "开发部门架构是什么样的" | 开发部门下的组织树（子部门 + 各组人数 + 组长） | 部门下钻 |
人员追踪类
| 用户问法 | 清海应答 | 备注 |
|---|---|---|
| "最近有新同事吗" | 近期入职人员列表（姓名 + 部门 + 入职时间） | 全公司维度 |
| "最近有人离职吗" | 近期离职人员列表 | 全公司维度 |
| "王五是哪个部门的" | 王五的部门 + 职位 + 上级 | 个人查询 |
| "张三管哪些人" | 张三的直属下属列表 | 管理幅度 |
| "产品部谁负责" | 产品部负责人 + 成员概况 | 部门负责人 |
组织管理类
| 用户问法 | 清海应答 | 备注 |
|---|---|---|
| "有没有通讯录信息不全的" | 列出缺失职位/上级/部门的人员 | 数据质量 |
| "帮我把王五的 GitLab 绑一下" | 执行绑定操作（老板可代绑任何人） | 身份管理 |
| "运营组和产品组各几个人" | 两个部门人数对比 | 跨部门对比 |
设计原则
- 无信息隔离：老板看全公司所有人、所有部门
- 上下文连续：追问"他具体什么职位"能接住上一轮的人/部门
- 人名自动映射：说中文名即可，清海内部匹配飞书账号
- 数据质量可见：老板能看到通讯录信息的完整度
组长会话场景
核心身份：既做业务又管人，日常关注组内成员动态、准备站会素材。 互动模式：主动查询 + 组内管理。 信息范围：本组成员个人信息 + 全公司公开信息。
组内管理类
| 组长问 | 清海答 | 备注 |
|---|---|---|
| "我们组有几个人" | 本组成员列表（姓名 + 职位） | 自动识别"我们组" |
| "我们组最近有新人吗" | 本组近期入职人员 | 组内变动 |
| "李XX 是什么职位" | 该组员的职位信息 | 只能查本组的人 |
| "我管哪些人" | 直属下属列表 | 管理幅度确认 |
组织查询类
| 组长问 | 清海答 | 备注 |
|---|---|---|
| "公司有哪些部门" | 全部部门列表（名称 + 人数） | 公开信息 |
| "后端组几个人" | 后端组人数 + 负责人 | 其他组公开信息 |
| "产品部负责人是谁" | 产品部负责人姓名 | 公开信息 |
身份管理类
| 组长问 | 清海答 | 备注 |
|---|---|---|
| "帮张子卓绑一下 GitLab 账号" | 确认后绑定（组长可代绑本组成员） | 组内身份管理 |
| "张子卓的 GitLab 绑了吗" | 查询该组员的平台绑定状态 | 组内查询 |
跨组查询边界
| 组长问 | 清海答 |
|---|---|
| "后端组有谁" | 返回后端组人数 + 负责人（公开信息），不返回个人明细 |
| "后端组的王锦什么职位" | "王锦的个人信息可以找后端组长或项目经理了解" |
| "公司架构是什么样的" | 返回完整部门树（公开信息） |
设计原则
- 信息范围 = 本组成员：前端组长看不到后端组的个人信息
- 公开信息不隔离：组长能看到所有部门的公开数据（名称/人数/负责人）
- "我们组"自动解析：清海通过 PersonIndex 知道组长管哪些人
- 可代绑本组：组长可以帮组内成员绑定平台身份
员工会话场景
核心定位：专心工作，需要时能快速查到组织信息。 互动模式：主动查询为主，查询范围有限。 信息范围：自己的信息 + 公司公开信息。
个人信息类
| 员工问 | 清海答 | 备注 |
|---|---|---|
| "我是哪个部门的" | 你所在的部门 + 职位 | 自己的信息 |
| "我的上级是谁" | 直属上级的姓名 + 职位 | 自己的关系 |
| "我的 GitLab 绑了吗" | 查询自己的平台绑定状态 | 自己的身份 |
组织查询类（公开信息）
| 员工问 | 清海答 | 备注 |
|---|---|---|
| "公司有哪些部门" | 全部部门列表 | 公开信息 |
| "产品部几个人" | 产品部人数 + 负责人 | 公开信息 |
| "人事部负责人是谁" | 人事部负责人姓名 | 公开信息 |
身份绑定类
| 员工问 | 清海答 | 备注 |
|---|---|---|
| "帮我绑定 GitLab 账号 wangjin" | 确认后绑定 | 只能绑自己的 |
| "大家叫我小王" | "好的，已记住你的别名小王" | 别名学习 |
越权查询拒绝
| 员工问 | 清海回应 |
|---|---|
| "王锦什么职位" | "同事的个人信息可以找组长或项目经理了解" |
| "研发部有谁" | 返回研发部人数 + 负责人（公开信息），不返回个人明细 |
| "最近有人离职吗" | "人事变动信息可以找组长或人事部门了解" |
| "帮我查张三的手机号" | "个人联系方式属于隐私信息，建议直接在飞书上联系" |
设计原则
- 信息范围 = 自己 + 公开：能查自己的一切 + 公司公开架构
- 语气友善不生硬：越权时礼貌引导，不说"你没有权限"
- 鼓励绑定：未绑定平台时适时引导，不强制
- 别名自然学习：员工说"叫我小王"，清海自然记住
三角色信息权限流转
关键设计决策汇总
| 决策 | 结论 | 理由 |
|---|---|---|
| 信息隔离维度 | 按人隔离（公开信息不隔离） | 部门架构是公开的，个人信息才需要隔离 |
| 公开信息定义 | 部门名称、人数、层级关系、负责人姓名 | 这些在飞书通讯录中本身就是可见的 |
| 越权引导 | 找组长或项目经理，不升级老板 | 减少老板负担，平级协调 |
| "我们组"解析 | 通过 PersonIndex 自动识别组长管辖范围 | 不需要每次指定组名 |
| 代绑权限 | 老板可代绑任何人，组长可代绑本组 | 方便管理者帮新人完成初始化 |
| 飞书为权威源 | 部门/职位/上级以飞书通讯录为准 | 避免 AI 推断与行政数据矛盾 |
| 离职处理 | MVP 即时静默，后续增加交接期 | 先保守，观察实际需求再迭代 |