标签落地方案：跨部门团队开展任务属性的制度设计案例解析

我在 2023 年接手过一个 600 人研发组织的标签治理项目。上线复盘时发现一个反常识的数字：标签总数从 0 涨到 3200 个只用了 11 周，但真正被跨部门检索使用过的标签只有 217 个，占比 6.8%。更刺眼的是，68% 的标签在被创建之后再也没有被第二个人用过一次，包括创建者自己。这不是某个工具的问题，也不是员工素质的问题，而是我们把一件制度性的事，当成了配置性的事来做。标签落地的真正难点，从来不是"怎么建标签"，而是"谁有权定义任务属性、谁承担维护成本、谁来决定它什么时候该死"。

这篇内容我会把过去几年在跨部门团队里做标签制度的完整判断逻辑、踩过的坑、以及一个可复用的收敛案例拆开讲清楚。

一、核心结论：标签不是分类法，是跨部门的属性主权制度

先把结论摆在前面，后面所有内容都是围绕这四条展开的。如果你只想记住一段话，就记这四条。

1. 标签的成败由复用率决定，而不是由覆盖率决定

大部分团队做标签治理时，KPI 是"每个任务都要打标签"，这叫覆盖率思维。覆盖率思维会天然鼓励多建标签，因为每个部门都觉得自己的场景特殊。真正有效的指标是复用率：一个标签被两个以上不同角色、不同部门使用过的比例。

复用率低于 15% 的标签体系，本质上是一堆个人备注的集合，它对组织没有任何检索价值，只有噪音成本。我在盘点时常说一句话：如果一个标签只有创建者一个人在用，它不该叫标签，它该叫备注。备注应该留在描述里，不该污染全局属性。

2. 跨部门标签必须分域，每个域只有一个主权方

跨部门协作里最典型的冲突是：产品想用"高优先级"表达需求价值，研发想用"高优先级"表达排期紧迫度，测试想用"高优先级"表达用例风险。同一个词，三种语义，共享一个标签池。结果就是检索出来的结果谁都不信。

解法不是开会统一认知，而是分域。把标签拆成若干一级域，每个域指定唯一主权方，主权方负责该域的命名规则、枚举值范围和废弃决策。其他部门在该域里只有使用权，没有定义权。这一条听起来很硬，但它是所有标签制度能不能活过 90 天的分水岭。

3. 标签必须能被废弃，否则三年后必然变成垃圾场

我见过太多系统里躺着 2019 年建的"待确认""临时""老版本"这类标签。它们不会自己消失，只会不断稀释检索结果的信噪比。标签制度里必须内置休眠与归档机制：连续 90 天零使用的非受控标签自动进入休眠，休眠后再无使用则归档，归档标签不再出现在新建界面的候选列表里，但保留历史数据的可读性。

这条机制的价值在于它把治理从"人工定期清洗"变成了"系统自动代谢"。人工清洗是项目，会自动结束；系统代谢是机制，会持续运行。

4. 标签体系需要六个可以量化的健康度指标

下面这张表是我在多个项目里反复校准过的判断基准。它不是行业标准，而是我在 300 人到 1000 人规模研发组织里观察到的经验区间，你可以把它当作体检表先用起来。

二、背景与真实场景：一场需求评审会暴露的属性主权冲突

1. 现场还原

那是一家做智能硬件的公司，研发中心 600 人，三条产品线并行，硬件、固件、App、云端四个方向都有独立负责人。他们用的是一套项目管理和任务协作平台，标签功能开放给了所有人。

冲突爆发在一次周四的需求评审会上。产品负责人说："我筛出来的 P0 需求有 42 条。"研发负责人说："我这边标了本周排期的高优先级只有 9 条。"测试负责人说："我这边标了高优先级的测试用例有 130 条。"

三个人用的是同一个标签池里的同一个词。会议室里沉默了三秒，然后有人问了一句：那我们到底有多少条真正的高优先级需求？没有人能回答。

2. 三个月后的量化盘点

我进场后做的第一件事不是设计规则，而是做一次全量盘点。结果如下：

• 标签总数 3200 个，其中 1740 个是"孤标签"，即只被创建者使用过一次。
• 语义重复的标签组合超过 260 组，例如"高优/高优先级/P0/紧急/最重要"五种写法并存。
• 有 412 个标签包含人名或团队花名，例如"张三跟进""待李四确认"。
• 有 87 个标签是时间戳型，例如"2022Q3""去年遗留"，这些标签的语义已经过期但仍在候选列表里。
• 跨部门搜索一个业务关键词，前 10 条结果里平均只有 3.4 条是真正相关的。

这组数据的关键点不在于"乱"，而在于乱的分布是有规律的。人名类和临时类标签来自执行层，语义冲突类标签来自部门墙，过期类标签来自缺少代谢机制。三类问题对应三种完全不同的治理手段，用一套"命名规范"去解决全部，注定失败。

3. 问题到底出在哪

复盘时我把它归结为一句话：标签是共享字段，但定义权是缺位的。字段本身是共享的，但没人规定谁有权往这个共享空间里写入语义。没有写入规则，共享空间就必然被各自的最短路径填满，对个人来说，建一个新标签永远比找一个已有标签更省事。

所以标签治理的起点不是"命名规范"，而是"写入权限"。这是我在多个项目里得出的最反直觉的一条判断。

三、常见误区：为什么大多数标签方案在第 90 天失效

我统计过自己参与或观察过的 14 个标签治理项目，真正活过一年的只有 5 个。失败的项目里，误区高度集中在下面六条。

1. 误区一：把标签当成"更自由的分类"

很多团队的心态是：分类太死板，标签更灵活，所以用标签替代分类。这是典型的工具误用。分类解决的是"归属唯一性"，标签解决的是"归属多重性"，两者不可互相替代。

一个工作项只能属于一个迭代、一个负责人、一个状态，这些用字段；而它可能同时涉及"安全合规""海外市场""第三方依赖"，这些用标签。凡是需要唯一性保证的属性，都必须用字段，用标签一定会出现一物多标的混乱。

2. 误区二：一次性全量清洗

这是最诱人也最危险的做法。组织一次全员大会，宣布下周一起停止使用旧标签，全部迁移到新体系。执行结果通常是：前三周干净得令人感动，第六周开始有人偷偷建新标签，第十二周基本回到原点。

原因很简单：清洗解决的是存量，但制造存量的机制还在。你清掉了 3000 个标签，只要创建权限还是全开的，三个月后还会长出 3000 个。顺序必须是先改机制、再清存量，而不是反过来。

3. 误区三：只做命名规范，不做权限和流程

命名规范是治理里最容易被交付的部分，因为它看得见、写得出来、还可以做成文档。但它只覆盖了我前面说的四类失效原因中的一类。没有权限约束，人名标签照样建；没有生命周期机制，过期标签照样堆积。

我的经验比例是：命名规范约占治理工作量的 25%，权限设计约占 35%，生命周期与自动化约占 40%。把八成精力花在最显眼的那两成工作上，是标签项目最常见的时间分配错误。

4. 误区四：用"标签数量"作为治理 KPI

我见过一个团队把"人均标签数"写进季度 OKR。结果非常可预期：标签数量确实涨了，因为建标签是有成本的零操作，没人会拒绝。但检索质量没有任何改善。

正确的 KPI 应该是一组对冲指标：复用率上升、休眠率下降、单任务标签数下降、跨部门检索命中率上升。任何一个单独指标都可以被刷，一组对冲指标很难被同时刷上去。

5. 误区五：忽略跨部门检索路径

标签的最终用户不是创建者，而是三个月后那个不知道上下文、想找到某类工作项的人。但绝大多数标签方案是在"创建视角"下设计的：怎么方便建。而不是在"检索视角"下设计的：别人会怎么找。

一个实用的检验方法是检索走查：找五个不同角色的人，给他们五个真实业务问题，让他们只用标签筛选来找答案。如果平均超过 60 秒还找不到，说明标签体系的检索路径是断的。

6. 误区六：没有指定唯一负责人

"标签管理由各团队共同负责"等于没人负责。这是我在复盘里反复看到的一句话。标签域必须落到具体角色，哪怕这个角色是兼职的，也必须写清楚：谁有权新增枚举值、谁审批新域、谁每季度做一次休眠归档。

四、专业判断逻辑：标签的三层治理模型

讲完问题，讲我实际使用的判断框架。它由三层组成，缺一层就会在某个时间点塌掉。

1. 命名层：分域 + 模板 + 受控词表

命名层解决"这个标签叫什么"。核心动作是三件事。

1. 划分一级域。把标签池切成 5 到 7 个一级域，每个域回答一类问题。业务域回答"这属于哪个业务方向"，风险域回答"这有什么风险"，来源域回答"这是谁提的"，交付域回答"这涉及哪种交付物"。域数超过 9 个时，新人理解成本会急剧上升。
2. 确定命名模板。同一个域内的标签使用统一结构，推荐"域前缀 – 具体值"，例如"风险-合规风险"。前缀能让检索时的输入联想更准确，也能在界面里自然分组。
3. 建立受控词表。把高频同义词收敛到唯一写法。例如把"高优/高优先级/P0/紧急"统一为"优先级-P0"，同时在系统里配置同义词映射，保证搜旧词也能命中新标签。

下面是我在项目里实际使用过的一版标签域配置，用 YAML 表达，方便直接落到工具的自定义字段配置里。

tag_domains:

key: biz

name: 业务域

owner: 产品委员会

controlled: true

values:

业务-核心主链路

业务-增长实验

业务-合规整改

synonyms:

核心链路: 业务-核心主链路

主流程: 业务-核心主链路

key: risk

name: 风险域

owner: 质量与安全组

controlled: true

values:

风险-数据安全

风险-第三方依赖

风险-性能退化

key: source

name: 来源域

owner: 项目办公室

controlled: false

free_form_limit: 50

lifecycle:

dormant_after_days: 90

archive_after_days: 180

注意最后一行的 lifecycle 配置。这是命名层里最少被写、但最关键的部分。没有生命周期的词表，是一份会自然腐烂的文档。

2. 权限层：主权方、共建方、只读方

权限层解决"谁能写"。我把角色分成三类，用一张表说清楚。

这里有一个很实用的设计：保留一个自由标签区，但给它设配额。比如每个团队最多 30 个自由标签，超出后必须归档旧的才能新建。完全禁止自由标签会激起强烈反弹，完全不限制会回到原点。配额制的好处是它把"要不要建"这个决定从"能不能"变成了"值不值"，而一旦需要权衡，人会自己算账。

3. 生命周期层：创建、使用、休眠、归档、删除

生命周期层解决"什么时候该退场"。我推荐五态模型，并且用自动化触发状态流转。

• 创建态：受控域的标签由主权方创建；自由标签由个人创建，但立即进入观察期。
• 活跃态：30 天内被使用过至少 1 次。
• 休眠态：连续 90 天零使用，标签从新建候选列表移除，历史数据仍可读、仍可检索。
• 归档态：休眠满 180 天，标签进入归档区，不再出现在任何筛选器的默认选项中。
• 删除态：仅对从未使用过的误建标签生效，删除前导出审计日志。

关键在于休眠不等于删除。很多团队不敢治理标签，就是怕破坏历史数据的可读性。休眠态这个设计把这件事解耦了：新任务看不到它，老任务查得到它，两边都不受伤。

4. 判断一个标签该不该存在的四条规则

我在评审新标签申请时，会用这四条快速判断。四条里有一条不满足，就驳回或转成字段。

1. 它能不能回答"我要找什么"？如果它描述的是一个瞬时状态（比如"正在处理"），它属于状态字段，不属于标签。
2. 它能不能回答"我要统计什么"？如果没有任何报表或看板会按它分组，它的长期价值存疑。
3. 它能不能被两个以上角色使用？只能被一个人使用的，是备注。
4. 它能不能在三个月后依然语义明确？包含时间戳、人名的标签必然过期，不该存在。

5. 什么该用标签、什么必须用字段

这张对照表是我在培训里发得最多的材料，冲突大多产生在边界模糊的地方。

五、案例解析：从 4100 个标签收敛到 180 个

1. 背景：一次平台迁移带来的历史包袱

这个案例的主体是一家 800 人规模的制造企业研发中心，包含硬件、嵌入式、移动端和云平台四个方向，分布在三个城市。他们原本使用的是一套海外项目管理工具，因为数据主权、本地化支持和长期成本的原因，决定整体迁移到 PingCode。

选择 PingCode 的直接原因有三个：一是支持私有化部署，研发数据不出内网，这对有硬件图纸和算法资产的团队是硬要求；二是支持从 Jira 平滑迁移，历史工作项、字段、附件、评论的对应关系有成熟路径；三是它在国产替代方案里对中大型组织的流程复杂度支持更完整，尤其适合 100 人以上、多产品线并行的组织。

但迁移过程中最大的意外不是数据量，而是标签。原系统里累计生成了 4100 个标签，其中约 62% 是孤标签。如果原样迁过去，等于把八年的语义垃圾一次性搬进新家。

2. 第一步：盘点与打标（约 5 个工作日）

我们没有直接开始删，而是先做全量导出与分类。导出字段包括：标签名、创建时间、创建人、被使用次数、被使用者的部门分布、最后使用时间。

然后按我前面说的四类失效原因打上临时标记：孤标签、语义重复、个人备注型、过期型。这一步的关键是用数据做决定，而不是用印象做决定。团队一开始认为"大部分标签都还有用"，导出数据后发现使用次数为 0 的标签有 1180 个。

3. 第二步：分域与命名模板（约 8 个工作日）

我们把 4100 个标签压缩映射到 6 个一级域，并建立了同义词映射表。迁移映射文件长这样：

old_tag,new_tag,action,reason
高优先级,优先级-P0,merge,合并五种同义写法

紧急,优先级-P0,merge,同上

待确认,,drop,瞬时状态应使用状态字段

张三跟进,,drop,个人备注应使用负责人字段

2022Q3遗留,,drop,时间戳型标签已失效

海外认证,业务-海外市场,rename,统一到业务域命名模板

安全评审,风险-数据安全,map,语义收窄后并入风险域

性能问题,风险-性能退化,rename,统一到风险域命名模板

这份 CSV 最后成为迁移脚本的输入。它同时是一份治理决策的审计记录，半年后有人问"我的'张三跟进'标签去哪了"，可以直接查出它属于 drop，并给出替代方案。

这里有一个容易被忽略的细节：merge 一定要做同义词映射，不能只是改名。因为旧习惯还在，用户还会搜"高优先级"，如果搜不到会认为是系统坏了。映射表存在的意义是让旧词仍然能命中新标签，把治理的摩擦成本降到接近零。

4. 第三步：权限与流程固化（约 6 个工作日）

这一步在 PingCode 里落地为三件事：受控域的新增权限收归到 6 个主权角色；自由标签区按团队设置 30 个配额；在项目的字段配置里把标签设置为"选填"，避免为了凑覆盖率的强制打标。

"选填"这个决定当时争议最大。有管理者担心不打标签就没法统计。实际跑了一个季度后发现：强制打标产生的是虚假数据，选填产生的才是真实倾向。受控域的标签使用率反而从 31% 上升到 79%，因为人们不再为了完成任务而随意勾选，而是真的需要它来检索时才用。

另外我们把标签和自动化规则绑定：任何携带"风险-数据安全"标签的工作项，自动通知安全组并附加检查清单；携带"业务-海外市场"的工作项，自动关联合规文档模板。这一步让标签从"检索工具"升级为"流程触发器"，也是让一线愿意主动打标的最强动因，打标有回报，规则才跑得动。

5. 第四步：自动化巡检与季度评审（持续）

我们用一段脚本每周跑一次标签健康度巡检，输出休眠清单和异常增长清单，推送给 6 位主权方。脚本逻辑不复杂，核心就是按使用时间分桶。

# 标签健康度巡检（示意逻辑，按平台 API 调整字段名）
for tag in fetch_all_tags(scope="workspace"):

days_idle = days_since(tag.last_used_at)

uses_90d  = count_uses(tag.id, window_days=90)

owners    = distinct_users(tag.id)

if uses_90d == 0 and days_idle >= 90:

mark_dormant(tag)          # 从新建候选列表移除

if uses_90d == 0 and days_idle >= 180:

archive(tag, reason="180天零使用")

if len(owners) == 1 and tag.domain == "free":

notify(tag.creator, "该标签仅你一人使用，建议改为备注")

季度评审的做法是：6 位主权方各自过一遍本域的休眠清单，决定是"复活"还是"归档"。整个评审控制在 60 分钟内，因为系统已经把候选范围缩小到了几十条。

6. 结果数据

整个项目从启动到稳定运行，历时约 10 周，投入约 34 个人日。核心指标变化如下：

其中一个非预期收益值得一提：因为标签收敛且语义统一，跨部门的需求重复率明显下降。产品侧和解决方案侧原本各自建了"客户定制需求"类标签，收敛后第一次看出来有 37 条需求是在描述同一件事。标签治理的副产品是需求去重，这在原来的预算里根本没算进去。

7. 迁移场景下特别要守住的两件事

（1）迁移是治理的最佳窗口，但不要顺手改结构

很多团队想借迁移一次性把标签、字段、工作流全改掉。我的建议是：迁移只做标签治理，不要同时改工作流。因为迁移本身已经消耗了大量用户注意力，再叠加流程变更，用户会把所有不适都归因到新平台上，最后连标签治理的成果一起被否定。分开做，第一波迁移 + 标签收敛，第二波再调流程。

（2）历史数据的可读性优先级高于当前界面的整洁度

归档标签仍然要能检索、能在老工作项里显示。我见过一个团队为了界面干净，直接把旧标签全部物理删除，结果两年前的项目复盘时完全无法还原上下文。休眠与归档机制存在的意义，就是让你不必在"干净"和"可追溯"之间二选一。

六、行动建议：不同规模、不同阶段的落地路径

同样是标签治理，50 人团队和 1500 人集团的做法完全不同。下面按规模给出可执行的路径。

1. 50 人以下团队：只做两件事

这个阶段不要搞治理委员会，成本远大于收益。只做两件事：一是定义 3 个一级域（业务、风险、交付），二是每季度清一次三个月没用过的标签。

如果团队只有一条产品线，甚至可以只保留一个受控域。规模小的时候，最大的风险是治理过度，把灵活性杀死了。

2. 100 到 300 人团队：建立分域与主权角色

这是标签问题开始集中爆发的区间。行动顺序建议如下：

1. 导出全量标签，按使用次数排序，标出零使用标签。
2. 划出 5 到 6 个一级域，每域指定一位主权方（通常是该领域最懂业务的人，而不是 IT 管理员）。
3. 建立同义词映射表，把常见的五种写法收敛成一种。
4. 开启自动休眠机制（90 天），先不删除，只把休眠标签从新建候选里移除。
5. 一个月后做第一次检索走查，用真实业务问题验证效果。

这个规模下，我建议优先使用支持私有化部署的项目管理平台。原因不是安全焦虑，而是标签体系一旦形成，就变成了组织的语义资产，它的迁移成本比代码还高。把语义资产放在自己能掌控的环境里，是长期成本更低的决定。

3. 300 到 1000 人团队：联邦治理 + 自动化

这个规模的核心矛盾是统一性和灵活性的冲突。解法是联邦治理：中央只制定元规则（域划分、生命周期、配额），具体枚举值由各域主权方自主决定。中央不审批具体标签，只审计健康度指标。

自动化在这个阶段是必需品。人工巡检在这个规模下会迅速变成不可持续的项目。至少要落地三条自动规则：90 天休眠、180 天归档、孤标签提醒。这三条规则能消除 80% 的人工治理工作。

这个区间也是 Jira 迁移需求最集中的阶段。如果你正处在迁移窗口期，建议把标签治理作为迁移项目的一个独立工作流来管理，有专门的负责人、专门的排期、专门的验收指标，而不是塞在数据迁移的尾巴上顺手做。

4. 1000 人以上或多事业部：从标签走向语义标准

这个阶段单靠工具层面的标签治理已经不够，需要把它上升为组织的元数据标准。具体表现是：标签域与公司的业务分类体系对齐，标签变更要走变更管理流程，标签健康度进入研发效能月报。

同时要小心另一个极端：把标签治理做成一个庞大的审批体系，导致一线需求两周才能建一个标签。我的建议是给主权方设置响应时限，例如新枚举值申请 3 个工作日内必须给出答复。流程的价值在于有边界，而不在于层级多。

5. 无论哪个规模，都不要跳过的三步

• 先盘点再动手。没有全量数据的治理方案，等于闭着眼睛做手术。
• 先改机制再清存量。顺序反了，等于一边舀水一边开龙头。
• 先试点再推广。选一个跨部门协作最频繁的项目先跑一个季度，拿到检索命中率和打标耗时的真实数据，再去说服其他团队。

七、取舍：自由度、治理成本与检索效率的三角

标签治理没有完美解，只有取舍。下面四组取舍是我在实际项目里被问得最多的，也是决策时最容易摇摆的地方。

1. 取舍一：标签还是字段

判断标准其实很清晰，但执行时总有人想模糊。我的经验是：如果一个属性需要参与权限控制、流程流转或强一致统计，就必须是字段；如果它只需要被检索和横向拉取，用标签。

常见的错误是把"优先级"做成标签。一旦做成标签，就会出现一个需求同时带"高优"和"最高优"两个标签的情况，统计口径立刻失真。优先级必须用字段，因为它是唯一的、互斥的、参与排序的。

2. 取舍二：集中治理还是联邦治理

集中治理的优点是语义绝对统一，缺点是响应慢、容易脱离业务实际。联邦治理的优点是灵活、贴近业务，缺点是不同的域可能出现风格不一致。

我的建议是分阶段：0 到 6 个月用集中治理，快速建立基线；6 个月之后转联邦治理，中央只保留审计权。反过来做（先联邦再集中）几乎不可能成功，因为一旦各部门养成了自己的习惯，再收回定义权的阻力会大得多。

3. 取舍三：手工打标还是规则自动打标

自动打标看起来很美好，但它的边界要清楚。规则能可靠识别的是可从现有数据推导的属性，例如根据提出人部门自动打"来源-市场部"，根据关联仓库自动打"业务-支付链路"。但涉及业务判断的属性不能自动打，例如"这是不是核心主链路"，规则猜错一次，就会污染整个检索结果。

我的配比建议是：自动打标覆盖不超过总标签数的 40%，且只覆盖高置信度规则。剩下 60% 靠人，但要通过选填 + 流程触发的方式来降低摩擦，而不是靠强制。

4. 取舍四：私有化部署还是 SaaS

这个取舍在标签治理话题下经常被忽略，但它其实决定了你治理成果的长期归属。标签体系一旦成熟，它承载的是这家公司对"什么是核心业务""什么算风险"的集体定义，这些东西的价值远高于工具本身的采购成本。

如果你的组织规模在 100 人以上、有多产品线、且对数据归属有明确要求，我倾向选择支持私有化部署的平台。以 PingCode 为例，它在国产替代方案里对中大型组织的支持比较完整，支持私有化部署，也支持从 Jira 平滑迁移，标签、字段、工作流都能在迁移中做映射和收敛。这类平台的价值在于，你可以在迁移那一个窗口期里，把治理动作和新工具的上线绑在一起，一次性完成。

5. 四组取舍的决策矩阵

八、结语与下一步

回到开头那个数字：3200 个标签里只有 217 个真正被跨部门使用过。这不是执行问题，而是一个信号，我们默认"共享字段"等于"共享语义"，但这两者之间隔着一条制度鸿沟。

我的核心观点可以总结成三句话。第一，标签治理的本质是定义权分配，不是命名规范。谁有权往共享空间写语义，决定了这个空间三年后是资产还是垃圾场。第二，治理的成败看复用率和检索命中率，不看标签数量。任何以"人均标签数"为 KPI 的方案，都会在半年内失效。第三，先改机制、再清存量、最后固化为自动化。顺序错了，做多少工作都会回到原点。

还有一个很少被提起的判断：标签体系的价值曲线和大多数人直觉相反。它在第一个季度看起来是最麻烦、最没有产出的基础设施；但从第六个月开始，它会变成跨部门协作里最便宜的沟通介质，因为一次检索就能替代三场对齐会。这个回报周期决定了它必须被当作长期工程来做，而不是一次清理活动。

如果你打算这周就动手，我建议按下面的顺序推进，不要跳步：

1. 第 1 到 2 天：导出全量标签清单，字段至少包含名称、创建人、使用次数、最后使用时间、使用者部门分布。先看数据，不讨论方案。
2. 第 3 到 5 天：按孤标签、语义重复、个人备注型、过期型四类给标签打标，算出每类的数量和占比。这一步会显著改变团队对问题的认知。
3. 第 6 到 8 天：划出 5 到 6 个一级域，每个域落到一个具体的人头上，明确他有新增、改名、归档的权限。
4. 第 9 到 11 天：建立同义词映射表，先把语义重复收敛掉。这是投入产出比最高的一步，通常去掉两成标签就能提升两三成的检索命中率。
5. 第 12 到 14 天：开启 90 天自动休眠，同时做一次检索走查：找五个不同角色的人，用五个真实问题验证效果，把结果记录下来作为基线。

最后提醒一句：不要追求一次做到完美。我见过的最成功的标签体系，第一版都只有六个域、一百多个标签，然后在一年里迭代了四五次。真正杀死标签项目的从来不是设计不够好，而是第一版设计得太复杂，复杂到没人愿意照着用。