专题 01
权益条目对齐
银河YH会员权益分类下的 386 条条目由不同批次陆续录入，同一项权益在条款形态、栏目形态与条目注脚里出现过不止一种说法。这个专题处理的不是新增内容，而是让已有条目之间先对上话。
- 同一含义统一到最早登记的那一版，其余写法转为历史备注保留，不做删除。
- 只重排权益层级、生效年度、适用端三类字段，不引入台账之外的新字段。
- 编目组通读一遍，校对组抽检三成，两组判断不一致时回到条目原文再读一次。
- 编号保持原值不动，对齐改的是表述，不是归属。
实践记录：四条路径，把条款走成做法
档案里写的是什么，与这份档案实际被怎么用，隔着一整套动作。这一页把站内反复出现的四类落地路径摊开：它们各自从什么处境出发、按什么顺序推进、推到哪一步算完成，以及在哪一步容易停下。
- 专题 01 权益条目对齐 把同一项权益的多种写法收敛到一版
- 专题 02 服务清单梳理 让权益条目与服务条目一一挂接
- 专题 03 PC 端适配推进 先确认读取环境，再逐项核对结论
- 专题 04 常见问题闭环 把分散反馈归到编号并回写记录
- 专题
- 4
- 实践条目
- 9
- 覆盖年度
- 5
- 涉及分类
- 4
专题总览 · 四条轨道
四个专题，各自处理一段说不清的地方
四条轨道没有先后依赖，可以只挑与自己处境最接近的那一段读。它们的共同点是都从一个具体的错位出发，而不是从一份完整的方案出发。
专题 02
服务清单梳理
服务清单分类下 412 条条目与权益条目之间原本没有明确对应关系。读者读到一项权益，不知道它由哪几条服务承接；反过来读到一条服务，也说不清它挂在哪个权益下。这个专题做的是把两边的连线补上。
- 允许一对一，也允许一条权益对多条服务，映射不上的条目单独成列。
- 不为凑齐关系而强行归并，对应关系缺失的位置如实留空。
- 映射结果落成一张可并排对照的表，表内只保留编号、适用条件与状态三列。
- 清单的结构调整随每月一次更新分段落地，不集中在一个期次里改完。
- 表格只承担对照职能，涉及正式口径仍以条目原文为准。
专题 03
PC 端适配推进
适配清单类下 PC 端适配共 486 条，是四个适配分类里条目最多的一类，也是日常查阅里被翻得最勤的一段。这个专题关心的是同一份说明在不同读取环境下的差别，以及差别该记在哪一栏。
- 覆盖桌面端两类操作系统与四类浏览器内核，逐项对照，不做整体判断。
- 先确认环境字段，再读适配结论；顺序反过来，会把环境差异当成内容错误。
- 适配说明从汇总段落拆成独立条目，一条只讲一个使用场景。
- 旧分档标记为历史值，与新增分档并存，两套均可检索。
专题 04
常见问题闭环
反馈散落在邮件、条目注脚与索引网格的点击记录里，同一个问题常常被登记成好几条。这个专题处理的是把它们归到编号上，再以新增条目的形式回写更新记录，让待处理清单上的条目数与实际待处理的问题数对得上。
- 同一问题只保留一条主记录，重复反馈合并到编号最靠前的那条，其余作为附注。
- 落不进 12 个分类的反馈先挂待定区，等下一轮再判断归属，不强行归类。
- 修订以新增条目的形式出现，原编号保留，不做覆盖式改写。
- 变更按七类标签归入不同分组，便于日后按标签回溯。
实践条目带 · 9 条
每条实践都按场景、需求、做法、结果四段记录
条目之间尽量不重复同一种处境。展开一条可以看到它推到哪一步算完成，以及哪一部分不在这一条的处理范围里。
做法与边界 · 9 条
可以照做的部分，和它不成立的地方
下面这九条做法是从上面的实践条目里抽出来的可复用部分。每一条都配了适用的前提，以及明确不适用的情况——先看右边两列再决定要不要搬。
| 做法 | 对应分类 | 适用条件 | 不适用情形 |
|---|---|---|---|
| 表述收敛到最早登记版本 | 会员权益 | 同一含义出现多种写法，且每种写法都能定位到编号 | 差异发生在不同权益层级之间，不属于表述问题 |
| 双向引用拆解为单向 | 会员权益 | 两处相互引用同一条口径，改动需要人工同步 | 引用关系本身尚未稳定，此时拆分会产生断链 |
| 档位边界改写为条目引用 | 服务等级 | 档位判断依赖段落理解，不同读者归纳结果不一致 | 档位划分本身还在调整，边界尚未固定 |
| 条款翻成可并排对照的表 | 服务清单 | 同一批条目被多人反复取用，且取用间隔超过一周 | 单次查阅、不存在转述环节的场合 |
| 映射不上的条目单独成列 | 服务清单 | 对应关系不完整，但仍需要把推进过程显式记下来 | 缺失字段本身尚未定义，留空位置无法被解释 |
| 逐项对照而非整体判断 | PC 端适配 | 同一内容在不同环境下表现不一致，需要先定位差异 | 差异来自条目本身写得不一致，与环境无关 |
| 汇总段落拆为独立条目 | PC 端适配 | 一条说明混着多个使用场景，需要被单独引用 | 多个场景共享同一前置条件，拆开后需要重复交代 |
| 重复反馈合并到最前编号 | 服务响应 | 同一问题被多渠道反复反馈，登记时出现多条记录 | 反馈分属不同分类，合并会抹掉归属差异 |
| 一处描述只保留一个位置 | 问题修复 | 同一口径同时出现在正文与页脚，且措辞不一致 | 两处描述承担不同职能，删去任一都会造成缺口 |
继续往前 · 三个方向
看完做法之后，还可以往哪里读
这一页只铺开四条路径的轮廓，每条路径的细节、变更记录与使用条件，分散在站内另外三个位置。
