Content Factory: A One-Person Local AI Content Pipeline

The first time I described Content Factory, it sounded too much like a button

"One article auto-generates WeChat, Xiaohongshu, Douyin and a blog" — that sentence is easy to grasp, and I've used it. But it happens to hide the hardest part of the system.

The same material can share facts, but you can't copy the same body into four platforms; a locally generated file doesn't mean the layout is readable; an API returning success doesn't mean content has appeared in the target account. A more real problem: three months later, updating the article, can you still find the source and version from back then?

Content Factory isn't about turning one into four. It handles the things most likely to run out of control when one person does content long-term: scattered material, facts mixed with inference, platform versions copying each other, publish status resting on memory.

So I now call it a production line. Every station leaves something behind — and leaves responsibility behind too.

The smallest unit of a piece of content in the factory

The basic unit in the system isn't "an article" — it's one content run with an identity. A run includes at least:

• The original source.
• Citable facts.
• Unconfirmed questions.
• The target reader and search intent.
• Kenton's main judgment.
• Platform-native drafts.
• The cover and step assets.
• QA results.
• Authorization records.
• The platform read-back.

These objects don't all have to be saved in one format, but they must map to each other. Otherwise, after the body updates, the system may keep using the old cover; after a draft appears on the platform, locally you no longer know which version it matches.

The current structure: six layers, not six big models

Source layer

The source layer saves links, captions, documents, screenshots, fetch time and license info. Original material is kept as untouched as possible; what's generated later are derived files.

The rule here is simple: can't read the page, record that it can't be read; only a search summary, mark it a lead; no date, don't fill in a date for the source.

Facts and judgment layer

This layer splits information into four kinds:

• Facts directly supported by a source.
• Inferences combined from several facts.
• Kenton's experience and choices.
• Questions still needing a real test.

The platform Writer can only consume the allowed parts. For versions, prices, account rules and software entrances, it also records the last verification time.

Topic layer

Topic selection isn't "write whatever word is hot." I look at, at the same time:

• What problem the reader needs to solve now.
• Whether this problem has a stable search intent.
• Whether I have the conditions to verify it.
• How much it costs to make screenshots and real tests.
• Whether it relates to the AI, automation and content-production mainline.
• Where the reader should naturally go after reading.

If a piece has only traffic, with no verification conditions or long-term value, it can enter inventory, but it doesn't have to be produced right away.

Platform production layer

WeChat, the blog, Xiaohongshu and Douyin have different Writers. They share a fact pack, not the final deliverable.

The blog handles full explanation and the search entrance; WeChat suits continuous reading; Xiaohongshu needs image-and-text nodes; Douyin organizes voiceover around real on-screen actions.

The system doesn't chase "generate four at once" — it chases "the four don't contradict each other."

Quality and authorization layer

Quality checks include at least source, originality, timeliness, beginner readability, images and the business path. Different problems go back to different stations to fix.

Generation done, layout done, draft saved and published for real are four states. A real external action always needs independent authorization — it isn't triggered automatically by the previous step.

Read-back layer

The read-back layer saves the platform's real status, the article URL, the draft ID, the publish time and the necessary feedback.

Only by reading back from the target system does content upgrade from "done locally" to "confirmed externally." On a timeout or a can't-confirm, the status stays unknown, with no blind re-submitting.

How data flows between the layers

The logical chain can be compressed into this diagram:

source evidence
  -> claims and unknowns
  -> topic decision
  -> platform package
  -> layout and editorial gates
  -> explicit authorization
  -> platform action
  -> external read-back

Every arrow is a contract. What the previous step delivers, what the next step needs, and where it stops when something's missing — all have to be clear.

This is also what local-first means: not that everything is offline, but that important intermediate assets land first in a place you can manage, without treating a platform backend as the only content store.

Run one minimal loop with a public link

Say I find an official product update and want to write it as a blog tutorial.

1. Save the source

Record the official URL, publish date, update date and a snapshot of the original page. A third-party retelling can be a lead, but facts go back to the official page first.

2. Build the fact table

Separate the product's new capability, the applicable version, the limits and the unexplained questions. A capability not verified locally can't be written as "I've already used it."

3. Decide the reader's problem

Not "a major product update," but a problem a user would actually search, e.g. "does my existing config still work after upgrading."

4. Verify in a real environment

Save the steps, version, success screen and failure info. When it can't be verified, the article can become a concept explainer or be paused — don't force a fake walkthrough.

5. Generate the blog package

The blog package includes the body, a title-based cover, necessary screenshots, a summary, tags, the source and one CTA. The cover is created around the title; it doesn't download the reference site's images.

6. Pass the quality gate

Check terminology, steps, success criteria, risks, source and mobile. An article with no increment, only a rewording, isn't published.

7. A human decides to publish

A passing local build isn't the same as live. After authorization, run the deploy, then read the actual page from the public URL.

8. Update the read-back

Record the public address, publish time and the version conditions that will need updating later. When the product changes in future, you can find the affected article.

Once this loop runs, then consider expanding to a second platform. Building a giant dashboard first usually just visualizes undefined problems.

How I separate "shipped" from "wish to ship"

A content system is most prone to product hallucination: a module drawn in the architecture diagram is treated as already usable.

I constrain myself with three labels:

Verified: walked the full path in the current environment, with a corresponding file or platform read-back.

Partially usable: one stage works, but the before and after still need a human to connect.

Planned: only a design and an interface idea, with no real run evidence.

For example, local article generation, cover creation and a static build can each stand alone, but without a production-URL read-back, they can't be written up as "already live." Likewise, a ready local publish package isn't the same as a platform draft existing.

Measure the factory, not how many pieces a day

Generation count is easily amplified by the model, but it doesn't mean the content asset is growing. I care more about these:

• How long it takes to recover an original source.
• Whether a fact, when reused, still carries its evidence and date.
• Whether a failure can be located to a specific station.
• Whether different platforms show fact conflicts.
• Whether the platform status has a real read-back.
• Whether, when an article goes stale, you know which version it's affected by.
• Whether readers continue along the learning path or into a related service.

If you generate ten pieces a day but can't find the source, version and status, the factory just manufactures inventory faster.

Local-first doesn't mean no cloud at all

Model calls, platform APIs, image services and deploys can all happen externally. The key questions are: what was sent, who authorized it, what came back, and whether the result is saved.

Sensitive material, account credentials and unpublished content shouldn't default into every model just because "automation needs it." You can use redacted samples, temporary credentials and least privilege to finish verification.

Local-first is a control strategy, not a technical religion.

The business path should appear after solving the problem

Content Factory will eventually take on workflow consulting and content-production work, but each article can't demand the reader follow, join a group, subscribe, buy and submit a form all at once.

A general tutorial leads the reader to the next piece first; an automation article can show a ready workflow; a real case then invites the reader to submit their own process. Each piece keeps only one action relevant to the problem.

That way the commercial sense comes from "this method actually works," not from a bigger button.

How one person starts

Don't support every platform first. Pick one real piece you've already published and fill in four nodes:

1. The original source.
2. Verifiable facts and your own judgment.
3. The current platform deliverable.
4. Real publish evidence.

Then add a failure exit: if the platform status is unclear, how the flow stops.

First align one real piece's source, judgment, platform deliverable and publish evidence. Get that far, and it turns from one output into an updatable asset. As for the big dashboard and all-platform automation, those can wait.