一个 180 人的 SaaS 团队，任务池里挂着 137 个标签，其中 61 个只被使用过一次。这是我做过的一次研发效能诊断里，打开系统后看到的第一屏数据。团队的产品负责人很委屈：命名规范写在 wiki 上，标签也不是随便建的，为什么还是乱成一团？我的判断是，问题不在规范本身，而在于标签这个属性天生缺少约束，它既能当分类用，又能当状态用，还能当备注用。当同一个字段同时承担三种语义时，任何治理动作都会失效。
这篇内容拆解的就是产品经理如何把"任务属性"从一个自由填写的输入框，变成一套能执行、能度量、能交接的落地方案。我不会给你一套放之四海皆准的标签树，因为那东西在你团队里大概率活不过三个月。我会给你的是判断逻辑、收敛路径、真实数据和我踩过的坑。
一、核心结论：标签不是分类法，而是决策压缩器
先把结论摆出来，后面再展开论证。任务属性方案做得好不好，不看标签设计得多优雅，只看一件事：它有没有让某个具体的人在做某个具体决策时，少问一句话、少开一次会、少翻一次聊天记录。
如果一套标签体系上线三个月后，没有任何一个报表、自动化规则或筛选视图依赖它，那它本质上就是装饰品。装饰品的成本不是零，它会持续消耗检索效率、增加新人理解负担，并且在季度复盘时污染统计口径。
1. 结论一：标签数量与检索效率是倒 U 型关系，不是线性关系
很多产品经理的直觉是"标签多一点没关系，反正能筛"。实际观察恰好相反。标签数量从 20 涨到 60，检索效率是提升的；从 60 涨到 110，开始持平；超过 130 之后，筛选行为本身就变成了负担。
原因很朴素：用户在执行筛选时，需要在脑子里先完成一次"标签的心理映射"。可选标签越多，这次映射的耗时越长，出错的概率越高。我做过一个粗糙但有效的测量，在同一个任务库中执行一次"关键词 + 标签"组合筛选，记录从打开筛选面板到关闭面板的中位耗时，以及未完成筛选就关闭的会话占比。
2. 结论二：只有能被自动写入的标签才有生命力
我问过十几个团队同一个问题：你们最有价值的三个标签是什么？答案高度集中在"客户反馈""线上问题""合规相关"这类和流程强绑定的标签上。这些标签的共同点是，它们不需要人手动打，而是由流程节点、来源渠道或字段联动自动写入。
反过来，那些依赖人工判断的标签，比如"复杂度高""设计感强""需要关注"，三个月后的使用率通常跌破 15%。这不是团队不认真，而是人工打标这个动作本身没有即时收益。打标的人得不到反馈，不打标的人也不承担后果，理性选择就是不填。
3. 结论三：标签方案的真正对手是"字段选型"
很多人把标签当成万能容器。我的经验是，一个任务属性该用标签还是该用结构化字段，决定了这套方案能活多久。字段有约束、有权限、有校验；标签只有自由。凡是需要参与统计、需要触发规则、需要控制权限的属性，都不该做成标签。
换句话说，标签方案的落地过程，本质是一次属性治理，其中 60% 的工作量在于把错误的标签"升级"为字段，剩下 40% 才是设计标签本身。
二、背景与真实场景：三个翻车现场
抽象结论容易讲，落地难点都在细节里。下面三个场景是我在过去几年里亲自参与或深度复盘过的，它们分别代表了三种典型的失败路径：导入污染、语义争夺、报表失效。
1. 场景一：批量导入带来的标签污染
某团队从 Excel 迁移到专业项目管理工具时，为了"保留历史信息"，把表格里所有填写过的分类列都映射成了标签。迁移脚本跑完很成功，任务一条没丢。问题出现在两周后，批量导入把 Excel 里的自由文本原样带了过来。
同一个含义出现了七种写法：客户A、客户 A、客户a、KA客户、大客户、战略客户、重点客户。筛选时选任意一个都只能命中一部分任务，报表里客户端统计直接失真。
这件事给我的教训很直接：数据迁移不只是字段搬运，它是一次语义清洗的机会，错过就要用两倍成本补回来。迁移前不做标签映射表，系统上线就是你麻烦的开始。
2. 场景二：两个事业部对同一个标签的语义争夺
另一个团队有两个事业部共用一个任务平台。A 事业部把"紧急"定义为"影响付费客户"，B 事业部把"紧急"定义为"影响本季度 OKR"。双方都觉得自己用得没错，于是同一个标签在系统里承载了两套完全不同的优先级语义。
结果是每周例会上为了"到底有多少紧急任务"扯皮二十分钟。后来我建议把"紧急"降级为字段级的优先级枚举，并在字段上绑定业务线维度，冲突才消失。标签不适合承担这种有明确业务口径的属性，因为它没有互斥性，也没有默认值。
3. 场景三：季度复盘时标签撑不起任何一张报表
最隐蔽的一种失败：标签看起来用得不错，任务卡上花花绿绿。等到季度复盘要出"各产品线需求交付周期"时，发现标签根本无法聚合，因为标签可以多选、可以为空、可以改名，任何基于标签的统计都站不住脚。
这时候团队通常已经积累了三个月的数据，重做等于推倒重来。我后来把这条写进了自己的检查清单：凡是三个月后要被用来做趋势分析的属性，必须在设计阶段就做成必填字段，而不是可选标签。
三、拆解四类常见误区
误区之所以顽固，是因为它们在短期内都"看起来有效"。下面四条我按发生频率排序，每一条都附上了我观察到的典型症状和替代做法。
1. 误区一：把标签当成状态的替代品
症状是任务卡上出现"待评审""开发中""已上线""已验收"这类标签，而系统里的状态字段被闲置。这样做的问题在于，状态需要流转记录、需要看板泳道、需要触发自动化规则，而标签不提供这些能力。
更麻烦的是状态是有唯一性的，标签没有。一个任务理论上可以同时挂着"开发中"和"已上线"，看板上就会出现自相矛盾的卡片。状态类属性必须走状态机，标签只用来补充状态机表达不了的信息。
2. 误区二：开放创建权限换取推广速度
这是最政治正确的错误。"先让大家用起来，后面再治理"，这句话我听过至少二十次，但真正完成治理的团队不到三成。开放创建权限换来的是短期活跃度，代价是长期的语义碎片化。
我的建议是做分级权限：一线成员可以给任务打已有标签，但不能新建标签；新建标签需要一个短的申请动作，说明用途和预期使用频次。这个门槛低到不会阻碍推广，却能把一次性标签的数量压掉一半以上。
3. 误区三：用标签替代结构化字段
典型的例子是把"所属产品线""归属客户""迭代周期"做成标签。这些属性的共同点是可枚举、有权限边界、需要参与统计。做成标签后，筛选会漏、报表会错、权限会失控。
判断办法很简单：如果这个属性在图表里要当一个维度（比如按产品线分组），它就该是字段；如果它只是用来辅助搜索和提醒，标签更合适。
4. 误区四：一次性设计完整的标签树
有些团队花两周时间设计出一棵三层标签树，覆盖业务、技术、客户、风险四大域，一共两百多个标签。上线当天很漂亮，第二个月开始没人维护，第三个月一半标签无人使用。
标签体系和代码架构一样，需要的是可演进的最小内核，而不是一次性完整设计。我的做法是从 12 到 20 个标签起步，只覆盖三类场景：跨团队检索、自动化触发、风险标记。其余需求等出现第三次之后再讨论要不要加。
四、专业判断逻辑：一个属性该不该做成标签
前面讲了什么不该做，现在讲判断方法。我总结了一套四问法，配合三层结构和一个治理闭环，这套东西在我参与过的七个团队里跑过，收敛效果稳定。
1. 四个判定问题决定属性归宿
拿到一个待定属性，依次问四个问题。第一，它是否需要唯一性，一个任务能否同时具备多个取值？第二，它是否可枚举，候选值能不能在建设阶段就穷举出来？第三，它是否参与统计，三个月后会不会有人拿它做分组或趋势？第四，它是否需要权限控制，不同角色能否看到不同的取值？
四个问题的组合决定归宿。需要唯一性、可穷举、参与统计、需权限控制的，一律做字段；四个问题都不满足的，才考虑标签。中间地带最考验判断，比如"风险等级"，通常做字段更好，因为它要参与统计且最好有唯一值。
2. 标签的三层结构：域、族、值
决定用标签之后，结构比命名更重要。我固定在用三层：域是粗粒度的管理边界，族是同一类信息的集合，值是具体标签。举例如下。
domain: customer # 域：客户相关
family: customer-tier # 族：客户分层
values: [KA客户, 成长客户, 中小客户]
family: customer-source # 族：客户来源
values: [售前反馈, 售后工单, 客户拜访]
domain: risk # 域：风险相关
family: risk-type # 族：风险类型
values: [合规风险, 技术债, 交付风险]
三层结构的好处是可以在域和族上做权限和统计，而不必限制具体的值。比如"客户相关"这个域可以只对销售和产品开放，域级别的筛选也能在报表里作为粗维度使用。
3. 命名与编码规范要能机器校验
我见过太多规范写得很漂亮但没人执行，因为规范只写给人看，没写成机器能检查的规则。我的做法是把命名规则固化成可校验的约束。
- 标签名统一 2 到 6 个汉字，禁止包含空格、括号和英文缩写混排。
- 同一个族内不允许出现同义标签，同义判断由季度评审会裁定。
- 标签名不得包含状态词、时间词和人员姓名，这三类是污染的主要来源。
- 标签不得以数字开头，避免排序时出现不可预期的位置。
这四条规则可以直接用于批量扫描存量标签。我用这套规则扫过一个 143 个标签的库，一次性识别出 38 个违规标签，占 27%。这个比例说明大多数团队的问题不是不知道怎么规范，而是从来没有一个执行检查的动作。
4. 治理机制：谁建、谁删、多久审一次
没有治理机制的标签体系，平均生命周期是四到六个月。治理机制不用复杂，三个要点就够：新建要走申请、删除要有兜底、评审要有节奏。
新建申请的关键不是审批，而是让申请人填写"预期使用频次"和"替代方案"。这一条能挡掉大部分冲动型标签。删除方面，我的做法是先归档不删除，观察一个季度，确认无引用后再物理清除。评审节奏建议季度一次，每次只处理两件事：使用频次低于三次的标签，以及出现语义冲突的标签。
五、落地案例：180 人团队从 137 个标签收敛到 28 个
这一节讲一个完整的实施过程。对象是一家 180 人规模的 B 端软件公司，研发加产品约 110 人，销售和客户成功约 50 人，共用一个任务平台。项目周期八周，我作为外部顾问参与其中。他们最后用的平台是 PingCode，选它的核心原因是需要私有化部署，并且要能把原有 Jira 上的任务历史平滑迁过来。
1. 第 0 到 2 周：盘点、量化、排序
第一件事不是设计，是盘点。我导出了全部标签及其使用频次、创建时间、创建人、最近一次使用时间，然后按频次从高到低排序。结果很有代表性：
- 使用超过 100 次的标签：9 个，占 6.6%，覆盖了绝大多数真实检索场景。
- 使用 10 到 100 次的标签：31 个，占 22.6%，其中一半语义重叠。
- 使用 1 到 9 次的标签：36 个，占 26.3%，是治理的主要候选对象。
- 从未被使用的标签：61 个，占 44.5%，全部为创建后即弃。
这个分布几乎是我见过的通用形态：不到 7% 的标签承担了绝大部分价值，接近一半的标签是纯噪声。盘点的意义在于，它把"要不要治理"从主观判断变成了一道算术题。
2. 第 3 到 4 周：语义合并与字段升级
合并这一步最容易引发部门摩擦，所以我把裁决标准前置了：以使用频次高者为基准名，以业务口径清晰者为优先保留项。凡是两个部门无法达成一致的，就不合并，而是各自归属到不同的族里，用族的权限区分可见范围。
字段升级是我认为最有杠杆的一步。他们把"产品线""归属客户""迭代周期"从标签改成必填字段，并设定了默认值。改完之后，季度报表第一次能自动出来，不再需要人工整理 Excel。这一步的代价是迁移期有大约三天的数据回填工作量，收益是后续每个季度的报表人天从约 16 人天降到 2 人天以内。
3. 第 5 到 6 周：权限收紧与自动打标
权限方面，他们把标签创建权限从"全员"改为"产品经理 + 技术负责人"，一线成员可以打已有标签但不能新建。这一条刚推的时候有阻力，两周后基本无人抱怨，因为申请通道足够快。
自动打标是让标签重新产生生命力的关键。他们设置了三类自动规则：从客户工单转过来的任务自动带来源标签，从缺陷跟踪系统同步过来的自动带风险类型标签，跨越两个迭代未完成的任务自动带滞留标记。这三类标签的覆盖率从人工时代的不足 20% 提升到 90% 以上。
4. 第 7 到 8 周：存量迁移与灰度验证
存量迁移建议分批。他们第一批只迁移最近三个月的活跃任务，覆盖 62% 的日常检索量；三个月前的历史任务保持只读，标签不再强行改写。这样做避免了在海量历史数据上做高风险批量操作。
平台选择在这一步体现出实际差异。团队选用的 PingCode 支持私有化部署，数据留在自己的服务器上，安全团队没有额外阻力；同时它支持从 Jira 平滑迁移，历史任务的字段映射和标签映射可以在迁移过程中一次性完成，省掉了自建脚本反复调试的时间。对于 100 人以上的中大型组织，这种迁移能力往往比功能清单上的几十个特性更值钱。
六、不同规模团队的行动建议
同一套方法在 30 人和 800 人的组织里，优先级完全不同。下面按三个规模档位给建议，你可以直接对号入座。
1. 20 到 50 人：先约束，后建设
这个阶段最大的风险是过早引入复杂性。我的建议是标签总量控制在 15 个以内，创建权限收到团队负责人一级，全部标签只服务于两个目的：跨项目检索和风险标记。
不要在这个阶段做标签树、做域权限、做自动打标。人少的时候，一句话能解决的事不要用系统解决。等出现第三次"我们找不到某类任务"的情况，再考虑加标签。
2. 100 到 500 人：字段优先，标签补位
这是最需要系统化设计的档位，也是我在案例中讲的那家公司所处的区间。这个阶段的关键动作是先把所有要参与统计的属性字段化，再用标签处理剩余的表达需求。
同时要考虑部署形态。中大型企业通常有数据合规要求，支持私有化部署的平台会成为硬门槛。PingCode 主要服务中大型企业及 100 人以上组织，支持私有化部署，这一点在这个规模档位上是实打实的加分项。
3. 500 人以上：平台化治理与多租户隔离
超过 500 人之后，标签治理不再是单点问题，而是平台能力问题。你需要的是标签的域级权限、跨组织隔离、审计日志和批量治理接口。这个阶段人工评审会已经不够用了，必须靠规则引擎和定期扫描。
我的建议是设立一个虚拟的"任务模型委员会"，由产品运营、研发效能和数据团队各出一人，每季度审一次存量标签和字段。没有固定的责任主体，治理动作一定会在两个季度内停摆。
七、取舍：四种代价你必须提前认账
任何方案都有代价，把代价说清楚比把收益说漂亮更有价值。下面四条是我在复盘时反复遇到的取舍，每一条都没有标准答案，只有适用条件。
1. 灵活性与一致性的取舍
放开标签创建，灵活度上升，一致性下降；收紧创建权限，一致性上升，一线成员会觉得"想标记点什么都要走流程"。我的判断标准是团队规模：50 人以下优先灵活性，100 人以上优先一致性。
中间地带可以用折中方案，允许自由创建但禁止进入公共筛选面板，个人标签只在个人视图可见。这样既满足了表达欲，又不污染公共语义。
2. 治理成本与检索效率的取舍
治理是有成本的。每季度一次的标签评审，按 100 人团队算，大约需要 4 人天的投入。如果团队的任务检索频率本身很低，这笔投入就不划算。
判断办法是看检索行为的数据：如果周均标签筛选次数低于 50 次，说明标签对你们不是关键路径，治理优先级应该排在需求管理流程之后。
3. 私有化部署与开箱即用的取舍
私有化部署换来的是数据可控和深度定制，代价是升级节奏变慢、需要自有运维能力。SaaS 方案升级快、免运维，但在数据合规严格的行业里可能过不了安全评审。
我的建议是把这个决策交给安全与合规团队，而不是产品团队单独拍板。产品经理要做的是把两种形态对标签治理的影响说清楚：私有化环境下，批量治理脚本和字段迁移通常更可控，历史数据回填的窗口也更好安排。
4. 迁移存量数据与保持系统干净的取舍
全量迁移带来完整性，也带来历史噪声。我在案例中的选择是只迁移最近三个月的活跃任务，历史数据只读保留。这个选择的代价是偶尔需要跨系统查老任务，收益是新系统的语义从第一天起就是干净的。
如果你们所在行业有审计要求，历史数据的完整性可能是硬约束，那就必须全量迁移，同时准备好一份映射表并投入更多清洗工时。这个取舍没有中间态，必须在项目启动前就定下来。
八、30 天落地清单与验收指标
最后一节给你一份可以直接执行的清单。我把它压缩到 30 天，因为超过一个月的治理计划，通常会在第三周失去推动力。
1. 第一周：盘点与冻结
- 导出全部标签及其使用频次、创建人、最近使用时间，形成一张可排序的盘点表。
- 冻结标签创建权限，改为申请制。这一步必须第一天就做，否则治理期间会持续产生新噪声。
- 圈定 12 到 20 个核心标签作为候选白名单，覆盖检索、自动化、风险三类场景。
- 找出所有需要参与统计的属性，列出字段化候选清单。
2. 第二、三周：合并、升级与自动化
- 对同义标签做合并映射表，逐条确认基准名，无法达成一致的按族隔离。
- 把字段化候选属性改为结构化字段，设置默认值和必填规则，完成历史数据回填。
- 配置三类自动打标规则：来源渠道、风险类型、流程滞留。
- 在测试环境跑一遍存量迁移，统计失败条目和语义丢失情况。
3. 第四周：灰度与验收
灰度建议先覆盖一个 20 到 30 人的小团队，观察两周再全量。验收指标我建议看这四个数字，而不是看"标签少了多少"。
| 验收指标 | 治理前基线 | 目标值 | 测量方式 |
|---|---|---|---|
| 筛选放弃率 | 38% | 低于 12% | 筛选面板未完成即关闭的会话占比 |
| 自动打标覆盖率 | 18% | 高于 80% | 由规则写入标签的任务数 / 应打标任务数 |
| 报表人工投入 | 16 人天/季度 | 低于 3 人天/季度 | 季度复盘时人工整理数据的实际工时 |
| 标签清理率 | ， | 高于 60% | 归档、合并或升级的标签数 / 治理前总量 |
4. 验收不达标时的回退动作
如果自动打标覆盖率没上去，八成是规则设计得太理想化。先检查规则触发条件是否依赖了人工字段，能自动获取的条件才适合做规则。
如果筛选放弃率降不下来，问题多半在标签命名上，存在大量语义相近的标签，用户每次都要停下来判断。这时候要做的是继续合并，而不是继续增加筛选条件。
结语：标签治理的本质是一次成本再分配
回到开头那个 137 个标签的团队。他们最后收敛到 28 个，不是因为大家突然变得自律，而是因为治理动作把成本从"每个使用者每次筛选时的犹豫"转移到了"少数人每季度一次的集中维护"。这才是标签方案真正在做的事，把分散在几百个人身上的隐性认知成本，收拢成少数人可管理的显性治理成本。
我在这件事上最深的体会是，产品经理不要追求设计出一套完美的标签体系，而要追求设计出一套能持续演进的机制。完美体系会在人员流动中失效，机制不会。
如果你的团队现在标签混乱，我的建议是本周就做三件事：导出标签使用频次表，冻结新建权限，圈出 15 个核心标签。这三件事加起来不到半天，却能让后续所有治理动作有据可依。
如果你所在的组织超过 100 人，还有数据合规要求，那么在动手治理之前，先把平台形态定下来。私有化部署和迁移能力会决定你未来两年的治理成本上限，这个决策的优先级，高于任何一条命名规范。
常见问题解答（FAQ）
1. 任务属性到底该用标签还是自定义字段，怎么判断？
之前我把优先级、所属模块、迭代这些都塞进标签里，视图一多就彻底乱了；后来在另一个项目里全改成自定义字段，又觉得不够灵活。作为产品经理，我到底该按什么标准去切，一直找不到一条清晰的线。
判断标准就三个问题：这个属性是不是只能有一个值、要不要参与排序或统计、要不要被写进流程规则。凡是“单选、要统计、要卡流程”的，比如优先级、所属迭代、任务类型、负责人角色，一律做成自定义字段；凡是“可以多值、偏描述、边界模糊、随业务不断长出新值”的，比如业务域、涉及端、技术栈、风险标签，才用标签。
一个可执行的量化口径：自定义字段控制在 8 到 15 个，超过 15 个团队就会出现填写疲劳；标签总量控制在 30 到 50 个以内，单个任务建议打 1 到 3 个标签，超过 3 个基本等于没打。
落地时先拉一张“字段/标签边界表”，把现有任务属性全部列成两列，逐条判定归属，评审一次就能定稿，后面再改的代价会小很多。
2. 标签体系怎么设计，分类维度切几个才合适？
我们现在的标签是各人随手加的，三个月后同时出现了“前端”“前台”“web端”“前端相关”四个意思一样的标签，报表完全没法统计。我想推倒重来一次，但不确定该从哪几个维度切、切几层不会过头。
用“维度:值”的两段式命名，比如 业务域:支付、涉及端:小程序，这样一眼能看出归属，统计时也能按维度聚合。维度数量不要超过 3 个，每个维度下的值控制在 5 到 10 个；如果某个维度长出十几个值，通常说明这个维度没切干净，应该拆成两个维度。
维度不要凭感觉穷举，而是从“你要拿它做什么决策”反推：为了排期就切涉及端和技术栈，为了复盘质量就切问题来源和根因类型。设计时先写清楚未来三个月的三张报表需求，再倒推需要哪些维度。
另外一定要建一张同义词映射表，把历史口语标签统一收敛到标准值，第一次收敛通常能砍掉 40% 到 60% 的冗余标签，这一步不做，后面所有统计都是废的。
3. 方案评审时大家都说好，怎么保证上线后不会一周就烂掉？
我们上一版标签规范在评审会上全员点头，上线一周填写率就掉下来了，新人不知道该选什么就问老人，老人自己也说不清。我作为产品经理，很想知道怎么让这套东西真正活下去。
三个机制叠加才有效。第一，让标签先为填写者服务，而不是只为管理者服务：在任务创建模板里默认带出 2 个高频标签，减少选择成本；同时把按标签聚合的个人视图做出来，让人真切感受到“打了标签我自己的活更好找”。
第二，把标签纳入流程卡点，比如任务从进行中流转到待验收时必须至少带一个分类维度标签，缺了就不能流转，这一条的执行力比开十次培训都强。第三，设一个季度治理动作：每季度导出标签使用数据，90 天内零使用的标签直接归档下线（归档而不是物理删除，保留历史数据），新增标签走一个轻量申请，审批一分钟内能完成。
默认值加流程卡点加季度清理，这套组合比一次宣导靠谱得多。
4. 怎么衡量标签落地方案有没有效果，该看哪些数据？
老板问我这套标签折腾了两个月到底有什么用，我总不能只回答“大家用起来方便了”。我想拿数据说话，但又怕选出来的指标是自嗨，反而被追问得更惨。
看四个口径，前两个是健康度，后两个是收益。健康度一看覆盖率，即当期新建任务中至少带一个分类标签的比例，低于 70% 说明流程卡点没真正生效；二看离散度，把标签使用次数排个序，如果 Top3 标签占了 50% 以上说明粒度太粗，如果使用次数少于 5 的长尾标签超过总量一半，说明体系太碎需要收敛。
收益三看筛选效率，统计按标签筛选和保存视图的调用次数及人均周活跃，同时观察“找人问任务归属”这类沟通量的变化；四看复盘耗时，用同类项目的复盘准备时间做前后对比，规范之后通常能从半天压缩到一到两个小时。强烈建议在方案实施前先手动记录两周的现状基线数据，否则事后没有任何参照，改善幅度是无法证明的。
核心关键词
文章包含AI辅助创作：标签落地方案：产品经理开展任务属性的落地方案案例解析，发布者：飞飞，转载请注明出处：https://worktile.com/solution-1/archives/356545
读者评论
我们团队八十来人，去年做过一轮标签清理。把“所属产品线”“客户”这类升成字段后，筛选确实准了，但老数据回填拖了快一个月，历史任务里的自由文本没法自动对齐到枚举值，最后只能人工抽样补，剩下的挂“未归类”。作者说标签升级为字段占六成工作量，我体感还得加上历史数据清洗这一项，而且这块最难推动，业务方普遍不觉得旧数据还有价值。
倒U型那张图我持保留态度。筛选中位耗时和放弃率受任务库总量、搜索框设计、有没有保存常用视图影响太大，单看标签数量未必能推出这么整齐的阈值。我们系统标签也有140多个，但常用筛选固定了七八个，日常点击并没变慢。真正让人烦的不是标签多，是同类任务每次都得从头选一遍。
最认同“三个月后没人依赖就是装饰品”。我上次推标签方案漏了说清谁来维护，上线后新增没人复核，半年又长回两百个。现在改成新建走简短申请、季度盘一次停用标签，才稳下来。至于风险等级做成字段，我们试过，好处是能出趋势，坏处是填的人嫌麻烦，最后统一填“中”，这个副作用原文没提。