Blog-Style-Suite on Uncle Xiang's Notebook

Writing an AI blog post, in the end, still needs to be turned into engineering (Part 3)

Fri, 03 Apr 2026 21:06:02 +0800

After going through all the configurations in the repository, I am even more certain about one thing: what matters in the end is not how strong any single model is, but rather who should bear the cost at each layer.

The most obvious signal is that the currently active published.runtime.json is still the one generated on April 2, 2026, for minimax-m2, yet the entry from April 3, 2026, at 16:38, labeled 5f17088, has switched the default provider for blog-style-suite to the local gemma-4-26b-a4b in LM Studio. This might look inconsistent, but it actually isn’t; it precisely illustrates that this pipeline has begun to specialize.

With these articles, the first two have laid out the boundaries. The first article discusses why blog-writer emerged, and the second article discusses how blog-style-suite separates style learning from token costs. This final article settles on the most practical question: where should local models, online models, and Minimax ultimately be placed?

Training Style Data, Not Worth Burning Online Models at Every Step

The issue of style data, once you start taking it seriously, quickly becomes a practical problem with tokens. It’s not about whether you want to save costs; if you don’t divide the labor, this whole setup won’t run for long. The most common mistake in the past was letting one online model handle everything.

Scraping historical articles
Performing filtering
Doing categorization
Scoring
Sampling
Enforcing style
Finally writing the draft The biggest problem with doing it this way isn’t that “the model isn’t strong enough,” but rather that every step burns the same level of cost. Looking back now, the truly reasonable approach should be to think in reverse: which steps must be online, which steps should ideally be localized, and which steps shouldn’t even be given to a model at all. As long as this boundary isn’t clear, no matter how powerful the model is, it will just end up helping you repeat a bunch of tasks that could have been pre-processed away.

Local Models are Better Suited for Dirty, Heavy, and Iterative Tasks

I am increasingly inclined to define local models as the “physical layer” for production use. They might not be the strongest, nor perfect every time, but they are particularly suited for tasks such as:

Building through repeated runs/iterations
Multi-round compression experiments on style data
Re-scanning after configuration changes
Low-risk recalculation on existing structures

These types of tasks share a clear commonality. The value isn’t in a single, extremely high-value output, but rather in the ability to run repeatedly, tolerate errors, and ideally avoid paying high costs every single round. Currently, scripts/blog-style-suite/config.json has switched to lm-studio-gemma4, which itself indicates a shift in judgment. It’s not that local gemma is necessarily stronger than online models, but for the production pipeline, we are finally starting to prioritize “runnability, frequency of use, and ability to iterate/modify repeatedly.” This point actually aligns with the logic I wrote previously in Don’t force strong tasks onto weak models. Local models might not be suitable for writing complex, comprehensive articles from scratch, but they are excellent for handling dirty, heavy, and batch processing tasks. Preprocessing style data is inherently more like this category of task.

Online models are better suited for the final polish, not for doing everything from scratch

Just because local models are suitable for the production side doesn’t mean online models have no value. The real value of an online model lies precisely in that final polishing touch. For example:

Supplementing facts based on the latest information
Structuring arguments within a larger context
Handling time-sensitive information that requires internet verification
Transforming already prepared structured style assets into a publishable article These tasks require higher demands on expression quality, factual integration, and contextual understanding, making online models more valuable here. In other words, the powerful model is more like the final few assembly line steps. It’s not that it can’t do more upfront work, but if you make it scan from beginning to end, the entire cost structure will quickly become distorted. This is also why blog-writer is designed to only read from the published location published.runtime.json, rather than having to switch providers or re-scan the suite directory while drafting. The lighter the consumption side, the better it is for a more powerful model to focus on finalizing the article.

The Significance of Minimax: It’s Not Just Another Provider Connection

Many people who see Minimax might first think: “It’s just another model being connected.”

I don’t think so.

The truly valuable aspect of Minimax is that it has successfully paved the way for “multiple provider outputs consumed by a single publishing contract.”

The change on April 2, 2026, at 10:18 (9f15199) modified blog-style-suite to support multi-model configurations, with outputs isolated per provider. Subsequently, the README and runtime structure have consistently emphasized one thing: while the suite can generate many sets of results, only the manually selected published.runtime.json is actually effective.

This boundary is extremely important.

Because once this boundary is clear, the role of Minimax changes from being “something that must be bound within the drafting process” to becoming:

Something that can participate in production-side comparisons.
Something that can be used to generate a runtime version.
Something that can be compared horizontally with local model artifacts.
Finally, something whose publication is decided by human judgment.

This transforms the provider from a “system dependency” into a “replaceable component.”

I believe this is the most interesting significance of Minimax within this engineering setup. It isn’t here to dominate the entire pipeline; it’s here to validate whether this pipeline has successfully cleaned up its interfaces.

True specialization is not based on model strength, but on task type

I now favor a classification method that is quite rudimentary, but very effective.

Rules and Hard Constraints

Leave to local scripts. If it can be solved with deterministic tools like scanner.py, write_post.py, or write_post_series.py, don’t let the model get involved.

Style Data Generation

Prioritize local models or lower-cost providers. Because what is most important here is reproducibility, room for iteration/error, and cacheability, not necessarily the most dazzling single output.

Final Drafting and Fact Consolidation

Hand this off to a model better suited for long-context integration, expression consolidation, and fact-checking/web retrieval. This layer is where spending money on online models is most worthwhile. When broken down like this, many previously confusing issues are actually not that complex. You don’t need to argue every day about “which model is the strongest”; you just need to ask: which layer does this task belong to?

Ultimately, what is most valuable is not the model, but the clear boundaries.

This concludes my third article. As blog-writer and blog-style-suite have evolved, I feel that what is most valuable is not which provider we connected next, or who we replaced, or which one we tested. What is most valuable is that the boundaries are finally becoming clearer.

blog-writer handles the consumption side.
blog-style-suite handles the production side.
published.runtime.json is the publishing point.
Local models are better suited for dirty and heavy lifting that needs to be run repeatedly.
Online models are better suited for the final polish/wrap-up.
Online providers like Minimax feel more like replaceable components rather than the central hub of the system. Once the boundaries are clear, the entire workflow flows smoothly. You won’t expect one model package to conquer everything, nor will you stack every step onto the most expensive layer. In the end, while it looks like selecting a model, what we are actually doing is assigning workstations for different types of tasks. Simply put, having a single strong point is certainly good. But in the long run, clear boundaries are often more important and stronger than any single point solution.

References

Repository Commit: 9f1519967981c5eef7bd1eb407b0406ac542ebd0
Repository Commit: 5f17088391ee858b88fc50df884bc0103ff0b3c1
Repository File: scripts/blog-style-suite/config.json
Effective Runtime: .agents/data/blog-writing/published.runtime.json
Related Old Article: A Period of Heavy AI Programming
Related Old Article: Ultimately Returning to Domestic Models
Related Old Article: Don’t Force Strong Tasks with Weak Models

Writing Notes

Original Prompt

$blog-writer This content is quite extensive, so I've split it into a series of articles: Last year, many drafts were written using large models. Back then, the process was to create an outline or a list of questions myself, and then have the AI generate the draft, copy the content into a local md document, fill in header information, tag information, and publish the article; recently, I used Codex a lot and found that its web search capability is very strong. So, could I write a skill to automate these tasks? This led to the first draft of the skill blog-writer. I also thought about having the AI learn my previous writing style, which caused blog-writer to consume a lot of tokens when running. Subsequently, I optimized blog-writer in several versions, splitting out the data module and the data generation module. The original data generation module was still an independent skill. As I continued writing, I realized that it would be better as a Python project, which led to blog-style-suite. Then, I found that training on style data also consumes a lot of tokens, so I wanted to use a local large model and connected to a local LLM. I then thought about comparing the differences between the local LLM and the online version, so I integrated minimax; the evolution history of blog-style-suite and blog-writer can be analyzed from the git commit history. Additionally, based on the code for local blog-writer and blog-style-suite, I can discuss the design ideas, how token saving was achieved, and how the data structure was designed—the core design concepts. If tokens are abundant, it can consume entire historical articles; preprocessing can save a lot of tokens.

Writing Strategy Summary

The third article will no longer repeat the discussion on architecture, but instead focus solely on the practical issue of “model specialization/division of labor.”
Start directly by stating the current reality—whether to use published.runtime.json from the current repository or if it’s switched locally to gemma4 via minimax-m2 or config.json—to reduce filler content.
The focus should not be on proving which model is stronger, but rather on explaining why different tasks should be assigned to different cost layers.
Placing Minimax in the “replaceable provider” section aims to pull its significance back into the engineering boundary, rather than treating it as just another entry on a model leaderboard.
Conclude by returning to the overarching judgment: “Clear boundaries are more important than single points of strength,” serving as the closing statement for the entire series of articles.

Making the "AI writes blog" thing into an engineering project later (Part II)

Fri, 03 Apr 2026 21:02:02 +0800

If there are enough tokens, the least effort method is actually quite crude: just feed the model historical articles and let it learn on its own. The problem with this method is that it only suits occasional writing, not continuous work. If you treat blogging as a long-term workflow, relying solely on raw historical articles will quickly go from “simple and direct” to “expensive and messy.”

With these articles, the main thread has shifted. The previous article, AI Writing Blogs: It Eventually Needs to Become an Engineering Process (Part 1): Why a blog-writer is inevitable, discussed automation on the consumption side. This article starts discussing the production side—how to generate style data, how to compress it, and how not to waste tokens; the next article will continue this in AI Writing Blogs: It Eventually Needs to Become an Engineering Process (Part 3): Local Models, Online Models, and Minimax—How They Finally Divide Labor.

The most natural initial thought is to just feed it historical articles.

This path feels too natural. If you want the model to learn your writing style, the most intuitive way is certainly to feed it old articles. It’s best to include all the posts from your history that are most like your own, and let it summarize them itself. For a single task, this approach has no flaws. In fact, many times the results are quite good. If the context is long enough, the model is powerful enough, and there are enough historical articles, the style can indeed be captured. But the problem isn’t “can it write this one article,” the problem is “for the next one, the one after that, do we have to repeat this process?” Feeding a new batch of old articles every time brings several very practical side effects:

The same batch of material repeatedly occupies the context window.
Token overhead grows almost linearly with the number of drafts written.
The model sees more and more noise, causing genuinely useful signals to become diluted.
The drafting action and style maintenance action become completely bound together; neither can be easily reduced. In other words, when tokens are abundant, eating it raw certainly works. But from an engineering perspective, we cannot keep doing that forever.

This is also why the data module and the data generation module must be separated

I later realized that the core idea can be summarized in one sentence: separating the consumption side from the production side.

blog-writer is responsible for the consumption side. It only reads an already published runtime and then writes out the article according to a fixed contract.

Meanwhile, scanning, filtering, scoring, compressing style data, and provider comparison—all of this should be placed in another production pipeline. This is what later became blog-style-suite.

Looking at the git history, this turning point is very clear.

The commit 84a06b5 on April 1, 2026, at 21:47 clearly replaced the original blog-style-maintainer skill with a repository-level CLI tool. This action speaks volumes because once you have scan/build/rebuild, an output directory, and a recovery mechanism, it’s no longer like a simple skill; it’s more like a normal Python project.

By the commit 9e92b8e on April 1, 2026, at 23:05, blog-style-suite was further broken down into modules like scanner.py, builder.py, and compressor.py. By this stage, the thinking process was already highly engineered:

scanner.py is responsible for scanning articles from disk and extracting structured features.
builder.py is responsible for scoring, selecting, caching, and runtime assembly.
compressor.py is responsible for the compression steps that involve the model.

This represents a completely different approach compared to simply writing a super prompt.

Saving Tokens: Not by Magic, But by Preprocessing and Batching

The most valuable part of this entire engineering setup, I think, is the commit bc4b950 from April 2, 2026, at 19:41. That commit was very direct: it reduced AI calls from about 2000 times down to a maximum of 5 times per provider. How was this achieved? It wasn’t by “making the prompt smarter,” but by doing the necessary preprocessing beforehand. The current flow in blog-style-suite is very clear:

The scan stage is purely heuristic, requiring 0 AI calls.
The build stage first performs heuristic scoring, also requiring 0 AI calls.
Then, it performs one batch selection and labeling for each of the four lanes: technical / finance / essay / tooling.
Finally, there is one author style compression step. Counting this up, the cold start requires at most 5 calls. More critically, these 5 calls are not spread across every single article; they are concentrated on high-value summary materials that have already been preprocessed. This is where preprocessing truly saves tokens. It’s not about saving a few words; it’s about changing the process from “calling per article” to “batch calling by stage.” Furthermore, caching has been implemented. In builder.py, there are lane batch fingerprints, provider checkpoint recovery, and contractions like review_pool_per_lane = 12 for local model context. If you change a small amount of data, the entire pipeline doesn’t need to rerun. These kinds of designs might not look flashy, but every single one is highly practical because they solve the problem of “don’t let the same batch of tokens burn twice.”

Essentially, this data structure is compressing the truly useful signal.

Once this is broken down, the data structure will be smooth. I am now more willing to understand it as three layers.

Layer One: `scan.json`

This is the shared raw material. It contains structured signals such as article path, title, date, category, tags, opening paragraph, closing stub, headings, screening results, and lane classification. It is not directly consumed by blog-writer; rather, it is passed to the production side for further processing.

Second Layer: `{provider}.source.json`

This is the provider-level checkpoint. Building upon the shared raw materials, it includes intermediate states such as scoring results, lane selection, fingerprint, and cache status. In other words, it is more like a “semi-finished product during processing,” with an emphasis on being recoverable, reusable, and resumable.

Layer Three: `{provider}.runtime.json` and `published.runtime.json`

This is what the consumption side truly cares about—the finished product. It retains:

author_style
lanes
samples
writer_guide In essence, it compresses a large collection of historical articles into one ready-to-consume runtime style asset. The published.runtime.json in particular is crucial for the publishing stage. The blog-writer only reads this file and does not need to scan content/post, nor does it need to care about the complete images of all providers in the suite directory. Once this boundary is established, the consumption side becomes much lighter. The writing model no longer sees a pile of raw old articles, but rather a pre-processed, high-density signal.

Not Everything Should Be Left to the Model

I’m increasingly feeling that the most correct judgment in this entire engineering process isn’t “add more models,” but rather “don’t throw tasks that shouldn’t be done by a model onto it.” Things like these are much better handled by local rules first:

Frontmatter parsing
Extracting introductory paragraphs
Headings extraction
Determining author/repost/model attribution
Detecting blockquote ratios
Hard rule filtering for things like , embedded prompts, and body length. Having the model do these tasks isn’t impossible, but it’s wasteful. What models are better suited for are parts that involve ambiguity or trade-offs. For example, which few articles in a lane best represent the current sentiment, or extracting author style tags from high-scoring articles. Therefore, what makes blog-style-suite truly valuable isn’t just “saving tokens,” but rather its re-division of labor among humans, rules, and models—assigning each party the tasks they are best suited for.

Preprocessing isn’t about saving a few tokens; it’s about making the act of writing sustainable.

For the conclusion in the second article, I want to make it more direct.

When you have plenty of tokens, reading historical articles raw is fine. In fact, if you only write one or two pieces, it might even be less mentally taxing.

But as soon as you want to turn this into a long-term workflow, preprocessing becomes non-negotiable. Because without preprocessing, the writing model has to re-read old materials every time, and style maintenance and article generation are always mixed together.

The significance of blog-style-suite is to untangle this mess.

It’s not about making the system look complex, nor is it just for another project name; it’s so that blog-writer can remain lightweight, stable, and focused on “only the action of writing.”

Having reached this point, the next question naturally follows.

Since the production side has been separated, what model should bear this cost? Local models, online models, or Minimax—where should each one stand in the workflow? I’ll save this for the next article: AI Writing Blogs: How It Eventually Has to Become Engineering (Part 3): The Division of Labor Between Local Models, Online Models, and Minimax.

References

Repository Commit: 84a06b5dc743f2e9bc6e788d53496a1261bc63ae
Repository Commit: 9e92b8e6a15d03e6392aff7f3b2dcb0992fe5043
Repository Commit: bc4b950cbb13e37d1fdb16a9d23325cfefa6f90e
Repository File: scripts/blog-style-suite/README.md
Repository File: scripts/blog-style-suite/style_pipeline/scanner.py
Repository File: scripts/blog-style-suite/style_pipeline/builder.py
Repository File: scripts/blog-style-suite/style_pipeline/compressor.py
Effective Runtime: .agents/data/blog-writing/published.runtime.json

Writing Notes

Original Prompt

$blog-writer This content is quite extensive, so I've split it into a series of articles: Last year, many drafts were written using large models. Back then, the process was to create an outline or a list of questions myself, and then have the AI generate the draft, copy the content into a local md document, fill in header information, tag information, and publish the article; recently, I used Codex a lot and found that its web search capability is very strong. So, could I write a skill to automate these tasks? This led to the first draft of the skill blog-writer. I also thought about having the AI learn my previous writing style, which caused blog-writer to consume a lot of tokens when running. Subsequently, I optimized blog-writer in several versions, splitting out the data module and the data generation module. The original data generation module was still an independent skill. As I continued writing, I realized that it would be better as a Python project, which led to blog-style-suite. Then, I found that training on style data also consumes a lot of tokens, so I wanted to use a local large model and connected to a local LLM. I then thought about comparing the differences between the local LLM and the online version, so I integrated minimax; the evolution history of blog-style-suite and blog-writer can be analyzed from the git commit history. Additionally, based on the code for local blog-writer and blog-style-suite, I can discuss the design ideas, how token saving was achieved, and how the data structure was designed—the core design concepts. If tokens are abundant, it can consume entire historical articles; preprocessing can save a lot of tokens.

Writing Outline Summary

This article shifts the focus from the act of writing drafts to data engineering, with the core answer being “why modularization is necessary.”
The introduction directly acknowledges that “using raw historical articles works,” which makes the subsequent arguments for splitting more convincing.
It elaborates on the three structural layers: scan.json, source.json, and runtime.json, avoiding vague architectural discussions.
bc4b950 is placed in the middle as a turning point because “reducing from about 2000 times to 5 times” best illustrates the value of preprocessing.
The conclusion re-separates the consumption side and the production side, setting the stage for model division in the third article.

Blog-Style-Suite on Uncle Xiang's Notebook

Writing an AI blog post, in the end, still needs to be turned into engineering (Part 3)

Training Style Data, Not Worth Burning Online Models at Every Step

Local Models are Better Suited for Dirty, Heavy, and Iterative Tasks

Online models are better suited for the final polish, not for doing everything from scratch

The Significance of Minimax: It’s Not Just Another Provider Connection

True specialization is not based on model strength, but on task type

Rules and Hard Constraints

Style Data Generation

Final Drafting and Fact Consolidation

Ultimately, what is most valuable is not the model, but the clear boundaries.

References

Writing Notes

Original Prompt

Writing Strategy Summary

Making the "AI writes blog" thing into an engineering project later (Part II)

The most natural initial thought is to just feed it historical articles.

This is also why the data module and the data generation module must be separated

Saving Tokens: Not by Magic, But by Preprocessing and Batching

Essentially, this data structure is compressing the truly useful signal.

Layer One: scan.json

Second Layer: {provider}.source.json

Layer Three: {provider}.runtime.json and published.runtime.json

Not Everything Should Be Left to the Model

Preprocessing isn’t about saving a few tokens; it’s about making the act of writing sustainable.

References

Writing Notes

Original Prompt

Writing Outline Summary

Layer One: `scan.json`

Second Layer: `{provider}.source.json`

Layer Three: `{provider}.runtime.json` and `published.runtime.json`