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