企业官网建设流程全解析

团队里十个人有八个在文件名里把 Axure 拼成 “axuer”，这事我见过太多次，搜索框里搜出来的教程也一堆带着这个错拼。拼写本身不重要，重要的是它暴露了一个态度问题：很多人把原型工具当成“画图软件”，点两下能跑就算完，等到评审会上被问一句“这个筛选能按状态过滤吗”，当场卡壳。这篇就聊 Axure 里那些真正影响交付质量的部分操作——不是从零教你怎么拖一个矩形，而是把元件命名、动态面板、母版、中继器、变量函数、自适应视图、生成交付这几块里最容易出事的操作细节掰开讲。适合已经能画出页面的初中级使用者，也适合需要接手别人原型、被一堆没名字的矩形折磨过的协作者。我的判断标准很简单：一个原型能不能在别人手里被改，能不能在评审会上被追问而不崩，全看这些操作有没有做对。

1. 先想清楚原型要替谁回答什么问题

动手之前先问一句：这个原型是给谁看的。给产品内部讨论用、给开发对着做、给外部演示用，三种场景对保真度的要求完全不是一回事。给内部讨论，静态线框加几条关键跳转就够，纠结圆角和阴影属于自我消耗；给开发对着做，交互状态和边界情况必须跑通，因为开发会拿它当“需求说明书”来看，你漏一个空状态，他就自己拍一个，最后上线对不上还得返工；给外部演示，流畅度和视觉稳定性优先，这时候宁可少做两个分支，也不能点着点着白屏或者跳错页。

我见过最常见的浪费是把内部原型做成演示级，一个列表页做八种状态，结果需求改了三次，原型维护成本比写代码还高。反过来也有把演示级原型直接扔给开发的情况——开发问“点击未登录用户会怎样”，原型里一片空白，于是凭感觉加了个弹窗，上线后被投诉。所以第一个操作不是画元件，是给自己定一条线：这次只做到什么程度，哪些是必做，哪些明确不做。这条线写在页面备注里，随手可查，比事后扯皮省事得多。

版本层面，工具本身迭代到大版本更替时，文件格式和部分交互行为会有差异，团队里如果有人用旧版打开新文件，可能出现元件错位或者交互丢失。统一版本这件事在做原型之前就该定下来，别等到合并文件才发现对不上。我个人习惯是在文件首页放一个只读的说明页，写清楚版本、修改人、当前进度、已知问题，谁接手都能一眼看懂——这个习惯救过我很多次，尤其是隔了两周再打开自己的文件。

1.1 页面结构先立骨架再填肉

页面面板的组织方式直接决定了后期找人有多痛苦。我习惯按模块分组，用文件夹把“登录注册”“首页”“列表详情”“设置”这类业务块隔开，页面命名用“模块-页面-状态”的格式，比如“订单-列表-空态”。有人喜欢按用户流程命名，也行，但一定要统一，不能一半按模块一半按流程，那样左边一长串看不出门道。

顺序也值得讲究。把主流程页面放在最上面，边缘状态和异常页收进子文件夹，评审的时候从上往下点，观众跟得住节奏。把所有页面平铺在根目录，翻到第五屏才找到想要的那一页，观感是灾难性的。

2. 元件与图层面板：原型的可维护性从命名开始

一个原型能不能被别人接手，看三分钟就知道——打开图层面板，如果满屏都是“矩形”“矩形 2”“组合 3”“动态面板”，基本可以判定这文件后期没法改，谁动谁踩雷。图层顺序是按堆叠层级排的，越靠上越靠前，遮挡关系全在这里。可问题在于，视觉上完全看不出来的差异，在图层里就是一堆无名条目，你想选中被盖住的那个按钮，只能按住修饰键一层层往下点，点错三次就开始骂人。

命名这事有硬规则，我自己执行三条。第一，交互目标元件必须带前缀，按钮用btn_，面板用p_，文本用t_，输入框用input_，热区用hot_。原因很实际：交互面板里的元件下拉框是按照图层名排序的，你去绑一个动作，列表里全是“矩形 27”，找一个按钮要滚半天；加了前缀以后输入btn_直接筛出来，效率差一个量级。第二，同一层级的同类元件带业务语义，比如btn_订单_提交、btn_订单_取消，别用“主按钮”“次按钮”这种视觉词，需求一改视觉词就全错了。第三，纯装饰性的图形不命名也行，但强烈建议成组后统一叫“装饰”，或者干脆锁住，避免误选。

提示：交互动作一旦绑定了带名字的元件，后续改名会自动同步，不必担心改完名字交互断掉。真正会断的是把元件删掉重建——名字对不上，动作目标就空了，只会静默失效，不报错。这是新手最容易忽略的坑。

2.1 组合、成组与动态面板的层级差别

很多人在需要“一起移动”的时候随手就打组，结果后面想做状态切换发现无从下手，只能拆了重画。这三者的区别值得掰清楚。

组合（Group）只解决“一起移动、一起缩放、一起隐藏”的问题，它没有状态，不能被当作切换目标，也基本不承载交互逻辑。用它来整理布局是对的，用它来承载业务状态是错的。动态面板（Dynamic Panel）是有状态的容器，一个面板可以有多个状态，每个状态内部还能放任意元件，切换动作只作用在面板这一层，内部的元件跟着走。所以凡是“同一个位置、不同内容”的场景——标签页切换、弹窗显隐、加载中/有数据/空数据三态、轮播图——都该用动态面板。

判断标准我自己总结成一句话：这个区域会不会在不同时刻呈现不同内容。会，就用动态面板；不会，就用组合。把列表项做成组合然后想加选中态，只能整块替换显示隐藏，视觉上会闪，而且状态一多根本管不住。反过来，一个纯静态的页头打成一个动态面板，多一层容器，改个间距要进两层才点到，纯属自找麻烦。

2.2 热区放在哪一层决定点击能不能落到

热区（Hot Spot）是透明元件，专门用来接点击。它的坑在于层级——如果热区被上面的图片或文本盖住，点击会被上层元件吃掉，热区收不到事件。所以标准做法是把热区拖到最顶层，或者在图层里往上提。这个细节在列表卡片上特别常见：整卡可点、卡内按钮单独可点，两个热区叠着，谁在上谁赢。想做到“点卡片进详情、点按钮只触发按钮”，把按钮热区放在卡片热区上方，并且按钮的事件里不要再冒泡到卡片——Axure 本身没有冒泡的概念，一个点击只会触发它所在最上层元件的用例，所以只要层级对，行为就是确定的。

3. 动态面板的多状态思维：一个面板顶十个页面

新手做状态切换最直觉的做法是复制页面，登录前一个页、登录后一个页，购物车空态一个页、有商品一个页。页面数量爆炸，改一个公共头部要改十几遍。正确的思路是把会发生变化的区域收敛成动态面板的多个状态，页面数量控制住，公共部分只维护一份。

多状态面板的关键是给状态起名字，别用默认的“State1”“State2”。状态名会出现在切换动作的下拉里，state_空态、state_加载中、state_有数据一眼就知道该切哪个。尤其当面板有七八个状态时，全靠记顺序就等于赌博。

切换动作有三个常见写法，副作用不一样。第一种是直接在按钮上加“设置面板状态”动作，指定目标面板和目标状态。这是最直白的，也是最好维护的。第二种是把切换动作放在面板自己身上，或者用触发事件间接调用——好处是多个入口能复用同一段逻辑，坏处是链路变长，排查时要跳好几次才能找到真正的落点，团队协作时尤其折腾。第三种是用条件判断做分支，比如根据全局变量里存的登录状态决定切到哪个状态，这个后面讲变量时再展开。

3.1 面板切换后状态被“记住”的问题

有个现象很典型：同一个面板，从 A 入口进去切到状态二，退出后再从 B 入口进来，发现它还是状态二。原因是面板状态在当前会话里是保持的，不会自动回位。解决办法是在每次进入该面板的入口动作里，显式先切回初始状态，再执行后续逻辑；或者在页面载入时统一重置一遍关键面板。

另一种情况是多个用例同时作用在同一个面板上，一个要切到状态一，另一个要切到状态三，执行顺序取决于用例的排列，最后生效的那个说了算。这类问题排查起来很费劲，因为每个用例单看都没错。我的做法是给每个面板指定唯一入口，所有切换逻辑集中在一个地方，其他位置只负责触发，不直接改状态。

3.2 面板套面板的性能代价

动态面板里面再放动态面板，嵌套三层以上，预览时就能感觉到卡顿，尤其是里面还有图片和滚动区域的时候。原因是每次状态切换，容器内所有子元件都要重新计算布局和可见性。做复杂页面时我一般把嵌套控制在两层，超过两层就考虑拆成独立页面，或者用显示隐藏来替代内层面板的状态切换。

还有个隐藏问题：面板开了“适应内容大小”，再配滚动条，两者会打架——内容一多，容器跟着长高，滚动条就永远不出现，你会以为滚动坏了。需要滚动的固定高度区域，明确关掉适应内容，写死高度，这个问题立刻消失。

4. 母版是双刃剑：拖放方式选错，改一处要改十处

母版的初衷是复用——导航栏、页脚、通用弹窗、列表项模板，做一份到处用，改母版所有实例同步。听起来完美，实际上母版是原型里最容易出事故的地方，因为它的三种拖放行为决定了同步关系，选错了后期维护成本翻倍。

页头页脚这类全站统一的模块，用固定位置放置是对的，改一次全站生效。但要注意母版的位置坐标——如果母版画在画布的 (0,0)，所有实例都贴左上角，你在某个页面想让它偏移一点，改不动，只能改母版本身，然后全站跟着动。这个特性用好了是效率，用不好就是灾难。

通用弹窗和列表项模板，用任意位置放置更合适，因为每个页面里它们的位置不同。但代价是位置不再跟随母版，母版里调整了内部布局，实例内部会更新，外框位置保持你当初放的地方。

4.1 覆盖操作会静默打断同步

这是母版最隐蔽的坑。你在某个页面的实例上直接双击改了一行文字，或者调了一个按钮的颜色，Axure 会把这个改动记录成覆盖项——从此这一处属性不再跟随母版。改动本身没问题，问题是它是静默发生的，没有明显提示。等你后面在母版里统一改这行文字，全站都变了，就那一个页面不动，你还得挨个页面找是哪里被覆盖了。

排查的办法是选中实例，看属性面板里有没有覆盖标识，或者用恢复覆盖的操作清掉。我的习惯是：母版内部的文字尽量做成可由实例覆盖的占位内容，需要差异化的地方主动覆盖，不需要的地方坚决不动。刻意覆盖和误触覆盖，区别就在于你知不知道自己在干什么。

4.2 母版数量失控的后果

一开始两三个母版很好用，做到后期变成三十个，每个只用了两三次，改一个需求要判断改母版还是改实例，判断完还得确认有没有被覆盖，效率反而下降。我给自己定的门槛是：同一个结构在三个以上页面出现，才值得做成母版；只出现一两次的，复制粘贴然后各自维护更省心。这不是洁癖，是算过账的——母版的维护成本是隐性的，它集中在“你以为改了其实没改”这种时刻。

5. 点击没反应时的完整排查链路

这是被问得最多的一类问题，也是最值得写成流程的。表面上都是“点了没反应”，底层原因至少有六种，按可能性从高到低排，基本能在五分钟内定位。

第一步看层级遮挡。用图层面板把可疑元件临时隐藏，看点击是否恢复。恢复了就是遮挡问题，把热区或按钮提到最上层。

第二步看交互绑没绑对元件。交互面板里选中元件，看用例列表是不是空的，或者动作目标指向了一个已经被删掉的元件。目标丢失时用例还在，但执行无效果，界面没有任何报错，这是最容易骗过眼睛的一种。

第三步看条件判断。用例上加了条件，条件不满足就不执行，而条件依赖的变量可能压根没赋上值。把条件临时去掉试一次，能点通就是条件的问题，回头去查变量在哪一步该赋值而没赋。

第四步看面板状态。动作确实执行了，但目标面板本来就在那个状态，切过去等于没变化。或者面板被设在屏幕外、透明度为零、被其他内容盖住，视觉上看不见变化，实际已经切了。

第五步看页面载入时的用例。页面载入用例里如果有一条把面板重置回初始状态，而你手动触发的动作紧跟在后面，效果就是刚切过去又被重置。这种时序冲突在带参数的跳转里特别常见。

第六步看是否在被隐藏的容器里。元件本身可见，但它所在的父级面板是隐藏状态，任何交互都不会触发，因为根本收不到点击。这一条排查起来最费时间，因为元件自己在画布上是可见的。

注意：这套顺序不是理论推导，是踩出来的。我早期的习惯是先怀疑交互写错，结果折腾半小时发现是热区被图片盖住了——从那以后我固定先查层级，命中率最高。

5.1 一次完整排查的记录方式

我现在的做法是把排查过程写进页面的备注区，格式很简单：现象、怀疑点、验证方式、结论。比如“现象：卡片点击无跳转；怀疑：热区被图片遮挡；验证：隐藏图片层后点击恢复；结论：热区层级需置顶，已调整”。写下来不是为了给别人看，是因为同类问题在一个项目里会重复出现三五次，有记录第二次直接对号入座。

更系统一点的做法，是在原型里建一个只给自己看的“调试页”，把关键全局变量的当前值用文本元件实时显示出来，用设置文本动作同步。变量到底有没有赋上值，看一眼就知道，比猜快得多。这个调试页在交付前删掉，不影响正式版本。

6. 中继器与变量：让原型从“能点”变成“能验证”

只会做静态跳转的原型，本质上是一叠带链接的图片。真正能在评审会上扛住追问的，是能跑数据的那部分——列表能筛选、能翻页、能排序、能选中。这块的核心就是中继器和变量配合。

中继器的逻辑是数据驱动的：先给它一份数据集，每行若干列，然后在中继器的“每项加载时”事件里，把当前行的字段值写进对应的元件。字段引用用双方括号包裹行属性，比如把当前行的标题写进标题文本。数据集里加十行，页面上就渲染十个卡片，不用手动复制十次——这就是它比复制粘贴强的地方，改版式只改一个模板。

关键在于加载顺序。中继器的渲染是在每项加载时事件里逐行执行的，所以任何依赖“先渲染后操作”的逻辑都必须放在渲染完成之后。常见的错误是把筛选逻辑写在页面载入时，但页面载入先于中继器逐行加载，筛选条件根本没生效，列表还是全量。正确做法是把筛选条件挂在触发元件上，或者在中继器每项加载时里就带上过滤判断。

6.1 全局变量做筛选与分页的实操组合

一个能跑的筛选功能，需要三个东西配合：一个存放筛选关键词的全局变量、一个在中继器每项加载时里执行的过滤判断、一个触发重新加载的动作。

流程是这样：输入框失焦或者点搜索按钮时，把输入框的值写进全局变量；然后给中继器加一个过滤动作，条件写成当前行的标题字段包含该全局变量；中继器会重新逐行加载，只保留匹配的行。清空筛选就是给变量写空字符串再触发一次加载。

分页稍微绕一点。中继器自带分页设置，指定每页条数就能自动分页，翻页靠设置当前页码的动作。坑在于页码变量和筛选变量的联动——筛选之后总条数变了，当前页码如果还停在第三页，很可能翻到空页。稳妥做法是在触发筛选的同时，把当前页码重置回第一页。

6.2 页面间传参的几种做法对比

从列表点进详情，详情页怎么知道该显示哪一条，这事有好几种解法。最粗暴的是给每一行都做一个独立详情页，十条数据十个页面，数据一改全废，只适合两三条固定内容的场景。

常规做法是用全局变量传一个标识，跳转前把当前行的编号写进全局变量，详情页载入时读这个变量，再用它去中继器里定位对应行、把字段填进详情元件。这条链路长一点，但通用性强，数据量再大也不用加页面。

还有一种是用中继器自带的行标记，配合详情页通过筛选找到被标记的那一行。好处是不用额外维护变量，坏处是跨页面时标记状态不一定可靠，我一般只在同一页面内的主从联动里用它。

选择的标准很实际：跨页面用全局变量，同页面用行标记或局部变量。混着用容易出“跳过去是空白”的问题，因为详情页载入时变量还没赋值，或者值还是上一次的残留。

7. 自适应视图与栅格：一次设计多端的取舍

多端适配这块，工具能做的比想象中少。断点可以设，元件在不同视图下可以单独调位置和尺寸，但它不是响应式布局引擎——不会自动重排，也不会自动换行。想靠它一次生成手机端和桌面端两套能用的原型，基本会失望。

实际可用的做法是设两到三个断点，比如窄、中、宽，主结构在基础视图里画好，窄屏视图里把侧边栏隐藏、把横向排列改成纵向堆叠。每个断点下的调整是独立的，改了基础视图，其他视图不会自动跟着变，这是最容易踩的坑：你在宽屏视图里把一个按钮往右挪了二十像素，切到窄屏一看还在老位置，得再挪一次。所以要么一开始就把自适应视图规划好，要么干脆放弃，做两套独立页面，反而干脆。

7.1 元件尺寸的自适应与固定

元件的宽度可以设成固定值，也可以随容器伸缩。这个设置在自适应视图里尤其重要。横跨整屏的页头，宽度设为随容器伸缩；图标按钮，宽度设固定值。混着设的后果是窄屏下按钮被拉成一条，或者页头右边空出一大截。

栅格辅助线在画基础视图时很有用，设好列数和间距，主要模块对齐到栅格，后面切视图时位置关系不会乱得太离谱。但它只在你手动摆放时起作用，不会自动吸附重排，别指望它帮你完成适配。

我的建议很直接：如果项目只需要交付桌面端，自适应视图这一整块可以跳过，省下的时间拿去打磨交互状态更值。如果确实需要移动端预览，优先做一套精简的移动版页面，共用母版和全局变量，比在一个页面里塞三套视图好维护得多。

8. 生成与评审：问题总在最后一刻集中爆发

生成 HTML 原型这一步，看着只是点个按钮，实际上问题密集出现。最典型的是双击生成的入口文件打开后一片空白，或者样式全丢、图片不加载。原因通常是直接用了文件协议打开，浏览器对本地文件的加载有限制，一部分资源请求被拦了。稳妥的做法是在输出目录里起一个本地静态服务再访问，比如在目录下执行一条简单的命令：

python -m http.server 8000

然后从本地地址访问入口页。这样资源按正常路径加载，链接跳转、字体、图片都正常。交付给外部评审时，压缩成包发给对方，同样提醒对方用本地服务打开，不然对方第一眼就是白屏，解释成本比交付本身还高。

8.1 评审现场最常被挑的三件事

第一件是空状态和异常状态缺失。列表没有数据时长什么样、加载失败时提示什么、输入超长时怎么截断，这些在画原型时最容易被跳过，评审时又最容易被追问。补起来其实不难，动态面板多做一个状态就行，但前提是你得想到。

第二件是返回路径。评审的人会随手点返回，然后发现回不到上一页的原始状态——比如从筛选后的列表点进详情，返回后筛选条件没了。要解决就得靠全局变量把筛选条件存下来，返回时读回来重建。这一条做完，原型的可信度会明显不一样。

第三件是命名和备注。开发对接时会问“这个按钮点了之后调用哪个接口、失败了怎么提示”，原型里没写就只能开会再对一遍。我的习惯是在关键交互元件的备注里写清楚触发条件和预期结果，成本很低，省下的是整场会议的时间。

8.2 文件本身的交付习惯

交付前做三件事：把调试用的辅助页和隐藏页面删掉或归档；把没用的母版清理一遍，避免别人打开看到三十个残留母版不知道哪个在用；在首页写一版变更说明，记录这一版改了什么、还有哪些待定。这三件事加起来十分钟，能省掉对接方半小时的猜测。

文件命名也值得说一句，别用“原型终版”“原型最终版”“原型真的最终版”这种，用日期加版本号，比如“订单模块-20240312-v3”。谁都知道最终版之后还有最终版，日期才是唯一可信的坐标。

最后分享一个我用了很久的小习惯：每做完一个模块，关掉文件重新打开一次，从第一个页面点到最后。很多状态残留、变量没初始化、跳转断链的问题，只有走完整流程才会暴露，而你在编辑状态下反复点同一个按钮是发现不了的。这个动作花不了几分钟，但拦下来的问题，往往就是评审会上最尴尬的那几个。