直接回答：原型设计 Skill 是一套把用户任务、页面结构、交互状态、权限边界和验收条件写成可复用规则的方法。它的价值不是替人决定产品，而是让每次生成或绘制原型时都遵循同一套输入和检查顺序，减少“页面画出来了、关键状态却没定义”的返工。用墨刀原型承载这套规则，可以把初稿、交互和评审意见放在同一份可编辑文件里。
原型设计 Skill 和普通页面清单有什么区别
页面清单只回答“需要哪些页面”，Skill 还要规定“依据什么生成、遇到什么情况补什么、怎样判断完成”。一张合格的原型 Skill 至少包含四层：任务目标、页面与数据结构、状态和异常、验收与交付。缺少其中一层，生成结果就可能只覆盖正常路径，评审时再发现权限、空数据或失败恢复没有位置。
因此，Skill 不等于一串工具按钮，也不等于一句“生成一个后台系统”。它更像团队共同使用的设计协议：输入保持稳定，输出可以被编辑、评论、复用和核对。
一条原型设计 Skill 要定义哪些输入和输出
| 环节 | 需要写清的内容 | 可检查的成果 |
|---|---|---|
| 目标 | 用户、场景、任务、成功标准 | 一句话任务和待验证决策 |
| 结构 | 页面、模块、入口、数据依赖 | 页面树、关键字段和主流程 |
| 状态 | 默认、加载、成功、空、失败、无权限 | 状态表和可回到主任务的路径 |
| 验收 | 触发条件、反馈、边界和交付备注 | 可复现步骤、验收条件和未决项 |
输入越具体，结果越容易比较。比如“做一个团队管理页面”无法说明谁能邀请成员、团队为空时显示什么；“企业管理员在已登录状态下创建团队，名称重复时保留输入并提示修改”则已经带上了角色、入口、规则和失败结果。
用五步规则把 Skill 落到原型
- 先写目标：明确使用者、触发场景和这版原型要支持的决定。不要先从首页或视觉风格开始。
- 再列结构：把页面、弹窗、入口和关键数据列出来，标记哪些是本次必做，哪些暂不展开。
- 补齐状态：为关键操作写默认、进行中、成功、空、失败和无权限状态；状态改变时说明用户能做什么。
- 划定边界：补权限、数据来源、网络中断、重复提交和中途退出。对研发有影响的限制写在对应页面旁边。
- 定义验收：用可复现步骤检查主流程和高风险分支，并记录负责人、版本和未决问题。
五步之间不是一次性瀑布流程。评审发现字段缺失时，应回到结构；发现失败后无法恢复时，应回到状态和边界。重要的是每次修改都能追溯到某条规则，而不是只留下“再优化一下”的评论。
可复制的原型 Skill 模板
下面这张卡片可以复制到团队规范、AI 工作区或原型评审任务中，再按项目替换内容：
目标：谁在什么场景完成什么任务？要支持哪项决策？
入口：从哪里进入？前置登录、角色和权限是什么？
页面：页面、弹窗、关键字段和数据依赖有哪些？
状态：默认、加载、成功、空、失败、无权限如何呈现？
边界：重复提交、网络中断、中途退出和恢复怎么处理？
验收：按什么步骤复现？什么结果算通过？谁确认？
交付：原型版本、标注、未决项和研发备注放在哪里？把模板写进规则后，下一次只需替换目标、页面和业务约束，仍然保留同样的状态与验收检查。这样既能提高生成初稿的一致性，也能让设计、产品、研发对“完成”有相同理解。
案例：企业管理员创建团队
目标是让首次登录的企业管理员创建团队并邀请成员。入口为工作台的“创建团队”按钮；页面包括团队名称、行业选择、邀请成员和完成页；状态至少包含名称为空、名称重复、邀请发送中、邀请失败、创建成功和无权限。
原型评审时按三条路径走查：正常创建并邀请两名成员；输入重复名称后修改并重新提交；邀请接口超时后保留已输入邮箱并提供重试。通过标准不是“页面看起来完整”，而是每条路径都能说明反馈、下一步和数据是否已经确认。
交付给研发时，附上字段规则、权限前置条件、失败提示和版本号。产品确认业务规则，设计确认反馈层级，研发确认接口和状态来源；Skill 负责让这些信息出现在同一份原型中，不能代替三方确认。
AI 生成原型时，Skill 应该管什么
AI 可以根据 Skill 快速整理页面骨架、生成重复状态和提出遗漏项，但它不知道真实业务是否允许某个角色执行操作，也不能凭空确认数据字段和接口约束。使用时应把真实需求、术语和边界作为输入，把生成结果当作可编辑初稿。
检查生成结果时，优先核对任务是否闭环、异常是否可恢复、权限是否明确、页面之间是否能回到主流程。发现问题就回写到 Skill 的规则卡中，下一次生成再复用；不要只在一张图上临时修补。
在墨刀中落地原型设计 Skill
可以在墨刀原型工作区中先搭建页面与交互，再通过评论记录验收结论和未决项。需要把规则交给AI处理时，可参考墨刀 AI Skill 的创建方法，但原型的事实、权限和交付边界仍应由项目负责人确认。
一条能长期复用的 Skill，最终应留下三种成果：可编辑原型、可复现验收步骤、带负责人和版本的决策记录。只生成一张漂亮的页面，不能证明它已经适合开发。
常见问题
原型设计 Skill 适合哪些团队？
适合需要反复制作相似业务原型、多人协作评审，或希望让AI生成结果遵循统一规则的团队。一次性小页面可以直接画，不必为了形式建立复杂规范。
Skill 写得越详细越好吗？
不一定。应该优先写会影响任务、状态、权限和验收的规则；视觉偏好、无关背景和无法验证的口号会增加输入噪声。
生成结果可以直接交付研发吗？
不能。交付前仍要由产品确认业务规则、设计确认体验、研发确认实现边界，并在同一版本中完成关键路径和异常路径走查。
如果你正在把零散需求整理成可评审的页面，可以先用墨刀创建一份可编辑原型，再把这张 Skill 卡片作为团队的检查入口。
