Doubao turns a game prompt into a mini arcade

I break down a one-hour Doubao build and give you a copy-ready prompt flow for turning rough ideas into a playable mini arcade.

I've been doing AI-assisted coding long enough to know when a workflow is lying to me. The code looks fine, the demo runs, and then I try to extend it and everything turns into glued-together guesses. That’s exactly why this Zhihu post caught my eye. The author describes building a retro “4399-style” mini game collection in about an hour with Doubao, but the part I care about is not the nostalgia. It’s the process: take a messy idea, clean it up with a text model, then hand that cleaned brief to the coding model. I’ve used that same trick with DeepSeek, Doubao, and code assistants like Cursor, and it keeps saving me from the usual “why did the model invent this weird edge case” nonsense.

The author’s own habit is simple: let a text-first model shape the requirements into a clear prompt before sending it to the coding model. That sounds almost boring. It isn’t. It’s the difference between asking for “a fun game site” and asking for a menu-driven arcade shell with specific game cards, interaction rules, and a pace the model can actually follow. The original post is on Zhihu, and it connects directly to a pattern I keep seeing in real projects: the better the brief, the less the model hallucinates confidence.

Stop feeding code models your raw chaos

“I usually ask a text-oriented model, like DeepSeek, to organize the requirements into a structured prompt first, then feed that into the code model.”

What this actually means is: I should stop pretending the coding model is also my product manager. It can write decent code, but it is terrible at reading my half-baked notes and inferring product intent without drifting. When I give it a rough brain dump, it fills the gaps with whatever seems plausible. That’s how you get a game launcher that looks cute for five minutes and then becomes a maintenance headache.

I ran into this while building small internal tools. I’d ask for “a dashboard with filters and export,” and the model would give me a Frankenstein UI with inconsistent state handling. Once I switched to a two-step flow, the output got much less random. First I had the text model rewrite my notes into a clean spec. Then I gave that spec to the code model. Suddenly the assistant stopped freelancing.

How to apply it: keep a dedicated “prompt cleaner” step in your workflow. Don’t skip it because you’re impatient. If your idea is messy, let a text model turn it into sections: goal, users, screens, interactions, constraints, and output format. Then send only that cleaned version to the coding model. If you want to do this manually, even a simple checklist works better than a raw paragraph.

• Goal: what the app should do in one sentence
• Scope: what is included and what is explicitly out
• UI: what screens or components must exist
• Logic: what should happen on click, submit, or load
• Constraints: framework, style, performance, and file structure

Make the model build a shell, not a pile of features

The post is about a mini game collection, and that matters because collections are easier to reason about than one giant “make me a fun website” request. A shell gives the model a skeleton: a home screen, a game list, a consistent layout, maybe a few placeholder game cards. Once that exists, each game can be added as a separate unit instead of one giant blob of logic.

What this actually means is that I should ask for structure before I ask for polish. I’ve wasted too much time telling a model to “make it interactive” when I hadn’t even defined the navigation model. The result is always the same: flashy UI, weak architecture. If I start with a shell, the assistant has rails to follow.

I saw this again when I tried to prototype a small browser game hub. The first pass looked impressive, but every button was wired in a slightly different way. The second pass, where I forced the model to produce a layout-first scaffold, was much easier to extend. The rough edges moved from the core to the periphery, which is where they belong.

How to apply it: ask for a minimal app frame before any game logic. In practice, that means a title bar, a category panel, a content area, and a predictable card component. Tell the model to leave game internals as placeholders if necessary. You want the app to feel complete enough to navigate, but not so overbuilt that every new game requires surgery.

• Use one shared layout for all game entries
• Keep each game in its own component or module
• Separate navigation state from game state
• Prefer placeholders over invented mechanics

Retro nostalgia works because the rules are obvious

The “4399-style” framing is not just marketing nostalgia. It gives the model a recognizable interaction pattern: browse a list, click a game, play immediately, switch back, repeat. That familiarity is useful because it narrows the space of possible UI decisions. The model doesn’t need to invent a new product category. It just needs to recreate a familiar one cleanly.

What this actually means is that recognizable references are a design shortcut, not a crutch. If I say “make it feel like a classic game portal,” I’m not asking for plagiarism. I’m giving the model a shared mental image. That reduces ambiguity, which is the real enemy here. Ambiguity is where models start guessing.

I’ve used this trick with admin panels too. Saying “make it feel like a spreadsheet-heavy internal tool” gets me better results than saying “make it professional.” One phrase is concrete. The other is a shrug. The Zhihu post uses nostalgia the right way: not as decoration, but as a constraint.

How to apply it: anchor your prompt to a known interaction pattern. Use references the model can map to structure, like “classic arcade launcher,” “mobile app grid,” or “simple game portal.” Then immediately define what must be different in your version. That keeps the reference useful instead of letting the model drift into imitation mode.

Prompt cleanup is the real time saver

The author says the text-model pass only costs a couple of extra minutes, but saves multiple rounds of rework. That matches my experience almost exactly. The first prompt is rarely the one I actually want. It’s usually too vague, too broad, or stuffed with assumptions I didn’t notice I was making.

What this actually means is that prompt editing is not overhead. It is part of the build. I used to think I was being efficient by skipping the cleanup step. I wasn’t. I was just moving the cost downstream, where it became debugging, rewriting, and arguing with the model about what I meant. That is a terrible use of time.

When I started treating prompt cleanup like a normal engineering step, my iterations got shorter. I’d have the text model turn my notes into a spec, then I’d ask it to tighten the wording again if needed. Only after that did I send the prompt to the coding model. The output became less clever and more usable, which is exactly what I want.

How to apply it: create a reusable prompt-cleaning pass. You can even make the text model answer in a fixed format so the coding model gets consistent input every time. The key is repeatability. If each request arrives in a different shape, the code model has to relearn your intent from scratch.

1. Raw idea dump from me, no cleanup yet.\n2. Text model rewrites it into a structured spec.\n3. I review the spec and remove anything vague.\n4. Code model implements only what is in the spec.\n5. I ask for fixes in small, isolated changes.

Why one-hour demos fail unless you control scope

A one-hour build sounds fast, and it is, but only if the scope is brutally controlled. The moment you let a mini arcade request expand into “add more games, animations, scoring, and responsive polish,” the clock is gone. The post works because the target is narrow enough to finish. That’s the part people skip when they copy the idea.

What this actually means is that speed comes from saying no early. I’ve watched too many quick demos die because the creator wanted one more feature. By the time that feature is in, the original flow is broken and the whole thing needs another pass. The author’s workflow avoids that by keeping the build bounded.

I’ve had better results when I define a “demo ceiling” before I start. For example: one homepage, three games, one shared theme, no backend, no account system, and no custom animation system unless it’s trivial. That sounds restrictive, but it keeps the model honest. If the model can’t fit the request inside the box, the box was wrong.

How to apply it: write your scope as a list of hard limits before prompting. Don’t just list features. List exclusions too. That gives the coding model a fence line. Without it, the assistant will keep adding nice-looking extras that cost you time later.

• Maximum number of screens
• Maximum number of interactive states
• No backend unless explicitly requested
• No extra libraries unless they solve a real problem

The best prompts read like specs, not vibes

This is the part I keep coming back to. The author’s workflow works because it moves from vibe to specification. A good spec is not fancy. It is plain, direct, and hard to misunderstand. That is exactly what code models need. They are not mind readers, and they are definitely not good at decoding “make it feel nostalgic but modern.”

What this actually means is that prompt quality matters more than prompt length. A short, structured brief beats a long, emotional one almost every time. I’d rather give a model six bullet points than one paragraph of enthusiasm. The bullets are actionable. The enthusiasm is noise.

I’ve seen this in team settings too. The tickets that get implemented fastest are the ones with concrete acceptance criteria. AI coding tools are the same. They just expose the weakness faster. If your prompt would be rejected in a decent engineering review, it will probably produce junk code too.

How to apply it: write prompts the way you’d write a task for another engineer. Include output format, behavior, and boundaries. Ask for the result in a way that makes missing pieces obvious. If you need the assistant to think in layers, say so. If you need it to preserve existing structure, say so. If you need it to avoid inventing features, say so twice.

The template you can copy

Title: Build a retro mini game hub with a clean prompt workflow

Goal:
Create a browser-based mini arcade inspired by classic game portals. The app should feel nostalgic, simple to navigate, and fast to demo.

Workflow:
1. Use a text model first to clean up the raw idea into a structured spec.
2. Use a coding model second to implement only what appears in the spec.
3. Keep changes small and review each step before adding more features.

Product requirements:
- One homepage with a visible game list
- Shared layout for all games
- Each game opens from a card or button
- Easy way to return to the hub
- No backend required
- No login or account system
- No extra features unless explicitly requested

Design rules:
- Keep the interface simple and familiar
- Use a retro arcade feel without copying any specific brand assets
- Prefer clear navigation over flashy effects
- Make the shell first, then add game logic one piece at a time

Prompt-cleaning instruction for the text model:
Rewrite the raw idea into a structured implementation brief with these sections:
- Objective
- User flow
- UI structure
- Game list behavior
- Constraints
- Output format

Implementation instruction for the code model:
Build only the approved spec. If any requirement is vague, ask for clarification instead of inventing details. Return code in small, reviewable chunks.

Copy-ready prompt to send to the text model:
"Rewrite the following idea into a concise implementation brief for an AI coding model. Keep it structured, specific, and free of vague language. Include objective, user flow, UI structure, constraints, and output format. Raw idea: [paste idea here]"

Copy-ready prompt to send to the code model:
"Implement the following spec exactly. Do not add features that are not listed. If anything is ambiguous, stop and ask a question before coding. Spec: [paste cleaned brief here]"

The original idea comes from the Zhihu post at https://zhuanlan.zhihu.com/p/2069733955432079942. My breakdown is original, but the workflow pattern is directly inspired by the author’s prompt-first approach.