这组文章其实就想讲一件事，AI 写博客到了后面，不能再只靠一段 prompt 硬顶。当前这一篇先讲 blog-writer 为什么会长出来；下一篇会接着写 AI 写博客这件事，后来还是得做成工程（二）：blog-style-suite 怎么把风格学习和 token 成本拆开；最后一篇收在 AI 写博客这件事，后来还是得做成工程（三）：本地模型、在线模型和 Minimax 最后怎么分工。
真正烦人的，不是写稿，是那一串机械动作
早期那套流程，说穿了很像外包流水线。
我自己先把问题列清楚，或者先搭个大纲。模型负责把正文铺出来。然后人再回来补齐剩下的发布动作。
- 复制到本地
md - 补
title、date、slug - 填标签和分类
- 补
<!--more--> - 整理参考资料
- 再决定落到哪个目录
这一串活，单看每一步都不难，连起来就很烦。烦的不是技术难度，烦的是它们都很机械，但又不能不做。
这也是为什么我后来越来越觉得，基于命令行的AI编码交互 这类变化，不只是“换了个入口”。当 AI 已经能直接在仓库里读写文件的时候，博客写作如果还停在“复制正文到本地文档”这一层，整个工作流其实已经落后了。
blog-writer 第一层价值，不是文风，是把契约写死
blog-writer 最早的那个节点，是 2026 年 4 月 1 日 17:00 的 991536a。从 git 提交记录看，这一版已经把 SKILL.md、write_post.py 和一套最初的风格材料一起放进来了。
但我后来回头看，这一稿最值钱的地方，不是“AI 学会了我的文风”，而是先把写稿契约写死了。
什么叫契约写死？
- 输入里至少要有大纲和事实锚点
- 输出必须是完整 Markdown，不是半成品
- frontmatter 不能再靠人补
- 文章不能只停在聊天窗口里，得直接落到
content/post
这件事很重要，因为 prompt 本身不稳定。你今天说一句“帮我像以前那样写”，它可能理解成语气像一点；明天你再说一遍，它可能只学到表面句式。可一旦写成 Skill，规则就从“临场发挥”变成“固定工序”了。
后面的几个节点，其实都在继续补这个契约。
2026 年 4 月 2 日 22:54 的 8eb735a，把作者字段、写作附记、原始提示词这些东西都固定下来了。到这一步，博客成稿已经不是“正文写完就算完”，而是连元信息、可追溯性、公开附记都一起标准化了。
所以 blog-writer 的第一层价值，从来不是让模型显得更会写，而是让写稿这件事终于有了可重复执行的边界。
系列模式，其实也是写作契约往前走了一步
单篇写稳了以后，下一个问题很快就冒出来了。
有些题目根本不适合挤在一篇里。你如果硬塞，最后往往会变成一篇信息很多、主线很散、每个点都讲不透的长文。
这也是为什么 2026 年 4 月 2 日 23:55 的 1a5604e 很关键。那次直接把系列模式和 write_post_series.py 一起补进来了，文章之间用 relref 串起来，批量写入时再统一替换。
这看起来像是个写文件脚本的小升级，实际上不是。
它说明一件事：写作工程化已经不再只考虑“这一篇怎么生成”，而是开始考虑“这一组内容怎么稳定落盘、怎么保证顺序、怎么在站点里互相跳转”。
第二天 2026 年 4 月 3 日 09:29 的 04dccb9 继续把这件事往前推了一步。系列文章时间戳按分钟递增，不再共用一个时间。这个改动很小，但很有工程味，因为它解决的是 Hugo 列表页、上一篇下一篇、系列顺序这些真实问题。
说白了，系列模式不是为了显得高级，而是为了让“多篇一起发”这件事别再靠手工兜底。
但只靠一个 skill，后面还是会撞到 token 墙
问题也就出在这里。
一旦开始认真折腾文风学习，blog-writer 的上下文会很快变胖。你不但要让它会写，还想让它像你以前那样写。那最自然的办法，就是把历史文章也一股脑塞进去。
这么干，单次当然能跑。
但只要你不是偶尔写一篇，而是想把它变成长期工作流，问题马上就来了：
- token 花销高
- 每次都重复喂同一批旧文章
- 模型注意力被旧材料稀释
- 写稿和风格维护缠在一起，谁都不轻
也就是从这里开始，我慢慢意识到，blog-writer 更适合当消费侧，而不是把所有事情都塞给它做。
写稿这个动作，应该尽量轻，尽量直接，尽量只读生效版本。至于风格数据怎么生成、怎么筛、怎么压缩，那是另一条生产侧流水线的事。这个判断，最后才把我推到了下一步，也就是 AI 写博客这件事，后来还是得做成工程（二）：blog-style-suite 怎么把风格学习和 token 成本拆开。
先把流程做稳，后面才有资格谈风格和模型
现在回头看，blog-writer 长出来，不是因为我忽然很想做一个博客写作助手。
更像是因为原来那套流程已经开始不配合新的工作方式了。
Codex 这种工具一旦能联网补资料、能在仓库里读写、能直接调用脚本，写博客这件事就不该再停在“复制正文到本地文档”那一步。你不把这部分自动化，它反而会变成整条链路里最笨的一环。
所以第一篇的结论我就放这。
blog-writer 先解决的，不是文风，而是发布动作的重复劳动。没有这层契约，后面谈 token、谈数据结构、谈本地模型，其实都站不住。
参考资料
- 仓库提交：
991536a237d04aba7c44dec501b3d98c644040c8 - 仓库提交：
8eb735aa8448c97deb2af1ea46b86772008fa9e3 - 仓库提交：
1a5604e7e6ce0a13f260fcbb8c2c1d964cdd0892 - 仓库提交：
04dccb98c55a6ea3b81408012b33a6219cf8ab77 - 仓库文件：
.agents/skills/blog-writer/SKILL.md - 仓库文件：
.agents/skills/blog-writer/scripts/write_post.py - 仓库文件：
.agents/skills/blog-writer/scripts/write_post_series.py
写作附记
原始提示词
$blog-writer 本次的内容比较多，拆分成系列文章：去年就有很多稿子是通过大模型写的，那会是自己写个大纲或者问题清单，然后AI出稿子，复制内容到本地 md 文档，填写头信息，标签信息、发布文章；近期 codex 用了很多，发现 codex 里面的联网搜索能力很强，那我是不是能写个 skill，将这些事情自动化，此时诞生了 skill blog-writer 的第一稿，我还想着让 AI 学习我以前文章的风格，这就导致 blog-writer 运行的时候，很费 token，后续我针对 blog-writer 进行了多个版本的优化，拆分了 数据模块，数据生成的模块，原本数据生成的模块还是独立的 skill，写着写着，我就发现，更适合做成 Python 项目，此时就有了 blog-style-suite，然后我又发现，训练风格数据，也是比较费 token，我就想着用本地的大模型，对接了本地的大模型，我又想到了对比下本地大模型和在线版本的区别，又对接了 minimax；blog-style-suite 和 blog-writer 的演化历史可以分析的 git 提价记录。顺带基于本地 blog-writer、blog-style-suite 的代码，可以讲讲里面的设计思路，是如何做到了节约 token，数据结构是如何设计的，核心的设计思路。Token 富裕完全能生吃历史文章，预处理能节约很多 token
写作思路摘要
- 第一篇先收在工作流触发点，不急着展开 token 和模型分工，避免三篇一起抢主线。
- 重点保留了“正文不难，麻烦的是发布前后那串机械动作”这个判断。
- 通过
991536a、8eb735a、1a5604e、04dccb9这些节点，把“流程契约化”落到真实 git 演化上。 - 系列模式放在这一篇讲，是为了说明博客写作已经从单篇生成走到了整组落盘。
- 结尾故意把问题引到 token 墙，为第二篇的数据工程和预处理做铺垫。