产品形态
多社区聚合平台（Reddit 式）。每个社区是独立站点：自有品牌、主题色、规则、版主与专属菜单树。 平台方提供身份、内容、互动、检索与治理能力。
!See translation tasks
This page is not translated yet
The interface, navigation and community content are bilingual. The long-form body of this page is still in Chinese. The translation work is tracked as task I18N-10.
Ruyi Community · 产品与技术设计 v3.3
一个「社区即站点」的讨论平台，从界面到数据表的完整设计
把 Reddit、Hacker News、V2EX、Discourse、Lemmy、掘金、贴吧、知乎、Lobsters 的功能骨架拆开，分析其设计动因与代价，再重新组装成可直接进入开发的模块化设计。v3.0 做了一次彻底的界面重做 —— 从「SaaS 官网」转向「信息优先」的社区界面；v3.1 把社区目录放到万级规模下重新设计，并把布局问题逐项量化修掉；v3.2 把全部设计文档拆成 58 条可指派、可验收的工程任务；v3.3 落地中英双语 —— 语言协商、手动切换、社区的英语版本与 hreflang 一起打通，界面与社区内容全量双语，长篇正文的翻译作为独立任务继续推进。
- 调研产品
- 9 个
- 功能模块
- 13 个
- 数据表
- 53 张
- 社区规模
- 1.3 万
v3.x 重做的四件事
上一版把功能铺得很宽，但界面形态还带着「官网」的影子，社区目录也只是一堵卡片墙。v3.0 换掉视觉语言，v3.1 把「看着不对」的地方逐个数出来修掉。
视觉
全站界面按「信息优先」重做
去掉渐变、大圆角、大留白与全大写小标签这些「官网感」的来源，改为带灰画布 + 纯白卡片 + 1px 实描边 + 小圆角 + 12/14px 紧凑字阶。配色只保留一个行动色（暖橙红），正文链接用强蓝，其余全是中性灰。
看设计语言与布局规范 →规模社区目录面向万级社区
原来的目录是一堵静态卡片墙，社区一多就没法用。现在改为「搜索 + 16 个领域 + 四种排序 + 三档密度」，并以 12,883 条数据实测检索、筛选、分批加载与 URL 状态同步。
打开社区目录 →适配任意 slug 都能打开，不再 404
旗舰社区用人工维护的菜单与专属 SFC；其余上万条目录社区走一套标准站点骨架，两者产出同一个 Community 形状 —— 因此「几万个社区」里每一个都能被点开，而不是点进去报错。
看一个目录社区 →v3.1把「看着挤」拆成三个可量化的错
目录页曾经只有 349px 宽：两层三栏栅格套在一起、断点按视口写、组件类没进级联层。逐个量出来修掉后中栏回到 653px，并在 13 个视口宽度上自动断言无溢出、无裁切、列对齐。
看这三处是怎么查出来的 →设计语言速览
下面这些不是示意图，是 app/assets/css/main.css 里的实际取值。整站所有组件都只从这套令牌里取色、取圆角、取字号。
行动色 · 暖橙红
brand-500#d93d16
brand-50#fef4f1
brand-600#bd3211
brand-900#611d0e
全站只有这一个行动色。它出现在主按钮、赞同、Logo、当前选中项上 —— 出现得越少，越有指向性。
中性色 · 冷灰
ink-900#14171a
ink-600#55626b
ink-400#98a4ac
ink-100#eef0f2
line#dfe3e7
canvas#eaedef
画布（canvas）比卡片深一档，层次靠底色差建立，而不是靠阴影与渐变 —— 这是「不像 SaaS」的关键一步。
语义色 · 只在有含义时出现
up#d93d16赞同
down#5a7fd6反对
link#0b6bcb正文链接
online#0d8a4f在线 / 成功
赞同用暖红、反对用冷蓝（中文语境习惯），链接用强蓝。三者互不借用，扫读时不会误判含义。
圆角 · 整体收紧
rounded4px小标签
rounded-md6px控件 / 行
rounded-lg6px面板
rounded-2xl12px卡片
rounded-full999px胶囊 / 头像
字阶 · 页面按 14px 排版
30px社区目录与树形评论页标题
19px社区目录与树形评论小节标题
15.5px社区目录与树形评论帖子标题
14px社区目录与树形评论正文
13px社区目录与树形评论次级正文 / 导航
12px社区目录与树形评论元信息
11px社区目录与树形评论分组标签
控件 · 一套就够
1.2K
-12
教程经验求助
我们要造的是什么
一句话：一个「社区即站点」的讨论平台。社区不只是帖子列表，而是一套可以用菜单无限延展的内容结构。
差异化在哪里
现有社区产品的导航层级普遍停在 2–3 层。我们把「无限级菜单 → 独立 slug 页面」做成地基， 让一个技术社区真正承载「框架 → 生态 → 方案」这类纵深信息架构。
技术边界
只用 Ubuntu 26 / Nginx / Nuxt 4 / Rust / MySQL / Redis / Meilisearch。 不做自研搜索引擎、不做 K8s、不做原生 App —— 在验证产品价值之前，任何基础设施都属于负债。
八条设计原则
这些原则决定后面所有模块的取舍方向：当两个方案冲突时，回到这里看哪一条更重要。
01
社区是一等公民
把 Subreddit / 吧 / 节点统一抽象为 Community 实体。社区拥有独立规则、版主、主题色与专属菜单，平台只供给基础能力与底线治理。
02
菜单即信息架构
技术社区天然需要「框架 → 生态 → 方案」这类四五层结构。菜单写死在代码里就要发版才能加板块；变成数据 + 注册表，运营侧自己就能长出站点结构。
03
排序决定生态
排序算法是社区最核心的杠杆：它决定谁被看见，进而决定创作者的激励。热度公式必须内建时间衰减，同时保留人工可调与离线校准。
04
讨论要成为一棵树
线性评论区只能容纳一条主线，树形结构让多个分支并行生长。需要折叠、排序、深层自动收敛三条路径协同。
05
界面必须为密度服务
社区不是落地页。用户是来连续滚动几百条内容的，所以画布要带灰、卡片要无阴影、字阶要紧凑、动画要短。任何「更大气」的改动都要先问它牺牲了多少可读条数。
06
治理先于增长
垃圾内容淹没社区的速度远快于运营的反应速度。必须在用户量起来之前建立「举报 → 自动隐藏 → 版主复核 → 管理员兜底」四层闭环。
07
只用手上有的工具
Ubuntu 26 + Nginx + Rust + MySQL + Redis + Meilisearch + Nuxt 4，七个组件覆盖全部需求。每多引入一个要运维的进程，就多一处会在凌晨三点出问题的地方。
08
数据主权归用户
用户的帖子、评论、投票记录都应可导出；社区 Owner 可归档社区内容。开放 API 与数据导出不是负担，而是信任的基础设施。
推荐阅读路径
按「界面 → 功能 → 实现 → 计划」的顺序读，比从头翻到尾更高效。
当前交付状态
诚实说明：本仓库交付的是设计文档 + 可运行的界面演示。所有后端能力都还在 V1.0 计划中。
82
需求条目
35
已交付（文档与界面）
11
部分完成（设计或原型）
36
未开始