用途：在正式确定设计前，用一次性的可丢弃代码回答一个具体问题。问题决定原型的形态。
分流两条分支：若问题是“这套逻辑/状态模型是否合理”，走 LOGIC.md，构建一个小型交互式终端应用，把状态机推到难以纸上推理的场景中运行；若问题是“它该长什么样”，走 UI.md，在单个路由上生成多个差异明显的 UI 变体，通过 URL 搜索参数和底部浮动栏切换。两条分支产物差异很大，选错会浪费整个原型。若问题确实模糊且联系不上用户，默认选择与周边代码更匹配的分支（后端模块走逻辑，页面或组件走 UI），并在原型顶部注明该假设。
共同规则：从第一天起就是可丢弃的，并明确标注；原型代码放在实际会被使用的位置附近（模块或页面旁），命名让普通读者能看出它是原型而非生产代码；可丢弃 UI 路由遵循项目已有路由约定，不要新造顶层结构。一条命令即可运行，使用项目现有任务运行器支持的形式，如 pnpm <name>、python <path>、bun <path> 等，用户无需思考。默认不做持久化，状态放在内存中；持久化本身是原型要检验的对象，而不是它应依赖的东西。若问题明确涉及数据库，则使用临时库或命名为“PROTOTYPE — wipe me”的本地文件。跳过打磨：不写测试，不做过多的错误处理与抽象，重点是快速学到东西然后删除。暴露状态：每个动作后（逻辑）或每次变体切换时（UI）打印或渲染全部相关状态，让用户看到变化。完成后删除或吸收：问题得到回答后，要么删除原型，要么把已验证的决策并入真实代码，不要让它在仓库里腐烂。
完成时：原型唯一值得保留的是答案。把它连同所回答的问题记录到持久位置（提交信息、ADR、issue，或原型旁的 NOTES.md）。若用户在场，可快速对话确认；若不在，留占位符，供其或下次再填上结论后再删除原型。
限制：官方文本未提供具体平台、收费、价格与效果信息；分类依据其明确的逻辑验证与 UI 变体原型用途。