品牌故事 · 来历与边界
以收录为起点的一座看台
贝投看台最早是为了回答一个很小的问题而出现的：主站和区域站点各自发布说明文档，读者搜到一份之后，怎么判断它还作不作数。于是第一批工作只是把清单收拢、编号、标明来源与状态，后来才慢慢长出分类、对照和版面。
- 1,286 条收录条目
- 9 个区域说明档案
- 41 个分类标签
来历
一份清单为什么必须留编号
站点最初要处理的情况很具体：同一条说明在不同区域的档案里存在细微差别，读者无法确认自己手上的是不是最新一版，也无法确认两处说法是否同源。所以第一条规则是把区域说明档案逐份收进来，给每一条发放一个不会随内容更新而改变的编号，来源与状态一并写在条目里。九个区域说明档案就是这么进来的，至今仍按同一套编号沿用。
收录形成规模之后，判断标准就必须写下来。一条记录除了标题与正文摘要，还带分类归口、当前状态和时间戳；时间戳精确到日，用等宽字体呈现，方便纵向对齐比读。域名 beacon-beitou.com.cn 与品牌名贝投看台在这里是同一件事的两面：域名指向入口，看台指向入口之后那座可以逐层翻阅的结构。
所以这个站点从设计之初就不打算做首页推荐或热门排序。它更像一间对外开放的档案室：谁进来都能按编号找，找到之后能看来源、能看状态、能看这条记录上一次被核对是哪一天。
复核批次 001–012 · 建档期
结构演进
四次改版，把清单变成看台
目录结构经历四代演进，每一代都由一种新的核对需求推着走：先是能查到，再是能归口，然后是能比照，最后是能一眼扫过时间顺序。
-
阶段 01
单栏清单
所有内容排成一条竖列，靠条目编号维持顺序。这一代只解决“能不能查到”，搜索之外没有第二种找法，区域说明档案按发布时间先后并入。
-
阶段 02
分类标签归口
清单变长以后，读者开始问“这条属于哪一类”。服务与规则两组语义色在这一代确定下来，标签全大写并加字距，同一标签下的条目共享同一种版式。
-
阶段 03
导出对照并入
当条目数量稳定之后，问题从“有没有”变成“对不对”。每一条收录都配上一组品牌站导出对照，逐条对应，核对人员可以拿两份记录对着看，不必依赖描述性文字。
-
阶段 04
纵向时间轴与看台式版面
最近一代把版面摊开成看台：左侧一条纵向刻度串起复核节奏，右侧以卡片堆叠呈现版本记录，宽窄章节交替出现。扫描一段时间的变动，比翻单条记录更省力。
覆盖近三年内发布的全部版本记录 · 连续运行三个完整年度
能力边界
这里不做什么，先说清楚
把边界写在正文中段而不是藏在页脚，是为了让读者在翻阅版本记录之前，就知道这些记录的性质。
- 不提供交易功能，站内没有下单、撮合或订单状态这类页面。
- 不提供投注功能，也不展示与投注相关的实时数据或结果。
- 不承载任何形式的资金往来，没有充值、提现、结算与余额入口。
- 不代替任何区域站点作出解释。站内内容以收录与对照为主，两处口径不一致时，以对照记录里标注的来源为准。
这些边界不是临时约定，而是与结构和版本一起写下来的。可核查性如何落地、时间戳与留痕如何产生，在安全机制里逐节说明；站点性质的完整表述见网站声明。
条目口径：服务类 512 条 · 规则类 774 条 · 合计与总数一致
运营团队
十三个人，三条分工线
维护这座看台的是一个十三人团队，按内容复核、对照校对与技术支持三条线分工，工作日 09:00 至 18:00 轮值回复来信。
- 6 内容复核 逐条确认说明文档与收录条目是否仍然有效，处理待复核状态，并把每一次判定写回时间戳。
- 4 对照校对 负责条目与品牌站导出对照之间的一一比对，发现差异时标注来源，不擅自改写被对照的原始记录。
- 3 技术支持 维护站点结构、时间戳呈现与导出对照的可用性，保证长列表在各类设备上都能逐条读完。
轮值时段 工作日 09:00–18:00
运营原则
四条节奏，撑住可核查的说法
-
01
每周复核一次
注册相关条目由运营团队每周核对一次，累计完成 156 个周度复核批次，时间戳精确到日，不做模糊表述。
-
02
变更后两个工作日内同步
常用入口发生调整时，说明文档在两个工作日内跟进。目前累计收录 47 份变更说明，每一份都挂在对应条目的时间轴上。
-
03
每季度一次全量回溯
回溯不看新增条目，只看已有条目是否仍与来源一致。发现偏差先标状态，再补对照，最后才改写条目正文。
-
04
每年一次口径校准
分类标签的归属、统计的口径与字段的定义每年校准一次，校准结果写进标签说明，不改变既有条目的编号。
记录不删除 · 只追加状态与对照
把说过的话留在编号里，
把改过的痕迹留在时间戳上。
站点不会变成另一种形态。它会继续做同一件事：把主站与各区域站点的说明收拢、归口、比照，让每一条记录都能被翻到、被核对、被追溯。