prototype

原型

原型是用于回答问题的一次性代码。问题决定原型的形式。

选择分支

确定要回答哪个问题——从用户的提示、周边代码中判断，或者在用户在线时直接询问：

• “这个逻辑／状态模型感觉对吗？” → LOGIC.md。构建一个小型交互式终端应用，让状态机经历那些难以纸上推演的情况。
• “它应该是什么样子？” → UI.md。在单一路由上生成多个截然不同的 UI 变体，并通过 URL 搜索参数和浮动底栏切换。

这两个分支会产出截然不同的成果——选错分支会让整个原型白费。如果问题确实模棱两可，而且联系不上用户，就默认选择更符合周边代码的分支（后端模块 → 逻辑；页面或组件 → UI），并在原型开头说明这一假设。

两种分支均适用的规则

1. 从第一天起就按一次性代码处理，并明确标记。 将原型代码放在靠近实际使用位置的地方（放在原型所针对的模块或页面旁边），让上下文一目了然——但命名时要让普通读者看出这是原型，而非生产代码。对于一次性 UI 路由，遵循项目已有的路由约定；不要另创顶层结构。
2. 一条命令即可运行。 使用项目现有任务运行器支持的命令，例如 pnpm <name>、python <path>、bun <path> 等。用户不必费心就能启动。
3. 默认不做持久化。 状态保存在内存中。持久化才是原型要检验的内容，不应成为原型的依赖。如果问题明确涉及数据库，就使用临时数据库或本地文件，并采用清晰的“PROTOTYPE — wipe me”名称。
4. 省去精修。 对一次性脚手架，省去测试基础设施和精修；但仍要检验原型旨在回答的问题。要投入生产的逻辑需要采用项目常规的测试和错误处理。重点是快速获取经验，然后删除原型。
5. 展示状态。 每次操作后（逻辑原型）或每次切换变体时（UI 原型），都打印或渲染完整的相关状态，让用户看到发生了什么变化。
6. 完成后删除或合并。 用户审阅结果后，应商定是删除原型，还是将经过验证的决策融入实际代码——不要让它在代码仓库中逐渐腐坏。

完成之后

原型唯一值得保留的是它的_答案_。将答案和它所回答的问题一起记录在某个持久位置（提交说明、ADR、Issue，或原型旁边的 NOTES.md）。如果用户在线，这可以通过简短对话完成；如果联系不上，就留下占位内容，让他们（或下次继续处理的你）在删除原型前填写结论。