这几天我做了一件很典型、但也很容易越做越乱的事情：重新整理自己的个人博客。
原本我只是想“再改一改网站页面”，后来目标慢慢变得更清晰了。我想要的不是一个随便能用的博客，而是一套真正适合长期写作的系统。它应该有我喜欢的风格，最好接近 Ghost 上 Haas 主题那种偏编辑部、偏杂志感的气质；它也应该有一条顺手的发布链路，让我在 Obsidian 里写完文章之后，不需要在好几个目录之间来回搬文件。
这篇文章记录的，就是这次整理博客的全过程。
先把真正的博客源码找回来
一开始最大的障碍不是设计，而是“源代码到底在哪”。
我的博客跑在 blog.capootech.com，但是本地并没有一个现成、明确的 Hugo 仓库。后来顺着已有的项目笔记和部署信息一点点查，才确认真正的 Hugo 源码其实部署在我的阿里云上海服务器上。
于是第一步就变成了很朴素的运维工作：
- 确认服务器上的博客目录
- 把 Hugo 项目从服务器同步回本地工作区
- 在本地整理成一个可以继续维护的仓库
只有把这一步做扎实，后面无论是改主题、写文章还是做自动发布，才有稳定的基础。不然所有修改都像在“摸黑操作生产环境”。
博客页面不是小修，而是重做一遍展示层
把源码拿回来之后，我重新看了一遍博客本身，发现真正的问题不在某一个按钮、某一段间距或者某个颜色变量。
问题在于它整体的气质不对。
我想要的是那种更像出版物的感觉：标题要更有存在感，首页应该像在推荐文章，而不是机械地堆列表；文章详情页也应该更像“阅读页面”，而不是一套默认主题的技术文档壳子。
所以这次不是在原有页面上打补丁，而是直接把展示层按新的方向重做了一遍。目标很明确：向 Ghost 的 Haas 风格靠，但不照搬，而是变成适合我自己博客内容的版本。
这次重做里，比较关键的部分包括：
- 用更偏编辑感的首页结构替掉原来的普通列表页
- 重做文章卡片、文章详情页、标签页、归档页和搜索页
- 把整体配色、留白和版式往“浅底、阅读优先、杂志感”上推
- 让页面结构不再依赖原来主题的默认布局
当博客真正开始长内容的时候，展示方式本身就是内容的一部分。一个写作者的网站，不应该只是“能打开文章”；它应该让访问者一眼看出这里是在认真地组织内容。
改完本地，还得真的上线
很多“博客改版”最后停在本地预览能打开，线上一直没切过去。
这次我不想留在这个状态里，所以改完之后做的不是“先这样吧”，而是直接上线。
上线这一步其实也有两个重点。
第一，是先做备份。生产环境博客在动之前，先把服务器上的现有版本打包备份，确保新页面有问题时可以回滚。
第二，是把“本地改动”和“服务器生成”明确分开：本地继续维护 Hugo 源码，服务器负责接收同步后的代码并重新生成 public 目录。这样部署逻辑很清楚，后面也方便继续维护。
结果就是，新的博客页面没有停留在“做完了但没发”，而是真的切到了线上。那种感觉很直接：这个博客终于开始长成我真正想要的样子了。
真正更重要的，其实是写作流程
页面上线只是第一层。更重要的问题其实是：以后我怎么发文章？
我平时写东西主要还是在 Obsidian 里。如果每次写完之后，还要手动把 Markdown 复制到 Hugo 的 content/posts，再去处理图片、front matter、文件名和 slug，这种流程几次之后就一定会变得烦。
所以后面最值得做的事情，反而不是视觉，而是把 Obsidian 和博客真正接起来。
这次最后定下来的关系是：
- Obsidian 里的
发表文章文件夹，作为写作源目录 - Hugo 仓库里的
content/posts，作为同步后的发布产物 - 博客展示、搜索、归档等逻辑，继续由 Hugo 负责
也就是说，内容只在一处维护，展示只在一处维护。两边的边界要清楚，不然迟早会出现“这篇文章到底应该改 Obsidian 那份还是 Hugo 那份”的混乱。
同步脚本把“写作”和“发布”拆开了
为了让这件事稳定可用，我补了一层同步脚本。
它负责做几件很琐碎但非常必要的事情：
- 读取 Obsidian 文章里的 front matter
- 把
publish: true的文章同步到 Hugo - 把
publish: false的文章保留在 Obsidian，不同步到博客 - 自动处理 Obsidian 图片引用和相对路径图片
- 维护一个 manifest，知道哪些文章是由这套流程生成的
这样一来，Obsidian 里的文章就不再只是“普通笔记”，而是变成了博客内容的真正源头。
这里最关键的设计其实只有一句话：Obsidian 管内容，Hugo 管展示。
这个分层非常重要。它让写作和建站不再互相打架。
再往前走一步：把发布动作做进 Obsidian
如果还要每次打开终端手动敲脚本，这套流程依然不够顺。
于是后面又继续往前推了一步：直接给 Obsidian 做了一个本地插件。
这个插件最早只做几件事：
- 同步全部文章到 Hugo
- 发布全部文章到线上
- 同步当前笔记
- 发布当前笔记
- 新建博客文章模板
做到这一步的时候，流程已经能用了，但还不够像一个真正的“写作工具”。因为它更像是一组命令，而不是一个明确的内容管理入口。
后来又继续补了两层：
第一层，是发布前确认弹窗。这样点到发布命令时，不会直接把内容推上去。
第二层，是文章管理面板。这个面板会把博客目录里的文章分成两类：
- 已发表
- 未发表
已发表的文章可以直接撤回，未发表的文章可以直接发布，同时都可以快速打开原始笔记继续编辑。
做到这里，这个插件才开始真正有“博客管理器”的感觉，而不是一个包着 PowerShell 的按钮集合。
我喜欢这次过程的地方，不只是效率
如果只从结果上看，这件事可以被总结成一句很简单的话：
我和 AI 一起，把博客改版了，上线了，还把 Obsidian 到 Hugo 的发文流程打通了。
但这件事真正有意思的地方，不只是“更快”，而是协作方式变了。
以前做这种事情，最容易卡住的地方通常有两个：
- 事情太散，不知道从哪一步开始
- 每一步都不难，但串起来之后很容易丢上下文
这次的体验是，设计、代码、运维、内容结构、发布流程这些原本属于不同层的事情，被放在同一轮对话里一点点推完了。不是停在建议，不是停在计划，而是真的做成了一个能跑、能写、能发、还能继续维护的系统。
对我来说，这种价值甚至比“省了多少时间”更重要。因为博客不是一次性项目，它是以后还会不断写、不断改、不断长内容的东西。一次把底层流程理顺，后面每次写作都会更轻松。
接下来还可以继续做什么
现在这套博客已经能稳定工作了，但它显然还有继续打磨的空间。
我已经能想到几件后续可以继续推进的事：
- 继续把首页做得更像真正的编辑页，而不是仅仅“更好看”
- 给文章详情页增加更完整的阅读辅助，比如目录、上一篇/下一篇、作者区块
- 给插件里的文章管理面板加更多信息，比如线上链接、最后发布时间、最近修改时间
- 做更完整的文章模板，让新建草稿时就能把标题、slug、tags 一次填好
这些都不是“必须马上做”的事情，但它们说明一件事：博客终于进入了一个值得持续迭代的状态。
写在最后
回头看，这次我原本想做的只是“改一下网站页面”，结果最后做成的是一整套博客系统的重建。
我把博客的展示风格重新拉回了自己喜欢的方向，把真正的 Hugo 源码从服务器上整理回了本地，把线上部署流程重新理顺，又把 Obsidian 写作和博客发布打通，最后还做了一个能直接在 Obsidian 里管理文章的本地插件。
这不是那种“搭了一个博客”的成就感，而更像是终于给自己建立起了一套长期写作的基础设施。
而对一个想持续写东西的人来说，这件事比单独写成任何一篇文章都更重要。