从 PPT 到可交互原型：用 AI 做小程序原型的实践｜深度实践版

我用 AI 把一份 PPT 做成了可交互的小程序原型

不是画几张图，而是跑通整个业务流程。

最近我尝试把一份已经评审过的小程序建设方案 PPT，借助 AI，一步步变成真正可以点击、可以演示、可以拿去评审的交互原型。

整个过程做下来，我发现真正有效的方法并不是：

把 PPT 丢给 AI → 让 AI 直接生成小程序。

而是建立一套更加可控的工作流：

PPT 定方向 → 产品说明定边界 → 原型跑通路 → 差异文档定业务 → 小步迭代做对齐 → 问题清单做收敛。

1. 为什么不直接让 AI 根据 PPT 生成页面？

因为 PPT 本质上是给人看的，不是给 AI 执行的。

一份建设方案里面可能同时存在产品定位、功能规划、页面示意、一期范围、后期规划甚至历史方案。

如果直接告诉 AI：

"根据这个 PPT 帮我做个小程序。"

很容易出现三个问题：

功能不断扩张、需求理解偏差、后期反复返工。

所以我的做法是在 PPT 和原型之间增加一个中间层：

产品说明 Markdown。

整个流程变成：

建设方案 PPT → 产品说明 → 明确边界 → 可交互原型

这样需求会清楚很多，后续修改也更加可控。

2. 我的完整工作流

整个过程可以拆成 7 步：

第一步：PPT 提炼

从建设方案里提取真正和产品有关的信息。

第二步：产品说明

把需求整理成 AI 更容易理解和持续引用的 Markdown 文档。

第三步：明确边界

确定本期做什么、不做什么，避免 AI 自行扩展需求。

第四步：生成原型

使用多页面 HTML + 公共 JS/CSS，快速生成能够点击和演示的原型。

第五步：定义业务差异

如果产品存在两条业务线，单独梳理它们的用户目标、字段和页面结构。

第六步：小步迭代与产品体检

一次只解决一类问题。页面复杂以后，先让 AI 分析问题，再决定修改哪些。

第七步：沉淀项目规则

把 UI、产品、文案和修改规则固定下来，减少后续反复沟通。

3. 从 PPT 到产品说明：先把模糊的信息变清楚

这是整个流程里非常重要的一步。

我会把 PPT 重新整理成一份 产品说明.md，至少包含：

产品定位与目标
本期做 / 不做
用户角色
核心业务闭环
信息架构
分页面功能
关键数据展示规则

其中尤其重要的是：

一定要写清楚"本期不做什么"。

例如：

不做在线支付
不做真实订单
不做复杂库存
不做后台审核
地图只做演示
登录使用模拟状态

为什么？

因为 AI 很容易"热心过头"。

如果只告诉它要做什么，没有告诉它什么不能做，它可能会自动补齐一些你根本没有计划实现的功能。

所以产品说明实际上承担的是：

PPT 与 AI 开发之间的"产品翻译层"。

4. 生成可交互原型：先跑通，再好看

原型阶段，我没有一开始就搭真正的微信小程序工程。

而是采用：

多 HTML 页面 + 公共 JS/CSS

例如：

css 复制代码

prototype/
├── index.html
├── list-a.html
├── detail-a.html
├── list-b.html
├── detail-b.html
├── consult.html
├── mine.html
├── app.js
└── app.css

这么做的好处很直接：

生成速度快
修改成本低
适合模拟登录、收藏、咨询等交互
浏览器打开就能演示
后续仍然可以迁移到真正的小程序

第一版不要急着追求视觉效果。

先验证：

首页 → 列表 → 筛选 → 详情 → 收藏/咨询/预约 → 我的记录

这条主路径到底能不能完整跑通。

我的原则是：

先跑通，再好看。

5. 两条业务线看起来像，不代表逻辑相同

这个问题非常容易被 AI 忽略。

比如 A、B 两条业务都采用：

列表 → 详情 → 咨询

从页面结构来看很像。

但用户真正关心的信息可能完全不同。

A 类业务可能是长期决策，重点关注：

床位、收住、照护、服务能力、长期费用。

B 类业务可能是短期体验，更关心：

目的地、面积、景点、季节、交通、短期价格。

如果没有明确说明，AI 很容易直接：

复制 A 页面 → 修改几个字段 → 得到 B 页面。

所以我会单独写一份：

《A/B 业务差异说明》

明确两条业务：

用户目的有什么不同
重点字段有什么不同
哪些模块保留
哪些模块删除
CTA 有什么不同

业务判断由人完成，AI 负责执行。

6. 好的 AI 指令，一定要能够验收

例如下面这种指令：

"整体优化一下体验，让页面高级一点，顺便把搜索、价格、详情和登录也优化一下。"

看起来要求很多，实际上非常难执行。

因为它存在三个问题：

范围太大、没有验收标准、容易改乱。

我后来会改成：

本轮只修改【列表价格】。

首页热门和列表统一显示"最低价 + 起"。

详情仍然保留价格区间。

不修改筛选和其他页面。

这样就清楚很多。

我总结下来，一个比较好的修改指令最好包含：

修改对象 + 修改内容 + 对照标准 + 禁止修改项 + 验收结果

一句话：

AI 不怕需求多，怕的是边界不清。

7. 页面多了以后，让 AI 做一次"产品体检"

当原型页面越来越多以后，我不会继续让 AI 直接修改。

而是先告诉它：

梳理当前原型的页面、功能和交互逻辑。

检查流程、登录状态、列表与详情字段、业务线差异、搜索筛选规则等是否存在问题。

输出问题清单。

本轮只分析，不修改代码。

然后让 AI 按严重程度输出：

P0：严重问题

B1 登录后无法继续刚才的收藏操作

P1：中等问题

B2 列表与详情价格口径不一致

P1：中等问题

B3 A 业务详情出现 B 业务字段

P2：优化问题

B4 空状态缺少下一步引导

接下来由人决定：

B1、B2、B3 修改，B4 暂时不处理。

最后再让 AI 按照选中的问题修改。

这里非常重要的一点是：

先分析，再决策，最后修改。

不要直接把产品决策权交给 AI。

8. 最终交付的，不应该是一堆聊天记录

整个项目结束以后，真正需要留下来的应该是一套可以继续使用的材料。

例如：

css 复制代码

AI-Prototype/
│
├── 产品说明.md
├── A-B业务差异说明.md
├── 功能梳理与问题清单.md
├── 项目规则.md
│
└── prototype/
    ├── index.html
    ├── list-a.html
    ├── detail-a.html
    ├── list-b.html
    ├── detail-b.html
    ├── mine.html
    ├── app.js
    └── app.css

这套材料分别解决：

需求有依据、修改有规则、问题有记录、原型能演示。

这样后续交给研发的时候，对方问的问题会逐渐从：

"这个页面到底有没有这个按钮？"

变成：

"这个字段后台应该怎么设计？"

到了这一步，原型才真正完成了它的任务。

9. AI 并不会取代产品经理

整个过程做下来，我最大的感受反而不是：

"以后不用画原型了。"

而是 AI 改变了从需求到原型之间的协作方式。

AI 可以：

读得快、写得快、生成快、修改快。

但真正需要人决定的问题仍然存在：

这个功能到底做不做？
两条业务是不是同一种逻辑？
用户真正关心什么？
一期做到哪里应该停？
哪个问题现在必须解决？
哪个问题可以以后再处理？

AI 可以几分钟多生成五个页面。

但产品经理真正应该思考的是：

这五个页面真的应该存在吗？

所以我更愿意把 AI 原型理解成：

一种低成本把产品想法变成"可验证对象"的方式。

而不是一个自动画图工具。

最终我的整个工作流可以浓缩成一句话：