agile-pm-workflow

name	agile-pm-workflow
description	Guides novice PMs through a 7-step agile workflow: dialogue-based requirement gathering, drafting PRD skeleton, HTML prototype creation (via frontend-design), mermaid flowcharts, and final PRD with iframe slices.

敏捷产品经理需求产出工作流 (Agile PM Workflow)

触发方式

当用户提供一个初步的想法或需求描述时，请严格按照以下七个步骤引导用户。 🚨 绝对强制指令：你必须一步一步（Step-by-Step）执行！绝不允许一次性输出所有步骤的结果。在每一个带有【等待用户确认】的步骤结束后，你必须停止输出，等待用户的回答！

---

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

新手往往难以一次性说清需求。AI 应首先采用「灵活对话式」引导，主动评估、温和追问、并进行总结确认。在需求未明确前，不要急于创建文件或文件夹。

1.1 接收需求

• 接受用户的任意形式输入（一句话、截图、草图、大白话）。
• 不要要求用户填写复杂的固定模板，降低认知门槛。

1.2 核心维度评估与反馈

当你接收到用户的初步需求后，必须将以下 7 个关键维度的评估结果直接展示给用户，告诉他们当前需求在哪些维度是清晰的，哪些是缺失的：

1. 背景/痛点：为什么要做？现状有什么问题？（必须）
2. 业务目标：做完后想达到什么效果？（必须）
3. 用户与场景：谁在什么具体情况下使用？（必须）
4. 核心用户旅程：用户从接触到完成目标的关键路径是怎样的？中间有什么触点和痛点？（必须）
5. 现有方案：现在他们是怎么解决这个问题的？（重要）
6. 业务规则：有哪些必须遵守的限制或特定流程？（重要）
7. 参考/竞品：有没有喜欢的对标产品？（加分项）

1.3 深度追问与多轮确认 【等待用户确认】

🚨 关键规则：不要急于总结，必须进行至少 3 轮深度的启发式追问！

• 追问方式：抛弃死板的选项（A/B/C），采用开放式、启发式的提问，引导用户多方面、更全面地思考这个需求。
• 追问数量：每次追问必须在 3 到 5 个问题之间。
• 循环机制：基于用户的上一次回答，挖掘出新的盲点继续追问，至少进行 3 轮对话。
• 最终确认：只有当你通过多轮追问完全理解了需求的所有细节，并且用户明确表示“没有补充了，可以开始写了”之后，你才能进行结构化复述并进入下一步。
• 🛑 强制暂停：在每一轮提问后必须停止输出！等待用户回复后才能进行下一轮动作。

---

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

在需求确认无误，准备开始产出文档之前，必须先帮用户建立一个清晰、规范的项目文件夹结构，避免后期文件混乱。

2.1 建立标准目录树

主动为当前项目创建一个专属的根文件夹（如以项目名称命名），并在其中创建以下标准子目录：

• prd/：用于存放所有的产品需求文档（如 prd_v1.0.html）。
• prototype/：用于存放所有的高保真 HTML 原型文件。
• flowcharts/：用于存放 Mermaid 流程图或导出的图片。
• annex/：用于存放各种附件（如原始的 Excel/CSV 数据字典、需求原始文稿、参考资料等）。
• templates/：用于存放工作流模板或参考文件（如 prd_template.md）。

2.2 确认架构

向用户展示创建好的目录结构，并告知后续的产出物都将分类存放在这些对应的文件夹中。

---

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

🚨 关键规则：初步的 PRD 也必须非常详细，不能只是一个空框架。

3.1 产出内容

根据步骤一的确认信息，直接生成一份详细的初步 HTML 格式文档（存放在 prd/ 目录下）。这份初版 PRD 必须搭建好完整的文档结构骨架（参考 6.1 节的标准目录），并且必须深度填充以下部分：

1. 项目基本信息
2. 需求背景与目标：必须包含四列表格（目标类型、描述、衡量指标、目标值）。
3. 用户使用场景与旅程图：必须使用表格或清晰的结构描述用户旅程（User Journey Map），包含：阶段、用户触点、用户行为、痛点/情绪、产品机会点，要具备强烈的代入感。
4. 详细的功能清单与基础逻辑：不能只列出模块和名称，必须详细梳理出核心的操作主线、前置条件、基本业务规则和数据流向。 （后续章节如详细方案带原型的模块、整体流程图等可先留空，并注明“待原型确认后补充”）

3.2 用户确认 【等待用户确认】

询问用户：“这是产品的详细第一版架构和业务逻辑，您看方向和基础逻辑准确吗？如果没问题，我们将先进行【原型设计】，通过具体的画面来进一步理清交互细节和可能遗漏的功能。” 🛑 强制暂停：在此处必须停止输出！等待用户回复同意后，才能进入步骤四。

---

步骤四：产出高保真 HTML 原型 (核心验证阶段)

这是本工作流最具特色的环节。 新手往往在看到具体画面后，才能发现逻辑上的漏洞（如缺失的返回按钮、未考虑的空状态）。

4.1 原型规范

1. 产出 单文件 HTML 原型，包含完整的 CSS 样式。
2. 强制使用 Tailwind CSS，并采用现代、简洁的设计风格。
3. 必须包含关键的交互状态（如：默认页、展开弹窗、成功提示等）。可以通过简单的原生 JavaScript 或 URL Hash (#page1) 来实现页面切换。
4. 沙盒锁定支持 (Focus Mode)：在编写原生 JavaScript 时，必须加入 URL 参数解析逻辑（如 ?focus=feature_id）。当处于 focus 模式时，锁定或遮罩其他无关的交互区域（如设置 pointer-events: none; opacity: 0.5），仅允许用户操作对应的功能点。这为了后续在 PRD 嵌入原型时，实现“仅展示对应功能交互”的需求。

4.2 💡 强烈推荐使用 Impeccable Skills

在生成原型前，AI 必须主动向用户推荐业界顶级的前端设计指令集：

“为了让原型达到专业级的高级 UI 效果，我强烈建议您使用 Impeccable 提供的设计技能库。如果您在编辑器中（如 Trae/Cursor）已经安装了 frontend-design 或 teach-impeccable 等指令，请告诉我，我将调用这些专业的前端设计规范为您生成精美的界面。”

4.3 原型审查与 PRD 双向同步更新 (核心迭代循环) 【等待用户反馈】

• 将生成的 HTML 代码或预览呈现给用户。
• 引导用户思考：“看看这个界面，您觉得用户点完这个按钮后，如果网络断了该怎么提示？这里的信息展示够全吗？”
• 🛑 强制暂停：在此处必须停止输出！等待用户反馈修改意见。
• 根据用户的反馈修改原型。
• 🚨 关键规则（PRD 实时同步）：每次用户提出对原型的修改（如增加功能、修改交互逻辑、调整页面流转），AI 必须在修改 HTML 原型的同时，同步更新第二版（详细版）PRD 中对应的“详细方案”表格。不仅要更新逻辑描述，还要确保切片引用路径与最新原型保持一致。
• 只有当用户对原型表示“完全满意”、“可以进入下一步”时，才可进入步骤五。

---

步骤五：输出流程图 (Mermaid)

在原型跑通后，业务逻辑已经相对清晰，此时再来画流程图。

1. 使用 Mermaid 语法（flowchart TD 或 sequenceDiagram）。
2. 重点描绘：用户的核心操作主线，以及刚才在原型审查中发现的异常分支。
3. 确保代码中没有会导致渲染错误的特殊字符（如未转义的中文括号）。

---

步骤六：产出最终版 PRD (内嵌原型与切片)

综合前四步的所有成果，输出最终的详细产品需求文档。

6.1 格式与结构要求

• 必须使用 HTML 格式 输出，确保独立运行可用。
• 排版与 UI 规范：
  • 动态 UI 升级 (Impeccable Skills)：如果用户在工作流执行期间安装了 Impeccable Skills，你必须在生成或更新 PRD 时调用相关指令（如 /typeset, /arrange, /colorize），对 PRD 的排版和色彩进行高级 UI 升级。
  • 目录导航 (TOC)：页面左侧或顶部必须提供悬浮的目录导航，方便快速跳转。
  • 字体层级与间距：严格区分 H1（页面标题）、H2（章节标题）、H3（模块标题），设置合适的 line-height (如 1.6) 和段落间距（如 margin-bottom: 1.5rem），确保阅读体验舒适。
• PRD 必须严格遵循以下标准目录结构进行组织：
  1. 项目信息与版本记录 (包含右上角的版本切换下拉菜单预留)
  2. 一、需求背景 (现状问题、为什么现在做)
  3. 二、需求目标 (目标类型、描述、衡量指标、目标值)
  4. 三、用户与使用场景 (典型用户与 User Journey)
  5. 四、需求功能清单 (骨架与优先级)
  6. 五、详细方案 (带原型沙盒切片，见下文 6.2)
  7. 六、业务流程图 (Mermaid 格式)
  8. 七、异常与边界处理 (断网、空状态、无权限等)
  9. 八、数据追踪与埋点 (可选)
  10. 九、未来演进规划 (Roadmap)
  11. 十、附件 (数据字典/工艺标准等)

6.2 详细方案设计 (独立功能模块化展示)

PRD 中的核心部分是“详细方案”。必须摒弃传统的纯文字或简单表格，改为模块化分块布局。

对于每一个核心功能点，必须包含以下三部分：

1. 交互逻辑流程图：使用 Mermaid 画出该功能的具体交互分支和异常流转。
2. 详细规则描述：文字说明触发条件、交互反馈、异常处理（如断网、空数据）。
3. 专注模式沙盒切片：使用 <iframe> 嵌入对应原型。

如何进行原型切片与沙盒锁定？

1. Hash 路由定位：确保原型 HTML 支持 URL Hash 路由（如 index.html#login）。
2. Focus 模式参数：在 iframe 的 src 中加上专注参数（如 ?sandbox=true&focus=login），原型代码会据此锁定无关功能。
3. 尺寸控制 (Web vs 移动端)：
   • 移动端原型：强制设定 iframe 的宽度（如 width: 375px; height: 812px;），可通过 CSS transform: scale(0.7) 缩小。
   • Web端/后台原型：使用响应式宽度（如 width: 100%; height: 600px;）。
   • 去除边框：加上 border: none; background: transparent;。
4. 沙盒隔离 (Sandbox)：在 iframe 上添加 sandbox="allow-scripts allow-same-origin" 属性。

HTML 结构示例：

<div class="feature-module">
  <h3>功能：用户登录</h3>
  <div class="feature-content" style="display: flex; gap: 20px;">
    <div class="logic-rules" style="flex: 1;">
      <h4>交互流程图</h4>
      <div class="mermaid">
        flowchart TD
        ...
      </div>
      <h4>规则描述</h4>
      <ul>
        <li><strong>触发条件</strong>: ...</li>
        <li><strong>交互反馈</strong>: ...</li>
      </ul>
    </div>
    <div class="sandbox-preview">
      <iframe src="../prototype.html?focus=login#login" style="width:375px; height:812px; border:none;" sandbox="allow-scripts allow-same-origin"></iframe>
    </div>
  </div>
</div>

6.3 交付检查

• 包含了清晰的用户旅程图（User Journey Map）。
• 详细方案中，每个功能点都有对应的Mermaid流程图。
• 详细方案中，每个原型沙盒都开启了锁定无关功能的 Focus 模式。
• 异常情况（断网、空数据、权限不足）已被补充到文档中。

---

步骤七：版本迭代与管理 (Version Control)

当项目进入后续迭代阶段（例如从 v1.0 升级到 v1.1）时，必须执行严格的结构化版本控制，确保历史可追溯，且不破坏过往版本。

7.1 文件物理隔离与复制

• 绝对不要直接覆盖历史版本。
• 在进行 v1.1 迭代时，需进入 prd/ 和 prototype/ 文件夹，将 prd_v1.0.html 和 prototype_v1.0.html 复制一份，并重命名为 prd_v1.1.html 和 prototype_v1.1.html。
• 后续所有的修改仅在 v1.1 文件中进行，保留 v1.0 作为历史快照。

7.2 PRD 界面内的版本切换器

• 在生成的 PRD HTML 页面右上角，必须增加一个**“版本切换下拉菜单”**。
• 用户可以通过下拉菜单在 v1.0、v1.1 等不同版本间一键跳转。
• 提示：如果当前查看的是历史版本，可在页面顶部加一条明显的警告横幅（如：“您正在查看历史版本 v1.0，点击此处前往最新版 v1.1”）。

7.3 变更日志与双向联动

• 在新版 PRD 的【版本记录】表格中，详细记录本次迭代新增、修改或下线的具体功能点。
• PRD 与原型必须强联动：在 prd_v1.1.html 中，所有通过 iframe 嵌入的原型切片路径，必须统一修改指向 ../prototype/prototype_v1.1.html，确保文档和原型版本的严谨对应。