pm-agile-workflow

分类: 工具与效率 | 上传者: arcsin1 | 下载: 0 | 版本: v1.0（最新）
指导用户完成更严格的 7 步敏捷 PM 工作流程。当用户有一个粗略的产品想法并需要交互式 HTML 原型、PRD、美人鱼流程图和版本化交付时调用。
更新日志: Source: GitHub https://github.com/arcsin1/pm-agile-workflow
目录结构

当前层级: tree/main/pm-agile-workflow/
📄 SKILL.md 16.2 KB
SKILL.md

---
name: "pm-agile-workflow"
version: "1.0.0"
description: "Guides users through a stricter 7-step agile PM workflow. Invoke when users have a rough product idea and need interactive HTML prototype, PRD, mermaid flowcharts, and versioned delivery."
---

# 敏捷产品经理需求产出工作流 v1.0.0

## 触发方式
当用户提供一个初步的产品想法、功能需求、业务流程、草图、截图、口头描述，且希望最终得到可讨论、可演示、可继续迭代的 **PRD + 交互 HTML 原型 + Mermaid 流程图** 时，立即启用本技能。

**🚨 绝对强制指令**
- 必须严格按七个步骤推进，禁止一次性输出所有步骤结果。
- 每一个带有【等待用户确认】的步骤结束后，必须停止输出并等待用户回复。
- 在步骤一未完成前，不要创建文件、文件夹，不要直接产出 PRD，不要提前写原型。
- 原型是本技能的核心验证环节，不能弱化、更不能省略。

## 本技能的核心价值
- 帮用户把模糊需求逐步收敛成清晰业务逻辑。
- 先通过对话厘清问题，再用 HTML 原型验证交互与遗漏点。
- 最终产出可展示、可评审、可继续版本迭代的完整交付物。

## 适用场景
- 用户只有一个产品想法，还说不清流程和边界。
- 用户需要输出专业级 PRD，但又不希望只得到空框架。
- 用户需要交互式 HTML 原型来验证页面逻辑、异常流和信息结构。
- 用户希望 PRD 中直接嵌入原型切片，方便评审和对齐。

## 不适用场景
- 用户只要求修一段文案、改一个字段、补一个接口说明时，不必强行走完整七步。
- 用户已经明确只要单个文档、单个图、单个页面时，应先完成当前明确任务。

## 全局执行原则
1. 所有输出都要围绕”帮助用户更快发现需求漏洞、交互问题与边界条件”展开。
2. 初版 PRD 不能是空架子，必须带完整业务主线和关键逻辑。
3. 原型必须是单文件 HTML，并包含可验证的关键状态。
4. 每次用户调整原型，必须同步更新 PRD 中对应逻辑、规则和嵌入路径。
5. 最终版 PRD 必须与原型、流程图、版本记录保持强一致。
6. **自动打开预览**：产出 HTML 文件后，必须自动在浏览器中打开，让用户直接看到效果。

## 对话风格要求
- 对用户说人话，专业但不生硬。
- 先复述理解，再展示缺口，再提出追问。
- 不要用机械问卷，不要要求用户先填模板。
- 追问要有启发性，要帮助用户想到之前没想到的问题。

---

## 步骤一：对话式需求采集与确认

### 目标
帮助用户把模糊需求讲清楚，并在开始写文档前完成充分澄清。

### 1.1 接收需求
- 接受任意形式输入，例如一句话、截图、草图、会议纪要、口语化描述。
- 先用自然语言复述你当前的理解，再进入维度评估。

### 1.2 必须展示的 7 个维度评估
收到用户初始需求后，必须直接把以下评估结果展示给用户：
1. **背景/痛点**：为什么要做，现状哪里不顺。
2. **业务目标**：这次做完希望改善什么指标或结果。
3. **用户与场景**：谁在什么情况下会使用。
4. **核心用户旅程**：用户从开始到完成目标会经历哪些关键步骤。
5. **现有方案**：现在怎么做，哪里效率低或体验差。
6. **业务规则**：是否存在审批、权限、时效、合规、数据约束。
7. **参考/竞品**：是否有参考产品、参考页面或喜欢的交互方式。

### 1.3 深度追问规则 【等待用户确认】
- 必须至少进行 3 轮追问。
- 每轮必须提出 3 到 5 个开放式、启发式问题。
- 每轮问题都要基于用户上一轮回答继续深入，不允许重复机械发问。
- 每轮提问后必须停止输出，等待用户回复。
- 只有当你确认已经完整理解需求，并且用户明确表示“没有补充了，可以开始写了”后，才能进入步骤二。

### 1.4 推荐输出结构
第一轮建议使用以下结构：

#### 当前理解
- 用 3 到 6 句话总结用户现在想做什么。

#### 需求清晰度评估
| 维度 | 当前状态 | 说明 |
| --- | --- | --- |
| 背景/痛点 | 清晰/部分清晰/缺失 | ... |
| 业务目标 | 清晰/部分清晰/缺失 | ... |
| 用户与场景 | 清晰/部分清晰/缺失 | ... |
| 核心用户旅程 | 清晰/部分清晰/缺失 | ... |
| 现有方案 | 清晰/部分清晰/缺失 | ... |
| 业务规则 | 清晰/部分清晰/缺失 | ... |
| 参考/竞品 | 清晰/部分清晰/缺失 | ... |

#### 本轮追问
- 问题 1
- 问题 2
- 问题 3

### 1.5 本步骤禁止事项
- 禁止创建目录或文件。
- 禁止提前开始写 PRD。
- 禁止在需求未确认前直接进入原型阶段。

---

## 步骤二：项目初始化与目录架构搭建

### 目标
在正式产出前建立清晰目录结构，让 PRD、原型、流程图和附件各归其位。

### 2.1 推荐目录命名
- `requirements/`
- `prototypes/`
- `flows/`
- `attachments/`
- `templates/`

### 2.2 目录规则
- 根目录建议使用项目名。
- PRD 文件统一放在 `requirements/`
- 原型文件统一放在 `prototypes/`
- Mermaid 流程图源码或导出文件统一放在 `flows/`
- 原始资料、数据字典、补充材料统一放在 `attachments/`

### 2.3 对用户必须展示的内容
- 展示目录树
- 说明后续每一类产物的保存位置
- 告知后续版本迭代将沿用该结构

### 2.4 推荐目录树
```text
<project-name>/
├── requirements/
├── prototypes/
├── flows/
├── attachments/
└── templates/
```

---

## 步骤三：输出详细的第一版初步 PRD

### 目标
基于步骤一确认过的信息，先产出一份足够详细、足够可讨论的 HTML 初版 PRD。

### 3.1 文件要求
- 必须使用 HTML 格式。
- 存放在 `requirements/` 目录。
- 推荐命名：`prd_v1.0.html`

### 3.2 初版 PRD 必须深度填充的内容
1. 项目基本信息
2. 需求背景与目标
3. 用户使用场景与用户旅程
4. 详细功能清单与基础业务逻辑

### 3.3 具体要求
- **需求背景与目标**：必须使用四列表格，包含目标类型、描述、衡量指标、目标值。
- **用户旅程**：必须覆盖阶段、用户触点、用户行为、痛点/情绪、产品机会点。
- **功能清单**：不能只列模块名，必须写清主线流程、前置条件、规则和数据流向。
- 尚未确认的详细交互可以标注“待原型确认后补充”，但不能让主体内容空着。

### 3.4 用户确认话术 【等待用户确认】
该步骤结束时，必须向用户发出以下确认引导：

> 这是产品的详细第一版架构和业务逻辑，您看方向和基础逻辑准确吗？如果没问题，我们下一步先进入原型设计，通过具体画面进一步验证交互细节和可能遗漏的功能。

发出确认后必须停止输出，等待用户回复。

---

## 步骤四：产出高保真 HTML 原型（核心验证阶段）

### 目标
通过可交互的 HTML 原型，把抽象需求变成可以直接看到、点击、挑错的画面。

### 4.1 原型强制规范
1. 必须产出 **单文件 HTML 原型**
2. 文件中必须包含完整 CSS
3. 强制使用 **Tailwind CSS**
4. 页面风格应现代、清晰、适合评审
5. 必须包含关键交互状态，例如默认态、弹窗态、空状态、成功态、失败态、加载态
6. 可使用原生 JavaScript 或 URL Hash 做页面切换

### 4.2 Focus Mode 强制要求
为了支持 PRD 中的功能切片展示，原型必须支持专注模式：
- 必须解析 URL 参数中的 `focus`
- 当 `focus=<feature_id>` 生效时，只允许对应功能区域可交互
- 其他区域必须弱化、锁定或遮罩
- 可以使用 `pointer-events: none`、`opacity`、遮罩层等方式实现

### 4.3 推荐设计增强
在生成原型前，应主动提示用户：

> 为了让原型达到更专业的高级 UI 效果，如果当前环境已安装 `frontend-design` 或类似设计增强技能，我会优先调用它来生成更完整、更精致的界面。

### 4.4 原型审查与迭代循环 【等待用户反馈】
- 生成原型后，**必须自动在浏览器中打开原型文件**，让用户直接预览
- 打开方式：使用 Bash 工具执行 `open <文件路径>`（macOS）或 `start <文件路径>`（Windows）
- 必须主动引导用户从以下角度思考：
  - 这里有没有缺少返回路径
  - 如果断网或接口失败，应该怎么提示
  - 如果为空数据，页面是否有引导
  - 权限不足时该怎么处理
  - 成功操作后用户下一步要去哪里
- 每次用户提出修改，都必须同步更新：
  - 原型 HTML
  - PRD 中对应功能的详细方案描述
  - PRD 中嵌入原型的切片路径
- 只有当用户明确表示“完全满意”或“可以进入下一步”时，才可进入步骤五

---

## 步骤五：输出流程图（Mermaid）

### 目标
在原型跑通后，用 Mermaid 固化核心主线与异常分支。

### 5.1 格式要求
- 使用 Mermaid
- 推荐 `flowchart TD` 或 `sequenceDiagram`

### 5.2 内容要求
- 重点体现主操作链路
- 必须补充原型审查中暴露出的异常流程
- 应覆盖断网、失败、空状态、权限不足、校验失败等必要分支
- 书写时避免导致 Mermaid 渲染失败的特殊字符组合

### 5.3 推荐文件
- 存放位置：`flows/`
- 推荐命名：`flowchart_v1.0.md`

---

## 步骤六：产出最终版 PRD（内嵌原型与切片）

### 目标
整合前几步产物，输出一份真正可评审、可展示、可演示的最终 HTML PRD。

### 6.1 PRD 基本要求
- 必须使用语义话的 HTML 格式，确保独立打开即可使用，确保符合HTML5标准
- 必须有清晰目录导航
- 必须有良好的字体层级、留白、表格与模块布局
- 如环境可用设计增强能力，应优先提升排版与可读性

### 6.2 标准章节结构
1. 项目信息与版本记录
2. 一、需求背景
3. 二、需求目标
4. 三、用户与使用场景
5. 四、需求功能清单
6. 五、详细方案
7. 六、业务流程图
8. 七、异常与边界处理
9. 八、数据追踪与埋点
10. 九、未来演进规划
11. 十、附件

### 6.3 详细方案的模块化要求
每一个核心功能点必须包含以下三部分：
1. 交互逻辑流程图
2. 详细规则描述
3. 专注模式原型切片

### 6.4 iframe 切片规则
- 原型必须支持 Hash 路由，例如 `prototype_v1.0.html#login`
- iframe 的 `src` 必须带 `focus` 参数，例如 `?sandbox=true&focus=login#login`
- 移动端原型可使用固定尺寸，如 `375 x 812`
- Web 端原型可使用响应式宽度
- iframe 必须设置 `sandbox="allow-scripts allow-same-origin"`
- 建议移除边框，保证嵌入视觉整洁

### 6.5 推荐 HTML5 语义结构
```html
<article class="feature-module">
  <header class="feature-header">
    <h3>功能：用户登录</h3>
    <p>用于说明该功能的目标、适用场景与核心价值。</p>
  </header>

  <section class="feature-content" style="display: flex; gap: 20px; align-items: flex-start;">
    <section class="logic-rules" style="flex: 1;">
      <section aria-labelledby="login-flow-title">
        <h4 id="login-flow-title">交互流程图</h4>
        <div class="mermaid" role="img" aria-label="用户登录交互流程图">
        flowchart TD
        ...
        </div>
      </section>

      <section aria-labelledby="login-rules-title">
        <h4 id="login-rules-title">规则描述</h4>
        <dl>
          <dt>触发条件</dt>
          <dd>...</dd>
          <dt>交互反馈</dt>
          <dd>...</dd>
          <dt>异常处理</dt>
          <dd>...</dd>
        </dl>
      </section>
    </section>

    <aside class="sandbox-preview" aria-labelledby="login-prototype-title">
      <h4 id="login-prototype-title">原型预览</h4>
      <figure>
        <iframe
          title="用户登录原型预览"
          src="../prototypes/prototype_v1.0.html?sandbox=true&focus=login#login"
          style="width: 375px; height: 812px; border: none;"
          sandbox="allow-scripts allow-same-origin"
        ></iframe>
        <figcaption>聚焦展示登录功能的交互原型切片。</figcaption>
      </figure>
    </aside>
  </section>
</article>
```

### 6.6 交付检查
- 产出最终版 PRD 后，**必须自动在浏览器中打开**，让用户直接查看完整交付物
- 打开方式：使用 Bash 工具执行 `open <文件路径>`（macOS）或 `start <文件路径>`（Windows）

### 6.7 交付清单
- [ ] 是否包含清晰用户旅程图
- [ ] 是否每个核心功能都有 Mermaid 流程图
- [ ] 是否每个原型切片都开启 Focus Mode
- [ ] 是否补充断网、空数据、无权限等异常说明
- [ ] 是否保证 PRD 与原型路径完全一致

---

## 步骤七：版本迭代与管理

### 目标
让后续每次迭代都保留历史快照，并保持 PRD 与原型版本同步。

### 7.1 文件物理隔离
- 绝对不要覆盖历史版本
- 从 `v1.0` 迭代到 `v1.1` 时，必须复制：
  - `requirements/prd_v1.0.html` → `requirements/prd_v1.1.html`
  - `prototypes/prototype_v1.0.html` → `prototypes/prototype_v1.1.html`
- 所有后续修改都在新版本文件中进行

### 7.2 PRD 内版本切换器
- 在 PRD 页面右上角增加版本切换下拉菜单
- 支持在 `v1.0`、`v1.1` 等版本间跳转
- 若当前页面是历史版本，建议显示明显提示横幅

### 7.3 变更日志与双向联动
- 在新版 PRD 的版本记录中写清新增、修改、下线内容
- 所有嵌入原型的 iframe 路径必须同步切换到对应版本
- PRD 与原型版本号必须严格一致

---

## 自动预览规则

在以下节点完成后，必须自动在浏览器中打开产出的 HTML 文件：

| 步骤 | 产出文件 | 自动打开 |
|------|----------|----------|
| Step 3 | `requirements/prd_v1.0.html` | ✅ |
| Step 4 | `prototypes/prototype_v1.0.html` | ✅ |
| Step 6 | `requirements/prd_v1.0_final.html` | ✅ |

**打开命令：**
```bash
# macOS
open requirements/prd_v1.0.html

# Windows
start requirements/prd_v1.0.html

# Linux
xdg-open requirements/prd_v1.0.html
```

**注意：** 必须使用 Bash 工具执行打开命令，不要让用户手动操作。

---

## 执行质量底线
- 不要把七步法压缩成一步完成
- 不要在用户未确认时自动跳步
- 不要只给静态文档，不做交互原型
- 不要只改原型，不改 PRD
- 不要给空洞框架式 PRD
- 不要覆盖历史版本文件

## 快速判断口诀
- 先问清，再建目录
- 先出初版 PRD，再做 HTML 原型
- 原型每改一处，PRD 同步一处
- 原型跑通后，再补 Mermaid 流程图
- 最终交付必须可读、可演示、可迭代

---

## 快速开始示例

**用户输入：**
> "我想做一个积分兑换功能，用户可以用积分换商品"

**执行过程：**
```
Step 1 → 追问澄清：积分来源？兑换限制？库存处理？...
Step 2 → 创建目录：requirements/ prototypes/ flows/
Step 3 → 输出 prd_v1.0.html（含功能清单、业务规则）
Step 4 → 输出 prototype_v1.0.html（商品列表、兑换弹窗、成功/失败态）
Step 5 → 输出 flowchart_v1.0.md（主流程 + 异常分支）
Step 6 → 输出 prd_v1.0_final.html（内嵌原型切片）
Step 7 → 版本记录、变更日志
```

**最终产出：**
```
points-exchange/
├── requirements/
│   ├── prd_v1.0.html
│   └── prd_v1.0_final.html
├── prototypes/
│   └── prototype_v1.0.html
├── flows/
│   └── flowchart_v1.0.md
└── attachments/
```

---

## 前置依赖

| 依赖项 | 说明 | 是否必需 |
|--------|------|----------|
| Tailwind CSS | 原型样式，通过 CDN 自动引入 | 否（自动处理） |
| Mermaid.js | PRD 中流程图渲染，通过 CDN 自动引入 | 否（自动处理） |
| 现代浏览器 | Chrome / Firefox / Safari / Edge | 是 |

**CDN 引入示例（原型中自动包含）：**
```html
<!-- Tailwind CSS -->
<script src="https://cdn.tailwindcss.com"></script>

<!-- Mermaid.js（PRD 中使用） -->
<script src="https://cdn.jsdelivr.net/npm/mermaid/dist/mermaid.min.js"></script>
```

---

## 推荐配合使用的 Skill

| Skill 名称 | 用途 | 场景 |
|------------|------|------|
| frontend-design | UI 设计增强 | 需要更精致的界面效果时 |

---
登录后下载/点赞/收藏 ❤ 21 | ★ 0
pm-agile-workflow

目录结构

SKILL.md

举报内容

提示
