做产品原型做了这么多年，Axure RP 一直是我主力工具，而 Axure Share 这个云端功能，说实话最开始我是抗拒的。原因很实际：原型传到别人的服务器上，心里总不踏实；再加上早年间网络环境不算稳定，上传到一半卡死、客户打开白屏的场面我也没少经历。可后来团队异地协作越来越多，评审也从线下搬到了线上，硬着头皮把整套工作流迁到 Axure Share 上，跑完两个完整版本周期之后，我只能说真香。今天这篇东西不打算复述官方文档，就说说这两年我在发布、权限、评论、问题排查上实打实踩过的坑，以及沉淀下来的一套流程。正在用或者准备用 Axure Share 的朋友，应该能从里面看到不少熟悉的场景。

如果你和我一样，是产品经理、交互设计师，或者在一个小团队里既出需求又画原型，那这篇基本可以当避坑指南看。Axure Share 要解决的底层问题只有一个：把原型从“发文件”变成“发链接”，再围绕这条链接把评论、版本、权限和团队协作全部串起来。这个定位想清楚之后，很多看似奇怪的功能和限制其实都能理解。接下来我尽量按实际使用顺序来写，从交付场景一路讲到问题排查。

1. 先说清楚：为什么原型的交付不能只靠发文件

1.1 本地文件交付的三个老大难

困难一：文件本身太重，传起来费劲。
用 Axure 做中大型后台原型，一个 .rp 文件动辄几十兆甚至上百兆，里面还经常挂着高清截图和大图片。以前给客户交付原型，要么压缩成 zip 再走邮件，要么通过即时通讯软件传。大文件传到一半失败是常态，接收方那边还得等下载，然后本地装 Axure 才能打开。麻烦不说，客户也不见得会装软件，很多时候明明只想看个交互效果，最后却变成了一场安装指导大会。

困难二：版本管理靠文件名，早晚要乱。
我见过最夸张的命名是“后台 v2 最终版 修改版 绝对不改 3”这种。只要评审来两轮，文件就会裂生出十来个副本。更坑的是，不同人手上拿的版本可能不一样——产品看的是一版，开发用的是另一版，测试拿着第三版去写用例，整个流程从源头就歪了。文件名后缀救不了流程，它只会制造更多误会。很多时候争论半天的“你说的是老版本吧”并不是玩笑，而是每天都在发生的真实闹剧。

困难三：导出 HTML 并不像想象中那么省事。
Axure 可以导出 HTML 原型，但导出物是一堆网页文件和资源目录，很多非技术背景的客户根本不知道点开哪个文件；双击本地 HTML 后浏览器限制、交互报错等问题也经常冒出来。哪怕放到内部服务器上，更新一次还要重新导出、重新传，一个人维护起来也很费时间。更不用说多人评审时每个人打开的页面可能不一致，出了问题还要逐个去抠是哪个版本的问题。这个方案作为兜底没问题，作为日常流程就太累了。

1.2 Axure Share 把交付方式简化成一条链接

Axure Share 是 Axure RP 自带的云端托管服务。在软件里把原型“发布”出去之后，它会生成一个短链接，任何人拿到这条链接，用浏览器打开就能直接看。所有交互跳转、动态面板、中继器渲染基本都能保留，不需要安装 Axure，也不需要下载一堆文件夹。如果一定要类比，那就是以前你得把原型做成一个产品实物，把实物搬到对方面前给他看；Axure Share 等于你租了一间展示厅，把原型摆好，然后只给对方一个门牌号。门牌号不变，里面的展品随时可以换，看完想留意见也有地方写。

不过有一点要拎清楚：Axure Share 更偏重“展示、放映、协作批注”，它不是实时多人协作编辑器。同一个文件要多人分工一起画，走的是团队项目模式，那相当于把同一份设计稿放到公共画板上，大家分批去改。这两者我在后面的章节会分开讲，别一上来就混在一起，否则你会发现很多操作对不上。

2. 从文件到链接：发布原型的完整实操流程

2.1 发布前的三个准备工作

磨刀不误砍柴工，发布前我会花 10 分钟做三件事。

第一，清理页面结构。把所有临时草稿页、废弃页面拖进专门的归档文件夹，没有用的页面直接删掉，留下评审真正需要的页面。页面命名也要检查：不要用“page1”“未命名”这类名字，评审者进入原型后第一眼看到的就是页面列表，命名混乱非常影响观感。如果某几个页面还没做完，与其让它们暴露在链接里，不如统一收进归档文件夹，等做完再放出来。

第二，压缩图片资源。很多原型卡顿都是图片体积撑出来的。正文规范里尽量使用压缩后的图片，对背景图、高清截图先压一轮再导入，能把整个 .rp 文件体积降下来不少。比如一张 2MB 的截图压到 300KB，肉眼基本看不出差异，但发布和加载速度会差别很大。尤其是页数多的后台原型，图片不压缩，后面发布时大概率会在上传阶段吃苦头。

第三，在 Axure 里先完整预览一遍。尤其是涉及动态面板状态切换、中继器筛选、文本框输入等逻辑的页面，逐条点一遍。这个环节能拦住至少八成的低级交互 bug，不要等发完链接之后客户再替你发现。正式评审前自己多花十分钟，比发出去之后来回补救要划算得多。

2.2 一键发布到 Axure Share 的完整操作

实际操作非常简单。在 Axure RP 顶部工具栏里找到“发布”，下拉选择“发布到 Axure Share”。弹窗里有几个字段需要留意，我按自己的使用习惯逐个说。

页面范围：如果只是评审某一核心流程，可以只选择对应页面，避免把未完成页面暴露出去。默认全选，但我习惯还是只发布需要评审的页面。未完工页面统一放到归档文件夹再隐藏，而不是手动去勾选页面，这样页面列表保持完整，不会被“缺页”问题干扰评审节奏。

选项设置里，比较重要的是“密码保护”和“允许从共享站点下载源文件”。给外部客户演示时我通常会开启密码保护，把密码单独用另外的渠道发出去，防止链接被转发后任何人随意围观。是否允许下载源文件，我的判断标准是：开发作为交付对象时，可以用允许下载让他们拿到 .rp 源文件；给甲方和领导演示时，就关掉这个选项，避免源文件被随意扩散。这个开关看似简单，实际影响的是原型资产的安全边界，不能每次都凭手气乱选。

发布完成后，Axure 会自动打开一个浏览器页面，同时复制分享链接。这个链接比较短，可以直接贴到聊天窗口、邮件或者评审文档里。点开后如果是团队项目，部分功能需要登录账号才能使用，个人发布的项目则一般不用登录。第一次使用的人容易在这个地方迷糊，以为是链接坏了，其实只是登录门槛。

2.3 发布之后：更新、删除和重新发布

链接发布之后最方便的一点是，它不需要重复发送。原型改了，直接在软件里再次发布到 Axure Share，原链接不变、内容自动覆盖为最新版。这意味着你可以和评审方约定好一个固定链接，每次评审会前更新一次即可，永远不会有“版本对不上”的问题。对客户方来说，他们习惯了一个入口之后，也不会再问你“能不能重新发一份”，整个沟通链路都清爽很多。

如果某个原型已经完成使命，比如项目上线了，或者客户换了一套方案，我会到 Axure 的发布管理里把对应发布记录删除。删除之后旧链接立即失效，对方再点就看不到内容了。这个动作容易被人忽略，尤其涉及商业项目时，收尾清理非常必要。别让一堆已经过期的原型链接散落在网络里，哪怕内容是演示数据，也容易给无关的人造成误导。

但这里有两个坑要提醒。第一个坑：删掉发布记录后，如果本地没有保存 .rp 源文件，那这个原型就彻底没了，别指望云端帮你留底，把云端当备份介质非常危险。第二个坑：密码保护开启后，如果同一份原型多次发布，密码是跟着发布记录走的，别人把旧链接转发出去，新密码不会自动保护旧链接，必要时把旧发布一并删掉。总结起来，发布和删除都是常规操作，但每个操作背后都要有“本地留底”“链接收回”的意识。

2.4 三种发布场景怎么选

我在实际中基本只用三种形态：个人发布、团队项目发布、导出 HTML 内网部署。个人发布适合快速演示和外部客户评审，团队项目适合多人共同维护同一套原型库，导出 HTML 是信息安全要求较高时的兜底方案。它们之间的差异列成表会更清楚。

这张表只是我自己的经验判断，具体还要结合团队习惯来选。个人发布轻量简单，一个人也能快速把原型发出去；团队项目适合几个人同时维护组件和页面，权限和版本管理更清晰，但引入账号管理和项目结构之后，维护成本也会上来；导出 HTML 灵活但更新繁琐、协作弱。不要一上来就奔着团队项目去，项目管理也是有成本的，我个人建议个人项目能覆盖就先个人项目，到多人分工的时候再升级。

3. 权限、版本与团队协作：多人一起用 Axure Share 的正确姿势

3.1 团队项目从哪里建，成员权限怎么分

当原型进入多人维护阶段，我会把 .rp 文件转为团队项目。做法是在 Axure 中创建团队项目，选择一个云端空间，然后邀请成员。成员加入后，可以在自己的客户端里打开同一个团队项目，多人同时编辑页面。和本地文件最大的区别是，编辑时系统会提示某人正在编辑某页面，避免两个人同时改一张图导致覆盖。多人协作的秩序感，就是从这种细小的锁定机制里来的。

成员权限大体分三类：管理、编辑、查看。管理权限负责邀请成员、删除项目、调整页面权限；编辑权限可以打开项目改页面并发布；查看权限只能浏览，适合开发、测试和业务方。这里我吃过一次亏：给了某位同事编辑权限之后，他在主页面上大改了导航交互，发布后才被我发现，回滚花了不少时间。后来凡是批量加入的辅助角色，一律先给查看权限，需要协作时再单独提升。权限给得越粗，后面收拾残局的概率就越大。

另外要注意，团队项目通常要求成员有对应的账号，并且需要接受邀请。项目初始化时尽量让项目名、目录结构、页面权限一开始就定好，后面再改会涉及很多人，沟通成本很高。我见过一个团队把团队项目的空间建错了，导致所有页面都要迁移，折腾了大半个月才消停。前期的五分钟规划，能省掉后面一周的返工。

3.2 版本记录：改来改去也能找回过去

版本管理和回滚，在团队项目里比在本地文件里靠谱得多。每发布一次或每次提交编辑，系统都会留下版本记录。你可以给关键版本打个标记，比如“评审版本”“开发基线”“v2 稳定版”。这样当出现“这次改坏了，想退回上一版”的时候，直接选中上一个版本恢复，不用像以前那样到处翻本地备份文件。这个机制解决的是团队协作里最让人崩溃的一类问题：明明没人知道谁改了什么，但成品就是不对了。

我的建议是，不要频繁地打标记，只在两个节点打：对外评审前、开发交付前。至于平时的小改动，靠自动记录足够了。版本打得太碎，版本列表反而会失去辨识度，到时候你想找那个真正的基线版本，还得一个个点开看，效率反而更低。标记的意义在于给重要节点命名，而不在于收集所有快照。

个人发布到 Share 的版本历史相对简单，它保留的是发布记录，不是完整的源文件变更记录。所以个人项目我依然强调：本地源文件要自己管好，云端只是发布渠道，不是源码仓库。这个观念越早建立越好，否则某天误删一个发布记录，你连后悔的余地都没有。

3.3 评论和标注：把评审意见钉在页面旁边

Axure Share 的浏览器端支持在页面上添加点评。评审者不需要装软件，打开链接后选中页面右上角的批注按钮，就能在指定位置写下评论，把意见“钉”在当前页面的某个元素旁边。作为原型作者，我可以逐条回复，处理一条就标记一条。这个机制最大的价值是保留评审的上下文。

以前评审意见是聊天记录里飞过来的一整段文字，比如“第三页那个按钮好像不对”，你还得去猜他说的哪个按钮；现在评论直接挂在对应页面上，甚至能挂在对应控件附近，作者回复之后快速收敛，一条一条解决。“哪里有问题”和“为什么有问题”都留在原处，评审会上的口头讨论也能沉淀成可追踪的记录。

实践中要主动降低评论门槛。我在评审会前会先发布原型，然后专门说一句：“大家打开链接后，直接在对应页面点评论图标留言，不用单独整理到文档里。”大部分第一次接触 Axure Share 的业务同事，其实并不知道可以评论，你稍微引导一下，反馈收集就会顺畅很多。评论区不适合长篇大论的技术讨论，那种细节还是拉会或者走需求池。评论是记一时之需，不是文档系统的替代品。

4. 常见问题排查与避坑清单

4.1 发布失败或上传卡住，先查这几处

发布失败是被问得最多的问题之一。按出现频率排序，通常是这几个原因。

网络原因排在第一位。Axure Share 服务在境外，实际体验和本地网络环境关系很大。如果你处于公司内网，而内网对外部站点有限制，上传时就会卡在进度条上。先做一次最基本的判断：在浏览器里能否直接打开 Axure Share 的官网；能打开但上传失败，多半是上传通道被限速或阻断。我自己的处理方式是换一个网络环境再试，或者把文件拆小。这里是典型的“等多久都没用，换条路才有效”的场景。

第二是文件太大。上百兆的 .rp 文件上传，成功率会明显下降。我建议在上传前把体积压到 50MB 以内，做法是压缩图片、删除废弃素材、把不用的页面归档。发布本质上是一个在线上传的过程，体积越小越稳。很多团队成员喜欢把运营给的高清原图直接拖进原型，这是上传慢的直接原因，没有之一。

第三是文件和账号异常。团队项目如果成员的账号权限被改过、或本地文件状态异常，发布时可能会提示冲突。处理办法很简单：不要点“覆盖解决”盲目覆盖，先看清楚冲突内容，和团队沟通后再操作。盲点覆盖按钮一时爽，可能会把别人最新的改动直接冲掉，这种事故在多人协作里代价极高。

4.2 为什么原型在浏览器里交互失效

最诡异的问题是：本地预览一切正常，发到 Share 之后动态面板不切换、点击按钮没反应。排查这类问题，路径其实很清晰。

第一类原因是资源引用方式。原型里如果用了本地绝对路径引用的图片，本地能看到，上传到云端后路径失效，图片挂掉，视觉上会让人觉得整个页面坏了。处理办法是尽量把图片直接粘贴进 Axure，让图片资源打进 .rp 文件，而不是用外部路径引用。外部路径引用在本地没问题，但发布后依赖条件不成立，问题就会定时炸开。

第二类高发点是中继器。如果中继器一次性加载大量数据，浏览器端渲染性能跟不上，交互就会变得一顿一顿，甚至点不动。我的经验是把演示数据控制在 20 条以内，数据再多就要在原型里说明“这是示意数据，完整数据见数据说明文档”。客户不会要求你在原型里跑真实全量数据，他们要看到的是交互逻辑和视觉框架。

第三类是浏览器弹窗拦截。涉及“在新窗口中打开”的交互时，某些浏览器默认拦截弹出窗口，点起来没反应。我会在演示说明里提一句，如果点击后没有新窗口，请允许本站点弹出窗口。这种问题不是原型错了，是浏览器的安全策略在发挥作用，说明清楚就好。

4.3 打开慢、白屏，十有八九是体积和加载方式

打开链接后白屏，很多人第一反应是链接坏了。实际上链接一般没问题，主要是首屏加载太慢。Axure Share 打开原型时，浏览器要把页面文件拉取下来再渲染，如果原型里塞了几十张大图、几十个页面，首次加载就非常痛苦。我过去也遇到过，等了十几秒还在转圈，最后发现是某个页面里嵌了一张十几兆的截图。

解决办法分三层。第一层是源头控制，图片压缩、删废页，把体积降下来，这条前面已经反复强调。第二层是调整演示策略，用演示模式逐个打开需要讲解的页面，而不是让浏览器一次性加载整个原型。第三层是换个网络再试，有时候白屏只是加载慢，等一会儿就有内容。尤其远程评审时，别急着甩锅给 Axure，先看看自己的网络环境是不是稳定。

另外定期清理浏览器缓存也有帮助。原型更新后，本地浏览器可能还在用旧的缓存资源，导致你看的总是旧版。开个无痕窗口访问链接，是排查这类问题最快的方式。这个动作几乎可以解决九成的“我这边看到的是旧版”问题，先无痕验证再下结论。

4.4 哪些原型内容不建议传上 Axure Share

Axure Share 虽然方便，但它终究是把原型托管在云端，由第三方服务器保存。涉及真实客户姓名、手机号、身份证号、内部系统账号密码截图这类敏感信息，我都不建议上传。即便有访问控制和密码保护，内部保密要求高的项目也要先脱敏再发布。分享这事，控制住源头永远比事后补救简单。你永远不知道一个链接会被转给谁看，能做的就是别把敏感内容放到链接里。

演示数据就老老实实用假数据。登录页可以用 demo / 123456，列表页用“张三、李四、王五”这种虚拟姓名。现实中很多产品经理图省事，直接把真实系统截图丢进原型，客户看完之后原型文件外流，风险全在自己头上。尤其是金融、医疗这类行业，真实数据出现在演示原型里属于比较严重的事故了。养成脱敏习惯，比事后补救安全得多。

另外，如果你所在公司对数据外发有明确要求，那就要事先评估。这种情况下优先考虑内网部署的 HTML 导出方案，或者走团队自建的原型托管方案，而不是把原型放到外部云端。判断标准其实很简单：这页原型如果外流，会不会给公司带来麻烦？会，就不发外部链接。

5. Axure Share 的进阶用法：演示、反馈和更轻的维护

5.1 用演示模式把远程评审变成现场讲解

远程评审最怕各看各的，讲的人翻页讲，听的人找不到位置。Axure Share 在浏览器里有一个演示模式，打开后可以全屏展示当前页面，并且在页面上移动高亮指针，相当于把原型变成一个幻灯片式的演示工具。我在线上评审时，会共享浏览器窗口，开启演示模式，用这个高亮指针引导大家看当前操作位置。这个方法比单纯共享桌面里操作 Axure 源文件要稳定得多，因为 Share 上大家的视野是一样的。

这个模式对我最大的帮助是，它把“远程各看各的”拉回到“同一个屏幕往前走”。配合视频会议，体验很像线下评审：讲解人点开某个页面、某个交互，观众在同一个视野里跟进，比抱着一堆标注干聊顺畅得多。评审中的临时反馈也能当场引导到正确页面上，大家一边看一边决定下一步看哪里。演示模式已经是我的远程评审标配。

5.2 把 Share 链接嵌进团队文档和知识库

原型链接会出现在需求文档、排期文档、会议纪要等多个地方。与其到处复制一长串链接，我习惯把定期更新的原型入口固定在一个位置，然后让其他文档引用这个固定入口。很多知识库工具支持嵌入网页，直接嵌入 Share 链接后，文档读者可以在页面内直接预览原型，不需要跳转出去。这个动作能把“看原型”嵌入团队日常工作流，而不是把原型当成一件需要专门去打开的交付物。

这个做法带来的好处是，原型更新后，所有关联文档不需要跟着改。因为引用的永远是最新发布内容，只要你的发布链接不变，所有入口就自动指向最新版。对团队里的开发、测试同事来说，他们不用每次追问“这一版到哪了”，打开文档里的原型就是最新版。这其实就是把 Axure Share 当成团队内部的“原型发布源”，比反复邮件发附件省心太多。

5.3 从评论到需求池：整理反馈的固定流程

Share 上的评论是短消息型的信息，天然碎片化。如果评审结束后不做整理，它就会散落在各个页面里，项目一忙就忘了跟进。我的固定流程是：评审结束后当天，把每条评论记录摘要，按模块归档到需求池，给每条评论标注状态：已处理、待确认、暂缓、不处理。处理完后回到 Axure Share 里逐条标记解决，关闭评论。这个流程不用额外工具，就是评论功能加一张简单的表格，但效果非常好。

这个过程坚持下来，你会发现原型评审的结论越来越清楚。过去口头评审“想起来什么说什么”，会后没有记录；现在每条意见都有出处、有归属、有结论。哪怕隔了一个月再翻记录，也能还原当时是怎么定下这些交互细节的。更重要的是，状态标注可以逼着你跟进：哪些意见还没处理，哪些意见被否定了，都一目了然。原型评审不再是开完会就蒸发的一小时。

5.4 源文件的分发和组件沉淀

如果团队不只是看原型，还要让开发基于原型还原界面，那源文件分发就得讲究一点。给开发开“允许下载源文件”权限后，对方拿到的是一份和发布内容一致的 .rp 文件，里面保留着页面结构、组件命名和交互逻辑。这一步能显著减少开发还原时的理解偏差。相比开发在浏览器里一点一点看图片猜尺寸，直接给源文件显然高效得多。但前提是源文件里的图层命名、组件命名不要太混乱，否则给了也白给。

进一步说，我会在团队项目里沉淀一套常用的组件库，从按钮、表单到导航，都做成可复用的母版。发布评审时直接用组件拼页面，改样式只改组件，所有引用页面同步更新。组件库放在团队项目里，比个人项目更容易统一维护，因为组件更新后重新发布，整个原型都会收到变化。这一套走顺之后，每周的原型输出速度和质量都能上一个台阶。组件不是设计团队独有的概念，原型里的组件化同样是效率杠杆。

最后再讲一个让我印象深刻的小事。有一次给客户做远程演示，我提前一小时更新了原型链接，结果客户打开的还是旧页面，当场质疑我演示内容是不是错了。后来查下来，是因为对方浏览器缓存了旧版本，我让他开无痕窗口再访问，问题立刻解决。从那以后，我养成了一个习惯：任何正式评审前，我一定用无痕窗口自己先点一遍新链接，确认内容、交互、加载速度都没问题，再发到评审群。这个习惯看起来不起眼，但替我省掉了很多尴尬的场合。Axure Share 说到底只是一个工具，真正让协作顺畅的，还是操作它的人有足够的耐心和流程意识。