企业官网建设流程全解析

做产品原型这几年，我换过不少工具，最后在团队里稳定下来的还是Axure RP 9。原因倒不是因为它最新或者最“酷”，而是因为原型这件事，最核心的需求不是“画得好看”，而是“能讲清楚逻辑、能模拟交互、能让开发和测试看得懂完整路径”。Axure RP 9在这三个维度上恰好都踩在点子上，尤其当你面对复杂的状态切换、条件判断、列表增删改查这类硬核逻辑时，用它来画原型图，比一堆静态切图加文字注释要高效得多。

这篇文章不是工具文档的翻译，也不是官网教程的“复读”，而是我从实际项目里整理出来的一份Axure RP 9使用笔记。内容包括从画布设置、页面架构、组件复用，到交互面板的机制理解，再到中继器、弹窗、轮播、标签切换这类高频场景的实操步骤，最后还有交付前踩过的各种坑。适合刚接触Axure的初级产品经理，也适合那些已经能画静态页面、但一碰到交互就发怵的同行。如果你能把这篇文章里的内容消化掉，日常80%以上的原型需求基本都能独立拿下了。

1. 为什么是Axure RP 9？从工具选型聊聊原型这件事

1.1 原型工具的取舍逻辑

很多刚入行的朋友第一个问题通常是：现在大家都在用Figma、Sketch，会不会比Axure更香？我用过一段时间Figma做UI稿，也用它做过一阵子交互原型，但最后在中大型Web系统、后台管理类项目上，我还是会切回Axure。原因很简单：Figma和Sketch的优势在设计协同和视觉还原，而Axure的优势在逻辑模拟和信息架构演示。

拿后台管理系统举例，权限不同的人看到的菜单不同，表单填错时要有校验提示，列表数据要能筛选、排序、分页，这些在Figma里要么靠插件、要么靠大量画板串联，操作成本和维护成本都很高。在Axure里，一个动态面板加几个事件就能模拟出来，而且逻辑是“真实可点击”的，评审会上现场演示，比嘴上讲“这里点击会弹出”有说服力得多。

再说Sketch，它一直偏静态视觉输出，交互能力基本要依赖第三方工具，交互链路一多就断层。Figma的Prototype功能这几年进步明显，但它的交互模型仍然偏向页面跳转和简单的固定面板切换，遇到中继器那种数据驱动的列表渲染逻辑，Figma就力不从心了。Axure的中继器功能，相当于是原型工具里的“迷你数据库”，你可以往里面塞真实的数据结构，再通过交互规则渲染到画布上，这份能力在当前的同类工具里仍然是稀缺的。

所以我一般不建议团队把“唯一工具”作为目标，更合理的分工是：视觉设计稿交给Figma，逻辑原型、复杂交互、需求评审用的可点击Demo交给Axure RP 9。

1.2 RP 9相对RP 8的变化，为什么值得升级

如果你是老Axure用户，可能还在用RP 8。我的建议是尽早迁到RP 9，尤其是团队协作的项目。RP 9重做了交互面板，从以前那种稍显“工程师风格”的规则列表，变成了更接近流程图思维的“事件—条件—动作”结构。虽然刚上手会觉得不习惯，但用熟之后，配置复杂交互的速度明显更快，而且出错的概率更小。

RP 9另一个重要变化是部件库和样式检查器。左侧的样式检查器把填充、边框、阴影、圆角、排版这些属性集中管理，改起来比RP 8直观很多。对于原型图来说，这直接影响了出稿效率。以前在RP 8里调一个按钮的投影，要弹好几层窗口，现在右侧面板直接改，几秒钟的事情。

还有一点容易被忽视：RP 9的元件拖动和画布刷新更流畅，页面多、组件多的时候，不再像RP 8那样频繁卡顿。这点在你做整套系统原型时会感受很深，几十个页面来回跳转能明显感知到差异。

1.3 学习成本与授权，先说实在话

Axure RP 9不是免费软件，商用场景基本都是付费授权。别在网上找那些不明渠道的所谓“绿色版”“破解版”，一方面是有很大的法律风险，另一方面是破解版经常被植入奇怪的脚本，做原型的时候突然弹广告，甚至可能把案例数据传到别人服务器上，这其实是一个很大的安全隐患。

如果你只是个人学习，官方有试用期，找一个给自己“30天专项训练”的阶段，每天花2小时，把每个部件和交互都试一遍，足够你判断这个工具是否适合自己。如果是公司采购，就更不用纠结，团队协作时需要统一版本，否则互相打开文件之后样式错乱、交互丢失，反而浪费更多时间。

2. 画原型前的底层准备：页面树、母版与组件库

很多人打开Axure就开始往画布上拖组件，画完一屏是一屏，结果页面多了之后，光找文件位置就要花半天。我给你一个建议：在画第一根线条之前，先把页面树搭好。

2.1 先把页面树搭对，交互管理才不乱

Axure左侧的Pages面板不是简单的文件列表，它是整个原型的“地图”。我的习惯是，接到需求后先不看细节，先把信息架构盘一遍，然后在Pages面板里按模块建层级目录。比如做一个电商App，我会建“首页”“商品列表”“商品详情”“购物车”“结算流程”“个人中心”几大目录，每个目录下再按实际页面拆分。

页面命名的规范也比很多人以为的重要。千万不要叫“页面1”“页面2”，至少要体现业务含义，比如“PDD-商品列表-筛选态”“PLP-搜索结果-空态”。这有两个好处：一是你自己在几十个页面之间跳转时不迷路；二是交付给开发时，对方能根据页面名称快速对应到具体的路由或页面文件。开发看到“页面1”的时候，心里是真的会骂人的。

页面树搭好了，后面配置交互的时候也会顺手很多，因为Axure里的“打开链接”事件需要从页面树里选择目标页面，页面名字清晰，配置时一目了然，不用靠猜。

2.2 母版不是模板，是“同一件事只维护一次”

母版大概是Axure里被低估得最严重的一个功能。很多人从头到尾没用过母版，每个页面都手动复制一份导航栏、顶部栏或者弹窗，然后某天产品经理过来说“导航栏的菜单文案要改”，你必须一个个页面去改，改到怀疑人生。

我平时一定会把两类内容放进母版：全局导航和通用弹窗。

全局导航包括顶部栏、侧边栏、底部Tab栏，这些组件在每个页面里都出现，而且往往带选中态。母版做一次，所有引用它的页面自动更新，选中态也可以用母版的“状态”来管理。比如侧边栏有5个菜单项，我给母版设置5个状态，每个状态对应一个菜单的选中态，然后每个页面引用母版时选择对应状态，整个系统的导航体验就非常完整。

通用弹窗，比如删除确认框、操作成功提示、全局的“加载中”遮罩，这些也放进局部母版。用局部母版的好处是，它在发布后的HTML里会被当作一个公共区域加载，不会在每个页面里重复生成一堆节点。

刚开始你可能觉得做母版是在“浪费时间”，但当页面超过20个、需求进入频繁调整期时，母版节省的时间会成倍放大。我建议你从第一个正经项目开始就养成用母版的习惯，后面真的会感谢自己。

2.3 自建组件库，界面规范从源头开始

Axure RP 9自带的默认组件库已经够用，但如果你的团队或者公司有自己的设计规范，我更建议你自建一套常用的组件库文件，保存为.rplib格式，然后贡献给团队使用。

自建组件库包含什么呢？我一般会收集按钮（主按钮、次按钮、危险按钮、不可用按钮）、表单输入框、下拉选择器、弹窗、标签、提示框、分页器、表格行等等。每一个组件尽量把长宽、字重、字号、圆角、阴影都固定好。这样你在画原型时直接拖出来就是符合规范的，不用每个页面重新画一次。

这套组件库还可以和设计团队规范做同步。视觉同学更新了按钮圆角或主色值，你也在组件库里同步更新一下，后面画出来的原型和最终UI稿就不会差太多，评审会上的胶着时间也能少一些。

3. 静态绘制阶段的具体操作：画布、尺寸与排版技巧

静态页面绘制是整个原型的基础。这里我强调的是“效率”和“规范”，而不是美术能力——原型图的职责是把信息结构和布局表达清楚，不是做高保真视觉稿。

3.1 新建文件的页面尺寸设置

新建文件的时候，Axure默认的页面尺寸是自适应浏览器的宽度，但如果做移动端或固定宽度的Web端，最好先手动设置页面尺寸。

我在做Web后台时会先把页面宽度设为1440px，页面高度设为自适应（勾选“自动填充内容高度”）。1440是当前主流笔记本的分辨率宽度，后台类系统采用这个宽度做基准，评审的时候浏览器打开不需要横向滚动条，体验最稳。如果做移动端，则直接选iPhone 12/13类尺寸，375x812，后面适配时再用自适应视图去处理不同机型。

需要注意，页面尺寸不是死板的。很多实际项目会要求同时适配1366和1920的屏幕，这时候不要直接把画布拉宽，正确的做法是用“自适应视图”功能来解决问题。

3.2 网格、辅助线与对齐分布：让界面不随缘

稍微有一点追求的原型，都不该出现元素之间“肉眼对齐”的情况。Axure RP 9的画布默认显示网格，但16px的网格对于界面排版来说太粗了。我习惯把网格间距设为8px，这样所有组件都按8的倍数进行排布——左右边距16px、栅格间距8px、卡片内边距24px，整体层次会非常统一。

画布顶部和左侧的辅助线也值得熟练使用。按住鼠标从标尺拖出来就能生成辅助线，在你需要做栅格系统或者对齐多个卡片时非常有用。比如做一张商品列表页，我先把左侧边栏宽度拖到240px辅助线，内容区再给左右各留16px的辅助线，后面所有组件都往这个“安全的框”里放，整体结构不会乱。

对齐和分布功能在顶部工具栏上：“左对齐”“水平居中”“等高”“垂直平均分布”。选择多个组件后快速点一下，组件位置立刻规整。我见过不少人在画布上纯靠手动拖动来对齐，每次都要反复微调。其实多选后点几下对齐按钮，三秒钟就能做到像素级整齐，何乐而不为呢。

3.3 格式刷与快捷键，提效的好帮手

Axure RP 9有格式刷，位置在工具栏上，选中一个设定好样式的组件，点击格式刷，再点击目标组件，样式就复制过去了。如果是批量修改，双击格式刷可以连续应用，改完按Esc退出。这个功能我在批量调整按钮样式时几乎离不开。

快捷键方面，记住几个高频的就行：Ctrl+D复制，Ctrl+G组合，Ctrl+B置于底层，Ctrl+Shift+[和Ctrl+Shift+]，分别是上移/下移一层。还有一个很实用的是Ctrl+K，在Axure里可以快速给选中组件创建动态面板。实际操作时，最常用的操作路径基本都靠快捷键，鼠标只负责拖拽和画线。

3.4 自适应视图与浏览器适配

经常有人搜“Axure RP 9 画布怎么适应浏览器”，说的就是自适应视图。默认情况下，你发布HTML后，页面是固定宽度的。如果内容区宽度超过浏览器窗口，就会出现横向滚动条，这在小屏笔记本上特别明显。

Axure的“自适应视图”机制，可以理解为：针对不同浏览器宽度，给同一个页面配置不同的样式覆盖规则。我在做Web后台时，通常会建立两个自适应视图：一个针对1024-1366px的小屏，元素略微收缩；一个针对大于1440px的大屏，内容区自动拉伸。

配置方式是在页面底部工具栏点击“自适应视图”按钮，选择“创建自适应视图”，设置断点范围，然后在这个视图里调整组件布局。需要注意，自适应视图不是另画一个页面，它还是同一个页面，只是根据窗口宽度切换布局规则。调试的时候，直接用浏览器窗口拉伸看效果就好。

4. 交互机制的本质：事件、条件、用例与动作

很多人在Axure里“不会做交互”，其实是没理解交互面板的组织逻辑。Axure RP 9里的交互不是一个按钮对应一个结果那么简单，它是基于“事件—条件—用例—动作”四层结构的逻辑引擎。把这套机制弄懂后，再复杂的交互都可以拆解成一条条规则来实现。

4.1 交互面板的四层结构

当你给任意组件添加交互时，右侧会打开“交互”面板。点击“新建交互”，看到的第一层是“事件”，比如鼠标单击、鼠标移入、载入时、键盘按下等。事件相当于触发点。

在事件下面，你可以创建多个“用例”。用例的核心作用是做条件分支。比如“鼠标单击”这个事件下，我能添加两个用例：第一个用例的条件是“当前状态为未选中”，动作为“切换到选中态”；第二个用例的条件是“当前状态为选中”，动作为“切回未选中态”。这样同一个按钮就实现了“点击一次切换状态”的效果。

每个用例下面可以添加多个“动作”，比如“显示/隐藏”“设置文本”“设置选中状态”“打开链接到某个页面”等。动作是实际发生的事，可以同时配置多个，Axure会按照你添加的顺序依次执行。

我的建议是，配置复杂交互时先在纸上（或者脑内）过一遍完整的触发链，再动手在面板里配置。否则很容易出现“先隐藏了A再设置B文本，结果因为顺序搞反，演示时画面闪一下”这类低级问题。

4.2 条件判断：用“用例”实现if-else逻辑

Axure里的条件判断，本质上就是多个用例的配合。每个用例都可以设置条件，比如“如果查询关键词不为空”“如果变量等于1”“如果文本元件的内容长度大于0”。

以登录表单为例，当你点击“登录”按钮时，可能要判断账号是否为空、密码是否为空、账号密码是否匹配。这三个判断就是三个用例：

用例一：条件为“文本框内容为空”，动作是提示“请输入账号”。

用例二：条件为“密码框内容为空”，动作是提示“请输入密码”。

用例三：无条件（或其他条件都不满足时），动作是跳转到首页。

而不为空、匹配等的判断条件，在用例的“条件生成器”里可以从左侧选组件或变量，右侧选判断条件，设置得非常细致。比如判断某个输入框的文本是否为空，需要选中文本框部件后，选择“元件文字”“不含”“空值”这样一层一层去设定，所以要先熟悉每一个组件能暴露哪些属性。

4.3 动态面板与状态：Axure交互的灵魂

如果说只能选一个Axure功能来精通，我一定会选动态面板。动态面板可以理解成“一个带有多个画面状态的容器”，它能在不跳转页面的前提下，切换容器内显示的内容。实现弹窗、抽屉、标签切换、轮播图、下拉菜单，靠的都是动态面板的状态切换。

动态面板的状态可以在右下角的“状态管理”里添加。每个状态里面可以放置任意组件，包括另一个动态面板。比如做一个“抽屉从右侧滑出”的效果：动态面板有两个状态，“默认”和“展开”，把面板固定在页面右侧且初始在屏幕外，点击“展开”后切换到展开状态，再配合动画“向右滑动”，就生成了你常见的抽屉效果。

动态面板还有一些容易被忽略的属性，比如“固定到浏览器窗口”。勾选后，这个面板无论页面怎么滚动，都固定在浏览器可视区的某个位置。做弹窗遮罩、顶部导航、底部悬浮按钮时，这一项几乎是必须的。

4.4 用例执行顺序与等待时间

一个事件下如果有多个用例，执行顺序按照用例在面板里的排序从上到下进行。一般满足条件的用例执行后，后面的用例就不会再执行了，这很接近编程里的if-else if语义。

有些场景下，你需要让某些动作“等一会儿再发生”，比如弹窗显示1秒后自动消失。这时候就需要在用例里设置“等待时间”动作。添加动作时找到“其他”分类下的“等待”，设定毫秒数。等待动作是很实用的，但要注意别滥用。等待时间设置过长会让人在演示时产生“是不是卡了”的错觉，我一般习惯是轻提示类自动消失用1500到2000毫秒，页面提示类用500到800毫秒。

还有一点和动画有关：动态面板切换状态时可以设置动画方向和时长。弹窗淡入我习惯用300毫秒的Fade，抽屉用400到500毫秒的左右滑动，时间过长则显得拖沓，过短则看不见效果。这些动画参数没有统一标准，但最好在项目里保持一致，形成统一的手感。

5. 高频需求逐例拆解：标签切换、弹窗、轮播、锚点

这一节我选了四个在实际项目中出现频率最高的交互场景，把操作路径一步一步拆开。你跟着做一遍，之后遇到类似的交互需求，基本都可以举一反三。

5.1 标签切换：状态与选中样式

标签切换，比如一个商品详情页的“商品介绍”和“用户评价”两个Tab，点击后下方内容跟着变。

我的实现方案是：先准备两个内容区域，分别做好内容，命名为“内容A”“内容B”。准备两个标签按钮，命名为“Tab1”“Tab2”。然后全选Tab1和Tab2，右键“创建动态面板”，把两个标签放进同一个动态面板的不同状态里，这样能更好地管理选中态。

交互配置如下：

“Tab1”的鼠标单击事件里，添加用例：设置“内容面板”为状态“内容A”，同时设置自身为选中态，Tab2为取消选中态。

“Tab2”的鼠标单击事件里，做反向操作。

这样点击Tab，下方内容即时切换，标签选中态也同步更新。如果Tab很多，比如5个以上，可以利用动态面板的状态切换来管理，而不是堆一堆事件，管理起来会轻松很多。

5.2 弹窗与遮罩：层级原理和关闭交互

弹窗是高频需求，很多人问为什么弹窗出来之后还能点后面的按钮，本质上就是遮罩层级和交互覆盖的问题。

我的方案是做一个“弹窗容器”动态面板，里面放两个子状态：默认态为空，弹窗态包含“遮罩层＋弹窗主体”。需要注意的是，遮罩层一定要覆盖整个页面可视区，所以动态面板要选择“固定到浏览器窗口”并让尺寸等于浏览器窗口的100%。

点击“打开弹窗”按钮时，将弹窗容器面板切换到“弹窗态”，并设置动画“淡入”300毫秒；点击弹窗右上角的“关闭”按钮或遮罩空白区域时，再切回“默认态”。

在遮罩空白区域关闭弹窗，我通常是在遮罩层上设置“鼠标单击”事件：如果“当前元件”处于“可点状态”，则切回默认态。这里有个容易踩的坑：遮罩层铺满全屏后，弹窗主体会被遮罩盖住，导致弹窗内部的按钮不能点击。正确做法是弹窗主体的层级要高于遮罩层，也就是把弹窗主体放在动态面板里较底层的索引，或者让弹窗主体不被遮罩层包含，直接作为动态面板中的另一个元素放在遮罩层上方。

简单说，动态面板内部的组件可以设置层级关系，确保弹窗主体在遮罩上方即可正常点击。

5.3 轮播图：自动播放结合动态面板循环

轮播图的核心不是“切图”，而是“自动播放”和“状态循环”。

先把轮播图的内容做进动态面板的多个状态，比如“图1”“图2”“图3”。然后给这个动态面板增加“载入时”事件，添加用例：设置面板状态为“下一状态”，循环条件设置成“向后循环”，勾选“从不停止”，在“间隔时间”填写3000毫秒，动画选择“向左滑动”，时长500毫秒。这样，页面一加载，轮播图就会自动切换。

你在设置下一状态时，选中“下一状态”后，把“自动循环”和“循环间隔”都设置好，Axure会自动做无限循环。这就省去了“最后一张切回第一张”的额外处理逻辑。

如果想手动点击左右箭头切换，再给箭头设置“鼠标单击”事件：设置面板状态为“上一状态”或“下一状态”，选择相应的滑动动画即可。加上指示器的处理逻辑就是指示器的小圆点需要跟随当前状态变化，这个通过给每个圆点设置不同的选中态，再根据当前轮播状态动态设选中态来实现。

5.4 锚点跳转与页面滚动

长页面的锚点跳转，在Axure里的实现和Web里的锚点逻辑类似。先给目标区域一个命名，比如“支付说明”“配送说明”，然后在交互里选择“滚动到锚点链接区域”，选择目标元件，设置“垂直滚动”，最后设置动画为“缓入缓出”，时长500毫秒。

这里有个要点：锚点跳转时，滚动到的位置是该元件的顶部边缘。如果页面有吸顶的导航栏，目标组件会被导航栏盖住一部分，影响阅读。解决方法也很简单：在目标组件上方放一个无形的占位元件，把它作为锚点目标，让页面滚动到占位元件的位置。

另外，Axure也支持“窗口滚动”事件，基于滚动的距离来做“返回顶部按钮渐显”之类的效果，这个场景多用于做信息流类或长表单页面。

6. 用中继器把原型做成“能用的系统”

中继器是Axure里最接近“编程思维”的功能，也是很多人学Axure时觉得最难啃的部分。但一旦你理解了它的数据模型，原本需要靠几十个页面堆出来的“假列表”项目，它能让你用相当于一个页面的工作量就做出来。

6.1 中继器是什么：数据表和模板

中继器本质上是一个“数据表 + 渲染模板”的集合。你可以在中继器的“数据集”里定义字段，比如商品名称、价格、库存、封面图URL、状态字段；然后在画布上设计一行列表项的模板，把模板里的文本绑定到数据字段上。发布后，Axure会读取数据集里的每一行数据，自动按模板渲染成列表。

听起来很像前端框架里的v-for对列表的遍历，对吧？理解了这个模型，后面所有中继器玩法就通了。

新建中继器后，双击进入中继器的内部编辑模式，里面只有一个默认的“Item”。你可以在这个Item里面排版，再把文本元件关联到数据集字段。比如放一个“商品名”文本，在右侧检查器里点击“编辑文本”，选择“插入变量或函数”，找到“Item.商品名称”，这样文本就会随着当前行数据变化。

6.2 列表展示、新增与删除

用中继器做数据列表，最大的好处是“增删改查”都是动态的。

做“删除”功能时，中继器有一项“删除行”动作，用它可以删除当前行数据。一般来说，你会给列表项的“删除按钮”添加上“鼠标单击”事件，设置“删除行”，目标为“当前行的中继器”，条件设为“当前上下文行”。这样就能实现点击删除按钮移除某条数据。

做“新增”功能时，先做个表单页面，输入商品名称、价格等信息；点击“保存”时，添加“添加行”动作，把输入框的值作为数据集字段的值写入中继器。新增的行会自动渲染到列表里，刷新后依然存在。这个过程和操作数据库很像，做久了你会发现自己其实在原型工具里给后端写了个“Mock接口”。

6.3 筛选与搜索

中继器最吸引人的能力之一是，它支持条件筛选。你可以给搜索框设置“文本改变时”事件，添加“移除筛选”动作，然后再添加“添加筛选”动作，设置的规则是“商品名称包含 搜索框的文本”。

这里条件生成器的逻辑是：当某一行数据的“商品名称”字段包含搜索框文本时，保留这一行；否则隐藏。通过这样一个条件，就能实现常见的关键词实时搜索效果。

要注意的是，中继器筛选可能重叠叠加。在设置新筛选前，最好先“移除所有筛选”，否则之前添加的筛选规则和新的筛选规则会一起作用，结果看起来就像数据越来越少。这个坑我第一次用时踩过，数据没查出来，还以为中继器坏了。

6.4 分页与性能注意点

中继器数据量很大的时候，比如超过一两百行，每次刷新都会有一些性能损耗，尤其加载图片较多时会变卡。这时候要做两件事：首先是给中继器分页。中继器属性里自带“每页项目数”设置，配合首页、上一页、下一页、尾页按钮的交互，就能实现分页浏览。很多后台列表原型都用得上。

其次，如果业务场景需要加载大量数据，比如上千行，那说明原型已经达到了它的承载上限，别死磕。我一般会在原型里用“示例数据20条 + 分页”的方式来模拟，并跟开发说明“这里模拟每页20条，真实逻辑由后端分页”。原型做到能清晰表达规则即可，不需要真的承载几万条数据，那不是Axure该干的事。

7. 从交付到评审：预览、导出与团队协作的实战细节

画完原型，不意味着工作结束。如何把原型高效地展示给团队、交付给开发，同样考验基本功。我见过不少原型做得好但不会“演示”的人，评审会上不是这里点不了，就是那里显示不全，非常可惜。

7.1 浏览器预览与画布尺寸适应

很多人第一次用RP 9预览时都会遇到一个问题：浏览器打开后，画布只有一部分显示在左上角，旁边空出一大片，或者内容超出屏幕需要横向滚动，展示效果很不理想。

这是画布尺寸和浏览器窗口尺寸不匹配的原因。想要让画布自适应浏览器，最稳妥的办法是给页面设置“自适应视图”，尤其是针对不同窗口宽度，把断点配置好。如果你只是临时预览，也可以在“预览”面板里选择合适的设备类型，比如“桌面浏览器”“平板““手机”，Axure会把画布按对应设备的宽度来渲染。

还有一个高频场景：在办公室投屏评审时，投影仪分辨率通常不高。预览前我习惯先把预览窗口设置到合适的分辨率，或者直接最大化预览窗口，避免页面一部分离开可视区域。另外，评审前一定要花几分钟把原型从头到尾点一遍，确保每个交互在当前版本里都正常，尤其是动态面板状态之间切换、中继器加载这些容易因为误操作而“丢样式”的地方。

7.2 HTML导出、Chrome预览和ActiveX控件提示

Axure RP 9发布HTML后，默认情况下双击HTML文件用浏览器打开就能正常演示。但有一些公司内部浏览器环境或者IE兼容模式下，打开时会出现一条关于ActiveX控件和本页面其他部分交互可能不安全的提示。

这条弹窗看着吓人，其实一般是浏览器安全级别设置导致的。正常文件是Axure生成的JS和HTML，并不是真正危险的内容。如果评审时遇到这种提示，最简单的处理方法是直接使用Chrome、Edge这些现代浏览器打开。如果你需要让团队统一使用某个浏览器，也建议在分享说明里写清楚“请用Chrome或Edge访问”，能省掉很多不必要的沟通。

如果公司环境里必须用某些浏览器，我建议在发布HTML时，把生成的文件整体打包发到内网服务器或Axure Cloud，然后把访问链接分享到群里。直接发送本地HTML文件会存在脚本安全提示，而通过URL访问则不会触发这类拦截。这个细节在跨部门协作时特别值得注意。

7.3 团队项目协作与版本管理

RP 9提供“团队项目”功能，可以让多人同时编辑同一个原型文件。不过我用下来有一个比较深的体会：团队项目的核心冲突是“谁在改哪个页面”，如果大家都随意编辑同一个页面，图表锁定和冲突合并会消耗不少精力。

我建议团队里实行“模块认领制”。比如A负责首页、购物车模块，B负责个人中心和订单模块，C负责后台管理端。每个人各自编辑自己负责的页面，定期同步一次。Axure团队项目里也支持“获取所有更改”和“提交所有更改”，同步前最好先看看别人的提交说明，别盲目覆盖。

个人项目我用的是“版本命名+日期”的方式来管理。比如“电商后台-需求评审-v3-20250118.rp”，每次大改动前复制一份保存，万一改崩了还能回滚。这个习惯看似原始，但在没有完善版本库的公司里，比什么都管用。

7.4 与开发沟通的标注与交付细节

原型交付给开发，通常不只是丢一个HTML链接就完事。我更推荐在Axure里给关键页面增加“交付说明”层，用文本注释把隐藏逻辑、异常边界、字段格式约束写清楚。比如某个输入框限制11位手机号、某个按钮在空状态下置灰不可点击，这些信息用文字在原型里标注，开发在预览时点开就能看到，不需要反复来回询问。

页面尺寸的标注也很重要。如果你做的是Web端，可以在页面画布外用矩形做一个“标注说明区”，把页面的栅格宽度、间距、默认字体大小直接写出来。开发开评审会时看到清清楚楚的数据，比他们自己拿像素尺量快得多。

另外，我强烈建议在原型交付时附上一份“交互说明文档”或在首页区域整理一个“全局交互说明”，说明哪些地方用到了动态面板、哪些地方用了中继器、哪些交互是模拟数据，方便开发理解原型的边界。尤其要说明“这部分是模拟，真实逻辑以接口文档为准”“这里仅演示前置状态，未覆盖异常场景”，这样开发不用对着原型猜你的意图。

最后再分享一个我个人的习惯：每次项目做完，我都会把原型里用过的高频交互组件整理成一个“交互模板库”。比如弹窗、下拉筛选、标签切换、表单校验、轮播图、中继器的增删改查，全部从最终文件里抠出来放到一个干净的模板文件里，下次新项目直接复用。这件事看起来是给自己“偷懒”准备的，但坚持几期之后，你画原型的速度会肉眼可见地提升一大截。团队里其他同事如果也照着你的模板做，整体交付质量都会被拉高。这也是我为什么一直在跟团队强调，好的原型工具和好的工作方法配合起来，才能真正体现价值。