原型

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

挑一个分支

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

• 「这个逻辑 / 状态模型感觉对吗？」 → LOGIC.md。构建一个单一的可分享 HTML 文件——自由玩耍按钮加上带标签页的引导式演练——把状态机推过那些在纸上难以推理的情形，而且非开发者也能驱动它。
• 「这该长什么样？」 → UI.md。在单个路由上生成若干截然不同的 UI 变体，通过一个 URL 查询参数和一个浮动底栏切换。

两个分支产出非常不同的产物——搞错了会浪费整个原型。如果问题确实含糊而用户又联系不上，就默认走与周围代码更匹配的那个分支（后端模块 → 逻辑；页面或组件 → UI），并在原型顶部陈述这个假设。

两个分支都适用的规则

1. 从第一天起就用完即弃，并明确标注为如此。 把原型代码放在它实际会被用到的地方附近（挨着它在为之做原型的那个模块或页面），这样上下文一目了然——但给它起个名，让随意的读者一看就知道这是原型、不是生产代码。对于用完即弃的 UI 路由，遵循项目已有的路由约定；不要发明新的顶层结构。
2. 运行起来轻而易举。 一个 UI 原型从项目任务运行器里的一条命令启动——pnpm <name>、python <path>、bun <path> 等。一个逻辑演示是一个用户双击的单 HTML 文件。无论哪种方式，启动它都不用动脑子。
3. 默认不持久化。 状态活在内存里。持久化是原型在核实的东西，不是它该依赖的东西。如果问题明确涉及数据库，就打到一个临时数据库或本地文件，起个明确的「PROTOTYPE — wipe me」名字。
4. 跳过打磨。 没有测试，除了让原型可运行所必需的之外没有错误处理，没有抽象。重点是快速学到点东西。
5. 让状态浮现。 每次 action（逻辑）之后，或每次变体切换（UI）时，打印或渲染全部相关状态，让用户看到变了什么。
6. 完成后捕获它。 把任何经过验证的决策折叠进真实代码，然后把原型本身作为一份一手来源捕获：把它 commit 到一个主线之外的用完即弃分支，并在实现工单上留一个指向那个分支的上下文指针。也捕获答案——那个结论以及它所定夺的问题——记在工单或一个 commit 里。主分支只保留经过验证的决策。