2026/02/22，记录
今日从notionNext迁移到mizuki了。
====
要说为什么要换到mizuki，大概就是因为notionNext的限制太死了，毕竟现在vibe coding这么发达，还是想自由调整一点的。
其实一开始是打算使用hexo或者innei看看的，结果没想到正好碰到mizuki的一个视频，就打算先换换看，正好功能不算太重，感觉对于个人和项目的平衡也不错。
那么下面就大概是本人使用notion作为blog存储进行的mizuki迁移记录。
mizuki部署
Mizuki是一个基于Astro开发的博客框架。有一说一，虽然之前搞了不少像是wordpress/hexo/notionNext之类的自部署博客，但其实只是大致看个外形，觉得主题不错就打算切了，当然这次也不例外（
这次选择切换的主要理由大概就是因为mizuki有日记可以满足轻量吐槽的需求，也有project来展示一下项目的地方。加上Astro毕竟大众主题，想要vibe的话素材应该还是比较充沛的，所以就切过来了（然后就遇到坑了（乐）
mizuki配置
大致配置也没有什么，按照官方文档进行配置就好了。
大概要注意的就是post和about的内容是通过修改md来控制的，而其他的像是dairy/project/timeline这些内容则是通过修改ts里面的data来进行控制的。
不过还有一个有趣的是可以连接bangumi的api(/v0/users/{userId}/collections)来获取用户番剧记录。那么其实稍微把获取类型改一下，加上配置一个bangumi的token其实就可以看到eroge的收藏list了。然后把动画页面再稍微改一下，eroge的记录页面就新鲜出炉了（挖坑
个人配置
然后再说下个人配置，因为打算用ci把notion的内容实时同步到mizuki里面，加上mizuki正好支持对博客内容和架构进行分开编写，所以就正好在内容仓库来动动手脚了，结构简单改起来也方便不少。
大致打算修改的其实就是两块：通过ci让notion的编写内容和通过llm对notion同步的文章预处理来实现多语言。
通过ci对notion内容进行同步
其实要说也就是做一个cron定时，来定期查询notion的内容更新状况，不过毕竟是notion api那通信速度，怕不是跑个两天就把GitHub的action额度给跑完了，所以就直接给这个同步action放在self host上跑了。
具体实现其实也没啥，思路就是把notion的databse的内容取出来，然后让post/about/dairy之类的这些不同类型内容更加一个type分流，然后再通过notion数据库的colum和实际上述内容的具体配置进行对应，然后就是顺理成章的事了（指vibe一下）。
不过有个小坑是，有些img直接取的notion头图链接其实是一个1h就会过期的url（话说没想到notion用的图片存储其实是aws s3，感觉r2不是更量大吗），所以还是得找个外部存储持久化一下（其实r2就行）。不过如果在添加notion图片的时候，直接用的url，那么其实取出来的还是上面填写的图片链接。所以其实只要提前把图片update好，这个倒也不是什么大问题。
具体实现大概可以参考这里： NotionSyncAction(正好试一下mizuki-GitHub的repo可以怎么用（
通过llm来进行多语言适配
其实在在notion同步ci之前，对于mizuki的框架部分也得进行一下修改。毕竟目前还是没有去做跟随浏览器语言来进行显示语言切换的，所以就稍微小改了一番（指把对于.en.md/.ja.md这种后缀类型的文件给收入到多语言适配中，本身框架用的因为是静态站，所以如果要多ui显示那就得大改了）。毕竟这种多语言切换什么的在各种项目上的实现应该都挺多的了，大致说明一下vibe一下就好了。
然后再就是给ci中加入llm的翻译模块。
其实也差不多，通用的翻译prompt，加上简单的api调用，稍微vibe一下就可以了。就是得小心一下大文章的llm回复时间可能很长，得稍微调整一下实际请求的超时时间。
结语
大致应该也就这些，毕竟也没有什么太深入的修改，就大概说一下个人的配置思路吧。
现在ci配完，应该也算是让输出的flow稍微舒畅一点了（
不过感觉未来适配多语言ui也是一个大坑（
2026/02/22 — Notes
Today I migrated from NotionNext to Mizuki.
====
To explain why I switched to Mizuki, it’s mainly because NotionNext’s limitations are too rigid; after all, vibe coding has become so developed nowadays, and I want a bit more freedom to adjust.
Originally I planned to check out Hexo or Innei, but I happened to come across a Mizuki video, so I decided to give it a try first. The functionality isn’t too heavy, and it feels like a good balance for personal and project use.
So below is roughly my Mizuki migration log, using Notion as the blog storage.
Mizuki deployment
Mizuki is a blog framework built on Astro. Truth be told, although I had previously tinkered with several self-hosted blogs like WordPress/Hexo/NotionNext, I mainly looked at the appearance and decided to switch if the theme looked good; and this time it’s no exception (
The main reason for switching this time is probably that Mizuki has a diary to satisfy lightweight venting, and a place to showcase projects. Plus Astro is a popular theme, so if you want vibe the assets should still be relatively plentiful, so I switched over (and then hit some pitfalls (lol))
Mizuki configuration
The general configuration isn’t complicated; just follow the official documentation to configure it.
The main thing to note is that the content of posts and about is controlled by editing md files, while other elements like diary/project/timeline are controlled by modifying the data inside the TS files.
However, there’s another interesting thing: you can connect to Bangumi’s API (/v0/users/{userId}/collections) to fetch a user’s anime records. Then if you slightly adjust the fetch type and configure a Bangumi token, you can see the eroge collection list. Then tweak the animation page a bit, and the eroge records page will be freshly released (digging a pit).
Personal configuration
Then let’s talk about personal configuration. Because I plan to use CI to synchronize Notion content into Mizuki in real time, and Mizuki conveniently supports separating blog content and architecture, I decided to tinker in the content repository; the structure is simpler to modify and much more convenient.
Basically, the two areas I plan to modify are: using CI to sync Notion-written content and using an LLm to preprocess Notion-synced articles to enable multilingual support.
Synchronizing Notion content via CI
Actually, it’s basically a cron job to periodically check Notion content updates. But given the Notion API’s throughput, I’m worried that it would exhaust GitHub Actions quotas in a couple of days, so I put this sync action on a self-hosted runner.
The basic idea is to fetch the Notion database content, then route different content types such as posts/about/diary into separate type streams, and then map them to the Notion database columns and the actual configurations of the content above, making it a natural progression (for vibe).
One small pitfall is that some images pulled directly from Notion header images are expiring URLs after about an hour (honestly I didn’t expect Notion’s image storage to be AWS S3; R2 might be more scalable). So you still need external storage for persistence (R2 would work). But if when adding Notion images you directly use the URL, what you fetch back will still be the image link you filled above. So as long as you update the images in advance, this isn’t a big problem.
The rough implementation can be referenced here: NotionSyncAction (just to test how the Mizuki-GitHub repo can be used
Multilingual adaptation with LLM
Actually, even before the Notion sync CI, I had to make some modifications to Mizuki’s framework. After all, it still doesn’t switch display language according to browser language, so I did a small tweak (i.e., include files with suffixes like .en.md/.ja.md into multilingual adaptation; since the framework is static, enabling more UI language displays would require a major rewrite). After all, implementations of multilingual switching exist in many projects; I’ll just give a rough vibe.
Then also add an LLM translation module to CI.
It’s basically the same: a generic translation prompt plus a simple API call; with a bit of vibe it’s doable. Just be careful that LLM responses for long articles may take a long time, so you may need to adjust the actual request timeout a bit.
Conclusion
That’s about it; there aren’t deep changes, just roughly outlining my personal configuration approach.
Now that CI is configured, it should make the output flow a bit smoother (
But I feel that future multilingual UI adaptation will also be a big challenge (
2026/02/22、記録
今日はNotionNextからMizukiへ移行しました。
====
Mizukiに乗り換える理由は、おおむねNotionNextの制限があまりにも厳しすぎるからです。いまやVibe Codingがこれほど発展しているのだから、自由に少しだけ調整したいという思いもあります。
実は最初はHexoやInneiを試してみようと思っていましたが、偶然 Mizuki の動画を見つけて、まずは試しに乗り換えてみることにしました。機能はそれほど重くなく、個人とプロジェクトのバランスにも良い感じだと感じました。
それでは以下に、私がNotionをブログ保存として使用してMizukiへ移行した記録の概略を記します。
Mizukiのデプロイ
MizukiはAstroをベースに開発されたブログフレームワークです。正直なところ、以前はWordPress／Hexo／NotionNext などの自前デプロイ型ブログをいくつか扱ってきましたが、外見を大まかに見てテーマが良いと感じたので乗り換えようと考えました。もちろん今回も例外ではありません（
今回切り替えを選んだ主な理由は、Mizukiには日記機能があり、軽いつぶやきのニーズを満たせることと、プロジェクトを紹介する場所があることです。Astroはやはり一般向けのテーマなので、Vibeを使いたい場合には素材も比較的豊富でしょう。というわけで乗り換えました（ただし困難にも直面しました（笑））
Mizukiの設定
大まかな設定自体には特に難しい点はなく、公式ドキュメントに従って設定すればよいです。
注意すべき点は、投稿と自己紹介ページの内容はMarkdownを修正して制御しますが、日記・プロジェクト・タイムラインといった他の内容は、TypeScriptのdataを変更して制御します。
さらに面白い点として Bangumi の API（/v0/users/{userId}/collections）に接続してユーザーの番組履歴を取得することができます。取得タイプを少し変更してBangumiのトークンを設定すれば、エロゲーのコレクションリストが表示できるようになります。その後、アニメのページを少しだけ変更すれば、エロゲーの記録ページが新しく登場します（坑を掘る）
個人設定
次に個人設定についてです。Notionの内容をCIでリアルタイムにMizukiに同期させる予定があるため、Mizukiはブログの内容と構成を分離して記述することをサポートしています。そのため、コンテンツのリポジトリで手を動かして、構造をシンプルにして編集をかなり楽にしました。
大体変更を加えようとしているのは2つの部分です。CIを通じてNotionの執筆内容を同期し、Notion同期の文章をLLMで前処理して多言語対応を実現します。
Notion内容をCIで同期する
正直言えば、Notion の内容更新状況を定期的に照会するCronを作るということです。ただしNotion APIの通信速度を考えると、2日も経たずGitHub Actionsの実行枠を使い果たしてしまうのではないかと思い、この同期アクションをセルフホストで実行することにしました。
具体的な実装は特に難しくなく、Notion データベースの内容を取り出し、投稿・自己紹介ページ・日記のような異なるタイプのコンテンツを1つのタイプに振り分け、Notion データベースのカラムと前述の各コンテンツの具体的な設定を対応させる、という流れです。あとは自然に成り立ちます（雰囲気を整える意味です）。
ただし小さな落とし穴があります。Notion のヘッダー画像のリンクの一部は実際には1時間で期限切れになるURLです（Notion が画像保存に AWS S3 を使っているとは思いませんでした。R2 のほうが容量が大きい気がします）。なので、外部ストレージに永続化する必要があります（実際には R2 で十分です）。ただNotion画像を追加する際に直接URLを使うと、取得しても上記の画像リンクのままになります。ですので、事前に画像を更新しておけば、これほど大きな問題にはなりません。
具体的な実装はおおよそここを参考にできます： NotionSyncAction（ Mizuki-GitHub のリポジトリをどう使うか試してみるにはちょうどよいです）
LLMを用いた多言語対応
実は Notion同期CI の前に、Mizuki のフレームワーク部分にも少し修正が必要でした。現状はブラウザ言語に追従して表示言語を切り替える機能がまだ実装されていないため、少しだけ変更しました（.en.md/.ja.md のような拡張子を持つファイルを多言語対応へ取り込む形です。元々静的サイトを前提にしたフレームワークなので、多言語UIを追加するには大幅な改修が必要になるかもしれません）。この種の多言語切替の実装は様々なプロジェクトでかなり見かけるので、雰囲気だけ説明しておけば十分です。
そしてCIにLLM翻訳モジュールを追加します。
実際にはほぼ同じです。一般的な翻訳のプロンプトに、簡単なAPI呼び出しを組み合わせて、雰囲気を整えるだけで動作します。ただし長文のLLMの応答時間が長くなることがあるので、実際のリクエストのタイムアウトを少し調整する必要があります。
結び
大体はこれくらいです。深い変更はあまりしていないので、個人的な設定方針を大まかに述べます。
現在CIの設定が完了したので、出力のフローが多少スムーズになったと言えるでしょう（
ただし将来的に多言語UIへ対応するのは大きなハードルだと感じます（
部分信息可能已经过时