---

name: prototype-orchestrator-pro description: 将口语化需求、会议纪要、聊天记录或半结构化需求文档编排为可交互的单文件 HTML 产品原型。用于”帮我做原型””把需求变成界面””根据会议纪要出后台页面””做个低保真/中保真页面””prototype from requirements””convert notes to UI”等场景；先归一需求，再输出 ProductSpec、页面方案与 frontend-design 渲染指令。

Prototype Orchestrator Pro

把模糊需求转成可评审、可渲染的原型规格，而不是只列功能点。

按阶段工作

只在当前阶段读取必要资源，避免一次性加载全部上下文。

1. 识别输入类型和输出模式。
   • 读取 references/input-normalization.md。
   • 将输入识别为：口语化需求、会议纪要、半结构化需求、目标导向型需求、需求文档。
   • 用户只说“先看效果”“先出图”“不用解释太多”时，切换到快速模式。
2. 建立产品规格。
   • 读取 references/prototype-spec-schema.md。
   • 选择视觉预设时，再读取 references/design-presets.md。
3. 展开页面和交互。
   • 需要具体交互时，读取 references/interaction-recipes.md。
4. 生成渲染交接。
   • 读取 references/rendering-prompt-template.md（已包含渲染规范）。
   • 需要骨架时，再读取 assets/prototype-template.html。
   • 只在此阶段读取 frontend-design skill。
5. 结束前自检。
   • 按下方「交付前自检清单」逐项检查。

需要校准输出风格时，再读取 examples/meeting-notes-to-prototype.md。

坚持这些原则

• 先归一事实，再做页面。
• 先定义角色、任务、页面树和状态，再做视觉。
• 把补全内容标记为 [默认推断]，不要伪装成已确认需求。
• 除非缺失会改变产品方向，否则不要频繁追问。
• 永远输出页面、动作、状态和跳转，不要只输出模块名。

选择运行模式

快速模式

在用户更看重“先看到效果”时使用。

输出：

• [需求解析摘要（压缩版）]
• [页面设计方案]
• [原型渲染指令]

规则：

• 只保留主链路。
• 默认先做 1 个总览页 + 1 个列表页 + 1 个详情层。
• 默认先渲染 P0，再补 P1。

专业模式

在用户需要需求梳理、方案评审或多角色页面结构时使用。

按顺序输出：

1. [需求解析摘要]
2. [产品建模结果]
3. [页面设计方案]
4. [原型渲染指令]

产出每个阶段

产出 [需求解析摘要]

提取并整理：

• 产品方向
• 目标用户
• 业务目标
• 关键对象
• 已确认事实
• [默认推断]
• 待确认项（最多 5 条，只保留高影响项）

会议纪要额外提炼：

• 已达成结论
• 待办项
• 优先级
• 争议点

产出 [产品建模结果]

严格按 references/prototype-spec-schema.md 组织，至少包含：

• 角色清单
• 模块清单
• 页面清单（P0 / P1 / P2）
• 主流程
• 关键实体与状态
• 权限边界
• 视觉预设选择与理由

产出 [页面设计方案]

为每个核心页面输出：

### 页面名
- 页面目标：
- 适用角色：
- 页面布局：
- 核心区域：
- 核心字段 / 数据：
- 主操作 / 次操作：
- 交互行为（至少 2 条）：
- 状态反馈（loading / empty / error / no_permission）：
- 页面跳转关系：

满足最低要求：

• 每页至少 3 个组件
• 每页至少 2 条可执行交互
• 每页覆盖 4 类状态
• 每页至少 1 组 mock data

产出 [原型渲染指令]

把结构化结果转成交给 frontend-design 的明确任务。

要求：

• 指定产品类型、导航模型、响应策略和视觉预设。
• 指定首批渲染页面，默认先 P0。
• 使用 references/rendering-prompt-template.md 的指令格式和渲染规范。
• 只实现原型层交互，不补业务后端。
• 使用与场景一致的 mock data。

选择视觉预设

按 references/design-presets.md 的决策树选择预设，不按个人偏好随机选色。没有明显行业信号时默认 saas-clean。

控制首轮范围

• 优先做能讲清主链路的 P0 页面。
• 不要在首轮加入拖拽画布、复杂审批引擎、多人协同、条件编排器。
• 页面数过多时，按 references/rendering-prompt-template.md 的分步渲染方式拆批。

进入迭代模式

在用户提出“加一个详情页”“把表格改成卡片”这类修改时：

1. 先定位变更范围：单组件、单页面或跨页面。
2. 只增量修改受影响的 ProductSpec 和页面方案。
3. 只重写受影响的渲染交接。
4. 保持未修改部分的页面结构和视觉基调稳定。

处理失败保护

输入极度混乱时：

• 收敛成最小可行方向。
• 默认输出 1 个总览页 + 1 个列表页 + 1 个详情层。
• 把高不确定项放进“待确认项”，不要阻塞产出。

长会议纪要只抽取影响页面设计的内容，不逐句复述。

交付前自检清单

任何一项明显不满足，先回退修正再输出。

需求忠实度

• 区分了用户原话、已确认事实和 [默认推断]
• 高影响不确定项收敛到"待确认项"
• 会议纪要未逐句复述成流水账

产品结构

• 明确了目标用户、核心目标和关键对象
• 给出了角色、模块、页面和主流程
• 补上了关键实体状态和权限边界

页面完整度

• 输出了真正的页面，而不是功能点清单
• 每个核心页面至少 3 个组件、2 条交互、4 类状态、1 组 mock data

渲染交接质量

• 明确了首批渲染页面和优先级
• 说明了导航模型、响应策略和视觉预设
• 限制在单文件 HTML + 原型层交互范围内

视觉质量

• 颜色符合行业气质，非随机选色
• 避免 Inter、紫色白底、廉价渐变和平均分配多色
• 主色、强调色和状态色职责清晰

发布级视觉

• 界面上没有规格注释、组件说明、交互描述等批注文字
• 按钮和标签只有产品级文案，没有"点击可以……"之类的解释
• Mock data 使用写实内容，没有"示例""测试"等暴露原型身份的文案
• 整体看起来像真实产品，不像带注解的线框图

可交付性

• HTML 可直接浏览器打开
• Hash 路由可用
• 抽屉、弹窗、Toast 至少有一条可演示路径
• 首轮范围收敛，没有无关页面膨胀