抛原型

解决什么问题

纸上推演状态机和 UI 总有推不动的角落。逻辑上，你画了订单状态图，但「部分发货后再退款」该落到哪个状态，画稿自己互相打架；UI 上，「用户到底在购物车里点哪里」评审来回改十版，谁也没看过它真跑起来的样子。更糟的是这类探索很容易滑进主分支——为了「先跑通看看」，给探索代码补上测试、异常处理和抽象层，最后它变成没人敢删的代码。

抛原型把这类验证固定成一套一次性流程：先锁定要回答的那个问题，写一份答完即弃的代码，验证完把决策折进真实代码，原型本身丢进 throwaway 分支当一手资料。

它是怎么工作的

第一步是选分支，这一步决定整次原型的形状，选错等于整次报废：

• 逻辑分支——问题是「这个状态模型手感对吗？」，就建一个微型交互终端程序，把状态机推过那些纸上难以推理的 case
• UI 分支——问题是「它该长什么样？」，就在单一路由上生成差异巨大的多个 UI 变体，用 URL 参数加浮底栏切换

问题真的模糊、且用户不在时，默认选更贴合周边代码的那一支：后端模块走逻辑，页面或组件走 UI，并在原型顶部注明这个假设。

两分支通用的六条规则：

• 从第一天起就明显标注一次性，放在实际会用到它的位置附近以便理解上下文，但命名要让 casual reader 一眼看出是原型
• 一条命令可跑，沿用项目既有的 task runner，例如 bun prototype/order-fsm.ts
• 默认不持久化，状态只在内存里；问题确实涉及数据库时用 scratch DB，或标了 PROTOTYPE — wipe me 的本地文件
• 跳过润色：不写测试，不做超出「能跑」范围的错误处理，不做抽象
• 暴露状态：每次动作或每次变体切换后，打印或渲染完整的相关状态
• 做完即捕获：验证过的决策折进真实代码，原型提交到主分支之外的 throwaway 分支，并在实现 issue 上留下指回该分支的指针

输入是设计疑问，可接收 DesignQuestion 工件；输出是 PrototypeResult（含 branch、question、verdict、decision_captured、artifact_ref）。验证后的决策可以交给 to-spec / implement 落地，grill-with-docs 也能引用原型当一手资料。

适用边界

原型不是生产代码。它不进主分支，不写测试，不做超出可跑程度的错误处理。真正进主分支的只有验证之后的那个决策，不是原型本身。也不要拿它做集成验证、性能压测或数据迁移演练——那些问题需要的是真实系统，不是一次性代码。