The Blog Production Line (Part 1): I Built an AI Production Line for Blogging, Then the First Article Taught Me a Lesson
What you are reading is the second post of the production line, written after it finished its first real article. The subject is the production line itself: how the skills were chosen, how they were orchestrated, how the first live run got schooled by reality, and how the lessons were grown back into the line.
What the Production Line Looks Like
First, the structure. An article’s lifeline is four steps: research, writing, polishing, publishing. The first three each have a dedicated skill. content-research-writer is a writing-partner skill covering research, outlining, section-by-section writing, and section-by-section feedback; the pipeline uses it for its blog-article workflow: agree on an outline first, then write and review section by section, with technical tutorials also checking that code samples actually run. Polishing belongs to write, whose sole mission is stripping out the AI flavor; humanizer-zh is based on the Wikipedia list of “signs of AI writing” and targets machine cadence: three-part parallelism, inflated symbolism, and the like. None of these skills were written by me — they are off the shelf, and the production line’s only job is to wake them at the right moment.
What I added are two pieces: one called orchestration, one called the gate.
Orchestration is a skill called blog-pipeline. It doesn’t write a single word itself; it does one thing: look at which scenario you are in and call the right sub-skill on demand. Writing a new article runs the full flow; revising a published article goes through edit-article; polishing an existing draft skips everything ahead and enters the polish gate directly. It is the floor manager who never cooks. The production line’s entire inventory is this routing table:
| Scenario | Stage sequence |
|---|---|
| A. Write a new article | Topic → Research/Outline → Writing → Polishing → Publish |
| B. Revise a published article | edit-article → Validate → Publish |
| C. Polish an existing draft only | Polishing → Publish |
The gate is a script — more on that below.
Design Decision: Keep the Orchestrator Thin
This orchestrator pattern is not my invention; it was ported from my novel-writing production line “Li Bai”. Li Bai covers the full flow of “eight-question book setup, outline, manuscript, revision, archiving” and likewise generates nothing itself: subject matter, writing style, and word-count standards are all fetched live from the liyu service, and the manuscript is generated by liyu too; it only orchestrates the questioning, delegates the reviews, and guards acceptance, storing no domain data locally. The blog production line copied that skeleton and simply swapped liyu for the writing sub-skill.
One point of hesitation during the port: should the sub-skills’ instructions be copied into the orchestrator skill? Copying would make the orchestrator self-contained, complete in isolation.
I didn’t copy. The reasoning is practical: the same instructions stored in two places, edited in one and forgotten in the other, means drift is only a matter of time. A sub-skill upgrades; the copy inside the orchestrator stays on the old version; then nobody can say which set of rules actually ran. So the orchestrator skill holds only the routing table and scenario judgment, and sub-skill content is always loaded on the spot. It stays thin — and never goes stale.
Turning Discipline into Code
Agents have a flaw: they read the skill, then drift at execution time. You tell them the date must be earlier than the push moment; they remember today, and at three weeks’ notice in the middle of the night, maybe not. So discipline cannot live only in documents written for humans — it has to become code that runs.
Thus check_post.py was born: zero dependencies, and mandatory before every publish. Every one of its checks corresponds to a real pain.
The earliest check comes from the Jekyll era: back when the site still ran the Chirpy template, a post’s front-matter date was written later than the build moment (an article dated noon pushed at 11:30), and Jekyll silently skipped it — one line in the log saying “has a future date,” the article never went live, and no error of any kind. That one took a good while to diagnose, and “date earlier than the push moment” has been the first mechanized discipline ever since.
The second was the double-date trap after the Hexo migration. The site’s permalink is :year/:month/:day/:title/; I assumed :title came from the front matter, and only a curl test revealed it comes from the filename: a file named 2026-09-11-xxx.md produced the URL /2026/09/11/2026-09-11-xxx/, with the date appearing twice. Once found, this too escalated into a regex block:
1 | FILENAME_RE = re.compile(r"^(?!\d{4}-\d{2}-\d{2}-)([0-9a-z-]+)\.md$") |
The script didn’t go on duty the moment it was written. First it ran tests on five scenarios: positive case, future date, missing title, date inconsistent with filename, and the 5-minute margin boundary. Then a sub-agent did a dry run of the full flow to verify the routing and the red lines behaved as expected. Only after everything passed was it adopted. Today it also guards cover: a missing thumbnail is blocked, and a thumbnail duplicating an in-article image is blocked too (the origin of that check is in the next section).
The FAIL output looks like this, from a real trigger:
1 | [FAIL] /tmp/test.md |
FAIL means no push, no negotiation; warnings (like missing tags) may pass with an explanation.
First Live Run: the Production Line Gets Schooled
However smooth the design, only the first real run shows where it hurts. The first article was a rewrite of my 2024 CSDN piece on CentOS; a few highlights from the process.
The skill instructions were stale. These skills were originally written to Jekyll/Chirpy conventions, and the site had moved to Hexo/Butterfly the day before. A pre-publish comparison found the validator, the front-matter template, and the workflow notes all carrying the old conventions. Fortunately the gate’s philosophy is “always check before publishing,” so the problems surfaced before publishing, and all three artifacts were then updated to the Hexo versions. Which in turn proved the saying: when documentation goes stale nobody knows; when code goes stale it alarms on the spot.
The “real output” principle for screenshots. The article is about Linux commands, so the numbers in screenshots must not be invented. My machine is macOS, so I spun up a Docker container and ran the commands for real to capture genuine output; the container was Rocky Linux 9 rather than Ubuntu, because the article’s context is CentOS’s successor, and which distribution appears in the image matters. Once the output existed, it still had to be rendered into a uniform terminal-window style. The render script consumes a JSON spec where each line is tagged by type (command, output, comment) and substrings to highlight are marked separately — for example, one line of that image:
1 | { "t": "cmd", "s": "uptime -p # how long the box has been up, the human version" } |
The render script went through two versions: in the first, all Chinese came out as tofu blocks. Only later did it click that monospace fonts like Menlo have no Chinese glyphs at all — the Chinese in comments had to be switched automatically to a Chinese font, with ASCII and Chinese segments each rendered in their own. Another small trap: when a vision model QA’d the rendered results, it would earnestly “hallucinate” the tofu regions into a stretch of Chinese that never existed. When the report says “there are tofu blocks,” that is believable; before quoting any specific text it claims to have read, verify it against the source file first.
The thumbnail lesson was the most direct. I gave the first article a terminal-style banner as its cover and felt pretty good about it. After publishing, feedback arrived: don’t use images from the article as the thumbnail. I swapped in an Unsplash photo, and the requirement was codified on the spot: every article must have its own dedicated thumbnail, reusing in-article images is forbidden — written into the front-matter template, with two new FAILs added to the validator. By the time this post went out, the rule had grown another layer: the image must also be on-topic — a reader seeing it should guess what the article is about. I have personally flubbed this: “production line” rendered literally became a photo of warehouse shelves, and all readers saw was parcel delivery. The image-selection standard is now explicitly the reader’s perspective. Scripts can’t enforce that one; it can only be a self-question asked every time an image is picked.
One More Lesson After Publishing
Push done, build green, the article’s URL returning 200 — I thought it was over. A look at the home page showed no new article; a scare. Digging back in, it was actually there already: the GitHub Pages CDN cache was still holding its 10-minute window. Not a bug, but worth remembering: verify a deployment by curling the article URL directly, not just the home page. This, too, went into the skill’s checklist.
A Production Line Is Grown, Not Built
Looking back at the essence: this production line has never had a “design complete” day. Skill selection and orchestration are its skeleton, and a skeleton only means usable; what made it reliable is the loop behind it: every live run exposes one blind spot, fix it, then sediment it in three layers. The skill files shed their stale conventions; the conclusions go into the memory system, so the next task starts by checking memory and never steps in the same hole twice; the generalizable conclusions harden into new validator rules. People forget, documents go stale — only a script standing on the mandatory path to publishing spares no one.
This post is the production line’s second live run and the first artifact “produced by the line recording the line’s own growth.” Writing it validated the loop once more: the first draft omitted the orchestrator’s origin and several pitfall records, readers spotted it immediately, and the gaps were filled. When the next pain arrives, it will probably be the birth certificate of another new red line.
Other posts in this series: (2) 10 Parallel Agents Renovated 93 Old Articles in One Day (Chinese) | (3) Six Automated Pre-Publish Checks (Chinese)
