prototype

工程开发社区 @mattpocock

信任分: 88/100
兼容 Agent: 1

速查档案只列事实：领域、Agent、信任分、作者、原文章节。装与不装请看下方作者解读。

领域: 工程开发
兼容 Agent: Claude Code
信任分: 88 / 100 · 社区维护
作者 / 版本 / 许可: @mattpocock · 未声明 license
安装命令数: 1 条

需要注意： 未限定 allowed-tools，默认拥有全部工具权限。

解读由编辑根据原文凝练而成，命令、链接、术语均与作者原文一致；想看完整论述请切到右侧

设计思路

prototype 是 mattpocock 的「快速原型」skill——把「我们应该怎么做」拆成两个分支问题：逻辑 / 状态模型（用 LOGIC.md：建一个小交互终端 app 把状态机推过那些纸上很难推的 case）vs 视觉 / UI（用 UI.md：在单一路由上同时生成多套激进不同的 UI，通过 URL search param + 浮动底栏切换）。走错分支会浪费整个 prototype——所以要先选对枝。

选枝原则

"logic / state model 对不对？" → LOGIC.md
"这玩意应该长什么样？" → UI.md
真模糊且联系不上用户 → 看周围代码默认（后端模块 → logic；页面 / 组件 → UI），并把假设写在 prototype 顶部

两枝共用规则

从第一天起就是 throwaway，并显式标记：放在它要被用的地方旁边（让 context 清楚），但命名让随便看的人都能看出来「这是 prototype，不是生产」。throwaway UI 路由遵循项目既有路由约定，别造新顶层结构。
One command to run：用项目现有 task runner（pnpm <name> / python <path> / bun <path>）——用户不动脑就能跑。
No persistence by default：状态住内存里。持久化是 prototype 在测的东西，不是它该依赖的东西。如果问题确实涉及 DB，挂临时 scratch DB / 本地文件，名字明确写「PROTOTYPE — wipe me」。
Skip the polish：不写测试、不超出「能跑」的错误处理、不抽象——目的是快速学到东西然后删掉。
Surface the state：每次动作（logic）后或每次切换（UI）时把相关完整状态打印 / 渲染出来——用户能看见到底变了啥。
Delete or absorb when done：prototype 答完问题后要么删要么吸进真实代码——别让它在仓库里腐烂。

When done

答案才是 prototype 留下的唯一价值。 把它沉淀到 commit message / ADR / issue / prototype 旁边的 NOTES.md，连同它在回答的问题。删 prototype 之前，把 verdict 写下来。

适合谁

拿不定主意「先做 A 还是先做 B」希望靠跑一把代码学到答案的工程师
设计阶段验证状态机 / UI 假设的人
想用代码替代纸上推演但不想被生产代码标准拖慢的快速决策

何时不该用

答案已经清楚——直接写
写到一半就忘了删——prototype 的反模式

配套

brainstorming（前置）、design-an-interface（接口形状专门版）、design-shotgun（UI 多版本探索的视觉版）、writing-plans（prototype 答完之后正式落实施）。

Prototype

A prototype is throwaway code that answers a question. The question decides the shape.

Pick a branch

Identify which question is being answered — from the user's prompt, the surrounding code, or by asking if the user is around:

"Does this logic / state model feel right?" → LOGIC.md. Build a tiny interactive terminal app that pushes the state machine through cases that are hard to reason about on paper.
"What should this look like?" → UI.md. Generate several radically different UI variations on a single route, switchable via a URL search param and a floating bottom bar.

The two branches produce very different artifacts — getting this wrong wastes the whole prototype. If the question is genuinely ambiguous and the user isn't reachable, default to whichever branch better matches the surrounding code (a backend module → logic; a page or component → UI) and state the assumption at the top of the prototype.

Rules that apply to both

Throwaway from day one, and clearly marked as such. Locate the prototype code close to where it will actually be used (next to the module or page it's prototyping for) so context is obvious — but name it so a casual reader can see it's a prototype, not production. For throwaway UI routes, obey whatever routing convention the project already uses; don't invent a new top-level structure.
One command to run. Whatever the project's existing task runner supports — pnpm <name>, python <path>, bun <path>, etc. The user must be able to start it without thinking.
No persistence by default. State lives in memory. Persistence is the thing the prototype is checking, not something it should depend on. If the question explicitly involves a database, hit a scratch DB or a local file with a clear "PROTOTYPE — wipe me" name.
Skip the polish. No tests, no error handling beyond what makes the prototype runnable, no abstractions. The point is to learn something fast and then delete it.
Surface the state. After every action (logic) or on every variant switch (UI), print or render the full relevant state so the user can see what changed.
Delete or absorb when done. When the prototype has answered its question, either delete it or fold the validated decision into the real code — don't leave it rotting in the repo.

When done

The answer is the only thing worth keeping from a prototype. Capture it somewhere durable (commit message, ADR, issue, or a NOTES.md next to the prototype) along with the question it was answering. If the user is around, that capture is a quick conversation; if not, leave the placeholder so they (or you, on the next pass) can fill in the verdict before deleting the prototype.