prototype

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

原型（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. 完成后把它归档保存。 把任何已验证的决策折叠进真实代码，然后把原型本身作为 一手资料（primary source） 保存下来：把它提交到一个用完即弃的分支上、不进主干，并在实现 issue 上留一个指向该分支的上下文指针。也把答案保存下来——结论以及它所解决的问题——记在 issue 或提交里。主干只保留经过验证的决策。