/prototype 技能

它的作用

prototype writes 回答一个问题的一次性代码 ——这个状态模型感觉对吗，或这个屏幕应该长什么样。问题先行，并决定其后一切的形状；回答错问题的原型无论多好看都是纯浪费。

一次性是对代码「如何」的约束 written，而不是承诺销毁它。没有测试，除了让它跑起来所需的错误处理外没有别的，没有抽象，没有持久化——因为这些都无助于你学到想学的那一件事。存活下来的是答案——它被折叠进真实代码——以及原型本身，停在 main 之外的某个分支上，作为答案来源的证据。

何时使用

输入 /prototype，或这个 agent 任务合适时会自动调用它。

一遇到无法靠讨论解决的问题就用它——一个边界情况装不进脑子的状态机、一个要看到三个版本并排才能想象的屏幕。 审问 会话正是在这些问题上膨胀：智能体重述，你猜测，范围膨胀去填满不确定性。停止 追问审视，构建一次性版本，看看它，然后用一行回答。如果相反，是已构建的东西行为异常而你想知道原因，用 diagnosing-bugs ——原型开发探索构建什么，而不是已构建的东西为什么坏了。

你也会在没主动选择的情况下到达这里。 wayfinder files prototype decision tickets 在地图上，而处理一个正是这个技能。

两个分支

问题选择分支，而分支产出非常不同的产物：

• 「这个逻辑 / 状态模型感觉对吗？」 ——一个 单个可分享的 HTML 文件。一个自包含的页面，无需构建、无需服务器，双击即可打开。它带有一个带标签的状态面板（每次点击后重新渲染）、供你以任意顺序摆弄模型的自由操作按钮，以及带选项卡的 引导式演练 ——每个选项卡一个场景，每个场景下方是依次要按的按钮。一切都用领域语言标注，所以你可以把它交给设计师、PM 或领域专家，让他们亲手感受模型。页面背后的逻辑是一个小纯模块——一个 reducer、一台状态机、一组函数——保持与 DOM 干净分离，让验证过的版本直接升入真实代码。
• 「这应该长什么样？」 ——几个 截然不同 同一条路线上的 UI 变体，可从浮动底栏和 ?variant= URL 参数。变体必须在结构上不同，而不是颜色上；三个微调过的卡片网格是壁纸，不是原型。只要可能，它们就在真实页面中渲染，面对真实数据和真实密度，因为在真空中评判的变体看起来总是很好。

两者都在内存中保持状态，开始时无需思考，并在每一步之后向你展示完整状态。当你发现自己开始加固其中某一个——加测试、接真实数据库、为一个以后可能需要的场景做泛化——你就已经不是在原型开发了。

原型是第一手来源

一个完成的原型留下两样东西，它们去往不同的地方。

这个 answer ——结论加上它解决的问题——被持久捕获：一条提交消息、一份 ADR、实现 issue。这正是 main 分支保留的，折叠进真实代码。

这个 prototype 是可运行的证据，证明答案的来源，而且它不会被删除。它也不属于 main——那里没有什么需要维护，它很快就会腐烂——所以它被提交到一次性 prototype/<name> 脱离 main 的分支，永不合并，带有一个 上下文指针 指向那个留在实现 issue 上的分支。main 保持干净；探索保持可找到、可被下一个接手者重跑。

常见问题

等等——原型不是应该被删除吗？ 不再是了。它以前是：构建它、留下答案、扔掉代码。对那种做法最尖锐的反对从来不是关于速度——而是 下一个接手工作的人 会话，而他们有什么可用的基础？ 原型的文字摘要会失去让它有说服力的东西。所以原型现在被当作 第一手资料：它落在 prototype/<name> 脱离 main 的分支上，实现 issue 指向它。改变的是代码住的地方，不是纪律——它仍然永远不会合并进 main。

它以前构建终端应用。那去哪了？ 逻辑分支现在改为产出单个可分享的 HTML 文件。终端应用只能被克隆了仓库并装了运行时的人操作，而这恰恰排除了原型需要其意见的人——设计师、PM、知道状态模型应该意味着什么的领域专家。一个双击打开、经得起邮件传递的自包含文件，任何人都能操作。底下的纯逻辑模块没有改变，仍然是会升入真实代码的部分。

一个智能体让我 /prototype 在我本该实现的时候。 已知，而且是一个命名问题。 prototype 是一个通用、讨喜的词，对不了解流程的智能体来说，一旦任务存在，它读起来就像「显而易见的下一步」，所以即使设计已在对话中完全敲定，它也会被点名推荐。如果你已经知道要构建什么，下一步是 /implement，每个任务。只有当某个具体的设计问题确实悬而未决、且光靠讨论无法解决时，才使用原型。

在构建任何生产功能之前，我应该先原型化整个应用吗——比如给潜在客户演示？ 那是穿着这个技能名字的另一种产物。这里的原型限定在一个问题，「整个应用是什么」不是一个问题。全应用原型没有自然的停止点，所以它会凭惯性变成生产应用：清理环节永远不会发生，按原型规则写的代码——没有测试、没有错误处理——最终出现在用户面前。如果你需要销售演示，就把它刻意当作演示来构建，并明确说明其中没有生产代码。如果你需要敲定设计问题，把它砍到只剩那个问题。

我怎么在它自己的会话中运行它？ 原型住在自己的目录里，并产生大量 context 你不想留在提问线索里的东西，所以到别处运行，只把答案带回来。 handoff 是双向的桥梁。

这不是烧 Token 的最快方式吗？ 可能是，如果你原型化了本可靠讨论回答的问题，或让一个原型蔓延到整个功能。重要的比较不是 Token 对零，而是 tokens 防止构建错误的状态模型、直到它有了生产环境的调用者才发现。保持问题狭窄、运行简短，花费就始终成比例。

做到以下就算成功

• 你可以用一句话说出原型存在的目的是回答什么问题——而且它写在演示顶部，而不只是在你脑中。
• 不读代码的人也能操作逻辑演示。他们打开文件，在演示选项卡里按按钮，用自己的话描述所见。
• 有人说「等等，那不可能」或「咦，我以为 X」。那是 idea，这正是全部意义所在。
• UI 变体在布局和信息层级上不一致，而不仅仅是颜色和文案——你得到的反馈是「B 的头部配上 C 的侧栏」。
• 它一次坐下就能回答。如果一天后你还在构建它，说明问题太大；把它拆开。
• 结束时，main 包含决策而不包含原型，实现 issue 指向仍然持有它的分支。

在流程中的位置

prototype 是一个 随时可调用的独立技能 ——你切入它敲定一个设计问题，然后退出——它也是另一个技能运行其上的机器。

它最大的消费者是 wayfinder。一张 wayfinder 地图由 决策任务，以及 prototype 是任务可以是的四种类型之一：当阻塞问题是「这应该长什么样」或「这应该如何表现」、任何讨论都无法解决时使用的类型。Wayfinder 通过做出可供回应的具体事物来提高模糊讨论的保真度，而这个技能就是那个具体事物被构建的方式。原型任务由答案解决，原型作为附件从地图链接。

其他邻居在它的上游和下游。 grill-me and grill-with-docs 回答可审问的问题；不可审问的来这里，一行答案再回到审问中去。下游，经过验证的状态模型或 UI 方向会成为 to-spec，它可以直接内联原型产出的富含决策的代码片段，而不是用文字描述。其他情况， ask-matt 为你规划整套流程。