Workflow on Uncle Xiang's Notebook

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.

AI Writing a Blog: The Next Steps Towards Engineering (Part 1)

Fri, 03 Apr 2026 20:58:02 +0800

I wrote quite a few AI articles last year. The most basic workflow back then was: first, organize an outline or a list of questions myself; let the large model spit out the main body text; then copy the content into a local md document, add frontmatter, tags, categories, and titles, and finally publish it. This process isn’t unusable, but it’s tedious. The part that really wastes time isn’t the main body text, but the repetitive labor surrounding it. Especially after using Codex a lot recently, this awkwardness has become even stronger. It can read repositories, modify files, supplement materials, and even write articles directly into the directory. If I still have to copy and paste things manually, it feels like I’m tying down the tool’s legs.

This series of articles is actually trying to convey one thing: AI writing blogs cannot rely solely on a single prompt in the long run. This current article first discusses why blog-writer came into existence; the next article will continue with AI Writing Blogs: Later, It Still Needs to Be Engineered (Part II): How blog-style-suite Separates Style Learning and Token Costs; and the last article concludes with AI Writing Blogs: Later, It Still Needs to Be Engineered (Part III): How Local Models, Online Models, and Minimax Will Finally Divide Labor.

What’s truly annoying isn’t writing the draft, but that sequence of mechanical actions.

The early workflow was essentially like an outsourced assembly line. I would first list out the problems clearly, or build a rough outline. The model is responsible for laying out the main body text. Then, a human comes back to complete the remaining publishing steps.

Copy to local md file
Fill in title, date, and slug
Add tags and categories
Insert 
Organize reference materials
Finally, decide which directory it should go into Looking at each step individually, this sequence isn’t difficult. But when strung together, it becomes tedious. What’s annoying isn’t the technical difficulty; it’s that these steps are all mechanical, yet they cannot be skipped. This is why I increasingly feel that changes like AI coding interaction based on command line are not just about “changing the entry point.” When AI can directly read and write files within a repository, if blog writing still stops at the level of “copying the body text to a local document,” the entire workflow is actually outdated.

blog-writer The First Layer of Value: It’s Not the Style, It’s Locking Down the Contract

The very first node for blog-writer was at 17:00 on April 1, 2026, with the commit hash 991536a. Looking at the git commit history, this version included SKILL.md, write_post.py, and an initial set of style guidelines all together.

However, when I looked back later, the most valuable part of this draft wasn’t that “the AI learned my writing style,” but rather that it established a rigid contract for content creation.

What does “locking down the contract” mean?

The input must include at least an outline and factual anchors.
The output must be complete Markdown, not a work in progress.
Frontmatter cannot rely on manual additions anymore.
The article cannot just stay in the chat window; it must land directly into content/post.

This point is crucial because prompts themselves are inherently unstable. If you say, “Write it like before,” today, it might understand that only the tone should be similar; if you repeat it tomorrow, it might only learn superficial sentence structures. But once it’s written as a Skill, the rule shifts from “improvisation” to a “fixed workflow.”

The subsequent nodes were actually all about reinforcing this contract.

The commit at 22:54 on April 2, 2026, with hash 8eb735a, standardized elements like author fields, writing notes, and original prompts. By this stage, the blog draft was no longer considered “finished once the body text is done”; instead, metadata, traceability, and public notes were all standardized together.

Therefore, the first layer of value for blog-writer has never been about making the model seem better at writing; it’s about finally giving the act of drafting repeatable boundaries.

Series Mode, Which is Actually One Step Forward in Writing Workflow

After stabilizing writing a single article, the next problem quickly emerged. Some topics are simply not suitable to be crammed into one piece. If you force it, the result often becomes a long article that is information-heavy, has a scattered main thread, and fails to fully explain every point. This is why the commit 1a5604e on April 2, 2026, at 23:55 was so crucial. That time, they directly added the series mode along with write_post_series.py. The articles are linked using relref, and the replacement is done uniformly during batch writing. This might look like a minor upgrade to a file-writing script, but it’s not. It illustrates one thing: content engineering is no longer just about “how to generate this single article,” but rather starts considering “how to stably save this set of content, how to guarantee the order, and how to link between them on the site.” The next day’s commit, 04dccb9 on April 3, 2026, at 09:29, pushed this process one step further. The timestamps for series articles now increment by minutes instead of sharing a single timestamp. This change is small but very “engineering-y” because it solves real problems like Hugo list pages, previous/next article navigation, and series ordering. Simply put, the series mode isn’t about looking advanced; it’s about eliminating the need for manual fixes when publishing multiple articles together.

But relying on just one skill will eventually hit a token wall.

The problem lies here. Once you start seriously tinkering with style learning, the context of blog-writer will quickly become bloated. You not only want it to write, but you also want it to write like you used to. The most natural way to do this is to dump all your historical articles into it. This works for a single run, of course. But as soon as you’re not writing an occasional piece, but trying to make it a long-term workflow, the problems immediately arise:

High token consumption
Repeatedly feeding the same batch of old articles every time
Model attention is diluted by old material
Drafting and style maintenance are intertwined; neither is easy.

It was from here that I slowly realized that blog-writer is better suited for the consumption side, rather than trying to feed it everything. The act of drafting should be as light, direct, and limited to reading only the effective versions as possible. As for how to generate, filter, or compress style data, that’s a matter for a separate production pipeline. This realization finally pushed me to the next step, which was AI Blog Writing: It Still Needs to Be Engineered (Part II): How blog-style-suite Separates Style Learning from Token Costs.

First, stabilize the process; only then can we talk about style and models.

Looking back now, blog-writer didn’t emerge because I suddenly wanted to build a blog writing assistant. It was more because the original workflow started failing to keep up with new ways of working. Once a tool like Codex can connect to the internet for supplementary material, read and write within repositories, and directly call scripts, the act of writing a blog shouldn’t stop at “copying the body text to a local document.” If you don’t automate this part, it will actually become the clumsiest link in the entire chain. So, I’ll leave the conclusion for the first post here. What blog-writer solved initially wasn’t writing style, but the repetitive labor of the publishing action. Without this layer of contract, any subsequent discussion about tokens, data structures, or local models is actually baseless.

References

Repository Commit: 991536a237d04aba7c44dec501b3d98c644040c8
Repository Commit: 8eb735aa8448c97deb2af1ea46b86772008fa9e3
Repository Commit: 1a5604e7e6ce0a13f260fcbb8c2c1d964cdd0892
Repository Commit: 04dccb98c55a6ea3b81408012b33a6219cf8ab77
Repository File: .agents/skills/blog-writer/SKILL.md
Repository File: .agents/skills/blog-writer/scripts/write_post.py
Repository File: .agents/skills/blog-writer/scripts/write_post_series.py

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 one locally. I then thought about comparing the differences between the local large model 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 first article should focus on the workflow trigger point, without rushing to detail the division of labor between tokens and models, to avoid having all three articles compete for the main narrative.
It retains the key insight: “The body content is not difficult; what’s troublesome are the mechanical actions before and after publishing.”
By using nodes like 991536a, 8eb735a, 1a5604e, and 04dccb9, we ground the concept of “process contracturization” in actual Git evolution.
The series pattern is reserved for this article to illustrate that blog writing has moved from generating single pieces to managing entire sets of deliverables.
The ending deliberately points toward the token wall, setting up the groundwork for data engineering and preprocessing in the second article.

After reviewing AI articles from the past two years, I think these are the 8 topics I should write about next.

Mon, 30 Mar 2026 22:20:00 +0800

I recently went back and reviewed the articles in my blog related to AI from the past two years, and I found that the content is no longer just simple experiences like “whether a certain model is good or not.” Instead, it has gradually formed a relatively clear main thread: How AI truly entered my development workflow, and what efficiency gains, costs, and new constraints it brought.

When I say “the past two years” here, looking forward from the current time, it roughly spans from 2024-03-30 to 2026-03-30. Upon actually reviewing them, a very noticeable phenomenon is that there were almost no articles with a truly significant AI theme in 2024; the intensive output only began around 2025-01. This fact itself is quite interesting. It shows that for me, AI didn’t enter a stable period of use right away; rather, it slowly permeated my work and writing, and only after I encountered suitable tools and task formats did continuous documentation begin to form.

The AI articles of the past two years can generally be divided into three stages

Phase One: Tool Exploration, Testing Usability First

Representative articles from this phase include:

“Trying out the Cursor AI Coding IDE”
“Locally Deploying deepseek-R1 with ollama”
“Designing and Developing a Stock Selection Module Without Writing Code”
“Two Years of AI Development: A State Similar to Before Docker’s Release” The core question in this phase is very simple: Can AI actually help me get things done? The focus at that time was more on the tool level:
Whether the IDE format is convenient to use.
Whether local deployment can actually run.
Whether code generated by the model saves time.
Whether AI gets stuck when encountering complex requirements. Looking back, the articles from this phase feel like paving the way for heavy usage later on. Many conclusions remain valid today, such as: AI can significantly boost basic development efficiency, but complex tasks still require manual decomposition; local models are good for experimentation, but stability and speed are key when integrating into high-frequency workflows.

Phase Two: Starting to Integrate into the Workflow, But Side Effects Appear Too

Representative articles from this phase include:

“Overusing AI, and Some Aftermath” (or “The Side Effects of Overusing AI”)
“Claude 4 Release: Attempting Development with Hugo Tags and Hyperlink Translation Assistants”
“Some Usage Experiences with Large Models Recently”
“ByteDance AI Coding New Paradigm SOLO”

By this point, AI is no longer just a “tool to occasionally try out,” but it has started to directly participate in:

Developing blog toolchains
Translation caching and batch processing pipelines
UI design and code iteration
Model specialization and scenario selection

At the same time, the problems becoming more specific. The previous question was, “Can AI write code?”, while the later questions became:

The code is written, but how do I validate it?
The article is generated, but does it lack a human touch/real-world flavor?
The documentation has been updated synchronously, but do I truly understand it myself?
The tools are getting stronger, but is the intensity of human thought decreasing?

This is what I find to be the most valuable part of this set of articles. Compared to empty talk about “AI being powerful,” these records that carry a slight sense of discomfort feel more authentic.

Phase Three: Moving from Single Tool Experience to Protocols, Workflows, Stability, and Cost

Representative articles for this phase include:

“AI Coding Interaction Based on Command Line”
“From Protocol Constraints to Intelligent Release: A Deep Comparison of MCP vs. Skill”
“A Period of Heavy AI Programming”
“The End Game of Low-Cost API Gateways: Large Model Experiences and the Impossible Triangle in March” By this stage, the focus has clearly upgraded. It is no longer about “which model answers more intelligently,” but rather:
Which is better for continuous development: terminal interaction or IDE integration?
What are the boundary differences between capability extension methods like MCP and Skill?
Where should human intervention occur during heavy AI programming?
How to make realistic choices among cost, stability, and quality. These topics are no longer simple product reviews; they are closer to workflow design. This is also the most stable and recognizable thread in AI topics on blogs right now.

The biggest advantage of this batch of articles is not chasing hot topics.

Looking back, what makes the existing AI articles on the blog truly distinctive is not writing about a certain model earlier than others, nor is it covering parameters, leaderboards, and benchmark scores more completely, but rather these points below:

1. All Originate from Real-World Scenarios

Whether it’s the stock selection module, the blog translation tool, command-line coding, or records of API relay station tinkering, almost none of these topics were conceived out of thin air; they were written after encountering problems during actual use. The advantage of this type of content is that it is not easily superficial.

2. Focuses on “How to integrate AI into the workflow”

Many AI articles only write about model capabilities, but this set of existing articles is more concerned with:

How to decompose tasks
How to integrate into projects
How to maintain documentation
How to control context
How to divide labor between different models The lifecycle for these types of content is usually longer than simple model evaluation.

3. Beginning to realize the side effects and costs

From “Too Much AI, Some Side Effects” to “The End of Low-Cost API Relays,” a very complete line of thought has actually formed:

AI can boost efficiency
But it changes people’s search and thinking habits
Cheap does not equal truly saving money
Quality, stability, and cost-effectiveness are hard to achieve simultaneously These judgments come from personal usage accumulation, not just repeating online opinions.

But there are also several obvious gaps in the content

Although the existing article has a main thread, if we continue writing, I feel there are still some noticeable gaps.

1. Lack of a Systematic “Acceptance Methodology”

Many articles have covered the AI programming experience, and they have mentioned unit testing, performance testing, and documentation synchronization, but there hasn’t been an article that thoroughly explains the entire process of “how to accept/validate what AI writes.”

2. Lack of Team Perspective

Currently, most focus on individual development and personal workflows. This perspective is good, but if we continue writing, it can be expanded to:

How to limit the scope of AI modifications during team collaboration
How to approach AI-generated code in code reviews
How documentation, commit logs, and test records should work together

3. Lack of Discussion on Security and Permission Boundaries

This trend has become increasingly obvious recently; AI is no longer just a chat box, but is taking over:

Terminal commands
Repository read/write access
Browser operations
Third-party tool calling The stronger the capability, the more valuable it is to define the permission boundaries.

4. Lack of “Long-term Knowledge Base” Direction

The article currently has basic capabilities like translation cache, slugs, and tags, but it hasn’t systematically addressed: If the blog itself is a personal knowledge base, how can it be organized into content assets that are more suitable for AI consumption, retrieval, and processing.

The 8 Topics I Think Are Best to Write About Next

I have ranked these 8 areas based on “best fit with current writing style” and “easiest to generate original content.”

1. How to Build an Acceptance System for AI Programming

This is the article I most recommend writing first. You can focus on the following points:

Which modifications must have unit tests added
Which modules must run regression tests
Which refactorings require performance comparison
Which documents should be maintained synchronously
What to focus on during manual review Once this article is written, it can be linked back to for many subsequent AI programming articles.

2. Where MCP is Truly Useful, It’s Not About Connecting More Things

MCP is getting increasingly popular, but most discussions are still at the conceptual level. What is more worth writing about is:

Which tool integrations genuinely boost efficiency
Which ones just look cool but aren’t actually necessary
Among local files, documents, issues, monitoring dashboards, and design mockups, which should be prioritized for integration?
What is the actual difference between protocolized integration and “stuffing in a large prompt”?

3. Cross-Comparison of Claude Code, Codex, Gemini CLI, and Domestic CLI Models in Practice

Instead of simply stating “which one is better,” the goal is to conduct a comparative evaluation using a unified set of tasks. For example, fixed comparisons on:

Requirement decomposition ability
Instruction following accuracy
Scope control for code modification
Ability to supplement tests
Documentation synchronization capability
Cost and waiting time This type of article is easiest for readers to reference directly.

4. Context Management in AI Programming

Often, the issue isn’t that the model is weak, but rather that the context has become dirty, too long, or drifted. This article could specifically cover:

When to clear the context
When a new thread should be started
When tasks should be broken down into smaller pieces
When multi-agent parallelization is appropriate
In what situations manual re-summarization of the current state is necessary This topic is very specific and easy to combine with one’s own real-life case studies.

5. From IDE to Terminal, and then to Multi-Agent Collaboration

Over the past year, the focus of AI programming interaction has clearly shifted. Previously, it was more about in-IDE completion, chat, and local code modification; now, more and more tools are emphasizing:

Terminal interaction
Repository-level understanding
Multi-threaded context
Parallel agents
Worktree isolation for development This topic is suitable for connecting past articles such as Cursor, Trae, Claude Code, and Codex.

6. The Security Surface of AI Programming is Expanding

This direction is very worth writing about, and it hasn’t been covered much yet. You can approach this from these angles:

Risks associated with automatically executing commands
Trust boundaries for third-party MCP services
Issues of private repository and sensitive information leakage
Prompt injection and malicious context contamination
The boundary between automated scripts and human confirmation If you only write that “AI is very capable,” the article will become repetitive; incorporating the security boundaries will make the content significantly higher in quality.

7. The True Place of Local Models

Previously, the focus was more on “Can the local model run?”, but now it is more valuable to ask:

What tasks is it suitable for?
What tasks is it not suitable for?
When do advantages like privacy, offline capability, and low cost truly materialize?
At what point does continuing to insist on a local solution actually become a waste of time? This has more follow-up value than just deployment tutorials.

8. How to Organize Blog Content into AI-Friendly Knowledge Assets

This direction integrates most closely with the existing blog system. You could write about:

How to uniformly design slugs, tags, abstracts, and categories
How to minimize link drift in multilingual content
How article metadata can aid subsequent retrieval
How to make historical articles more suitable for AI retrieval, summarization, and citation If this piece is written, it will be both an AI topic and one that can serve the entire blog system in return.

Trends to Watch in the Near Future

There have been several changes in the industry recently that will also influence future topic selection.

First, AI programming is increasingly moving from being a “completion tool” to an “agent workflow.” Products like Codex and Claude Code no longer emphasize single-turn answers; instead, they focus on task decomposition, tool calling, parallel processing, and continuous context maintenance.

Second, protocolized access methods, such as MCP, are transitioning from being “new concepts” to becoming infrastructure. In the future, truly valuable articles will not be those that re-explain protocol definitions, but rather those that clearly articulate: which integration scenarios are genuinely effective, and which ones just look advanced.

Third, the back-and-forth between design mockups, documents, code, and command lines is increasing. Previously, tools were siloed; now, AI is attempting to connect these links. This also means that “workflow design” will be more valuable for long-term writing than simply listing “model benchmarks.”

Fourth, stability, cost, and permission risks are not going away. On the contrary, the stronger the model’s capabilities become, the more critical these issues will be.

The Final Judgment

If I were to continue writing about AI, the one thing I feel we should stick to is not chasing every new model release for reviews, but rather focusing on a more specific question: How exactly does AI integrate into real development and writing workflows step-by-step? Where does it genuinely improve efficiency, and where does it push the problem back to humans? You have actually outlined this line; it just hasn’t fully materialized yet. The most appropriate next step is not to spread out the topics further, but rather to continue digging along these four sub-themes: “Practical Tools,” “Process Design,” “Boundary Control,” and “Long-term Knowledge Assets.” Content written this way will, over time, be easier to solidify into one’s own material, rather than just a collection of quickly outdated hot topics.

Workflow on Uncle Xiang's Notebook

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

AI Writing a Blog: The Next Steps Towards Engineering (Part 1)

What’s truly annoying isn’t writing the draft, but that sequence of mechanical actions.

blog-writer The First Layer of Value: It’s Not the Style, It’s Locking Down the Contract

Series Mode, Which is Actually One Step Forward in Writing Workflow

But relying on just one skill will eventually hit a token wall.

First, stabilize the process; only then can we talk about style and models.

References

Writing Notes

Original Prompt

Writing Strategy Summary

After reviewing AI articles from the past two years, I think these are the 8 topics I should write about next.

The AI articles of the past two years can generally be divided into three stages

Phase One: Tool Exploration, Testing Usability First

Phase Two: Starting to Integrate into the Workflow, But Side Effects Appear Too

Phase Three: Moving from Single Tool Experience to Protocols, Workflows, Stability, and Cost

The biggest advantage of this batch of articles is not chasing hot topics.

1. All Originate from Real-World Scenarios

2. Focuses on “How to integrate AI into the workflow”

3. Beginning to realize the side effects and costs

But there are also several obvious gaps in the content

1. Lack of a Systematic “Acceptance Methodology”

2. Lack of Team Perspective

3. Lack of Discussion on Security and Permission Boundaries

4. Lack of “Long-term Knowledge Base” Direction

The 8 Topics I Think Are Best to Write About Next

1. How to Build an Acceptance System for AI Programming

2. Where MCP is Truly Useful, It’s Not About Connecting More Things

3. Cross-Comparison of Claude Code, Codex, Gemini CLI, and Domestic CLI Models in Practice

4. Context Management in AI Programming

5. From IDE to Terminal, and then to Multi-Agent Collaboration

6. The Security Surface of AI Programming is Expanding

7. The True Place of Local Models

8. How to Organize Blog Content into AI-Friendly Knowledge Assets

Trends to Watch in the Near Future

The Final Judgment

Layer One: `scan.json`

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

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