Turning WeChat Writing Into a Pipeline That Won't Fire on Its Own

The most tempting button is one I haven't built yet

The easiest scene to demo in a content pipeline is: enter a topic, and minutes later the page pops "published." That scene sells well, but I don't dare hand a real account to it.

An article, from source to broadcast, passes through at least facts, body, layout, assets, account and platform status. Guess wrong at any layer and that final green notice may just push the error further out.

At first I wanted to build acceleration; what I actually built first was a brake: every step can stop, and after stopping it can still say where it's stuck. Because these four cases must never be covered over by the same "success":

• The source may be unreliable.
• The model may invent a case that didn't happen.
• Layout succeeding isn't the same as mobile-readable.
• The API receiving a request isn't the same as a correct draft existing in the target account.

So generation, layout, save-draft and broadcast don't share one button. Speed can be added later; a runaway duplicate broadcast is hard to undo.

A piece of content isn't an article in the system — it's a run

I treat each production as an independent run. It has to answer at least:

• Where the input came from.
• Which claims are verified.
• Which version the current body is.
• Which version generated the layout file.
• Which account it's heading into.
• Whether the platform has been read back.
• Whether the next step is authorized.

The specific filenames can vary by project, but the content contract shouldn't be missing. A minimal run directory can be expressed as:

run/
  sources/          original links, documents and screenshots
  claims.json       citable facts, limits and items to verify
  article.md        the current body
  rendered.html     the platform version after layout
  assets/           self-made cover and body images
  receipt.json      local actions and platform read-back

This isn't demanding everyone copy the directory — it's reminding myself that source, facts, body, visuals and platform status can't be mixed into one file.

Six stations, each doing only one thing

Source station: keep the original, don't rush to opinions

This saves the original URL, author, publish date, update time and license. A search summary only finds leads — it can't go straight into the fact table.

When a page can't be read, the status is "source missing," not "let the model fill in the body from the title."

Fact station: separate the four kinds of sentence

Sentences in an article split into at least four types:

• Facts directly supported by a source.
• Inferences made from several facts.
• Kenton's experience and judgment.
• Verification not yet done.

This step matters, because the model is best at writing all four in the same confident tone. The fact table keeps the source and the level of support, so the Writer knows what can be written and what to leave blank.

Draft station: organize around one reader's problem

Drafting isn't expanding the fact table more smoothly — it's designing an order of understanding for one clear reader. A technical tutorial needs preconditions, actions, a success sign and a failure exit; a case postmortem needs background, evidence, choice and cost.

The model can organize expression, but it can't invent local tests, user feedback, platform permissions and business results.

Layout station: convert, don't change the conclusion

The formatter only handles heading levels, paragraphs, lists, code, images and platform HTML. It can't add punchlines, exaggerated promises or a fixed ad tail in the name of "stronger reach."

After conversion, keep at least a Markdown and an HTML version. Only then, when a page is wrong, can you tell whether the problem is the body or the conversion.

Draft station: read back after submitting

Generating HTML locally only says "a local deliverable exists."

The platform API returning an ID only says "the request was accepted."

Reading the title, body, cover and draft ID back from the target account is what lets you mark it "draft confirmed."

These three states can't be replaced by one "success."

Broadcast station: use one-time authorization

Broadcast and save-draft are two actions of different risk. A broadcast authorization is only valid for the current account, the current article version and the current time window.

Once the body or cover changes, the old authorization expires. Allowing a broadcast last time doesn't mean the next article gets permission automatically.

Status names must show where the evidence is

I avoid a vague "done" and keep an evidence hierarchy:

collected
claims_ready
drafted
layout_checked
draft_submitted
draft_confirmed
publish_authorized
published_confirmed
unknown

The most critical is unknown.

On an API timeout, a dropped page or a failed read-back, the system doesn't know whether the platform received it. unknown is neither failure nor success. Auto-retrying here may create a duplicate draft; publishing onward may cause a duplicate broadcast.

The right action is to freeze the current run and first read the list, ID or page status from the platform. Until there's new evidence, the status stays unknown.

How to locate one real failure

Say after saving a draft, the backend doesn't immediately show the new article.

Don't re-run the whole thing from gathering material. Check layer by layer, by evidence:

1. Is article.md frozen: confirm which body version this submission corresponds to.
2. Is rendered.html complete: whether the title, image references and body exist.
3. Was the request sent: check the time, target account and the platform-returned ID.
4. Can the platform be read back: query via the draft-read API or the current backend.
5. Is there already a same-title draft: compare IDs and creation times; don't delete by title alone.
6. Still can't confirm: keep it unknown, stop blind retries.

This looks slower than "just click again," but it avoids the hardest error to handle: the system made a duplicate result, but didn't record which one is real.

Three hard boundaries I set for automation

First: writing permission can't naturally escalate into publishing permission.

The tool that researches and drafts doesn't need to hold broadcast capability. Even in the same program, keep the action entrances separate.

Second: high-risk actions fail closed by default.

When an account, authorization, asset or read-back is missing, the flow stops — it doesn't guess a default and continue.

Third: platform status is only upgraded by platform evidence.

Local files, HTTP status codes and interface notices all have value, but each only proves limited facts. You have to get the target system's read-back before claiming an external action is done.

The minimal version needs no big backend

If you're currently fully manual, don't build a full-featured console first. Running this loop through one real article is enough:

1. Save two reliable sources.
2. Write one fact table.
3. Generate one Markdown.
4. Manually check the laid-out HTML.
5. Only save to draft.
6. Read the draft back from the target account.
7. Decide on a broadcast only after human confirmation.

In these seven steps, each has to name its input, output and pass condition. Once it's stable run after run, then automate the mechanical steps.

I now judge whether a pipeline is mature not by how many clicks it saved, but by whether it can stop at the right station when something goes wrong. Reverse-engineer one already-published article and write down, station by station, "stop if this evidence is missing." That sheet is usually more useful than installing one more one-click publish tool.