Visualization for Hexo项目地址，持续开发中

项目的初衷

在日常写博客时，很多人都会遇到同一个痛点：写作在编辑器里，预览在浏览器里，发布又要切到命令行，流程割裂、上下文频繁切换。为了解决这个问题，我做了一个桌面工具 Visualization for Hexo。它基于 Qt/QML 开发，目标很明确：把本地博客内容编辑与发布流程串成一个顺滑闭环。

Hexo 本身很强大，但命令行工作流对内容创作者并不总是友好。尤其在高频写作场景下，你经常需要反复执行几件事：浏览并切换文章、编辑 Markdown 并实时预览、运行构建或发布命令、查看 Git 状态并提交改动。如果这些操作分散在多个工具里，效率会被持续拉低；而如果集中到同一个界面，体验会连贯很多。

项目的高中

这个项目目前已经覆盖博客管理中的核心环节：文章列表切换、编辑预览联动、常用 Hexo 命令集成、Git 操作封装，以及基于 QML 的现代化无边框界面。简单来说，它既像一个博客控制台，也像一个轻量本地工作台。

技术上，项目采用 C++17 负责底层逻辑与服务编排，Qt 6（QML + Qt Quick）负责界面层表达，MSBuild 和 PowerShell 脚本负责构建与打包。这样的组合既保证了桌面端稳定性，也保留了足够的 UI 可塑性，适合持续迭代的本地工具场景。

运行环境推荐 Windows 10/11、Visual Studio 2022（含 MSVC x64 工具链）和 Qt 6.8 以上；如果你要完整跑通博客链路，还可以配合 Node.js、Hexo CLI 和 Git。上手也很直接：克隆仓库、执行调试构建脚本、运行可执行文件即可。项目也提供发布构建脚本，可完成 Release 编译、windeployqt 依赖收集并输出可分发 zip 包。

image-20260315134101039

从工程结构看，代码分层比较清晰：核心逻辑集中在 src/core、src/adapters、src/models，UI 资源在 qml 与 components，构建脚本在 scripts。这种组织方式对维护和扩展都更友好。实践上，建议统一使用脚本构建、提交前至少跑一次 Debug 构建、发布前做一次“解压即运行”验证，能显著降低交付风险。

项目的大学

很简单，进入我的项目主页，点击Release，然后下载解压它，运行其中的exe文件即可。不过若是想再为其添加一些新功能，或改变他的界面样式，README.md 文件会帮助你。

image-20260315134420494

项目的研究生

倘若你已经拥有一个正在运行的博客网站，那么直接选择其文件夹即可——但需要注意的是必须是hexo框架，正如项目的名字所言。倘若你还没有自己的博客，那么很好，新建一个文件夹，随便他叫什么，然后开始。

image-20260315134712009

程序会自动帮你配置好基础所需的一切（值得一提的是因为我的电脑上已经配置了Hexo的前置环境，如果你想使用它的话，建议先参考教程准备好安装环境），当裸Hexo预览出现在你的4000端口，则表示你可以开始进行主题的选择并配置你的网站了。

image-20260315134732339

初始化的工作会有点漫长，请耐心等待。当浏览器打开预览界面后就可以进行下一步了。

image-20260315135003099

非常完美。

我们可以在文章的头部修改编辑文章的信息，不再是通过MD代码段来设置，另外我还加入了文章描述的AI功能，只不过需要你配置一下API key，对于这种轻度环境来说，GLM-4.7flash显然是很好的选择（只是推荐），项目在未配置 API key 时，会按如下顺序依次检查：

  1. 读取系统环境变量 GLM_API_KEY，如果没有则继续；
  2. 读取环境变量 ZHIPUAI_API_KEY，如果没有则继续；
  3. 读取环境变量 OPENAI_API_KEY，如果没有则继续；

所以API key的命名还是按上述方法来吧。

image-20260315135346598

总的来说，Visualization for Hexo 想解决的不是某个炫技功能，而是创作流程里真实存在的摩擦成本：把分散的博客工作流收敛成一个可视化、可持续、可迭代的桌面体验，让你把更多精力放在内容本身。