把 AI 助手的博客发布流程，改造成一句话触发的工作流

摘要：每次让 AI 助手写博客都要复制一长串模板、再手动发布，效率极低。本文展示如何把整条流程固化为 Skill，一句话触发自动产出三份文件、确认后一键推送，并拆解三个关键设计决策。

引子：你是否有过这样的体验

用 AI 助手干活时，你大概经历过这个循环：

  1. 想让它把一段对话整理成博客，于是翻出一份写好的”提示词模板”，复制、粘贴。
  2. 模板太长，每次都要改日期、改主题，粘错了还得重来。
  3. 生成完只有一篇文章，个人博客、CSDN、知乎各平台还得分别手动处理。
  4. 想发布个人博客，还得自己打开 Git 敲命令。

一次两次还能忍，但如果这件事每周都要做几遍，浪费的时间就很可观了。

本文用一个真实案例说明：如何把”让 AI 助手做重复任务”从”复制模板”升级为”一句话触发”，让机器完整执行多步骤流程。改造对象是博客发布，但方法本身可以迁移到任何高频重复的 AI 任务。

一、先讲清楚：什么是 AI 助手的 Skill

“Skill”是 AI 编程助手（如 CodeBuddy）的一种扩展机制。你可以把它理解成一个机器可直接执行的指令包，通常包含：

组成部分 作用
说明文档（SKILL.md） 定义这个技能做什么、什么话会触发它、按什么步骤执行
模板 / 参考文档 规定产物的格式、结构、命名规则
脚本 处理确定性的计算，比如日期、序号、Git 推送

关键区别在于：提示词模板是给”人”看的，Skill 是给”机器”执行的。 把流程写成模板、让用户自己复制粘贴，等于把本该由机器做的工作推回给了人——这就是大多数 AI 工作流”半自动化”的根源。

二、改造前的痛点：一次博客发布要折腾四步

改造前的博客产出流程是这样的：

1
2
检测到"整理成博客"意图 → 让用户复制 blog-prompt.md 模板
→ 用户粘贴给 AI → AI 生成 Obsidian 博客 + 发布清单 → 用户手动 git push

三个毛病：

毛病 具体表现
多一步手动操作 用户要自己复制、粘贴模板，做不到”一句话触发”
模板与主流程脱节 模板单独放在 references 目录，Skill 主流程不直接执行
产物不完整 只出 Obsidian 博客 + 发布清单，个人博客（Hexo）要另写，推送要另做

改造目标很明确：说一句「把刚才这段对话整理成博客」，AI 自动完成提炼、产出文件、等待确认、推送部署。

三、改造方案：一句话触发，一次产出三份文件

改造后的 Skill 一次运行产出三份文件，对应三个用途：

# 文件 路径 用途
1 Obsidian 正式博客 08-博客/001-博文/NN.标题.md CSDN 等平台发布，正文保留 [[wikilink]]
2 发布清单 08-博客/001-博文/NN.标题.发布清单.md 发布前逐平台核对：标签 + 摘要 + 封面图
3 Hexo 个人博客 source/_posts/NN.标题.md 个人网站，title/tags/date/description，去掉 wikilink

为什么是三份而不是一份？因为三个平台的格式要求不同：Obsidian 用 created/updated 字段且保留 wikilink，Hexo 必须用 title/date/description 且去掉 wikilink（否则渲染报错），发布清单则是给人核对用的操作页。一次生成、各取所需。

四、三个关键设计决策

1. 摘要统一 50-80 字

发布清单和博客 front-matter 里的摘要，统一为 50-80 字、不超过 100 字。旧规范写的是 100-150 字，实测 CSDN 摘要栏放不下、读者也没耐心看，于是全部改成 50-80 字。这条规则同时固化进了写作规范和模板，避免每次生成时凭感觉写。

2. 推送”确认后”才执行

Git 推送是不可逆操作，所以做成硬性规则：三份文件生成后必须停下，向用户展示文件路径、标签摘要、commit 信息，等用户说「确认」才执行 git commit + push。绝不自动 push。 这是自动化流程里最重要的安全边界——机器跑得再快，也不该在没有确认的情况下改写远程仓库。

3. 序号两边独立续接

Obsidian 目录和 Hexo 目录的博客序号不同步，因此序号要各自数、各自 +1。这个细节最容易出错——如果共用一个序号，下一篇就会撞号覆盖。

五、推送脚本：只 add 指定文件

配套的推送脚本 publish_blog.py 只做三件事，但有一个关键约束：

1
2
3
4
# 核心逻辑：只提交指定的博客文件，绝不 git add .
subprocess.run(["git", "add", blog_file], cwd=BLOG_REPO, check=True)
subprocess.run(["git", "commit", "-m", commit_msg], cwd=BLOG_REPO, check=True)
subprocess.run(["git", "push", "origin", "main"], cwd=BLOG_REPO, check=True)

只 add 指定的那篇博客文件，绝不 git add .。 因为博客仓库里混着数据库文件、日志、构建产物等未跟踪文件，git add . 会把它们全部带上，污染一次本应干净的提交。

六、路径集中配置：换机器只改两行

改造前，博客仓库路径和 Git 分支名散落在 5 个文件里（Skill 说明 3 处、模板 2 处、脚本里还有一份），换机器要逐个改。改造后，所有路径集中到 Skill 说明文件顶部的「配置」节，三个变量：

1
2
3
VAULT_ROOT  = d:\Obsidian\笔记
BLOG_REPO   = D:\Blog
BLOG_BRANCH = main

脚本通过 read_skill_config() 自动读取，支持命令行参数覆盖。迁移成本从”改 5 处”降到”改 2 行”。

七、效果与验证

改造完成后做了两层验证：

  • 两个脚本通过 Python 语法检查，lint 0 错误。
  • 用一条真实指令「把刚才这段对话整理成博客」端到端实测：三份文件正确生成、序号各自续接、确认后 git push 成功、个人博客由 Netlify 自动重新部署。
  • 整个改造涉及 7 个文件：Skill 说明、模板、写作规则、发布清单文档、推送脚本（新建）、内容预处理脚本、README。

八、这套方法能迁移到什么场景

本文改造的是博客发布，但背后是一套通用方法，任何”高频 + 多步骤 + 有固定产出格式”的 AI 任务都能套用：

  1. 把流程写成机器可执行的步骤，而不是让用户复制的模板。
  2. 一次产出满足所有下游需求的完整产物（三份文件、各取所需）。
  3. 自动化里保留安全边界（确认后推送、只提交指定文件）。
  4. 集中配置所有环境相关路径，让技能随处可迁移。

下次你发现自己又在给 AI 助手复制一段长长的指令，就可以停下来想想：这段流程，是不是值得固化成一个 Skill？