即使在某个站点相对集中的主题范围内（SO上的每个人都不太可能会认为太阳是指太阳系的恒星），某些标签本质上还是模棱两可的。
当前存在两种不令人满意的选择：
声明该标签仅用于一种可能的含义，编写一个标签Wiki对其进行解释，并从此处链接至新创建的具有其他含义的标签，并在任何时候保持清理标签有人会忽略解释该标签的Wiki弹出窗口。
对所有含义使用替代标签（例如
cd-command和compact-disk，而不是cd），并在每次再次弹出时都删除不想要的标签。而且会的。代表要求不阻止用户创建不必要或多余的标签。将标签列入黑名单是一种复杂的仪式，最多一次出现在蓝色的月亮中，涉及到一条龙，一个团队成员并为此付出了牺牲。被烧毁。如果将其他明确的标签应用于不明确的标签，它也将不容易被发现。在这种情况下，我认为这不是可行的选择。
建议
这里是建议的功能请求：
就像可以将一个标签声明为另一个标签的同义词一样，基本上可以改变所有对该同义词的引用均指向对该其他规范标签的引用，因此应该有可能使它成为多个其他标签的歧义标签（或歧义标签）。从“您输入的术语与其他术语具有相同的含义”到“您输入的术语与其他术语之一具有相同的含义，请选择正确的含义”是一种逻辑上的进步。
标签应强制用户选择显示的其他选项之一：
“您输入了'as'，是指关键字还是动作脚本？“
”您输入了'vb'，您是指vb6，vb.net还是virtualbox？“
”您输入了'vm'，您是指虚拟机还是虚拟内存？“
“您输入'sas'，是指Serial-attached-scsi还是sas软件？”
“您输入了'kvm'，是指kvm-switch还是基于内核的vm？”
“您输入了'mono'，您是指单声道框架还是音频？”
“您输入了'dsl'，您是指数字用户线还是该死的小型Linux？”
并非所有这些示例都可能很好（我不确定例如前两个SO示例），但是无论如何，这并不是重点-它们应该传达如何使用。
请注意如何如果用户必须键入某些标签，这些标签可能永远不会使用，但是所有简短的内容都是模棱两可的。
可以通过扩展当用户输入标签时显示的同义词/标签Wiki摘录下拉列表来解决此问题，提出用户输入的歧义标签的替代方案（类似于同义词建议，但具有多个选项）。如果忽略，仍然可以向用户显示一条错误消息，如带有黑名单的标签，但是通过精心设计选择对话框，应该可以在大多数情况下避免这种情况。
> 在标记时建议用户消除歧义
此主题相关，但是用户似乎已经接受了在标记建议下拉列表中包含标记Wiki摘录的足够内容。
应如何处理含糊不清的标签？
这需要大量讨论和团队参与（即现状）
如何处理标签有多种含义？
除了手动重新标记外，该主题没有其他解决方案。
#1 楼
我对模糊标签的最大问题是为这些标签编写标签Wiki是一种折磨。*对于wma，我应该写有关Windows Media Audio格式还是有关Java ME Wireless Messaging API的文章？ >
对于cdc，我是否应该写有关USB通信设备类或有关SQL Server中的更改数据捕获或有关Java ME中的连接设备配置的内容？
即使我决定涵盖标签Wiki中所有流行的含义，想象读者会觉得如何，这让我感到恶心。一个页面要涵盖两个，三个或更完全不同的主题？
据我所知，提出的功能请求有助于摆脱这种头痛，这就是我全力以赴的原因。
评论
到目前为止的解决方案（至少在SU上）是使它们中的每一个仅代表一件事（由约定或元讨论确定），并且如果要使用其他含义进行标记，则需要找到另一个标记。您可以想象它的效果如何。
–丹尼尔·贝克（Daniel Beck）
2012年12月12日在6:18
@DanielBeck是的，我可以想象。这就是为什么我赞成您的功能要求
– gna
2012年12月12日6:30
#2 楼
据我所知，这些站点上的标签需要调整，而且我认为该建议还不够。常见的，不好的问题都带有“标签句”。低重复用户刚开始在标签字段中键入内容，发现英语中最常用的1000个单词都是现有标签，可能在糟糕的日子里包括“ a”和“ is”。就技术术语而言，我认为标记框可能是等效的，因为它实际上包含所有常用编程语言的所有关键字。
至此，至少，即stackoverflow的成熟度，我想知道是否需要采取高防护措施来使一个新标签存在更有意义。当具有中等代表数量的某人首次使用标签时，除非高级用户或mod明确认可它，否则其他任何人都无法使用该标签。
评论
请注意，新用户无法创建真正的愚蠢标签。在SO上创建标签是一项1500次重复的操作，很遗憾，这是看不见的。如果输入标签，标签将简单地存在。而且，新用户会很乐意选择mac，os和x，而不是mac-os-x，这是事实。关于关键字，这似乎是SO特有的问题，应单独讨论。
–丹尼尔·贝克（Daniel Beck）
2012年12月12日6:20
对于逗号而不是空格，这是一个简单的决定，因为标签分隔符可以避免。那好吧。一次战斗。
–丹尼尔·贝克（Daniel Beck）
2012年12月12日6:25
我相信这是一个完全不同的问题。例如，在SU上，完全有可能查看最近30天创建的新标签（我们只需要再增加1万名用户即可）。
–slhck
2012年12月12日，11：06
好吧，那么我们有一些不是那么新来的用户就一直把稻草变成不黄金。
–罗西南特
2012年3月12日下午16:27
是否有可能使标签创建需要用户编写至少20个字符的标签Wiki，以防止意外或愚蠢的标签创建？
–大卫·曼海姆（David Manheim）
2012年6月12日18:44
@daniel逗号也可以用作标签分隔符。自己尝试...
–杰夫·阿特伍德
2012年6月12日20:06
我认为标记框可能会等效于：D !!好一个
– hek2mgl
2014年1月28日在21:50
#3 楼
重新编辑：正如评论中向我指出的那样-该提案应解决一些问题。可行的解决方案：
要求标签需要在其Wiki中至少要使用100个字符的描述。所有当前被认为不明确的标签都可以将Wiki条目替换为“不明确-使用A或B”。
在这种情况发生之前，它们不能应用于任何帖子，并且出现错误提示例如“如果没有标签Wiki上的描述，用户将无法应用新标签。标签'stupid-tag'是新标签和/或长度不足。请尝试使用现有标签，或者如果确定可以写新说明此标签描述的内容与现有标签有所不同。“
标签Wiki的创建将更改为1500个信誉锁定操作。这些锁定的标签只有在决定如何使它们变得明确或保留得太短之后才能应用于现有帖子。
人们可以，随着时间的流逝，请对这些较旧的，标记错误的帖子进行编辑，以修复标记。对旧帖子进行修改将不允许人们在帖子上留下任何新的不可接受的标签。
评论
这是解决特殊情况的不必要的瓶颈。
– Toomai
2012年6月12日19:00
将会发生什么：原始问题作者尚未创建新主题的现有标签，因为这太费力了。审稿人和编辑增加了对问题的维护。用户将创建未使用的标签来“准备”问题，但标签自动删除（用于清除）将应用于零个问题标签。由于此方法将使0个问题标签成为系统的必需部分，因此必须重新设计标签清理。负面影响和副作用太严重，无法使这种方法有用。
–丹尼尔·贝克（Daniel Beck）
2012年6月12日19:26
丹尼尔-好的电话，您可能是100％正确的。我没有意识到自动清理问题。 （恳求无知并不是真正的借口。）自动清除多长时间运行一次？它可以做一个很小的修改，只排除最近5分钟内创建的任何标签吗？
–大卫·曼海姆（David Manheim）
2012年6月12日19:33
Toomai-例外情况应该是创建新标签。我希望在几乎所有情况下都应该已经有一个标签，因为标签应经常重复使用。如果没有标签，则表示该特定主题对该网站而言是全新的。 （不太可能，因为我们在与该网站有关的主题中汇总了知识。）
–大卫·曼海姆（David Manheim）
2012年6月12日19:36
这实际上是一个好主意-它为新标签的创建添加了恰如其分的摩擦，即“如果您真的很想要这个新标签，则必须了解它的含义，并先向其他人进行解释。
–杰夫·阿特伍德
2012年6月12日在20:07
@JeffAtwood-这可能是一个好主意，但是实现它比我预期的要重得多。我希望为用户增加摩擦成本，这就是这个想法，但是实现听起来好像太沉重了。
–大卫·曼海姆（David Manheim）
2012年6月12日20:12
杰夫-而且，与您互动很酷-我是您的忠实粉丝。
–大卫·曼海姆（David Manheim）
2012年6月12日在20:14
此解决方案的真正问题：您基本上是在问题中建议“不满意的选项1”，并带有可以（并且将被忽略）的强制标记Wiki。正如我在原始问题中所写的那样，用户不在乎标签wiki（摘录）说的是什么—他们会很乐意选择mac标签来解决软件问题。
–丹尼尔·贝克（Daniel Beck）
2012年6月14日17:27
我知道它可能会发生这种情况，但是对我来说，删除mac，用machintosh替换它，然后对mac标签做一个简短的解释，这对我来说更有意义：这是模棱两可的。有关为何不使用它的信息，请参见[链接]。
–大卫·曼海姆（David Manheim）
2012年6月14日19:43
这使mac成为元标记。我不知道模棱两可的标签是否可以解决mac问题，这不是重点。这只是一个示例，用户在选择标签时会忽略标签Wiki摘录，从而使答案无效。
–丹尼尔·贝克（Daniel Beck）
2012年6月15日4:08
根据该建议，对其进行简短的解释将使该标签无效。可以将其称为meta标记，但我宁愿称其为带注释的删除。我可以更普遍地删除模棱两可的标签，尽管meta-tag规则是一个很好的规则，但该建议将对其稍加修改，以允许使用一类元但有效删除的标签。
–大卫·曼海姆（David Manheim）
2012年6月15日11:26
在我看来，您正在提出与我的功能请求类似的解决方案，但通过黑客（不需要的标签使用简短说明）而不是通过针对要解决的问题正确实施特定的解决方案来达到预期的效果，例如通过自动将所需标签显示为自动完成（例如今天的同义词）。除了显而易见的（需要标签Wiki）之外，您的提案还有什么优势？它将需要进行同样多的开发，而且不够清晰，需要用户学习“简短描述”技巧。
–丹尼尔·贝克（Daniel Beck）
2012年6月15日在16:04
尽管我为获得更多更好的标签Wiki所付出的努力表示赞赏，但要求标签描述以创建/使用标签的方法将成为标签创建的重大障碍，并产生严重的副作用，例如a）将不再创建新标签，即使它们很有用（在SO上可能不错，但在其他地方也很痛苦）b）重复的，无用的标签Wiki，从而设法超过了字符数要求。注释已经具有最小长度要求，通常通过随机无用的填充来实现。与无用的标签Wiki相比，我更喜欢无标签的Wiki-前者更易于识别。
–丹尼尔·贝克（Daniel Beck）
2012年6月15日在16:06
@DanielBeck这很公平。想法是实施起来会容易得多。如果这是不正确的，则可能无济于事。游戏标签长度的问题并不是我想到的，而是一个公平的问题。 SO与其他SE站点所面临的挑战不同的问题也不是我完全考虑过的问题。另一方面，增加摩擦会减慢无用标签的创建，并可能使人们考虑自己在做什么。
–大卫·曼海姆（David Manheim）
2012年6月15日在16:13
#4 楼
作为Microsoft Unity的活跃用户，我总是尝试保护标签unity（最初用于该产品）免受滥用。我认为应该在此提案中添加两个要点，
每个标签的朋友标签
对于每个标签，我们应该允许定义朋友标签。例如，
unity应该具有inverse-of-control，dependency-injection和ioc等。ubuntu-unity应该具有ubuntu等等。/>
unity3d应该具有3d，game等。自动建议
由于每个问题可以有5个标签，因此我们可以从其他标签中分辨出
unity是否正确。例如，如果用户使用
ubuntu和unity，他/她必须指ubuntu-unity，我们应该生成警告。 如果用户使用“ 3d”和“ unity”，则他/她必须指“ unity3d”，我们也应发出警告。
仅当模糊标签为仅使用标记，我们将平均显示所有歧义选项。这更加方便，因为用户可以轻松地了解最可能使用哪个选项。
评论
我喜欢“朋友”标签的想法。但恐怕只有在OP甚至添加多个标签的情况下，它才会有用！
– Joachim Sauer
13年5月27日在11:14
看起来好像是消歧过程的有趣优化。这也可能是自动化的，因为系统知道哪些标签经常组合使用，因此无需手动定义它们。
–丹尼尔·贝克（Daniel Beck）
13年5月29日在20:40
#5 楼
另一个解决方案可能是使其知名度更高，或者具有gui前端，以便您可以轻松地执行多标签查询。例如，“表”标签超载。如果仅单击“表格”按钮，您将获得涉及不同主题的帖子，尤其是sql数据库表和html表。但是，如果您转到右上角的框并输入[table] [sql]
，那么您会得到一个几乎只涉及数据库表的问题列表。
或者，如果您键入
[html] [table]
，您将得到几乎与html表完全相关的问题列表。
使用多标签查询时，过载的问题已基本消失，因此应以某种方式加以推广。
评论
我们也需要一个用于数据库的我喜欢，但这是一项艰巨的工作。我预计将需要6--8个星期。
绝妙的主意解决了我长期以来一直在寻找解决方案的问题，例如[vb]标记不明确（因此毫无用处）。 （哦，嘿，您甚至知道那是因为您与我的问题有关。那怎么办！）
为什么这个网站甚至使用标签？为什么不仅仅依靠全文搜索进行搜索？
@Rosinante：您可以关注标签。搜索是模糊逻辑，当每个人在其问题中使用正确的术语时，其准确性最高可达95％。正确应用标签后（高级用户可以在其他人不执行的情况下执行此操作），标签可以达到99％+的准确度，并且从模糊匹配到完全不同的主题区域的渗色几率较小。另外，借助标签系统，您可以准确提示（如此功能要求所建议）。祸be于试图实现Clippy的SE开发人员。
当您搜索包含许多指称的单词（例如vb）时，Wikipedia具有类似的功能。
暂且说一下，但是上述功能请求的某些实现可能允许这样做：显然，还有一些有效的非歧义标签会与其他标签混淆。如果也可以为这些警告显示警告，那可能会很好，但是仍然允许人们选择原始标签。
如果实施了此请求，带有歧义标签的现有问题会如何处理？对于主持人来说，这听起来像/ hyperbole /小时。
@SamDeHaan好问题。我的建议：让我们防止新主题和编辑内容拥有（或保留），让社区修复所有较旧的内容（例如列入黑名单的问题标题术语-问题问题-AFAIK）。
如果SE的某个人在“我们正在考虑”的情况下对此加以考虑，那就太好了。模棱两可的标记以及处理它所必需的清理工作似乎一直是一个问题。
我♥这个。是的，至少要得到团队的认可并暗示他们的感受，这真的很酷
我真的喜欢这个主意。我只是希望弹出窗口的颜色能多加考虑；）
@PeeHaa我确定开发人员足够聪明，可以将＃fe7a15用于SO。屏幕截图是在SU上创建的，这是.supernovabg颜色...
“因此，不太可能有人认为太阳是太阳系的恒星”。真的吗？请注意，sun标签可能应该走了-所以问题是关于solaris或sparc或sun-jvm或您有什么问题，而不是关于前公司的问题。
那么，这将被实施吗？