write-brd

name write-brd description 输入一个产品 idea（一句话或详细描述均可），自动生成图文并茂、结构完整的 BRD（商业需求文档），以 Markdown 格式保存到当前项目 markdown/ 目录，同时输出配套 SVG 图表文件。触发条件：用户提到"写 BRD"、"帮我写需求文档"、"生成 BRD"、"写商业需求文档"、"我有个产品想法"、"帮我把这个 idea 写成文档"、"PRD/BRD 模板"、"产品立项文档"。即使用户只给出一句简短的产品描述如"我想做一个 XX 产品"，也应立即使用本 skill 生成 BRD。本 skill 面向产品经理、创业者、产品负责人，输出可直接用于团队评审和立项决策的专业文档。 Write BRD Skill 将一个产品 idea 转化为完整、可直接评审的 BRD（Business Requirements Document）。 工作流总览 用户输入 Idea ↓ Step 1: 信息补全与假设推演 ↓ Step 2: 搜索市场背景与竞品（web search） ↓ Step 3: 生成配套 SVG 图表（独立文件） ↓ Step 4: 生成完整 BRD Markdown 文件 ↓ 输出到 markdown/ 目录 Step 1：信息补全与假设推演 拿到用户的 idea 后， 不要立刻问问题 ，而是先做推演： 推断目标用户 ：谁会用这个产品？什么场景下使用？ 推断核心问题 ：他们现在遇到了什么痛点？ 推断商业模式 ：这个产品怎么盈利？或者它服务于什么更大的商业目标？ 推断成功指标 ：上线后看什么数据来判断成功？ 识别需要澄清的关键信息 （如果有的话，在生成文档前一次性问完，不超过 3 个问题） 如果用户提供的信息足够（或者可以合理推断），直接进入 Step 2，不要打断流程问问题。 推断优先于询问 ，在 BRD 中标注"[待确认]"的字段，告知用户哪些是推断。 Step 2：搜索市场背景（使用 web_search） 搜索以下信息，用于充实 BRD 背景章节： 该领域的市场规模数据（TAM/SAM） 主要竞品和竞品的核心功能 行业近期趋势（政策、技术、用户行为变化） 参考类似产品的成功/失败案例 搜索关键词格式： [产品领域] market size , [产品类型] competitors , [用户痛点] trends 2024 Step 3：生成 SVG 图表 必须生成以下至少 2 个 SVG 图表 ，保存到 markdown/ 目录： 图表 A：产品功能架构图（必选） 展示核心功能模块及其关系 文件名： [product-name]-architecture.svg 风格：简洁，用色块区分模块，有箭头表示关联 图表 B：用户旅程图 / 核心流程图（必选） 展示用户从发现问题到完成目标的完整路径 文件名： [product-name]-user-journey.svg 风格：横向流程，有状态标注 图表 C（可选，根据产品类型选择）： 竞品对比矩阵（有竞品时生成） 商业模式画布关键要素（B端产品） 数据流图（技术型产品） SVG 技术规范 ： viewBox="0 0 820 [适当高度]" font-family="'PingFang SC', 'Helvetica Neue', Arial, sans-serif" 使用渐变色增强视觉层次 添加 filter shadow 增强立体感 配色参考： 主色调：#667eea（科技蓝紫） 成功色：#43a047（绿） 警告色：#e65100（橙） 危险色：#c62828（红） 背景：#f7f8fc 或 white Step 4：BRD Markdown 文件结构 文件命名： [product-name-en]-brd.md （英文小写，连字符分隔） 完整 BRD 模板 # [产品名称] BRD > [一句话摘要：这个产品为谁解决了什么问题，通过什么方式] **文档状态** ：草稿 / 评审中 / 已批准 **版本** ：v1.0 **作者** ：[PM 姓名] **最后更新** ：[日期] **阅读时长** ：约 X 分钟 --- ## 一、执行摘要（Executive Summary） [3-5句话的高管版摘要，包含：问题规模、解决方案、预期商业价值] --- ## 二、问题定义 ### 2.1 背景与现状 [市场背景，数据支撑，不超过200字] ### 2.2 用户痛点（JTBD 框架） 当 [目标用户] 在 [使用场景] 时， 他们需要 [完成某个任务/达到某个目标]， 但目前面临 [具体障碍]， 导致 [业务/用户体验影响]。 ### 2.3 目标用户 **主要用户群体** ：[描述] **用户画像** ： - 人口属性：[年龄/职业/地域] - 使用场景：[什么时候、在哪里、为什么] - 当前行为：[他们现在怎么解决这个问题] - 痛点优先级：[最痛的3个点] ### 2.4 市场机会 | 指标 | 数值 | 来源 | |------|------|------| | TAM（总市场规模） | | | | SAM（可服务市场） | | | | SOM（可获取份额） | | | --- ## 三、解决方案 ### 3.1 产品定位 [一句话定位：我们是[产品类型]，帮助[目标用户]，[核心价值主张]，不像[竞品]，我们[差异化]。] ### 3.2 功能架构 ![ 功能架构图 ]( [product-name]-architecture.svg ) ### 3.3 核心功能（MoSCoW 优先级） #### Must Have（MVP 必须包含） | 功能 | 用户故事 | 验收标准 | 优先级 | |------|---------|---------|--------| | [功能1] | As a [用户], I want [行为], so that [目的] | Given [场景] When [动作] Then [结果] | P0 | #### Should Have（重要但可简化） [同上格式] #### Could Have（有余力再做） [列表形式即可] #### Won't Have（本期明确不做） [列表，说明原因] ### 3.4 用户旅程 ![ 用户旅程图 ]( [product-name]-user-journey.svg ) ### 3.5 非功能需求 | 维度 | 要求 | 验证方式 | |------|------|---------| | 性能 | [具体指标，如页面加载<2s] | 压测 | | 安全 | [如符合 SOC2 / GDPR] | 安全审计 | | 可用性 | [如支持 99.9% uptime] | 监控告警 | | 扩展性 | [如支持 X 并发用户] | 架构评审 | --- ## 四、竞品分析 [竞品对比矩阵或文字分析，说明差异化优势] --- ## 五、成功指标 ### 5.1 北极星指标（North Star Metric） [唯一最重要的指标，及其计算方式] ### 5.2 关键指标体系 | 指标 | 基线 | 目标值 | 观测周期 | |------|------|--------|---------| | [核心业务指标] | [当前值] | [目标值] | [周/月] | | [用户行为指标] | | | | | [技术质量指标] | | | | ### 5.3 实验设计 - A/B 测试方案：[描述] - 灰度策略：[5% → 20% → 100%] - 回滚条件：[出现什么情况触发回滚] --- ## 六、执行计划 ### 6.1 范围边界 **In Scope（本期包含）** ： - [功能列表] **Out of Scope（本期不做）** ： - [明确排除的功能，及原因] ### 6.2 里程碑 | 阶段 | 内容 | 时间节点 | 负责人 | |------|------|---------|--------| | Discovery 完成 | 用研报告、竞品分析 | [日期] | PM | | 设计评审 | 高保真原型通过 | [日期] | Design | | 技术评审 | 架构方案确认 | [日期] | Tech | | MVP 上线 | 核心功能可用 | [日期] | 全团队 | | 数据验证 | 关键指标达标 | [日期] | PM | ### 6.3 资源需求 | 角色 | 工作量（人天） | 备注 | |------|-------------|------| | 产品经理 | | | | 设计师 | | | | 前端工程师 | | | | 后端工程师 | | | | 测试工程师 | | | --- ## 七、风险评估 | 风险 | 可能性 | 影响 | 应对方案 | |------|--------|------|---------| | [技术风险] | 中 | 高 | [具体措施] | | [市场风险] | 低 | 高 | [具体措施] | | [资源风险] | 中 | 中 | [具体措施] | | [合规风险] | 低 | 极高 | [具体措施] | --- ## 八、干系人与审批 ### 8.1 RACI 矩阵 | 事项 | PM | 工程 | 设计 | 运营 | 法务 | 高层 | |------|----|----|------|------|------|------| | 需求确认 | R | C | C | I | I | A | | 技术方案 | C | R | I | | | I | | 上线决策 | R | C | C | C | C | A | *R=负责执行 A=最终决策 C=需咨询 I=需知会* ### 8.2 审批记录 | 干系人 | 角色 | 意见 | 签字日期 | |--------|------|------|---------| | | | | | --- ## 九、附录 ### 9.1 术语表 [项目专有名词解释] ### 9.2 参考文档 - [用研报告链接] - [竞品分析报告] - [技术可行性评估] - [相关数据分析] ### 9.3 修订历史 | 版本 | 日期 | 修改内容 | 修改人 | |------|------|---------|--------| | v1.0 | [日期] | 初始版本 | | --- *本文档由 write-brd skill 生成 · 请在评审完成后删除此行* 写作质量标准 问题定义质量检查 是否用 JTBD 格式写出用户痛点？ 是否有具体数字支撑问题规模（用研数据 or 市场数据）？ 是否明确区分了"用户问题"和"解决方案"？ 功能规格质量检查 所有 Must Have 功能是否有验收标准（Given/When/Then）？ 是否明确写了 Out of Scope？ MoSCoW 优先级是否有明确分层（不全是 Must）？ 图表质量检查 架构图是否展示了核心模块及其关系？ 用户旅程图是否有明确的起点、终点、关键决策节点？ SVG 是否单独保存为文件并在 Markdown 中正确引用？ 指标质量检查 是否定义了唯一的北极星指标？ 所有指标是否可量化（有数值目标和时间节点）？ 是否设计了验证方式（A/B测试 / 对照组）？ 文档整体质量 执行摘要能否让不懂背景的人在1分钟内理解核心价值？ 是否有清晰的决策流程和审批链条？ 风险评估是否覆盖了技术、市场、资源、合规四个维度？ 输出文件清单 生成完成后，markdown/ 目录应包含： markdown/ ├── [product-name]-brd.md ← 主文档 ├── [product-name]-architecture.svg ← 功能架构图 ├── [product-name]-user-journey.svg ← 用户旅程图 └── [product-name]-*.svg ← 其他可选图表 特殊场景处理 场景 A：用户只给了一句话 idea 直接推演，用 [待确认] 标注假设字段，生成完整文档后告知用户哪些需要补充。 场景 B：用户给了详细描述 提取关键信息后按模板生成，无需额外搜索即可完成大部分内容。 场景 C：用户要求简版 BRD（1-2页） 只生成核心章节：问题定义 + Must Have 功能 + 成功指标 + 里程碑，省略其余章节。 场景 D：B 端产品 BRD 在竞品分析部分增加"购买决策链分析"，成功指标加入客户成功指标（NPS / Churn Rate）。 场景 E：内部工具 BRD 简化市场分析部分，增加"效率提升量化"章节，指标侧重内部 ROI。 触发示例 以下均应触发本 Skill： "帮我写一份 BRD，产品是一个帮助设计师管理灵感的 App" "我想做一个企业内部的知识库系统，帮我出一份需求文档" "有个 idea：给餐厅做一个 AI 点餐助手，帮我写成 BRD" "写个 BRD 模板" "产品立项需要一份商业需求文档，我们要做 XX" "帮我把这个产品想法整理成文档，方便跟团队对齐"