产品经理如何用 AI + Mock 快速生成高保真原型

很多产品经理已经开始用 AI 生成页面和可点击原型。它确实能缩短从想法到画面的距离，但进入一个已经上线的真实项目后，速度优势很快会被新的问题抵消：

• 原型的页面风格与现有系统不一致。
• AI 不知道真实接口和数据结构。
• Mock 用过一次后就与真实代码脱节。
• 下一轮需求只能重新生成，无法站在上一轮成果上继续。

这篇文章想讨论的不是“AI 能不能画页面”，而是一个更具体的问题：

产品经理怎样在已有的 1-N 项目上，低成本做出能运行、贴近真实系统、还可以持续迭代的高保真原型？

传统串行研发为什么不适合快速验证

传统流程通常从需求文档开始，依次经过 UI、前端、后端和测试。每个环节都需要等待上一个环节产出足够稳定的结果。

这套流程的问题并不是专业分工本身，而是验证成本太高。一个方向还没有被业务确认，就要投入设计和研发资源；真正做出来后再发现理解有偏差，返工会沿整条链路向前传递。

产品经理需要的是在正式开发之前，先让业务方看到接近真实产品的效果：页面能点、数据能变化、关键流程能跑通。只有这样，评审讨论的才是产品本身，而不是每个人脑海中不同的想象。

第一种尝试：让 AI 直接生成前端和 Mock

AI 代码生成提供了一条很直接的捷径：输入需求，让 AI 同时生成页面代码和 Mock 数据，再把它们组合成一个可运行原型。

对全新产品来说，这种方式非常有效：页面结构、数据格式和流程都可以自由决定，验证完成后甚至可以直接丢弃。

但 1-N 项目完全不同。真实产品已经有组件规范、页面布局、权限逻辑和几十上百个接口。AI 凭空生成的新页面即使看起来漂亮，也可能与现有系统“两张皮”。

因此，关键不是让 AI 更努力地猜，而是让它有真实系统可以依靠。

引入 Mock：让原型从真实接口生长

更合理的方式是读取真实项目的前端和接口定义，再生成符合接口契约的 Mock 数据。这样原型使用的是现有产品的页面外壳和数据结构，只把真实后端替换为可控制的模拟场景。

这带来三个直接收益：

1. 页面保真度来自真实前端，而不是重新模仿。
2. 数据字段来自真实接口，关键流程更接近生产环境。
3. 产品经理可以自由构造空状态、异常状态和边界场景，不依赖后端临时造数据。

到这里，原型已经“长在真实系统上”。但 Mock 本身还有一个老问题。

Mock 为什么总会与真实系统脱节

传统 Mock 往往只在某次联调或演示中临时使用。后端接口继续开发后，字段、类型和路径都会变化，而旧 Mock 没有自动获得这些信息。

如果没有同步机制，Mock 维护很快会变成额外负担。接口越多，手动核对越不现实；最终团队会放弃维护，原型也重新变成一次性产物。

所以，可迭代原型的核心能力不应该只是“生成”，而应该是“持续回补”。

我的产品判断：Mock 是代码资产

Mock 不应该只存在于运行内存或某个临时脚本中。接口契约、场景和样例数据应该保存为文件，并像真实代码一样进入 Git：

能力	真实代码	Mock 资产
版本记录	commit	commit
改动审查	diff / review	diff / review
出错恢复	revert	revert
多人协作	分支	分支

一旦 Mock 成为 Git 资产，AI 的角色也会更清晰：它不直接修改最终结果，只生成一份可审查的补丁。人负责判断，Git 负责记录，错误可以回退。

两套环境服务不同角色

这里必须澄清一个容易混淆的概念：真实前端和原型前端不是同一套运行环境。

产品经理使用的是“真实前端副本 + Mock”临时组合出的原型环境。它追求高保真和可控场景，不连接真实业务数据。

开发、测试和线上用户使用的是真实前端，它连接真实后端，并遵循正式研发与发布流程。两者用途不同，不能简单地把生产前端切到 Mock 上解决。

回补：把真实接口变化带回 Mock

当业务确认原型并进入正式开发后，开发者会在真实项目中实现需求。需求完成时，真实接口可能新增字段、调整类型或替换路径。

此时由人手动触发“回补”：

1. AIMockFlow 读取最新代码提交或 Swagger。
2. AI 对比真实接口与 Mock 契约。
3. 系统生成待审核的 Mock 补丁。
4. 人查看 diff，确认、调整或丢弃。
5. 确认后的结果 commit 到 Mock 仓库。

这里刻意保留了两个限制：必须手动触发，AI 只能生成补丁。接口同步很重要，但不可控的自动修改同样危险。产品需要把自动化放在人能理解和确认的位置。

两个前端是平级的，不是谁替代谁

真实项目提供前端代码和接口定义，Mock 仓库保存可迭代的模拟资产。AIMockFlow 在需要演示时读取两者，临时组装出原型环境。

这种边界有三个好处：

• AIMockFlow 不需要污染真实项目仓库。
• 原型环境可以随时重建，不必长期维护前端副本。
• Mock 仓库保持轻量、可读，也更适合产品经理和 AI 共同迭代。

这套方案最后变成了 AIMockFlow

沿着这条思路，我把方案整理成了一个开源项目：AIMockFlow。

它的定位不是另一个“输入一句话生成页面”的工具，而是一个长期维护 Mock 资产的引擎：

在真实项目上生成可运行的高保真原型，并在需求开发完成后，把真实接口变化持续回补到 Mock。

第一阶段会优先验证两个问题：真实前端副本能否稳定运行，以及回补后的 Mock 是否仍能与真实接口保持一致。只有这两个基础成立，后续自然语言改场景、一键分享和桌面客户端才有长期价值。

更完整的产品架构、MVP 和风险判断，可以查看项目页：AIMockFlow · 可迭代高保真原型。

写在最后

AI 原型的下一个阶段，可能不是生成得更快、更漂亮，而是更深入地连接真实系统。

对于 1-N 项目，产品经理真正需要的不是再造一个孤立页面，而是：

• 从真实前端获得保真度。
• 从接口契约获得可信的数据结构。
• 用独立 Mock 获得可控的演示场景。
• 用 Git 和回补机制获得持续迭代能力。

当这四件事连起来，原型才不只是评审会前的一次性道具，而会成为产品探索过程中可以不断积累的资产。