这组文章到这里，前两篇已经把边界铺开了。第一篇 讲的是 blog-writer 为什么会长出来，第二篇 讲的是 blog-style-suite 怎么把风格学习和 token 成本拆开。最后这一篇，就收在最现实的问题上：本地模型、在线模型、Minimax，到底该放在哪个工位上。
训练风格数据，不值得每一步都烧在线模型
风格数据这件事，一旦开始认真做，token 很快就会变成现实问题。
不是你想不想省，而是你如果不分工，这套东西根本跑不久。
以前最容易出现的误区，就是让一个在线模型把所有活都包了。
- 扫历史文章
- 做筛选
- 做归类
- 评分
- 抽样本
- 压风格
- 最后再去写稿
这么干的最大问题，不是“模型不够强”，而是每一步都在烧同一档成本。
现在回头看，真正合理的做法应该是反过来想：哪些步骤必须在线，哪些步骤其实应该尽量本地化，哪些步骤甚至根本不该交给模型。
只要这个边界不清楚，再强的模型进来，最后也只是在帮你重复做一堆本来能预处理掉的活。
本地模型更适合脏活、重活和反复试错
我现在越来越愿意把本地模型定义成生产侧的体力层。
它不一定最强，也不一定每次都最漂亮，但它特别适合承担这些事情：
- 反复试跑的构建
- 风格数据的多轮压缩实验
- 配置改动后的重新扫描
- 对已有结构做低风险重算
这类活的共同点很明显。
不是单次价值极高，而是要反复跑、能容忍试错、并且最好别每一轮都重新付高价。
当前 scripts/blog-style-suite/config.json 已经切到了 lm-studio-gemma4，这本身就说明判断在变。不是说本地 gemma 一定比在线模型更强，而是生产侧这条链路，终于开始优先考虑“跑得起、跑得勤、能反复改”。
这一点，其实和我前面写过的 弱模型别硬上强活 是同一个逻辑。
本地模型不一定适合总包复杂写稿，但很适合接那些脏活、重活、批量活。风格数据的预处理，本来就更像这一类任务。
在线模型更适合收口，不适合包办一切
说本地模型适合生产侧，不等于在线模型就没价值了。
在线模型真正值钱的地方，恰恰是最后那一下收口。
比如：
- 根据最新资料补事实
- 在更大上下文里整理论证
- 处理需要联网核验的时间敏感信息
- 把已经准备好的结构化风格资产，转成一篇能发出来的文章
这些动作对表达质量、事实整合、上下文理解要求更高，在线模型放在这里更值。
也就是说，强模型更像总装线最后那几道工序。它不是不可以往前多干点，但如果你让它从头扫到尾，整个成本结构很快就会走形。
这也是为什么 blog-writer 在设计上只读发布位 published.runtime.json，而不是写稿时再去切 provider、再去回扫 suite 目录。消费侧越轻，越适合让更强的模型专心把文章收好。
Minimax 的意义，不只是多接了一个 provider
很多人看到 Minimax，第一反应可能是：无非又多接了一个模型。
我觉得不是。
Minimax 真正有价值的地方，是它把“多 provider 输出，同一发布契约消费”这条路走通了。
2026 年 4 月 2 日 10:18 的 9f15199 把 blog-style-suite 改成了多模型配置，输出按 provider 隔离。后面 README 和 runtime 结构也一直在强调一件事：suite 可以生成很多份结果，但真正生效的只有人工挑出来的 published.runtime.json。
这个边界特别重要。
因为一旦边界明确了，Minimax 的角色就不再是“必须绑定在写稿流程里”，而变成了：
- 它可以参与生产侧的对比
- 可以用来生成一版 runtime
- 可以和本地模型产物横向比较
- 最后由人工决定哪一版发布
这就把 provider 从“系统依赖”变成了“可替换部件”。
我觉得这是 Minimax 在这套工程里最有意思的意义。它不是来统治整条链路的，它是来验证这条链路到底有没有把接口收干净。
真正的分工，不是按模型强弱分，是按任务类型分
我现在更认同一种很土，但很管用的划分法。
规则和硬约束
交给本地脚本。
能用 scanner.py、write_post.py、write_post_series.py 这种确定性工具解决的，就别让模型掺和。
风格数据生产
优先交给本地模型或成本更低的 provider。
因为这里最重要的是可重复、可试错、可缓存，不是单次输出必须最华丽。
最终写稿和事实收口
交给更适合长上下文整合、表达收束、联网补事实的模型。
这一层才是在线模型最值得花钱的地方。
这么一拆，很多原来纠结的问题反而没那么复杂了。你不需要每天争论“到底哪个模型最强”，你只需要问一句：这个任务属于哪一层。
到最后，最值钱的不是模型，而是边界清楚
第三篇我就收在这里。
blog-writer 和 blog-style-suite 这套东西一路演化下来，我觉得最值钱的，不是又接了谁、又换了谁、又试了哪个 provider。
最值钱的是边界终于越来越清楚了。
blog-writer管消费侧blog-style-suite管生产侧published.runtime.json是发布位- 本地模型更适合反复跑的脏活和重活
- 在线模型更适合最后的收口
Minimax这类在线 provider 更像可替换部件，而不是系统中枢
边界一清楚，整个工作流就顺了。
你不会再指望一个模型包打天下，也不会再把每一步都堆到最贵那一层去做。到最后，这件事看起来是在选模型，实际上是在给不同类型的任务安排工位。
说白了，单点更强当然好。
但长期跑下来，边界清楚，往往比单点更强更重要。
参考资料
- 仓库提交：
9f1519967981c5eef7bd1eb407b0406ac542ebd0 - 仓库提交：
5f17088391ee858b88fc50df884bc0103ff0b3c1 - 仓库文件：
scripts/blog-style-suite/config.json - 生效运行时：
.agents/data/blog-writing/published.runtime.json - 相关旧文：重度AI编程的一段日子
- 相关旧文：终归还是回到国产模型
- 相关旧文：弱模型别硬上强活
写作附记
原始提示词
$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
写作思路摘要
- 第三篇不再重复讲架构，而是把“模型分工”这个现实问题单独收口。
- 直接用当前仓库里
published.runtime.json还是minimax-m2、config.json已切到本地gemma4这个事实开篇，减少空话。 - 重点不是证明谁更强，而是说明为什么不同任务该由不同成本层来承担。
- 把
Minimax放在“可替换 provider”这个位置上讲，是为了把它的意义拉回工程边界，而不是模型榜单。 - 结尾回到“边界清楚比单点更强更重要”这个总判断，作为整组文章的收口。