Full upload: MCNVideo AI project with .workbuddy
This commit is contained in:
maogeigei committed
commit
782e06c1ab
760 files changed
+170975
No files matched your search
@@ -0,0 +1,86 @@
|
||||
---
|
||||
name: ProductTeamWork
|
||||
description: 这是一个模拟真实产品团队的多智能体协作系统。当面对竞品分析、产品框架设计、产品框图绘制、流程图规划、产品文档撰写等复杂产品需求时，本 Skill 会激活一个由产品负责人、竞品研究员、产品架构师、交互设计师和产品文档工程师组成的虚拟团队。他们通过标准化的协作协议和明确的职责分工，共同完成从需求理解、竞品洞察、架构设计、可视化呈现到文档交付的全流程工作，确保产品分析与设计产出的专业性、结构性和可落地性。
|
||||
---
|
||||
|
||||
## 激活条件
|
||||
|
||||
满足以下**任意一项**时，激活本 Skill：
|
||||
|
||||
- 用户需要进行竞品分析、竞品对比、市场调研类产品研究工作
|
||||
- 用户需要设计产品框架、产品架构、功能模块或信息架构
|
||||
- 用户需要输出产品框图、流程图、泳道图、思维导图等可视化产品图表
|
||||
- 用户需要撰写 PRD、需求文档、产品说明书、用户故事、功能规格等产品文档
|
||||
- 任务同时涉及研究、设计和文档交付，单次对话无法覆盖全流程
|
||||
|
||||
**不激活的场景**：单一明确的问答、简单文案修改、单步信息查询等无需多角色协作的请求。
|
||||
|
||||
## 核心协作机制
|
||||
*严格遵循 ./references/ 目录下序号最大的文件*
|
||||
|
||||
## 项目目录结构
|
||||
|
||||
顶层存放路径为 `project/项目名称/`，支持多个项目并列：
|
||||
```
|
||||
project/
|
||||
├── 竞品分析-短视频MCN工具/
|
||||
│ └── 项目版本01/
|
||||
│ └── ...
|
||||
├── 产品设计-AI脚本平台/
|
||||
│ └── 项目版本01/
|
||||
│ └── ...
|
||||
```
|
||||
|
||||
单个项目内部结构：
|
||||
```
|
||||
项目名称/
|
||||
├── 项目版本01/
|
||||
│ ├── 00_项目章程.md — 产品负责人输出：研究目标、交付范围、成功标准、角色分工
|
||||
│ ├── 01_竞品洞察.md — 竞品研究员输出：竞品清单、对比维度、核心发现、差距分析
|
||||
│ ├── 02_产品架构.md — 产品架构师输出：功能模块划分、信息架构、核心流程设计
|
||||
│ ├── 03_可视化设计.md — 交互设计师输出：框图/流程图/泳道图设计说明与规范
|
||||
│ ├── 04_产品文档.md — 产品文档工程师输出：正式交付的产品文档（PRD/功能规格等）
|
||||
│ └── 05_项目产出/
|
||||
│ ├── 竞品分析报告/
|
||||
│ │ ├── 竞品对比表.md
|
||||
│ │ └── 竞品分析报告.html — 竞品研究员 + 产品负责人联合输出的可视化分析报告
|
||||
│ ├── 产品框图/
|
||||
│ │ ├── 信息架构图.html — 交互设计师输出，使用 HTML/SVG/Mermaid 渲染
|
||||
│ │ ├── 产品框架图.html
|
||||
│ │ └── 功能模块图.html
|
||||
│ ├── 流程图/
|
||||
│ │ ├── 核心业务流程.html — 使用 Mermaid 或 SVG 渲染的交互式流程图
|
||||
│ │ ├── 用户旅程图.html
|
||||
│ │ └── 泳道图.html
|
||||
│ └── 产品文档/
|
||||
│ ├── PRD.md — 产品需求文档（标准格式）
|
||||
│ ├── 功能规格说明.md
|
||||
│ └── {项目名称}_产品交付.html — 产品文档工程师生成，整合所有产出的交付确认页
|
||||
└── 经验汇总/
|
||||
├── 竞品研究方法论.md — 跨项目可复用的竞品分析框架与模板
|
||||
├── 产品架构模板.md — 跨项目可复用的架构设计模式与组件
|
||||
├── 图表设计规范.md — 框图/流程图的设计标准、颜色规范、组件库
|
||||
└── 文档模板库.md — PRD、功能规格、用户故事的标准模板
|
||||
```
|
||||
|
||||
## 基础原则
|
||||
|
||||
1. **阶段不可跳过**：五个阶段（启动 → 研究 → 设计 → 可视化 → 文档交付）是硬性约束，不因需求"简单"而省略任何阶段。
|
||||
2. **产物必须落文件**：每阶段的关键产物须写入对应文件后，方可进入下一阶段；不允许仅在对话中描述。
|
||||
3. **角色边界不可越权**：竞品研究员不做架构设计，交互设计师不主导竞品分析，文档工程师不裁决架构正确性；职责边界以 References 角色定义为准。
|
||||
4. **模糊先澄清，不假设推进**：目标、研究范围或交付标准不明确时，必须先向产品负责人或用户确认，不得带着假设继续执行。
|
||||
5. **修正上限 3 轮**：单个产物审核不通过超过 3 次，由产品负责人介入决策，禁止无限循环修改。
|
||||
6. **图表必须可渲染**：所有框图、流程图必须输出为可在浏览器直接预览的 HTML 文件（使用 Mermaid.js / SVG / D3.js），禁止仅输出文字描述。
|
||||
7. **竞品信息须注明来源**：竞品分析中引用的数据、功能描述须注明信息来源与获取时间，禁止无来源输出竞品结论。
|
||||
|
||||
## 角色
|
||||
|
||||
> 详细职责、边界与关键输出以 `References 角色定义与职责边界` 为准。
|
||||
|
||||
| 名称 | 定位 | 核心职责 | 边界约束 |
|
||||
|-------|------|---------|---------|
|
||||
| 产品负责人 | 项目统筹 + 决策者 | 明确研究目标、统筹全局、主持评审、管控交付质量、最终汇报 | 不做具体研究执行，不绘制图表，专注目标正确性和交付完整性 |
|
||||
| 竞品研究员 | 市场洞察 + 信息挖掘者 | 搜集竞品信息、建立对比框架、输出竞品洞察报告、识别市场机会 | 不做架构设计，不写产品文档，专注"竞品是什么、做什么、怎么做、差距在哪" |
|
||||
| 产品架构师 | 结构设计 + 逻辑建模者 | 设计产品功能模块、信息架构、核心业务流程、梳理数据与交互逻辑 | 不做竞品研究，不直接绘制图表，专注"产品应该是什么结构" |
|
||||
| 交互设计师 | 可视化呈现 + 图表工程师 | 将架构设计转化为可视化框图/流程图/泳道图，输出可渲染的 HTML 图表文件 | 不主导架构决策，不撰写文档，专注"把结构画清楚、让人一眼看懂" |
|
||||
| 产品文档工程师 | 文档交付 + 知识沉淀者 | 将研究成果、架构设计、图表整合为标准化产品文档，沉淀可复用模板 | 不参与设计决策，专注"把所有产出用规范语言写清楚、让文档能被执行" |
|
||||
@@ -0,0 +1,247 @@
|
||||
# 核心工作流
|
||||
|
||||
该 Skill 遵循"启动-研究-设计-可视化-文档交付"的线性推进流程，每个阶段由特定角色主导，其他角色协同支持。阶段间存在严格依赖关系，上一阶段产物未完成前不得进入下一阶段。
|
||||
|
||||
---
|
||||
|
||||
## 第一阶段：启动与规划（由产品负责人主导）
|
||||
|
||||
### 需求接收与范围界定
|
||||
- **[产品负责人]** 接收用户输入的初始需求（竞品分析/产品框架/流程图/产品文档等）。
|
||||
- **[产品负责人]** 与用户进行结构化沟通，明确以下要素：
|
||||
- 研究对象：是哪个产品/行业/功能域？
|
||||
- 交付形式：需要哪些产出（竞品报告/框图/流程图/PRD）？
|
||||
- 研究深度：概览级 / 专项深度分析 / 完整产品设计？
|
||||
- 参照标准：是否有对标产品或样例？
|
||||
- 时间约束和格式要求
|
||||
- **[产品负责人]** 输出 **项目章程（00_项目章程.md）**，内容包含：研究目标、交付范围清单、成功标准、角色分工、关键节点。
|
||||
|
||||
### 任务拆解与阶段规划
|
||||
- **[产品负责人]** 根据项目章程，将交付物拆解为阶段性任务，明确每个阶段的输入、负责角色和预期产出。
|
||||
- **[竞品研究员]** 评估竞品研究的可行性（数据获取难度、资料丰富度、分析维度合理性）。
|
||||
- **[产品架构师]** 评估架构设计的范围（功能深度、模块颗粒度）。
|
||||
- **[产品负责人]** 锁定最终任务清单，同步给全体角色。
|
||||
|
||||
---
|
||||
|
||||
## 第二阶段：竞品研究（由竞品研究员主导）
|
||||
|
||||
> 仅当项目包含竞品分析需求时执行本阶段；纯产品设计项目可跳过，直接进入第三阶段。
|
||||
|
||||
### 竞品清单确认
|
||||
- **[竞品研究员]** 根据研究目标，确定竞品清单（直接竞品 3-5 个 + 参考竞品 2-3 个）。
|
||||
- **[竞品研究员]** 与产品负责人确认竞品范围，避免遗漏或过度覆盖。
|
||||
|
||||
### 多维度竞品信息搜集
|
||||
- **[竞品研究员]** 使用 WebSearch / WebFetch 工具，系统搜集各竞品的：
|
||||
- 产品定位与目标用户
|
||||
- 核心功能模块与差异化特性
|
||||
- 商业模式与定价策略
|
||||
- 用户口碑与市场反馈（应用商店评分、用户评论）
|
||||
- 近期迭代动态（版本更新、功能上线）
|
||||
- 技术栈（如可获取）
|
||||
- **[竞品研究员]** 记录每条信息的来源 URL 和获取时间，确保可追溯。
|
||||
|
||||
### 竞品对比分析
|
||||
- **[竞品研究员]** 建立结构化对比维度框架（根据项目类型选择适配维度）：
|
||||
- 通用维度：产品定位 / 目标用户 / 核心功能 / 用户体验 / 商业模式 / 技术能力
|
||||
- 专项维度：根据项目特殊关注点定制
|
||||
- **[竞品研究员]** 输出 **竞品洞察（01_竞品洞察.md）**，包含：
|
||||
- 竞品全景地图（竞品清单 + 基本情况）
|
||||
- 多维对比矩阵表
|
||||
- 核心洞察（优劣势分析、市场空白、机会点）
|
||||
- 对我方产品的启示与建议
|
||||
|
||||
### 竞品报告可视化
|
||||
- **[竞品研究员]** 联合 **[交互设计师]** 将竞品对比数据生成可视化 HTML 报告（05_项目产出/竞品分析报告/竞品分析报告.html）。
|
||||
- **[产品负责人]** 审核竞品洞察，确认核心结论正确性，方可进入下一阶段。
|
||||
|
||||
---
|
||||
|
||||
## 第三阶段：产品架构设计（由产品架构师主导）
|
||||
|
||||
### 功能模块划分
|
||||
- **[产品架构师]** 基于竞品洞察（如有）和项目目标，梳理产品功能全景：
|
||||
- 识别核心功能域（一级模块）
|
||||
- 拆分功能子项（二级 / 三级模块）
|
||||
- 定义模块间的依赖关系和边界
|
||||
- **[产品架构师]** 明确每个模块的：功能描述 / 用户价值 / 数据输入输出 / 关键交互节点
|
||||
|
||||
### 信息架构设计
|
||||
- **[产品架构师]** 设计产品信息架构（IA）：
|
||||
- 导航结构（一级/二级/三级页面层级）
|
||||
- 核心内容实体与关系
|
||||
- 用户入口与核心路径
|
||||
- **[产品架构师]** 输出 **产品架构（02_产品架构.md）**，包含：
|
||||
- 产品功能模块清单（含模块描述）
|
||||
- 信息架构层级树
|
||||
- 核心业务流程文字描述
|
||||
- 数据流与交互逻辑说明
|
||||
|
||||
### 核心流程梳理
|
||||
- **[产品架构师]** 梳理 3-5 条核心用户流程（注册/登录、核心任务流、支付/转化等）：
|
||||
- 触发条件 → 步骤序列 → 分支逻辑 → 终态
|
||||
- 识别异常路径和降级方案
|
||||
- **[产品负责人]** 评审架构方案，确认功能范围和核心流程逻辑合理，方可进入下一阶段。
|
||||
|
||||
---
|
||||
|
||||
## 第四阶段：可视化图表制作（由交互设计师主导）
|
||||
|
||||
### 图表规划
|
||||
- **[交互设计师]** 根据 02_产品架构.md 和项目需求，规划需要输出的图表类型：
|
||||
- 产品框图（Product Framework Diagram）
|
||||
- 信息架构图（IA Diagram）
|
||||
- 核心业务流程图（Business Flow）
|
||||
- 用户旅程图（User Journey Map）
|
||||
- 泳道图（Swimlane Diagram）
|
||||
- **[交互设计师]** 与产品架构师确认图表边界：哪些内容在图表中展示，哪些在文档中描述。
|
||||
|
||||
### 图表设计与输出
|
||||
- **[交互设计师]** 输出 **可视化设计说明（03_可视化设计.md）**，记录每张图表的设计思路、颜色规范、组件说明。
|
||||
- **[交互设计师]** 使用以下技术栈生成可渲染的 HTML 图表文件：
|
||||
- **流程图 / 泳道图**：优先使用 Mermaid.js（`flowchart` / `sequenceDiagram` / `graph`）
|
||||
- **产品框图 / 信息架构图**：使用 HTML + SVG 自定义渲染，确保层级清晰
|
||||
- **复杂交互图表**：使用 D3.js 或 ECharts
|
||||
- 每张图表独立输出为 HTML 文件，存入 `05_项目产出/` 对应子目录。
|
||||
- **图表技术要求**：
|
||||
- 文件可在浏览器直接打开，无需服务器
|
||||
- 响应式布局，宽度自适应（最大宽度 1400px）
|
||||
- 支持节点 hover 高亮，关键路径颜色区分
|
||||
- 禁止使用截图或图片，必须是可缩放的矢量图表
|
||||
|
||||
### 图表审核
|
||||
- **[产品架构师]** 审核图表内容准确性（节点、关系、层级是否与架构文档一致）。
|
||||
- **[产品负责人]** 审核图表整体呈现质量（是否清晰易读、是否满足交付标准）。
|
||||
- 审核不通过：交互设计师根据反馈修改，上限 3 轮。
|
||||
|
||||
---
|
||||
|
||||
## 第五阶段：文档撰写与交付（由产品文档工程师主导）
|
||||
|
||||
### 文档结构规划
|
||||
- **[产品文档工程师]** 根据项目章程确认的交付文档类型，建立文档大纲：
|
||||
- PRD（产品需求文档）：按标准模板（概述/背景/目标/用户群/功能列表/非功能需求/验收标准）
|
||||
- 功能规格说明：按功能模块逐一描述（输入/输出/交互规则/边界条件/异常处理）
|
||||
- 用户故事：用 As a / I want to / So that 格式撰写
|
||||
- **[产品文档工程师]** 与产品架构师确认文档覆盖的功能范围与深度。
|
||||
|
||||
### 文档撰写
|
||||
- **[产品文档工程师]** 整合所有前序阶段产物（竞品洞察、产品架构、流程图说明），撰写正式产品文档：
|
||||
- 文档语言：清晰、无歧义、面向研发可执行
|
||||
- 功能描述：结合图表引用，禁止纯文字描述复杂逻辑（图文并茂）
|
||||
- 验收标准：每个功能模块须附可验证的验收条件
|
||||
- 输出 **产品文档（04_产品文档.md）** 及 `05_项目产出/产品文档/` 下的各文档文件。
|
||||
|
||||
### 交付确认页生成
|
||||
- **[产品文档工程师]** 将本项目所有产出整合为交付确认 HTML 页面（`{项目名称}_产品交付.html`），包含以下板块：
|
||||
- 项目概览（目标 / 范围 / 交付清单）
|
||||
- 竞品洞察摘要（如有）
|
||||
- 产品架构总览（嵌入或链接框图）
|
||||
- 核心流程图（嵌入主要流程图）
|
||||
- 文档索引（所有交付文档的链接与简介）
|
||||
- 待确认事项（需要用户/业务方确认的关键决策点）
|
||||
- HTML 页面技术规范见「交付确认页生成规范」章节。
|
||||
|
||||
### 文档评审与知识沉淀
|
||||
- **[产品负责人]** 组织最终评审，确认所有交付物完整、准确、可用。
|
||||
- **[产品文档工程师]** 将本项目可复用的内容沉淀到 `经验汇总/`：
|
||||
- 有效的竞品分析维度框架 → 竞品研究方法论.md
|
||||
- 可复用的架构模式 → 产品架构模板.md
|
||||
- 图表设计经验 → 图表设计规范.md
|
||||
- 优质文档结构 → 文档模板库.md
|
||||
- **沉淀原则**：仅沉淀经过本次项目实际验证、有效的方法和模板。
|
||||
|
||||
---
|
||||
|
||||
# 角色定义与职责边界
|
||||
|
||||
| 角色 | 定位 | 核心职责 | 关键输出 | 边界与规则 |
|
||||
| :--- | :--- | :--- | :--- | :--- |
|
||||
| **产品负责人** | **项目统筹 + 决策者** | 1. 与用户沟通，明确研究目标和交付范围<br>2. 统筹全局，协调各角色工作节奏<br>3. 主持阶段评审，把控交付质量<br>4. 管控风险，处理角色间分歧<br>5. 最终汇报与交付确认 | `项目章程`，`阶段评审结论`，`最终交付确认` | 不做具体研究执行，不直接绘制图表，不写一线文档。确保目标正确、进度受控、产出满足用户预期 |
|
||||
| **竞品研究员** | **市场洞察 + 信息挖掘者** | 1. 确定竞品清单和研究维度<br>2. 系统搜集竞品信息（使用搜索工具）<br>3. 建立结构化对比矩阵<br>4. 输出竞品洞察与机会判断<br>5. 为架构设计提供竞品参考输入 | `竞品洞察.md`，`竞品对比矩阵`，`竞品分析报告.html` | 不做架构设计，不写 PRD，不绘制产品框图。专注"竞品是什么、做什么、差距在哪"。所有结论必须有信息来源 |
|
||||
| **产品架构师** | **结构设计 + 逻辑建模者** | 1. 设计产品功能模块层级<br>2. 梳理信息架构（IA）<br>3. 定义核心业务流程与分支逻辑<br>4. 说明数据流与模块间依赖关系<br>5. 审核图表与文档中的架构内容准确性 | `产品架构.md`，`功能模块清单`，`核心流程文字描述` | 不做竞品研究，不直接绘制图表，不撰写 PRD 正文。专注"产品应该是什么结构"，为图表制作和文档撰写提供权威输入 |
|
||||
| **交互设计师** | **可视化呈现 + 图表工程师** | 1. 规划图表类型与呈现范围<br>2. 将架构文字描述转化为可视化图表<br>3. 使用 HTML/SVG/Mermaid 输出可渲染文件<br>4. 维护图表设计规范（颜色、字体、组件） | `可视化设计说明.md`，`*.html 图表文件`（框图/流程图/泳道图/IA图） | 不主导架构决策，不撰写产品文档正文。专注"把结构画清楚"。所有图表必须是可在浏览器渲染的 HTML 文件，禁止仅输出文字描述 |
|
||||
| **产品文档工程师** | **文档交付 + 知识沉淀者** | 1. 整合前序阶段产物，撰写结构化产品文档<br>2. 确保文档语言清晰、面向研发可执行<br>3. 生成项目交付确认 HTML 页面<br>4. 将可复用模板和方法论沉淀到知识库 | `PRD.md`，`功能规格说明.md`，`{项目名称}_产品交付.html`，`经验汇总/` 更新 | 不参与架构决策，不绘制图表。专注"把所有产出用规范语言写清楚，让文档能被执行，让知识能被复用" |
|
||||
|
||||
---
|
||||
|
||||
# 图表制作技术规范
|
||||
|
||||
## 技术选型原则
|
||||
|
||||
| 图表类型 | 优先技术 | 备选技术 | 禁止方式 |
|
||||
|:---|:---|:---|:---|
|
||||
| 流程图 | Mermaid.js `flowchart` | HTML + SVG | 纯文字描述 |
|
||||
| 泳道图 | Mermaid.js `sequenceDiagram` | HTML + CSS Grid | 截图/图片 |
|
||||
| 信息架构图 | HTML + SVG 树形图 | ECharts tree | Markdown 缩进 |
|
||||
| 产品框架图 | HTML + CSS Grid + SVG | D3.js | Word/PPT 截图 |
|
||||
| 用户旅程图 | HTML + CSS Timeline | ECharts | 仅文字表格 |
|
||||
|
||||
## 文件输出规范
|
||||
|
||||
- 每张图表独立为一个 `.html` 文件，可浏览器直接打开
|
||||
- 文件名：`{图表类型}_{简短描述}.html`（如 `流程图_用户注册核心路径.html`）
|
||||
- 页面最大宽度：1400px，内容居中
|
||||
- 配色方案：主色 `#4F6EF7`，辅助色 `#34C759`（通过），`#FF3B30`（异常），`#FF9500`（决策节点）
|
||||
- 所有文字使用系统中文字体栈：`"PingFang SC", "Microsoft YaHei", sans-serif`
|
||||
|
||||
## Mermaid 代码规范
|
||||
|
||||
```html
|
||||
<!-- 标准 Mermaid 引入方式 -->
|
||||
<script src="https://cdn.jsdelivr.net/npm/mermaid/dist/mermaid.min.js"></script>
|
||||
<script>mermaid.initialize({ startOnLoad: true, theme: 'base', themeVariables: { primaryColor: '#4F6EF7' } });</script>
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 交付确认页生成规范
|
||||
|
||||
> 本规范适用于产品文档工程师生成的项目交付确认页面（HTML）。
|
||||
|
||||
## 页面整体结构
|
||||
|
||||
- 单页长页面，所有板块从上到下纵向排列，不使用 Tab 切换
|
||||
- 顶部：项目标题栏（含项目名称、版本、生成日期） → 吸顶锚点导航栏（滚动时自动高亮当前板块）
|
||||
- 每个板块之间用分隔线（图标 + 标题 + 横线）视觉区分
|
||||
- 页面须生成在 `05_项目产出/` 目录下，文件名为 `{项目名称}_产品交付.html`
|
||||
|
||||
## 板块命名与内容定义（固定，不可自定义）
|
||||
|
||||
| 板块名称 | 内容 | 数据来源 |
|
||||
|:---|:---|:---|
|
||||
| 项目概览 | 目标摘要 + 交付清单 + 成功标准 | 00_项目章程.md |
|
||||
| 竞品洞察 | 竞品对比矩阵 + 核心结论 + 机会点 | 01_竞品洞察.md（如有） |
|
||||
| 产品架构 | 功能模块树 + 架构说明 | 02_产品架构.md |
|
||||
| 图表索引 | 所有图表文件的预览缩略图 + 打开链接 | 05_项目产出/ 各图表文件 |
|
||||
| 文档索引 | 所有交付文档的链接 + 一句话摘要 | 05_项目产出/产品文档/ |
|
||||
| 待确认事项 | 关键决策点清单（已决策/待确认状态） | 项目评审记录 |
|
||||
|
||||
## 技术约束
|
||||
|
||||
- **含 emoji 的 HTML 必须使用 Python 脚本生成**（`open(path, 'w', encoding='utf-8')`），禁止使用 Write 工具直接写入
|
||||
- 页面最大宽度：1600px，内容居中，两侧留边距
|
||||
- 响应式：数据卡片 4列 → 2列 → 1列（断点 768px / 480px）
|
||||
- 外部链接：`target="_blank"`；图表预览区支持点击全屏展开
|
||||
|
||||
---
|
||||
|
||||
# 沟通与协作协议
|
||||
|
||||
## 结构化消息传递
|
||||
- 所有跨角色的关键产物交接必须明确标注：`[来源角色] → [目标角色] ：{产物名称}`
|
||||
- 审核反馈使用结构化格式：`问题描述 | 严重程度（阻断/建议） | 修改建议`
|
||||
|
||||
## 基于上下文的协作
|
||||
- 所有角色共享项目目录文件系统作为协作空间，每阶段产物实时写入对应 Markdown 文件
|
||||
- 禁止仅在对话中传递关键产物，必须写入文件后方可视为"阶段完成"
|
||||
|
||||
## 失败重试与降级
|
||||
- 单个产物审核不通过时，由负责角色根据反馈修改，上限 3 轮
|
||||
- 超过 3 轮由产品负责人介入决策：接受现有版本并记录待优化点 / 重新界定需求范围 / 将问题升级给用户
|
||||
- 竞品信息无法获取时（页面 404、付费墙等），竞品研究员需在竞品洞察文档中注明"信息缺失"，不得编造数据
|
||||
|
||||
## 阶段推进确认
|
||||
- 每个阶段完成后，产品负责人向用户汇报阶段成果摘要，并询问是否继续推进下一阶段
|
||||
- 用户如需调整方向，产品负责人更新项目章程并同步给全体角色
|
||||
Reference in new issue
Block a user