治理机制决定谁有权新增或合并类目，防止分类体系无序膨胀

概念解释

谁都能在 CMS 里「新建栏目」，树就会按部门政治和当周活动涨。治理指定：谁可以提议、谁可以批准新增或合并、依据是什么、多久评审一次。没有这套机制，分类膨胀不是内容增长的自然结果，是权限敞口的结果。治理要防的是无序的节点增殖，不是防一切变化——变化应走同一扇门进来。

「大家商量一下」不是治理。治理是可执行的权限与记录，事后能回答「这个类是谁在哪一天为什么加上的」。

机制

新增类目的局部收益很大（我的活动有入口了），全局成本被摊到所有查找者（多一个不可预测的邻居）。个人理性导致树膨胀。合并的收益是全局的，成本由失去专属入口的团队承担，于是合并几乎没人提。治理把这两类操作收到同一张桌面上，用同一套标准（体积、可辨识度、与现有维度是否重复）来批，而不是谁先建谁占坑。

权限若只锁新增、不锁改名和挪父，膨胀会改头换面：类还是那些类，归属关系被私下改乱。治理覆盖新增、合并、改名、改父、废弃。

怎么研究

把「谁能改树」当成变量，观察膨胀与可预测性。

• 范式：对比开放新建与审批制两个阶段的类目净增、重复率、树测试成功率；审计现有类目有多少写得出批准记录。访谈提议被拒的原因是否公开。
• 自变量：批准人角色、最小体积等硬规则、评审周期、是否允许紧急临时类及过期。
• 因变量：年净增类目数、无记录类目比例、同层近义类对数、找路成功率随时间的变化。
• 方法论注意点：膨胀在流量日志里可能显示为「导航更丰富」，要并用可预测性，而不是用点击分散当健康。治理研究要看被拒绝的提议，不只看通过的。缺少拒绝日志等于治理没有发生。

边界

个人工作区、草稿、团队私有空间可以有更松的局部类目，只要不泄漏进全局导航和官方筛选。紧急事件需要当日入口时，应有带过期时间的临时类通道，而不是为了速度永久开放新建。多品牌或多租户各有自己的树，治理发生在租户内；跨租户强行统一会把治理变成另一场无序合并。受控词表的责任人可以与导航治理是同一角色，但词表节点和导航节点的批准标准不同，不要共用一张「什么都能建」的表单。

怎么落地

• 写权限矩阵：提议、批准、实施、紧急临时类分别是谁；CMS 上关掉无审批的「新建栏目」。
• 新增/合并申请必须填写：对象体积或预期体积、与现有类的差别、要动哪些旧路径。
• 每次批准留下记录；临时类到期自动并回或下线。
• 验证：随机抽十个导航类，能否指出批准人和日期。指不出的类就是敞口留下的。再看近一年净增：若新增远多于合并且找路指标在掉，治理门没有在工作。

延伸

• 同组：G1.11.1 分类体系需要为未来新增内容预留位置，而非填满当前已知内容 · G1.11.2 过早为小类目单独设类，会在内容增长后失去意义 · G1.11.3 架构变更成本随外部链接、书签与用户心智模型的沉淀而上升 · G1.11.4 结构调整需要重定向旧路径，避免断链 · G1.11.6 类目使用量的失衡是触发重构的信号，不应仅凭直觉判断
• 相邻：G1.10 受控词表与同义词 · G1.07 内容清单与审计 · T3.04 内容策略与信息治理
• 站内检索：taxonomy governance · category minting · information architecture stewardship