choosing-prototype-formlisted

# Choosing Prototype Form ## Core Rule The prototype form is chosen by what is still uncertain, not by what the tool can generate. Exploration-stage uncertainty (product shape, layout, user path) → HTML. Converged-direction validation (interaction, state flow, API behavior, edge states) → React Mock. Implementation-path uncertainty → written spec first, no prototype yet. A prototype of either form is never production code, and its fields are never frozen API contracts. "It runs" proves nothing about "it ships". ## Selection Table | Situation | Choice | Why | |---|---|---| | Product shape undecided | Text flow + HTML | Validate direction fast; avoid premature engineering | | Layout / user path undecided | HTML | Cheap to change, good for frequent restructuring | | Technical implementation path undecided | Spec document, no React yet | A runnable prototype gets mistaken for a technical decision | | Direction converged | React Mock | Validates interaction, state, and data-link behavior | | Formal customer demo | React Mock | Clickable full paths; HTML demos die at "点不了、跳不了、状态变不了" | | Handing to engineers for task breakdown | React Mock + delivery doc | Yields draft API contracts and component inventory | | HTML prototype already exists | Rebuild as React Mock, never convert | See Anti-Pattern below | | Early customer requirement talks | HTML | Customers judge entrance, flow, and information — not state machines | ## Anti-Pattern: Mechanical HTML → React Conversion Convert