Most people approach AI writing the same way. They type a topic into a box, receive twelve hundred fluent words, and then spend an hour trying to make those words publishable. The draft is confident and completely generic. It touches every point and commits to none.
The problem is not the model. It is the order of operations. Asking for a finished article in a single request means asking one system to do four different jobs at once: decide what the piece argues, gather what it needs, arrange it, and write it. All four get done adequately. None get done well.
Split those jobs apart and the same model produces something you can publish with a light edit. The workflow below is six steps. Each one names the input it needs, because that input is what separates a draft you can ship from a draft you have to rebuild.
Why one-shot drafts fail
When you ask for a complete article in one move, the model has to invent the substance of the piece, because you have not given it any. It cannot know what you have seen, which customer objection keeps coming up, or what your team tried last year that did not work. Lacking that, it fills the space with the average of everything it has read about your topic.
The result is recognisable immediately. You get three-paragraph introductions that circle the subject without landing on it. You get lists of five points where each point is true and none is useful. You get transitions that promise a lot — "but the real secret is…" — and then deliver a restatement of the previous paragraph.
None of this is a defect in the model. It is a defect in the brief. The quality of what comes back is bounded by how much of your own knowledge made it into the request. If all you sent was a topic, the average of the internet is exactly what you asked for.
Step 1 — Write the argument in one sentence
Before you open any tool, write one sentence that states what the article claims. Not the subject — the claim.
A subject is "AI and content marketing." A claim is "Most content teams get poor results from AI because they generate final drafts first and decide what to say second."
The second version tells you what every section has to support. It also gives you a test you can apply to every paragraph later: does this sentence help the claim, or is it just adjacent to the topic?
If you cannot write the claim in one sentence, you do not yet have an article. What you have is a subject, and a subject produces exactly the kind of piece described in the previous section.
Step 2 — Build the evidence file
This is the step almost everyone skips, and it is the one that decides whether the finished piece has any value. The evidence file is a short collection of things only you can supply:
- Observations from work you have actually done — what the process looked like, where it broke, what you changed.
- Numbers you own: your own timing, your own counts, your own results. Not figures you half-remember from somewhere.
- Questions real people asked you, in their words. Customer objections are the most reliable source of section headings.
- Specific examples, named plainly. A generic example teaches nothing.
Five to ten bullets is usually enough. It does not need to be tidy prose — fragments are fine, because you are going to hand these to the model as constraints rather than as copy.
One rule matters more than the rest: never write an instruction that tells the model to cite a source. Requests like "reference a recent industry report" or "include a statistic about adoption" produce confident, invented attributions. If you do not personally have a number, the honest move is to write the sentence without one.
Step 3 — Outline as reader questions
Write your outline as four to seven headings, each phrased as a question a reader would actually ask. Not "The Benefits of Batching" but "How much time does batching actually save?" Not "Common Mistakes" but "Why does the draft still sound like a robot after three edits?"
Questions do two things that noun-phrase headings do not. They force each section to have something to answer, and they create forward motion, because a question in a heading is an open loop the reader wants closed.
If a question turns out to have no substance behind it, that is useful information now rather than after you have written eight hundred words under it. Cut it and merge what remains.
Step 4 — Draft one section per request
Now use the tool — but ask for one section at a time, and give that section everything relevant: the one-sentence claim, the three or four evidence bullets that belong to it, and the heading.
A request that works looks roughly like this:
Write the section under the heading "How much time does batching actually save?"
Context: the article argues that teams get poor AI results because they generate drafts before deciding what to say. This section must answer the heading with the specifics below.
Specifics: [your evidence bullets]
Rules: no invented statistics, no invented quotes, no source citations. Write in plain sentences. Do not open with a definition. Do not use the phrase "in today's fast-paced world" or any variant.
Working one section at a time keeps the context tight, and tight context is what produces detail. Ask for the whole article at once and the model has to spread its attention across every section, which is why the middle of one-shot drafts always flattens out.
The explicit prohibitions matter as much as the instruction. Every "do not" you add removes a specific failure you have seen before.
Step 5 — Edit for specificity, not grammar
Grammar is the model's job and it usually does it correctly. What it cannot do is decide whether a sentence contains any information. That is your work, and it is mechanical enough to be quick.
Go through the draft and circle every abstract noun — efficiency, engagement, optimisation, value, insights, solutions. For each one, ask what actually happened. Then write that instead.
"This improves efficiency" becomes "this step drops from about forty minutes to about ten." "Drives better engagement" becomes "readers reach the last section instead of leaving at the second heading." The replacement does not need to be dramatic. It needs to be checkable.
Then delete every sentence that cannot be wrong. Vague encouragement feels like content because it is grammatically complete and pleasant to read, but it carries no information, and a page full of it is what search engines and readers both recognise as filler.
Step 6 — Cold read before publishing
Read the finished piece once, doing only one thing: after each paragraph, silently ask "so what?" If you cannot answer in a few words, the paragraph is not carrying its weight. Cut it, or replace it with the thing that answers the question.
Two checks belong with this pass. First, does the headline promise exactly what the article delivers, or does it promise slightly more? A headline that overpromises is the fastest way to make an otherwise solid piece feel disappointing. Second, does the piece end, or does it simply stop? A final section that restates the introduction is not a conclusion.
Where this fits in a week
The steps compress well. Deciding the claim and assembling the evidence is the only part that requires you to think, and it is roughly thirty minutes. The outline takes ten. Drafting four sections takes forty minutes, but you are reviewing rather than writing. The specificity edit is the longest stretch at around forty minutes. The cold read is fifteen.
The compounding effect is in step two. The evidence file is not article-specific — observations, customer questions, and your own numbers accumulate. By the fifth piece you are assembling the file from notes you already have, and the front of the workflow drops to a few minutes.
That is the real reason to run this as a workflow instead of a prompt. The model is replaceable and interchangeable. The evidence file is not, and it is the only part of the process that makes the finished article something a competitor cannot reproduce.