用途：用一次性代码回答一个设计问题。资料指出，问题决定原型形态，首先要判断要回答的是哪个问题，可从用户提示、周围代码判断，或直接问用户。
两个分支： 1）“这套逻辑/状态模型感觉对吗？”→ LOGIC.md：构建一个可分享的 HTML 文件，包含自由试玩按钮和带标签页的引导式演练，把状态机推过在纸面上难以推理的用例，非开发者也能上手操作。 2）“它应该长什么样？”→ UI.md：在单一路由上生成几个截然不同的 UI 变体，通过 URL 查询参数和底部悬浮栏切换。 两个分支产物截然不同，选错则整个原型白做。若问题模棱两可且联系不上用户，默认选择更贴合周围代码的分支（后端模块→逻辑；页面或组件→UI），并在原型顶部注明该假设。
通用规则：
- 从第一天起就是一次性的并明确标注：原型代码放在靠近实际使用位置（所原型化的模块或页面旁），命名让人一看就知道是原型而非生产代码；一次性 UI 路由遵循项目已有路由约定，不发明新的顶层结构。
- 运行零门槛：UI 原型用项目任务运行器的一条命令启动，如 pnpm <name>、python <path>、bun <path> 等；逻辑演示是双击即可打开的 HTML 文件，启动无需思考。
- 默认不持久化：状态只存内存。持久化恰恰是原型要检验的东西，而非应依赖的东西。若问题明确涉及数据库，用命名清晰的“PROTOTYPE — 用完即删”的临时数据库或本地文件。
- 跳过打磨：不写测试，不做超出“可运行”所需的错误处理，不搞抽象，重点是快速学到东西。
- 把状态摆在明面上：每次操作后（逻辑）或每次切换变体时（UI），打印或渲染完整的相关状态，让用户看到什么变了。
- 完成后留存：把验证过的决策折进真实代码，原型本身作为一手来源留存，提交到 main 之外的一次性分支，并在实现 issue 上留下指向该分支的上下文指引；结论和所解决的问题写进 issue 或一次提交，main 只保留验证过的决策。
限制：资料未提供具体安装命令、平台、收费、价格或效果数据，暂未提供。