最近我把“写博客到上线发布”这件事，整理成了一套可复用的 Skills 流程。本文不讲空概念，直接分享一次真实落地过程：我们如何把写作、配图、建文、构建、部署串成一个可执行闭环。
为什么要做这套 Skills
博客更新最大的阻力通常不是不会写，而是流程碎片化：
- 文章要反复改，版本来回跳
- 封面图风格不统一，视觉质量不稳定
- 目录和文件命名容易出错
- 发布前容易漏掉构建检查
- 上线步骤依赖人工记忆
这套 Skills 的目标很明确：
把博客发布流程标准化，让一次主题输入可以稳定走到最终上线。
我们沉淀出来的 5 步链路
1. 内容打磨与确认
先把用户给的草稿、观点或主题，补全为可发布文章。这个阶段必须有一次确认关卡，避免后续封面和发布阶段返工。
2. 生成封面图
通过 Playwright 打开 https://chatgpt.com/images，先检查登录状态，再根据文章主题生成一张横版封面（16:9 方向的视觉风格要求），并下载到本地。
3. 图片压缩与文章落盘
将封面图放到 static/img/posts/，若图片超过 1MB 则强制压缩并转为 webp，目标尽量压到 700KB 内。随后按 content/post/YYYY/MM/ 自动建目录和 Markdown 文件，在 frontmatter 中绑定封面路径。
4. Hugo 构建检查
执行 ./build.sh 验证站点可编译。只要有报错就先修复，不允许直接跳到部署环节。
5. 部署上线
执行 ./deploy.sh 完成发布，并明确返回线上访问地址，确保发布动作可追踪、可确认。
这次实战里最关键的三个细节
细节一：确认关卡不能省
确认不是形式化步骤，而是减少返工成本的关键控制点。先确认内容，再做封面和发布，效率会明显更高。
细节二：图片标准必须固定
封面统一横版、统一目录、统一 webp，能同时提升：
- 视觉一致性
- 页面加载稳定性
- 后续维护可预测性
细节三：先构建再部署是底线
build 是最低成本质量门，任何跳过构建直接上线的流程，最终都会把小问题放大成线上问题。
从一次发布，变成可复用能力
这套 Skills 的价值，不是“多写一篇文章”，而是把一次性的手工流程沉淀为可复制能力：
- 输入：一个主题或草稿
- 过程：标准化、可观测、可复用
- 输出：一篇已上线且可稳定维护的博客文章
当流程稳定后，创作节奏会更可持续，发布质量也会更稳定。
结语
长期写博客，拼的不只是灵感，更是流程工程化能力。先把“写作 -> 构建 -> 发布”跑通，再逐步加入封面自动化和质量检查，你会明显感受到内容生产效率的提升。