简介：《十大原型设计工具（附带墨刀使用教程）》以PDF形式梳理产品经理、交互/UI设计师及原型初学者常用的十款原型工具，帮助读者按团队协作、交互复杂度、平台限制与学习成本进行选型。内容覆盖Axure RP、Invision、Proto.io、蓝湖、Fluid UI、GUI Design Studio、Justinmind、iClap等，逐项说明功能定位、适用场景与优缺点，并附墨刀使用教程，便于从工具对比过渡到上手实践。资源包共1个PDF文件，约216KB，轻量便于随时查阅；已有1692人学习下载。读者可借此快速建立原型工具全景认知，理解高保真交互、在线协作、设计稿标注与移动端线框图等差异，也能结合墨刀教程完成基础原型制作与团队评审，适合课程学习、工具选型和项目前置调研。
1. 需求评审前一晚的救场：这份 PDF 解决的是「说不清」不是「画不出」
需求评审前一晚，产品经理在群里甩出一份线框稿，开发问「这个弹层从哪进」，设计问「点完回到哪」，一圈问下来，原型里根本没有跳转，会议开成了猜谜。《十大原型设计工具（附带墨刀使用教程）》这份文档瞄准的就是这类场面：它把 Axure、InVision、Proto.io、蓝湖、Fluid UI、GUI Design Studio、Justinmind、iClap、Balsamiq Mockups、墨刀 十款工具逐个拆开，讲清各自擅长哪一段，再用相当长的篇幅附了一整套墨刀使用教程，从建应用、拖组件、页面树、连跳转，一路走到导出安装包和分享链接。
适合谁：手上有真实需求、要在两三天内出一版能点能走的东西的人；也适合把这份材料当课程资源从头过一遍、想建立选型判断的新手。它不解决视觉设计能力，也不替代交互说明文档，边界就在这里。
2. 十款工具怎么挑：从交付物倒推的选型坐标系
选原型工具最容易犯的错，是拿一张功能对比表逐项打勾，最后选了个功能最全、自己也最不会用的。我一般的做法是倒推：先确定这一版原型要交给谁看、要验证什么，再回来看工具。交给客户看的、交给开发估工作量的、交给用户做测试的，是三件完全不同的事，对应的工具也不是同一批。
按这个思路，这十款工具大致落在三个档位上：第一档是重交互型，代表是 Axure RP 和 Justinmind，做的是「逻辑表达」；第二档是协作与交付型，蓝湖、InVision、Proto.io 属于这一档，位置在设计稿之后；第三档是轻量和专用型，Balsamiq Mockups、Fluid UI、GUI Design Studio、iClap、墨刀各有明确的场景边界。分清楚这一点，后面的选择会快很多。
2.1 重交互型：Axure RP 与 Justinmind 的边界在哪
Axure RP 的定位是专业快速原型工具，覆盖线框图、流程图、原型、规格说明文档四类产出，宣传口径是比 Visio、OmniGraffle 这类静态原型工具更快。它的设计区是无限画布，这一点在做带大量文字注解的长页面时确实好用——不用切画板，注释放旁边就行。
它真正的门槛在交互层。Axure 支持很多条件判断，巧妙组合能做到相当复杂的逻辑，但这同时意味着效率问题：细节越繁琐，画原型时的负担越重。我见过有团队为了做一个「登录失败三次锁定」的演示，在 Axure 里堆了十几个状态，最后自己都理不清跳转关系。它的用户群体也确实宽泛，商业分析师、信息架构师、可用性专家、产品经理、IT 咨询师、体验和交互设计师、界面设计师、架构师、开发工程师都能用，但「能用」和「用得值」是两码事。
判断要不要上 Axure，我推荐一个测试方法：拿你最近一个真实需求，只做两个页面，中间加一个条件分支（比如表单校验失败回到本页并弹提示），限时两小时。两小时做不出来，说明你当前阶段的需求用不上它的条件逻辑，硬上只会拖慢交付；能顺利做出来，后面的复杂交互也就顺着这条路走了。
Justinmind 和 Axure 常被拿来对比，差异点挺具体。它能输出 HTML 页面，更偏移动端 App 方向；可视化环境里可以用鼠标直接创建带注释的高保真原型；触屏交互提供了滑动、缩放、旋转，甚至能捕捉设备方向，在需要出效果的部件上选手势就行；为 iPhone、iPad、Android 提供了组件，也支持自定义组件库。交互方式上，它靠拖拽实现跳转和定向，不必像 Axure 那样每一步都点选，属性窗口也更顺手，还能捕获 PS 里的图像属性。要注意的是，收费版本才提供完整的移动端交互组件，免费版会简单不少。
| 维度 | Axure RP | Justinmind |
|---|---|---|
| 交互表达 | 条件判断强，逻辑可做得很深 | 手势和动效现成，拖拽连线即可 |
| 上手成本 | 高，细节繁琐 | 中等，属性面板更直观 |
| 主要输出 | 原型 + 规格说明文档 | 可输出 HTML 页面 |
| 适合场景 | 复杂业务逻辑演示、需求规格交付 | 移动端触屏交互演示 |
| 明显短板 | 画图效率被细节拖慢 | 完整组件需付费版 |
2.2 协作与交付型：蓝湖、InVision、Proto.io 各管哪一段
这三家的共同点是：它们都不是「从零画图」的第一顺位，位置都在设计稿之后。把它们当画图工具用，会觉得处处别扭；把它们当交付中转站用，价值立刻出来。
蓝湖是国产协作平台，自我定位是团队工作台。它通过插件导入 Sketch、Photoshop、Adobe XD 的设计稿，然后在平台上做自动标注和交互原型。对设计师来说，这里是设计图管理和自动标注的地方；对产品经理来说，可以画页面逻辑流程图、汇集产品文档。关键限制是它本身没有设计功能，必须依托外部设计软件，交互效果的创建方式也相对隐晦，第一次用容易找不到入口。
InVision 起步于设计稿之后的交互原型和团队协作管理：顺畅衔接 Sketch/PS 设计稿、给设计稿做批注、用 Freehand 让团队自由讨论想法。后来发布的 Studio 补上了从基础开始的设计能力，能做相当精细的设计稿，动效也够用，还能把团队的设计规范落到实际设计工作里。短板比较实在：界面以英文为主，访问体验一般，价格偏高。
Proto.io 是轻量在线工具，大多数浏览器都能跑，支持导入 Sketch 和 PS 设计稿做交互，界面清爽，UI 组件比较丰富，原型可以直接用链接分享。它最有辨识度的能力是集成了移动录屏工具，适合用户测试场景：能记录用户的点击、滑动和点击区域，也能记录用户的声音和 facecam 视频评论。协作功能有，但比较受限；复杂交互要靠容器实现，细节效果做起来绕，上手成本不低。价格比 InVision 便宜，但相比国产工具仍然偏高。
落地判断很简单：如果你的团队设计稿出自 Sketch 或 PS，交付环节缺一个自动标注加原型托管的地方，蓝湖是最省事的；如果要做跨地域的多人评审和讨论，InVision 的批注和 Freehand 更顺手；如果这一版原型的目的是拉真实用户来点、并且要留下行为记录，Proto.io 的录屏能力是别家不容易替代的。
2.3 轻量与专用型：Balsamiq、Fluid UI、GDS、iClap、墨刀
Balsamiq Mockups 是个小软件，功能不多，但控件上下了功夫：内置所有常用控件，每个控件的属性都经过取舍，不复杂又够用，出来的效果精致，图标库也不错，不需要到处找第三方控件库，也不用装插件。它的爽点在于快——能以最快速度把界面原型画出来，而且是彻底的手绘风格，评审时没人会把它误当成视觉稿来挑颜色。缺点同样明显：控件库不能满足需求时不能自己定制，只能干瞪眼。
Fluid UI 面向移动开发，主要帮设计师画线框图，但影响会延伸到后期界面设计、功能设置和上线前测试。它对 UX 流程设计帮助很大，能把不同界面联立起来看彼此关系。技术上有几个实用点：无设备限制、无平台限制，Windows、Mac、Linux 都能用；支持 Chrome 和 Safari，Chrome 上的应用还能离线使用；拖拽操作，不需要写代码；有独特的屏幕流功能，方便和团队交流；资源库覆盖 iOS、Android 和 Windows 8，不够用可以自行添加；还能用播放器预览设计、收集意见反馈。
GUI Design Studio 的定位更垂直：面向应用软件设计图形用户界面，特别适合客户端软件。它不需要编码，能把设计思路快速可视化并实现基本交互，方便演示和与客户沟通。它提供大部分 C/S、B/S 组件的示意图，可以组合使用，做 Windows 平台软件的界面模型很对路。做移动 App 的团队基本可以先跳过它。
iClap 严格说不算画原型的工具，它是一条从需求到上线后的协作链路：在线批注可以直接在 App 运行中生成任务，处理任务时还原场景；语音能转成任务，并自动识别紧急程度和对接人；多个 App 项目在同一个客户端管理，不必逐个下载；版本升级只需后台上传一次数据，客户端自动更新；还有 Bug 跟踪自动生成报告、插件管理、会议纪要、基于平台的信息分发。适合的是已经进入迭代期、需要把反馈闭环管起来的团队。
墨刀是这份文档的重头，也是后面教程的主角。它对 App 原型的设计体验很好，控件拖拉、尺寸调整都会自动匹配相应的母版大小，不用纠结多移了一点还是少选了一点；系统控件基于 iOS 和 Android，进来先选设备布局，能省不少环节。比较有差异的一点是，墨刀的原型可以下载到手机里，以单机版形式通过手机直接打开，这一点比靠插件做手机预览的方案顺得多。中文界面和中文教程对新手友好。
2.4 一张对照表与三种混搭方案
| 工具 | 最强的一段 | 明显短板 | 典型交付物 |
|---|---|---|---|
| Axure RP | 条件判断与规格文档 | 细节繁琐、效率低 | 需求规格 + 复杂交互原型 |
| Justinmind | 触屏手势与动效 | 完整组件需付费 | 移动端高保真 |
| InVision | 设计稿批注与团队讨论 | 英文界面、价格高 | 评审用可点原型 |
| Proto.io | 用户测试录屏 | 复杂交互靠容器 | 用户测试素材 |
| 蓝湖 | 自动标注与文档汇集 | 自身无设计功能 | 设计交付与标注 |
| Fluid UI | 移动端线框与屏幕流 | 高保真动效有限 | UX 流程线框 |
| GUI Design Studio | Windows 客户端界面 | 场景单一 | 客户端软件界面示意 |
| iClap | 批注转任务、Bug 跟踪 | 不以画图见长 | 迭代期反馈闭环 |
| Balsamiq Mockups | 手绘风快速线框 | 控件不可定制 | 早期方案讨论 |
| 墨刀 | App 原型 + 真机预览 | 复杂条件逻辑偏弱 | 可点击演示 + 手机安装包 |
真正干活时很少只用一款。我常用的三种组合是这样的。
第一种，两周内做验证的小团队：Balsamiq 半天出线框，确认信息结构；墨刀把关键三四页做成可点击、能装到手机上的版本；最后把设计稿丢进蓝湖做标注交接。这条路的好处是每一段都不需要学习成本堆叠。
第二种，客户演示型项目：用 GUI Design Studio 出客户端界面示意，因为它的组件示意图和真实 Windows 控件接近，客户看得懂，也不会误以为已经开发完成。
第三种，需要拉真实用户测试的项目：线框用 Fluid UI 串屏幕流，交互稿放 Proto.io 跑录屏，把点击路径和用户表情、声音一起录下来，回来复盘时比对着会议纪要猜要靠谱得多。
3. 墨刀最小闭环：建应用、拖组件、连跳转、出链接
这一章把教程里那套网页版操作拆成能照着走的一条线。之所以选网页版做主线，是因为它不依赖本地安装，换台机器也能接着改；手机端主要负责预览和演示，不承担编辑工作。
3.1 创建应用：模板和设备类型先定死
进入官网登录后，点右上角的创建应用，流程是选模板和设备类型、填应用名称，创建完成后就能编辑、与他人共同编辑或分享。这三步里最容易被忽略的是设备类型，它决定了画布基准尺寸和可用的系统控件库，中途改会很麻烦。
模板建议第一次别选重的。带完整页面结构的模板看着省事，实际上会塞进一堆你用不上的页面和组件，后面删起来比新建还费时间。选空白或最简结构，把页面树自己搭一遍，反而更快。
设备尺寸这块，我习惯在项目开始就把基准写进一个约定文件，团队里所有人按同一套数值出稿，避免后面标注对不上。
/* 原型基准尺寸约定：放进项目 README，所有人按这个出稿 */ :root { --design-width: 375px; /* iOS 逻辑宽度基准，设计稿按 1x 出 */ --design-height: 812px; /* 首屏高度基准 */ --grid-columns: 4; /* 移动端常用四栏栅格 */ --gutter: 16px; /* 卡片与卡片之间的间距 */ --safe-top: 44px; /* 状态栏 + 导航栏占位高度 */ --safe-bottom: 34px; /* 底部安全区，避开手势条 */ --tap-min: 44px; /* 可点击区域最小边长 */ }这段变量的意义不在样式本身，而在统一口径。--design-width定 1x 设计稿宽度，导出时按 2x 或 3x 出图，标注才对得上；--safe-top和--safe-bottom是为了让顶部导航和底部按钮不被系统区域压住，做真机预览时这个问题暴露得最明显；--tap-min是点击热区下限，原型阶段就该守住，否则用户测试时会出现「点了没反应」的假故障。
3.2 编辑区四栏布局与组件拖拽
进入应用编辑后，界面分四块：菜单栏、组件栏、编辑栏、预览排列栏。最左边是组件栏，选中需要的组件拖到中间编辑栏；中间编辑栏负责对选中组件做编辑；右边是预览排列，也就是最终页面的基本呈现。
组件的基本操作是拖进来、双击改文字或颜色。这里有个细节值得单独说：墨刀的控件在拖拉和调整尺寸时会自动匹配相应的母版大小，不需要你精确对齐到像素，这对不擅长做视觉的人很友好，但也意味着你不能指望它替你做精细排版。它提供的是系统控件，基于 iOS 和 Android，选好设备布局后，导航栏、标签栏这类结构件直接可用。
我一般的操作顺序是：先把页面骨架（导航、内容区、底部操作区）用系统控件搭出来，再往内容区填业务组件。反过来做，往往会在最后发现内容区高度和底部操作区打架，整页重排。
3.3 页面树管理与跳转连线
页面管理在最右边的页面管理栏，可以新建或复制页面。复制页面比新建更常用——同一套骨架下做变体，复制改文案比从零搭快得多。教程里的原型页面树就是这个东西：它决定你的原型是一堆孤立页面，还是一个能走的流程。
跳转的连法是：点击组件，拉动组件旁边的超链接样式图标，拖到目标页面上，跳转关系就建立了。这个动作要落在具体组件上，落在容器或者编组上，运行时很可能点了没反应，后面避坑章会专门讲。
做页面树我建议一开始就定命名规则，比如01-首页、02-列表、03-详情，按主路径编号。原型超过十页以后，靠「页面1、页面2」这种默认名找页面，效率会掉得很难受，而且分享给别人时对方完全看不懂结构。
3.4 导出与分享：三条交付路径怎么选
做完之后有三个出口，用途完全不同。
点页面上方的下载图标，可以导出图片或者安装包。图片适合贴进需求文档、放进汇报材料；安装包适合装到手机上做真机演示。注意手机上的原型是单机版，改了云端内容之后，手机上那份不会自动同步，需要重新下载覆盖。
点页面上方的运行图标，进入运行页面，在运行页右侧通过分享图标生成分享链接。链接适合发给不在同一间会议室的人，对方点开就能走流程，不用装任何东西。
选哪条路取决于你要对方做什么：要对方「看」，给图片；要对方「点」，给链接；要对方在真实设备上感受手势和尺寸，装安装包。三种混着用是常态，但交付时要说清楚哪份是最新的，否则核对版本能耗掉半天。
4. 五个翻车点：点了没反应、真机打不开怎么查
原型工具的问题大多不复杂，难在不知道从哪找。下面五条是我和同事实际踩过的，每条按现象、原因、解决三步记，遇到同类问题可以照着对。
4.1 三条与跳转、预览相关的翻车
第一条：连线做了，运行起来点了没反应。
现象是编辑态能看到连线，运行后点组件毫无反应，也没有报错提示。原因通常是连线挂在了容器或编组上，而不是最终响应点击的那个组件；另一种情况是页面被复制或删除后，原来的连线目标失效了，连线还在但指向了不存在的页面。解决办法是先取消编组，选中里层组件重新拉一次超链接图标；然后打开页面树逐个核对，凡是连线目标显示异常的，删掉重连。我后来的习惯是连线前先确认组件是独立元素，做完一段流程就运行一遍，别攒到最后一起验。
第二条：真机安装包打开是空白，或者布局整体错位。
现象是手机上打开原型，顶部被状态栏压住、底部按钮被手势区挡住，严重的整页空白。原因有两个方向：一是设备类型选的和真机差太远，按窄屏设计的页面放到宽屏上，母版尺寸不匹配；二是页面里用了绝对定位，没有给安全区留位置。解决办法是回到应用设置核对设备类型，把--safe-top和--safe-bottom对应的占位补上，底部固定元素往上抬一档再试。顺带提醒，真机安装包是单机版，云端更新后手机端不会自己变，得重新下载。
第三条：分享链接发出去，对方看到的流程和你不一样。
现象是自己这边跑得好好的，对方点开链接走到第二步就断了。原因多半是链接指向的是某个页面而非首页，或者分享时把编辑态页面当成运行态发了出去；还有一种情况是你在发链接之后又改了页面树，旧链接对应的页面被替换。解决办法是统一从运行页面生成分享链接，发之前自己用无痕窗口点一遍全流程，改完结构之后重新生成链接并说明「以这条为准」。
4.2 两条与导出、协作相关的翻车
第四条：导出的图片放到文档里发虚。
现象是导出的页面图在演示时还行，一投屏就糊。原因是导出倍率不足，按 1x 导出的图放到高分辨率屏幕上必然被拉伸。解决办法是按 2x 或 3x 导出，文档里再按实际显示尺寸缩放；如果只是截图贴进需求文档，也要保证截图宽度不低于 750px。
第五条：两个人同时改，改动被覆盖。
现象是同事改完保存后，你之前调的一整页组件位置全回去了。原因是协作落在页面级，同一页面并发编辑没有细粒度合并。解决办法是按页面树分工，谁负责哪几页提前说清楚；确实要动同一页时，先复制一页做版本，命名加日期，改完再决定是否合并。这条不是工具的问题，是流程的问题，工具只能缓解不能根治。
4.3 排查顺序：三步定位法
遇到问题别一上来就重做，按这个顺序过一遍，八成能定位。
第一步，看页面树。目标页面是否存在、命名是否被改过、连线目标是否有异常标记。页面树是原型的骨架，骨架错了，后面全是白费。
第二步，看选中层级。点一下出问题的组件，确认选中的是里层组件还是外层容器，容器的点击事件和组件的点击事件不是一回事。
第三步，换环境复现。编辑态正常就跑运行态，运行态正常就发链接用无痕窗口开，链接正常就装到真机上。每换一次环境，问题的范围就缩小一圈，剩下的基本就是设备尺寸或者发布状态的问题。
5. 从需求清单到可点击交付：一套原型的五天走法
工具选完，真正决定原型好不好用的还是流程。下面这套走法是我在小团队里反复用过、也改过几轮的版本，五天出可点击交付，中间不留返工尾巴。
5.1 需求清单到线框：先画到什么程度
第一天只做一件事：把需求拆成页面清单和动作清单。页面清单写「有哪几屏」，动作清单写「每屏上用户能做什么、做完去哪」。这两份清单不需要工具，写文档就行，但必须写全——跳转关系是从动作清单里长出来的，不是画的时候临时想的。
第二天用 Balsamiq Mockups 出线框。选它的理由很实在：手绘风格天然带着「这是草稿」的信号，评审时大家会讨论结构而不是抠按钮颜色；控件内置、图标够用，不用装插件也不用找素材，一天能出十几屏。这个阶段唯一的任务是确认信息结构和主路径，任何视觉细节都是浪费时间。
线框评审要盯住三个问题：主路径能不能走通、异常路径有没有出口、每屏的主要动作是否唯一。第三个最容易被忽略，一屏上放了四五个平级按钮，等于告诉用户「你自己猜哪个重要」。
5.2 高保真与动效：墨刀和 Justinmind 的分工点
第三天到第四天进高保真。这里的分工我一般这么切：需要装到手机上演示、需要中文界面、需要快速改版的部分交给墨刀；需要触屏手势演示（滑动切页、缩放、旋转、跟随设备方向）的部分交给 Justinmind，它的手势是现成组件，配上就行。
墨刀这边，我按 3.2 节说的顺序搭：系统控件出骨架，业务组件填内容，全部按 3.1 的尺寸约定走。跳转只连主路径和关键异常路径，不要试图把所有分支都在原型里实现——原型是给人看的，不是给机器跑的，把所有边界条件都做进去，最后没人看得完。
Justinmind 这边要注意免费版的组件限制，收费版才提供完整的 iPhone、iPad、Android 交互组件。如果只是内部评审，免费版够用；要做客户演示，得提前确认版本能力，别到现场发现手势组件拖不出来。
5.3 交付与走查：标注、版本和验收单
第五天做交付。设计稿进蓝湖做自动标注和交互原型，产品文档和页面逻辑流程图也汇到同一个地方，开发和设计各取所需。这一步的前提是设计稿本身出自 Sketch、Photoshop 或 Adobe XD，蓝湖没有设计功能，指望它在平台内改图会卡住。
版本管理用笨办法最有效：文件名带日期和版本号，页面树按编号命名，每次交付写一行变更说明。听着原始，但比任何工具都稳。原型改到第三版之后，靠记忆区分「这版加了什么」是不可能的。
验收单也别省。我用的模板只有四行：主路径是否通畅、异常路径是否有出口、真机预览是否有遮挡、分享链接是否是最新版本。四条全过再发出去，能挡掉大半返工。
6. 把原型当测试脚本：页面编号与走查清单的用法
原型做到能点之后，多数人就停在「发个链接给大家看看」这一步，价值其实只发挥了一半。我的做法是把它当测试脚本用：给每条关键路径编号，让原型自带执行顺序，谁来点都能点出同一套结果。
具体做法是页面树统一用「编号-动作」命名，比如01-启动、02-登录-成功、02b-登录-密码错误、03-首页。字母后缀表示异常分支，主路径只用数字。这套命名在页面树里看是一棵能读的流程图，分享给别人时不用额外解释。
配套写一张路径清单表，交给测试或评审的人照着走。
| 编号 | 起点 | 动作 | 预期落点 | 检查点 |
|---|---|---|---|---|
| P01 | 01-启动 | 冷启动等待 3 秒 | 02-登录 | 无白屏、无重复跳转 |
| P02 | 02-登录 | 输入正确账号，点登录 | 03-首页 | 按钮点击热区不小于 44px |
| P03 | 02-登录 | 输入错误密码，点登录 | 02b-登录-密码错误 | 提示可关闭，返回后输入框保留 |
| P04 | 03-首页 | 下拉刷新 | 03-首页 | 加载态有占位，不跳动 |
| P05 | 03-首页 | 点卡片进入详情，再返回 | 03-首页 | 返回后滚动位置保留 |
有了这张表，用户测试时的记录方式也变了：不用写「用户觉得卡」，直接记「P04 失败，加载时页面整体下移 12px」。这类记录才能进缺陷列表，也才能被修掉。
还有个小技巧：把路径清单的编号同步到墨刀的页面命名里，走查时让对方报编号而不是描述问题，沟通成本会低很多。跨团队评审尤其明显，一边说「那个点进去又回来的页面」，一边说「P05」，后者省下的时间够多聊两个需求。
最后一条是血泪经验。早些年我做原型喜欢把所有分支都堆进去，觉得做得越全越专业，结果评审时大家在第 7 层分支里绕不出来，主路径反而没人看。从那以后我每次出原型前，都强制走一遍「主路径能不能三次点击内走完」这个检查，走不完就先砍分支。原型不是产品，它的任务是让决策发生，不是把可能性穷举一遍。这份 PDF 里十款工具的对照和墨刀那套操作我留在手边当清单翻，需要的话拿一份对着做，比在十几个工具页面之间来回跳省事得多。希望帮到你。
本文还有配套的精品资源，点击获取
