产品原型 Skill 71.1 万次安装，三版只回答一个问题

同一张产品页交给 Agent 做三版，最容易拿到的不是三种方案，而是三张颜色不一样的卡片网格。

prototype 这个 Skill 正好盯着这个毛病。抓取时，skills.sh 页面显示 71.14 万次安装，它所在的 mattpocock/skills 仓库有 24.59 万 GitHub Star。安装只有一行。

npx skills add https://github.com/mattpocock/skills --skill prototype

调用也不绕。

Use prototype for this project creation page.
Answer one question only.
Should goal, context, or user scenario appear first?
Build three structurally different variants on the same route.

熟悉任务、公开热度、安装命令、调用方式，都在这儿了。可我真正想聊的不是它能多快出图，而是它在第一句里写得很硬的定义，原型是回答一个问题的一次性代码。

抓取时页面显示 711.4K 安装、245.1K Star，安装量只证明注意力，不替效果背书。

这句话挺刺耳。很多团队嘴里说做原型，手上做的却是便宜一点的正式版。数据库接了，权限补了，异常处理写了，顺手再抽象两个组件。两天后大家还没决定入口放左边还是右边，代码已经舍不得扔。

好家伙，原型还没回答问题，先拿到了永久居留权。

先把问题写窄，才轮到画页面

官方总规则把任务分成两条路。

问「这个状态模型走得通吗」，做逻辑原型。问「这个页面该长什么样」，做 UI 原型。一个问题若同时混着流程、视觉、权限和数据结构，先选最影响下一步决定的那一个，别让原型替整个产品开会。

我按 UI 分支的公开规则做了一次同输入对照。示例任务是设计一个 AI 项目创建页，只回答一句，用户进来时，目标、上下文、使用场景，哪个应该先出现？

三版共用同一份产品目标、仓库名和约束，没有拿文案差异作弊。

A 版把一句话目标放在中央，右边自动挂上产品说明、设计约束和验收证据。它适合意图已经清楚，只是资料散在各处的任务。

A 版不是把按钮涂成红色，而是把主操作换成一句话目标。

B 版把上下文放到左侧，中央逐条确认用户卡点、系统限制和视觉约束，右边才生成拟定变更。它逼着团队先承认旧系统真实存在，没法把一个已经有权限、数据和组件的产品当白纸画。

B 版先讨论哪些条件不能丢，再决定页面要改什么。

C 版干脆不从页面区块开始。第一次创建、从模板开始、复制现有项目三种进入方式被摆在一张表里，主操作变成「设为主路径」。这版回答的是用户从哪里进入，不急着回答卡片怎么排。

C 版把讨论从页面好不好看，挪到哪条用户路径应该赢。

三张截图未必有一张能直接上线，这反而是好事。它们真的在争论三件不同的事。目标优先让意图最短，上下文优先减少脱离现实，场景优先帮团队选主路径。

把这次实验的前后变化摊开看，会更清楚。

之前的任务通常只写「给项目创建页做三套方案」。Agent 很听话，复制同一个布局，换一组颜色，挪两个按钮，再交三张静态图。评审的人能看到结果，却看不到每套方案在坚持什么。讨论很快滑向红色还是蓝色、圆角要大还是小，半小时过去，入口到底服务谁仍然没人回答。

之后的任务顶部多了一句可被推翻的问题，三版共用数据，各自押注一种信息顺序。链接可以单独分享，评审意见也能落到具体方案上。产品可以说 B 的限制太抢，设计可以拿 C 的路径层级，工程可以指出 A 的自动上下文实现代价太高。大家争的从视觉偏好变成产品选择。

它没有替团队做决定，只把原来藏在脑子里的分歧变成了能点、能看、能留下证据的东西。

如果三版只差配色，评审现场只能说我喜欢蓝色。结构真不一样，产品、设计和工程才有东西可反驳。有人会说入口必须从已有项目继承，有人会发现模板其实只服务老用户，还有人会坚持新用户只该看到一个输入框。

这才叫原型。

可分享链接，比三张静态图更有用

这次产物不是三张互不相干的 HTML。它们在同一路由里通过 ?variant=A、?variant=B、?variant=C 切换，底部有一个临时方案切换器，左右方向键也能换版。

我把可验收的部分跑了一遍。三套方案都能独立渲染，左右键可以循环，空状态和错误状态存在，暗色模式能读，390px 手机宽度没有横向溢出，控制台没有报错。

variants A / B / C      passed
keyboard left / right   passed
empty / error states    passed
dark mode               passed
mobile 390px            no horizontal overflow
console errors          0

这组数据不能证明哪一版产品判断最好。浏览器测试只证明评审材料能打开、能切、能在常见状态下继续看。产品答案仍然要由真实用户、设计师、工程师和业务约束决定。

官方规则里有个细节我很喜欢，UI 原型优先嵌在已有页面，而不是新建一张真空白纸。真实页头、侧边栏、数据密度和权限都留着，只替换要比较的那棵渲染子树。单独拿出来时每版都挺顺眼，一旦塞回旧系统，谁挤、谁抢、谁说不清主次，立刻现形。

坦率讲，这比再加一条「更高级、更有设计感」的提示词实在。后者得到的是审美形容词，前者得到的是可争论证据。

逻辑原型是另一条路，别混着做

如果真正没想清楚的是状态流转，别硬画三版 UI。LOGIC.md要求做一份能双击打开的单文件 HTML，把状态机、reducer 或纯函数跟页面外壳分开。

页面只负责让非开发者点按钮、看状态。核心逻辑不碰 DOM，不接真实数据库，不需要框架和构建工具。正常路径、难缠的边缘情况、原本就不该被允许的操作，都做成可重复的引导场景。

这种原型的爽点不在像不像成品，而在某个人点到第三步时突然说，等一下，这个状态不该出现。

厉害了，bug 还没进生产代码，先在想法里被抓到了。

两条路都反复强调同一件事，把完整状态露出来。UI 切版后要看得出结构换了什么，逻辑操作后要看得出状态改了什么。只给一张漂亮截图，团队很容易把自己的想象补进去，人人点头，心里想的却不是同一个产品。

哪些场景别用

prototype 不是偷懒许可证，也不是快速交付正式功能的捷径。

需求和设计已经确定，只差按现有组件实现时，直接做生产代码。一个修改可以靠纸笔、流程图或一次代码评审决定时，也不用专门搭原型。涉及真实支付、权限、隐私或不可逆数据操作时，不能拿无测试、弱错误处理的一次性代码赌运气。

更重要的是，选出赢家以后不要把切换器和三套方案一起合进主分支。官方建议把验证过的决定重新吸收到真实实现里，把完整原型留在一次性分支，再从任务或提交里留一个指针。

也就是，带走答案，别把实验台搬进客厅。

我自己看完这套规则，最认同的不是快速，而是克制。代码生成越来越便宜，最危险的动作反而是因为来都来了，就把原型继续补成产品。一个原型只回答一个问题，答案到了，停手。

这道刹车，可能才是 71 万次安装背后真正值得收藏的东西。