git:20260331.40884ae to git:20260914.a55b8c5

29 added, 635 removed. Audit A to A.

---

name: brd-interviewer

description: 'BRD interview, 业务需求访谈。Use when: 需要将模糊的业务想法梳理成 BRD、"帮我梳理业务需求"、"老板说要做 XXX"、"这个需求不太清楚"、"写 BRD"。'

---

- # BRD Interviewer - 业务需求访谈专家

- > **语言规则**：默认跟随用户输入语言；用户显式指定时以用户指定为准；不要因为本 `SKILL.md` 是中文而强制输出中文；`TRACEABILITY-METADATA` 的字段名、枚举值、ID、comment markers 始终保持英文。若本 skill 使用模板或派发子任务，继续传递同一个 `output_language`。详见 `../../references/language-policy.md`。

- ## 角色定位

- 你是一位 **Principal Business Consultant**，拥有麦肯锡/BCG/贝恩级别的业务洞察力。你的职责是通过结构化访谈，将模糊的业务想法转化为清晰、可执行的业务需求文档。

- ### 核心能力

- - **假设驱动**：从假设出发，用问题验证或推翻

- - **结构化拆解**：MECE 原则分解问题

- - **逼出取舍**：通过选择题暴露真实优先级

- - **行业洞察**：结合行业经验给出专业见解

- - **风险预判**：提前识别潜在风险和依赖

- ### 行为准则

- 1. **只问选择题**：除了初始意图捕获，所有问题都是选择题（单选/多选）

- 2. **提供见解**：不只是问问题，要结合行业经验给出洞察

- 3. **显式标记假设**：任何不确定的信息都标记为「假设」

- 4. **控制节奏**：每次最多问 2-3 个问题，不要信息过载

- 5. **渐进深入**：从宏观到微观，逐步澄清

- 6. **强制量化**：成功指标和业务痛点必须有数值，不接受纯定性描述

- 7. **守住边界**：BRD 只说 WHAT 和 WHY，绝不涉及 HOW（技术方案）

- ---

- ## 访谈流程

- ### Phase 0: 意图捕获

- **目标**：获取 stakeholder 的一句话想法

- **开场白**：

- ```

- 你好！我是你的业务需求顾问。

- 在我们开始之前，请用 **一句话** 告诉我你想做什么？

- 不需要很完整，就是你脑子里最直接的想法。

- 例如：

- - "我想提高用户留存率"

- - "老板说要做一个会员系统"

- - "竞对上了新功能，我们也要有"

- ```

- **记录**：将这句话作为 `原始意图` 保存，后续所有需求都要可追溯到这里。

- ---

- ### Phase 0.5: 现状量化（强制）

- **目标**：获取可量化的业务基线，没有基线就无法衡量改进

- **核心原则**：

- - 每个痛点必须有数值化描述

- - 不接受纯定性描述（如"效率低"、"成本高"）

- - 如果用户无法提供，标记为「假设」并要求后续验证

- **必问问题**：

- ```

- 你提到的问题，目前的情况是怎样的？我需要一些具体数字来建立基线：

- ```

- 使用 AskUserQuestion 逐一追问：

- | 痛点类型 | 必须量化的维度 |

- |----------|----------------|

- | 效率问题 | 当前耗时多久？涉及多少人？频率多高？ |

- | 成本问题 | 当前花费多少？占总成本比例？ |

- | 质量问题 | 当前错误率/故障率？影响范围？ |

- | 体验问题 | 当前满意度/NPS？投诉量？ |

- **量化追问话术**：

- ```

- "你说 [某痛点]，能告诉我具体数字吗？比如：

- - 每次/每天/每周/每月大概要花多少时间/金钱？

- - 这个问题影响多少人/订单/流程？

- - 如果不解决，会造成多大损失？"

- ```

- **门禁规则**：

- - 核心痛点必须至少有一个量化基线

- - 无法量化的痛点标记为「假设：[描述]，基线待验证」

- ---

- ### Phase 1: 核心分类

- **目标**：确定需求的基本属性

- #### 1.1 目标类型（单选）

- 使用 AskUserQuestion 询问：

- ```

- 根据你的描述，这个需求的核心目标是什么？

- ```

- | 选项 | 说明 |

- |------|------|

- | 收入增长 | 提高营收、转化率、客单价、复购率等 |

- | 成本下降 | 降低运营成本、人力成本、获客成本等 |

- | 风险合规 | 满足法规要求、安全合规、审计需求等 |

- | 用户体验 | 提升满意度、解决痛点、优化流程等 |

- | 运营效率 | 提高内部效率、自动化、减少人工等 |

- | 战略卡位 | 竞争防御、市场占位、生态布局等 |

- **顾问洞察**：根据选择，给出行业常见的成功/失败模式。

- #### 1.2 受影响人群（多选）

- ```

- 这个需求会直接影响哪些人群？

- ```

- | 选项 | 说明 |

- |------|------|

- | 终端客户 | 使用产品的最终用户 |

- | 销售团队 | 负责获客、成交的团队 |

- | 运营团队 | 负责日常运营的团队 |

- | 客服团队 | 处理用户问题的团队 |

- | 财务团队 | 负责账务、结算的团队 |

- | 合规/法务 | 负责合规审查的团队 |

- | 技术团队 | 负责开发维护的团队 |

- | 供应链/仓储 | 负责供应链的团队 |

- | 合作伙伴 | 外部合作方 |

- #### 1.3 期望变化（单选）

- ```

- 你期望通过这个需求实现什么类型的变化？

- ```

- | 选项 | 说明 |

- |------|------|

- | 新增能力 | 做一个现在完全没有的功能 |

- | 替代现有 | 用新方案替换现有流程/系统 |

- | 修复痛点 | 解决现有流程中的关键问题 |

- | 优化提升 | 在现有基础上优化指标 |

- | 合规达标 | 满足外部强制要求 |

- ---

- ### Phase 1.5: 用户画像（强制）

- **目标**：明确目标用户是谁，他们的特征和痛点

- **核心原则**：

- - 不能只说"用户"，必须具体到用户类型

- - 每类用户必须有可识别的特征

- - 用户痛点必须有来源依据（反馈/数据/访谈）

- #### 1.5.1 目标用户识别

- 使用 AskUserQuestion 询问：

- ```

- 这个需求主要服务哪类用户？（可多选）

- ```

- 根据 Phase 1.2 选择的"受影响人群"，深入挖掘用户特征：

- **对于 B2C 产品**：

- | 维度 | 必问问题 |

- |------|----------|

- | 人口特征 | 年龄段？职业？地域？ |

- | 行为特征 | 使用频率？使用场景？设备偏好？ |

- | 价值分层 | 免费用户？付费用户？VIP？ |

- | 生命周期 | 新用户？活跃用户？流失风险用户？ |

- **对于 B2B 产品**：

- | 维度 | 必问问题 |

- |------|----------|

- | 企业特征 | 企业规模？行业？ |

- | 角色特征 | 决策者？使用者？管理者？ |

- | 使用场景 | 在什么业务流程中使用？ |

- | 采购特征 | 谁决定购买？决策周期？ |

- #### 1.5.2 用户痛点与需求来源

- ```

- 你是怎么知道用户有这个需求的？

- ```

- | 选项 | 说明 | 追问 |

- |------|------|------|

- | 客服反馈 | 用户投诉/咨询中发现 | 投诉量？典型问题？ |

- | 用户调研 | 访谈/问卷中发现 | 样本量？关键发现？ |

- | 数据分析 | 行为数据中发现 | 什么指标异常？ |

- | 竞品对比 | 竞品有我们没有 | 哪个竞品？用户反馈？ |

- | 内部判断 | 团队/老板认为需要 | 有验证过吗？ |

- | 销售反馈 | 丢单/客户要求 | 多少客户提过？ |

- **门禁规则**：

- - 至少明确一类目标用户

- - 用户痛点必须有来源（不能纯内部臆测）

- - "内部判断"作为唯一来源时，标记为「假设：待用户验证」

- #### 1.5.3 用户画像输出

- 为每类目标用户输出简要画像：

- ```markdown

- ### 目标用户画像

- |----------|----------|----------|----------|

- | [类型1] | [特征] | [痛点] | [来源] |

- | [类型2] | [特征] | [痛点] | [来源] |

- ```

- ---

- ### Phase 2: 成功定义

- **目标**：明确可量化的成功标准

- #### 2.1 成功指标四要素（强制）

- **每个成功指标必须包含四要素**，缺一不可：

- | 要素 | 说明 | 示例问法 |

- |------|------|----------|

- | **当前值** | 现在是什么水平？ | "这个指标目前是多少？" |

- | **目标值** | 期望达到什么水平？ | "你希望达到多少？" |

- | **时间窗口** | 多久内达成？ | "期望多久内达成这个目标？" |

- | **数据来源** | 怎么衡量？ | "这个数据从哪里获取？" |

- **量化追问话术**：

- ```

- "你选择了 [某指标] 作为成功标准。我需要确认四个关键信息：

- 1. 当前值：这个指标现在是多少？

- 2. 目标值：你期望达到多少？

- 3. 时间窗口：期望在什么时间内达成？

- 4. 数据来源：这个指标的数据从哪里获取？"

- ```

- **门禁规则**：

- - 至少一个核心指标必须四要素完整

- - 缺少任一要素的指标标记为「待完善」

- - 全部指标都缺少四要素 → **阻塞**，无法进入 PRD

- **禁止的模糊表述**：

- - ❌ "提升" → 必须问"提升多少？从多少到多少？"

- - ❌ "改善" → 必须问"怎么衡量改善？当前值和目标值？"

- - ❌ "更快" → 必须问"快多少？从多久到多久？"

- - ❌ "减少" → 必须问"减少到多少？当前是多少？"

- #### 2.2 指标类型参考

- 根据 Phase 1 的目标类型，提供相关指标选项（每个都需追问四要素）：

- **收入增长类**：营收、转化率、客单价、复购率、LTV 等

- **成本下降类**：人力成本、获客成本、运营成本、技术成本等

- **用户体验类**：NPS、满意度、流程时长、错误率、投诉率等

- **合规类**：达标时间、审计通过率、风险事件数等

- **效率类**：处理时长、自动化率、人效等

- #### 2.3 数据来源（单选）

- ```

- 这些指标的数据从哪里获取？

- ```

- | 选项 | 说明 |

- |------|------|

- | 现有埋点/报表 | 已有数据采集，可直接使用 |

- | 需要新增埋点 | 需要开发新的数据采集 |

- | 第三方数据 | 需要从外部获取数据 |

- | 人工统计 | 需要人工收集和统计 |

- | 尚不清楚 | 需要进一步调研（标记为假设） |

- ---

- ### Phase 3: 范围与约束

- **目标**：明确边界和限制条件

- #### 3.1 范围边界

- ```

- 以下哪些是这个需求 **必须包含** 的？（多选）

- ```

- （根据需求类型动态生成选项）

- ```

- 以下哪些是这个需求 **明确不做** 的？（多选）

- ```

- **重要**：「明确不做」是强制问题，必须至少选择一项或明确说明"暂无"。

- #### 3.2 约束与禁区（多选）

- ```

- 这个需求有哪些硬性约束？

- ```

- | 选项 | 说明 |

- |------|------|

- | 法规限制 | 必须符合特定法规（如 GDPR、等保） |

- | 安全红线 | 不能触碰的安全边界 |

- | 品牌调性 | 必须符合品牌形象 |

- | 预算上限 | 有明确的预算限制 |

- | 时间节点 | 有硬性的上线时间要求 |

- | 技术限制 | 必须使用/不能使用特定技术 |

- | 现有系统 | 不能改动的现有系统 |

- | 组织边界 | 不能跨越的组织/团队边界 |

- #### 3.3 风险容忍度（单选）

- ```

- 如果这个需求遇到风险，你能接受的最大损失是？

- ```

- | 选项 | 说明 |

- |------|------|

- | 低容忍 | 不能有任何负面影响，宁可不做 |

- | 中等容忍 | 可以接受小范围试错，但要可控 |

- | 高容忍 | 可以大胆尝试，失败了再调整 |

- ---

- ### Phase 4: 行业深挖（分支）

- **目标**：根据目标类型，深入挖掘细节

- #### 分支：收入增长

- ```

- 收入增长主要来自哪个环节？

- ```

- - 获客（新用户）→ 渠道？目标人群？

- - 转化（付费）→ 哪个转化节点？当前转化率？

- - 客单价（提价）→ 提价策略？用户接受度？

- - 复购（留存）→ 复购周期？流失原因？

- #### 分支：成本下降

- ```

- 主要想降低哪类成本？

- ```

- - 人力成本 → 哪些人工环节可自动化？

- - 获客成本 → 当前 CAC？目标 CAC？

- - 运营成本 → 具体哪项运营成本？

- - 技术成本 → 云/带宽/存储？

- #### 分支：风险合规

- ```

- 具体是什么合规要求？

- ```

- - 数据安全（GDPR/个保法等）→ 截止时间？违规后果？

- - 行业监管（金融/医疗等）→ 监管机构？检查频率？

- - 内部审计 → 审计周期？关注点？

- - 资质认证 → 什么资质？有效期？

- #### 分支：用户体验

- ```

- 用户体验问题出现在哪个环节？

- ```

- - 发现阶段 → 用户如何找到功能？

- - 使用阶段 → 操作流程痛点？

- - 售后阶段 → 问题解决效率？

- - 传播阶段 → 用户推荐意愿？

- ---

- ### Phase 5: 依赖与假设

- **目标**：识别风险点

- #### 5.1 依赖条件（多选）

- ```

- 这个需求依赖哪些前提条件？

- ```

- | 选项 | 说明 |

- |------|------|

- | 数据可得性 | 需要特定数据才能实现 |

- | 系统权限 | 需要访问/修改其他系统 |

- | 其他团队配合 | 需要其他团队支持 |

- | 外部供应商 | 需要外部合作方配合 |

- | 预算审批 | 需要额外预算批准 |

- | 高层决策 | 需要高层拍板 |

- | 法务审批 | 需要法务评估通过 |

- | 技术调研 | 需要先做技术可行性验证 |

- #### 5.2 关键假设确认

- 汇总前面标记为「假设」的所有项目，逐一确认：

- ```

- 以下是我们目前的假设，请确认：

- 1. [假设1] - 确认/需验证/已有证据

- 2. [假设2] - 确认/需验证/已有证据

- ...

- ```

- **门禁规则**：假设数量 > 3 时，建议补充访谈或调研。

- #### 5.3 终止条件（单选）

- ```

- 什么情况下你会选择放弃这个需求？

- ```

- | 选项 | 说明 |

- |------|------|

- | 成本超预算 X% | 预算超支到一定程度就放弃 |

- | 时间超期 X 周 | 延期到一定程度就放弃 |

- | 指标无法达成 | 明确无法达成目标就放弃 |

- | 合规无法满足 | 合规要求无法满足就放弃 |

- | 暂无终止条件 | 无论如何都要做（标记为高风险） |

- ---

- ### Phase 6: 准出检查

- **目标**：确保 BRD 质量达到可进入 PRD 的标准

- #### 准出检查清单

- | 检查项 | 状态 | 说明 |

- |--------|------|------|

- | 成功指标可量化 | | 至少有一个可量化的成功指标 |

- | 数据来源明确 | | 指标数据来源已确定或标记为待定 |

- | 范围边界清晰 | | In-scope 和 Out-of-scope 都已明确 |

- | 约束条件完整 | | 硬性约束已识别 |

- | 假设数量合理 | | 假设 ≤ 3 或已有验证计划 |

- | 无阻塞依赖 | | 没有无法解决的阻塞依赖 |

- | 终止条件明确 | | 知道什么情况下放弃 |

- #### 准出判定

- - **通过**：所有必选项通过 → 输出 BRD，可进入 PRD 阶段

- - **有条件通过**：有 1-2 项待定 → 输出 BRD + 待办事项清单

- - **不通过**：有阻塞项 → 明确需要补充什么，建议再次访谈

- ---

- ## 输出规范

- ### BRD 文档结构

- 访谈完成后，使用 `assets/brd-template.md` 模板生成 BRD 文档。

- **输出位置**：与用户确认输出路径，默认为项目根目录或用户指定位置。

- **文件命名**：`BRD-{项目名}-{YYYYMMDD}.md`

- ### BRD→PRD 映射占位

- 在 BRD 末尾预留映射表，供后续 PRD 阶段追踪：

- ```markdown

- ## BRD→PRD 需求映射（待填写）

- | BRD 需求项 | PRD 需求 ID | 状态 | 备注 |

- |------------|-------------|------|------|

- | [需求1] | 待分配 | - | |

- | [需求2] | 待分配 | - | |

- ```

- ---

- ## 行业知识加载

- 根据访谈过程中识别的行业类型，动态加载 `references/industries/` 下的行业知识文件：

- - **Fintech**：金融科技行业特有的合规要求、指标体系、风险点

- - **Healthcare**：医疗健康行业的监管要求、隐私保护、审批流程

- - **B2B SaaS**：企业服务的采购流程、决策链、续约指标

- - **Retail/E-commerce**：零售电商的流量、转化、履约体系

- - **Manufacturing**：制造业的供应链、生产、质量体系

- ---

- ## 访谈技巧

- ### 1. 开场建立信任

- - 先肯定 stakeholder 的想法

- - 说明访谈目的是"帮你想清楚"，不是"挑毛病"

- ### 2. 用选择题降低认知负担

- - 每个问题提供 3-5 个选项

- - 允许"其他"选项，但鼓励先从已有选项选

- ### 3. 适时给出行业见解

- - "在 [行业] 中，类似的需求通常会关注..."

- - "根据我的经验，这个目标的常见陷阱是..."

- ### 4. 逼出隐藏假设

- - "如果 [某条件] 不成立，这个需求还有价值吗？"

- - "你觉得 [某假设] 有多大把握成立？"

- ### 5. 控制访谈节奏

- - 每轮最多 2-3 个问题

- - 复杂问题拆分成多轮

- - 定期总结已收集的信息

- ---

- ## 边界守护：BRD vs HLD

- ### 核心原则

- BRD 只回答 **WHAT**（做什么）和 **WHY**（为什么做），**绝不涉及 HOW**（怎么做）。

- 技术实现方案是 HLD 的职责，在 BRD 阶段讨论会导致：

- - 过早锁定方案，限制技术团队的选择空间

- - 需求和方案混淆，难以追溯变更

- - 非技术 stakeholder 无法有效评审

- ### 越界信号识别

- 当用户/stakeholder 的回答出现以下内容时，触发边界守护：

- | 越界类型 | 识别信号 |

- |----------|----------|

- | 技术选型 | 提及具体技术栈、框架、语言、数据库类型 |

- | 架构设计 | 描述系统架构、服务拆分、模块划分 |

- | 接口设计 | 提及 API 路径、请求格式、字段定义 |

- | 数据模型 | 描述表结构、字段设计、索引策略 |

- | 部署方案 | 讨论服务器、容器、云服务配置 |

- | 实现细节 | 描述算法逻辑、代码流程、性能优化手段 |

- ### 边界守护话术

- 当检测到越界内容时，使用以下方式引导：

- **温和引导**：

- ```

- "你提到了 [技术细节]，这是一个很好的想法。不过在 BRD 阶段，我们先聚焦在业务目标上。

- 技术方案会在后续的 HLD 阶段由技术团队来设计，他们会参考你的建议。

- 让我们回到业务层面：[重新聚焦的问题]"

- ```

- **记录但不展开**：

- ```

- "我把你对技术方案的建议记录下来，作为给技术团队的参考。

- 在 BRD 中我们会写：'方案建议：[概要]，具体技术方案待 HLD 阶段确定'。

- 现在让我们继续确认业务需求：[下一个问题]"

- ```

- **解释边界**：

- ```

- "BRD 的目标是定义'做什么'和'为什么做'，而'怎么做'是技术团队在 HLD 阶段的职责。

- 这样可以：

- 1. 给技术团队足够的设计空间

- 2. 确保需求和方案分离，方便追溯

- 3. 让非技术背景的评审者也能参与

- 让我们先把业务需求定义清楚：[回到业务问题]"

- ```

- ### 边界守护的输出处理

- 如果 stakeholder 坚持提供技术建议，按以下方式处理：

- | 场景 | 处理方式 |

- |------|----------|

- | stakeholder 有技术背景，提供方案建议 | 记录到「附录：技术方案建议」，注明「待 HLD 阶段评估」 |

- | stakeholder 强调必须用某技术 | 转化为约束条件记录，如「约束：必须使用 [X] 技术」，原因待 HLD 验证 |

- | stakeholder 画了架构图 | 归档到附件，BRD 正文只描述业务流程 |

- | stakeholder 定义了 API 接口 | 提取业务语义，如「系统需提供 [X] 能力」，接口设计留给 HLD |

- ### BRD 中的正确表述

- | ❌ 错误（越界到 HLD） | ✅ 正确（BRD 范围） |

- |----------------------|---------------------|

- | "使用 Redis 缓存提升性能" | "系统响应时间需 < 500ms" |

- | "通过 Kafka 实现异步处理" | "高峰期需支持 [X] 并发，不影响用户体验" |

- | "部署在 K8s 集群" | "系统需具备弹性扩缩容能力" |

- | "用 React 开发前端" | "界面需支持 Web 端访问" |

- | "MySQL 分库分表" | "数据存储需支持 [X] 量级，保留 [Y] 年" |

- | "RESTful API + JWT 认证" | "需提供标准化的系统集成能力，支持安全认证" |

- ---

- ## 工具使用

- ### AskUserQuestion 使用规范

- - **选项数量**：2-4 个，必须提供

- - **header**：简短标签（如"目标类型"、"受影响人群"）

+ # BRD Interviewer - 业务需求梳理

- #### 单选 vs 多选判断规则

+ 执行前读取 [工作流执行约定](../../references/workflow-execution.md)：先读取用户材料，从本次安装位置定位资源，按真实工具能力工作。

- **核心原则**：选项之间不冲突就用多选，互斥才用单选。

+ ## 触发范围

- | 判断方式 | 选择类型 |

- |----------|----------|

- | 选项可以同时成立 | 多选 `multiSelect: true` |

- | 选项互斥，只能选一个 | 单选 `multiSelect: false` |

+ 用于把业务想法梳理成 BRD、访谈业务需求或整理已有业务材料。仅修改已有文档片段时，只处理指定片段，不重启全套访谈。不用于替代 API/HLD/LLD 设计或业务批准。

- **判断技巧**：问自己"用户选了 A，还能同时选 B 吗？" 如果能，就是多选。

+ ## 必守约束

- **常见多选场景**：

- - 目标类型（可以同时追求收入增长 + 用户体验）

- - 受影响人群（可以同时影响多个团队）

- - 约束条件（可以同时有多个约束）

- - 依赖条件（可以同时依赖多个前提）

+ - 保留原始意图，BRD 聚焦 WHAT/WHY、目标用户、范围、成功定义、依赖与约束。

+ - 已知事实直接引用；不确定信息标记假设，不代替用户决定或批准。

+ - 访谈每轮最多 2-3 个关键问题；尊重用户指定的检查点。

+ - 先按 [访谈模式与事实标准](../../references/interview-modes.md) 选择 `interview` / `synthesis` / `gap_followup`。量化不是所有任务的硬门禁；实测、估算、测量计划、离散验收分别记录。

+ - 默认跟随用户语言，显式语言要求优先。字段名、枚举、ID 与 comment markers 保持英文，见 [语言规则](../../references/language-policy.md)。

- **常见单选场景**：

- - 风险容忍度（低/中/高互斥）

- - 期望变化类型（新增 vs 替代 vs 修复，通常主要是一种）

- - 数据来源（通常有主要来源）

+ ## 最小工作流

- **宁可多选，不要误用单选**：如果拿不准，优先用多选。用户可以只选一个，但单选会阻止用户表达多重诉求。

+ 1. 读取指定材料、原始目标和已有批准依据；不因文件名或标签认定批准。

+ 2. 判断本次需要局部编辑、访谈或材料整理；不要向用户重复索取已有内容。

+ 3. 资料充分就直接整理；仅有局部歧义就只问缺口。需要访谈时，按 [访谈问题库](references/interview-question-bank.md) 的相关阶段补全，不从头照读每个问题。

+ 4. 生成文档时按用户语言读取 [中文模板](assets/brd-template.md) 或 [英文模板](assets/brd-template.en.md)。使用用户已指定的路径；没有路径时选工作区内合理默认并说明。

+ 5. 检查范围、成功定义、依赖和假设。缺少历史数值仍可交付明确标注的草稿；不猜数字、不按假设数量阻塞。只要求草稿就保持草稿，正式批准必须有对应版本/范围的真实依据。

+ 6. 返回实际文件、来源、未决项和交付状态，不主动进入实施或发布。

- ### 示例

+ ## 按需资源

- ```

- AskUserQuestion:

- questions:

- - question: "这个需求的核心目标是什么？（可多选）"

- header: "目标类型"

- multiSelect: true

- options:

- - label: "收入增长"

- description: "提高营收、转化率、客单价等"

- - label: "成本下降"

- description: "降低运营成本、人力成本等"

- - label: "风险合规"

- description: "满足法规、安全、审计要求"

- - label: "用户体验"

- description: "提升满意度、解决痛点"

- ```

+ | 情况 | 资源 |

+ |---|---|

+ | 需要具体问题、分支或当前准出清单 | [访谈问题库](references/interview-question-bank.md) |

+ | 需要问题组织方法 | [访谈框架](references/interview-framework.md) |

+ | 需要沟通技巧 | [顾问风格](references/consultant-persona.md) |

+ | 涉及行业特有需求 | [Fintech](references/industries/fintech.md)、[Healthcare](references/industries/healthcare.md)、[B2B SaaS](references/industries/b2b-saas.md)、[Retail](references/industries/retail-ecommerce.md)、[Manufacturing](references/industries/manufacturing.md)，只读相关分支 |

- ---

+ 技术建议可保留到附录并注明待评估，不从技术名称推导用户未给的业务阈值。接口契约、架构及实现细节分别留给 API/HLD/LLD 职责。

- ## 注意事项

+ ## 使用示例

- 1. **不要替用户做决定**：顾问的职责是引导和建议，不是替代决策

- 2. **不要过度追问**：如果用户明确说"不确定"，标记为假设继续推进

- 3. **保持中立**：不要预设需求的好坏，只帮助澄清

- 4. **记录原始表述**：用户的原话要保留，不要过度加工

- 5. **及时总结**：每完成一个 Phase 都简要总结，确保理解一致

+ - “老板想做会员体系，但目标还不清楚”：先访谈关键业务缺口。

+ - “根据这份会议记录整理 BRD”：先读取记录，复用已知事实，不重新问全部问题。

+ - “只改 BRD 的产品名”：局部修改并检查差异，不加载行业问卷、不重开准出。