一、写博客的入口，从编辑器变成了对话#

现在我不需要先把文章想完整。一个主题、一段经历、几句还没有整理好的话，甚至只是一个突然想到的问题，都可以直接说出来。

比如：

我想写一篇文章，记录我是怎么借助 AI 把博客发出去的，重点说清楚我们现在形成的工作流，以及为什么使用 Luna 之后成本很低。

这句话本身还不是文章，但它已经包含了文章的方向。

接下来，通过几轮对话，主题会逐渐变得清楚：这篇文章到底想记录什么，哪些内容是事实，哪些只是个人感受，应该从哪个角度展开，最后希望读者记住什么。

对我来说，这比面对一个空白编辑器轻松很多。因为我不需要一开始就同时处理“想写什么”和“应该怎么写”这两件事，只需要先把想法说出来。

二、AI 做的不是简单改写，而是把对话整理成文章#

如果只是把聊天记录复制下来，当然不能算是一篇博客。真正有用的部分，是把对话里散落的内容重新组织起来。

在这个过程中，AI 主要承担几件事：

• 从零散的表达中提取一个相对明确的主题；
• 把前后几轮对话里的信息串成一条主线；
• 删除重复、绕远和只适合聊天的部分；
• 保留个人经历、判断和语气，而不是改成统一的说明书口吻；
• 根据博客已有的风格补出标题、摘要、章节和标签；
• 对不确定的地方保留边界，不把猜测写成确定事实。

这里有一个很重要的区别：我并不是把思考完全交给 AI，而是先通过对话把思考外化，再让 AI 帮我整理。

最终文章里真正有价值的内容，仍然来自我经历过的事情、做过的选择和形成的判断。AI 更像一个随时可以调用的编辑，帮助我把这些东西从聊天状态整理成可以阅读的文字。

三、文章最终还是一个普通的 Markdown 文件#

这套流程能够真正落地，还有一个前提：博客本身采用 GitHub 加 Markdown 的方式管理。

我的博客源码在私有仓库 ly2u/ly2u-blog 中，文章位于：

1
src/content/posts/

每篇文章都是一个普通的 .md 文件，文件开头使用博客现有的 Front Matter，例如标题、发布日期、摘要、分类、标签和是否为草稿等信息。

所以在写入文章之前，AI 需要先读取仓库当前的目录结构、文章格式和最近的内容，而不是凭空假设一个路径。这样做有两个好处：

第一，生成的文件能够符合现有博客的构建规则，不会因为字段写错或目录放错而导致构建失败。

第二，文章会尽量延续原来博客的语气和结构。它不会突然变成一篇和站内其他内容完全不同的模板文章。

我还有一个单独的笔记站 bijiy.com，但它和这个博客的用途不同。笔记仍然由我自己整理和发布；这套“对话后直接提交”的流程，目前只用于 ly2u-blog。

四、从一句话到一个可发布文件#

现在整套流程大致可以概括成下面这样：

1
提出一个想法
2
      ↓
3
通过对话补充背景、经历和判断
4
      ↓
5
AI 提取主题，整理结构，完成文字
6
      ↓
7
读取博客现有格式，生成 Markdown
8
      ↓
9
写入 ly2u-blog/src/content/posts/
10
      ↓
11
提交 GitHub
12
      ↓
13
GitHub Actions 自动检查、构建和部署
14
      ↓
15
blog.ly2u.com 发布

这中间最关键的一步，是把“写文章”和“发布文章”接在了一起。

以前我可能需要在聊天窗口里得到一篇文章，然后自己复制、打开仓库、创建文件、提交。现在只要文章内容和方向已经明确，AI 可以继续完成后面的机械工作：按现有格式创建文件，并提交到正确的仓库和分支。

文章仍然保存在 GitHub 里，仍然可以查看修改历史，也没有因为使用 AI 就引入一个新的数据库或封闭的编辑系统。

五、提交之后，云端自动完成发布#

博客的 main 分支配置了 GitHub Actions。每次有新的提交，工作流会自动执行：

1. 安装项目依赖；
2. 运行 pnpm check；
3. 执行生产构建；
4. 生成 Pagefind 搜索索引；
5. 使用 Wrangler 将最终的 dist 上传到 Cloudflare Pages。

也就是说，我和 AI 的对话并不会直接操作网站服务器。对话最后只产生一个正常的 Git 提交，后面的构建和部署仍然交给已经配置好的自动化流程。

这让整个过程保持得比较简单：

1
对话
2
  ↓
3
Markdown
4
  ↓
5
Git commit
6
  ↓
7
GitHub Actions
8
  ↓
9
Cloudflare Pages
10
  ↓
11
博客页面

如果文章格式有问题，构建检查会先暴露问题；如果构建成功，网站再接收最终产物。至少从工程上看，文章发布并不是一次不可追踪的黑箱操作，而是一个有源文件、有提交记录、有构建过程的普通发布流程。

六、为什么 Luna 让这件事变得更容易坚持#

这套工作流还有一个很现实的条件：并不是每次写博客都需要调用最重的模型。

对于日常文章来说，提取主题、整理段落、润色表达、补充 Front Matter、检查文件路径，再完成一次 GitHub 提交，这些工作使用 Luna 就已经足够了。

由于调用的是 Luna，按照目前的使用方式，单次额度消耗基本可以忽略。这里的价值不只是节省一点模型额度，更重要的是降低了“写一篇文章”的心理成本：我不需要因为一次普通的记录，就专门安排一套很重的流程。

如果每个想法都要经过复杂的编辑、排版和发布步骤，博客很容易重新变成一个需要刻意维护的项目。轻量模型加上自动化提交，让它更接近日常记录，而不是一次正式的内容生产任务。

七、它真正减少的是启动成本#

回头看，这套方式并没有改变写作最核心的部分。我仍然需要有经历、有问题、有判断，也仍然需要决定一篇文章是否值得留下来。

它减少的是启动成本：

• 不必等到有完整提纲之后才开始；
• 不必先处理文件名、目录和 Front Matter；
• 不必在聊天、编辑器和 GitHub 页面之间反复切换；
• 不必为了发布一篇短文单独维护一套复杂流程；
• 以后想修改时，仍然可以从原来的 Markdown 和 Git 历史继续开始。

这也比较符合我搭建这个博客时一直想要的方向：网站可以有一定的功能，但内容本身尽量保持简单、开放和可迁移。

八、自动化不等于不需要判断#

当然，这套流程并不是说以后只要随便说几句话，所有内容就应该直接公开。

对于技术经验、工程资料、历史信息或涉及他人的内容，仍然需要人工判断哪些可以发布，哪些需要核对，哪些只适合保留在私人笔记里。AI 可以帮我整理表达，但不能替我承担事实责任，也不能替我决定一段经历是否应该公开。

所以我更愿意把它理解成一种“半自动写作”：

人负责提供真实的经历、问题和判断，AI 负责整理与执行，GitHub 负责保存版本，云端流程负责完成发布。

自动化的是重复劳动，不是思考本身。

结语：先说出来，再让它留下来#

以前我常常把写博客想成一个完整的动作：坐下来，写完一篇文章，然后发布。

现在这个过程被拆成了几个更容易开始的小步骤：先说出一个想法，再通过对话把它想清楚；想清楚之后，让 AI 整理成 Markdown；文件进入 GitHub，再由云端自动完成构建和发布。

这篇文章本身就是这样产生的。我没有先在编辑器里写好全文，而是先说出想记录的工作流，再让 AI 根据我们的对话把它整理出来，最后写入博客仓库。

对我来说，这种方式最有意义的地方，可能不是“AI 帮我写了一篇文章”，而是以后那些原本只会停留在聊天里的想法，有机会真正变成博客里一篇可以被留下来的记录。

先说出来，再让它留下来。