Skip to content

The Data Scientist

Screenshot 2026 02 11 155449

My Practical Framework for Testing Wan 2.2: A Data-Centric Tutorial

When people ask me whether a new video model is “good,” I try to slow the conversation down. “Good” is usually shorthand for a bundle of things: does it follow prompts, keep characters stable, avoid weird artifacts, and export something I can actually cut into a timeline without spending an hour fixing it?

Over the last year, I’ve learned the hard way that the only reliable answer comes from a repeatable evaluation loop. I’m not talking about a leaderboard score; I mean a small, well-defined test suite that you can run every time, with notes you can compare month to month.

In this tutorial, I’ll walk through the framework I use, and I’ll share a workflow I recently ran while testing GoEnhance AI in a production-like setting. I’ll also include the model-specific checks I use for the Wan 2.2 video model—not as a hype piece, but as a concrete example of how to judge output quality with the same standards you’d use for any tool.

Why I stopped “eye-balling” video quality

At first I evaluated models the same way most of us do: I typed a prompt, watched the clip, and made a gut call. That approach feels fast, but it breaks the moment you need to compare:

  • different prompt styles (literal vs. cinematic),
  • different scenes (faces vs. landscapes),
  • or different deliverables (social clips vs. product shots).

I started treating video generation like any other system: if you can’t measure it, you can’t improve it. The trick is not to over-engineer metrics; it’s to define a small set of observable behaviors that map to real editing pain.

So instead of “looks good,” I grade models on things I can verify:

  • Prompt fidelity (did it obey constraints?),
  • Temporal consistency (do key elements persist?),
  • Motion quality (does motion feel intentional, not jittery?),
  • Artifact profile (what kinds of failures appear, and how often?),
  • Editability (can I cut it into a timeline without distractions?).

My evaluation setup (simple, but consistent)

I keep the setup intentionally boring because boring is repeatable.

1) A fixed test suite (12 prompts)

I maintain 12 prompts across 4 categories:

  • Human close-up (3 prompts): hair detail, eye direction, subtle expression shifts
  • Hands + object interaction (3 prompts): pouring, typing, opening a box
  • Camera language (3 prompts): slow push-in, handheld drift, parallax pan
  • Text + UI-like composition (3 prompts): titles on posters, signage, or embedded text

Even if your content isn’t “people,” you still want at least one human close-up prompt. If a model can’t handle faces, it tends to fail in other fine-detail situations too.

2) A fixed scoring sheet

I score each clip 1–5 on five dimensions. A 3 is “usable with minor edits.” A 5 is “I’d ship it.”

3) A controlled generation environment

Same output duration, same aspect ratio, and I avoid changing too many generation knobs at once. If I do change something—say, more guidance, different motion strength—I note it like I would a hyperparameter in a training run.

The checklist I actually use

Here’s the rubric I’ve landed on after too many late nights staring at frames:

DimensionWhat I look forWhat counts as a fail
Prompt fidelityKey constraints obeyed (wardrobe, location, action, mood)Model adds forbidden elements or ignores scene intent
Temporal consistencyIdentity, objects, and layout persistFace morphing, object “teleporting,” background rewrites
Motion qualityMotion matches the shot languageRandom jitter, rubbery physics, unnatural acceleration
Artifact profileSmall defects that don’t distractWarped hands, melting edges, flicker, smeared textures
EditabilityClean enough for timeline cuttingDistracting glitches, text warble, unstable exposure

I also keep a column called “failure mode.” That’s where the real learning happens. If a model fails the same way repeatedly, you can build prompts and shot choices around it.

A Real Workflow From This Week: Stress-Testing Wan 2.2 for Production

When I tested Wan 2.2, I didn’t start with a dramatic cinematic prompt. I started with a clip I could realistically use in a product tutorial: a stable subject, small motion, and a clean background.

Step A: I locked a ground-truth spec (prompt comes later).

Before writing the prompt, I define the scene like a director’s note:

  • Subject: one person (mid-shot), neutral expression
  • Wardrobe: plain, no logos
  • Environment: soft daylight, uncluttered background
  • Motion: slow push-in, subtle head movement
  • Duration: short and loopable
  • Constraints: no sudden lighting shifts, no jump cuts, no added objects

If you skip this step, it becomes too easy to rationalize output that doesn’t match what you actually needed.

Step B: I prompt in layers

I write the prompt in three layers: scene, shot, constraints.
This prevents me from creating “pretty text” prompts that sound cinematic but are impossible to follow.

  • Scene is what’s in front of the camera.
  • Shot is how the camera behaves.
  • Constraints are the guardrails.

I do something else that looks trivial but saves time: I keep constraint phrases consistent across my test suite. That way, when a model fails, I’m not guessing whether the wording caused it.

Step C: I generated six clips—one clip is never enough to judge.

One clip tells you almost nothing because models have variance. Six clips gives you a distribution: you start seeing what failures are rare, and what failures are normal.

Step D: I put on my editor hat and stay ruthless.

I scrub the timeline and pause on “stress moments”:

  • the first second (models often “settle”),
  • any fast motion,
  • transitions in lighting,
  • and any part where text is visible.

My most useful note is usually a single sentence:
“What are the blockers that keep this out of a real cut?”

That’s the difference between research curiosity and production judgment.

Wan 2.2, Unpacked: What I’d Use It For

Here’s the practical insight: Wan 2.2 felt strongest when I treated it like a short-form scene builder, not like a “do everything” model.

  • Short, controlled motion was consistently more usable than chaotic action.
  • Clear camera language (push-in, pan, lock-off) reduced randomness.
  • Clean composition helped preserve subject identity and avoid background rewrite.

When I pushed it into complex, high-entropy scenes—crowds, fast fighting choreography, heavy occlusion—the variance increased. That doesn’t mean “bad”; it means you should choose prompts that match the model’s comfort zone when you’re building dependable workflows.

In a real production pipeline, I’d use Wan 2.2 video model to generate:

  • calm establishing shots,
  • controlled medium shots for explainers,
  • loopable b-roll for tool demos,
  • and stylized scenes where slight imperfections read as “style,” not “error.”

The part people forget: documenting results beats chasing novelty

I keep a tiny “model log” with three fields:

  1. Best-fit use cases (what it nails)
  2. Known failure modes (what it breaks)
  3. Prompt patterns that stabilize output (what I repeat)

After a month, you stop feeling like models are random. You start seeing them as systems with predictable behavior.

If you’re running a team, this log becomes even more valuable than the clips themselves. New teammates can generate in a consistent style on day one, and you don’t waste hours rediscovering the same limits.

A lightweight “go/no-go” rule I rely on

I use a simple gate:

  • If 3 out of 6 clips score ≥4 on editability and temporal consistency, I consider the model production-capable for that prompt category.
  • If not, I keep it in the “experimentation” bucket until I can find a stable pattern.

That rule is deliberately strict. In production, you don’t want a model that succeeds occasionally. You want one that succeeds reliably.

Closing thought: treat video models like datasets, not magic

The biggest mindset shift for me was this: I stopped asking “is this model impressive?” and started asking “is this model predictable under my constraints?”

Once you build a small test suite, your evaluation becomes calmer and more honest. You can still enjoy the creative side, but you’re no longer gambling your time on variance.

And when you find a workflow that consistently produces usable clips—whether with Wan 2.2 or any other model—you’ve done the most valuable thing a creator can do: you’ve turned a flashy demo into a repeatable system.

Free Starter Course • The Data Scientist

Building Autonomous AI & Data Agents with Python

Hands-on engineering course with ReAct agents, MCP tool integrations, and LangChain/CrewAI production patterns.