prototype

name	prototype
description	构建一个用完即弃的原型来回答一个设计问题。当用户想要检验某个状态模型或逻辑是否感觉对劲，或探索某个 UI 应该长什么样时使用。

Prototype

原型是回答一个问题的用完即弃的代码。问题决定形态。

选择分支

弄清正在回答的是哪个问题——从用户的提示、周围的代码，或者如果用户在场就直接问：

• "这个逻辑 / 状态模型感觉对吗？" → LOGIC.md。构建一个微型交互式终端应用，把状态机推过那些在纸面上难以推理的用例。
• "这东西应该长什么样？" → UI.md。在单个路由上生成若干截然不同的 UI 变体，通过一个 URL 查询参数和一个浮动底栏来切换。

这两个分支产出的产物差别极大——选错了会浪费掉整个原型。如果问题确实含糊、且用户联系不上，就默认选择更契合周围代码的那个分支（后端模块 → 逻辑；页面或组件 → UI），并在原型顶部声明这个假设。

两者都适用的规则

1. 从第一天起就用完即弃，并明确标注为此。 把原型代码放在它实际会被使用的地方附近（紧挨着它为之做原型的模块或页面），这样上下文一目了然——但给它起个名字，让随便看一眼的读者就能看出这是原型、不是生产代码。对于用完即弃的 UI 路由，遵循项目已在用的任何路由约定；不要发明新的顶层结构。
2. 一条命令即可运行。 项目既有任务运行器支持什么就用什么——pnpm <name>、python <path>、bun <path> 等。用户必须能不假思索地启动它。
3. 默认不持久化。 状态存在内存里。持久化正是原型要检验的东西，而不是它应该依赖的东西。如果问题明确涉及数据库，就用一个临时的 scratch 数据库或一个带清晰"PROTOTYPE — wipe me"名字的本地文件。
4. 跳过打磨。 不写测试，不做超出让原型可运行所需的错误处理，不搞抽象。重点是快速学到东西。
5. 暴露状态。 每个动作之后（逻辑）或每次变体切换时（UI），打印或渲染全部相关状态，好让用户看到发生了什么变化。
6. 完成后沉淀它。 把任何经过验证的决策融入真实代码，然后把原型本身作为一份一手来源沉淀下来：把它提交到一个用完即弃的分支、置于 main 之外，并在实现 issue 上留一个指向该分支的上下文指针。也把答案沉淀下来——结论以及它所敲定的那个问题——记在 issue 或一次提交里。main 分支只保留经过验证的决策。