通讯录可见范围设计表：按层级、岗位、项目三类授权

通讯录看起来只是一个找人工具，实际承载的是组织架构、汇报关系、岗位分工和项目协作四层信息。默认全员可见时，员工能看到的往往不只是一串名字，还包括部门层级、汇报线、手机号、邮箱、项目成员和外部联系人。信息一旦被批量导出或截图，后续很难追溯。

IBM《2026年数据泄露成本报告》显示，全球数据泄露平均成本已达到499万美元，创下该报告发布以来的新高。Ponemon Institute与DTEX联合发布的《2025内部风险成本报告》显示，单个组织每年因内部风险造成的平均成本为1740万美元，平均遏制时间为81天。通讯录权限只是这些风险的入口之一，也是容易被忽视的入口。

通讯录可见范围应该按层级、岗位、项目三类授权叠加设计，而不是在全员可见和一刀切隐藏之间二选一。 层级授权负责划组织边界，岗位授权负责收字段和操作，项目授权负责开有期限的跨部门口子。顺序不能反，先用层级圈定大范围，再用岗位决定范围内能看到什么、能做什么，最后用项目授权解决临时协作。

这套方法最终要落到一张设计表上。表里至少写清授权对象、可见范围、可见字段、可沟通范围、有效期、审批人和复核周期。下面按三层拆开讲，再给出可以直接套用的表格和冲突裁决规则。

一、三类授权叠加使用

三类授权解决的是不同问题，不能互相替代。只做层级授权，跨部门项目没法协作；只做岗位授权，组织调整时规则会散落；只做项目授权，日常通讯录又会缺少稳定边界。三者叠加，才能同时兼顾效率和信息暴露。

授权类型	解决的问题	授权对象	典型规则	生效周期	主要风险
层级授权	组织边界	集团、子公司、部门、班组	本公司及下级可见，兄弟公司默认不可见	长期	部门树过粗或过细
岗位授权	字段和操作	普通员工、负责人、人力资源、财务、信息技术管理员	公开字段默认可见，受限字段按岗位开放	长期	角色膨胀，权限难维护
项目授权	临时跨部门协作	项目成员、外协、审计人员	只可见项目接口人和项目群，随项目结束回收	项目周期	项目群变成永久组织

在设计表里，还要把三个动作分开。 可见是能不能在通讯录、搜索和个人资料页看到，可沟通是能不能发起单聊、群聊、语音或文件传输，可管理是能不能新增、修改、停用成员或调整部门。 很多组织只做了可见控制，却忘了可沟通和可管理，结果员工看不到某人，但仍然可以通过群聊把对方拉进来，或者管理员能改组织架构却没有审计记录。

通讯录与单聊、群聊、文件传输通常共用一套关系链，控制可见范围时也要同步检查 即时聊天的入口。只关通讯录列表，不关搜索、个人资料页和群成员列表，权限就会出现侧门。

图1展示了三类授权的叠加顺序。层级授权先圈定组织范围，岗位授权再决定字段和操作，项目授权最后开临时口子，三者汇入同一份通讯录可见结果。

二、层级授权划边界

层级授权适合组织架构相对稳定的企业，尤其是集团、多子公司、总部加分支机构的场景。它的核心不是给每个人一个部门名称，而是明确三件事。可见范围是否包含下级部门，兄弟部门或兄弟子公司之间是否默认互不可见，财务、研发、法务等敏感部门是否从通讯录中隐藏。

层级场景	默认可见	默认不可见	例外处理
集团总部	全集团组织架构	无	高管按分管范围开放
子公司	本公司及下级部门	兄弟子公司	联合项目单独授权
部门	本部门及下级部门	其他部门	指定接口人白名单
敏感部门	本部门成员	其他部门全员	分管负责人审批后开放
高管	分管范围	非分管范围	跨域查看只给摘要字段

层级授权的优点是容易理解，配置批量，员工也能根据组织关系判断自己应该看到谁。局限是它假设组织边界等于协作边界，而现实中跨部门项目、矩阵管理、临时任务组经常打破这个假设。部门树切得太粗，员工能看到过多组织信息；切得太细，跨部门找人又要靠私下问。

落地时建议把部门树当作第一层过滤，不要当作唯一依据。设计表里要写清部门标识、上级部门、是否包含下级、隐藏部门、白名单和例外审批人。组织隔离、IP登录限制、界面水印这类能力属于 通讯安全范畴，适合和层级授权一起设计，而不是等出了问题再补。

三、岗位授权收字段

层级授权解决的是能看到哪个范围，岗位授权解决的是在这个范围里能看到哪些字段、能做哪些操作。同样的部门范围内，普通员工、部门负责人、人力资源、财务接口人和信息技术管理员，需要的字段和操作完全不同。

岗位角色	可见对象	可见字段	可执行操作	复核要求
普通员工	本部门加协作部门	姓名、部门、职位、企业邮箱	发起会话、加入项目群	每半年
部门负责人	本部门及下级	公开字段加汇报关系	管理本部门成员、查看部门审计摘要	每季度
人力资源	全员基础资料	公开字段加在职状态	维护成员资料、发起入职调岗流程	每季度
财务接口人	对接部门	公开字段加对接人联系方式	发起财务相关会话	每半年
信息技术管理员	账号与组织架构	公开字段加账号状态	创建、停用账号，调整部门	每季度
高管	分管范围	公开字段加汇总信息	查看分管范围审计摘要	每半年

岗位授权的关键不是给岗位一个万能角色，而是把角色拆成四元组，角色、数据范围、字段、操作。 同一个角色在不同部门可以有不同的数据范围，同一个数据范围在不同角色面前可以开放不同字段。 把这两层混在一起，最后就会出现角色数量失控。

字段建议至少分三级。公开级包括姓名、部门、职位、企业邮箱，可以默认可见；受限级包括手机号、座机、汇报关系、办公地点，按岗位开放；敏感级包括身份证号、薪酬、合同、银行卡、家庭信息，默认不可见，单独审批。字段分级写进设计表，系统配置才有依据。

岗位授权常见的问题是角色膨胀。每加一个特殊岗位就新建一个角色，半年后没人说得清每个角色能看什么。建议用基础角色加少量例外，角色数量控制在可维护范围内，每季度做一次角色复核。一人多岗、代理、兼职的情况也要单独写明，默认取交集，只有经过审批的代理关系才临时取并集，并设置失效时间。

四、项目授权有期限

项目授权解决的是跨部门、跨子公司、跨外部伙伴的临时协作。它的本质是临时扩大协作边界，不是永久扩大通讯录。项目结束后，成员、群组、文件和搜索关系都应该回到项目开始前的状态。

项目场景	授权对象	可见范围	可沟通范围	有效期	退出规则
研发项目	项目成员	项目群成员加项目接口人	项目群、单聊、文件	项目周期	项目结束自动退出
投标项目	投标小组	投标接口人加相关资质部门	投标群、指定文件	投标周期	开标后回收
审计项目	审计人员	审计范围成员	审计群、只读文件	审计周期	审计报告归档后回收
外协合作	外协人员	项目接口人	项目群	合同周期	合同结束立即回收
并购整合	整合小组	双方指定接口人	整合群、指定文件	整合周期	整合完成或终止时回收

项目授权要写清五个字段，项目负责人、授权对象、可见范围、有效期、退出规则。没有这五个字段，项目群很容易变成永久组织。项目负责人应该是权限的主要责任人，而不是把权限全部交给信息技术部门。

外部协作要单独处理。外协人员默认只可见项目接口人和项目群成员，不可见公司完整组织架构，不可搜索非项目成员，文件权限随项目结束回收。外协人员加入全员群、看到全员通讯录，是常见的越权场景。

项目授权的风险在于项目蔓延。项目结束后群还在、文件还在、成员还在，权限就变成了历史遗留。建议把项目群和项目授权绑定，项目状态变更为结束或归档时，自动触发成员退出和权限回收。项目负责人变更时，也要同步转移权限责任。

五、设计表与冲突裁决

把三层放在一张表里，才能看清规则之间的关系。下面这张主表可以直接作为设计模板，实际使用时按组织规模增减行。

编号	授权维度	适用对象	可见范围	可见字段	可沟通范围	有效期	审批人
L1	层级	集团总部	全集团组织架构	公开级加分管范围受限字段	全集团	长期	集团负责人
L2	层级	子公司	本公司及下级	公开级	本公司	长期	子公司负责人
L3	层级	敏感部门	本部门及指定接口部门	公开级	指定接口人	长期	分管负责人
R1	岗位	普通员工	本部门加协作部门	公开级	本部门加协作部门	长期	部门负责人
R2	岗位	部门负责人	本部门及下级	公开级加汇报关系	本部门及下级	长期	分管负责人
R3	岗位	人力资源	全员基础资料	公开级加在职状态	按业务需要	长期	人力资源负责人
R4	岗位	信息技术管理员	账号与组织架构	公开级加账号状态	不默认开放聊天内容	长期	信息技术负责人
P1	项目	项目成员	项目群成员加项目接口人	公开级	项目群加接口人	项目周期	项目负责人
P2	项目	外协人员	项目接口人	公开级	项目群	合同周期	项目负责人
P3	项目	审计人员	审计范围成员	公开级，只读	审计接口人	审计周期	审计负责人

表里没有写商务信息、名次和供应商偏好，因为这些内容不应该影响权限设计。设计表要解决的是谁在什么条件下能看到谁、看到哪些字段、能做哪些操作，以及什么时候收回。

规则冲突时，按下面的顺序裁决。

规则一，拒绝优先。 只要有一条明确的不可见规则命中，就先拒绝，不要用其他允许规则覆盖。 规则二，显式优于继承。 针对具体成员的规则优先于部门继承规则。 规则三，字段最小化。 对象可见不代表字段全开，按岗位只给业务必需字段。 规则四，项目授权不扩部门。 项目授权只能扩大项目相关对象，不自动让成员看到对方部门全员。 规则五，例外必须有时限和审批。 没有审批人和失效时间的例外，不写进系统。 规则六，管理权限单独审计。 能改组织架构的人，不应默认能看全部聊天内容；能看审计日志的人，不应默认能改权限。

冲突场景	裁决	说明
部门可见，但某个成员被隐藏	隐藏优先	成员级不可见规则覆盖部门级可见规则
项目成员来自不可见部门	只开放项目接口人	不自动开放对方部门全员
高管跨域查看	给摘要，不给敏感字段	跨域可见不等于字段全开
外协人员搜索员工	拒绝	只允许搜索项目接口人
信息技术管理员查看聊天内容	拒绝	管理权限和审计权限分离
离职员工仍在项目群	自动退出	账号停用触发项目群退出

图2把冲突裁决压缩成三条路径。可见规则、不可见规则和例外授权同时命中时，先看不可见，再看显式例外，最后才看基础授权。

六、落地步骤与验收

设计表写完只是开始，真正容易出问题的是配置和回收。建议按六步走。

第一步，盘点组织数据。 确认部门树、成员归属、汇报关系、岗位、项目群和外部联系人是否完整，是否存在一个员工挂多个部门、一个项目跨多个子公司的情况。

第二步，给通讯录字段分级。 把姓名、部门、职位、企业邮箱放到公开级，把手机号、座机、汇报关系放到受限级，把身份证号、薪酬、合同放到敏感级。字段分级不完成，岗位授权就缺少依据。

第三步，定义基础角色。 先定义普通员工、部门负责人、人力资源、财务接口人、信息技术管理员、高管六个基础角色，再用例外处理特殊岗位。不要一开始就为每个岗位建角色。

第四步，建项目授权模板。 按研发、投标、审计、外协、并购整合分别建模板，每个模板固定项目负责人、授权对象、可见范围、有效期和退出规则。

第五步，配置系统。 把层级、岗位、项目三类规则写进系统，开启拒绝优先、字段最小化、例外审批和操作日志。需要和内部账号体系、审批系统对接的，优先使用开放接口和 灵活扩展能力，减少手工维护。

第六步，做验收和审计。 用真实场景测试，不要只看配置页面。新员工入职、调岗、加入项目、退出项目、外协加入、离职、跨子公司搜索、管理员操作，这八个场景都要有预期结果和检查点。

验收场景	预期结果	检查点
新员工入职	只看到本部门及下级公开字段	通讯录、搜索、个人资料页一致
员工调岗	原部门权限回收，新部门权限生效	调岗当天完成，历史群组单独处理
加入项目	只增加项目接口人和项目群	不增加对方部门全员可见
退出项目	项目群、文件、搜索关系同步回收	退出后无法搜索项目成员
外协加入	只看到项目接口人	不可见组织架构和全员群
员工离职	账号停用，项目群自动退出	历史文件访问关系一并回收
跨子公司搜索	默认搜不到兄弟公司成员	联合项目走单独授权
管理员操作	管理动作有日志，权限分离	管账号的不能看聊天内容

图3把权限生命周期画成一个完整循环。入职、定岗、入项目、退出项目、离职五个节点都要有对应的授权或回收动作，任何一段缺失，权限都会留在系统里。

七、工具能力怎么对照

设计表能不能落地，取决于工具是否支持组织树、字段级权限、项目授权、审计和生命周期同步。下面按私有化和公有云两类，选四个常见产品做能力对照。这里不做排名，也不给综合得分，只列和通讯录可见范围直接相关的部分。

产品	部署方式	通讯录权限要点	适合场景	需要评估的边界
喧喧IM	私有化部署，开源版与专业版	树形组织架构、通讯录可见范围、用户权限、消息审计、IP登录限制、LDAP与AD同步	数据留在企业内、信创适配、研发协同	超大型集团跨域治理和外部生态集成需要额外规划
飞书	以公有云为主	组织架构可见范围主规则与补充规则、用户组、规则验证	文档协作、跨组织连接	规则维护成本、数据驻留方案
钉钉	以公有云为主	通讯录查看权限、部门可见范围、成员资料显示设置、分级管理员	管理层级多、流程制度重	权限入口分散、数据驻留方案
企业微信	以公有云为主	隐藏部门或成员、限制查看外部门、限制查看所有人、字段隐藏	客户连接、行政人事操作	项目级细粒度、私有化成本

喧喧IM

喧喧IM是禅道软件（青岛）集团有限公司旗下的企业即时通讯产品，主打 私有化部署，数据存放在企业自有服务器，可在纯局域网环境运行。后台提供组织架构、用户管理、权限管理、状态监控和系统统计，通讯录按企业实际组织架构搭建，员工有明确的部门归属。

在通讯录权限上，官方资料给出的能力包括树形组织架构配置、用户权限与通讯录可见范围设置、消息审计日志，同时提供IP登录限制、界面水印、LDAP与AD同步等管理能力。产品分 开源版和专业版两档，开源版核心功能开放，专业版面向信创适配和更完整的企业级能力。这里的轻量指架构和部署轻，聊天、音视频、文件协同等能力并不因此减配。

喧喧IM适合把数据留在企业内、需要私有化部署、信创适配、组织权限控制，或已经使用禅道做研发管理的组织。需要评估的边界是，超大型集团的跨域治理、复杂外部协作生态和大量第三方应用集成，往往需要更细的项目级规划和额外实施投入。

飞书

飞书是字节跳动旗下的协作平台，强项在文档、表格、会议和即时沟通的一体化体验，适合已经形成文档协作文化的团队。它的管理后台把组织架构可见范围做成了可配置规则，管理员可以按成员、部门或用户组设置。

飞书的规则体系支持主规则和补充规则，规则之间有优先级，不可见规则优先于可见规则。管理员可以验证某个成员对另一个成员的权限结果，也可以把用户组应用到会话权限、搜索权限和文档权限等场景。对多业务线、多角色的组织来说，这种配置能覆盖较细的权限需求。

飞书的短板是规则数量一多，维护成本会上升，需要专人或固定流程做复核。它更适合公有云协作和跨组织连接场景，如果核心诉求是内网私有化和数据留在企业内，需要单独评估部署方案和边界。

钉钉

钉钉是阿里巴巴旗下的企业协同平台，组织管理、审批、考勤和开放接口体系比较完整，适合管理层级多、流程制度重的组织。它的通讯录权限不是单一开关，而是分散在通讯录查看权限、部门可见范围和成员资料显示设置几个入口。

钉钉支持分级管理员，管理员可以在后台设置成员的通讯录查看范围。开放接口可以获取管理员的通讯录权限范围，返回可管理的部门列表，便于和内部系统做权限校验。对集团和连锁型组织来说，这种分层管理比较贴合实际。

钉钉的短板是权限项分散，规则设计不清时容易出现管理员权限过大或字段暴露。它同样以公有云为主，涉及敏感数据驻留时，要评估部署方式和合规边界。

企业微信

企业微信是腾讯旗下的企业沟通平台，优势在和个人微信的客户连接，以及内部通讯、审批、文档等基础协作。它的通讯录管理后台把可见范围拆成了隐藏部门或成员、限制查看外部门、限制查看所有人三种操作，配置入口比较集中。

企业微信还支持字段级管理，可以对全员设置英文名、手机、座机、职务等字段的显示或隐藏，也可以对核心成员单独隐藏敏感信息。它还区分管理范围与通讯录权限范围，通讯录权限范围是管理范围的子集，避免管理员越界。对行政和人力资源团队来说，这种配置方式上手快，不需要写复杂规则。

企业微信的短板是字段级和项目级的细粒度授权需要结合组织结构和补充规则设计，复杂集团场景往往还要配合其他系统。它以公有云为主，数据驻留要求高的组织需要评估私有化方案和成本。

八、常见误区

误区一，全员可见看起来省事。 省掉的是配置时间，留下的是组织信息暴露、手机号被导出、外协人员看到全员架构的风险。通讯录权限不需要一次配到最细，但至少要先把敏感部门和敏感字段收起来。

误区二，只控部门不控字段。 员工能看到本部门同事，不代表应该看到对方的手机号、汇报关系和合同状态。部门可见和字段可见是两层，设计表里必须分开写。

误区三，项目群等于项目授权。 把外部人员拉进项目群，不等于给了他项目范围内的通讯录权限；反过来，项目授权也不应该顺带开放对方部门全员。项目群、通讯录、文件权限要分别配置。

误区四，调岗只改部门。 调岗后原部门群、原项目群、原文件权限往往还在。调岗流程应该同时触发原权限回收、新权限生效和历史群组处理，不能只改组织架构。

误区五，管理员不受约束。 能改组织架构的人、能看审计日志的人、能处理账号的人，权限应该分离。超级管理员数量要控制，管理动作要留日志。

误区六，只配置不审计。 权限配置完成不代表一直有效。组织调整、项目结束、人员离职都会改变权限关系，建议每季度做一次权限复核，每半年做一次全量审计。

九、常见问题解答

通讯录规则要不要向员工公开？ 建议公开规则框架，不公开具体名单。员工应该知道自己的哪些字段会被谁看到、哪些操作会触发审批，但不应该看到完整的权限矩阵和例外名单。公开规则能减少争议，隐藏名单能降低被试探的风险。

员工不愿意公开手机号怎么办？ 把手机号放到受限级，默认只对直接协作人和必要岗位开放。企业可以保留企业邮箱、座机或工号作为替代联系方式，员工个人手机号不作为全员默认字段。涉及客户服务或应急值班的岗位，再单独授权。

集团并购后两套通讯录怎么合并？ 先合并组织树，再合并字段和角色，最后合并项目群。合并期间建议保留两套命名空间，兄弟公司之间默认不可见，联合项目走单独授权。不要为了看起来统一，直接把两套通讯录全员打通。

项目负责人离职，项目权限谁来接管？ 项目负责人离职或调岗时，先由项目发起人指定临时接管人，再在三个工作日内完成权限转移。接管人只继承项目授权，不继承原负责人的部门权限。项目结束后，临时接管权限一并回收。

权限规则能不能按组织架构自动继承？ 可以继承，但要有边界。部门规则可以按组织树继承，成员级例外不应该自动继承。继承规则要设置优先级，显式规则高于继承规则，不可见规则高于可见规则。组织调整后，继承关系要重新计算，避免旧部门权限残留。

如何验证某个人到底能看到谁？ 不要只看配置页面，要用真实账号做模拟。分别检查通讯录列表、搜索、个人资料页、群成员列表和文件权限五个入口，确认结果一致。能提供权限验证工具的产品，优先用工具做交叉验证。

外部客户能不能通过通讯录找到对接人？ 可以，但只开放对接人名片，不开放组织架构。建议给外部客户提供项目接口人的单点联系入口，或者使用访客账号，只允许搜索指定对接人。外部客户不应看到公司全员通讯录、部门树和汇报关系。

通讯录权限能不能全部交给系统自动判断？ 常规规则可以自动化，例外授权不建议全部自动化。系统适合处理部门继承、字段分级、项目到期回收和离职停用，涉及高管跨域、敏感部门开放、外部人员加入的例外，仍然需要人工审批和留痕。

十、参考资料

• IBM《2026年数据泄露成本报告》，https://www.ibm.com/reports/data-breach
• Ponemon Institute与DTEX《2025内部风险成本报告》，https://www2.dtexsystems.com/l/464342/2025-02-19/583csx/464342/1740000012hNhGjMpn/2025_Cost_of_Insider_Risks_Global_Report_by_Ponemon_and_DTEX.pdf
• 企业微信通讯录管理帮助，https://open.work.weixin.qq.com/helpguide/detail?t=contact
• 飞书组织架构可见范围帮助，https://www.feishu.cn/hc/zh-CN/articles/360049067480
• 钉钉管理员通讯录权限范围文档，https://open.dingtalk.com/document/development/query-permissions-of-the-administrator-address-book
• 喧喧IM集团企业安全通讯方案，https://www.xuanim.com/column/group-enterprise-security-communication-plan-evaluation-multi-level-organization-cross-domain-communication-ba1-KnowledgeEncyclopedia