什么是 prototype？
如果你用 AI 写代码，大概率遇到过这种情况：一个需求摆在那，但你不确定技术方案对不对、状态流转合不合理、UI 布局该往哪个方向走。直接让 AI 写最终代码，万一方向错了，返工成本很高。不写吧，光靠脑子想又不够踏实。
prototype 就是 Matt Pocock 开发的一个 AI 技能，专门解决这个问题。它让你在正式提交代码之前，先做一段可丢弃的原型代码，用来回答一个具体的设计问题。
这个技能在 chatgptskill.cn上有独立的页面，被归类为“原型”类别。它适用于 Claude Code、Cursor、Windsurf、Codex 等 60 多个 AI 智能体。
Matt Pocock 对这个技能的定义很直接：“原型是用来回答问题的可丢弃代码。问题决定形状。”
主要功能
1. 两条明确的分支路径
prototype 最核心的设计是：在动手之前先做一次分支选择。它把所有的原型需求分成两类，对应两个不同的执行文件：
LOGIC.md（逻辑分支） ：当你要验证的是“这个状态模型对不对”、“这个业务逻辑走得通吗”这类问题时，走这个分支。AI 会构建一个可运行的终端应用程序，让你像推演棋局一样，把状态机在各种边界情况下跑一遍。
UI.md（界面分支） ：当你要探索的是“这个东西长什么样”、“哪种布局更好”这类视觉问题时，走这个分支。AI 会生成多个风格差异明显的 UI 变体，在同一个路由下可以切换查看。
这个分支选择本身就是 prototype 的核心价值——它避免了把时间浪费在错误类型的原型上。
2. 问题驱动的原型设计
prototype 的工作方式不是“随便做个 demo 看看”，而是先识别要回答什么问题，再决定做什么样的原型。
问题足够清晰时，直接按问题类型走对应的分支。问题模糊时，AI 会先看周围的代码——后端或模型密集型代码指向逻辑分支，页面或组件指向 UI 分支。如果用户在对话中，AI 也可以先问一个澄清问题再开始。
3. 贴合宿主仓库的约定
很多原型工具的做法是“开一个空白沙盒从头开始”，但 prototype 不一样——它要求原型贴合现有仓库的本地约定。原型的代码风格、目录结构、命名规范都和宿主仓库保持一致，而不是从零开始重新造一套。
这意味着原型虽然不是最终代码，但它的“基因”和最终代码是同一个谱系的。验证通过之后，从原型到正式实现的过渡会非常平滑。
4. 从第一天就标记为“可丢弃”
prototype 在文档里明确了一件事：原型从第一天起就是可丢弃的。它不是 MVP，不是 POC，不是“先写个大概后面再完善”——它就是用来回答一个问题，答完就扔。
这个定位很重要。它让 AI 在写原型的时候不会有“这个以后要复用”的心理包袱，代码可以写得快、写得糙、写得只够回答问题。“保留答案，删除代码” 是它的核心哲学。
5. 多轮 UI 变体探索
在 UI 分支下，prototype 支持生成多个风格差异明显的视觉方案，在同一个路由下切换查看。这不是“微调”几个设计细节，而是从布局、配色、排版等维度做出真正有区别的方案，让你能直观地比较和选择。
如何安装 prototype
方式一：单独安装 prototype 技能
在终端中执行以下命令：
npx skills add mattpocock/skills --skill prototype
这条命令会从 Matt Pocock 的技能仓库中单独安装 prototype 技能。
方式二：安装完整技能包
如果你想一次性安装 Matt Pocock 的所有技能，可以执行：
npx skills add mattpocock/skills然后在交互式列表中选择你需要的技能。
方式三：指定 AI 智能体安装
如果你只在一个特定的 AI 工具中使用，可以指定安装目标：
npx skills add mattpocock/skills --skill prototype --agent claude-code
这条命令会把技能安装到 Claude Code 的技能目录中。
验证安装
安装完成后，在终端中执行：
npx skills list
在列表中应该能看到 prototype。
应用场景
场景一：验证复杂状态机
你设计了一个订单状态流转的逻辑——从“待支付”到“已支付”到“配送中”到“已完成”，中间还有“取消”、“退款”、“售后”等分支。光靠脑子想觉得应该没问题，但这种状态机往往在边界情况下才会暴露问题。用 /prototype 走逻辑分支，AI 会生成一个可运行的终端程序，让你亲手把状态机在各种边界情况下推演一遍。
场景二：探索 UI 方向
你要做一个新功能，但不确定它的界面应该长什么样——是卡片式布局还是列表式？是深色背景还是浅色？是极简风格还是丰富的信息密度？用 /prototype 走 UI 分支，AI 会生成多个风格差异明显的方案，你可以在同一个页面里切换对比。
场景三：验证数据结构设计
你要设计一个复杂的数据结构——比如多层嵌套的配置对象、或者涉及多表关联的数据模型。纸上画觉得没问题，但实际用起来可能发现访问路径太深、或者某些字段永远用不上。用 prototype 做一个轻量的终端原型，把数据结构跑一遍，比看文档直观得多。
场景四：在正式实现前“试错”
你有一个想法，但不确定技术上是否可行——比如某个算法的时间复杂度、某个第三方库的集成方式、某个交互模式的手感。与其直接在主代码库里试错（污染仓库、留下技术债），不如用 prototype 开一个独立分支，试完就扔。
使用案例
案例一：订阅状态机的逻辑验证
一个开发者在设计一个订阅系统的状态机——包含“试用期”、“活跃”、“逾期”、“已取消”、“已暂停”等多个状态，以及它们之间的流转条件。这个状态机有十几种状态组合，光靠看代码很难确认所有边界情况是否都覆盖了。
他在 Cursor 中输入了 /prototype 验证订阅状态机的流转逻辑。AI
识别出这是一个“逻辑问题”，走的是 LOGIC.md
分支，生成了一个可运行的终端交互程序。这个程序允许他手动输入当前状态和触发事件，然后观察状态如何变化、以及哪些流转是被禁止的。他在终端里把十几种边界情况都跑了一遍，发现了一个之前没注意到的漏洞——“逾期”状态下居然还可以“续费”，而业务规则要求逾期后必须先“恢复”才能续费。修完之后，他才把状态机的最终实现提交到主仓库。
案例二：仪表板布局的三种方案对比
一个产品经理想做一张数据仪表板，但不确定信息怎么排——是把 KPI 卡片放在顶部、图表放在下面，还是左右分栏，还是用 Tab 切换不同数据视图。他不想直接让开发照着某一个方案做，万一不好用又要重来。
他用 /prototype 做一个仪表板的 UI 原型，给我三种不同的布局方案。AI
走 UI 分支，在同一个路由下生成了三个可切换的布局变体——方案 A 是 KPI 卡片 + 趋势图 + 明细表的纵向排列，方案 B
是左右分栏（左侧 KPI + 右侧图表），方案 C 是 Tab
切换不同数据视图。产品经理把链接发给了几个核心用户，收集了一轮反馈，最终确定了方案 B 的方向，然后把原型交给开发团队作为参考实现。
案例三：API 响应结构的数据探索
一个后端开发者在设计一个聚合 API 的响应结构——需要从三个不同的数据源拉取信息，然后组装成一个 JSON 返回给前端。三个数据源的数据格式各不相同，组装之后的嵌套层级很深，他不确定前端用起来会不会很痛苦。
他用了 prototype 的逻辑分支，AI 生成了一个终端程序，模拟了三个数据源的返回数据，然后执行了组装逻辑，把最终的 JSON 结构打印出来。他拿着这个输出跟前端同事一起看，发现有两层嵌套是多余的，完全可以拍平。调整之后，前端同事说“这个结构好用多了”。原型代码在验证完成后就被删除了，但优化后的数据结构留了下来。
案例四：新功能的“预演”
一个团队准备做一个“批量导入”功能，涉及文件解析、数据校验、冲突处理、结果反馈等多个环节。功能本身不复杂，但流程长、分支多，直接写代码容易漏掉某些分支。
团队 lead 让 AI 用 prototype 做了一个终端版本的原型——不涉及任何 UI、不涉及真实文件操作，只用模拟数据把整个流程走一遍。AI 生成的终端程序按顺序执行了“读取模拟文件 → 校验数据格式 → 检测冲突 → 生成报告”的完整流程，每一步都打印了清晰的日志。团队跑了几轮之后，发现“冲突检测”这个环节的逻辑有缺陷——某些边界情况下会漏报。修完之后，他们才开始写正式的 UI 和文件处理代码。那个终端原型在验证完成后就被删掉了，但团队对流程的信心留了下来。
总结
prototype 解决的是一个很实际的问题：有些设计问题，光靠想是想不清楚的，但直接写最终代码的风险又太高。
它让 AI 帮你先做一个“可丢弃的”中间产物——逻辑问题用终端程序跑一遍，视觉问题用多个 UI 变体比一比——答完问题就扔掉，不污染仓库、不留技术债。
两条分支：LOGIC.md 验证状态和业务逻辑，UI.md 探索视觉方向
问题驱动：先问“要回答什么问题”，再决定“做什么样的原型”
贴合仓库：原型遵循宿主仓库的代码约定，不是从空白沙盒开始
可丢弃：从第一天就标记为 disposable，答完问题就删
如果你经常遇到“不确定该怎么写”的情况——不确定状态流转对不对、不确定 UI 方向该往哪走、不确定数据结构好不好用——prototype 可能是你装过的所有技能里，最能帮你“先试错、后提交”的那一个。
◯ 评论 0