阶段 一 · 建档季
把零散说明收进编号
这一阶段做的主要是减法：把同一件事的多份说法合并成一条，再给它一个不再变动的编号。六个分类标签的雏形就是在这时候定下来的。
该阶段沉淀的条目类型
- 早期版本节点与变更说明
- 六类标签的划分口径
- 条目状态的初始三档定义
运营说明 · 站点来路
一份按赛季推进的内容档案，是怎么长起来的
新莆京8883 从建站起就把它当作一份可长期检索的档案来做，而不是一条不断刷新的信息流。这里保存的是变更与条目本身：哪一次迭代调整了哪条口径，哪一条说明归在哪个编号段。它不办理任何业务，也不替读者做判断。
先有编号，再有栏目
站点最早要回答的问题很具体：同一条说明在两个赛季里都出现过，措辞却不完全一致，回查时该以哪一次为准。当记录散落在不同渠道，回溯的成本往往比阅读本身还高。所以第一版结构就放弃了按时间倒序的流式排布，改成每条内容都带编号、可锚定、可跨赛季对照的排法。
会在这里长期停留的是几类固定的读者：按版本号回查变更的人，比对适配清单差异的人，凭编号定位某一条说明的人，以及按赛季阶段复盘案例的人。他们的共同点是不靠推荐位和热度找内容，而是先握着一个编号、一个标签或一个阶段词，再往下展开。
也正因为如此，站内没有推荐位，没有按浏览量排序，没有需要登录才能看的条目。进入任何一个栏目，看到的顺序都是编号顺序或阶段顺序。隔一个赛季再回来，位置基本不会变，只是条目更多了。
发展脉络
三个赛季周期，三段不同的沉淀
阶段按赛季与迭代周期划分，不绑定具体日期。每个阶段收尾时留下的记录类型并不相同，后续条目一律沿用当阶段定下的编号规则与状态口径，不再回头改写。
阶段 二 · 补录季
帮助文档收藏成体系
条目数量快速上升后，单靠编号已经不够定位，于是引入编号段划分，并让适配清单按环境与类别两条线分开记录，避免口径互相污染。
该阶段沉淀的条目类型
- 编号段划分与字段填写规则
- 按环境与类别区分的适配清单
- 条目之间的互引与锚点写法
阶段 三 · 复核季
案例复盘与口径复核并行
当前阶段的重心从"补"转向"核"：专题案例按四个阶段表述，过期口径统一标归档而不再直接删除，方便读者看清一次调整前后的差别。
该阶段沉淀的条目类型
- 专题案例与阶段性复盘记录
- 归档标记与替代条目的对应关系
- 每轮复核后更新的索引版本号
能力边界
这一站明确不做的几件事
边界不是保守，而是为了让每一条记录都能被稳定引用。下面这些限制直接决定了内容怎么组织、字段怎么写。
-
不提供在线办理
页面里出现的任何条目都只是记录，点开也只会到达另一条记录。因为没有办理入口，条目字段里也就不会出现"办理进度"这类会随时失效的字段。
-
不提供下载与附件
资源中心列的是索引与编号规则，不是文件本体。这样做的代价是读者需要自己对照条目，好处是任何一条索引都不会因为文件失效而变成死条目。
-
不设表单与账号
全站没有提交入口，也就不存在账号体系和由此产生的个人数据。需要沟通时走公开的联系渠道，记录留在邮件里而不是站内。
-
不承诺结果与时效
条目只说明"是什么状态"，不说明"会变成什么状态"。因此状态栏永远只有三档，不会出现预计完成、即将开放这类无法核对的表述。
-
不展示未经确认的协作关系
生态体系里只写协作类型、协作方式与边界，不写具体机构名称，也不做标识陈列。这样每一条协作记录都能长期成立，不需要随关系变化反复撤下。
运营原则
四条长期没有改过的做法
这四条从建档季一直沿用到当前版本。它们约束的是内容怎么被写进来，也约束了后续每一轮复核的动作。
两条主线，各自只管一件事
版本记录这条线管的是"变了什么"。它按迭代顺序编号，从早期节点一直排到 v46，每个节点说明这次调整影响了哪些条目、哪些口径。想回溯一次改动的前后差别，从这条线进去最快。
帮助文档收藏这条线管的是"在哪一条"。它以编号归档，按编号段区分用途，回答的是查阅问题而不是变更问题。两条线不互相覆盖职责：一条记录不因为出现在时间轴上就省掉索引编号，索引条目也不会重复叙述变更过程。
剩下两块内容各接一条支线：专题案例库承接产品线切换记录，按切换前评估、切换执行、切换后复核、赛季复盘四个阶段组织；资源中心承接资料索引与编号段规则，说明不同类型资料适合谁查阅。分工清楚了，同一个问题就只会有一个入口。
