从一个博客，到我的「个人宇宙」

搭建博客，大概是很多程序员都会经历的一个阶段。我也一样：写点东西，放上自己的介绍，再挑个喜欢的主题，改成自己的样子。

后来访问的网站越来越多。有的人把文章排版做得很好，有的人认真整理简历和作品，还有人在个人站里放了终端、音乐、碎碎念、相册和旅行地图。我感兴趣的东西也越来越多，不太想让自己的页面只有一份介绍和一个文章列表。

写文章可以表达观点，但照片、收藏、经历和日常记录，能让人了解到其他部分。于是从 my-profile 开始，又陆续有了后面的 my 系列。

这些项目并不是提前规划好的一套系统。最初做网站、进行技术选型时，我也会自己做一些探索：设计系统、monorepo template、测试体系，以及不同框架和开发方式。后面才逐渐有了各个内容站点，再用 Vesper 管理自己的日常操作。现在回头看，才有了标题里这个「个人宇宙」的样子。

博客，是起点

博客最吸引我的地方，是可以自己决定写什么、怎么展示。文章、代码、排版都能调整，不必完全按照某个平台的格式来。

只放文章时，Hexo、Hugo 这类提前生成页面的方式就很直接；想加在线编辑、登录或更多交互，就会接触到 SSR、CSR，以及不同框架的处理方式。除了页面和功能本身，技术怎么选、不同方案用起来怎样，也是我想亲自试的部分。

我喜欢的形式大致有几种：纯文章、个人主页、简历作品集、有趣的组件集合，以及生活记录。没有哪一种能完全覆盖我想放的内容，也不需要只选一种。

我想做的，是让第一次遇到我的人，能从不同的角度认识同一个人。

比如一篇技术文章，能说明我正在研究什么、怎样理解一个问题。但看完文章的人，也许还会想知道我做过什么、喜欢什么。个人主页和其他内容的入口，就可以接在这里。

从个人主页，到自己的技术尝试

my-profile 是最早的个人站点。个人介绍、社交链接、CV、Story 都放在这里，也加了终端这样的交互。

最初进行技术选型时，我就想自己做一些尝试。框架可以看文档、看别人的项目，但真正写起来，才会接触到组件怎么组织、样式怎么管理、应用之间怎么共享代码。这些也是我做个人项目的兴趣所在。

我在这里尝试了几个方向：设计系统、monorepo template，以及测试体系。它们关注不同的问题，也都可以在自己的项目里实践。

设计系统

my-design 让我试着把自己的审美落实到一套能使用的样式里。主题参考了要乐奈（Rana Kaname）：银白和柔墨作为明暗两种底色，蓝与琥珀来自异色瞳，再用一点抹茶绿做点缀。大部分页面仍然保持中性色，蓝色承担链接、主要操作和焦点提示，琥珀与抹茶只在局部出现。这样个人偏好可以留在页面里，长文和表单也有足够清楚的层次。

CSS 则按原始值 → 语义 → 使用分工。palette.css 保存实际色值，tokens.css 把它们映射为背景、正文、边框、强调色；组件只使用这些语义变量。比如按钮使用 --color-accent，切换深色时替换它的映射，按钮本身不用重新写一套颜色。my-design 的组件样式写在 global.css 等文件里；到 Vesper 中，第三层由 theme.css 把语义变量接到 Tailwind 工具类上。

这些选择还要放进实际内容里看。我用同一份内容比较衬线、宽松的阅读排版和无衬线、紧凑的日常排版，也做了文章、简历、报告样张。配色表里喜欢的颜色、单独看着合适的字号，到了长文、深色页面或打印稿里，还需要再调整。

my-design 的文章分享图，使用同一套配色与字体。

Monorepo template

my-monorepo 用来探索项目怎样组织。Web、API、Tauri 和 CLI 放在 apps，认证、数据库、AI、UI 等能力放在 packages。我想实际试一遍：多个入口一起开发时，哪些东西适合共享，哪些仍然应该留在各自的应用里。这部分也参考了 Midday。

比如 Web 和 Tauri 的前端可以使用同一套 UI 与登录客户端，认证的服务端实现再连接数据库。共享包里仍然要分清运行位置：浏览器读取公开环境变量，数据库和认证密钥留在服务端；类型可以共享，服务端实现不能顺手带进浏览器。目录拆开之后，还要检查这些依赖究竟怎么连。

这也让我有地方尝试工具链和工程约定：改一个共享包之后检查哪些应用，提交前怎样跑检查与测试，启动某个入口时要带上哪些依赖。模板先把这些连接做出来，后面的项目再按需要取用。它会随着尝试继续变化，也没有要求所有站点都采用同一套框架。

测试体系

测试体系里，我想试的是怎样把验证放进日常开发。以 my-knowledge 为例，一次修改可能同时影响 Markdown 规则、保存的数据和浏览器里的呈现，只检查其中一处，很容易漏掉另外两处。

比如新增一种图示，解析结果正确，还不能说明手机上没有文字重叠；保存接口成功，也还要确认重新打开文章能读到刚才的修改。Playwright 用来补上这些实际操作。这里运行的是构建后的 OpenNext 本地 Worker，配合独立的测试数据，让检查更接近应用实际运行的方式。

这些测试各自回答不同的问题，我也在尝试怎样把它们组合起来：规则和数据行为适合反复自动检查，阅读与编辑流程则需要浏览器参与。本地作者会话可以验证操作权限，真实 Google OAuth 和线上服务仍需另外验证。测试体系也和设计、项目组织一样，在具体使用中继续补充。

这些尝试能减少重复配置，不过我也会单纯因为想了解一种技术而去做。并不是每个实验都要先找到一个非它不可的需求。个人项目给了我这个空间，觉得适合，就继续用；遇到问题，再调整设计、项目组织或验证方式。

让不同内容，有各自的位置

随后，my-memos、my-moment、my-knowledge 陆续出现。Profile 逐渐回到个人介绍与导航的角色，短文字、照片和长文章则有了各自的地方。

Memos 最接近日常。一条只有两句话的想法、一个暂时用不到但想留下的链接，不需要先写标题、摘要，再考虑够不够发成一篇文章。记录这件事轻一点，才更容易真的记下来。

Moment 放照片，也放旅行足迹、影视收藏和购物记录。技术文章之外，我去过哪里、在看什么、喜欢哪些东西，都可以在这里出现。照片有日期和地点，也就不只是主页里的一张装饰图，可以按时间浏览，也可以放回地图中看。

Knowledge 留给值得展开的内容。长文章需要标题层级、代码、图示，也需要修改和关联。一个问题在短记录里可能只有一句话，认真写成文章之后，才有空间把背景、判断和细节说清楚。

这期间也看了 Memos、Afilmory、Kevin’s Journey、astro-doge 等项目。有时看的是功能想法，有时是处理原理，或者某一个组件。看到适合自己的部分，再拿回来尝试。

目前可以直接访问的站点有：

• you-find.me：my-profile，个人介绍、社交与友链、CV、Story。
• memos.you-find.me：my-memos，碎碎念、备忘和收藏。
• moment.you-find.me：my-moment，照片、旅行地图、影视收藏和购物记录。
• knowledge.you-find.me：my-knowledge，长文章、内容关联与检索。
• design.you-find.me：my-design，配色、组件和排版样张。
• oh.you-find.me：一个更轻的介绍与导航入口。

主页能说明我是谁，持续放进去的内容会比介绍更具体。

这些站点保持独立仓库，技术栈也不完全相同：Memos 用 SvelteKit，Moment 用 Solid，Knowledge 用 Next.js，Profile 后来换成 React 配合 Void / Hono。沿用的是开发经验，没有要求每个新项目都照着模板复制一遍。

把尝试用到具体项目里

前面探索的组织方式和工具链，也逐渐用到了这些站点里。多个仓库采用 workspace，把应用和共享包分开。Vite+ 收拢格式、检查、测试等工作；Void 是 VoidZero 提供的一个 Vite 插件，把 Vite 应用和它用到的资源部署到 Cloudflare Workers，OpenNext 则负责 Next.js 应用的 Cloudflare 接入。

具体选型有很多可以继续聊的地方，这里先不逐个比较。实际使用之后，哪些适合沿用、哪些需要调整，也会比只在模板里试更清楚。

比如 Knowledge 的 Markdown 规则，编辑、校验和阅读都需要理解，所以单独放在 content 包里。以后想给文章增加批注、图示或贴纸，不必在三个地方重新定义它是什么。

公开站点背后的分工

页面能打开之后，后面还要考虑怎样长期使用。随手写的一条 Memo 能不能找回来，照片多了会不会难以浏览，文章能不能方便地改，这些都会影响我是否愿意继续往里面放内容。

几个内容项目使用 Cloudflare Workers、D1、R2 和 KV。Knowledge 通过 OpenNext 运行在 Workers 上，Markdown 正文放 R2，标题、标签、可见性和版本放 D1，KV 做派生缓存。Profile 则保留 PostgreSQL，通过 Hyperdrive 连接。

Memos 和 Knowledge 的读取方式就不一样。时间线需要直接显示短正文，所以 Memos 在 D1 中保留正文镜像，读一页时不必逐条回 R2；Knowledge 首页只需要标题和摘要，正文等点开文章之后再取。

一页短记录本来就需要正文，一页长文章的目录还不需要。

Cloudflare 也会影响实际做法

这些服务让个人项目容易开始，不过免费额度不是无限资源，而且不同限制的硬度也不一样。Workers Free 的每次 HTTP 请求只有 10 ms CPU 时间，等待网络不计入，解析 JSON、处理长文和图片则会计入。Workers 官方限制

真正决定这些服务能不能长期免费跑下去的是每日额度：D1 Free 每天有 500 万行读取、10 万行写入，按扫描行数计算；KV Free 每天只有 1,000 次写入。更关键的是，从 2026 年 9 月 1 日起，D1 免费额度不再是软性提醒：超限后的查询会直接失败，直到次日 UTC 零点重置，已存数据不受影响。查询、缓存和批量操作要怎么做，很大程度上由这两条上限决定。D1 免费额度执行说明 · D1 · KV

CPU 时间则是每次请求的预算，它约束的是访问时还要做多少计算，而不是请求本身：静态产物几乎不占用 CPU，所以它并不构成对静态发布的阻碍。它真正影响的是编译放在哪一步，Shiki 的代码高亮就是一个具体例子。在免费资源预算下，我没法按最初的想法，把全量语言和主题都放进线上编译流程。Knowledge 现在只显式引入 13 种语言和两套明暗主题，使用预编译语法与 JavaScript 正则引擎；没有加载的语言保留普通代码块。这样能控制依赖体积和加载开销，但也意味着写文章时，可用的高亮范围受线上配置影响。Shiki 的细粒度打包说明

Mermaid 也让我继续考虑，图示应该在哪一步生成。一段图表源码要经过解析、布局，才能变成可读的 SVG。Knowledge 目前把这一步放在浏览器里，避开了 Worker 的计算开销，但读者打开文章后仍要等待渲染。对于发布后不再变化的图，提前生成 SVG 更符合我的使用方式：作者修改时重新编译，读者直接看结果。这也和后来 Vesper 的本地静态发布衔接起来。

Memos 曾把完整列表放进 KV。列表更新频繁，最先撞上的是 KV 每天 1,000 次写入的额度；缓存整份列表也意味着每次读取都要解析整个 JSON，占用 Worker 的 CPU。后来列表改成直接查询 D1，默认每页 25 条，用游标继续读取：分页之后，每次处理的内容才真正减少。

访问量少，也可能有很重的一次请求。

这些经历进一步坚定了我后来把编译放到本地的想法：代码高亮、Markdown 解析和图示生成都可以在发布前完成，文章写好之后会被反复阅读，没必要让这些工作一直挤在每次访问的预算里。这也成为后来 Vesper 选择本地优先的重要原因。不过它目前仍是机制上的判断，而不是实测结果：请求量、缓存命中率和访问延迟我还没有持续统计，真要验证本地优先解决了什么，这些数字会比免费额度更有说服力。

Vesper：把自己的操作入口收回来

模板提供了开发基础，各个站点逐渐承载起真实内容。接下来遇到的问题很日常：写备忘、整理照片、修改文章，要在几个入口之间切换；待办、日历和开销又在其他地方。

所以，我从模板出发，搭了 my-workspace 里的 Vesper。它把内容管理和日常工具收进本地工作区，同时提供桌面界面与 CLI。

前面按内容把站点分开，是为了让每种内容有合适的展示和编辑方式。到这里，我需要把常用操作放到一起。比如一篇文章写好以后，继续改稿、配图、发布，不必把每一步都当成一次重新进入网站的操作。

桌面用 Tauri 和 Svelte，Rust 负责网络、存储、内容编译和凭据访问，CLI 也复用这些能力。Memos、Moment、Knowledge 继续保存各自的内容，Vesper 通过 API 管理；公开 Memo 还可以按需分发到 Telegram 和 X。

待办和账本保存在本地 SQLite，音乐、游戏、设备状态也陆续接了进来。界面上参考过 shadcn-svelte、Atoll 等项目，再按自己平时的使用习惯调整。Vesper 会做得这么杂，主要是因为这些东西我都会用到。

Rust + CLI，把内容制作留在本地

前面在线上编译和免费额度之间做过的取舍，到 Vesper 这里，落实成了 本地优先 的 Rust + CLI 方案。文章和照片本来就在自己的电脑上，Markdown 编译、代码高亮、图示生成，以及 HEIF / HEIC 解码、图片转换和缩略图生成，这些处理可以先在本地完成，再把准备好的产物发布出去。

早期用 Next.js、SSR 做网站时，需要服务端渲染的页面会在请求到来后读取数据、执行渲染，再把结果交给浏览器。随着内容和展示形式增加，我更希望把其中能够提前完成的工作移出访问请求：文章可以在发布前编译，照片可以在上传前处理，远端拿到的就是适合展示的结果。

我希望制作发生在本地，访问时展示产物。

Rust 在这里负责可复用的本地处理能力，桌面和 CLI 调用同一套代码。这样在桌面里选择照片，或者通过命令行处理文件，走的都是同一套业务逻辑。CLI 则让我可以直接用文件、脚本和本地编辑器组织工作，不必为了每次构建、上传都先打开一个网页或桌面窗口，AI 助手也能接入已有流程。

它们组合起来，才是我需要的 Vesper：桌面负责方便地操作，CLI 方便重复执行和自动化，Rust 承担背后的计算与文件处理。只把一个管理网页搬进桌面窗口，还没有完成这件事。

远端尽量只负责展示

静态发布时，vesper build 从本地 content/ 生成 HTML、代码高亮、Mermaid SVG 和内容索引，确认后再上传 R2。照片通过 Vesper 上传时，也先在本地完成解码、方向处理、规范化图片、JPEG 缩略图和 ThumbHash 的生成。

接下来才轮到 Cloudflare。准备好的静态资源交给它的边缘网络分发，让访问者尽可能就近拿到内容，减少回源和临时处理。Workers Static Assets 会处理静态资源的缓存与分发；R2 对象则需要通过自定义域名及相应缓存配置接入 Cloudflare Cache，上传到桶里本身并不等于已经获得边缘缓存。静态资源分发 · R2 缓存接入

内容制作和访问的频率并不相同。一篇文章改完发布，可能会被反复打开；同一张照片也没必要每次有人浏览时重新缩图。把这些计算提前做完，再利用边缘网络分发，是我希望同时减少远端资源消耗和访问等待的方式。实际速度仍会受缓存命中、资源大小和访问位置影响，不能只因为用了 Cloudflare 就说一定最快。

远端尽量只做展示，是这条发布路径的方向，不代表所有内容服务都已经变成纯静态站点。

桌面阅读还有自己的本地编译：通过 API 拿到有权访问的 Markdown，再由 Rust 生成 HTML、目录、标题锚点和嵌入内容。原稿仍然保留为 Markdown，更新 Knowledge 时也提交 Markdown，不把桌面生成的 HTML 当成正文。

最近增加的 stickers 同样属于这套内容约定。正文写短码，阅读器映射到图片；批注、引用和图示也保留相应语义。网页和 Rust 两边需要对齐这些规则，才能让同一篇文章换一个入口阅读时，不必重新制作。

对我来说，这也让这组站点更容易继续维护：在自己的工作环境里写、整理、处理，准备好以后再公开。访问者看到的是文章、照片和页面，我不必让每一次内容制作都围着线上编辑器和服务端资源打转。

多一个入口，也要接得上原来的规则

CLI 让文件和脚本可以参与进来，MCP 则让 AI 客户端发现并调用内容工具。它们增加了操作方式，保存文章时仍然要经过服务端的权限和版本检查。

比如浏览器和 Vesper 同时打开一篇文章，一边已经保存，另一边的旧草稿就不能直接覆盖。Knowledge 要求更新带上 expectedHash 和 expectedUpdatedAt；正文没改、只调整了可见性，也能通过更新时间发现变化。

方便修改，也要保留修改之前的判断。

服务端再协调 R2 正文、D1 元数据和缓存，处理部分失败。照片登记超时也不能立刻认定上传失败并删除图片，因为服务端可能已经保存。这些细节不直接出现在个人主页上，但决定了我是否敢长期把内容放进来。

这篇文章也可以先留在本地 Markdown 里修改，正文、图示都确定后，再通过 CLI 提交。AI 能帮忙整理和操作，最终要表达什么，仍然需要我自己确定。

Vesper 是一套高度个人化的工具。它依赖我的配套内容服务、存储、账号和使用约定，换一个人使用，还需要配置甚至修改工作流。源码可以参考，但只安装一个 CLI，并不能复现这一整套体验。

把整个个人宇宙放在一张图里

把这些项目放到一起，可以沿着内容走一遍：我写文章、拍照片、整理经历，也用编辑器、脚本和 AI 工具辅助制作；内容经过处理和发布，出现在各个远程站点，最后被读者看到。生产者、加工者、消费者之间，才是这些入口和项目实际连接起来的地方。

这些入口服务于不同的使用场景：文件和脚本走 CLI，AI 可以调用 CLI 或 MCP，线上编辑经过 OAuth 登录，再通过内容接口保存。Vesper 承担本地制作，内容服务负责权限、版本与保存，各自处理自己熟悉的部分。

远程站点是这条发布链的出口，读者是最终的消费者。有人只读文章，有人更关注照片，也有人从主页进入项目和设计实验。我负责持续制作和整理，站点负责把这些内容展示出来；别人对我的认识，就从这些具体内容里逐渐形成。

从博客和个人主页开始，到这些技术尝试、内容站点和 Vesper，我逐渐搭出了这个「个人宇宙」的基本样子。不过，入口和工具有了，里面的内容还需要慢慢填充。

接下来还有很多具体的事可以做：把尝试过的技术整理成文章，把照片和旅行记录补上，把零散的想法留下来，再回头看看哪些值得继续展开。这也需要逐渐养成记录和整理的习惯，在日常使用中丰富内容，完善各个站点。

我希望这个「个人宇宙」能跟着自己的经历一起更新 成长。