prototype

原型

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

选择分支

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

• “这套逻辑／状态模型感觉对吗？” → 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. 呈现状态。 逻辑原型在每次操作后、UI 原型在每次切换变体时，打印或渲染完整的相关状态，让用户看清发生了什么变化。
6. 完成后留档。 将所有已验证的决策落实到实际代码中，然后将原型本身作为一手资料留档：将其提交到一次性分支，而非 main，并在实现问题单中留下指向该分支的上下文链接。也要在问题单或提交记录中记录答案——包括结论及其解决的问题。main 分支只保留已验证的决策。

---

改编自 mattpocock/skills，MIT © 2026 Matt Pocock。复制此文件时请保留此行。