AI Rap Videos 製作者説明如何設計付費 AI 影片流程中的免費文字預覽

A free text preview inside a paid media workflow creates a very specific UI problem: what, exactly, has the user approved?

I am the maker of AI Rap Videos, where a person or pet photo becomes a short rap performance. The public flow lets people preview and edit four English lyric lines before purchasing a video. That gives a concrete example for the design pattern below. This is a suggested frontend model, not a description of our private backend or a claim about conversion results.

Separate three promises

A lyric preview shows the words. It does not preview the final voice, timing, facial motion or complete video. A price quote describes a purchase. A generation result proves that a file exists.

Those three promises should have different labels and states. A single boolean such as isReady cannot tell a component which promise it is making.

Make stale previews visible

Consider this sequence:

1. A user requests a birthday verse for Alex.
2. The user changes the name to Sam before the response arrives.
3. The older request returns with Alex's lyrics.

If the UI simply renders the last response to finish, it can show an apparently successful preview for the wrong input. Disabling the button alone does not solve requests already in flight.

A minimal illustrative TypeScript model can attach a local revision to requests:

type PreviewState =
  | { status: 'idle' }
  | { status: 'loading'; revision: number }
  | { status: 'ready'; revision: number; text: string }
  | { status: 'error'; revision: number; message: string };

function acceptPreview(
  currentRevision: number,
  responseRevision: number,
  text: string,
): PreviewState | null {
  if (responseRevision !== currentRevision) return null;
  return { status: 'ready', revision: responseRevision, text };
}

The caller should ignore a null result, not replace the current screen with it. Increment the revision when preview-relevant inputs change. Cancellation can reduce wasted work, but the revision check still matters if cancellation arrives too late. This is a UI consistency mechanism; it is not authorization for a paid job.

Treat editing as ownership

Once a person edits the verse, an automatic refresh should not silently replace it. Keep the editable draft distinct from a proposed replacement, and let the person choose whether to apply the new version. Preserve the draft after a recoverable failure.

Some settings affect the preview and others affect only the output. Define that boundary explicitly. Changing the subject name should invalidate a verse about the old name; changing portrait to landscape need not discard the person's writing if the text remains applicable.

Keep payment language precise

Use a label such as “Preview my lyrics · free” for the text step, and show the paid video price separately. On our public page, standard 480p and HD 720p also consume different amounts of video balance. A resolution change therefore needs a clear cost update even when the lyrics stay unchanged.

The server must independently check the final request, balance and applicable rules. A frontend ready state must never serve as payment proof.

Test the transitions, not just the happy path

Useful checks for this pattern include an old response arriving after a new one, edits made while a request is running, changing a cost-affecting option after preview, and retrying after a network error without losing the draft. Also check that keyboard focus and an accessible status message make loading and errors understandable.

These checks answer a narrower, testable question than “is the generator working?”: does the UI consistently show the text and price the user actually chose?

Disclosure: I make the linked product. This article was drafted with AI assistance and checked against the current public product flow; the code is an illustrative pattern, not production source.