prototype

原型

构建一个可丢弃的原型，用来回答一个问题。原型本身不是要交付的功能，唯一必须保留下来的是答案。

在原型说明或最终回复的开头，说明：

• 要回答的问题。
• 分支：逻辑或 UI。
• 如果分支选择存在歧义，说明采用的假设。
• 什么结果会让原型发挥作用。

选择分支

不同分支会产出不同的成果。选错分支会让原型白费。

• 逻辑分支：用于状态机、领域模型、算法、API 结构、解析、验证、持久化行为或业务规则。
• UI 分支：用于屏幕、组件、视觉层级、交互模型、内容布局或产品流程对比。

如果问题确实存在歧义，且无法联系到用户，默认选择与周边代码相符的分支：后端／模块问题使用逻辑分支；页面或组件问题使用 UI 分支。开始构建前说明所采用的假设。

通用规则

• 将工作隔离在仓库的临时／原型约定目录中。如果没有此类目录，优先使用 docs/prototypes/<slug>/、prototype/<slug>/ 或其他明确可丢弃的本地目录。
• 除非问题只能在真实应用外壳中回答，否则不要修改生产路径。如果必须修改生产路径，确保 diff 易于删除。
• 尽可能使用现有运行时和任务运行器。
• 确保原型可通过一条命令运行。
• 除非问题涉及持久化，否则将状态保存在内存中。如果问题涉及持久化，则使用临时数据库或本地文件，并明确命名为 PROTOTYPE-wipe-me。
• 避免引入大量新依赖。只有在某个依赖能直接回答问题且易于移除时才添加。
• 将答案记录在某个可长期保存的位置：最终回复、父级工单、父级规范、ADR，或原型旁边的 NOTES.md。

逻辑分支

构建能体现行为的最小可运行模型：

• 使用终端脚本、单元测试风格的测试框架、REPL 命令、样例数据运行器或小型本地服务。
• 在原型中直接编码重要状态、转换、不变量和失败场景。
• 使用真实的样例数据，但保持小规模且限于本地。
• 打印或断言能回答问题的场景。
• 一旦模型证明或否定了设计，就停止；不要围绕它构建 UI。

逻辑分支应让隐藏行为显现出来。优先选择清晰的运行记录或测试输出，而非精致的展示效果。

UI 分支

构建多个有实质差异的方案，而不是一个精致的模型：

• 将不同方案放在同一路由、页面或本地预览界面中。
• 使用标签页、切换开关、查询参数或分段控件在不同方案之间切换。
• 除非问题专门涉及实时数据行为，否则在本地模拟数据。
• 如果有助于比较，复用应用现有的组件、样式 token 和布局约定。
• 如有可用的浏览器或预览环境，请在其中验证原型。

UI 分支应能快速呈现权衡。优先选择能回答设计问题的差异化方案，而不是细微的视觉调整。

输出

报告：

• 原型路径和运行命令。
• 使用了哪个分支，以及原因。
• 从原型中得出的答案。
• 哪些内容应保留、丢弃或转为生产工作。
• 仍存在的任何不确定性。

如果用户要求从探索转入实现阶段，请删除原型或将其标记为可丢弃。