害 事情是这样的
前两天不是刚准备从 Notion 迁移到 Obsidian 嘛, 就想着利用 Obsidian 再建个博客备份站吧, 但是市面上有挺多静态博客框架的, 结果我这爱对比框架的习惯让我找了好一会才选了一个完美支持双链并且主题看起来还行的 Quartz
选完框架后又开始对比部署在哪里比较好, 基于分散风险的考虑, 决定部署在 Cloudflare Pages, 不过部署方式又遇到了 2 种可选的方案, 思来想去问了问 Grok
它花了 19 秒给出了分析维度和参考意见以及最终的对比结果.
我原话是这么问的
现在有这样两个方案,
1. 通过git私有库a同步md文件, 每个md文件都有publish:true 标记, 通过github actions筛选带标记的md文件同步到另一个git仓库的content目录, 该仓库b同步上游最新的jackyzha0/quartz仓库代码, 同时仓库b的github actions收到仓库a的同步动作后自动构建并发布到cloudflare pages中
2. 只有一个仓库a, 同步上游最新的jackyzha0/quartz仓库代码, 并且content文件夹中的md文件包含publish:true或publish:false或不包含publish, 修改quartz.config.ts筛选带标记的md文件并通过github actions自动构建并发布到cloudflare pages中
以上两个方案那个更好, 详细分析它从 简单性、维护性、安全性、灵活性、性能与自动化、成本以及潜在风险 进行了回答.
看起来非常全面, 但是后期的扩展性好像没有涉及, 于是我又问
方案2如果后期需要发布到多个内容源 也是更优的嘛? 比如同时发布到cloudflare pages和netlify和vercel, 扩展性如何解决它思考了 5 秒, 随即回答 甚至给出了 Github Actions 的 yaml 代码
这下我相当放心了, 就采用方案2
一开始主要想在方案1上用心, 不过前前后后搞了一天, 实在麻烦, 于是就有了现在这个域名 aurizenshare.pages.dev