简介：面向产品经理、交互设计师与产品新人的原型工具速查资料，围绕十款主流原型设计工具做横向梳理，并附墨刀使用教程，帮助读者依据团队协作方式、上手成本与适用平台挑选合适工具。内容覆盖Axure RP的强交互与高学习门槛、InVision的在线协作与动效、Proto.io的浏览器轻量交互、蓝湖的国产标注协作、Fluid UI的移动端线框图与屏幕流，以及GUI Design Studio、Justinmind等客户端与移动原型方案，逐一说明功能特点、优势与局限。全包共1个PDF文件，约216KB，轻量便携，适合课程学习、团队选型讨论或会议间隙快速查阅。已有1692人学习，可作为新人培训与原型方案对比的参考清单，也可顺着墨刀教程完成从工具认知到上手实操的过渡。
1. 从一次返工说起：原型工具选错，后面全是补救
有个小组做课程设计，进度到第二周才发现原型工具选错了：交互稿用了一款交互能力很强的老牌工具，条件判断写得很细，结果指导老师只要求“把主流程点得通”，一改需求，几十个交互点全要重连。返工三天，进度直接落后一周。这类翻车跟能力无关，根源在选型时没有先问“这一阶段我到底要交什么”。这份《十大原型设计工具（附带墨刀使用教程）》的价值就在这里：它把 Axure、InVision、Proto.io、蓝湖、Fluid UI、GUI Design Studio、Justinmind、iClap、Balsamiq Mockups、墨刀十款工具摆在一起做横向对照，再用一份分步教程把墨刀从建项目到分享链接走通。适合要交课设、毕设交互稿的学生，也适合带小团队做 App 演示、需要给开发交付原型的产品岗。选型有依据，上手有路径，剩下的才是设计本身。
2. 选型基线：十大工具按交付场景切成三档
2.1 先定交付物，再定工具
很多人挑原型工具的习惯是打开官网看功能列表，谁的交互项多就投谁，这个顺序是反的。原型的第一性问题不是“工具能做什么”，而是“这一阶段你要交给谁、他拿它干什么”。交给指导老师看的课设原型，核心是流程讲得清、页面点得通；交给开发评审的原型，核心是标注全、字段和异常态写得明；拿去做用户测试的原型，核心是能在真机上跑、能记录点击路径。三种交付物对工具的要求差得很远，用同一把尺子量十款工具，量出来的排名没有意义。
所以合理的做法是先分层。按“这一阶段原型的表达重心”把十款工具切成三档：表达速度优先、交互深度优先、协作与交付链路优先。同一档内的工具可以互相替换，跨档替换就要付迁移成本。这个分法不追求给工具排座次，只回答一个问题——你现在这个阶段，应该从哪一档里挑。
分层之后还有个好处：团队里不同角色可以各取所需。产品经理偏第一档快速出结构，交互设计师偏第二档打磨分支逻辑，视觉和开发偏第三档看标注和切图。一套项目里同时用两三款工具是常态，不是浪费。
2.2 三档拆解：每档的能力边界与代价
第一档，表达速度优先：Balsamiq Mockups、Fluid UI、墨刀。这一档的共同特点是把“画出来”这件事的成本压到最低。Balsamiq Mockups 功能不多，但控件库下足了功夫，内置常用控件和图标，属性设计得不复杂又够用，画出来是手绘风格，特别适合需求讨论阶段快速对齐结构。它的短板也明确：控件库不满足需求时不能自定义，只能干瞪眼。Fluid UI 面向移动开发，拖拽式操作不需要写代码，无设备和平台限制，Windows、Mac、Linux 都能用，Chrome 和 Safari 里跑，Chrome 上的应用还能离线使用；它独特的屏幕流功能能把不同界面联立起来，看页面之间的关系，对 UX 流程设计帮助很大，资源库里 iOS、Android、Windows 8 的组件比较丰富，不够也能自行添加。墨刀在这一档里对移动端最友好，控件拖动和大小调整会自动匹配对应母版尺寸，系统控件基于 iOS 和安卓，建项目时先选设备布局就能省掉一圈适配工作，中文界面和中文教程对新手很友好。
第二档，交互深度优先：Axure、Justinmind、Proto.io、GUI Design Studio。Axure 是老牌专业工具，无限画布方便加文字注解，交互层面能做大量条件判断，巧妙组合可以实现相当复杂的逻辑，用户群体覆盖商业分析师、信息架构师、可用性专家、产品经理、IT 咨询师、用户体验设计师、交互设计师、界面设计师、架构师和开发工程师。代价是学习成本高，细节繁琐会加重画原型时的负担，效率反而不占优。Justinmind 的可视化环境支持用鼠标创建带注释的高保真原型，提供滑动、缩放、旋转甚至捕捉设备方向这类触屏交互，在需要产生效果的部件上选手势即可；属性窗口比 Axure 更好用，对 PS 等软件的图像属性支持更到位，跳转和定向可以用拖拽完成，不必每一步都靠点击。Proto.io 轻便、浏览器里就能用，支持导入 Sketch 和 PS 设计稿做交互，界面清爽、UI 组件较全，集成移动录屏工具后适合用户测试场景，能记录用户点击、滑动、点击区域，也能记录声音和 facecam 视频评论；但协作功能比较受限，复杂交互细节只能靠容器实现，上手成本不低。GUI Design Studio 走的是另一条路，专攻客户端软件界面，不需要编码，提供大量 C/S、B/S 组件示意图，可组合使用，适合把设计思路可视化后跟客户当面演示。
第三档，协作与交付链路优先：InVision、蓝湖、iClap。这一档的工具本身不一定负责“画”，重点是让设计稿流动起来。InVision 起家于设计稿之后的交互原型和团队协作管理，能顺畅衔接 Sketch、PS 设计稿，给设计稿做批注，Freehand 功能支持团队自由讨论想法；后来推出的 Studio 具备了从基础开始的设计能力，能完成较精细的设计稿，动效也能满足多数设计者需求，还能把团队设计规范落到设计工作里。它的不便之处是界面全英文、访问体验一般、价格偏高。蓝湖是国产协作平台，定位“简单好用的团队工作台”，通过插件导入 Sketch、Photoshop、Adobe XD 的设计稿，在平台上做自动标注和交互原型；设计师用它做设计图管理和自动标注，产品经理用它做页面逻辑流程图和汇集产品文档。要注意蓝湖本身没有设计功能，必须依托上述三款设计软件，交互效果的创建方式也相对隐晦。iClap 的定位更靠后，以产品为出发点串联不同职位，把工作产生的内容沉淀、处理、归档、共享，形成沟通协作闭环；在线批注可以在应用运行中直接生成任务，语音任务、即点即用、版本发布、Bug 跟踪、插件管理、会议纪要、人才培养这些能力都围绕项目协作展开，私有部署对数据文件管理更可控。
三档看下来会发现一个规律：工具的能力越强，前置约定就越多。Axure 的条件判断强，前提是你先把页面结构和变量命名想清楚；InVision 的协作顺，前提是设计稿本身在 Sketch 或 PS 里管好了。选型时只看能力强弱，忽略这些前置约定，就是后面返工的起点。
2.3 把选型变成可复现的打分
光靠文字描述还是容易拍脑袋，我一般会把上面三档转成一张带权重的打分表，让团队里三个人各打一遍再对齐分歧。权重用配置文件写下来，改项目类型时只改权重，不动评分逻辑：
# 原型工具选型权重表：把"哪个好用"变成可打分的判断 weights: learning_cost: 0.15 # 学习成本，团队新人多时调高 mobile_fidelity: 0.25 # 移动端适配，App 项目必看 interaction_depth: 0.20 # 交互深度，有无条件判断与变量 collab_annotation: 0.20 # 协作与标注，开发是否直接看稿 delivery: 0.10 # 导出与分享，能否一条链接发给评审方 cost: 0.10 # 订阅成本与自助可控程度 threshold: reject_below: 3 # 任一维度低于 3 分直接出局 must_pass: [mobile_fidelity, delivery] # 这两项必须达标这段配置的含义是：先算加权总分，再看硬门槛。reject_below: 3表示任何一项低于 3 分（满分 5）就不进入候选，避免出现“总分很高但移动端一塌糊涂”的结果；must_pass里列的是不可妥协项，App 项目里移动端适配和分享能力必须过线，否则交互做得再花也交付不出去。参数怎么改：课程设计这类个人项目，把learning_cost调到 0.3，collab_annotation降到 0.1；企业级项目反过来，协作与标注权重上调到 0.25 以上。评分表跑完通常只剩两三个候选，这时候再用真机试一遍，基本不会选偏。
3. 总体方案设计：选型、产出、协作、交付四段流程
3.1 四段流程与角色分工
选型只是第一段。一套能跑通的原型方案，我通常拆成四段：选型、产出、协作、交付。四段之间有明确的输入输出，上一段的产物是下一段的起点，任何一段缺了，最后都会在评审会上暴露出来。
选型段的输入是需求简报和交付对象，输出是一份工具决策记录，写明为什么选这三款、各自的职责边界在哪。产出段按原型层级推进，低保真出流程和页面树，中保真出页面结构和跳转，高保真出视觉与动效说明。协作段解决“谁改了什么、开发怎么拿到最新稿”，通常由协作平台承担，设计稿、标注、评论都在一条链路上。交付段是把原型变成可以发给评审方的东西：一条能打开的链接、一份可安装的演示包，或者一套带标注的页面清单。
角色分工上，产品经理主抓低保真和页面逻辑，交互设计师负责中保真的跳转和异常态，视觉设计师产出高保真并同步到协作平台，开发在协作平台上直接看标注提问题，测试拿最终原型对照验收。这套分工的关键是每一段只有一个负责人，工具可以多人用，交付物必须有人签字。
需要注意的是，四段不是严格串行。高保真阶段发现流程缺一个分支，要退回低保真补页面，这时候页面树和命名规范就是后悔药——命名乱了，退回补页面时找不到该插在哪里。所以命名规范要在产出段一开始就定下来，不要等页面堆到三四十个再补。
3.2 原型分层标准：三级交付物各管什么
原型不分层是另一个高频问题。有人一上来就做高保真，视觉细节抠了两天，评审会上被问“这个按钮点进去是什么”答不上来。分层不是为了多干活，是让每一层的评审问题都落在这一层能回答的范围内。
低保真解决信息架构和主流程。交付物是页面清单加流程图，标注每个页面的入口、出口和关键判断。这一层用 Balsamiq Mockups 或 Fluid UI 最合适，手绘风格反而能让评审方把注意力放在结构上，不去纠结颜色。我一般要求这一层的页面数量和流程图节点一一对应，对不上就是漏页。
中保真解决页面结构和跳转关系。交付物是页面树加可点击的原型，主干路径必须点得通，异常态用标注说明。这一层是墨刀、Axure、Justinmind 的主场，移动端项目优先墨刀，有条件判断和变量需求的用 Axure 或 Justinmind。中保真评审只问三个问题：主干能不能走通、分支有没有漏、返回和中断怎么处理。
高保真解决视觉还原和动效说明。交付物是视觉稿加动效描述，尺寸、间距、状态变化要写清楚。这一层通常由设计软件产出，再通过蓝湖或 InVision 做标注和交付。高保真不追求把每个动效都做出来，做主干动效加文字描述即可，做太细的动效在开发阶段大概率会被实现成本改掉，属于白干。
三级交付物对应三次评审，每次评审只邀请对应角色。低保真评审拉产品和业务方，中保真拉交互和开发，高保真拉视觉和前端。混在一起开会，问题会互相打断，效率很低。
3.3 工具组合矩阵与替换触发条件
实际项目里很少只用一个工具，常见的组合是：主工具负责中保真和跳转，辅助工具负责低保真草图，协作平台负责标注和交付。组合不是固定的，触发替换的条件我一般写死三条：交付对象变化、设备类型变化、协作人数变化。
交付对象从内部团队换成外部评审方，替换点是分享能力，主工具要能生成一条直接打开的链接，或者导出可安装的演示包。设备类型从 Web 换成移动端，替换点是移动端适配和设备模板，优先选内置 iOS 与安卓控件、带设备布局的工具。协作人数超过五人，替换点是标注和评论，单机工具要换成在线协作平台，否则改一版要发五份文件。
项目目录也按四段流程固定下来，避免文件散落：
proto-project/ ├── 00-brief/ # 需求简报、角色与场景清单 ├── 01-flow/ # 流程图与页面清单（对应低保真交付物） ├── 02-wireframe/ # 中保真页面与跳转关系说明 ├── 03-hifi/ # 高保真视觉稿与动效描述 ├── 04-annotation/ # 标注、字段说明、异常态清单 └── 05-review/ # 评审记录与变更日志这个目录结构的作用是把交付物和阶段绑死。01-flow里的每个节点必须在02-wireframe里找得到对应页面，找不到就是漏页；04-annotation里的异常态要和02-wireframe的页面编号对齐，否则开发看不懂标注对应哪个页面。05-review是变更日志，每次评审记一条“谁在什么时候要求改什么”，答辩时被问“为什么这个流程有两个分支”，翻日志就能答。通常的做法是每个目录放一个 README 写清本层交付标准和负责人，评审前对着 README 过一遍，比口头对进度可靠。
4. 墨刀落地：一个移动端原型从建项目到分享链接
4.1 创建应用：模板、设备类型与命名
墨刀的上手路径从建项目开始。访问官网登录后，点右上角的创建应用，先选模板和设备类型，填应用名称，创建完成。建好之后可以随时编辑，也可以邀请他人共同编辑和分享。
这一步有三个容易忽略的点。第一，设备类型要跟最终演示环境一致，选错了后面控件尺寸和页面宽度都要返工，墨刀的系统控件基于 iOS 和安卓，建项目时选定设备布局能省掉大量适配工作。第二，模板只是起点，选了模板不等于结构就对了，模板里的页面该删就删，留着不用反而干扰页面树。第三，应用名称要跟项目目录00-brief里的名字对上，答辩时评委会拿原型和文档对照，名字不一致会显得不严谨。
我一般会在创建完成后先做一件事：把页面管理栏里的默认页面按命名规范改一遍。命名规则用“编号-模块-页面名-状态”的格式，比如“02-订单-确认页-正常”。这条规则看似琐碎，页面超过二十个之后就是救命的东西，跳转拉线时一眼能找到目标页。
4.2 编辑区四栏与组件操作：拖拽、双击、母版自适应
进入编辑界面后，界面分四块：最左边是组件栏，中间是编辑栏，右边是预览排列，还有页面管理栏。组件栏选组件，拖到中间编辑栏里设计；编辑栏里对选中的组件做编辑；右边预览排列是最终页面的基本排列效果。
组件的核心操作是拖拽加双击。把左边组件栏的组件拉到编辑栏，双击组件编辑文字或颜色。这里体现的是墨刀对移动端体验的优化：拖动控件、调整大小时会自动匹配相应母版尺寸，不用担心里面多移一点或少选一点，这种“无形的人在旁边帮你”的手感，是它在 App 原型上体验好的主要原因。
组件用好之后要收敛到组件库。同一个按钮在十个页面出现十次，改一次颜色要改十遍，这是典型的重复劳动。通常的做法是把高频组合（比如带图标的列表项、带返回的标题栏）做成母版或自定义组件，改母版全站同步。这一步不用一开始就做，页面做到五六个、发现重复出现三次以上的组合再抽，抽早了反而限制设计。
自检点：每做完一屏，切到预览排列看一遍真实比例下的排布，编辑栏里放大的视图容易让人误判间距。
4.3 页面管理与跳转：页面树、复制页、超链接拉线
页面在页面管理栏里新建或复制。复制页面是提效的关键动作：同一模块的列表页、详情页、编辑页结构相近，复制之后改字段比从零拖快得多。页面树建议按模块分组，模块内按主流程顺序排列，页面树本身就是一张流程图，评审时直接展示页面树比讲十页 PPT 管用。
跳转的操作是点中组件，拉动组件旁边的超链接样式图标到目标页面，松手即完成。这个交互和很多工具不同，不需要进弹窗选动作，拉线所见即所得。主干路径的跳转要全部拉通，包括返回、取消、弹窗关闭这些容易被忽略的分支。异常态页面如果这阶段不做，就在页面上放一个标注组件写明“此处跳转至错误提示页”，别留空白。
跳转拉完之后做一次连通性检查：从首页出发，只点页面上的元素，看能不能走到终点。走不通的地方通常是漏拉了返回，或者组件被上层遮挡导致点不到。这一步在墨刀里做很快，五分钟能过一遍主链路，比评审时被当场点穿强得多。
4.4 导出与运行分享：图片、安装包、分享链接三条出口
出口有三条。第一条是运行预览，点页面上方的运行图标即可运行编辑好的应用，运行页面右侧通过分享图标可以生成分享链接，这条链接可以直接发给评审方，对方在浏览器里就能点。第二条是导出图片，点页面上方的下载图标，按页导出，用于放进文档或答辩 PPT。第三条是安装包，墨刀的 App 原型支持下载到手机里，是单机版，可以完全通过手机打开原型，这一点比依赖插件做手机预览的方案体验好不少，很适合答辩现场用真机演示。
三条出口的用途要分清：分享链接给远程评审和跨团队对齐，导出图片进文档和 PPT，安装包用于现场演示和用户测试。现场演示前一定要在目标手机上装一遍走一遍，不同机型的状态栏和屏幕比例会让布局产生偏差，提前发现还能改布局，现场发现只能临场解释。
分享链接生成后还有一件事：检查链接打开后的第一屏是不是首页。有些项目里编辑状态停在某个中间页，生成链接后打开直接落在那一页，评审方会以为流程断了。生成链接后自己用无痕窗口打开一次，从首页点一遍主链路，这个习惯能省掉不少解释成本。
5. 避坑与常见问题：五个最容易翻车的点
5.1 交互堆太细，需求一改全崩
现象：原型做了大量条件判断和变量，需求方一句“这个流程简化一下”，几十个交互点全部失效，重连比重画还慢。
原因：把原型当成品开发。Axure 的条件判断能力强，但强不代表要全用上，原型阶段的交互目标是“讲清楚逻辑”，不是“跑起来像真的一样”。分支越多，改动成本呈指数上升。
解决：主干路径做可点击交互，分支逻辑用标注说明。判断标准很简单——评审方会不会真的去点这条分支。不会点的分支，写一行文字说明比拉五条线划算。确有复杂逻辑要验证，单独做一个交互验证页，不要混在主流程里。
5.2 设计稿和原型两套走，改一处漏一处
现象：设计稿在 Sketch 里改了按钮颜色，原型里还是旧的，开发照着旧稿做，验收时对不上。
原因：源文件不唯一。蓝湖这类平台本身没有设计功能，必须依托 Sketch、Photoshop、Adobe XD 的设计稿导入后做标注和原型；如果团队同时在原型工具里手工维护一份样式，就等于有两份真源，冲突是必然的。
解决：定死单一真源。设计稿在哪个软件里，那里就是唯一真源，协作平台只做导入和标注，不在平台里二次修改样式。原型工具里的高保真页只作为演示用，标注以协作平台为准。这条规则写进项目 README，评审时按它对齐。
5.3 手机端预览卡顿或装不上
现象：答辩现场用手机打开原型，加载半天，或者装包失败，只能改用电脑演示，效果打折。
原因：工具选型和演示环境没对齐。部分老牌工具的移动端预览依赖插件，体验不稳定；外文工具还可能有访问和订阅上的额外门槛。
解决：把“真机可演示”列为选型硬指标，写进 2.3 那张表的must_pass。移动端项目优先选支持安装包或原生移动预览的工具，墨刀这类能下载单机版到手机的直接用。演示前一天在目标机型上完整走一遍主链路，把首页加到桌面，现场直接从桌面点开。
5.4 页面命名混乱，跳转和评审一起乱
现象：页面管理栏里一堆“页面1”“副本2”，跳转拉错页，评审时找不到对应页面，改一版要重新梳理半天。
原因：命名规范定得太晚。页面少的时候靠记忆能撑，超过二十个页面记忆就不可靠，复制页面产生的“副本”更是重灾区。
解决：建项目时就把命名规则写进 README，格式统一为“编号-模块-页面名-状态”，复制页面后立刻改名。页面树按模块分组，模块内按流程排序。评审前对着页面树过一遍，节点数量和流程图对不上就说明有漏页或者多余页。
5.5 只看功能不看交付环境，选完才发现用不了
现象：冲着功能列表选了一款外文工具，做到一半发现界面全英文、团队成员上手慢、订阅价格超出预算，换工具又要重画。
原因：选型时只评估了能力，没评估环境。工具能不能用，取决于谁用、在哪用、花多少钱用，这三项跟功能强弱没关系。
解决：选型打分表里learning_cost、cost、delivery三项必须打，且要在真实环境里试一次——让团队里最不熟悉工具的那个人上手半小时，看能不能画出三个页面。画不出来就是学习成本超线，功能再强也要降权。国产工具在中文界面和教程上有天然优势，团队新人多时优先考虑。
6. 验收与答辩：用一条主链路证明方案站得住
验收不是把页面翻一遍，而是按清单逐项打勾。我通常用下面这张表，五项全过才算交付，任何一项不过就退回对应阶段：
| 验收项 | 检查方法 | 通过标准 | 不过退回阶段 |
|---|---|---|---|
| 页面完整性 | 页面树对照流程图逐节点核 | 每个流程节点有对应页面，无孤立页 | 中保真 |
| 跳转连通性 | 从首页只点页面元素走主链路 | 主干路径无死路，返回与取消可用 | 中保真 |
| 标注覆盖率 | 抽查五个核心页面 | 字段、状态、异常态均有说明 | 高保真 |
| 设备适配 | 目标机型实机打开 | 布局无错位，状态栏不遮挡内容 | 产出 |
| 分享可用性 | 无痕窗口打开分享链接 | 首屏为首页，主链路可点通 | 交付 |
答辩环节的技巧是“一条主链路走到底”，不要逐页讲功能。选一条最能体现业务价值的路径，比如从浏览到下单完成，用三到五分钟点完，边点边说每个页面的设计依据和异常处理。评委的问题大概率集中在这条链路上，你提前准备过，答起来有底。我一般会准备三个必答题的答案：为什么这样分层、为什么选这款工具、异常态怎么处理。这三个问题覆盖了方案的设计、选型和细节三面，答完基本没有追问空间。
还有一个细节容易被忽略：答辩用的链接和安装包要提前一天生成好，放在桌面固定位置，别现场找。现场网络、投屏分辨率、手机型号都是变量，能提前固定的都固定掉。
从那以后我每次带项目，交付前都强制自己用无痕窗口从首页点一遍主链路，再拿目标手机装一遍走一遍，两个动作加起来不到十分钟，能挡掉答辩现场八成的意外。这份十大工具的横向对照和墨刀的分步操作，我整理成了一份按上面四段流程排列的文档，从选型打分到页面命名规范都有现成模板，照着过一遍大概两个晚上能上手，希望帮到你。
本文还有配套的精品资源，点击获取
