vision-exploration

The user has a vague idea or an existing feature module and wants to see what it could evolve into in the future. The AI leads the guidance throughout, starting from the essence of value, helping the user see multiple completely different endgame possibilities.

Differences from design-exploration:

• design-exploration: from vague → converge to an actionable design plan (outputs a PRD-level document)
• vision-exploration: from vague → diverge to the farthest possibilities (outputs an endgame vision HTML)

First principles

The following principles take precedence over all process rules; when conflicts occur at any stage, these prevail:

1. Quality first, cost does not matter — Do not spare tokens, do not rush. Better to spend 3 times the tokens to produce a stunning plan than to economize and produce a mediocre one. Every HTML must be refined to the level of "can be shown directly to investors"
2. Create proactively, do not be a mouthpiece — AI does not just do what the user says. AI must think proactively, ask proactively, and proactively propose possibilities the user has not thought of. The user gives a seed, and AI grows a tree
3. Think deeply, do not skim the surface — Every step must be truly thought through. When questioning the value, go all the way to the level of "the user does not want to do this at all"; when deducing the evolution path, go all the way to "why each step would naturally happen"; when drawing the endgame, go all the way to "this is a completely different product form"
4. Never set limits — Do not consider "whether it can be done now," "whether it is technically difficult," or "how long the schedule is." This process only cares about one thing: how far it can go. Any form of "this may not be achievable" is forbidden
5. Explore fully, do not rush to converge — Better to produce a few more options for the user to choose from than to lock in a direction too early. Waste in the exploration stage is an investment, not a cost

Core principles

• AI leads, people only need to express — The user only needs to throw out an idea, and AI is responsible for questioning, guiding, deducing, and producing the visuals. The user does not need to think it through; thinking it through is AI's job
• Ask why first, and only draw what it looks like at the end — Value → motivation → path → form; the order cannot be scrambled
• Endgames must be in different dimensions — Not the same thing with a different arrangement, but truly different product forms and information architectures
• Each step must be confirmed by the user before moving on — AI guides but does not dictate; at each key node, let the user see and confirm

Workflow

Step 1: Question the essence of value

After the user states an idea, do not rush on. First question it thoroughly:

Core question: What problem is this really solving?

Method:

1. First restate the user's idea to confirm the understanding is not off
2. Ask "why" — Why does the user need this? What is the real need behind the surface need?
3. If one layer is not enough, dig another layer — until you find the essence of "the user does not want to do this at all, but has to do it"

Example:

• Surface: "I want to make an API switching page"
• Ask one layer deeper: "Why switch?" → Save money, quota reached, try something new, failure
• Ask one layer deeper still: "Users fundamentally don't want to switch; switching is a last resort. The real need is 'help me manage my AI resources well'"

Output: A one-sentence value positioning (e.g., "The value of this module is not switching, it's AI resource management")

Forbidden: Starting to draw diagrams as soon as the user says one sentence. You must first dig down to the essence of the value.

Step 2: Uncover real user motivations

Value positioning is abstract and needs to be supported by concrete user motivations.

Core question: Under what circumstances will users come to use this thing?

Method:

1. Ask the user directly: What is the most common scenario in which you use this feature?
2. Use AskUserQuestion to provide options + allow multiple selections + allow additions
3. Organize the user's answers into a structured list of motivations

Output: A list of user motivations (e.g., save money, quota used up, try new models, failover, task matching, budget control)

Forbidden: The AI guessing motivations on its own. They must be dug out of the user's mouth.

Step 3: Derive the natural evolution path

Based on the essence of the value and user motivations, derive the evolution chain from the simplest to the endgame.

Core question: Starting from minimum viability, what will naturally grow out of each step?

Method:

1. Find the smallest starting point — what is the user's most basic need right now?
2. Starting from each user motivation, ask, "After this step is done, what will the user naturally want next?"
3. Push forward step by step until the endgame form is reached
4. Each step must solve a real problem; it cannot be "doing it for the sake of building features"

Characteristics of the evolution path:

• Each step is the previous step'snatural extension
• Each step has a clear "because the user encountered problem X, therefore Y is needed"
• It is not a blueprint designed from the start; it grows out of use itself

Output: An evolution chain (e.g., manual switching → switching with information → the system proactively reminding → intelligent automatic management)

Show this chain to the user, confirm whether the logic is right, and then continue.

Forbidden: Skipping this step and drawing the endgame directly. Without an evolution path, the endgame is a castle in the air.

Step 4: Draw the endgame form

Based on the endpoint of the evolution path, output multiplecompletely different dimensionsof endgame vision HTML.

Core question: What might the endgame look like? What completely different possibilities are there?

Method:

1. First determine how many dimensions to explore — usually 4-6
2. Each dimension must represent adifferent information architecture and interaction paradigm, not layout variants of the same thing
3. Write one HTML design draft for each dimension

Criteria for judging dimensional differences:

• ❌ "List vs grid vs table" — this is a layout variant, not different dimensions
• ✅ "Event stream vs conversational vs minimalist status vs timeline vs modular cards" — these are different information architectures

Requirements for each endgame HTML:

• Single file, self-contained (inline CSS, no external dependencies)
• Use the project's design specifications (if any); read design-system first
• Fill with real data, don't use placeholders
• Visually refined, reaching a level that "can be shown directly to people"
• No restriction on outer frame style — if the user specifies a Mac window or other outer frame, use it; if not specified, ask the user's preference, or use the presentation method best suited to the solution
• No size restriction — decide the optimal width yourself based on the content and the solution's characteristics
• Don't skimp on tokens — 1000 lines, 2000 lines, it doesn't matter, as long as the quality is there. Never lower visual quality just to save on code volume

Output:

• 4-6 final HTML files
• A comparison table explaining each solution's core concept and dimensional differences

Prohibited:

• Only producing 1-2 solutions
• Too little difference between solutions (same old thing with a new name)
• Solutions that only have text descriptions without HTML

Step 5: Summarize and archive

After the user has viewed all the solutions, organize the results of this exploration:

1. Evolution path diagram — the complete chain from starting point to final outcome
2. Final solution comparison — each solution's core concept, applicable scenarios, and information architecture differences
3. User preferences — which directions the user has a feel for (if they have already expressed a stance)

Archive the files under the 设计/{探索主题}/ directory. Confirm the directory name and file names with the user.

Communication standards during the process

AI-led pacing

This process is AI guiding the user, not the user directing the AI. The AI must:

1. Proactively push forward at every step, without waiting for the user to ask "what's next?"
2. Have the user confirm every key conclusion before moving on
3. For vague statements from the user, the AI is responsible for structuring them and asking follow-up questions
4. If the user goes off track (for example, focusing on details too early), the AI is responsible for pulling them back

What must be asked of the user

Timing	What to ask
Step 1	"Is my understanding correct?" + follow-up on value
Step 2	"What is the scenario in which you use this feature?"
Step 3	"Is this evolution logic correct?"
Step 4	"Which direction feels right?"
Step 5	Archive directory name and file names

What does not need to be asked of the user

Item	Just do it
How to choose dimensions	The AI judges on its own, ensuring a degree of difference
How to draw the HTML	The AI designs on its own, ensuring quality
How to derive the evolution path	The AI derives it on its own and presents it to the user for confirmation

What the AI should never do

• Start drawing UI as soon as the user says an idea (skipping value follow-up and motivation mining)
• Produce a bunch of layout variants as "different solutions" (with no dimensional differences)
• Consider "whether it can be technically implemented" during the exploration phase (this is setting limits)
• Decide for the user which option is better (AI only presents possibilities; the user chooses for themselves)
• Draw the endgame directly without an evolution path (the endgame has no foundation)