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