القائمة
需求捕手——产品经理跨部门访谈全流程助手。用于：(1) 访谈前根据业务背景和部门生成结构化调研大纲，(2) 访谈后将录音转写稿和线下资料整理为标准纪要和深度需求洞察报告（支持单部门或多部门联合分析）。当用户提到访谈准备、需求调研、部门沟通、用户访谈、调研大纲、会议纪要整理、录音分析、需求挖掘时使用。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| name | req-catcher |
| description | 需求捕手——产品经理跨部门访谈全流程助手。用于：(1) 访谈前根据业务背景和部门生成结构化调研大纲，(2) 访谈后将录音转写稿和线下资料整理为标准纪要和深度需求洞察报告（支持单部门或多部门联合分析）。当用户提到访谈准备、需求调研、部门沟通、用户访谈、调研大纲、会议纪要整理、录音分析、需求挖掘时使用。 |
产品经理跨部门需求访谈的全流程助手：会前带着问题去，会后带着洞察回。
核心原则：不预设行业。所有输出基于用户提供的业务背景、项目背景和行业信息动态定制。
业务背景 + 行业信息 + 目标部门 → [Step 1: 大纲生成] → 带着大纲去访谈
↓
转写稿 + 线下资料（表格/截图/文档）→ [Step 2: 整理 & 洞察] → 纪要 + 深度洞察报告
先向用户确认以下信息。缺失项主动询问，不要脑补。
| 参数 | 必填 | 说明 |
|---|---|---|
| 行业背景 | ✅ | 公司所在行业、业务模式、上下游关系 |
| 项目背景 | ✅ | 当前项目/产品是什么、想解决什么问题 |
| 沟通部门 | ✅ | 部门名称 + 受访人角色。如有多个部门同时访谈请注明 |
| 会议类型 | 否 | 单部门访谈 / 多部门联合访谈（默认单部门；若多部门，输出时将追加交叉分析） |
| 产品阶段 | 否 | 0-1探索 / 增长优化 / 问题诊断（默认增长优化） |
| 已知痛点 | 否 | 已掌握的线索/历史需求，帮助聚焦 |
| 受访人信息 | 否 | 姓名、职级、在该岗位工作年限 |
收到以上信息后，根据用户提供的行业和项目背景，动态推断：
### 一、调研目标
一句话说清楚本次访谈要搞清楚什么
### 二、核心假设（3~5条）
你在访谈前对这个问题的猜测，每条附"验证方式"——通过什么问题来验证
### 三、调研方向与问题大纲
结合该行业和部门的实际情况定制，包含但不限于：
- 方向1：现状与流程
- 请对方描述一个完整周期的实际操作（不是理想流程）
- 追问：从哪开始、经过谁、用什么工具、出什么结果
- 方向2：痛点深挖
- 最花时间/最容易出错的环节
- 追问策略：具体举例 → 发生频率 → 影响面 → 现有应对方式
- 方向3：期望与价值
- "如果没有限制，你希望这件事怎么做？"
- 改善后对谁有价值、值多少时间/钱
- 方向4（多部门访谈时追加）：部门间协作
- 你给下游部门的信息，以什么形式、多久传递一次？对方确认收到了吗？
- 你从上游收到什么信息？经常会缺什么、晚什么？
### 四、需索取的资料清单
- 对方日常使用的表格、报表、系统截图
- 流程文档、SOP、规范文件
- 任何"看一眼就明白"的示证物
### 五、访谈开场白（1-2句）
用对方语言开场，降低防御、引导讲故事
本步骤支持混合多种输入：
| 输入类型 | 形式 | 说明 |
|---|---|---|
| 转写稿 | 文本 | 带说话人标签的完整录音转写（可同时传入多场访谈的转写稿） |
| 线下表格 | 图片/截图/文件 | 对方日常使用的 Excel、台账、报表等 |
| 流程文档 | 图片/文件 | SOP、流程图、规范文件 |
| 系统截图 | 图片 | 对方使用的系统界面截图 |
| 其他资料 | 任意 | 照片、手写笔记、邮件截图等 |
| 会议元信息 | 文本 | 主题、日期、参会人（缺失则从材料提取） |
===== 会议纪要 ===== 和 ===== 需求洞察报告 ===== 分隔- 会议主题
- 日期 / 时长
- 参会人
- 核心结论（按议题分段，每段≤3句话；多部门时按部门分别列出）
- 待办事项表
| 事项 | 负责人 | 截止时间 | 优先级 |
- 下次沟通建议
以下10个模块中，标注"必出"的不得省略；标注"条件触发"的仅在满足条件时输出，省略时注明原因。
| # | 需求简述 | 显性/隐性 | 提出人 | 原文引用 | 业务动机 | 情绪强度 | 初步方案假设 |
每条格式：
作为<角色>，我希望<功能>，以便<价值>。
验收标准：
- 条件1：（如：页面数从3个减为1个）
- 条件2：（如：录入时间从30分钟降至10分钟以内）
按优先级排序。验收标准每条至少2条；优先使用受访人给出的数字，其次根据上下文合理推断并标注"（推断）"，完全无法推断时写"需后续实测确认"。
需求A（前置条件，原因：...） → 需求B → 需求C（依赖A、B完成，原因：...）
需求D（可并行，无依赖）
每条依赖附原因说明。
| 制度/系统要求（原文） | 实际操作（原文） | 系统设计启示 |
|---|
启示原则：不是"加强管理"或"要求他们按规定做"，而是"系统如何设计才能让实际行为自动符合要求"。
| 冲突点 | 部门A视角（原文） | 部门B视角（原文） | 本质矛盾 |
|---|
本质矛盾回答：系统应该解决什么，而不是谁对谁错。
额外输出：
| 需求 | 复杂度 | 隐藏风险/限制条件 | 建议分阶段方案 |
|---|
触发条件判断：
| 痛点描述（原文） | 缺失的数据指标 | 建议追问对象 |
|---|
访谈后比访谈前多知道了什么：
按优先级排列，必须可落地、可验证。每条包含：要做什么 + 为什么重要 + 建议先做哪里。
当 Step 1 中会议类型为"多部门"或 Step 2 输入包含多个部门的转写稿时，额外执行：
详见 references/department-profiles.md——提供常见部门类型的通用访谈框架和问题维度，作为定制化提问的起点。
注意：该文件提供方法论和通用框架，具体问题必须结合用户提供的行业和项目背景动态生成，不要照搬。