很多人不写博客，并不是因为没有内容，而是因为发布成本太高。
本来只是想记录一些想法，却要先打开终端、切换目录、确认环境、执行命令、等待构建。等站点真的上线，写作的连续性早已被打断。久而久之，博客就成了一项“计划中会维护的项目”。
我想做的事情很简单：
让写博客这件事，回到“记笔记”的复杂度。
核心思路只有一句话：
写作和发布全部在浏览器中完成，内容直接提交到 GitHub 仓库。
写完即发布，而不是“准备发布”
这个插件的定位并不是一个新的博客系统，而是一个发布入口的简化器。
在浏览器中，你可以完成所有写作相关的事情：
- 使用 Markdown 编写内容
- 实时预览文章效果
- 点击发布
发布动作本身并不是某种“黑箱操作”，而是一件你非常熟悉的事情：
一次标准的 GitHub 提交。
每一篇文章，都会以文件的形式直接进入你的仓库：
- 提交记录可追溯
- 内容天然可回滚
- 不依赖第三方平台的存储
你的博客站点依旧使用原有的构建方式自动更新，这个插件不会介入站点本身的实现。
使用插件之前：写作是一件需要“准备”的事
在没有插件之前，发布一篇博客通常是这样的流程：
- 打开编辑器，写完文章
- 保存文件，确认路径和命名
- 打开终端
- 切换到博客仓库
- 检查状态、添加文件
- 提交 commit
- 推送到远端
- 等待站点构建完成
这些步骤本身并不难，但它们有一个共同的问题：
写作结束之后，你还需要“再开始一次工作”。
这意味着你必须：
- 从写作状态切换到工程状态
- 从内容思考切换到工具操作
- 在发布前重新确认一遍流程
很多时候，正是这一段切换成本，让“写完了，但没发”。
使用插件之后：发布不再是一个阶段
使用插件之后，写作和发布之间不再有明确的分界线。
流程会变成：
- 在浏览器中写作
- 点击发布
插件会通过 GitHub API，把内容直接提交到仓库中。
构建和部署依旧由你现有的自动化流程完成。
对你来说，变化不在于少做了什么，而在于：
- 不需要打开终端
- 不需要切换上下文
- 不需要为“发布”预留额外精力
发布不再是一个需要单独完成的步骤，而是写作的自然收尾。
为什么是浏览器插件
浏览器插件的优势在于，它足够靠近“写作行为”本身。
- 不需要额外安装桌面应用
- 不绑定具体的博客框架
- 不强迫你改变已有的技术选型
- 随时可用，随写随发
它存在的意义只有一个：
降低“从写完到发布”之间的摩擦。
真正的区别，不在流程，而在心理门槛
从表面上看，你只是少敲了几条命令。
但实际上，你去掉的是：
- “等有空再发”的拖延
- “回头再整理一下”的犹豫
- “今天先写，改天再部署”的中断
当发布的心理门槛足够低，博客才会重新变成一种日常行为，而不是一个工程任务。
我希望这个插件最终带来的体验是：
写完一段想法的那一刻，你就已经完成了发布。