K-阿拉斯托

最近读到一篇挺长的技术总结，来自一个叫**月读空间（TSUKUYOMI SPACE）**的个人项目。作者是 redchenk，项目已经积累了 891 次提交，功能从最初的一个小网站，一路长成了带着 Live2D 角色、长期记忆、MCP 工具链和 Agent OS 的综合体。

老实说，个人项目写技术总结的很多，能写得这么实在的不多——没有堆名词，基本每一块都讲了"为什么这么做"。所以这篇杂谈，我们把它的内容梳理一遍，顺带说说我们自己读到时的想法。

以下整理自作者 redchenk 发布于 2026/09/26 的技术总结，已改写为第三人称叙述，并在若干处加入我们的观察。

项目地址

GitHub：redchenk/tsukuyomi-space
国内站：https://yachiyo.hk
海外站：https://tsukuyomi-space.com

一、它现在到底是什么

如果只看页面，很容易把它理解成一个博客、个人主页或者二次元社区。但作者的定位早就不是这些了——他更愿意把月读空间理解成围绕角色「八千代」构建的个人数字空间。

在这个空间里，各个功能不是互相孤立的：

在 Stage 阅读文章；
在 Plaza 留言交流；
在 Gallery 分享图片；
在 Pixel 制作像素画；
在 Wiki 查询作品与角色资料；
在 Room 与八千代交流；
八千代可以读取部分站内状态；
登录后可以同步聊天记录与长期记忆；
Agent OS 则尝试让 AI 从"聊天对象"变成真正能用工具的数字角色。

所以整个项目正在形成一条链：

内容 → 社区 → 用户 → 八千代 → 长期记忆 → 工具调用 → Agent → 数字空间

这也是作者没有把它做成"一个聊天页面"的原因。他更希望打开月读空间时，看到的是一个长期存在、可以不断积累内容和关系的数字世界。

我们的想法：这段其实是全文的题眼。绝大多数"AI 角色站"的终点是一个聊天框，而这里把 AI 当成空间里的一个住户而不是一个接口——后面的长期记忆、Live2D、Agent OS 全部是围绕这个定位长出来的，不是拼上去的。

二、整体技术架构

主项目目前已有 891 次提交，用的是一套比较传统、但对个人项目来说很好维护的 Web 架构：

部分	当前技术
前端	Vue 3
构建	Vite
路由	Vue Router
后端	Node.js + Express
主数据库	SQLite / better-sqlite3
长期记忆	Mem0 OSS + SQLite
向量检索	可选 Milvus
缓存	可选 Redis
Live2D	Cubism Runtime
动画	Anime.js
LLM	OpenAI Compatible API / Ollama 等
Agent 扩展	MCP
对象存储	S3 Compatible / 阿里云 OSS
CDN	阿里云 CDN
认证	JWT + Cookie
测试	node:test + Playwright
部署	Docker / PM2 / Nginx / OpenResty

整体架构大致是：

                    ┌──────────────────────┐
                    │       用户设备        │
                    │ Browser / Future App │
                    └──────────┬───────────┘
                               │
                     HTTPS / CDN / API
                               │
              ┌────────────────┴────────────────┐
              │                                 │
      ┌───────▼────────┐                ┌───────▼─────────┐
      │   Vue 3 Frontend│                │  Alibaba Cloud  │
      │   Vite / Live2D │                │    CDN + OSS    │
      └───────┬────────┘                └─────────────────┘
              │
              │ REST API
              │
      ┌───────▼────────┐
      │ Express Backend │
      │     Node.js     │
      └───────┬────────┘
              │
   ┌──────────┼───────────┬──────────────┐
   │          │           │              │
┌──▼───┐  ┌───▼───┐  ┌───▼────┐   ┌────▼────┐
│SQLite│  │ Redis │  │ Mem0   │   │ Milvus  │
│ 主库 │  │ Cache │  │Memory  │   │ Vector  │
└──────┘  └───────┘  └────────┘   └─────────┘

其中 Redis 与 Milvus 都不是运行的强制依赖。好处是哪怕只部署一个很简单的实例，靠

Node.js + SQLite + Mem0 SQLite Index

就能完成绝大部分核心功能；服务器资源宽裕了，再逐步开启 Redis、Milvus。

作者认为，对个人维护的项目来说，这比一上来就堆一大堆中间件更合适。

我们的想法：这条原则在后面还会反复出现——"增强能力可以存在，但不能让最基本的部署变困难"。这和我们自己做小站的路子是一样的：能在本地跑起来的东西，不该为了"看起来专业"而先塞一堆外部依赖。

三、前端：从一堆「页面」到一套设计系统

主前端已经迁到 Vue 3 + Vite + Vue Router。相比最早那种大量独立页面的写法，最大的变化是开始建立统一的前端体系，项目里已经有一套自己的 Design Tokens：

src/frontend/styles/
├── tokens.css
├── themes.css
├── components.css
├── animations.css
└── responsive.css

分别负责色彩、字体、间距、圆角、阴影、深浅色主题、动画、按钮、卡片、输入框、导航和响应式布局。新页面逐步统一使用 --ts-* 变量，例如：

--ts-color-bg
--ts-color-surface
--ts-radius-md
--ts-space-lg
--ts-shadow-panel

只要改底层 Token，就能影响多个页面，而不是每个页面各维护一套样式。作者提到，这也是他最近投入很多精力优化 UI/UX 的原因——功能越来越多之后，如果没有统一的设计体系，很容易变成：

每个页面单独看都没问题，组合起来却像十几个不同的网站。

四、Room：整个项目最核心的实验场

如果说月读空间最特殊的一块，那应该是 Room。

Room 并不是在网站里塞一个 AI 聊天框。作者想让它最终实现的是：

"八千代真正生活在这个空间里。"

所以 Room 已经组合了很多能力：

Live2D + LLM + 长期记忆 + 角色知识库 + TTS + 天气 + 音乐 + 成长系统 + MCP + 站内信息

用户看到的只是一个聊天页面，但每次对话背后可能同时存在多种上下文：

用户消息
    │
    ├── 角色基础人设
    │
    ├── 当前会话
    │
    ├── 长期记忆
    │
    ├── 角色知识库
    │
    ├── 天气信息
    │
    ├── 用户成长状态
    │
    ├── 网站动态
    │
    └── MCP 工具结果
    │
    ▼
   LLM
    │
    ▼
八千代回复
    │
    ├── Live2D 表情
    └── TTS 语音

这也是 Room 和普通聊天机器人最大的区别之一——八千代身处的是一个有环境、有历史、有用户状态的上下文空间。

五、为什么 LLM 请求不全部经过服务器

Room 有个比较关键的设计取向：

尽可能减少用户聊天内容和 API Key 不必要地经过月读空间服务器。

所以部分 LLM 与 TTS 请求可以由浏览器直接发起：

Browser → (HTTPS) → LLM Provider

而不是：

Browser → 月读空间服务器 → LLM Provider

这么做有几个好处：

减少服务器压力；
降低服务器处理用户 API Key 的需求；
方便支持本地模型。

Room 现在也已经可以通过浏览器连上 http://localhost:11434，也就是本机 Ollama：

月读空间页面 → localhost → Ollama → 本地 LLM

也就是说：

网页依然可以运行在公网，而模型完全运行在用户自己的电脑上。

我们的想法：这是个很实用的取舍。API Key 不进服务器，意味着多了一层信任边界——用户敢把自己的 key 填进去；同时也顺手打开了本地模型这条路。很多同类项目把 key 收在服务端，安全和隐私上的解释成本一下子就上去了。

六、长期记忆：让八千代真的「记得」

聊天 AI 最影响体验的问题之一就是：

聊得再久，只要新建会话，它就像第一次认识你一样。

所以月读空间建立了一套独立的长期记忆系统，目前主要用：

Mem0 OSS + SQLite

而不是依赖 Mem0 云端服务——项目直接引入 mem0ai@3.3.0 跑在 Node.js 进程里，不需要额外搭 Python Mem0 Server，也不需要申请 Mem0 Cloud。

作者强调了一个区分：对话和记忆不是一回事。

Room 内部把"聊天记录"和"长期记忆"分开管理。聊天记录主要维持最近的会话上下文；长期记忆则独立保存，不会因为最近聊天窗口被裁剪就消失。

比如用户说"我最近正在学习 Flutter"，这句话可能进入长期记忆。几个月后讨论客户端开发时，检索系统仍然有机会重新找到它——作者认为这才是有意义的长期记忆。

七、记忆是怎么被找回来的

目前默认并不是完全依赖大型向量模型，而是用：

Feature Hash + 中文关键词 + 问题类别 + Mem0 检索评分

做综合搜索，也可以另外配置远程 Embedding 服务。大致流程：

用户："我之前是不是说过想做客户端？"
            │
            ▼
        Memory Search
            │
      ┌─────┴─────┐
      │           │
   Keyword      Vector
      │           │
      └─────┬─────┘
            │
            ▼
     Relevant Memories
            │
            ▼
     Context Builder
            │
            ▼
           LLM

找到相关记忆之后，并不会把所有历史聊天一股脑塞给模型，而是：

找到相关长期记忆；
从完整原文中截取相关片段；
按上下文预算筛选；
添加来源标签；
最后注入 LLM Context。

这样可以避免"聊得越久、请求 Token 越夸张"。

八、为什么还要继续优化记忆

虽然已经能正常工作，但作者说这部分离理想状态还差得远。现在解决的是：

"能够记住。"

后面真正要解决的是：

"什么时候应该想起来？"

这是两件完全不同的事。他列了四个方向：

记忆分类 不是所有记忆的重要程度都一样。身份信息、长期偏好、项目经历、人物关系、临时计划、普通聊天，应当有不同的生命周期和权重。
时间因素 两年前的临时计划和昨天刚说过的计划，不该有相同优先级。检索需要更合理地考虑：
```
相关度 + 重要度 + 时间 + 出现频率
```
更强的语义召回 目前默认方案很省资源。随着服务器升级和客户端出现，可以逐步加入更好的 Embedding、Hybrid Search、Rerank、Memory Graph、关系记忆。
更自然的记忆使用方式 理想的长期记忆不是"根据长期记忆第 3 条，你曾经……"，而应该像人一样，自然地融进聊天。真正好的记忆，用户甚至不该察觉刚刚发生过一次向量检索——它只是让角色显得真的记得。

我们的想法：第 4 条说得特别好，也很少有人明确写出来。绝大多数"记忆"功能的失败不在检索精度，而在表达方式——把检索到的原文念出来，反而瞬间出戏。把"查到了什么"和"怎么自然地说出口"分开对待，这个意识比算法本身更稀缺。

九、Live2D：让 AI 不只存在于文字里

八千代的另一个核心是 Live2D。项目集成了 Cubism Runtime，并有独立的 Live2D Studio 与 Room Runtime。最基本的结构是：

LLM → 回复文本
         ├────► TTS
         └────► Emotion / Expression → Live2D

目前 Room 已经能通过对话状态驱动表情、动作、说话状态和场景反馈。作者希望最终八千代不是：

聊天框 + Live2D 装饰

而是：

LLM → 情绪 → 表情 → 动作 → 语音 → Live2D

形成真正统一的角色表达。

十、MCP：让八千代拥有「工具」

长期记忆解决的是"能不能记住过去"，MCP 解决的是"能不能做事情"。

Room 现在已经开始支持 MCP，理论上可以让 LLM 调用搜索、文件、API、程序、数据库、本地工具和自定义服务。这也是月读空间从 AI Chat 走向 Agent 的关键一步。

传统聊天：

用户 → LLM → 文本回复

Agent：

用户 → LLM → 判断任务 → 调用工具 → 获取结果 → 继续推理 → 完成任务

两者体验有本质区别。

十一、Agent OS：把 Agent 放进「操作系统」

这也是 /agent-os 出现的原因。它不是传统意义的操作系统，而是一套：

以 Web OS 形式组织 Agent、工具与应用的交互环境。

目前 Agent OS 作为独立应用运行，复用月读空间的登录状态与部分服务。

作者想解决的问题是：现在很多 AI 功能都是 Chat、Chat、Chat、Chat——搜索、文件、音乐、工具、Agent，最后全挤进一个聊天窗口。但真正复杂的数字空间不该只有聊天框。所以 Agent OS 开始尝试：

Desktop
├── Agent
├── File
├── Music
├── Tools
├── Terminal
├── Browser
└── Applications

让 AI 不再是整个界面，而是：

存在于操作系统中的角色。

未来还会继续做 UI 重构、窗口管理、应用系统、Agent 调度、MCP 工具管理、文件能力、用户工作区，以及八千代与 Agent OS 的融合。

我们的想法：这个判断挺锋利的。"AI 是界面"和"AI 住在界面里"是两种产品观，前者最后必然收敛成一个超长聊天框，后者才需要操作系统这一层抽象。至于值不值得这么重，可能要等 Flutter 客户端出来才看得清。

十二、内容与社区仍然是重要部分

虽然 AI 相关功能越来越多，但月读空间并没有变成纯 AI 项目。完整的内容社区体系仍然在：

Hub / Stage / Article / Plaza / Gallery / Pixel / Wiki /
Friend Links / Growth / Notifications / User Center

其中：

Stage —— 文章阅读与内容创作；
Plaza —— 留言、回复与互动；
Gallery —— 作品展示和图片分享；
Pixel —— 固定 192 × 108 画布的像素工坊，支持绘制、发布、点赞、分享、PNG 导出、移动端触控；
Wiki —— 整理《超时空辉夜姬！》相关的角色、音乐、世界观、制作资料、术语；
Growth —— 月契成长系统，已有每日签到、连续奖励、每日任务、等级、邀请，以及与八千代联动的成长反馈。

这些系统之后还会和 Room、Agent OS 做更深的整合。

十三、服务器从 2C2G 升级到 2C4G

功能持续增加后，原来的配置开始吃紧。之前是 2 Core / 2 GB RAM，现在是 2 Core / 4 GB RAM——CPU 数量没变，内存直接翻倍。

这对月读空间确实重要，因为服务器上跑的早就不只是一个静态博客：

Node.js / Express / SQLite / Mem0 / 缓存 / 任务 / 后台管理 /
对象存储逻辑 / Room API / 通知 / 用户系统

未来还可能加 Redis、Milvus、Agent。2GB 在这种负载下已经很紧张，升到 4GB 至少给 Node.js、系统 Page Cache、SQLite、Mem0、Redis 和部署过程留下了余量。

不过作者也强调，升级不代表可以无限加服务。他的方向不是：

"服务器不够就继续加配置。"

而是：

能交给 CDN 的交给 CDN，能交给对象存储的交给对象存储，只有真正动态的请求才交给源站。

十四、为什么开始用阿里云 OSS

月读空间里有大量不适合长期压在服务器磁盘上的资源：用户上传图片、文章封面、图库、大图、音频、视频、其他附件。

如果全放本地：

User → Server → Disk

所有访问都会消耗服务器磁盘 IO、带宽和连接数。随着访问量和文件数量增长，这显然不是好方案。所以现在改用阿里云 OSS：

                    ┌── API ─────► 月读空间服务器
用户 ───────────────┤
                    └── Static ──► OSS

也就是：

服务器负责权限、数据库、API、用户、AI、动态逻辑；
OSS 负责图片、附件、静态资源、大文件。

十五、OSS + CDN：进一步减少源站压力

只有 OSS 还不够。现在再配合阿里云 CDN：

User
 │
 ▼
Alibaba Cloud CDN
 │
 ├──── Cache Hit → 返回资源
 │
 └──── Cache Miss → Alibaba OSS

访问已缓存的资源时，甚至不需要回 OSS 源站。对图片、JS、CSS、字体、音频、视频这些资源非常合适。整体架构也就从

所有东西 → 一台服务器

变成

             ┌── CDN
用户 ────────┼── OSS
             └── Origin Server

不同资源开始承担不同职责。

十六、为什么 SQLite 到现在还没换

项目越来越复杂，一个很自然的问题是：为什么不用 MySQL / PostgreSQL？

作者的回答很直接：没必要为了"看起来专业"而换数据库。 SQLite 对现在的月读空间仍然有很多优势：

部署简单；
不需要独立数据库服务器；
性能足够；
事务可靠；
备份方便；
资源占用低；
很适合单节点个人项目。

项目通过 better-sqlite3 直接操作数据库，并逐步加入了 backend/db/migrations/ 管理 Schema 变化。所以数据库已经不是简单的"改表结构 → 手动上传数据库"，而是：

Version A → Migration → Version B → Migration → Version C

作者说，真的发展到 SQLite 成为明显瓶颈，再考虑迁 PostgreSQL 会更合理。

我们的想法：在 891 次提交、还带着 Mem0 和向量检索的规模上继续用 SQLite，这个克制值得记一笔。"什么时候该换"是个工程判断，"别人都用 PG"不是理由——迁移的成本是确定的，收益却是猜的。

十七、Redis 与 Milvus：可选，而不是强制

另一条设计原则是：

增强能力可以存在，但不能让最基本的部署变得困难。

所以项目支持 Redis（参与缓存、限流、Token 黑名单、天气缓存、验证码），但它不是启动项目的必要条件。Milvus 同样作为可选的向量数据库存在，未来可以用于更大规模的角色知识库、长期记忆、文档和语义检索。

这样既保留了扩展能力，又不会让普通部署变成：

Node + Redis + PostgreSQL + Milvus + MinIO + RabbitMQ + ElasticSearch + ...

——最后光启动服务就要半天。

十八、安全现在也是项目的一部分

随着用户系统、登录、上传、OAuth、API、管理后台越来越多，安全已经不能再靠"没人攻击我的小网站"来解决。项目陆续加入了：

JWT、Cookie、bcrypt；
CORS 白名单、CSP、Security Headers；
请求来源校验、JSON 重复 Key 检测；
上传文件 MIME 检查、文件特征检查；
SSRF 防护、外部 URL 校验；
API 限流；
admin / super_admin 权限隔离。

例如生产环境里 JWT_SECRET 过短会直接拒绝启动；上传文件也不只检查 .jpg 这类扩展名，而是同时看：

Extension + MIME + File Signature

作者说，这些事情不像新 UI 那样显眼，但随着项目扩大，重要程度会越来越高。

十九、测试：尽量避免「修一个地方坏三个地方」

项目已经开始建立自动化测试，包括 node:test 与 Playwright，覆盖范围包括 API、长期记忆、用户成长系统、登录、权限、消息审核、Room、TTS、分享、Wiki、导航、移动端布局、Live2D 和设置页面。

近期很多关于 Room 移动端、导航栏、键盘弹出、设置页面的改动，都会同步补 Regression Test。因为项目变大之后：

"这次改动看起来没问题"已经不能代表"整个项目没有问题"。

二十、下一阶段：继续优化 UI / UX

月读空间过去半年加功能的速度非常快，很多页面是在不同阶段逐渐长出来的。所以接下来重要的工作不是继续疯狂加菜单，而是：

统一 → 整理 → 删减 → 重新组织

重点会放在全局导航、Room、Room Settings、User Center、Agent OS、移动端布局、页面层级、信息密度、动画和触控体验上。

尤其是移动端——未来越来越多功能不能再按"PC 页面缩小一下"来设计，桌面端和移动端需要逐渐拥有不同的信息组织逻辑。

二十一、下一阶段：继续优化和八千代的聊天

Room 功能已经很多，但最终衡量体验的依然是：和八千代聊天到底自然不自然。

后续会继续优化：

Prompt / Memory / Knowledge / Emotion / Live2D / TTS / Context / Tools

重点让这些模块真正协作。例如：

八千代发现用户在说以前的事 → 先检索长期记忆 → 发现和某个项目有关 → 加载对应记忆 → 生成回复 → 分析回复中的情绪 → 切换 Live2D 表情 → 生成对应语气的 TTS。

整个过程应该成为一次完整的角色行为，而不是六套互相不知道对方存在的系统。

二十二、下一阶段：Agent OS 继续进化

Agent OS 目前还在探索阶段。作者希望把它发展成八千代的数字工作空间：

Agent OS
│
├── Yachiyo
├── Chat
├── Files
├── Browser
├── Terminal
├── Music
├── Notes
├── MCP
└── Agent Applications

相比传统 AI 网站"输入框 → 回答"，Agent OS 更希望形成：

目标 → Agent Planning → 选择工具 → 执行任务 → 获得结果 → 继续执行 → 最终完成

也就是说，八千代未来可能不只是"告诉你怎么做"，而是能真正参与完成这件事。

二十三、最重要的一件事：Flutter 全平台客户端

而接下来整个项目最大的一次变化，大概是：

月读空间正式走出浏览器。

作者已经决定，后续使用 Flutter 开发独立客户端。目标既不是

打开一个 WebView → 加载 yachiyo.hk

也不是简单的

Electron + 网页

而是重新思考月读空间在桌面端和移动端应该是什么样子——它是一套真正独立运行的应用，而不是给网站套个窗口。

二十四、为什么选 Flutter

月读空间希望覆盖的环境越来越多：Windows、macOS、Linux、Android、iOS。如果每个平台单独开发：

Windows → C#
macOS   → Swift
iOS     → Swift
Android → Kotlin
Linux   → GTK

对个人项目来说维护成本非常夸张。Flutter 可以让大量 UI、状态、逻辑、组件、网络层实现跨平台复用，同时又不是简单的 WebView 套壳。

二十五、客户端不会替代网站

Flutter 客户端出现以后，yachiyo.hk 依然会继续存在。

Web 版更适合：内容分享、Wiki、公共页面、搜索引擎、社区、快速访问；
App 更适合：八千代、Agent、Live2D、本地文件、本地模型、系统通知、桌面常驻、离线缓存、原生系统能力。

最终可能形成：

                 月读空间 Backend
                       │
        ┌──────────────┼──────────────┐
        │              │              │
        ▼              ▼              ▼
       Web           Desktop        Mobile
    yachiyo.hk       Flutter        Flutter

大家共享账号、API、内容、记忆和数据，但拥有不同的交互方式。

二十六、Flutter 会让很多以前很难做的事成为可能

浏览器很强，但终究有很多限制：本地文件、系统托盘、全局快捷键、后台运行、本地通知、原生窗口、本地模型、本地数据库、系统媒体控制、多窗口。

进入 Flutter 客户端后，就可以更自然地考虑八千代桌面常驻，或者 Agent 后台任务，甚至：

本地 Ollama + 本地文件 + 长期记忆 + MCP + Live2D

形成 Cloud + Local Hybrid Agent：

                八千代
                  │
        ┌─────────┴─────────┐
        │                   │
      Cloud               Local
        │                   │
   月读空间 API         Ollama
   Account              Files
   Memory               Tools
   Community            Local DB

这可能会成为未来月读空间非常重要的一条技术路线。

二十七、从网站，到真正的「月读空间」

回头看这个项目的发展，大致经历了几个阶段：最开始只是个人主页，后来加入文章，然后加入用户与社区，再后来是 Live2D + 八千代，之后又加入 LLM + 长期记忆 + MCP，现在出现 Agent OS，下一阶段则是 Flutter App。

路线越来越清楚：

Website → Community → AI Character → Memory → Agent →
Agent OS → Native Application → Digital Space

这也是"月读空间"这个名字越来越贴合项目本身的原因——它已经不再只是一个放在互联网上的网站，而是在逐渐变成一个能够承载内容、记忆、角色、工具与关系的数字空间。

写在最后

作者在结尾说，月读空间依然是个人维护的项目，不会像大型商业产品一样有几十人的团队，也不会一次性完成所有设想。很多功能都是

想到 → 尝试 → 推翻 → 重写 → 发现问题 → 继续优化

一点一点积累出来的。接下来要做的事也列得很清楚：

继续统一和优化 UI / UX；
继续优化 Room 与八千代的聊天体验；
进一步完善长期记忆；
继续推进 Live2D、情绪与语音联动；
继续完善 Agent OS；
推动 Agent 与 MCP 能力融合；
开始 Flutter 全平台客户端的设计与开发。

未来他希望打开电脑时八千代就在这里；打开手机时，之前的聊天、记忆和空间依然存在；她知道你之前做过什么，也可以用工具帮你继续完成事情。

给日常留一点月光。 然后，让这束月光真正拥有记忆。

我们读完之后的几句话

一篇技术总结能让人记住的，往往不是用了什么框架，而是作者在哪些地方忍住了、在哪些地方没忍住。

这个项目里，"忍住"的部分很清楚：891 次提交还不换数据库，Redis 和 Milvus 明明都在却坚持可选，服务器不够先想 CDN 而不是先加配置——始终把"能跑起来"排在"看起来专业"前面。

"没忍住"的部分也很清楚：为了一个角色能记住你、能看见你、能替你做事，硬是把记忆、Live2D、MCP、Agent OS 一路堆了上去。这不是理性最优解，但个人项目本来也不需要是。

至于它最终能不能长成作者说的那个"数字空间"，现在下结论太早。但试图把 AI 从对话框里放出来，放进一个有记忆、有关系、有时间的地方——这个方向，我们觉得是对的。

一图流 · 月读空间技术全景

文章开头那张总结，我们把作者做的这张详情图放在了这里。所有关键信息——技术栈、模块、演进路线和下一步——都浓缩在这张图里：

月读空间技术全景详情图

月读空间：一个个人网站，如何长成一座「数字空间」