I already had a video-script pipeline. Turning it into an article pipeline took one adapter.

2026年8月7日3 次浏览来源:Dev.to阅读原文

I run a small Japanese skincare site as a side project.

It needed articles — a lot of them — and I did not want to write a second content system.

What I already had was a video script pipeline: a generator that produces a structured script per topic, which then gets turned into narration, slides, and an uploaded short.

It had been running daily for months.

The realisation was that the expensive part of that pipeline is not the video.

It is the structure: a topic, an angle, an ordered set of sections, and a claim per section.

A rendered video throws almost all of that away into pixels.

An article can keep it.

So instead of writing an article generator, I wrote an adapter.

The shape that made it reusable The script format was already close to an article outline: The video renderer consumes (for TTS) and (for slide bullets).

The article renderer consumes + and uses as the prose seed for that section.

One input, two sinks.

About 49 articles later, this is still the whole idea.

Three things that were not obvious

1.

Narration prose is not article prose Spoken narration is short, repetitive on purpose, and full of connective filler ("so, next…", "here's the thing").

Dropped verbatim into HTML it reads like a transcript, which readers bounce off.

The adapter rewrites each section with an explicit instruction to drop spoken connectives, merge the repeated setup, and keep concrete numbers.

It is the only LLM call in the article path — everything else is deterministic.

2.

The same claim must not exist twice under two URLs If both the video description and the article carry the same paragraph, you are competing with yourself.

The rule I settled on: the article is the canonical long form; the video description links to it and carries only the hook plus a one-line summary.

3.

Cache invalidation, as always The video pipeline caches rendered slides under a temp directory keyed by the script hash.

When I started editing scripts to improve the article, the video side happily reused the old slides — same slug, stale cache.

Symptom: "I fixed the script, why is the video unchanged?" The fix is boring but worth stating: key the cache on the content hash, not the slug, and normalise out any timestamps before hashing.

I got bitten by a related version of that in another project, where a JSON payload carried a field — every diff looked dirty, so a "skip if unchanged" optimisation never once skipped anything.

It quietly burned a daily API quota for weeks.

If your JSON has a timestamp in it, hashing it raw means you have written .

What the numbers look like 1 script format, 2 renderers (video, article) ~49 articles produced from scripts that were going to be written anyway 1 LLM call per section, everything else deterministic and re-runnable Publishing is a static build — no CMS, no database The site itself is AI美容カルテ, a Japanese skincare-advice site; the articles are the long-form half of the same content the daily shorts cover.

The transferable bit If you already generate content in any structured intermediate form — video scripts, slide decks, podcast outlines, release notes — you probably already own the expensive half of an article pipeline.

Look at what your renderer throws away.

That is your second output format.

分享