简介：在产品设计流程中，原型不仅是界面的雏形，更是信息架构与交互逻辑的可视化载体。通过站点地图的父子层级梳理页面关系，利用Master机制复用导航与弹窗等公共模块，再借助自定义注释字段规范功能说明、优先级与验收标准，Axure RP构建了一套从线框到规格说明书的完整工作流。动态面板的状态切换让点击、滑入等交互行为贴近真实业务逻辑，而F5/F6生成的HTML演示与Word文档，则让原型直接转化为开发人员可读的结构化交付物。对于B端后台、多页面系统等复杂场景，这套方法能够显著降低需求评审与开发对接中的沟通成本，帮助产品经理与交互设计师把口头讨论逐步固化为可维护的工程文档。
1. 当原型要变成交付物时，为什么还是 Axure RP 稳
你接手过一个需要输出三十张以上页面的 B 端后台项目，就会有这种感觉：Figma 画界面很快，但开发追问“这个状态什么时候出现”“校验失败文案写在哪”时，你还是要回到文档里一条条补。Axure RP 在原型设计工具里属于另一条路线，它不强调视觉表现力，而是把站点地图、部件库、注释、交互规则和文档生成整合在同一条流水线上，最终产物可以直接变成带编号的 Word 规格说明书。对产品经理和交互设计师来说，最值的不是画图那一下，而是画完图之后，注释字段能替你回答开发的问题。这篇教程按照实际做原型的顺序来推进——先理页面关系，再选部件，再挂交互，最后收口到交付物。
2. 视图框架就是信息架构：Sitemap、Master 与注释字段
2.1 Sitemap 的父子结构决定了原型的信息架构
Axure RP 里的 Sitemap 面板看起来只是一个树形目录，但它承载的是信息架构。每一次在 Sitemap 里新增子页面，都等于告诉开发人员这个站点里存在一个层级关系；而每一个节点对应的页面类型，也在暗示这个页面的用途。Sitemap 右键菜单中，我对“增加子页面”“复制分支”“页面降序/升序”这几个命令的使用频率最高。复制分支会连子页面一起复制，适合在要做多版本页面结构时快速搭建一套平行分支；页面降序则把一个页面降为上一节点的子节点，常用于调整原型的信息层级。
Sitemap 里的每个页面有两种形态：wireframe和flow。wireframe 页面用来放具体的控件和细节说明，flow 页面则用来表达流程逻辑。两种页面可以混排在同一个树里，实际工作中我习惯用两种组织模式，视项目阶段选用。
| 组织模式 | 具体做法 | 适用阶段 |
|---|---|---|
| flow 为父，wireframe 为子 | 先画流程图，再按流程图节点拆页面 | 需求梳理初期，整体流程未固化 |
| wireframe 为父，flow 为子 | 线框图中某个模块逻辑复杂，用 flow 页单独拆解 | 页面结构已明确，局部流程需要补充 |
这两种方式不是互斥的。复杂项目里常常是“你中有我，我中有你”，比如首页线框下挂一个“登录流程”的 flow 子节点，而这个 flow 里又挂着一个“忘记密码”的 wireframe 页面。用这种混排方式，Sitemap 就不只是文件列表，而是可阅读的站点说明书。
2.2 Master 的三种行为模式决定了复用效率
Master 面板的作用与 Sitemap 的区别在初学者那里最容易混淆。Sitemap 里的节点是最终展示页面，而 Master 更像是在多个页面里反复使用的公共模块，类似于程序开发中的 include 机制，也类似于 Dreamweaver 里的 template。把导航、页脚、侧边栏这类重复出现的区域放进 Master，是减少重复劳动的常规做法。
Axure Master 有三种行为模式，理解它们的差异才能在不同场景下做对选择。
| behavior 行为 | 行为含义 | 典型用法 |
|---|---|---|
| Normal | 普通复用模块，页面中出现的样式与 Master 完全一致 | 全局页脚、版权声明 |
| Place in background | 定位在页面底层，且锁定 widget 的原始位置 | 头部导航、固定侧边栏、水印背景 |
| Custom widget | 页面里复用的只是结构和默认行为，各页面可以覆盖说明和局部配置 | 弹窗、卡片、动态列表项 |
Place in background是我在实战中最常用的一类。它被拖进页面后自动置于底层并锁死位置，不会因为误操作被移动。用它做后台系统的左侧导航栏，只需要在一个 Master 里维护菜单，几十个页面自动同步。Custom widget则适合弹窗这类场景：弹窗的结构一致，但不同页面里弹窗的说明文字、触发按钮文案可能不同，此时 Master 管结构和默认交互，页面里覆写注释即可，避免了为每个页面单独维护一套弹窗。
Master 还提供了一个很实用的功能——使用报告。右键 Master 文件选择“usage report”，会列出所有使用该 Master 的页面，双击列表项可以直接在编辑区打开对应页面。在需求变更频繁的项目里，这个列表就是影响范围清单。
2.3 自定义注释字段，让规格说明跟着你的需求走
Axure 默认自带一些注释字段，例如 specification、status、benefit。这些字段来自欧美公司常用的文档习惯，直接用到国内团队里往往不太贴合。我的做法是进入右侧“annotations & interactions”面板，选择“customize fields and views”，把默认字段替换成自己的字段体系。Axure 支持的字段类型有四种：Text（大段文字）、Number（数字）、Date（日期）、Selectlist（下拉选择）。
# 一个适合国内团队的自定义注释字段配置示例 字段名：功能说明 类型：Text 字段名：优先级 类型：Selectlist (高 / 中 / 低 / 排期后备) 字段名：UI 文案 类型：Text 字段名：接口/数据来源 类型：Text 字段名：验收标准 类型：Text 字段名：备注 类型：Text这里有个容易被忽略的点：Selectlist 类型的字段可以提前维护选项值，Axure 定义每一行为一个选项。我习惯把“优先级”做成选择列表，生成文档时统一输出，避免不同页面里出现“优先级高”“高优先级”“P0”这类口径不一致的写法。设置完字段之后，还可以在 Custom Views 里组合出不同模板，比如“开发视图”只保留功能说明、接口、验收标准，而“评审视图”额外保留优先级与 UI 文案。
提示：针对页面级的注释在底部页面笔记里维护，针对部件级的注释在右侧注释与交互面板里维护，两者分开但互不冲突。生成 Word 文档时，页面笔记和部件注释会分别落到不同章节。
3. Widget 分层：线框与流程符号各司其职
3.1 把线框 Widget 按职能分成四组，内化使用边界
Axure RP 的 Widgets 面板中，线框组约二十个工具，不用死记，按职能分组后，用起来会清晰得多。我自己是按四类来理解的：内容呈现、表单录入、页面组织、特殊区域。
| 职能分组 | 主要 Widget | 使用提示 |
|---|---|---|
| 内容呈现 | image、text panel、hyperlink、placeholder、rectangle、horizontal/vertical line | placeholder 适合表达“区域复杂但本次不展开”的模块 |
| 表单录入 | text field、text area、droplist、listbox、checkbox、radio button | 列表选择框常与按钮配合，单选用 radio，多选用 checkbox |
| 页面组织 | button、button shape、menu（horizontal/vertical） | 菜单可添加漂浮的子菜单，做 hover 出现的二级导航 |
| 特殊区域 | image map region、inline frame、dynamic panel | dynamic panel 是状态切换的核心工具 |
这里想单独说一下几个容易用错的 widget。table在 Axure 里的行列操作并不顺手，扩展列宽和行高都很繁琐，所以我的原则是：表格只用来表达数据列表的字段结构，不使用它做页面布局。hyperlink和 text panel 在交互层面没有本质区别，但建议画图时还是区分开，让浏览线框的人一眼看出哪些是链接文本，哪些是普通文本。image map region用于在一张大图上创建不可见的热区，当原型里需要展示“图片上的按钮区域”时，它比直接裁剪多张图片省事得多。
dynamic panel需要重点掌握，它是 Axure 实现状态切换的主力工具。动态面板的图标本身就是多层状态叠加的示意，一个面板里可以维护多个 state，默认只显示其中一个。把按钮的点击事件绑定到动态面板后，可以在交互规则里设置切换到指定的 state。这种方式与开发中的显隐控制非常接近，开发人员看原型时也能更好地理解状态逻辑。
3.2 Flow 流程图形的符号不必死背，但要能讲清状态流转
Flow 工具组对应的流程图符号，是产品经理和开发沟通时最直接的表达手段。很多需求问题用文字讲不清，画一张流程图就能定位到边界条件。Flow 里的图形与标准程序流程图基本一致，关键符号的作用如下表。
| 符号 | 名称 | 流程含义 |
|---|---|---|
| Rectangle | 矩形 | 处理过程，在页面框架图中可代表一个页面 |
| Rounded rectangle | 圆角矩形 | 流程的开始或结束 |
| Diamond | 菱形 | 判断分支（if-then-else） |
| Parallelogram | 平行四边形 | 数据输入或确定的数据处理 |
| File | 文件 | 生成的文件或调用的文件 |
| Actor | 角色 | 用例图中的执行者，可以是人也可是系统 |
| Database | 数据库 | 数据存储 |
在半圆、三角形、梯形这些符号的使用上，团队内部应该约定一套标准并在 PRD 里声明，不必强求某一种图形在业界有唯一答案。我的习惯是：判断框必用菱形，页面跳转用带箭头的连接线，流程节点需要补充说明时用括号括起来，避免在流程图中堆大段文字。
3.3 从拖拽到命名：一组快速画原型的步骤
建立页面结构后，画具体页面遵循一个固定顺序：先框架后细节，先放置模块再绑定交互。流程参考如下。
- 在线框工作区放入主导航模块，用矩形表达板块边界。
- 在板块内按内容层级放入 text panel、image、placeholder，先不调整样式。
- 加上页面级 annotation，说明本页的入口来源和出口去向。
- 为需要交互的按钮和模块命名，遵循“页面_模块_行为”的规则。
- 下一步启动交互配置，把动态面板的状态切换挂在对应触发事件上。
这里容易踩的坑是：画图时不命名，等到配置交互时才发现所有按钮都叫“Button 1”。命名规则可以参考如下示例。
# 部件命名规范示例 btn_submit_login # 登录提交按钮 panel_form_user # 用户表单动态面板 link_goto_forgot # 忘记密码链接 img_map_banner_zone # banner 图的点击热区命名之后，生成 HTML 演示和 Word 文档时，开发读到的对象名称才具备指向性。这个过程不需要额外成本，但大量节省后续沟通中对部件的指认难度。
4. 交互规则与文档输出：把静态线框变成可演示原型
4.1 交互事件绑定：点击、滑入与动态面板状态
Axure 的交互配置集中在右侧注释与交互面板。选中任意部件后，可以为它添加交互事件——例如鼠标单击时打开链接、鼠标滑入时显示某个动态面板的指定状态。对没有编程基础的人来说，核心要理解的是“基于事件触发行为”的思路。其逻辑与前端开发中的事件监听是同一回事：先有事件源，再配置行为，最后指定目标对象。
# 一个典型交互规则的可读化描述 OnClick（鼠标单击时） 行为：Set Panel State（设置面板状态） 目标：panel_form_user 状态：State 2（提交成功提示）常见配置场景中，登录按钮的交互规则通常是这样：OnClick 时先把输入框内容与预留的校验逻辑对比，条件满足则跳转到首页，不满足则切换到“错误提示”状态。Axure 还支持条件判断，可以在交互规则里配置 if-else 分支，这已经是接近真实业务逻辑的表达方式。对于“页面载入时”的交互，在页面底部的页面载入区设置，它能控制在页面初次打开时的初始状态，例如默认选中某个 Tab、默认展开某个动态面板状态。
另外，Axure 生成的 HTML 演示是一个可点击的网页包。利用这种方式，在需求评审会上可以直接操作原型给开发演示交互路径，远好于用 PPT 描述交互行为。
4.2 F5 与 F6 的文档生成链路
交互配置完成后，文档生成是 Axure 最需要熟练使用的一环。按 F5 生成 HTML 演示文件，按 F6 生成 Word 版本的规格说明书。F5 生成的 HTML 包包含所有已配置的交互效果，可以直接分发；F6 生成时，Axure 会依据每个部件的 label 和编号，自动将注释字段整理成表格形式，这是把原型做成交付文档的关键一步。
生成 Word 文档之前，要注意“页面载入时的交互”中的设置能否与注释字段匹配。页面说明位于底部页面笔记，只支持一段文本；而部件注释支持多字段，生成时会输出更结构化的表格。我的经验是，页面笔记只写页面级说明，例如“列表页，从客户管理进入，支持按姓名筛选”，而具体字段说明全部放进部件的注释字段中，这样生成的 Word 文档才不会是“一段话到底”的结构。
4.3 生成前自检清单与常见问题
在按 F6 之前，我会先对着检查清单过一遍原型，这份清单能显著降低返工概率。
| 检查项 | 检查标准 |
|---|---|
| Sitemap 页面命名 | 全部为业务用语，避免“未命名1”“page2” |
| 页面分组 | 线框页与流程页混排时，层级正确 |
| Master 使用 | 公共区域未重复绘制，无遗漏应用 |
| 交互规则 | 每个可点击元素至少有一个交互行为 |
| 注释字段 | 每个关键部件都有功能说明和验收标准 |
生成后如果发现 Word 里注释字段没有显示出来，原因通常是字段设置在“默认视图”下，而生成配置选择了其他视图。此时回到注释面板的 Custom Views 检查当前激活的是否为包含所需字段的视图即可。这个环节熟练后，每次生成前只需要两三分钟的检查，产出的文档质量却会有明显差别。
5. 把生成的 Word 规格文档收口成团队模板
前面几章都在解决“把原型做出来”的问题，最后一章要解决的是“把原型变成能被开发直接使用的文档”。Axure 生成的 Word 文档默认结构虽然完整，但距离团队规范还有一段调整空间，我一般会做三件收口工作。
第一，统一编号与层级。生成 Word 后，先检查目录和页眉，再对章节标题的编号格式进行微调，让原型规格书的章节号与 PRD 主文档保持一致。Axure 的注释字段支持“label 标签”方式输出，也就是每个部件字段对会生成带标签的表格行，直接在 Word 里替换表格样式即可。
# 注释字段在 Word 输出时的表格结构示意 | 标签 | 内容 | | 功能说明 | 用户点击提交后校验手机号格式 | | 优先级 | 高 | | 接口/数据来源 | POST /api/user/login | | 验收标准 | 错误提示在 1s 内展示 |第二，把页面间的跳转关系写成附录。在 Sitemap 树已经清晰的条件下，用“生成流程表”命令把页面父子关系输出为流程图，再把这张图作为附录放进 Word 文档。开发在排查跳转路径时，不需要逐页翻阅原型，直接看附录就能定位页面关系。
第三，用注释字段反哺评审过程。评审时直接打开生成的 HTML 演示，右击部件查看注释，让开发在讨论现场就能看到接口字段与验收标准。如果某个模块的注释缺失，当场补齐后重新按 F6 生成文档即可。这套方式下来，Axure 不再是画草图的工具，而是把需求从口头讨论逐步固化成结构化说明的中间层。
本文还有配套的精品资源，点击获取
