想用 AI 画原型图，可以先配好 brainstorming、frontend-design 和 web-design-guidelines：分别帮助你理清需求、生成有明确设计方向的界面、检查网页交互细节。需要把原型做成可运行的 HTML 或 React 页面，再加入 webapp-testing 等测试与调试 Skills。十个不必同时启用，按这次要交付的是结构草图、高保真页面还是可运行原型来选。
下面推荐的是 Anthropic、Vercel 及公开社区项目中已有的 Skills，每项附实际仓库入口、适合的任务和调用例子。你可以用墨刀 AI 客户端处理本地需求和项目规则，也可以在 Codex 中使用这些 Skills，再通过墨刀 MCP 生成原型并推进评审。
这10个Skills分别用在哪一步
| 阶段 | Skill | 最值得交给它的任务 |
|---|---|---|
| 需求与范围 | brainstorming | 把“做个后台”变成具体任务和页面范围 |
| 实施拆解 | writing-plans | 为多页面原型安排文件、步骤和验证点 |
| 界面生成 | frontend-design | 按真实内容建立视觉层级和页面实现 |
| 视觉选择 | ui-ux-pro-max | 检索适合产品与场景的设计建议 |
| 主题统一 | theme-factory | 试选配色、字体并应用到HTML等产物 |
| 界面检查 | web-design-guidelines | 检查表单、键盘焦点和界面代码 |
| 操作验证 | webapp-testing | 在浏览器里执行可运行原型的操作 |
| 问题修复 | systematic-debugging | 定位按钮无效、状态不更新等错误 |
| React优化 | vercel-react-best-practices | 检查React原型的加载与渲染问题 |
| 交付确认 | verification-before-completion | 根据实际运行结果说明哪些已完成 |
如果这次只画低保真结构，先用前两项梳理需求与步骤即可。后面的浏览器测试、调试和 React 优化，主要服务已经生成代码、能够打开运行的原型；它们不会替你在任意设计工具的画布里自动完成编辑。
先明确要画什么：两项需求与规划Skills
1. brainstorming：把模糊需求问到可以动手
brainstorming 来自 obra/superpowers。它擅长从目标、使用情境、已有材料和关键约束出发，与用户一起厘清要做什么。适合“我要一个售后后台，但还没想好主流程”的阶段。
给它客服访谈和现有流程，让它先弄清客服如何登记问题、主管如何分派、处理人如何反馈。你应得到足够明确的页面范围与业务约定，再开始绘制。已有清晰 PRD 时，只补尚未确认的问题，不必每次从头做一轮访谈。
使用 brainstorming，阅读售后需求.md，帮我明确客服登记、主管分派、处理人反馈的主流程。先找出影响页面结构的未知项；已有结论不要重新提问。确认后整理要画的页面、每页目标及暂不包含的功能。
2. writing-plans：把多页面原型拆成可以执行的步骤
writing-plans 同样来自 Superpowers，面向已有规格的多步骤实施。它会关注哪些文件需要创建或修改、任务如何拆分，以及每一步怎样验证。相比一口气生成整个系统，适合先完成工单列表，再推进详情与分派操作。
它偏实施计划，不是一个自动画信息架构图的工具。使用代码原型时，把数据文件、页面模块、状态处理与验证步骤明确下来；只做几张结构草图时，可以保持轻量，不必增加完整工程管理流程。
使用 writing-plans，基于已确认的售后原型方案制定实施计划。按列表、详情、分派弹窗和状态验证拆分，明确输入文件、交付结果和检查方法。只做本地原型，不增加登录服务或真实业务接口。
让界面有设计依据：三项视觉Skills
3. frontend-design：给页面一个具体的视觉方向
Anthropic 的 frontend-design 关注受众、内容、字体、排版和明确的设计选择。它适合从需求走向 HTML、React 等界面实现时使用，让生成结果有与项目相符的层级和细节。
售后后台的重点是快速辨认待办、状态和操作，不需要把营销首页的巨幅标题搬进来。给它长短不同的工单标题、真实长度的备注、既有组件约束，要求把这些内容放进界面。只输入“简洁高级”，仍容易得到缺少业务特征的通用页面。
使用 frontend-design，按售后需求.md 和界面约束.md 设计工单列表与详情。重点突出待处理状态、问题摘要和当前操作；用提供的内容长度检查排版。沿用团队组件和中文字体，不增加无关大图与装饰性卡片。
4. ui-ux-pro-max：在设计方案里找到具体的取舍依据
ui-ux-pro-max 来自 nextlevelbuilder/ui-ux-pro-max-skill，提供可检索的产品、风格、配色、字体、交互与实现建议。它适合在“清楚业务，但还不确定用什么视觉语言”时，帮助形成设计方案。
它包含数据、脚本和参考材料。按项目 README 使用 CLI 安装目标客户端；例如在 Codex 项目中，先安装 ui-ux-pro-max-cli，再运行 uipro init --ai codex，并准备 Python 3。上面的源码目录用于查看 Skill 规则，不要直接把 .claude 目录当成 Codex 的安装目录。查到的建议要对照中文界面和现有规范判断：例如英文展示字体不一定适合中文长表格，营销页风格也未必适合高频操作后台。
使用 ui-ux-pro-max，为中文售后工单后台整理设计建议，重点是高信息密度列表、详情抽屉和提交反馈。项目已有蓝色品牌主色与组件规范，优先保留。解释哪些建议适合这个场景，再把选定规则写入界面约束.md。
5. theme-factory：试选并统一一套配色和字体
Anthropic 的 theme-factory 为 HTML 等产物提供主题化的颜色与字体方案，也能按需要形成自定义主题。适合尚无明确视觉规范的概念原型，先比较方向，再统一应用。
已有设计系统的企业项目通常不需要再套一个主题。对于新项目，也要先看主题示例、确认选择，再应用；中文字体能否正常显示、状态对比是否清楚仍需检查。它解决视觉一致性，不负责设计审批、分派或权限逻辑。
使用 theme-factory，为这个尚无品牌规范的售后原型提供主题选择。先展示适合办公后台的方向，确认后再应用颜色和字体。中文字体需可用，警告与成功状态保留明确区分，不改变页面结构与业务文案。
把能看的页面变成能用的原型：五项检查Skills
6. web-design-guidelines：检查表单和操作细节
Vercel 的 web-design-guidelines 会读取 Web Interface Guidelines，检查指定的界面代码并定位问题。适合高保真 Web 原型生成后，检查按钮、表单、键盘操作、反馈和布局等细节。
给它具体文件或模块会更有效，例如只查分派弹窗：处理人选项是否有标签，提交中是否有反馈，键盘焦点能否合理移动，错误信息是否在需要的位置出现。它需要读取代码和获取规则的能力，不能仅凭一张截图完成全部检查。
使用 web-design-guidelines 检查工单详情及分派弹窗代码。优先找出影响完成分派的表单标签、键盘焦点、按钮状态与错误提示问题，按文件位置说明并修正；保留已确认的业务流程。
7. webapp-testing：让AI真的操作一次原型
Anthropic 的 webapp-testing 使用 Playwright 操作本地 Web 应用，可检查交互、截图并查看浏览器日志。它适合已经能运行的 HTML 或 React 原型，需要相应的 Python、Playwright 和浏览器环境。
给它明确的任务脚本，才知道该检查什么。工单分派至少应走完“打开详情—选择处理人—提交—看到结果”；再检查失败时是否保留选择、是否可以重试。如果仅能访问截图或静态说明，就先整理走查步骤，不把它当作已完成的浏览器测试。
使用 webapp-testing 打开本地售后原型。找到工单DEMO-001，进入详情并分派给指定处理人；检查提交中、成功、明确失败和重试状态。失败后应保留已选处理人。记录实际步骤、结果、截图及控制台错误。
8. systematic-debugging：解决反复改不好的交互错误
systematic-debugging 来自 Superpowers，强调复现问题、追踪原因，再做有针对性的修复。适合按钮点了没反馈、切换角色后权限不更新、列表与详情显示不一致等代码原型问题。
把出错前的角色、记录、操作与结果告诉它。比如“分派成功后，详情显示已分派，列表仍显示待分派”，应先检查两处是否使用了不同的数据状态，再决定如何改；不需要让 AI 把整个页面重新生成。
使用 systematic-debugging 排查：工单DEMO-001分派成功后，详情已更新，列表仍显示待分派。按现有操作复现并追踪两处状态来源，修复根因后重跑同一路径。不要顺带更改布局或重写整个模块。
9. vercel-react-best-practices：只在React原型需要时优化
Vercel 的 vercel-react-best-practices 面向 React 与 Next.js 的性能模式，涉及数据获取、包体积、渲染和重复更新等问题。注意：仓库目录是 react-best-practices，Skill 名称是 vercel-react-best-practices。
原型已有明显的输入卡顿、长列表反复重绘或加载过慢时，再让它针对受影响的模块检查。纯设计稿和简单 HTML 页面不必调用；只有几十行静态样本的原型，也不用为了“工程感”提前引入复杂优化。
使用 vercel-react-best-practices 检查工单React原型的筛选与详情模块。先定位已观察到的输入卡顿和不必要渲染，再做与原因相关的修改。保留业务行为，不增加本项目没有使用的Next.js能力。
10. verification-before-completion：交付前确认实际完成了什么
verification-before-completion 来自 Superpowers，用于在宣布完成前运行相关验证并阅读结果。它不是浏览器或测试框架，而是约束 AI 的收尾方式：修改文件、构建成功、交互正确，是不同的结论。
原型交付时，要求它分别说明页面能否启动、关键任务是否跑通、失败状态是否检查，以及哪些仍待人工评审。这样你拿到的是可以继续推进的结果，而不是一段笼统的“全部完成”。
使用 verification-before-completion 核对本次售后原型交付。运行项目现有构建和必要交互检查，说明列表、详情、分派与失败重试分别通过了什么验证。未实际操作的项目保留为待检查，并附启动或预览入口。
第一次使用，按这个顺序组合就够了
多页面原型先确定公共组件的复用规则：列表筛选、详情抽屉、状态标签和确认弹窗分别保留一份定义。每次生成新页时引用同一组规则，并把需求编号与页面旁的字段、权限及异常说明对应起来，减少页面之间的规则分叉。想完整走一遍，可接着做费用审批后台的 Vibe Coding 教程；主要卡在视觉层级，则先看改善 UI 审美的5个 Skills。
以售后工单原型为例，先准备 售后需求.md、角色权限.csv、界面约束.md 和一份去除真实个人信息的样本数据。字段说明、页面规则与角色范围放在项目材料中，现成 Skill 负责采用什么方法处理它们。
- 需求还没讲清：用 brainstorming 确认任务和范围。多页面可运行原型，再用 writing-plans 拆解实施。
- 需要生成高保真页面：用 frontend-design；视觉方向不明确时先用 ui-ux-pro-max 辅助选择。已有规范时，不必再额外套主题。
- 页面已能运行：用 web-design-guidelines 检查代码细节，再用 webapp-testing 跑“查看—分派—恢复失败”的真实操作路径。
- 出现具体问题：用 systematic-debugging 定位。只有 React 性能问题才追加 vercel-react-best-practices。
- 准备给团队看：用 verification-before-completion 确认实际结果，再整理评审入口。
下载时从上面各项的仓库入口获取 Skill，按维护者说明保留 SKILL.md 及所需的 scripts、references、data 等文件。不同客户端的安装目录与加载方式不同；依赖脚本的技能，只复制一份文字规则通常不够。
选好 Skill 后，可以按原型 Skills 安装与首次调用教程检查完整文件、依赖和加载目录，再用一个小任务确认技能确实被调用。
墨刀 AI 客户端可先处理项目材料与需求任务，第三方 Skill 的直接加载方式按当前技能入口确认。对于需要本地代码、终端和浏览器测试的完整组合，可在 Codex 中配置相关 Skills，再连接墨刀 AI MCP：客户端整理材料，墨刀生成 HTML 或 React 产物，通过 get_task_result 取得结果；对返回结果支持的产物类型，再用 import_to_proto 导入并复查页面与交互。
这些 Skill 各有自己的方法和运行条件，MCP 则负责连接墨刀的生成能力。把两者配合起来，才能从需求走到可评审原型。需要把团队的固定规则补进现成 Skill 时，可参考原型设计 Skill 的编写方法；先从最常做的一类页面开始，确认有效后再扩展。
