在当前AI驱动的开发范式下，原型设计的最佳实践已从单一交付物演变为“以结构化规范为核心，兼顾人机可读的协作体系”。这恰好契合你基于Spring Boot + RuoYi的技术栈，核心不再是某个特定工具，而是如何构建一个让AI与人类团队都能顺畅工作的“设计语言”和流程。

核心理念：以“规范驱动”替代“纯视觉驱动”

Google、微软等公司的最新实践揭示了一个共同趋势：为了让AI能深度参与，设计过程必须从“画图”转向“写规范”与“画图”并重。

1. 引入DESIGN.md：AI可执行的设计规范
Google在2026年推动的DESIGN.md规范，本质上是将品牌色彩、UI组件、交互规则等以Markdown这样的结构化文本记录下来。这相当于给AI提供了一份明确的“设计说明书”。当AI需要生成或修改界面时，它首先查阅这份文件，确保产出符合设计系统，而非凭空发挥。这解决了AI生成代码风格不一致、难以维护的痛点。

2. 采纳“规格驱动开发”（Specification-Driven Development）
微软在其开源项目（如hve-core）中强调，AI开发需要明确的“质量约束”和“保真度规则”。亚马逊的工程师也指出，AI编码代理需要规范文件（Spec Files），而非仅凭感觉编码，才能交付生产级代码。这与你提到的RuoYi-SpringBoot3-Pro项目引入OpenSpec工作流的实践不谋而合——在编码前锁定需求，避免AI因上下文丢失导致产出不可控。

3. 遵循“设计思维”的分阶段保真度策略
微软在其Design Thinking流程中，明确规定了不同阶段原型的“保真度约束”：

• 早期（问题探索）：强制保持低保真（Lo-fi），用草图、流程图，避免过早陷入细节，鼓励迭代。
• 中后期（方案验证）：逐步提升至中高保真，用于用户测试。
• 实现阶段：产出可对接开发的“生产就绪”规格。

这种策略让AI在早期不被要求生成完美像素的界面，而是专注于逻辑和流程，显著提升了协作效率。

工具选型建议：兼顾“效率”与“可控”

基于你的技术背景和国内环境，工具链的搭配建议如下：

产品经理/需求分析师	Calicat (ProcessOn出品) 产品官网：https://www.calicat.cn	核心：对话即设计。支持用自然语言生成高保真原型和需求文档，并具备MCP Server能力，可将设计数据对接给AI编程工具。非常符合你“让AI看得懂”的需求，且是国内工具，上手快。
AI 设计规范底座	Axure Cloud / 文档 + DESIGN.md	核心：规范沉淀。利用Axure Cloud的新文档和白板功能，将组件库、交互规则沉淀为团队共享的DESIGN.md文件，作为所有AI工具的“宪法”。
架构师/核心开发者	OpenSpec + 任意AI IDE (如Antigravity/Claude Code)	核心：需求锁定。在RuoYi框架中引入OpenSpec工作流，通过/openspec-proposal等命令，在AI编码前生成结构化的变更提案，确保架构决策和业务逻辑被准确理解和执行。

这三个工具并非互斥的选择题，而是一条环环相扣的AI全链路开发流水线。它们的核心逻辑是：用Calicat把模糊的想法变成AI能看懂的原型和文档，用AI设计规范底座确保AI始终遵循团队的”宪法”，最后用OpenSpec把前面所有的设计意图锁定为结构化的开发任务，交给AI编程工具去执行。

下面这张图可以清晰地展示它们如何分工与配合：

原型设计文档输出物方案

要让输出物同时满足AI和人类阅读，需要分两层产出：

1. 面向AI的“结构化规范” (存于代码库根目录)

• DESIGN.md：定义UI设计令牌（颜色、字体、间距）、组件使用规范（如按钮尺寸、弹窗交互）、页面布局骨架。
• AGENTS.md或CLAW.md：为AI代理设定编码规则，例如“所有API调用必须使用RuoYi的通用Controller”、“数据库操作必须通过ServiceImpl”。
• openspec/文件夹：存放通过/openspec-proposal生成的结构化需求变更文档，包含变更背景、影响范围、数据模型改动等。

2. 面向人类团队与AI辅助的“可视化原型”

• 交互原型：使用Calicat或Axure RP生成的可点击原型，用于用户测试和需求确认。关键操作：在这些原型中，所有交互事件应使用标准的业务术语命名（如submitOrder()），而非模糊描述。这样AI在审查原型时，能精准提取功能点，甚至自动生成部分代码。
• 配套说明：利用工具（如视频中展示的Skill）为原型每个页面和组件自动生成Markdown格式的需求说明，保持“原型即文档”。

整体协作流程建议

1. 需求探索：产品经理用Calicat与AI对话，快速生成低/中保真原型，验证流程。
2. 规范定义：架构师将可复用的UI模式、交互逻辑提炼，编写成DESIGN.md。
3. 需求锁定：开发者使用OpenSpec将确认后的需求（可附上Calicat原型的链接或截图）创建为结构化提案。
4. AI编码：AI编程助手（在RuoYi项目中配置好AGENTS.md）根据OpenSpec提案和DESIGN.md规范，生成符合框架（Controller/Service/Mapper）结构的代码。
5. 人工审查：重点审查AI生成代码中的核心业务逻辑，确保其与高保真原型和DESIGN.md规范一致。

这套方案的核心，是将原型设计从“一张图”变成了一个包含规范、流程和上下文的协作系统，让AI成为这个系统中的“高级执行者”，而人类则担任“架构师与评审者”的角色。

通过 Calicat 开发的原型，AI 能够读取并生成代码的核心机制是 MCP (模型上下文协议) Server。这相当于为 AI 提供了一个标准化的“数据接口”，让它可以精确理解原型中的布局、组件和需求，而不是像人一样去“看图说话”。

核心原理：MCP Server 搭建数据桥梁

Calicat 的 MCP Server 是其设计理念的关键，它能将设计文件中的结构化数据（图层、组件属性、需求卡片）直接提供给支持 MCP 协议的 AI 编程工具。这种方式相比让 AI 直接识别图片，数据更精准，避免了理解偏差。

落地步骤：在你的技术栈中集成

结合你 Spring Boot + RuoYi 的技术栈，实现从 Calicat 原型到代码的步骤如下：

1. 准备原型与需求：在 Calicat 中，利用其 AI 助手完成高保真原型设计，并同步生成结构化的需求卡片（PRD），将页面逻辑与业务需求关联起来。这是后续生成代码的“说明书”。
2. 配置 MCP 客户端：在支持 MCP 的 AI 编程工具（如 Trae、Cursor、Claude Code 等）中，配置 Calicat 的 MCP Server。参考配置格式如下（以 trae 为例）：json{ “mcpServers”: { “calicat”: { “command”: “npx”, “args”: [“-y”, “mcp-remote”, “https://www.calicat.cn/mcp”] } } }注：具体配置参数请以 Calicat 官方帮助文档为准。
3. AI 读取并生成代码：配置完成后，在 AI 编程工具中，将 Calicat 原型的分享链接提供给 AI 助手。AI 便可通过 MCP 协议获取所有设计数据与需求文档，然后自动生成：
   • 前端代码：解析原型中的组件、布局、样式，生成 Vue/React 等框架的响应式页面代码。
   • 后端接口设计：根据需求卡片中的业务逻辑描述，AI 可以为你生成 Spring Boot 的 Controller、Service、Entity 等分层架构的代码雏形。

实践工作流建议

可以参考业界实践，将 Calicat 融入一个更完整的 AI 开发流程：

1. 原型与需求：在 Calicat 中完成，并产出 Calicat 原型链接。
2. 规范驱动开发 (可选)：在 AI 编程工具中，通过类似 OpenSpec 的规范驱动框架（需安装对应 MCP），将获取的原型需求自动转化为结构化的 proposal.md, design.md 等文档，在编码前锁定架构和需求。
3. AI 生成代码：AI 工具结合原型数据与规范文档，生成符合 RuoYi 框架规范的代码。
4. 人工审查与整合：开发者对 AI 生成的代码进行业务逻辑审查和调整，确保安全与性能，然后整合到项目主干。

总的来说，Calicat 通过 MCP Server 提供了一种结构化、机器可读的设计输出方式，使得 AI 能够将“设计稿”直接视为“开发需求”来理解和执行，这才是它区别于传统图片式交付的核心价值。

————————————————————————————————————————————————————————————————————

为什么三者需要配合？

• Calicat：解决”AI看不懂需求”的问题。它通过自然语言生成高保真原型和结构化的PRD，并通过MCP协议将设计数据直接同步给后续工具，实现”对话即设计”。这确保了后续所有AI工具共享一个清晰、可执行的”原始需求”。
• AI设计规范底座：为所有AI行为立下”规矩”。它沉淀的是团队专属的组件库、交互规则和代码规范，相当于一份DESIGN.md”宪法”。当AI生成的代码风格五花八门时，这个底座能确保所有AI产出在统一规范之内，避免后期的整理成本。
• OpenSpec：担当”AI架构师”，锁定需求防止跑偏。它通过/openspec-proposal等命令，在AI编码前强制生成一份包含设计决策、技术方案和任务清单的变更提案，并经人工确认后再进行编码。这一步有效防止了AI直接”自由发挥”，确保架构决策和业务逻辑被准确理解。

完整的配合流程应该是这样的

根据行业实践，一个完整的AI驱动开发流程通常是：

1. 需求定义与原型生成 (Calicat)：产品经理在Calicat中用自然语言生成原型和PRD，并通过MCP服务将数据准备好。
2. 规范加载 (AI设计规范底座)：在AI编码工具（如Claude Code）启动时，将团队的DESIGN.md规范文档作为其全局系统提示词，作为所有AI决策的”宪法”。
3. 变更提案 (OpenSpec)：在AI编码IDE中执行/openspec-proposal命令，OpenSpec会结合Calicat的设计数据和设计规范底座的约束，自动生成结构化的开发提案与任务清单。
4. 提案审查：开发者（架构师/核心开发者）审查并确认OpenSpec生成的提案，确保架构方向正确。
5. 编码执行：审查通过后，执行/openspec-apply命令，AI编程工具（如Claude Code）严格按照提案和规范生成代码。

快速参考指南

工具	核心定位	何时使用
Calicat	需求可视化与结构化。把想法变成AI能懂的原型和PRD。	项目启动、需求变更时，由产品经理主导生成初始设计。
AI设计规范底座	团队标准约束。为所有AI工具提供统一的”宪法”和规范。	项目初始化或规范更新时，由架构师维护并供所有AI调用。
OpenSpec	需求锁定与任务拆解。把设计意图转化为结构化、可执行的开发计划。	每个新功能或大型变更开发前，由核心开发者或AI驱动执行。