🔍 调研报告
社区信息架构调研导航栏目 · 发帖类目 · 栏目增长2026-11-05

社区栏目与发帖类目 · 规划方式调研5 个社区如何把「浏览栏目」和「发帖类目」拆成两层 — SmallRig / DJI / Insta360 / Discourse / Blackmagic

覆盖对象
SmallRig Community（现状基线） · DJI 大疆社区 · Insta360 Community Forum · Discourse（OpenAI 社区） · Blackmagic Forum
调研方式
未登录态页面结构实测 + 业务方截图
证据规模
15 张截图 · 8 份结构记录
输出目的
为主页 tab、菜单与发帖类目的重规划提供依据
调研背景：业务提出两个问题——①社区主页的 tab 与上线的二级栏目（Learning 等）没有关联；②用户发帖时可选类目太多，归类也没有明确规则。目标是在「用户可选类目做减法」的同时，给日益增多的业务栏目找到承载方式。
调研口径：本次只对照结构，不做视觉评审。SmallRig 与 DJI 的首页、发帖页使用业务方截图，其余页面（含两个站的栏目页与圈子页）均为 2026-11-04 无头浏览器实拍，记录导航项、tab、类目 chip、版块列表等稳定结构，不含登录后的个性化视图。汽车之家与 Stack Overflow 仅作边界参照，记录与截图放在「附录-边界样本」，不进正文章节。
核心判断

所有站点都在做同一件事：把「栏目」和「类目」拆成两层

栏目是「去哪个入口看」，类目是「这条内容算什么」。一旦把两者混成一套，每新增一个业务栏目，就必然多一个发帖类目、多一个导航项——这正是 SmallRig 现在的处境。
5
个社区的结构对照
如果你只看这几件事 —
  • 共通点 — 没有一家让用户从 10 个以上语义混杂的类目里做选择：DJI 只有 5 个；Insta360 发帖只有 Board + Category 两个联动下拉；其余社区要么把分类关进容器，要么干脆没有类目。
  • 栏目怎么来 — 三种来源——按用户任务分（DJI：逛 / 找 / 按产品找 / 参与 / 求助；Insta360：学 / 产品 / 兴趣 / 活动 / 求助）；按商品或产品线自动生成容器（Insta360 产品系列、DJI 圈子）；按运营口径做视图（DJI 首页 4 个精选 tab）。
  • 类目怎么加 — 新增业务几乎从不加类目。DJI 加圈子、Insta360 加产品子类、Discourse 加顶级业务线——被强制选择的那一层（内容意图）长期保持 5 个左右。
  • 多入口是常态 — 同一批帖子在多个入口出现并不罕见（DJI 一篇教程可进首页精选、广场、圈子），前提是每个入口有不同口径，而不是把发帖类目原样复制成 tab。Insta360 更进一步：入口只有 6 个，维度全部作为卡片标签与筛选器出现。
  • 失效模式 — 按产品线硬建栏目会产出空栏目（Blackmagic 有 38 个主题的板块）；完全放开会失控（用户自建容器重复、同义标签泛滥）；纯标签会失去策展（Stack Overflow 没有浏览路径）。
  • 边界样本（未单列章节） — 汽车之家、Stack Overflow、Reddit、V2EX 只作边界参照：前两者见「附录-边界样本」；后两者与我们的圈子模型重合（用户自建容器），结论已被 DJI 圈子覆盖，不作为独立论据。
  • 三条可选路线 — A 双轴视图化（推荐）：类目收敛为 5 个内容意图，导航按用户任务做视图；B 容器化：以圈子或品类为容器承载业务栏目，类目退化为容器内筛选；C 标签化：取消固定类目，全用标签与场景。A 解决「归类无规则」，B 解决「栏目越来越多」，建议 A 为主、B 作补充，C 不采用。
  • 对我们的直接价值 — 场景轴（10 个场景）和商品关联已经具备，不需要再加一套；真正要动的是把 10 个 taskCategory 收敛成 4 至 5 个内容意图，并把导航栏目改成「视图」。
强制类目数量
5
DJI 5 个、Insta360 Board 5 个、Discourse 第二层 5 类；进入导航或被强制选择的类目都控制在个位数
内容轴
4
内容意图 / 场景主题 / 产品容器 / 标签，再多一层用户就分不清自己该选哪个
必选数量
1
所有站点发帖都只强制 1 个归属（类目、容器或节点），其余全部选填

横向对比

对象发帖必选什么类目数量浏览入口怎么分类目与导航的关系新增业务往哪落主要风险
SmallRig（现状）Category 必选，另有 Scenario / Product / Tags 选填10 个，语义混杂导航 5 项 + 首页 tab 7 个无映射，三套并行新增类目或新增导航项类目只增不减，用户无法判断
DJI 大疆社区主要分类 5 选 15 个，全部是意图按任务：首页 / 广场 / 圈子 / 活动 / 咨询5 类被 3 个入口分流，一个类目可有独立页新机型进圈子，新活动进活动页19 项圈子接近导航上限
Insta360Board 必选 + Category 随 Board 变化Board 5 个；Category 各栏 3 至 8 个按动作：学 / 产品 / 兴趣 / 活动 / 求助导航 6 项不含分类；二级只在发帖时出现新品进 Products 子类二级语义随栏变化，跨栏不可比
Discourse类目必选，子类目可选11 顶级 + 最多 5 子类顶级类目页 + 最新流第一层业务线，第二层内容意图新增顶级类目，子类目套模板两层认知成本，Uncategorized 兜底
Blackmagic必须选版块12 个版块 / 3 分组版块列表（无聚合层）版块即栏目，一一对应新品新建版块冷门版块长期空置
01

SmallRig Community（现状基线）

三套体系并行

导航 5 项、首页 tab 7 个、发帖类目 10 个，三者互不映射；同时已有独立的场景轴与商品关联，圈子功能已在设计中——如果不先定关系，会变成四套并行分类。

基本信息

项内容
站点SmallRig Community（现网 + 发帖页）
调研链接https://www.smallrig.com/community ／ https://www.smallrig.com/community/tutorials ／ https://www.smallrig.com/community/scenario-guide ／ https://www.smallrig.com/community/creator-club ／ https://www.smallrig.com/community/post/edit
页面结构顶部社区导航 5 项（Home / Learning⌄ / TaskPay / Task Center / Shoot the World⌄）；Home 信息流 7 个 tab（ALL、General、Product Reviews、Tutorials、Upgrade Rig、Task、Discover）；发帖页 10 个类目 + Scenario 最多 3 个 + Related Product 最多 2 个 + Tags 最多 20 个
调研日期2026-11-04
调研方式PC 端 DOM 实测 + 业务方截图
环境说明未登录可浏览；发帖页需登录，类目 chip 在未登录态仍可渲染

交互机制（实测拆解）

1
导航是业务入口，不是分类入口
Learning 下拉是 Tutorials / Scenario Guide，Shoot the World 下拉是 Creator-Club；TaskPay、Task Center 是工具页，Creator-Club 是线下活动页。5 个导航项里只有 Home 是信息流。
2
首页 tab 是第三套分类
ALL、General、Product Reviews、Tutorials、Upgrade Rig、Task、Discover 共 7 个 tab，直接筛帖子；其中 Learning、TaskPay、Task Center、Creator-Club 在 tab 里没有对应项，而 tab 里的 Task、Discover 在导航里没有对应入口。
3
发帖要同时作答四道题
Category（必选，10 选 1：Product Reviews、Creative Rigs、Featured Works、Feature Requests、Get Help、DreamRig、Rig Studio、General、Upgrade Rig、Tutorials）、Scenario（选填，最多 3，来自场景百科的 10 个场景 + New Scenes）、Related Product（选填，最多 2）、Tags（最多 20）。
4
类目语义混杂
10 个类目里同时存在内容形态（Product Reviews、Tutorials、Featured Works）、产品线（DreamRig、Rig Studio、Upgrade Rig）、诉求类型（Feature Requests、Get Help）、兜底（General）、活动（Creative Rigs），没有统一维度。
5
栏目页各自定制
Tutorials 是独立页，带 Product / Posted By 两个筛选；Scenario Guide 是场景聚合页，按 10 个场景分组展示；两者都不使用首页那套 topic-tab。
6
同一批帖子多入口重复出现
一篇 Tutorial 帖子可同时出现在 Home 的 ALL、Home 的 Tutorials tab、Learning 下的 Tutorials 页；场景内容还会再出现在 Scenario Guide 页与 hashtag 检索里。

结构记录（实测取证）

#观察点现状推论
1导航与发帖类目Learning 的二级项叫 Tutorials，发帖类目里也有 Tutorials，同名前不同层用户无法判断「选 Tutorials 类目」和「进 Learning 栏目」是不是一回事
2首页 tab 与导航tab 有 Task、Discover；导航有 TaskPay、Task Center、Creator-Club，两边互不覆盖两套入口各自维护，新增业务时没有规定该加到哪一侧
3发帖类目数量10 个，且 6 个是新业务期陆续加的类目是「新业务落地」的默认手段，没有准入规则
4场景轴已有独立场景轴（10 个场景 + New Scenes），但只在 Scenario Guide 页和 hashtag 里被消费第三套轴已经存在，却和类目、导航都不打通
5圈子圈子功能（20261111）已在设计：用户申请 + 审核，帖子最多归属 1 个圈子，Topic 初始 4 类若不先定关系，圈子会成为第四套并行体系
6后台后台按「所属栏目 type / 主题 category / 子分类 taskCategory」三层组织帖子前台看到的 10 个类目实际是 taskCategory，上游还有两层用户在发帖时看不到

截图证据

首页：导航 5 项 + 信息流 7 个 tab，红框为两套并行分类
截图1首页：导航 5 项 + 信息流 7 个 tab，红框为两套并行分类
发帖页：10 个类目 chip 平铺，另有 Scenario / Related Product / Tags
截图2发帖页：10 个类目 chip 平铺，另有 Scenario / Related Product / Tags
Learning 下的 Tutorials 独立页：自带 Product / Posted By 筛选，页面没有 topic-tab
截图3Learning 下的 Tutorials 独立页：自带 Product / Posted By 筛选，页面没有 topic-tab
Scenario Guide 独立页：按 10 个场景聚合，同一批帖子换了第三种入口
截图4Scenario Guide 独立页：按 10 个场景聚合，同一批帖子换了第三种入口

优点 / 缺点

✅ 优点

  • 已有场景轴与商品关联能力（Related Product、Scenario），内容是「结构化的」，具备做聚合视图的基础。
  • 业务栏目已经用独立页承载（Tutorials、Scenario Guide、Creator-Club），页面形态不受类目限制。
  • 帖子审核、品牌帖、任务等后台能力齐备，改造前台分类不需要重做内容链路。

⚠️ 缺点 / 风险

  • 三套体系（导航 5 项 / 首页 tab 7 个 / 发帖类目 10 个）互不映射，用户发帖时归类无依据，浏览时也不知道栏目差异。
  • 类目承担了「业务栏目落地」的职责，每加一个业务就要加一个类目，数量只增不减。
  • 类目语义跨维度混排，导致运营无法用一句话解释「什么时候选哪个」。
  • 圈子功能上线后会再叠加一层容器，若不定义关系，会变成四套并存。

可借鉴点

需避免 / 注意
不要再引入第四套并行分类；先明确「导航=视图、类目=内容意图、场景=主题、圈子=人群」四者分工。
可借鉴
现有场景轴和产品关联可以直接当作「浏览侧维度」，不需要用户发帖时再承担分类负担。
可借鉴
类目可以直接从 10 个收敛，存量帖子不迁移（已有后台字典能力，参考圈子 PRD 的初始化口径）。
02

DJI 大疆社区

5 类意图 + 任务型导航

发帖只选 5 个「我想干什么」，导航按用户任务分（逛 / 找 / 按产品找 / 参与 / 求助）；首页 tab 是运营精选而非分类，产品线扩张用圈子承接，类目数量不跟着涨。

基本信息

项内容
站点DJI 大疆社区（bbs.dji.com）
调研链接https://bbs.dji.com/ ／ https://bbs.dji.com/pro/square ／ https://bbs.dji.com/pro/group ／ https://bbs.dji.com/pro/consult
页面结构顶部导航 5 项（首页、广场、圈子、活动、咨询）；首页信息流 tab 4 个（推荐、优质教程、体验评测、优选作品）；广场 tab 4 个（全部、产品讨论、作品分享、教程技巧）；咨询 tab 3 个（全部、官方公告、咨询与售后）；圈子页 19 项，按产品系列划分（含「商用产品」「其他」两个兜底）
调研日期2026-11-04
调研方式PC 端实测（导航 / 广场 / 圈子 / 咨询逐页取证）+ 业务方发帖页截图
环境说明未登录可浏览全部列表；发帖需登录，发帖页分类为 5 个主要分类

交互机制（实测拆解）

1
导航按用户任务分，不按内容类型分
逛（首页）、找（广场）、按产品找（圈子）、参与（活动）、求助（咨询）。5 个导航项覆盖 5 种行为，没有一项叫「分类」。
2
发帖只回答一个问题
主要分类 5 选 1——产品讨论、活动投稿、作品分享、教程技巧、咨询求助。语义全部是「我想干什么」，不掺产品线和活动名。
3
类目与导航是映射关系，不是复制关系
作品分享、产品讨论、教程技巧进广场；咨询求助单独进咨询页（内部再分官方公告 / 咨询与售后）；活动投稿进活动页。5 个类目被 3 个入口分流，发帖类目多于浏览入口。
4
首页 tab 是运营精选，不是分类
推荐、优质教程、体验评测、优选作品——用户看不到「产品讨论」这类原始类目，看到的是编辑结果。分类浏览被收进广场的 3 个 tab。
5
圈子是产品线容器，与类目正交
19 项圈子（Pocket、Osmo 360、Avata、Neo、Lito、Mobile、Nano、Mini、ROMO、Flip、Air、Mavic、Action、FPV、Inspire、Phantom、Ronin、商用产品、其他）由官方按产品线建，用户先按产品找内容，再按内容类型筛选。
6
帖子卡片带多个弱标签
列表卡片上会显示「随拍」这类短标签与圈子归属，类目本身不刷在卡片上，避免卡片信息过密。
7
类目落库成「主题分类 typeid」，tab 是它的分桶视图
接口里每条帖子带 typeid，产品讨论=672、作品分享=673、教程技巧=674、咨询求助=675、活动投稿=676。广场的三个 tab 就是用这三个 typeid 分桶，其中「全部」是 672∪673∪674 的并集。
8
首页四个 tab 是「在桶之上再精选」
频道 slug 为 home-recommended-selected / -tutorial / -reviews / -post。抽查发现「体验评测」的首条帖子 typeid=672（产品讨论）、「优选作品」的首条 typeid=673（作品分享）——它们与广场同名桶是同一批内容，但只取人工挑选的子集，所以首页不是全量。

结构记录（实测取证）

#观察点事实推论
1发帖类目数5 个，全部是动作/意图表述类目可以同时很小又覆盖业务（活动、求助各有一类）
2类目与浏览入口广场只暴露 5 类中的 3 类；咨询求助不在广场出现浏览侧入口可以少于发帖类目，两类不必一一对应
3首页 tab4 个 tab 全部是精选口径，没有原始类目首页承担「发现」，不承担「分类完整性」
4圈子数量19 项（含两个兜底项），且随产品线增长容器数量可扩张，但需要独立页面承接，不能塞进导航
5新业务承载新机型 → 新增圈子；新活动 → 活动页；不新增发帖类目业务增长走「容器」和「活动页」，不走类目
6typeid 映射抽样 4 条帖子详情：产品讨论 672、作品分享 673、教程技巧 674、咨询求助 675、活动投稿 6765 个类目是一组固定的主题分类 ID，不是前端硬编码的 tab
7广场是否等于并集广场「全部」最近 100 条，100% 落在三个 tab 内；三个 tab 两两交集为 0「全部」就是三个桶的并集，tab 是纯分桶视图，不是三套独立内容
8两类是否被排除咨询最近 20 条、活动最近 6 条，在广场最近 200 条里命中 0 条咨询求助与活动投稿既不进广场，也不进「全部」
9首页是否全量首页四个频道与广场同名桶的近 100 条交集为 0，但抽查帖子 typeid 相同首页是「同桶不同集」：类目相同，只取人工精选，所以看不到全量

截图证据

首页：导航 5 项 + 信息流 4 个精选 tab，红框为两层结构
截图1首页：导航 5 项 + 信息流 4 个精选 tab，红框为两层结构
发帖页：主要分类只有 5 个 chip
截图2发帖页：主要分类只有 5 个 chip
圈子页：19 项产品线圈子平铺，与发帖类目正交
截图3圈子页：19 项产品线圈子平铺，与发帖类目正交
咨询页：5 个类目中的「咨询求助」单独成页，页内再分 3 个 tab
截图4咨询页：5 个类目中的「咨询求助」单独成页，页内再分 3 个 tab

优点 / 缺点

✅ 优点

  • 5 个类目语义统一（都是用户意图），新用户一秒能选完。
  • 导航与类目之间有明确映射，且允许一个类目对应独立页面（咨询）。
  • 首页用精选 tab 替代分类 tab，把「分类完整性」压力从首页移走。
  • 产品线扩张用圈子承接，类目数量不跟着涨。

⚠️ 缺点 / 风险

  • 19 项圈子已接近导航承载上限，圈子页只能平铺列表，依赖搜索找圈子。
  • 「活动投稿」在浏览侧几乎不出现，作者选了之后获得感弱。
  • 圈子与类目正交，若某圈子内容量小，圈内会出现「只有 1 类内容」的空洞感。

可借鉴点

可借鉴
发帖类目收敛到 5 个「我想干什么」级别的意图，是最直接可抄的结构。
可借鉴
允许「一个类目对应一个独立页面」（咨询求助 → 咨询页），不必所有类目都挤在同一个信息流里。
可借鉴
首页 tab 用运营精选口径，而不是把发帖类目原样搬上首页。
需避免 / 注意
容器（圈子）扩张要有独立列表页和搜索，否则 15 个以上就不可用。
03

Insta360 Community Forum

6 项导航 + 两级发帖

同品类海外站：导航 6 项全部是用户动作；发帖只有 Board + Category 两个联动下拉；产品线只做 Products 子类，Help 区把「分类 / 产品 / 处理状态」做成 3 个筛选器，卡片用 pill 展示维度。

基本信息

项内容
站点Insta360 Community Forum（forums.insta360.com，海外版）
调研链接https://forums.insta360.com/?c=feed ／ https://forums.insta360.com/section/14/ ／ https://forums.insta360.com/section/17/
页面结构顶部导航 6 项（Home、Tutorials & Tips、Products、Hobbies、Events、Help & Feedback）；首页信息流 tab 3 个（Featured、Recent、Last updated）；Products 区内 10 个子类（All、Updates、Insta360 X Series、Ace Series、GO Series、Flow Series、ONE R&RS、ONE&EVO、Professional Gear）；Help & Feedback 区 3 个筛选器（All categories、All products、All processing status）
调研日期2026-11-04
调研方式PC 端实测（未登录态）+ 无头浏览器截图 + 业务方发帖页截图
环境说明浏览开放；发帖页由业务方登录后截图补证，结构为 Title + Board + Category 三项

交互机制（实测拆解）

1
导航按内容目的分 6 项，没有一项叫分类
Home 是信息流；Tutorials & Tips、Hobbies 是内容形态；Products、Events、Help & Feedback 是容器/业务入口。
2
产品线不进导航，只作为容器内的子类
Products 区把全系产品收成 7 个系列子类（X / Ace / GO / Flow / ONE R&RS / ONE&EVO / Professional Gear），新品只进子类，导航不变。
3
发帖入口按意图分流
右侧固定两个按钮——SHARE A POST（作品/分享）与 ASK FOR HELP（求助），用户先选意图，再选归属。
4
发帖只有两个下拉，且是联动的
Board（必选，5 个分区）+ Category（随 Board 变化）。Board 选 Tutorials & Tips 时，Category 是 Starter / Advanced / Creator Tips；Board 选 Products 时，Category 变成 Updates / X Series / Ace Series / GO Series / Flow Series / ONE R&RS / ONE&EVO / Professional Gear。
5
分类不做 tab，做筛选器
Help & Feedback 区把「分类 × 产品 × 处理状态」做成 3 个下拉筛选，而不是三排 tab；列表保持单一流。
6
维度全部以元数据展示在卡片上
卡片左侧 pill 显示所属分区（Products / Tutorials & Tips / Questions / Bug），旁边再显示产品（X5 / X6 / Insta360 Studio）与处理状态（Solved / Pending / Resolution Handling / Reported），标题下方是 hashtag。
7
信息流只有排序，没有分类 tab
首页 Featured / Recent / Last updated 三个 tab 是排序口径，不是内容分类。

结构记录（实测取证）

#观察点事实推论
1导航数量6 项，含 3 个容器/业务入口品牌社区可以把「学、买、玩、参加、求助」直接做成导航，不需要分类 tab
2产品线位置7 个系列子类挂在 Products 下，导航层不出现产品线扩张只影响容器内子类，不影响导航
3分类位置Help 区 3 个下拉筛选，不是 tab维度多时用筛选器，列表保持单流
4状态维度Solved / Pending / Resolution Handling / Reported 四种求助类内容需要「处理状态」这一维，且状态是运营可见的
5发帖入口SHARE A POST 与 ASK FOR HELP 两个发帖先选意图，比选类目更省认知
6发帖表单Title + Board + Category 三项，Board 必选、Category 联动两级下拉替代平铺 chip，用户只需回答两次
7二级语义Tutorials 下是难度/类型（Starter / Advanced / Creator Tips），Products 下是产品系列二级按栏目定制，灵活但跨栏不可比

截图证据

首页信息流：只有 Featured / Recent 排序 tab，卡片左侧挂栏目 pill（Products / Tutorials & Tips），右侧是 SHARE A POST 与 ASK FOR HELP 两个发帖入口
截图1首页信息流：只有 Featured / Recent 排序 tab，卡片左侧挂栏目 pill（Products / Tutorials & Tips），右侧是 SHARE A POST 与 ASK FOR HELP 两个发帖入口
Products 区：10 个子类平铺，产品系列全部收在容器内，导航层不出现
截图2Products 区：10 个子类平铺，产品系列全部收在容器内，导航层不出现
Help & Feedback 区：分类 / 产品 / 处理状态 三个筛选器，卡片同时显示 [Questions][X5][Solved]
截图3Help & Feedback 区：分类 / 产品 / 处理状态 三个筛选器，卡片同时显示 [Questions][X5][Solved]
发帖页（Board = Tutorials & Tips）：Category 下拉只有 Starter / Advanced / Creator Tips
截图4发帖页（Board = Tutorials & Tips）：Category 下拉只有 Starter / Advanced / Creator Tips
发帖页（Board = Products）：同一位置 Category 变成 8 个产品系列
截图5发帖页（Board = Products）：同一位置 Category 变成 8 个产品系列

优点 / 缺点

✅ 优点

  • 导航只有 6 项，且每项都是一个用户动作，没有「General / Other」这类兜底项。
  • 产品线增长被关进 Products 子类，导航与类目数量都不受影响。
  • 用筛选器而不是 tab 承载多维信息，列表页不会因为维度增加而变复杂。
  • 卡片同时展示「分区 + 产品 + 状态」，用户不进详情就能判断内容是否与自己相关。

⚠️ 缺点 / 风险

  • 6 个导航项里有 3 个是容器，Home 的信息流实际上承担了「全部内容」的兜底，首页 burden 较重。
  • 卡片上同时出现 4 种元数据（分区、产品、状态、hashtag），信息密度偏高，弱化标题。
  • 二级 Category 的语义随 Board 变化（难度 / 产品系列），跨栏无法用同一口径统计，也无法做统一的「内容类型」筛选。
  • 发帖表单只有 Board + Category，没有独立的场景/主题维度，教程与作品的区分只能靠 Board 承担。

可借鉴点

可借鉴
发帖先分意图（分享 / 求助），比让用户在 10 个类目里挑更容易。
可借鉴
两级下拉（先 Board 再 Category），比 10 个 chip 平铺省认知；我们可以做成「内容意图 → 子类型」。
可借鉴
产品线只做容器内子类，不做导航项——直接对应我们 DreamRig / Rig Studio / Upgrade Rig 的处理方式。
可借鉴
维度多时用筛选器 + 卡片元数据，不要用 tab 堆；这可以替代首页现在的 7 个 tab。
需避免 / 注意
二级语义全按栏目定制会牺牲跨栏可比性，我们如果要统一统计，二级应保持全站同一套（如难度、类型）。
需避免 / 注意
卡片元数据不要超过 3 个，否则标题被淹没。
04

Discourse（OpenAI 社区）

两层类目 + 子类目模板

第一层按业务线，第二层按内容意图（Bugs / Feature requests / Support / Use cases），子类目模板跨业务复用；新增业务线只动第一层。

基本信息

项内容
站点community.openai.com（Discourse 架构，同类社区可复用同一套机制）
调研链接https://community.openai.com/categories
页面结构11 个顶级类目 + 子类目：Announcements、API（Bugs / Feedback / Deprecations）、ChatGPT（Bugs / Feature requests / Use cases and examples / Support / Dots）、ChatGPT Apps SDK、Open Models、Codex（Codex CLI / Bugs / Feature Requests）、Prompting、Documentation、GPT builders（Plugins-Actions builders / Plugin store）、Forum feedback、Community、Uncategorized
调研日期2026-11-04
调研方式PC 端实测（类目页 DOM 取证）
环境说明未登录可浏览类目与帖子；发帖需登录

交互机制（实测拆解）

1
第一层是业务线，第二层是内容意图
顶级类目按产品/业务划分（API、ChatGPT、Codex、Open Models…），子类目按内容类型划分（Bugs、Feature requests、Support、Use cases and examples）。同一套子类目模板在多个顶级类目下复用。
2
发帖必须有类目
类目是必选项，子类目可选，标签作为横切补充。平台保留「Uncategorized」作为兜底，说明强制类目在真实使用中仍有摩擦。
3
类目页可配置成不同形态
既能做成「子类目导航页」，也能做成「该类的全量最新流」，栏目形态由管理员配置而非写死。
4
新增业务线 = 新增第一层类目
不需要动导航结构，也不需要给每个业务线设计一套内容类型；子类目直接套用模板。
5
帖子归属唯一类目
一篇帖子只属于一个类目（可加标签），类目页因此是「全量」，而标签页是「横切聚合」。

结构记录（实测取证）

#观察点事实推论
1层级11 个顶级类目，其中 4 个带子类目，最多 5 个子类目两层足够，不需要第三层
2子类目复用Bugs 同时出现在 API、ChatGPT、Codex 下内容意图模板可复用，新业务接入成本低
3兜底类目存在 Uncategorized强制类目必须有兜底，否则用户卡在发帖页
4内容规模API 24.7k 主题、ChatGPT 28.8k、Codex 2.0k类目能承载万级内容而不拆分，说明不必靠加类目解决体量
5冷门类目Documentation 526 主题、Open Models 42 主题业务线类目允许冷门存在，不需要为了「看起来满」而合并

截图证据

Categories 页：第一层是业务线（API / ChatGPT / Codex…），第二层是内容意图（Bugs / Feature requests / Support…），左侧另列 Tags
截图1Categories 页：第一层是业务线（API / ChatGPT / Codex…），第二层是内容意图（Bugs / Feature requests / Support…），左侧另列 Tags

优点 / 缺点

✅ 优点

  • 业务线增长只影响第一层，内容类型层保持稳定，用户心智不会每次重构。
  • 子类目模板化，新增栏目不需要重新设计分类体系。
  • 同一类目页可以切换「导航视图 / 全量流」，运营灵活。

⚠️ 缺点 / 风险

  • 两层类目对普通用户仍有认知成本，Uncategorized 长期存在就是证据。
  • 顶级类目按内部产品架构划分，外部用户不一定知道自己的问题属于哪个产品。
  • 标签与类目并存，后台治理成本高。

可借鉴点

可借鉴
「第一层业务线、第二层内容意图」的两层结构，是让栏目可持续增长最省力的做法。
可借鉴
内容意图子类目做成模板，新业务直接套用，避免每次重定义。
需避免 / 注意
必须有兜底类目，否则用户会在发帖页流失；兜底应尽量少用（后台设阈值监控）。
05

Blackmagic Forum

版块制（产品线绑定）

一个产品线一个版块，发帖必须选版块且无标签；结构稳定，但冷门产品线会长期空置，新品越多空栏目越多。

基本信息

项内容
站点Blackmagic Design Forum（phpBB 架构，相机/后期硬件品牌社区）
调研链接https://forum.blackmagicdesign.com/index.php
页面结构3 个分组（General、Software Development、Other Topics）+ 12 个版块：Getting Started、Cinematography、Post Production、Live Production、Fairlight Live、Immersive Production、DaVinci Resolve、Fusion、Blackmagic Cloud、Software Development and OEM Integration、Announcements、Off-Topic
调研日期2026-11-04
调研方式PC 端实测（未登录）
环境说明浏览开放；发帖需注册

交互机制（实测拆解）

1
栏目即版块，板块即唯一归属
发帖必须选一个版块，没有标签，也没有聚合页；用户找内容只能从版块列表进。
2
版块按「产品线 + 工作阶段」划分
Cinematography（拍摄）、Post Production（后期）、Live Production（直播）、Fairlight Live（音频产品）、Immersive Production（沉浸式相机），是产品与工作流的混合维度。
3
板块随产品线硬增长
新硬件发布就新建板块，Fairlight Live 只有 115 个主题、Immersive Production 只有 38 个主题，仍保持独立板块。
4
不设聚合层
首页就是版块列表，没有「全部最新」「精选」入口，也没有跨板块的内容视图。

结构记录（实测取证）

#观察点事实推论
1版块数量12 个，3 个分组产品线多时，板块数量会线性增长
2冷门板块Fairlight Live 115 主题、Immersive Production 38 主题，对比 DaVinci Resolve 112975 主题按产品线建栏目会产出长期空栏目
3发帖必填必须选板块，且无标签补偿唯一归属让内容不能跨栏目复用
4入口只有板块列表，无聚合视图栏目越多，首页越长，且没有「今天有什么」

截图证据

论坛首页：12 个版块按 3 个分组排列，每块带主题数；Fairlight Live 仅 115 主题、Immersive Production 仅 38 主题，仍各占一格
截图1论坛首页：12 个版块按 3 个分组排列，每块带主题数；Fairlight Live 仅 115 主题、Immersive Production 仅 38 主题，仍各占一格

优点 / 缺点

✅ 优点

  • 结构极其稳定，一个产品线一个板块，用户能预期内容在哪。
  • 板块内全量内容，没有算法与精选干扰，适合深度技术讨论。

⚠️ 缺点 / 风险

  • 冷板明显（38 个主题的板块仍占首页一席），栏目数量被产品线绑死。
  • 无聚合视图，跨产品线的通用话题（如存储、调色）会被拆散在不同板块。
  • 唯一归属导致同一内容无法在多栏目曝光，新栏目必须自带流量。

可借鉴点

需避免 / 注意
「新品=新栏目」是最容易踩的坑，SmallRig 的 DreamRig、Rig Studio、Upgrade Rig 已是同类信号，应改为容器而不是栏目。
可借鉴
栏目内全量、不掺算法，适合教程与技术类内容做沉淀。
需避免 / 注意
必须有聚合层，否则栏目一多首页就变成目录页。
06

启示与决策点

Design Rules

设计红线

1
一个帖子只强制一个归属
5 个对象全部只强制 1 个选择，其余（标签、场景、商品）都是选填。SmallRig 现在 Category 必选之外还有 Scenario，属于必要，但 Category 本身必须收敛。
2
类目只表达内容意图，不表达业务栏目
DreamRig、Rig Studio、Upgrade Rig 是产品线或活动，不是内容意图；Hardware 里混着「作品 / 教程 / 评测 / 求助 / 活动」以外的语义，必然失控。
3
导航项必须是视图，不是类目集合
DJI 的首页 4 个精选 tab、Insta360 的 3 个筛选器都是「换一种看法」，不是「列一遍类目」。首页 tab 与发帖类目同源，是当前最直接的问题。
4
业务增长走容器或视图，不走类目
产品线增长 → 容器（圈子 / 品类）；运营活动增长 → 视图或独立页。类目层保持不变，用户的归类习惯才不会被反复打断。
5
多入口必须口径不同
同一帖子可出现在精选、栏目页、容器页，但每个入口的筛选条件要写清楚（精选 / 全量 / 该产品线），否则运营无法解释差异。
6
兜底类目必须存在且被监控
Discourse 保留 Uncategorized，说明强制类目有摩擦；我们的 General 可以先留，但要按周看占比，超过阈值就说明类目设计有问题。

需要拍板的决策点

待拍板决策点我们的建议
发帖类目收敛到几个、按什么口径？建议 5 个内容意图：作品 / 教程 / 评测 / 求助 / 活动（对齐 DJI）。DreamRig、Rig Studio、Upgrade Rig 从类目里移出，改由容器或活动页承载
浏览栏目怎么定？按用户任务：逛（Home）/ 学（Learning）/ 做任务（Tasks）/ 秀（Shoot the World）/ 圈子（Groups），每个栏目回答一个动作，不回答「内容类型」
业务栏目增长优先走哪条路？优先「视图」（同一批内容换口径聚合）→ 其次「容器」（有独立人群或独立品类）→ 最后才考虑新增类目
首页 tab 与发帖类目是否同源？不同源。首页 tab 用精选或运营口径，类目筛选收进二级页或筛选器；tab 数量控制在 5 个以内
场景轴放哪？保留为浏览侧第二维度（Scenario Guide），发帖时的 Scenario 选填保持不变，不与类目合并，也不进导航主项
类目超过 10 个怎么办？收进容器内做筛选（Insta360 把产品线做成 Products 子类、维度做成筛选器），不进一级导航；容器内筛选可以多，导航项不能多
存量 10 个类目怎么处理？只做映射关系，不迁移历史帖子；新帖按新类目，后台保留旧值可查（与圈子 PRD 的初始化口径一致）
圈子与栏目的关系？圈子是容器不是栏目：导航只给 Groups 一个入口，圈内不再设二级栏目，避免第四套体系
07

调研方法与说明

Method & Sources

统一调研法

1
选对象
覆盖两类：品牌社区（DJI、Insta360、Blackmagic）、开发者社区（Discourse）
2
固定四个观察问题
①导航怎么分 ②发帖要选什么、几个 ③帖子怎么进栏目 ④新增业务往哪落
3
取证方式
未登录态实测页面结构，抓取导航项、tab 文案、类目 chip、版块列表与子类目列表
4
记录口径
只记录页面上可见的稳定结构，不推断后台配置；截图与链接均随记录留存

调研来源

对象调研链接实测日期
SmallRig Communityhttps://www.smallrig.com/community ／ https://www.smallrig.com/community/post/edit2026-11-05
DJI 大疆社区https://bbs.dji.com/ ／ https://bbs.dji.com/pro/square ／ https://bbs.dji.com/pro/group2026-11-05
Insta360 Community Forumhttps://forums.insta360.com/?c=feed ／ https://forums.insta360.com/section/14/2026-11-05
Discoursehttps://community.openai.com/categories2026-11-05
Blackmagic Forumhttps://forum.blackmagicdesign.com/index.php2026-11-05

📋 说明与声明

本报告只呈现实测到的结构事实与横向对比，不对任何平台的运营效果做评价；结论以页面结构与截图为准。

环境限制：全部截图取自 2026-11-04 未登录态；Insta360 发帖页与 SmallRig、DJI 首页由业务方登录后截图补证。各站点结构与类目可能随版本调整，复现请以当日实测为准。