四句輸入、十七頁輸出：簡報生成器錯在內容結構

Monday at ten past eleven he typed four sentences into a box on his phone and went to bed. At seven the next morning the answer was waiting: seventeen pages.

Three evenings before that he had spent on the same talk and produced no page he could stand behind. He had moved font sizes from 24 to 28 and back. Only three of his own pages had words on them.

We are the small team that built the thing he typed into. When a user hands us a run like this we get the request and the result and, if we are lucky, the corrections in between. This one is worth going through slowly, because almost none of what went wrong was a writing problem. It was a shape problem.

The four sentences

He wrote it the way he would hand a job to a colleague:

Thursday, ten in the morning, ten minutes, and the room isn't technical.
Three things only, with one real example each.
No charts, no jargon, and a last line they can carry out the door.
Send it to my email when it's done.

Read that as a spec. It is better than most tickets we see. It fixes the deadline, the venue, the audience, the count (three things), the evidence form (one real example each), the visual register (no charts), the vocabulary register (no jargon), the ending (one actionable line) and the delivery channel.

Nine constraints, and every one of them is checkable. A reviewer could hold the output against that list and mark it.

Then notice what is missing. Nothing in those four sentences says how long the thing should be. Nothing says what unit a page should hold. Those are the two dimensions the generator had to decide for itself, and it decided them the way a system decides anything it was not told: in favour of the surface it was working on.

Sixteen pages of half a thing

The first version came back tidy. Margins, type sizes, images — all of it more presentable than the three pages he had made himself. The trouble was structural, and he described it precisely: every page said half a thing.

His three things had become twelve pages, four pages each, with one short phrase standing in the middle of each group like a slogan. His one real example had been pressed into three lines. He read it aloud and could hear that he still had not given an example.

This is the failure mode that hides behind a clean first draft. The generator did not refuse the work and it did not get the topic wrong. It took the one unit it had — the page — and expanded every claim until the page was full. The content stayed at three items. The container grew to seventeen. The ratio between them is the bug, and it is invisible in a screenshot.

For an audience that already knows the subject, half a thing per page is survivable: they fill in the missing half from context. For the audience in those four sentences — a room that is not technical — it is fatal. There is nothing to fill the gap with.

The correction that worked was about shape

He sent back what he had been given, with one line added:

One thing to a page, and write the example as something that happened, not as a conclusion.

The second version was six pages. One thing to a page, an example left whole on each, with a person, a place, a point in time.

Two words in that correction do all the work. One thing names the unit. To a page binds that unit to the surface. The rest of the sentence does the same job for the evidence: not "add an example" — he had already asked for examples and got a summary of an example — but "write it as something that happened". A sequence of events with a person in it, concretely enough that a listener can picture the room.

That is the pattern we keep finding. When a first draft comes back wrong, the instinct is to re-roll it with more adjectives: shorter, warmer, punchier, more concrete. Those are not constraints, they are moods. A meaningful correction names a dimension the generator was free to choose, and pins it.

Note also how small the correction was. One line. It cost him less to write than the original four sentences. If the cheap correction is available and the expensive one is not, the system should be shaped so that the cheap one lands.

A correction has to change the shape, not the sentence

The quick way to handle feedback is to take the last output and ask for it again with the new instruction appended. That fixes tonight. It rebuilds the same complaint next week, and now there are two outputs that disagree about what the instruction is.

What we wanted, and what the second version showed, is that the correction changes the rule that produces the shape rather than the shape that was already produced. "One thing to a page" is not a note on pages 3 through 11. It is the reason page 3 exists at all. The next run inherits it.

That distinction is easy to state and annoying to build. A prompt is easy to version. A person's intent, written in their own words, at a granularity they can recognise as theirs — that is a different piece of work. He has to be able to look at the accumulated shape rules and see his own line in there, otherwise the next correction will contradict a rule he never knew he had set.

Editing beats a blank page

The third version he did himself. He cut a page, moved a section, merged two more, and spent what was left of the week on the opening line. Two mornings of nothing but cutting.

He said the thing that made us write all of this down: editing something that already exists is far easier than facing a blank page and deciding the first sentence. He had not believed that before.

That is the honest value proposition of a generator for a piece of structured work, and it is not "the machine writes better than you". It is that the expensive moment — the blank page, the decision about what the first line is — gets moved off the critical path. What comes back does not have to be good. It has to be good to edit: a legible structure, one idea per unit, examples that are events rather than conclusions. Prose that is merely clever is a worse first draft, because you cannot cut it without losing the thing that made it look good.

The flip side is a boundary we are careful about. It does not read the files on his computer. It does not know the decks he made before, and it will not remember the house style of his team unless he tells it. It generates the thing he described, in the shape the rules produced, and it delivers it. The continuity across those four decks in his folder is his, not ours.

What we would instrument

Page count is the metric that looks useful and isn't. Seventeen pages out of a four-sentence request reads like productivity and is actually sixteen pages of half a thing. The number that told the truth on this run was not the count; it was what happened after.

If we were instrumenting this properly — and this is a design proposal, not something we can already show you off a dashboard — we would look at the rework signature instead. How many units did the human delete, merge, or rewrite? What did the cheapest correction change — a sentence, or a rule? Did the second run keep the first run's correction? A deliverable that comes back at the same size and shape after a structural correction is not converging; it is repeating.

The other honest reading: he did not come back to us for the third version. He edited it himself, twice, and then walked into the room with it. For a tool like this the success state is a person who no longer needs the tool for the last mile. That is a strange thing to write in a growth post, and it is the only version of the product we would defend.

A pre-flight list for structured deliverables

If you are wiring a generator into a job that ends in a document with an audience, these are the questions that decided this run:

• What is the unit? A page, a section, a slide, a card. If you did not name it, the generator will name it after the surface, and the surface wants to be full.
• Which dimensions did you leave unspecified? Those are the ones that will be wrong. Length, granularity, and the size of the evidence are almost never in a first-hand spec.
• What form must the evidence take? "An example" is not a form. "Something that happened, with a person, a place, and a time" is.
• Where does a correction go? If the answer is "into the next prompt", you are rebuilding the same week with a different set of symptoms.
• Can the person who receives it edit it? If the first draft is clever instead of legible, the answer is no, and the pass they were going to do themselves is the whole reason this was worth doing.

None of these are model questions. All of them were the difference between a talk that happened and a deck that got reused four times.

Where it sits

CloudPal runs long jobs on our machines and hands back a finished document — nothing to install, nothing asked of your computer, nothing read from the files you already have. You describe what you want the way you would describe it to a colleague, including the parts you did not think to specify; it goes and does the work; the result arrives where you already look.

It is in limited preview: new accounts get a dollar of credit, enough to run something real, and the number of new accounts per day is capped.

If you are evaluating it as an engineer, the property worth testing is not the prose. It is whether a one-line correction about shape changes the shape of the next run — and whether the person who asked for the work can tell you that it landed without opening an app.

CloudPal.TuringCorp.net — create an Agent Pass, sign in, and say what you want done.

Earlier in this series: the requester is not the reader, the first run is a demo, the ninth is the product, the meter, not the price, the request was one sentence, what breaks when an agent has to keep an appointment, and we deleted the install step.