产品经理的 Claude Code 技能包实战（三）：移动端原型，左预览右介绍的演示套装

这是《产品经理的 Claude Code 技能包实战》系列的第 3 篇。 前两篇把 PRD 写出来、把任务拆给研发。这一篇回到 PM 另一件高频的事——做原型给老板和开发讲。这是整个系列里我认为差异化最强的一个技能包。

一、痛点：AI 生成的原型，是「能看」但「没法讲」的

让 AI 做个移动端原型，现在很容易。但真拿去用，三个问题立刻暴露：

• 是单页的死页面——真实需求往往是一套多页流程，AI 给你一个孤立的页面，讲不清来龙去脉
• 没有讲解——老板打开看到的是一堆界面，不知道每个页面干嘛、为什么这么设计，你得站旁边口头解释
• 演示时手忙脚乱——讲到第三个页面，老板问「刚才那个呢」，你在一堆浏览器标签里翻找

说白了，AI 生成的是「设计稿」，而 PM 需要的是「能拿去演示和评审的方案」。这两者之间，差着一整套叙事的骨架。

二、为什么做成技能包：把「演示级原型」的骨架固化下来

关键洞察是：做一套能演示的原型，难点不在画出界面，在于结构——总览怎么组织、每页怎么讲、页面之间怎么串。

这套结构是可以固化的。所以 mobile-prototype 做的不是「帮你画页面」，而是给你一套演示级原型的骨架，AI 往里填内容。骨架包括三块：

1. 一个 plan.html 方案总览——先讲清楚整个方案，再进入具体页面
2. 每页强制「左预览右介绍」——左边手机框里是原型，右边是讲解
3. 一套强制的目录和命名约定——保证多页之间能串、能维护

三、这个技能包长什么样

触发方式

说「做一套移动端原型」「多页原型」「需要方案总览」「给老板看」「评审用」「演示用」就激活。也有反向约束——单文件原型走 frontend-design、Web 后台走 ui-ux-pro-max，不越界。

强制目录结构

<feature-name>-v1/
├── plan.html              # 方案总览（必须）
├── index.html             # 入口页（必须）
├── <page-2>.html          # 业务页 2、3 ...
├── styles/                # 共享样式（base/plan/prototype-intro + 每页独立）
├── scripts/               # store.js 跨页状态 + data.js 共享数据 + 每页独立脚本
└── .claude/launch.json    # 预览服务配置

关键约定：每页一个 .html + 同名 .css + 同名 .js；共享的放 styles/、scripts/。plan.html 是总览，从「进入原型 →」跳到 index.html。

核心亮点 1：左预览右介绍的单页结构

每个业务页强制四块：

<div class="pi-layout">
  <header class="pi-header">...</header>   <!-- ① 顶部 -->
  <main class="pi-main">
    <div class="pi-phone-col">...</div>     <!-- ② 左：手机框里的原型 -->
    <aside class="pi-intro-col">...</aside> <!-- ③ 右：介绍区 -->
  </main>
</div>

右侧介绍区里，5 个 section 缺一不可：

1. 使用角色 —— 谁在本页做什么
2. 本页定位 —— 一句话锚点 + 上下游
3. 怎么用 —— 3 步以内，每步一句话
4. 示例 —— 具体场景 + 关键值高亮
5. 场景呼应 —— 列出前后页，把流程串起来

这就是「能讲」的秘密：介绍区本身就是讲稿。老板自己照着右边读，就能看懂这一页。你不用站旁边解释。

核心亮点 2：plan.html 方案总览（6-section）

总览页把整个方案讲清楚，再让人点进具体页面：

Hero（方案名 + 简介 + CTA + 迷你手机缩略图）
① 背景与痛点
② 业务角色 · 场景 · 流程（客户类型 Tab + Mermaid 流程图）
③ 方案核心（2×2 卡片）
④ 功能介绍（可选）
⑤ 页面导览（grid 卡片列出所有页面）

流程图里每个节点点击还能弹窗，展开「业务场景 / 业务动作 / 功能清单」——复杂方案的层级叙事全在这一页里。

四、实战：一句话到能演示

用脚手架生成一套「客户积分查询」原型：

node ~/.claude/skills/mobile-prototype/scaffold.js \
  --name "customer-points-v1" \
  --title "客户积分查询" \
  --pages "index:积分首页, detail:积分明细" \
  --roles "客户·小王, 客服·李婷"

骨架（plan.html + 两个业务页 + 共享样式脚本）一次性生成。接下来：

1. 用 frontend-design 在每页的 .pi-phone-col 里填真实原型
2. 按 5-section 标准填右侧介绍区
3. 改 plan.html 的 Mermaid 流程图为实际业务流程
4. 起预览服务在浏览器里过一遍

出来的就是一套带总览、每页带讲解、流程能串起来的演示套装，直接发给老板或投屏评审。

五、踩坑与设计取舍

这个技能包的规范是迭代了很多版才定下来的，挑几个有代表性的：

1. 为什么强制「左预览右介绍」而不是让 AI 自由排版？ 因为演示场景里，讲解和画面必须同屏。早期让 AI 自由发挥，它有时把说明放在页面底部、有时干脆不写，演示时根本没法用。固化成「左预览右介绍 + 5-section」后，每一页天然就是一张「能讲的幻灯片」。

2. plan.html 有一张「内容归属表」，防止信息重复。 AI 写方案最爱犯的毛病是同一句话在 Hero、痛点、方案核心里重复说。技能包里专门列了张表：方案定位只能出现在 ①、核心动作只能在 ③、节点级动作只能在弹窗里……违反就视为排版 bug。还配了排版硬指标（单页 ≤1500px、Hero 标题锁定 24px），防止 AI 把页面排得又臭又长。这些细到像素的约束，正是「现写提示词」做不到、只能靠 skill 沉淀的。

3. 一长串「反模式」清单。技能包里有一节明确禁止：不用占位图（用 CSS 几何图形）、不引入 Redux/Vuex（用自带 store.js）、不写死 hex 颜色（必须用--pi-*CSS 变量）、单页超 500 行必须拆分、不写死预览端口（autoPort: true`，因为本机 9881/9882 常被占用）。每一条都是踩过的坑**，固化下来后 AI 不会再犯。

六、写在最后

做演示级原型，AI 画界面是基本功，真正值钱的是那套「总览 + 左预览右介绍 + 流程串联」的叙事骨架。mobile-prototype 把这套骨架固化下来，让 AI 每次产出的都是「能直接拿去讲」的方案，而不是一堆需要你再加工的设计稿。

下一篇（四）：原型做好了，开发还是会在群里问「这个按钮点了跳哪」——《给原型自动加标注，开发不再问交互》。聊聊怎么给原型自动打上可点击的交互说明。

系列目录

• （一）用技能包写 PRD：为什么小而精胜过大而全 —— prd-writer
• （二）把 PRD 一键变成禅道任务 —— pm-zentao-task
• （三）移动端原型：左预览右介绍的演示套装 —— mobile-prototype（本篇）
• （四）给原型自动加标注，开发不再问交互 —— annotation-generator
• （五）原型一键部署上线 —— deploy-prototypes
• （六）UI 设计：67 风格 161 配色实测 —— ui-ux-pro-max
• （七）搭设计系统：三层 Token 实战 —— design-system
• （八）幻灯片与 Banner —— slides / banner-design
• （九）给 AI 装上眼睛和手 —— agent-reach / kimi-webbridge
• （十）把真人思维做成 AI 顾问 —— zhangxuefeng-skill
• （十一）让 AI 自己写测试、自己调试 —— superpowers
• （十二·终篇）我沉淀技能包的方法论：skill 是资产不是代码