这一方向处理条目本身的位置与表述，四条流程覆盖错放类目、重复收录、条目缺失与描述偏差。 动手之前先做两件事：在类目总览里看清两个相邻类目各自的收录边界，再把想说的话写成别人能照着检索的形态。
适用场景条目确实存在，但所在类目和它实际承担的事情对不上，常见于边界靠得近的两类之间。
需要准备条目名称或可检索的关键词；它当前所在的类目编号（C01–C12）；你认为应归入的类目编号；一句说明理由。
注意不要用截图代替文字描述。截图无法被检索，也难以在目录中定位到具体那一条。
结果确认条目归位后，原类目与新类目的条目数同步变化，两者相加仍是 1,284 条。
适用场景同一个对象以两种写法、或在不同标签下分别出现在目录里，两条都能被检索到。
需要准备两条条目的名称；它们各自所属的类目编号；能说明二者指向同一对象的差异点。
注意跨类目的重复条目只提交一次。两条各自提交会进入不同的复核队列，处理反而更慢。
结果确认合并后只保留一条，另一条按跨类目迁移记入变动记录。
适用场景某类资源使用频率很高，但换了几种写法，在目录里始终找不到对应条目。
需要准备资源名称；你认为它属于哪个一级类目；一条可核对的特征描述。
注意现行目录中条目型内容 726 条、说明与指引型内容 558 条，先判断内容形态，才能判断它该落在哪里。
结果确认补入的条目计入当期变动记录，区间末总量重新核算，仍以 1,284 条为准。
适用场景条目名称和类目都没问题，只有附在后面的那句说明里，有一处说法对不上。
需要准备条目名称；原说明的原文；你认为不符的具体位置。
注意描述修订不涉及类目归属，不必重新走标签判定，两者是不同方向的流程。
结果确认修订后的说明会在下一次标签复核时一并写入，条目编号保持不变。
标签与类目分属两件事。前者决定一条内容上挂着哪些判定标记，后者决定它落在哪个编号之下。 这一方向的申诉不改变类目编号，结论只在原条目上体现，并入每月的标签复核轮次。
适用场景条目上的某个标签本身存在，但你认为它并不满足该标签的判定条件。
需要准备条目名称；标签名称；你参照的判定依据出自内容专栏里哪一分类目的解读。
注意这类申诉只针对判定依据的适用，不改变条目的类目编号，也不会把条目移到别的类目下。
结果确认申诉结论附在原条目上，标签要么维持原状，要么按结论调整。
适用场景同一条目上挂着两个看起来互斥的标签，连起来读自相矛盾。
需要准备条目名称；冲突的两个标签名称；你认为它们互斥的原因。
注意标签冲突多数出现在迁移之后，提交前先看该条目的迁移记录，能省掉一轮往返。
结果确认调整结果并入当月标签复核，产出后随条目同步更新。
适用场景条目所在的类目没问题，只是缺一个按判定依据本该挂上的标签。
需要准备条目名称；缺失的标签名；使该标签成立的判定条件原文。
注意标签判定每月复核一次，补打集中在复核轮次里处理，不因为单条提交而提前。
结果确认补打后条目的标签列表会变长，目录的条目总数不变。
溯源要回答的是「这条内容什么时候进的目录、在当时的结构里被放在哪一段」。 九个主版本 V1 到 V9 各自记录了命名规则、目录结构与呈现方式的变化，说明位置时统一用区间序号与版本编号。
适用场景想知道某条内容大致在目录的哪个阶段进入序列，好判断它当时遵循的是哪一套结构。
需要准备条目名称；能想起的其他线索，例如所属类目编号或已挂标签。
注意五个变动区间只表达先后关系，不对应具体年月，不要拿日期去核对。
结果确认你会得到一个区间级的定位结论，以及它进入目录时的类目归属。
适用场景怀疑某次结构调整改动过类目的收录范围，导致同一条内容在两个版本里归属不同。
需要准备你要对照的两个主版本编号，取值范围 V1 至 V9。
注意命名规则与目录结构是两个维度，版本说明里分开记录，比对时不要混在一起看。
结果确认你能判断某次归类变化是结构调整的结果，还是分类纠错的结果。
适用场景同一类内容在新旧版本中的呈现形式不同，不确定是内容变了还是只是显示变了。
需要准备涉及的内容类型；对照的两个版本编号。
注意呈现调整不产生增删记录，变动区间的计数不会因此改变。
结果确认核对结束后，你能说清这次差异属于结构层面、内容层面还是显示层面。
所有方向都在 2 个工作日内给出首次响应，差别不在响应速度，而在内部复核轮次和结论落在哪里。 下表按流程编号逐条列出，编号可以直接用来查询进度。
| 编号 | 流程 | 首次响应 | 内部复核 | 结论落点 |
|---|---|---|---|---|
| F01 | 条目被放进了相邻类目 | 2 个工作日内 | 1 轮，当期处理 | 回复类目归位结论 |
| F02 | 同一资源被收录两次 | 2 个工作日内 | 1 轮，当期处理 | 回复保留与合并结果 |
| F03 | 明显常见的资源检索不到 | 2 个工作日内 | 1 轮，计入当期变动 | 回复补入与归入编号 |
| F04 | 描述与实际对不上 | 2 个工作日内 | 1 轮，并入标签复核 | 修订写入原条目 |
| F05 | 判定依据与理解不一致 | 2 个工作日内 | 1 轮，并入当月标签复核 | 结论附加在原条目上 |
| F06 | 互斥标签同时出现 | 2 个工作日内 | 1 轮，并入当月标签复核 | 标签列表随之调整 |
| F07 | 应有标签缺失 | 2 个工作日内 | 1 轮，并入当月标签复核 | 标签列表随之补全 |
| F08 | 条目所属主版本定位 | 2 个工作日内 | 1 轮，比对区间记录 | 回复区间级定位结论 |
| F09 | 主版本目录结构比对 | 2 个工作日内 | 2 轮，结构差异需复看 | 回复版本差异清单 |
| F10 | 呈现方式调整比对 | 2 个工作日内 | 2 轮，需区分内容与显示 | 回复调整层面判定 |
查询时提供流程编号与首次提交时间即可，客服可以按编号定位到当前所处的复核轮次，不必重新描述一遍问题。 同一件事保留一条记录，后续补充材料直接回复原邮件。提交渠道与答复时间见联系我们。
十条流程本身并不复杂，拖慢处理的大多是提交方式。把这十条读完你会发现，「易游 使用工具」并没有额外技巧， 无非是先检索、再比对、最后提交。下面四件事是最常见的失手处。
只写「某条资源归类不对」，既没有条目名称，也没有类目编号。
正确做法：把条目名称、当前类目编号、建议归入的编号三样凑齐再发，缺一样就会多一轮往返。
隔一天补发一次，或换一个渠道再发一遍，两条记录被分到不同的队列里。
正确做法：保留首次提交的时间与流程编号，等首次响应；有新线索就回复原邮件，而不是另开一条。
把同一条内容的纠错分别发进两个类目，两边各自处理，结论可能对不上。
正确做法：一条内容只对应一次纠错，跨类目迁移由这一次处理一并覆盖。
只贴一张界面截图，不说条目名称，也不说争议落在哪个编号上。
正确做法：用文字写出条目名称、类目编号与偏差位置，让这条记录本身可以被检索和比对。