qwen-audio-3.0-tts-plus Prompt Recipes for Developers

Why TTS prompts deserve the same rigor as code

Most teams treat text-to-speech as a one-off: someone types a sentence into a demo box, the audio sounds fine, and the prompt disappears into a chat log. Three weeks later a copy change forces a re-run and nobody can reproduce the original delivery. The voice drifts, the pacing shifts, and the only fix is to guess again.

That failure mode is a process problem, not a model problem. A TTS prompt is an input that shapes an output, exactly like a config file or a template string. If it lives nowhere, it cannot be reviewed, diffed, or rolled back.

Treat each prompt as a recipe: a named, versioned artifact that pairs a script with the delivery instructions that made it sound right. Keep it next to the code that calls it, and re-test it whenever the script text changes, the caller changes, or the model version changes under you.

The payoff is boring and valuable. When a recipe is versioned, a failed re-generation becomes a diff. A stakeholder request to "make it warmer" becomes a branch, not a rewrite. And onboarding a new engineer means handing them a folder, not a memory.

A working rule: if a piece of audio is good enough to ship, the recipe that produced it is good enough to commit.

Anatomy of a reusable qwen-audio-3.0-tts-plus recipe

A recipe that survives real use has four parts. Keep them as separate fields in your prompt file rather than one long string, so you can edit one layer without touching the others.

1. Delivery note

A short instruction block that sets the overall read: audience, tempo feel, formality, target medium (explainer voiceover, ad read, IVR prompt). Write it in plain language and keep it stable across a series. This is the layer that changes least often.

Delivery: calm product explainer, moderate tempo, warm but not
chatty, addressed to a developer audience. Avoid rising
trailing intonation on statements.

2. Script body

The actual words to be spoken. Nothing else. No stage directions buried mid-sentence, no parentheticals that might leak into the audio. If a word must not be read aloud, it does not belong in this field.

3. Segment markers

Delimiters that split the body into independently directed chunks — typically one or two sentences each. Segments are where tone and pacing notes attach, so they need to be unambiguous and cheap to parse.

[seg-01] First segment text here.
[seg-02] Second segment text here.

4. Output expectations

A human-readable note on what the result should sound like, plus whatever verification you actually do (duration range, syllable-level spot checks, a link to the approved audio). This is what makes the recipe reviewable by someone who was not in the room.

Store all four in one file per use case, named for the use case rather than the model, so swapping the underlying model does not force a rename. The recipe should read as a specification first and a prompt second.

Recipe: narration and voiceover pacing

Pacing in TTS is mostly a writing problem. The engine reads what you give it, and long unbroken sentences tend to come out rushed or strangely emphasized. The fix is to control sentence length and line breaks before you touch any cueing language.

Delivery: documentary-style narration, unhurried, even energy,
clear sentence-final falling intonation.

[seg-01] Most audio pipelines fail at the same place.
[seg-02] Not at the model.
[seg-03] At the prompt that nobody saved.
[seg-04] A script change arrives, someone re-runs the generation,
and the voice comes back different, with no record of
what the old one looked like.

Three things make this repeatable:

• Short opener segments. One sentence per marker early on gives the engine clean boundaries and gives you a predictable rhythm.
• Physical line breaks inside a segment at natural clause boundaries. They act as pacing hints without adding punctuation the listener will hear as a pause.
• Sentence-final falling intonation spelled out in the delivery note. Statements that end on a rise sound uncertain, which is the most common complaint about long-form narration.

Write for the ear, then check. Read your script aloud once; anywhere you run out of breath is a place to split a segment. If a sentence contains more than one idea, it is two sentences.

Recipe: punctuation and pause control

Punctuation is the pacing control surface you already own. Used deliberately, it steers pause length and emphasis without adding any extra instruction language. The rough ordering most engines follow, from shortest to longest break, is:

comma  <  dash  <  period  <  ellipsis

That ordering is a useful default, not a guarantee — always confirm by listening. The recipe below uses each mark for one job only.

Delivery: instructional narration, steady tempo, deliberate
pauses at section changes.

[seg-01] Here is the part most people skip: the punctuation.
[seg-02] A comma is a breath. A dash — a short hold. A period
ends the thought.
[seg-03] And an ellipsis... is a real pause. Use it sparingly.
[seg-04] Three rules. Short sentences. One idea each.
Punctuate on purpose.

Practical constraints that keep this reproducible:

• One mark, one meaning. If a dash sometimes means "hold" and sometimes just decorates, the recipe will not read consistently across re-runs.
• Avoid stacked marks. Multiple exclamation points or interleaved ellipses and dashes produce erratic pauses. Pick one.
• Do not over-punctuate. A comma every three words fragments the read and makes the delivery sound robotic.
• Test the extremes. Compare a fully punctuated segment against the same text with minimal punctuation; the difference tells you how much weight the engine puts on marks.

Because punctuation changes are pure text edits, they are trivially diffable. That makes this the cheapest recipe layer to iterate on.

Recipe: emotion and tone cues by segment

Whole-script emotion instructions are brittle. A single "sound excited" note applied to a five-minute track produces a uniformly loud read and flattens every transition. Segment-level cues are the better tool: they let mood shift inside one continuous piece of audio, and they let you regenerate a single segment when one line lands wrong.

Delivery: multi-section product narration, same speaker
throughout, tone shifts at segment boundaries.

[seg-01 | tone: neutral, informative]
Here is what changed in this release.

[seg-02 | tone: neutral, informative]
The generation path is faster, and the retry logic is simpler.

[seg-03 | tone: warm, reassuring]
If something does fail, it now fails loudly and early,
not silently at the end of a long job.

[seg-04 | tone: upbeat, confident]
That is the whole update. Ship it.

Guidelines that keep segmented cueing under control:

• Name the tone, then anchor it. A bare label like "warm" is ambiguous. Pair it with what it means here — reassuring, slower, softer ending — so a future reader can re-create it.
• Keep the speaker constant. All segments should read as the same person. Cue the mood, not the persona.
• Change tone at boundaries, not mid-sentence. Mid-segment shifts are hard to verify and easy to make jarring.
• Limit yourself to a small tone vocabulary per project, and reuse it. Five well-understood labels beat twenty invented ones.

Because segments are independent, a rejected line is a one-segment re-run rather than a whole-track regeneration. That also makes A/B testing cheap: vary the cue on seg-03 and keep everything else fixed.

Testing outputs and locking a recipe

A recipe is a hypothesis until you have heard it. The loop is short and does not need tooling beyond a folder and a naming convention.

The loop

1. Draft. Write or edit the recipe file. Change one thing at a time — a single cue, a single punctuation pattern, a single segment split.
2. Generate. Produce audio for the whole script, not just the segment you edited. Pacing is contextual, and a change in one segment can shift how the neighbours read.
3. Compare. Listen to the new output against the last approved one, back to back, on the same speakers or headphones. Judge pacing, emphasis and tone transitions separately; they fail independently.

If the new take wins, promote it. If not, revert the file and keep the note about what failed in the commit message.

What to record

• The full recipe file, exactly as sent.
• The rendered audio, stored beside it with a matching name.
• A one-line verdict per comparison: what changed, what improved, what regressed.

Locking

When a recipe is approved, tag it — v1, v1.1, or a date-based tag, whichever your project already uses. From that point the tagged recipe is the shipped artifact; further edits branch from it. If a model version changes underneath you, regenerate from the tagged recipe first so you can measure the difference against a known reference rather than against memory.

Two rules make locking stick: never edit a locked recipe in place, and never ship audio whose generating recipe is not in the repository.

Common recipe mistakes and how to fix them

These are the failure modes that show up most often once teams start versioning recipes. Each has a text-level fix.

Over-cueing

Stacking delivery notes, tone labels, emphasis marks and parenthetical directions into one segment. The result is an unstable read and a recipe nobody can maintain.

Fix: one delivery note per recipe, one tone cue per segment, punctuation carrying the rest. If a segment needs three instructions, it is probably two segments.

Inconsistent punctuation

Using dashes and ellipses decoratively in some places and meaningfully in others. The same mark then produces different pauses across the script.

Fix: assign each mark exactly one job and audit the file for violations before generating. A search for ... and — takes seconds.

Unrepeatable scripts

Copy-pasted text with smart quotes, stray whitespace, or a parenthetical that was meant for a human reviewer and gets read aloud.

Fix: keep the script body free of anything not intended to be spoken, normalise quotes and spacing in your editor, and diff the file after every paste.

Whole-script emotion

A single "excited" or "serious" instruction covering minutes of audio.

Fix: move tone cues to segments, keep the speaker constant, and let mood change at boundaries you can verify by ear.

Untested edits

Changing a cue and shipping without listening, because the text looked fine.

Fix: generate and compare before promoting. A prompt that reads correctly on paper can still drift in pacing or emphasis.

When in doubt, cut instructions rather than add them. A short recipe with clean punctuation and honest segment boundaries is easier to reproduce than a long one that tries to control everything. Build the recipe, listen to the output, and lock what works.