A practical Suno prompt workflow: one change at a time

Why rerolling feels productive and isn't

The default behaviour with a generative model is to hit generate again and hope. It occasionally works, which is exactly what makes it a trap: intermittent reinforcement is the most durable way to build a habit that doesn't improve anything. Fifty rerolls later you have fifty tracks, no idea which prompt words did what, and no ability to reproduce the one you liked.

The alternative is not more effort. It's the same effort spent in a structured order. Build one prompt you understand, change one thing, listen for one difference, write down what happened. The skill compounds; rerolling doesn't.

There's also a hidden cost people rarely count. Every reroll spends attention as well as credits, and attention is the scarcer resource. After an hour of blind regeneration your ears are fatigued and your judgement is worse than when you started — which is precisely when people accept a mediocre take because they're tired of deciding.

Build a baseline you can return to

A baseline is a deliberately plain prompt that reliably produces something listenable. It's not meant to be good. It's meant to be a control group.

BASELINE
Genre: indie pop
Tempo: 108 BPM, steady
Instruments: electric guitar, bass, live drums, light pad
Vocal: female alto, close, conversational
Space: small room, short plate reverb
Mood: warm, slightly wistful

The loop

• Write the baseline and generate it twice to see its natural variance.
• Pick exactly one variable to change — tempo, one instrument, vocal descriptor, or space.
• Change only that, keeping every other word byte-identical.
• Generate twice, so you can tell a real effect from variance.
• Listen for the one thing you changed; ignore everything else.
• Log the change and the outcome in one sentence.
• Keep the change if it helped, revert if it didn't, then repeat.

What counts as one variable

Keep a log that's actually useful

The log is the deliverable, not the songs. One line per run, in a plain text file or a spreadsheet, is enough. What matters is that it records the delta and the perceived effect, not a general vibe rating.

After twenty entries you'll have something no amount of rerolling produces: a personal map of which words this model responds to, in your genres, for your taste. That map is transferable across projects and it survives model updates far better than any specific magic prompt.

Date every entry. Models get updated, and a finding from six months ago may simply no longer hold. A dated log lets you re-run the handful of tests that actually matter after an update instead of losing confidence in the whole file.

run 14 | +"gated snare" | drums much harder, vocal pushed back | keep
run 15 | "wide reverb" -> "tight room" | vocal forward, chorus smaller | revert
run 16 | 108 -> 96 BPM | groove sits better, energy drops | keep, raise chorus intensity next

When to stop tuning

• Three consecutive changes produce no audible difference — you've hit the prompt's ceiling for this idea.
• You're now fixing things that would be faster to fix in an editor.
• The track is good and you're polishing out of anxiety rather than intent.
• You've started stacking adjectives; that's usually the model ignoring you, not you being precise.

Stop, export the keeper, write down the final prompt, and start the next idea from a copy of it. Your baseline just got better, which is the actual point of the whole exercise.

FAQ