替代 Axure，先确认要迁移的是“能看的页面”，还是“能运行的业务规则”。若原型大量使用动态面板、变量、中继器和条件判断，换工具的难点在逻辑重建；若只是分享不便，可以先改进托管和评审，无须立刻重做全部文件。墨刀、Figma、Penpot、Sketch、Framer 都能进入候选范围，但各自承接的工作不同。
下面用一份报销审批原型做试点：两条费用合计 1000 元，新增一条 50 元费用后，审批路径发生变化。这个小任务能暴露“页面导进来了，规则却丢了”的问题。
五款候选工具，分别解决哪段工作
| 工具 | 适合先验证的任务 | 不能省略的核对 |
|---|---|---|
| 墨刀 | 中文原型、Axure文件托管与后续协作编辑 | 托管可演示与转换后可编辑要分别验收，动态面板/变量逐项试 |
| Figma | UI设计、组件库与设计协作 | 按需求重建业务交互，不预设.rp原生逻辑完整迁入 |
| Penpot | 开源UI设计及有自托管要求的设计流程 | 把部署、备份恢复与设计文件迁移分开评估 |
| Sketch | Mac设计师维护UI、组件与视觉资产 | Windows参与者需要什么编辑/审阅能力；复杂审批是否另做原型 |
| Framer | 营销网站视觉、响应式与发布 | 网站页面能发布，不代表报销权限和审批后端已实现 |
Axure 官方仍将条件逻辑、变量和交互原型作为主要能力。团队如果依赖这些能力，应让候选工具实际运行相同规则，而不是只比较首屏视觉。还不熟悉原有交互模型时，先用Axure教程专题确认动态面板、变量和中继器在当前项目中的用途；两款产品之间的取舍可继续看墨刀与Axure的核心差异。
报销申请：用1000元边界检验迁移质量
这份练习包含申请列表、申请编辑和审批详情三个页面。申请人林宁在 EXP-018 中填写交通费 360 元、住宿费 640 元；费用明细允许新增和删除，总额随明细变化。金额必填、大于 0，并保留两位小数。
规则：总额不超过 1000 元，由经理审批；严格大于 1000 元，经理通过后还要进入财务复核。阈值处使用“>”，不能把恰好 1000 元误送财务。画面中的经理与财务状态是待验证的原型规则，实际服务端审批另行实现。
- 在源文件建立两条初始费用，确认合计 1000 元，记录经理审批路径。
- 添加材料费 50 元，确认合计 1050 元，并在经理通过后看到财务复核。
- 删除新增行，确认总额和审批路径一起回到原状态；只改合计文字不算完成。
- 保存源文件副本、三页截图和路径记录，作为每个候选工具共用的对照材料。
不要先删掉中继器、拆散动态面板再导入，否则试点会绕开真正的迁移难点。应先测有代表性的原结构，确需简化时再登记简化理由。
先托管再转换，别把两种结果混在一起
墨刀Axure托管的官方页面介绍了上传、分享、评论和版本记录，也提供转为墨刀原型继续编辑的路径。两类验收应分开：托管阶段检查演示与访问；转换阶段检查字段、组件和业务逻辑能否修改。演示链接能打开，并不能证明源逻辑已经变成可编辑对象。
在工作台的 Axure 相关入口上传试点副本，按当时入口要求准备文件。先让一名评审者用分享链接走完 EXP-018，再尝试转换和修改。如果当前账号没有转换入口，保留托管方案并核对账号能力，不把 HTML 演示包当作可以还原全部变量的源文件。
把八条用例跑完，再决定是否换工具
| 用例 | 操作 | 必须看到的结果 |
|---|---|---|
| EXP-01 | 360+640；提交 | 合计1000；进入经理审批，不出现财务复核 |
| EXP-02 | 360+640+0.01；提交 | 合计1000.01；经理审批后进入财务复核 |
| EXP-03 | 360+640+50；删除材料费50 | 合计回到1000；审批分支重新计算 |
| EXP-04 | 材料费金额为空；提交 | 定位材料费金额，保留其他已填内容，不进入审批 |
| EXP-05 | 金额为-1；提交 | 金额必须大于0；不计算成负报销 |
| EXP-06 | 有效费用明细；连续点击提交两次 | 提交中禁用按钮；原型展示同一申请，不生成两条记录 |
| EXP-07 | 提交失败；重试 | 费用明细保留；错误消息可消除；成功后进入正确分支 |
| EXP-08 | 仅查看角色；打开申请 | 可查看但不显示可用的提交/审批操作 |
本例把 EXP-01～EXP-08 设为进入下一轮试点的必要条件。某项不能实现时，明确记录“需手工重建”或“该工具不承担此逻辑”，不要用总分掩盖规则错误。如果业务允许用多个状态页面演示，也应把它登记为演示方案，不能当成真实的数据计算能力。
检查后下载报销迁移验收表填写实际结果。表内已写好输入、操作和预期，空白结果栏由试用者填写。
再改一次审批阈值，算出维护成本
让另一名产品经理把阈值从 1000 元改到 1500 元，然后检查 1499.99、1500、1500.01 三个数值。这个动作能区分“规则集中管理”与“每张状态页都要重新找”的维护方式。
- 记录三段实际用时：首次迁入并修复、调整阈值、让研发独立读懂交付。不要用官网生成速度替代团队实际耗时。
- 记清协作席位：谁编辑、谁评论、谁查看开发信息，按实际套餐核对，不把所有参与者默认当编辑席位。
- 检查退出条件：能带走什么源文件、图片、说明和评审记录；只有截图的备份难以继续维护规则。
如果修复消耗已超过当前迭代可接受范围，可以先让新项目使用目标工具，旧复杂模块继续使用 Axure。分模块切换比强制一次迁移更容易控制返工。
一份能交给团队执行的迁移决定
试点结束应交出：源文件备份、目标原型链接、八条用例结果、不可迁移项及负责人、主文件切换时间和回退路径。使用报销原型迁移工作簿，可直接沿用本例材料和六个执行步骤。
如果主要问题是评审和分享，先改善托管；如果新工具能覆盖必要规则，且变更维护成本可接受，再扩大迁移。预算约束可结合免费Axure替代工具的适用范围核对；企业采购则继续评估国产替代中的数据、协作和迁移条件。需要补齐表单本身，可参考字段、校验与提交状态的画法。
