花了几年时间我拥有了属于自己的博客网站
有些想法不是在书桌前规规矩矩规划出来的，而是在某种晃晃荡荡的间隙里突然冒出头的。
从高中起，我就一直有记录和分享的习惯。后来进了大学学设计，这种习惯不仅没有断，反而变得越来越具体——设计需要不断消化吸收，平时看到的优秀案例、在软件里反复调试的间距，以及做完一个项目之后沉淀下来的复盘，都在推着我找一个合适的容器把它们装起来。
我记得大概是 2022 年的冬天，在一趟开往家里的火车上，那个念头变得清晰起来：我需要一个真正属于自己的地方，一个长期的知识库和博客。我想把那些散落在各处的东西收拢回来。学到的设计规范、摸索出的软件心得、做过的一个个设计项目，还有平时一点点迭代出来的工作流程。它们不应该只停留在本地硬盘的文件夹里，或者随手建立的草稿文档中。
那时候底层的愿望其实很朴素：我想有个地方，能把认真做出来的东西安安静静地放下去，然后，能被更多的人看见。这个念头落下去之后，便成了后面几年所有折腾的起点。
把零散的知识收拢起来，让分享的念头慢慢长大。
用了三年多的 Wolai
火车上的念头落定之后，第一步是找一个现成好用的工具。后来，我选了 Wolai，这一用就是三年多，而且一直付费。
回过头来看，那三年多的时间对我来说至关重要。Wolai 帮我做到了最核心的事：让我能够保持书写、用结构化的方式把笔记与项目组织起来，并且可以通过公开页面直接分享出去。在那段时间里，我把大量的项目复盘、设计笔记和方法总结搬了上去，搭起了一个初具规模的公开知识库。据我自己后来的了解，这份知识库被一些我很敬佩的优秀设计师收藏了。得知这件事时，我感到非常荣幸——那种感觉就像是你花心思整理的内容，路过的人驻足翻了翻，还愿意把它放进自己的书签栏里。那份认可给了我很大的信心去继续记录。
但在日常使用中，有三处局限随着我工作习惯的变化，开始慢慢显现。
第一处是个性定制的空间不够。作为设计师，对页面的字体层级、版心留白、行高与色彩节奏总有自己的执念。在现成产品的既定框架里，我只能做有限的微调，但心里总希望页面能更贴合我自己的审美。
第二处是 AI 工作流的适配。这几年设计与开发的工作流变化很大，AI 深度介入了我的思考、写作与代码构思。我需要一个能更顺畅地让 AI 读写、整理和自动化流转的环境，按我自己的使用体验，Wolai 配合这套工作方式时仍有些磕绊。
第三处则关于读者：我自己想看的浏览数据在平台上拿不到。一个公开分享的知识库，到底有没有人在读、大家更关注哪些内容，在现成平台里几乎看不到具体数据。
我离开 Wolai，不是因为它做得不够好——它陪伴并承载了我三年多密集的成长，那三年沉淀下来的内容本身就是基石。只是走着走着，我开始渴望一个更自主的空间，能够长成我想要的模样。
自由与摩擦：基于代码仓库的阶段
既然想要自主权，很自然地，我尝试了自设计前端加代码仓库的方案。
那套方案的基本架构很常见：内容写成 Markdown 文件，存放在一个私有的 GitHub 仓库里；我自己设计前端界面；本地把改动推送到 GitHub 的 main 分支后，自动触发构建并部署。在托管方案上，我最早使用的是 Cloudflare 的免费托管。
刚跑通的时候，整套方案确实带来了自主掌控的自由。界面的结构、暗色模式的对比度、大标题在移动端的排版细节，全部由自己调整；内容改动在 Git 的历史记录里清清楚楚，随时可以查阅 diff。
但当它真正作为日常写作工具运转起来之后，现实的摩擦接踵而至。
最先感到麻烦的是图片和视频的维护。写设计类的文章通常图文混排，穿插着大量界面截图和动图。在 Markdown 里插入媒体文件时，需要仔细核对相对路径，维护起来相当繁琐。
紧接着是 AI 参与协作的阻碍。想让 AI 处理文章和媒体，它又得先访问仓库：拉到本地，或建立云端连接。对我来说，光是让 AI 拿到材料，就又多了一层准备。
更大的困扰在访问端。部署在这套方案上时，国内读者访问受阻。如果网页无法稳定打开，视觉调得再讲究也失去了意义。
最后是手机操作难。对我来说，这套流程几乎告别了在手机上轻松更新内容的可能。
如果读者对那个阶段的某些探索感兴趣，我当时还留下过诸如
与
这样的页面。
回看那套方案，表面上免去了搭后台和管数据库的功夫，实则是把压力转移到了发布端——每次修改字句，流程上都像是在做一次微型的软件发布。内容写作本该是轻快的，这种摩擦让我意识到，必须把写作和发布从复杂的流程里解脱出来。
新主站之后：先把发布做轻
转机发生在我完成了自己的新主站设计与开发之后。
我决定重构博客，核心目标很明确：把前期的系统设计做完整，把日常的内容发布做轻。
目标清晰后，推进变得敏捷起来。整套新博客的设计图，我大概花了不到两小时定下视觉框架，这仅仅是指在设计软件里画出界面与排版的时间，后期的代码实现、数据导入与维护并不包含在内。
进入开发阶段后，很多交互细节与小组件是在 Codex 里边做边调整出来的。在写代码的过程中直接感受间距与字体质感，往往比在静态画板里反复推演更直观。
现在回头看，这套技术组合分别接住了几个具体需求：
- Astro 负责服务端生成阅读页面：由 Astro 在服务端生成阅读内容页面。
- React 负责局部交互：负责页面里需要用到的局部交互，以组件形式按需嵌入页面。
- Tiptap 负责后台的富文本编辑：既然不想再折腾本地文件路径，就需要一个在浏览器里随时能写字的现代化编辑器，Tiptap 能够很好地输出结构化内容并支持自定义外观。
现在看来，这样的技术组合让内容消费、局部交互与内容编辑各司其职，收拾起来清爽而明了。
现在的博客首页：文章有了自己的版式与阅读入口。
属于自己的后台与长期的账
有了技术分工，接下来的核心任务是搭一个属于自己的后台。在我的视角里，后台只是在回答日常写作时的几个具体问题。
在哪儿写？
一个打开浏览器就能敲字的后台编辑器。基于 Tiptap 搭建，界面保持干净，不需要打开本地终端，也不需要在 Markdown 语法里手动对齐图片标签。登录后台，光标落下去就可以开始打字。
东西存在哪儿？
存放在基于文件的 SQLite 数据库中，代码层通过 Drizzle 进行数据访问。
对于我目前的个人内容体量来说，一份单文件数据库已经足够装下文章、分类与统计记录。它不需要在服务器上单独维护一套独立的关系型数据库服务，系统也配置了定期的自动备份脚本，帮个人站点省去了一套运维负担。
多个栏目如何组织？
我有很多不同面向的内容想写，有的偏向设计思考，有的偏向工具与前沿技术，有的记录 AI 工作流。
我用一套后台统一管理了多个栏目。目前公开的四个栏目：blog、harness、codex、ai，统一挂载在二级域名
之下，彼此之间用 URL 路径进行自然分流。
除了这四个面向公众开放的栏目之外，我还有一个受保护的作品展示站 work，位于主站域名
下，需要特定授权登录后才能查看。四个公开栏目加一个受保护站，共用一套后台、一个数据库和一套对象存储，免去了在不同后台间来回切换的撕裂感。
发文章还要不要重新部署网站？
不用。在现在的系统里，内容发布和代码更新是两条分开的流程。
写好文章点击发布，后台更新数据库里的文章与发布状态，前台再读取展示，不需要为这篇文章重新构建网站。
而功能或样式变动，才需要更新网站代码。部署脚本安装新的发布版本，备份现有数据库、执行必要的数据迁移，并在重启服务后检查运行状态。分开以后，写文章就不必再走一遍代码发布流程。
自托管的代价
拥有自己的后台确实带来了掌控感，但作为设计工程师，我也明白它的代价：
自己托管，意味着凭据安全、服务器配置、定期数据备份以及运行环境维护，全部需要自己负责。这是为了换取自由所要承担的长期工程责任。如果享受这个搭建过程，这些是探索的乐趣；但如果核心目的只是单纯写字，这些运维工作就会成为切实的精力消耗。
内容怎样走进来：从弯路到接口分工
这一部分是建站过程中调试较多的一环。面对过去散落在外部工具里的旧文章和配图，如何体面地搬运进来，直接决定了新站能不能真正用起来。
最初的弯路
最开始我想得很直接：在 Wolai 里全选复制，粘贴到后台编辑器，再让 AI 做一个功能，遇到图片就自动上传到 OSS。
但在面对包含大量长文和配图的内容时，这种上传方式反复失败。单纯依赖浏览器的剪贴板去搬运高密度图文，是一条不够稳定的弯路。
改用文档接口
碰壁之后，我转向了接口路线。
现在后台处理旧文章导入流程很明确：在后台输入框里粘贴文档链接，后台根据域名识别来源，调用对应的解析模块。
核心逻辑在于：通过接口读取文档系统的底层结构化数据。将标题、引用、列表和图片等块级数据抓取回来，在内存中清洗并映射为自己的数据库格式。
自动化搬运的前提是授权通畅与格式受支持：
- 在 Wolai 这一端，配置对应的开发者 token，用于读取对应文档树的数据。
- 在飞书这一端，依托自建应用凭据，先解析独立文档或知识库（Wiki）节点背后的实体，再分段拉取内容。
之所以专门对接飞书，是因为飞书目前是我日常写作与 AI 协作的核心工作台，文章构思与初步整理常在飞书文档里展开。此前在 Wolai 尝试通过 MCP 处理图片和媒体时，体验上不够顺手，这也促使我将深度写作的工作台重心转向了飞书。既然内容是在飞书里长出来的，博客后台就需要有能力与它对接。
图片的处理
正文文字的转换相对平顺，图片处理需要更严谨。
笔记平台里的图片链接往往带有有效期的临时签名，如果直接存入数据库，签名过期后图片就会失效。
现在的导入流程里，后台在解析到图片时，会主动下载原始图片字节，校验真实大小与媒体格式，并按图片内容生成带有栏目路径的唯一标识。
在写入存储之前，系统会先检查同一栏目里是否已有相同记录。如果已经导入过，就直接复用已有地址；若没有，再正式写入阿里云 OSS 并登记。正文中的临时链接，也会被替换为指向 OSS 的稳定地址。这样减少了对源平台临时链接的依赖，也让同一栏目里的相同图片得到复用。
在飞书把链接交给 Codex
有了服务端的接口能力之后，我把导入这件事封装成了一个命令行工具，以 npm 包的形式放在仓库里，包名是
。包里还附带了一份给模型阅读的操作指引，让 AI 清楚知道该怎么调用、按什么规则处理。
它承接的是服务端已经具备的导入能力：读取已授权的文档内容、把图片取回来安置进我自己的存储、拼出一份草稿，然后把预览链接回传。
我现在的用法是：在飞书对话里把文档链接发给 Codex，由它调用这个工具完成准备，再把预览链接回传给我。我点击打开预览，检查段落、排版与图片，确认无误之后，自己在后台手动发布；如果中途改动过内容，就要重新预览一次。
交出去的是重复劳动：抓取、清洗格式、下载并安置图片、拼出草稿。留在我手上的则是判断：这篇要不要发、什么时候发、以什么样子发。文档链接由我提供，公开发布这一步必须由我本人在浏览器里亲自确认。
导入不等于发布
在导入机制的设计里，我定下了一条规则：导入不等于发布。
本站给 AI 使用的 CLI 与 API，最高权限只能按具体授权的栏目生成待审核草稿。
公开发布必须由管理员在浏览器后台亲自确认。在预览界面检查段落与排版，确认无误后再发布；如果在预览期间文章内容版本发生变化，系统会提示冲突并拒绝发布。
把重复的抓取和排版交给接口与 AI，但把公开发布的把关留给自己。发布流程之外，还有一层值得考虑：文章被搜索到、被转发出去时，别人看到的是什么样子。
文章离开我的站之后
发布这条路走通之后，还有一个经常被忽视的细节：文章一旦离开本站，被搜索到、或者被读者转发出去时，别人第一眼看到的往往不再是正文本身，而是我提供给搜索与分享平台的那部分信息。
这一层信息在系统里被分成了文字与图片两层。
文字那一层，核心思路是「先有一个合理的默认，再留一个可以手改的口子」。每篇文章默认沿用自己的正文标题与摘要，作为搜索和分享时用的描述；如果某篇内容在卡片里需要更凝练的呈现，我也能单独为它写一份标题和摘要。页面同时会给出栏目后缀、规范链接与发布时间，让搜索与分享平台清楚该指向哪里、该显示什么。页面还会输出一段结构化的文章信息，把作者、发布时间、修改时间和配图一并交代给搜索引擎，让它更清楚这是一篇什么文章。后台也留出了一块地方，可以预览搜索结果和分享卡片大概长什么样。
图那一层，主要是自动生成的分享封面。分享封面由服务端按 1200×630 的尺寸自动排版生成。视觉上延续了网站自己的浅色设计，使用同一套字体规范、品牌标识和栏目标签，搭配黑白的几何图形，组合起文章的标题与摘要。
四个公开栏目在视觉上各有自己的图形语言：blog 是唱片式的同心圆，codex 是严整的方格，harness 是连线的节点，ai 则是放射线与三角形。排版逻辑上，标题会按文字长度自动调整字号、最多显示四行，摘要最多展示三行，超出部分直接截断，免得把几何图形和页脚挤掉。实现上，由 Satori 将版式排成 SVG，再交给 Resvg 转成标准的 PNG 图片。
需要说清的是，这是代码模板在根据规则自动排版，并不是每篇文章去调用生成式 AI 画一张图；这张分享封面也不等于正文里的插画。
旧文《AI 打造自己的个人网站》的实际自动分享封面：AI 栏目的几何图形、标题和摘要由模板统一排版。
在日常使用中，我也能为某篇文章单独上传自己的封面图，系统会优先采用自定义图片；如果不想要了，还能随时恢复成自动封面。自动封面让全站风格更容易保持统一，省去了每篇重新排图的心思，但按模板走的方式留给单篇的表达自由相对有限；自定义图片能贴合某一篇文章的具体内容，代价则是每篇都要自己动手制作。两者怎么取舍，是可以随文章调整的选择。
在系统边界上，自动封面由服务端动态生成，自定义封面则走媒体存储写入云端。公开的自动封面接口只服务四个公开栏目中已发布且未删除的文章；草稿封面则可以在登录后的后台预览，不会因此公开。
这些都是我主动提供给搜索和分享平台的信息。我能设定交出去的标题、摘要和图像，平台最终怎样展示依然由各个平台自身决定。
这一层交代清楚了，接下来是那个更老的问题：有没有人真的来看。
有人来过吗：数据、邮件与 RSS
内容稳定流入后台之后，接下来需要解决的是反馈回路：有没有人来看？大家看完了，如果想持续阅读，怎样收到更新？
访问统计
博客的访问统计全部在服务端记录：当请求到达服务器时，服务端在处理页面的同时记录访问日志。统计逻辑会过滤掉常见抓取机器人与浏览器的预取（Prefetch）请求，管理员自己的访问也可以在统计中排除。
系统用访客 Cookie 来区分访问并在服务端做归集：Cookie 中存放一段随机访客标识，服务端将其哈希后用于区分与统计。
现在后台可以按 7 天、30 天或具体文章查看走势，也能查看当前栏目的有效邮箱订阅数以及 RSS 请求累计。我也清楚，记录下的独立访客只是网络环境下的标识聚合，不等于绝对精确的真实人数，而 RSS 请求累计也仅仅反映抓取频次，保持这些理解，数据才能起到客观的参考作用。
邮件订阅
邮件订阅用于提供更新回访通道。读者在页面输入合法邮箱后，订阅即时生效，针对站内的四个公开栏目。受保护的 work 栏目不包含在内。发信通道由异步任务队列配合阿里云邮件推送完成。
公开栏目新文章首次发布时会进入通知流程，而后续对旧文章改错字、换配图或微调段落，不会重复触发群发，避免打扰读者。
RSS
除了邮件，系统也提供了全局统一的 RSS feed。RSS 不需要填写邮箱或注册本站账户，在阅读器里添加订阅链接即可。feed 只收录四个公开栏目（blog、harness、codex、ai）中已经正式发布且未删除的文章，返回最近 50 条摘要加链接，受保护的 work 栏目同样不会出现在公共 feed 里。
统计了解阅读走势，邮件建立更新提醒，RSS 留给习惯在阅读器里阅读的人。有了这些通道，写作与阅读之间便有了一个安静的回路。
如果你也想拥有一个自己的站
很多设计师或设计工程师可能心里也装着一个建站的念头，在现成平台和自建方案之间反复权衡。
要不要自己建站，核心在于审视你当前的真实需求：
- 现成工具的版式和留白，是否已经明显限制了你的视觉表达？
- 当前的发布流程是否太笨重，每次修改都打断写作节奏？
- 现有平台是否很难让 AI 顺畅地帮你处理和流转内容？
- 你是否希望了解站点的基础访问情况，并建立属于自己的订阅通道？
如果现有的笔记或平台能让你顺畅地书写与分享，上面的痛点并没有真正卡住你，那么现成工具就足够好用，不必为了建站而建站。我在 Wolai 持续写了三年多，那些沉淀下来的内容才是后来继续搭建的基础。
如果你想清楚了要开始做，我建议先从一个小闭环起步：
- 挑一篇带图片的真实文章当样本。找一篇包含图文混排的实际文章，尽早暴露排版与图片加载的问题。
- 做出列表页和阅读页。先把核心的文字视觉和阅读版式定下来。
- 跑通一条最基础的链路。集中精力跑通“编辑/导入—生成草稿—前台预览—确认发布”，让文章能在列表里正常显示。
- 检查两项基础体验。在真实网络环境下测试：目标读者访问是否稳定，文章里的图片能否正常加载。
- 按实际需求逐步补齐功能。基础链路顺畅后，再根据需要添加服务端统计、邮件通知、分享呈现或多栏目划分。
如果需要一套具体的技术组合作为参考，可以采用：Astro 负责服务端渲染的内容阅读页，React 负责局部交互，Tiptap 负责后台编辑，SQLite 存放内容并通过 Drizzle 访问，阿里云 OSS 存放媒体文件。再用 CLI 承接文档导入，让 AI 交回草稿预览，由人在后台确认发布；分享封面则采用自动模板，并保留自定义图片的选择。
这套方案契合我自己的习惯，你不必全盘照搬，根据自己的实际情况取舍即可。同时也要正视自托管的长期维护责任：凭据管理、服务器配置和数据备份都需要持续打理。不过，如果你很喜欢我的这个博客站，我已经将整体内容开源，只需要配合上你的配置（OSS 仓库、飞书或是 wolai 账号等等即可直接使用），项目仓库地址是：
GitHub - Niall-Young/blogspace-framework: 一款开源的博客框架，基于我的博客站
按自己的需要，挑选合适的那一部分。
回想 2022 年冬天在开往家里的火车上，那个念头最初只是想找一个合适的地方，把做过的东西好好放进去，期待被看见。几年走下来，经历过现成工具的便利与局限，经历过代码仓库方案的摩擦，也一点点把属于自己的后台搭了起来，如今有了一个更符合自己审美和工作节奏的角落。
分享的初衷其实一直没变，只是现在，我能更踏实地决定它们以怎样的面貌呈现出来。
