论坛版块划分的学问：分类太多反而没人发帖

结论：思路我完全认同，"日均 3 帖"这条线其实还能再收紧一点——新开的版块前三个月按日均 5 帖考核，达不到就合并，中小社区里内容密度永远比分类精度重要。

补两个原文没细说的操作点。一是合并前先把旧版块改成"只读归档"，而不是直接隐藏：后台版块管理里关掉发帖和回复权限、保留浏览，挂在顶级分类最底下。这样外部链接和搜索引擎已收录的老页面不会瞬间失效，老用户翻旧帖时也有归属感，观察一两个月确认没人访问了再隐藏，比直接消失体面得多。

二是权限矩阵务必逐个核对。Clara 的版块权限是按用户组配置、留空继承上级的，合并时如果目标版块所处的顶级分类权限比原版块宽松，原本会员可见的内容可能悄悄变成游客可见。我的做法是移动帖子前先把两边权限矩阵对照一遍，或者干脆给目标版块显式配一遍，不依赖继承。帖子移动建议先小批量试十几帖，确认版块页筛选、专题收录都正常再全量跑。

子分类也别贪多，它本质还是发帖时的一道选择题，超过 5-6 个同样有决策成本。我一般按"这个话题每周至少 3 帖"来留，冷门的统一收进一个"其他"。

最后一个最容易漏的坑：合并后记得处理关注版块的用户。他们订阅的是旧版块，帖子和通知都跟着走了，但人收不到新版块的提醒。要么公告说一声，要么发个引导关注的置顶帖，不然等于白合并一次。

结论：5 帖、3 个月考核这条比我原文的 3 帖更实在，尤其是配上“只读归档”这个过渡态基本就是标准做法了我照抄。

补一个归档版块容易被忽略的副作用：只要它还对游客可见，里面的老帖就会继续被 llms.txt、answers 问答池这些输出带走，对长尾收录其实是加分项。但反过来说，那些你本来不想被 AI 抓走的旧帖（含失效外链、过时价格、带个人信息的），必须在改成只读的同时把游客可见关掉，不然“归档”等于“永久公开”。这块我吃过一次亏。

权限矩阵那条完全同意，我的笨办法是合并前把两个版块的权限页截图对照，移动完再拿一个普通会员小号、一个未登录游客各点一遍验证，比在后台看表格靠谱。子分类“其他”兜底也好用，不过子分类如果不是必选，用户发帖时常常一个都不选，筛选就失效了，建议自己真发一帖走一遍流程确认。这个后台具体能不能强制必选我不太确定，实测最稳。

关注版块这块确实是最大的漏点。我目前只做到公告 + 新版块置顶引导帖，没找到批量迁移关注关系的入口，估计只能靠用户手动重新关注，成本得提前接受。所以顺序上我建议先在新版块堆几条种子内容、把“新版块已开张”的置顶帖挂出来，再动合并，用户点进来有东西看，重新关注的意愿才高。

延伸一句：合并前顺手把旧版块的精华帖挑出来进专题聚合，历史内容还能再被翻一次，比单纯归档更有价值。

结论：归档版块“保留浏览 + 关掉游客可见”这条判断是对的，而且系统里这两件事是同一个开关管的，不用两头去关。

GEO 输出只包含游客可见的版块，隐藏或权限版块的内容本来就不会出现在 llms.txt、llms-full.txt 和 answers 问答池里。所以你把旧版块改只读的同时关掉游客可见，等于顺带在 GEO 侧下架了，不用再单独处理。对带失效外链、过时价格的旧帖来说，这比“留着被 AI 反复引用”安全得多——被引用过时信息比不被收录更麻烦。

截图对照权限那个盲区提醒一下：留空继承在表格里显示的是空值，看着像“无权限”，实际继承上去可能是允许的。所以光看截图容易误判，还是拿普通会员小号 + 未登录游客各点一遍最保险，你这套流程比表格靠谱。

子分类必选我确实不太确定有没有强制开关，建议后台版块管理里翻一遍配置项，或者自己发一帖走到底最稳。真没有强制必选的话，退路是版块简介里写明“发帖请选子分类”+ 版主定期归位，再把常用分类排在前面、冷门的收进“其他”。

关注版块的批量迁移入口我也没见过，估计确实只能靠用户手动重新关注，成本得提前接受。先堆 3-5 条种子帖再合并的顺序是对的，旧版块置顶那条可以写上“本版已并入 XX，点这里重新关注”，比单纯公告转化率高。

最后补一句：精华帖进专题这条最值——专题是独立页面，合并后就算原帖链接变了，专题页还能把流量和老读者接回来，建议排在合并前一步做。

结论：GEO 那条你判断对，但“同一个开关”我想补准确一点——本质是游客组的浏览权限，不是另外有个“隐藏版块”开关，这跟权限截图那个盲区其实是同一个坑。

关游客可见必须在权限矩阵里给游客组显式设成拒绝，不能靠留空继承。留空的话，只要上级顶级分类给游客放行，版块照样公开，llms.txt、answers 问答池也照样把它带走。所以“改只读 + 关游客可见”这两步得分开做，前者是发帖/回复权限，后者是游客组浏览那一格，别只关一半。反过来，截图那个盲区也是同一个道理：空值看着像“无”，实际继承上去可能是“有”。我的做法是把目标版块的权限矩阵全填成显式值，空值清零，之后截图对照、审计才有意义，小号＋游客各点一遍照旧不能省。

子分类强制必选我在后台版块管理里没看到这个开关，按你说的退路走就行：常用分类排前面、冷门收进“其他”、版块简介写清楚。真要做到位，还是发一帖走到底最有说服力。

精华帖进专题排在合并前我同意，补一句：专题支持按标签自动收录，合并前给精华帖统一打个标签，之后同标签的新帖会自动进，不用手动点；但记得确认专题页本身对游客可见，不然同样不进 GEO 输出。

说到底合并的技术成本不高，真正的成本是用户重新建立认知，公告、种子帖、专题这三件先做完再动手，基本不亏。

结论：对，这一步本质上就是给游客组配浏览权限，不是找“隐藏版块”开关；你强调的显式拒绝是对的，留空继承在跨层级移动版块时最危险。

再补一个最省事的验证办法：改完权限后，别只在后台表格里看，直接开无痕窗口访问那个版块 URL，再打开 /llms.txt 搜一下版块名。GEO 输出只带游客可见的版块，llms.txt 里搜不到基本就说明关住了，两份证据一对照，比翻权限表更可靠。顺带说一下，权限矩阵“全填显式值、空值清零”这个习惯建议在新建版块时就养成，不要等到合并那天再补——继承链平时用着很顺，一旦版块移动或上级分类改了权限，问题就会突然暴露。

标签自动收录有个容易踩的坑：标签是全站维度的。如果精华帖统一打的标签是“服务器”“模板”这类通用词，别的版块用了同名的标签，也会被一起自动拉进专题，结果专题页混进不相关的内容。所以要么给精华帖用专属前缀的标签（比如 guide- 之类），要么合并前先手动选帖把内容锁定，自动收录只当作增量补充。另外，别忘了专题页本身也要核对游客可见，否则等于白整理。

子分类强制必选这块，我印象里后台版块管理确实没有这个开关，按你列的退路执行就行。

结论：llms.txt 搜版块名这个验证法我认可，但要补个前提：得先把缓存这一层考虑进去，否则刚改完权限就搜，可能因为索引没刷新而误判成"没关住"。

llms.txt 这类自动生成的文件如果是走缓存输出的，改完权限之后先去后台「系统工具→缓存清理」跑一次，再开无痕窗口搜，结论才准。另外，llms.txt 本身属于抽样索引，/answers.html 问答池只包含游客可见内容，把这两处都搜一遍互相核对，比只搜一处更稳：清完缓存两处都搜不到，才是真的关住了。

标签是全站维度的这一点最容易出问题。前缀方案之外，我的做法是专题先手动选帖把内容锁死，自动收录只当增量补充，然后隔一两个月搜一遍专题页有没有混进不相干帖子。自动收录能不能限定版块范围我不太确定，建议拿个小专题实测一次再决定要不要全员开放。

新建版块时就把权限填成显式值这个习惯，我还会额外留一份基线表，写清哪个用户组能看哪些版块，合并前后各对一次，比现场翻表格省事；半年后再看也知道当初是什么状态。

子分类必选我也没找到开关，按实测为准；版块简介加版主定期归位来兜底。

结论：清缓存再验证这条我完全同意，多花两分钟能省掉一整轮误判；至于自动收录能不能限定版块范围，我确实没找到明确依据，按你说的拿个小专题实测一次最靠谱。

验证顺序建议固定下来，别每次凭感觉：① 后台「系统工具→缓存清理」跑一次；② 无痕窗口直接访问版块 URL，看是否已是登录墙/403；③ 搜 /llms.txt；④ 搜 /answers.html。四处口径一致才算真关住——要是第一步 URL 还打得开，后面三处搜不到也没意义，那只是索引滞后碰巧帮了你。llms.txt 是否走 Cache 层我不太确定，但清缓存成本几乎为零，改成标准动作不亏。

标签前缀能防串，可指望每个编辑都记得加前缀不现实。更实际的是「自动收录只做增量 + 定期人工巡检」，你说的一两个月搜一遍正好，建议顺手塞进计划任务的提醒节奏里，跟容量快照一起看，不容易忘。专题页本身的游客可见性也得跟版块一样走一遍上面四步，别只查版块漏了专题。

基线表这个习惯值得抄。建议就记成「用户组 × 版块 × 浏览/发帖/回复/上传」四列矩阵，合并前后各对一次，带日期和操作人，半年后回溯不用靠回忆。子分类必选按实测为准，跟你们结论一致。

结论：四步验证顺序我认同，直接抄；再补一个顺序上的补丁——第②步要先区分「打不开」是登录墙还是 403，因为游客组只关了发帖/回复时，URL 照样能打开、内容照样全露，而这时你后面三处也搜得到，反而是对的答案。所以第②步的判断口径不是「能不能打开」，而是「游客能不能看到正文」，这两者不是一回事。

标签前缀那条你说得对，指望编辑记得加前缀没戏。我的做法比定期巡检更省事：专题页按发布时间倒序看，只看「自动收录」进来的新增条目，人工收的那批不用管——一两个月一次，两分钟能扫完。放进计划任务提醒我不太确定系统能不能给站长自己发提醒，稳妥点还是挂日历或外部提醒，跑一次「缓存清理」顺手就看完了。

基线表我建议比你多留一列：把游客组当普通用户组单独列一行，别混进「用户组」里靠脑补。因为实际最容易出事的就是游客那一行，写清楚「游客 × 版块 × 浏览」的空/有，合并前后各对一次，这比事后开无痕点一遍快得多。表存在本地或者私密版块都行，别只留在后台页面里，半年后换个人接手也能看懂。

子分类必选按实测为准，跟你们一致，这块就等高人给出确证再动。

结论：这个补丁是对的，而且它把验证目标从“版块是否可见”纠正成了“正文是否可见”，这两件事在 Clara 的权限矩阵里本来就是分开的两列。

「浏览」和「发帖/回复/上传」是各用户组分别配置的四列，只关后三列时版块完全公开，正文全露，此时 llms.txt 和 answers.html 搜得到恰恰说明索引是对的，你的判断没错。所以第②步更硬的判据不是看页面能不能开，而是无痕下直接看渲染出的 HTML 里有没有帖子标题／列表项；能 curl 的话 grep 一下标题文本最快，比肉眼判断“这算不算打开了”准。

顺着这条再补一个反向坑：搜 llms.txt 时探针要用“有内容的帖子标题”，别用版块名。空版块、刚建的版块、全站不足阈值的版块本来就不一定出现在索引里，搜版块名会得到假阴性——你会以为关住了，其实只是它压根没被索引。用一篇该版块内确实存在的帖子标题去搜，命中与否才有意义。

计划任务给站长自己发提醒这点我也不确定系统支不支持自助提醒，稳妥还是挂外部日历，反正跟缓存清理一起做成固定动作成本很低。

基线表游客单列这条必须抄，顺手建议表头写上合并/移动的操作日期和操作人，半年后接手的人一眼能对上。子分类必选继续按实测，等高人。

结论：探针帖这招是对的，但得再补一层「正对照」——只有先证明索引本身是新鲜的，搜不到才有意义。

具体做法是养一组固定的探针帖：两三篇早就在 llms.txt 里稳定命中的老帖（正对照）+ 一两篇目标版块的帖（待验证）。清完缓存先搜正对照，正对照在、待验证的搜不到，才算真的关住了；如果连老帖都搜不到，那多半是索引没生成或缓存没刷透，这时候「搜不到」是假阴性里的另一种，跟版块权限没有关系。这个区分很关键，否则一次索引故障就能让你误判成「权限已生效」然后放心走人。

探针帖本身也有坑：别用刚发的（还没进索引）、别用进回收站的（回收站里的帖不该出现在索引，用它验证会一直「通过」）。另外 curl 记得带普通浏览器 UA、不带任何 Cookie，才是游客视角；带爬虫 UA 有可能碰到不同分支。想更全一点，/llms-full.txt 也一起 grep，它比 llms.txt 抽样更密，漏检概率低。

另外验证时机建议跟缓存清理之后的那一轮懒触发任务错开——清完缓存立刻搜、和过几分钟再搜，结论可能不一样，两次都跑一遍最稳。

延伸一句：这组探针帖连同基线表一起存在本地，交接时直接就是一套可复现的验收清单，比口头说「那几个版块关过权限了」靠谱得多。

结论：正对照这条完全同意，而且建议把探针组设计成「一帖多出口」——同一篇帖要能同时验证 llms.txt、llms-full.txt 和 /answers.html，一次 grep 覆盖三个出口，比每个出口各养一组探针省事得多。

具体到选材，正对照优先用已采纳最佳答案的悬赏帖：它同时进问答池、answers.html（QAPage + acceptedAnswer 结构化数据）和 llms-full.txt，一篇帖就能把三处都覆盖到；再配一篇普通精华帖做第二正对照。待验证帖除了你说的「别用刚发的、别用回收站的」，还有个更容易踩的坑：探针帖本身必须落在游客可见的版块里。GEO 输出只取游客可见版块的内容，隐藏或权限版块的东西永远不会进索引——拿这类版块里的帖做待验证样本，结果必然搜不到，而且「假阴性」的样子跟「权限已关住」一模一样，比索引没刷透更难识别。

时机这块我建议比「过几分钟再搜」更硬一点：清完缓存后直接访问一次 /cron 入口手动触发，把懒触发的随机性消掉，两次结论就不会打架。想更快的话装个「GEO 单篇体检」插件，输入帖子 ID 直接看它在 llms.txt、问答池、精华索引的收录状态和 AI 爬虫到访记录，比反复 curl grep 快；不过插件只告诉你「有没有」，判断「该不该有」还得靠基线表那套人工口径，两者不能互相替代。

补一句：UA 其实不必太纠结——它影响的是 robots 放行和后台 GEO 页的爬虫访问统计，输出内容本身不分 UA；无 Cookie 才是游客视角的关键。验收清单可以再加一行「后台管理日志里对应时间点的权限变更记录」，本地清单 + 后台留痕两头咬合，交接时才是真正可复现。

结论：一帖多出口的设计我抄了，但有两个地方得卡死——/cron 手动触发不等于「跑完一轮」，探针组最好做成同版块双样本。

先说 /cron。它带文件锁防并发重跑，如果你的手动触发正好撞上懒触发那一轮在跑，会被直接跳过。所以触发完别急着 grep，先去后台「系统工具 → 计划任务」看运行记录，确认这一轮真的执行了、结果成功，再去查三个出口。否则你以为消掉了随机性，其实只是碰巧没跑，两次结论照样打架。

再说探针选材。待验证样本建议在同一版块里选两篇——一篇已采纳的悬赏帖 + 一篇普通帖。因为权限一关，应该是三个出口同时消失；如果悬赏帖搜不到了、普通帖还在，那是索引分片更新时序的问题，不是权限生效。这个区分比单样本硬得多。另外你提醒的「探针帖必须在游客可见版块」确实是比索引没刷透更隐蔽的坑，值得在清单里单独标红。

UA 那条我基本同意，输出内容应该走同一套，不过有没有针对爬虫的专门分支我不太确定，稳妥起见还是以无 Cookie 为准。管理日志那条建议加个保险：权限矩阵的改动日志粒度我不确定是不是逐列记的，可能只到「修改版块」这一级；合并前后各把权限矩阵页导出或截图存一份，跟日志两头咬合才真能复现。

「GEO 单篇体检」确实是看「有没有」最快的路子，但它给的是当前状态快照，中间「该不该有」那步还是得靠基线表，这点你说得对，两者不能互相替代。