从 Axure HTML 到 Ardot：一次 AI 原型迁移实践

原型设计工具的选型一直是产品经理和设计师关注的议题。随着 Apple 逐步停止对 Rosetta 的支持，基于 Intel 架构的旧版软件面临越来越严峻的兼容性挑战。与此同时，新版软件的订阅制定价也让不少从业者重新审视自己的工具链。本文将分享一次将 Axure 原型迁移到 Ardot 的完整实践，探讨如何借助 AI 能力实现高效的原型批量迁移。

迁移的核心挑战

迁移的起因源于两个现实考量：旧版 Axure 9 的 Intel 架构与 macOS 未来的兼容性风险，以及新版 Axure 订阅费用的高昂。更重要的是，Ardot 作为一款类 Figma 工具，提供了本地 MCP（Model Context Protocol）能力，允许 AI 直接操作设计文件。这意味着只要 Token 充足，理论上可以让 AI 持续协助修改和创建原型。

规则先行的重要性

然而，Axure 的 .rp 文件无法直接导入 Ardot，可稳定处理的中间产物仅有 Axure 导出的 HTML 原型。虽然 Ardot 官方提供了 H2D（HTML to Design）功能，适合单个页面的视觉恢复，但对于需要批量迁移、要求组件复用、侧边栏统一、表格结构可维护的复杂后台系统来说，这一方案并不适用。核心问题因此变成：如何从 Axure HTML 出发，借助 MCP 工具，让 AI 在 Ardot 中重新生成一套可编辑的原型？

框架搭建与流程规范

这次实践最大的感受是：难点不在于让 AI 画出一个像样的页面，而在于让它每一次都按同样的规则画页面。如果只追求视觉相似，AI 能达到 60-70 分；但如果要求图层清晰、组件可复用、内容可编辑、后续可交接，那就必须先建立一套完整的规则框架。首先需要明确任务边界——Ardot 目前尚不支持类似 Figma 的「连线」功能，即使后续支持，让 AI 理解 Axure 中的复杂交互也是费力不讨好的事情，因此只要求复现静态页面，复杂交互一概忽略。其次是文件组织策略：Axure 中一个页面就是一个独立文档，而 Ardot 和 Figma 类似，一个文件相当于无限大的画布，所有内容都属于同一文档，因此需要将每个系统拆分成独立文件。

数据提取与准备

Axure 导出的 HTML 并非单纯的静态页面，它包含页面入口、资源目录、脚本、图片以及页面跳转关系。部分页面内容需要浏览器执行脚本后才能呈现。因此，作者采用了本地 HTTP 服务配合 Playwright 的方案：启动服务后用 Playwright 打开页面，导出渲染后的元素信息和截图。提取的材料包括三类：页面清单（命名和归属）、element JSON（内容信息）、以及截图（用于校验）。此外，提前在 Ardot 中准备本地组件库（TDesign 组件），并为颜色、间距、圆角等设计变量建立规范，这些都是后续 AI 高效执行的基础。

如有侵权，请联系删除。