prototype

prototype 技能概览

prototype 技能能做什么

prototype 技能帮助你先做一个可丢弃的原型代码，用来回答一个具体问题，再决定是否进入真正实现。它最适合那种“光靠一句 prompt 不够”的场景：你需要用一个可运行、易抛弃的东西，测试状态转换、数据结构，或者 UI 方向。

适合安装给谁

如果你经常会说“帮我做个 prototype”“给我看几个方案”“我还不确定哪种结构对”，那就很适合安装 prototype 技能。它对在现有仓库里工作的 agent 尤其有用，因为原型需要贴合本地约定，而不是从空白沙盒里重新开始。

它为什么不一样

这个 prototype 技能不是泛用的头脑风暴 prompt。它会强制你尽早做出分支选择：要么是偏逻辑的终端原型，要么是带多个视觉变体的 UI 原型。这个决定就是它的核心价值，因为它能避免把时间浪费在错误类型的原型上。

最适合与不适合的场景

prototype 适合设计探索、业务规则边界情况、状态机不确定性，或者“这个东西应该长什么样？”这类工作。如果你已经知道最终实现长什么样，或者你只需要文字说明而不是可运行原型，那就跳过它。

如何使用 prototype 技能

安装并定位源文件

使用 npx skills add mattpocock/skills --skill prototype 安装 prototype 技能。然后先读 SKILL.md，再根据问题选择读 LOGIC.md 或 UI.md。如果你需要更完整的上下文，可以继续查看仓库里的 README.md、AGENTS.md、metadata.json，以及附近的 rules/、resources/ 或 references/ 文件夹。

选对分支

prototype 的核心使用决策很简单：逻辑问题对应 LOGIC.md；视觉问题对应 UI.md。如果 prompt 比较模糊，可以结合上下文代码来判断：后端或模型密集型代码通常指向逻辑分支，而页面或组件通常指向 UI 分支。如果用户在场，最好先问一个澄清问题再开始做。

把模糊想法变成可用 prompt

一个好的 prototype guide prompt 需要写清楚问题、目标界面和约束。比如，“原型验证这个订阅状态机能否处理取消、宽限期和恢复流程”就比“prototype billing”更有用。做 UI 时，要说明它属于哪个页面、哪些现有数据必须保持真实，以及你想要几个变体。问题越具体，技能越不容易产出错误的成果。

先读哪些文件

先看 SKILL.md，了解分支规则和通用约束。然后，如果你需要一个小型交互式状态探索器，就读 LOGIC.md；如果你需要在同一路由上展示多个布局，就读 UI.md。这些文件之所以是最短路径，是因为它们展示的是实际工作流，而不只是概念。

prototype 技能 FAQ

prototype 只适合前端吗？

不是。prototype 技能被有意拆成了两个分支：一个用于 UI 探索，另一个用于业务逻辑或状态建模。如果你要测试“这个东西应该长什么样”，用 UI 分支；如果你要测试“这个状态变化是否合理”，用逻辑分支。

它和普通 prompt 有什么区别？

普通 prompt 也可以要求一个 mockup，但 prototype 技能多了一套能减少猜测的工作流：它会选分支、保持工作可丢弃，并把输出推向你能实际检查的东西。这样一来，当选错设计的代价很高时，它就更有价值。

prototype 技能适合新手吗？

可以，只要你能把问题描述清楚。它在请求比较模糊时就没那么适合新手，因为这个技能依赖于选对分支，并贴合宿主项目的约定。如果你不知道运行时环境或页面结构，通常就需要补充更多上下文。

什么时候不该把 prototype 用在 Prototypes 上？

不要把它用于最终生产实现、宽泛的架构重构，或者你只需要文案、只想做发散想法的请求。prototype 技能最强的场景，是你想要一个一次性产物，帮助你做决定，而不是一个可以直接发版的精致功能。

如何改进 prototype 技能

提问，不要先下结论

提升 prototype 技能输出的最好方式，是描述你需要被解决的不确定性。不要说“做一个更好的结账页”，而要说“测试单页结账能否在不显拥挤的情况下处理优惠码输入、运费选择和支付错误”。这样才能给技能一个真正的决策目标。

提供最少但真实的上下文

想让 prototype guide 的结果更好，可以加入宿主路由、相关数据结构、必须保留的现有组件，以及框架、运行时或禁止新增依赖之类的约束。原型质量会在技能能尽量复刻真实环境，而不是凭空编一个环境时明显提升。

注意最常见的失败模式

最常见的失败模式，是太早选错分支。如果原型做的是错误的问题，结果即使看起来很精致也没有用。拿不准时，强制技能在顶部先写明它的假设，并把原型范围严格限制在这个假设内。

每次只加一个更尖锐的约束

第一次生成后，改进 prototype install 结果的最佳方式，是每次只改一件事：更少的变体、更真实的数据、更严格的边界情况，或者更具体的目标屏幕。通常这比要求“多给几个方案”更有效，因为这个技能本来就是用来回答一个问题的，而不是追求覆盖面最大。