BMAD-METHOD PRFAQ Stage 3 实战以魔鬼代言人角色打磨 Customer FAQ验证产品价值主张【免费下载链接】BMAD-METHODBreakthrough Method for Agile Ai Driven Development项目地址: https://gitcode.com/gh_mirrors/bm/BMAD-METHOD导读本文围绕 BMAD-METHOD 开源仓库中bmad-prfaq技能Working Backwards / PRFAQ 挑战的Stage 3: Customer FAQ展开。在 PRFAQ 流程里Stage 3 的价值是让 AI 化身为被承诺伤害过的怀疑型顾客从怀疑、信任、实用、边界场景与最不愿被问到的硬问题五个角度逼问产品价值主张。读完本文你将掌握 6–10 个高难度客户问题的生成框架、四步陪练式作答校准方法、非商业概念的校准技巧以及如何通过 headless 模式、frontmatter 状态更新与 coaching notes 沉淀将 Stage 3 无缝衔接进完整的 PRFAQ 工作流。一、Stage 3 在 PRFAQ 流程中的位置BMAD-METHOD 的bmad-prfaq技能见 SKILL.md将 Amazon 的 Working Backwards 方法落地为一条五阶段流水线阶段名称目的位置1Ignition拿到原始概念强制建立客户优先思维SKILL.md内联2The Press Release逐句打磨新闻稿配合高难度陪练skills/bmad-prfaq/references/press-release.md3Customer FAQ魔鬼代言人式客户提问验证价值主张skills/bmad-prfaq/references/customer-faq.md4Internal FAQ持怀疑态度的干系人提问skills/bmad-prfaq/references/internal-faq.md5The Verdict综合评估、强度判定、产出最终成果skills/bmad-prfaq/references/verdict.mdStage 3 的核心目标见 customer-faq.md只有一句话通过提出真实用户会问的最尖锐问题——并打磨出经得起推敲的答案——来验证价值主张。它承接 Stage 2 完成的新闻稿我们已经把产品说得很好听了在进入 Stage 4 内部可行性拷问之前先从外部客户的视角把概念从外向内检验一遍。模块清单 module-manifest.toml 与 bmad-manifest.json 显示bmm模块的working-backwards能力菜单代号WB归属于plan阶段上游是brainstorming与perform-research下游是create-prd。这意味着 Stage 3 的产出不是终点而是后续 PRD 生成的输入之一——FAQ 中暴露的缺口与取舍会一路传导到最终的产品需求文档。二、角色设定你不是友善的早期用户而是魔鬼代言人Stage 3 要求 AI 切换身份你现在就是客户。但不是友好的尝鲜者——而是一个忙到没时间、且曾被各种承诺伤害过的怀疑论者。你已经读完了那份新闻稿现在你有问题要问。这份角色卡片的要点是直面怀疑直接挑战拒绝含糊其辞的思考给出出路当用户卡住时提供具体替代方案而非沉默——原文用一句话概括tough love, not tough silence严厉的爱而非严厉的沉默校准概念类型开跑前检查{concept_type}让所有问题框架与之匹配商业产品、内部工具、开源项目、社区/非营利组织四类。这意味着 AI 在这一阶段扮演的不是帮你圆梦的助手而是一个有目的地找茬的客户。新闻稿中的每一句营销话术在这里都会被追问到露出真相为止。三、问题生成6–10 个覆盖五个角度的高难度问题Stage 3 要求生成6–10 个客户 FAQ 问题必须覆盖以下五个角度且每个角度都给了范例句式1. 怀疑Skepticism这跟 [现有解决方案] 有什么不同我为什么要从现在的工具切换过来2. 信任Trust我的数据会怎样如果这东西关停了怎么办背后是谁在做3. 实用顾虑Practical concerns多少钱上手要多久能兼容 [我已经在用的东西] 吗4. 边界场景Edge cases如果我要 [少见但真实的需求] 怎么办它适用于 [相邻用例] 吗5. 团队最怕被问到的问题The hard question theyre afraid of每个产品都有一个团队祈祷没人问的问题。把它找出来然后问出来。这是五个角度中最关键的一条——它强迫团队直面自己一直回避的真相。出题底线不许出软题原文明确划出红线How do I sign up?怎么注册不是 FAQ而是 CTA行动号召。真正的客户 FAQ 是横亘在感兴趣与决定采用之间的那些异议objections。如果问题列表里全是软题说明这一阶段没有真正生效。四、按概念类型校准问题框架{concept_type}是在 Stage 1 Ignition 阶段早期识别并保存的商业产品 / 内部工具 / 开源项目 / 社区非营利。到 Stage 3 出题时必须据此校准维度商业产品非商业概念内部工具、开源、社区成本多少钱采用成本effort to adopt多高竞品切换为什么要从竞品切换为什么要改变现有工作流信任/公司存续数据安全公司倒闭怎么办维护与可持续性maintenance and sustainability如何保证对开源项目问unit economics单位经济模型是文不对题的对内部工具问获客同样荒谬。校准的目的是让每一个问题都真正刺痛目标受众。五、陪练式作答四步打磨法生成问题之后AI 要与用户一起把答案打磨出来而不是直接交付一份漂亮的问答一次性呈现全部问题——让用户看到客户关切的全貌而不是被逐个问题牵着走共同作答用户起草或 AI 起草用户反馈。每一条答案都要过三道检查诚实吗如果答案是我们还没做到就直接说并解释路线图或替代方案具体吗我们有企业级安全不算答案。什么认证什么加密什么 SLA客户会信吗FAQ 答案里的营销腔会直接摧毁可信度答案暴露真实缺口时直接点名并逼用户做决定这是发布阻断项launch blocker、快速跟进项fast-follow还是被接受的取舍accepted trade-off允许用户补充自己的问题——往往他们比任何人都更清楚哪些问题最吓人。这套方法的精髓在于答案不是写出来的是被审出来的。每一条都要经过诚实性、具体性、可信度三层过滤含糊的答案在第二道检查就会被当场打回。六、Headless 模式无交互自动起草在--headless/-H模式下AI 直接从现有上下文生成问题与尽力而为的答案不进行交互式陪练。但有一条硬约束见 SKILL.md 的 Pre-workflow Setup对低置信度的答案必须明确标记flag交由人类复核。Headless 模式的输入 schema 要求customer具体人物画像、problem具体问题、stakes为何重要、solution概念四项必填若缺失或过于模糊则返回错误并给出具体改进指引。运行期间会并行扇出两个子代理详见 artifact-analyzer.md 与 web-researcher.md分别扫描规划产物与项目知识库、检索竞争与市场情报最后按模板 prfaq-template.md 生成输出文档。七、文档更新状态机与 frontmatter每次进入 Stage 3 完成作答后需要把 Customer FAQ 章节追加到输出文档{planning_artifacts}/prfaq-{project_name}.md并同步更新 frontmatterstatus: customer-faqstage: 3updated时间戳从 prfaq-template.md 可以看到完整的文档骨架frontmatter 区title/status/created/updated/stage/inputs、新闻稿正文、## Customer FAQ章节按最硬的问题排第一排序的 Q/A 对、## Internal FAQ章节与## The Verdict章节。而 SKILL.md 的 Resume detection 逻辑表明工作流重启时会读取该文档前 20 行的 frontmatter 中的stage字段来决定从哪个阶段续跑——因此 frontmatter 的维护是流程可恢复性的关键绝非形式主义。八、Coaching Notes Capture对抗上下文压缩的保险在离开 Stage 3 之前AI 必须在输出文档中追加一个!-- coaching-notes-stage-3 --注释块记录客户问题暴露出的概念缺口gaps revealed已做的取舍决定launch blocker vs fast-follow vs accepted浮现的竞争情报competitive intelligence surfaced任何范围或需求信号scope or requirements signals。从 Stage 5 的实现见 verdict.md可以理解它的真正用途这些注释块会在上下文压缩中幸存成为最终prfaq-{project_name}-distillate.md面向下游 LLM 的 token 高效上下文的核心素材来源。换句话说Stage 3 的陪练过程中那些没有写进 FAQ 正文的洞察——被否定的框架、暴露的缺口、浮现的竞品信息——全部通过 coaching notes 沉淀下来供 Stage 5 的蒸馏环节使用。九、阶段完成标准与流转Stage 3 的完成标准是当每个问题都有了诚实、具体的答案且用户已经直面其概念所面对的最强客户异议时本阶段完成。不允许有任何软题存活No softballs survived。完成后路由到 references/internal-faq.mdStage 4: Internal FAQ。Stage 4 的角色从外部客户切换为内部怀疑干系人小组——工程负责人、财务、法务、运营、见过上百个 pitch 的 CEO。它的核心追问是客户 FAQ 回答的是我该不该用内部 FAQ 回答的是我们到底能不能做成——以及该不该做覆盖可行性、商业可行性、资源现实、风险与战略契合五个角度详见 internal-faq.md。两阶段的承接关系非常清晰Stage 3 在外面验值不值得买Stage 4 在里面验做不做得到最后统一汇入 Stage 5 的 The Verdict 判定。十、从源码看 Stage 3 的定制化接口bmad-prfaq技能的行为并非写死而是可通过 customize.toml 按 BMad 结构化合并规则定制标量覆盖、数组追加、带code/id的表格数组按主键替换activation_steps_prepend/activation_steps_append在标准激活流程配置加载、问候之前/之后插入的自定义步骤persistent_facts整个工作流期间常驻的上下文事实支持file:{project-root}/...前缀引用文件或 glob加载其内容作为事实适用于团队标准、合规约束、风格护栏等静态上下文on_complete工作流到达终态Stage 5并交付 PRFAQ 与 distillate 后执行的自定义收尾指令。激活时技能会通过uv run {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --project-root {project-root} --key workflow解析定制脚本失败时则按 base → team → user 三层的customize.toml、_bmad/custom/{skill-name}.toml、_bmad/custom/{skill-name}.user.toml顺序手动合并随后用 resolve_config.py 读取modules.bmm.planning_artifacts与modules.bmm.project_knowledge确定输出位置与上下文扫描范围。这意味着团队可以在不改动技能本体的情况下为 Stage 3 注入自己的持久事实例如所有 FAQ 答案必须注明合规性影响或挂载自定义的激活前检查步骤。十一、实战要点小结把 Stage 3 跑好本质上是守住五条纪律角色要入戏你是被伤害过的怀疑型客户不是粉丝tough love, not tough silence。数量与角度要达标6–10 个问题覆盖怀疑 / 信任 / 实用 / 边界 / 最怕被问五个角度最硬的问题排第一。软题清零怎么注册是 CTA 不是 FAQ异议才是 FAQ 的原料。答案三层过滤诚实承认还没做到并给出路线图、具体认证、加密、SLA 而非形容词、可信杜绝营销腔。沉淀闭环追加 Customer FAQ 章节、更新 frontmatterstatus: customer-faq/stage: 3、写入coaching-notes-stage-3注释块然后路由到 internal-faq.md让 Stage 3 的发现成为整个 PRFAQ 流水线可持续消费的证据链。当你确认没有任何软题存活、每个答案都诚实且具体时Stage 3 才算真正完成——这也是概念从听起来不错走向经得起追问的分水岭。【免费下载链接】BMAD-METHODBreakthrough Method for Agile Ai Driven Development项目地址: https://gitcode.com/gh_mirrors/bm/BMAD-METHOD创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 BMAD-METHOD PRFAQ Stage 3 实战：以魔鬼代言人角色打磨 Customer FAQ，验证产品价值主张
BMAD-METHOD PRFAQ Stage 3 实战以魔鬼代言人角色打磨 Customer FAQ验证产品价值主张【免费下载链接】BMAD-METHODBreakthrough Method for Agile Ai Driven Development项目地址: https://gitcode.com/gh_mirrors/bm/BMAD-METHOD导读本文围绕 BMAD-METHOD 开源仓库中bmad-prfaq技能Working Backwards / PRFAQ 挑战的Stage 3: Customer FAQ展开。在 PRFAQ 流程里Stage 3 的价值是让 AI 化身为被承诺伤害过的怀疑型顾客从怀疑、信任、实用、边界场景与最不愿被问到的硬问题五个角度逼问产品价值主张。读完本文你将掌握 6–10 个高难度客户问题的生成框架、四步陪练式作答校准方法、非商业概念的校准技巧以及如何通过 headless 模式、frontmatter 状态更新与 coaching notes 沉淀将 Stage 3 无缝衔接进完整的 PRFAQ 工作流。一、Stage 3 在 PRFAQ 流程中的位置BMAD-METHOD 的bmad-prfaq技能见 SKILL.md将 Amazon 的 Working Backwards 方法落地为一条五阶段流水线阶段名称目的位置1Ignition拿到原始概念强制建立客户优先思维SKILL.md内联2The Press Release逐句打磨新闻稿配合高难度陪练skills/bmad-prfaq/references/press-release.md3Customer FAQ魔鬼代言人式客户提问验证价值主张skills/bmad-prfaq/references/customer-faq.md4Internal FAQ持怀疑态度的干系人提问skills/bmad-prfaq/references/internal-faq.md5The Verdict综合评估、强度判定、产出最终成果skills/bmad-prfaq/references/verdict.mdStage 3 的核心目标见 customer-faq.md只有一句话通过提出真实用户会问的最尖锐问题——并打磨出经得起推敲的答案——来验证价值主张。它承接 Stage 2 完成的新闻稿我们已经把产品说得很好听了在进入 Stage 4 内部可行性拷问之前先从外部客户的视角把概念从外向内检验一遍。模块清单 module-manifest.toml 与 bmad-manifest.json 显示bmm模块的working-backwards能力菜单代号WB归属于plan阶段上游是brainstorming与perform-research下游是create-prd。这意味着 Stage 3 的产出不是终点而是后续 PRD 生成的输入之一——FAQ 中暴露的缺口与取舍会一路传导到最终的产品需求文档。二、角色设定你不是友善的早期用户而是魔鬼代言人Stage 3 要求 AI 切换身份你现在就是客户。但不是友好的尝鲜者——而是一个忙到没时间、且曾被各种承诺伤害过的怀疑论者。你已经读完了那份新闻稿现在你有问题要问。这份角色卡片的要点是直面怀疑直接挑战拒绝含糊其辞的思考给出出路当用户卡住时提供具体替代方案而非沉默——原文用一句话概括tough love, not tough silence严厉的爱而非严厉的沉默校准概念类型开跑前检查{concept_type}让所有问题框架与之匹配商业产品、内部工具、开源项目、社区/非营利组织四类。这意味着 AI 在这一阶段扮演的不是帮你圆梦的助手而是一个有目的地找茬的客户。新闻稿中的每一句营销话术在这里都会被追问到露出真相为止。三、问题生成6–10 个覆盖五个角度的高难度问题Stage 3 要求生成6–10 个客户 FAQ 问题必须覆盖以下五个角度且每个角度都给了范例句式1. 怀疑Skepticism这跟 [现有解决方案] 有什么不同我为什么要从现在的工具切换过来2. 信任Trust我的数据会怎样如果这东西关停了怎么办背后是谁在做3. 实用顾虑Practical concerns多少钱上手要多久能兼容 [我已经在用的东西] 吗4. 边界场景Edge cases如果我要 [少见但真实的需求] 怎么办它适用于 [相邻用例] 吗5. 团队最怕被问到的问题The hard question theyre afraid of每个产品都有一个团队祈祷没人问的问题。把它找出来然后问出来。这是五个角度中最关键的一条——它强迫团队直面自己一直回避的真相。出题底线不许出软题原文明确划出红线How do I sign up?怎么注册不是 FAQ而是 CTA行动号召。真正的客户 FAQ 是横亘在感兴趣与决定采用之间的那些异议objections。如果问题列表里全是软题说明这一阶段没有真正生效。四、按概念类型校准问题框架{concept_type}是在 Stage 1 Ignition 阶段早期识别并保存的商业产品 / 内部工具 / 开源项目 / 社区非营利。到 Stage 3 出题时必须据此校准维度商业产品非商业概念内部工具、开源、社区成本多少钱采用成本effort to adopt多高竞品切换为什么要从竞品切换为什么要改变现有工作流信任/公司存续数据安全公司倒闭怎么办维护与可持续性maintenance and sustainability如何保证对开源项目问unit economics单位经济模型是文不对题的对内部工具问获客同样荒谬。校准的目的是让每一个问题都真正刺痛目标受众。五、陪练式作答四步打磨法生成问题之后AI 要与用户一起把答案打磨出来而不是直接交付一份漂亮的问答一次性呈现全部问题——让用户看到客户关切的全貌而不是被逐个问题牵着走共同作答用户起草或 AI 起草用户反馈。每一条答案都要过三道检查诚实吗如果答案是我们还没做到就直接说并解释路线图或替代方案具体吗我们有企业级安全不算答案。什么认证什么加密什么 SLA客户会信吗FAQ 答案里的营销腔会直接摧毁可信度答案暴露真实缺口时直接点名并逼用户做决定这是发布阻断项launch blocker、快速跟进项fast-follow还是被接受的取舍accepted trade-off允许用户补充自己的问题——往往他们比任何人都更清楚哪些问题最吓人。这套方法的精髓在于答案不是写出来的是被审出来的。每一条都要经过诚实性、具体性、可信度三层过滤含糊的答案在第二道检查就会被当场打回。六、Headless 模式无交互自动起草在--headless/-H模式下AI 直接从现有上下文生成问题与尽力而为的答案不进行交互式陪练。但有一条硬约束见 SKILL.md 的 Pre-workflow Setup对低置信度的答案必须明确标记flag交由人类复核。Headless 模式的输入 schema 要求customer具体人物画像、problem具体问题、stakes为何重要、solution概念四项必填若缺失或过于模糊则返回错误并给出具体改进指引。运行期间会并行扇出两个子代理详见 artifact-analyzer.md 与 web-researcher.md分别扫描规划产物与项目知识库、检索竞争与市场情报最后按模板 prfaq-template.md 生成输出文档。七、文档更新状态机与 frontmatter每次进入 Stage 3 完成作答后需要把 Customer FAQ 章节追加到输出文档{planning_artifacts}/prfaq-{project_name}.md并同步更新 frontmatterstatus: customer-faqstage: 3updated时间戳从 prfaq-template.md 可以看到完整的文档骨架frontmatter 区title/status/created/updated/stage/inputs、新闻稿正文、## Customer FAQ章节按最硬的问题排第一排序的 Q/A 对、## Internal FAQ章节与## The Verdict章节。而 SKILL.md 的 Resume detection 逻辑表明工作流重启时会读取该文档前 20 行的 frontmatter 中的stage字段来决定从哪个阶段续跑——因此 frontmatter 的维护是流程可恢复性的关键绝非形式主义。八、Coaching Notes Capture对抗上下文压缩的保险在离开 Stage 3 之前AI 必须在输出文档中追加一个!-- coaching-notes-stage-3 --注释块记录客户问题暴露出的概念缺口gaps revealed已做的取舍决定launch blocker vs fast-follow vs accepted浮现的竞争情报competitive intelligence surfaced任何范围或需求信号scope or requirements signals。从 Stage 5 的实现见 verdict.md可以理解它的真正用途这些注释块会在上下文压缩中幸存成为最终prfaq-{project_name}-distillate.md面向下游 LLM 的 token 高效上下文的核心素材来源。换句话说Stage 3 的陪练过程中那些没有写进 FAQ 正文的洞察——被否定的框架、暴露的缺口、浮现的竞品信息——全部通过 coaching notes 沉淀下来供 Stage 5 的蒸馏环节使用。九、阶段完成标准与流转Stage 3 的完成标准是当每个问题都有了诚实、具体的答案且用户已经直面其概念所面对的最强客户异议时本阶段完成。不允许有任何软题存活No softballs survived。完成后路由到 references/internal-faq.mdStage 4: Internal FAQ。Stage 4 的角色从外部客户切换为内部怀疑干系人小组——工程负责人、财务、法务、运营、见过上百个 pitch 的 CEO。它的核心追问是客户 FAQ 回答的是我该不该用内部 FAQ 回答的是我们到底能不能做成——以及该不该做覆盖可行性、商业可行性、资源现实、风险与战略契合五个角度详见 internal-faq.md。两阶段的承接关系非常清晰Stage 3 在外面验值不值得买Stage 4 在里面验做不做得到最后统一汇入 Stage 5 的 The Verdict 判定。十、从源码看 Stage 3 的定制化接口bmad-prfaq技能的行为并非写死而是可通过 customize.toml 按 BMad 结构化合并规则定制标量覆盖、数组追加、带code/id的表格数组按主键替换activation_steps_prepend/activation_steps_append在标准激活流程配置加载、问候之前/之后插入的自定义步骤persistent_facts整个工作流期间常驻的上下文事实支持file:{project-root}/...前缀引用文件或 glob加载其内容作为事实适用于团队标准、合规约束、风格护栏等静态上下文on_complete工作流到达终态Stage 5并交付 PRFAQ 与 distillate 后执行的自定义收尾指令。激活时技能会通过uv run {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --project-root {project-root} --key workflow解析定制脚本失败时则按 base → team → user 三层的customize.toml、_bmad/custom/{skill-name}.toml、_bmad/custom/{skill-name}.user.toml顺序手动合并随后用 resolve_config.py 读取modules.bmm.planning_artifacts与modules.bmm.project_knowledge确定输出位置与上下文扫描范围。这意味着团队可以在不改动技能本体的情况下为 Stage 3 注入自己的持久事实例如所有 FAQ 答案必须注明合规性影响或挂载自定义的激活前检查步骤。十一、实战要点小结把 Stage 3 跑好本质上是守住五条纪律角色要入戏你是被伤害过的怀疑型客户不是粉丝tough love, not tough silence。数量与角度要达标6–10 个问题覆盖怀疑 / 信任 / 实用 / 边界 / 最怕被问五个角度最硬的问题排第一。软题清零怎么注册是 CTA 不是 FAQ异议才是 FAQ 的原料。答案三层过滤诚实承认还没做到并给出路线图、具体认证、加密、SLA 而非形容词、可信杜绝营销腔。沉淀闭环追加 Customer FAQ 章节、更新 frontmatterstatus: customer-faq/stage: 3、写入coaching-notes-stage-3注释块然后路由到 internal-faq.md让 Stage 3 的发现成为整个 PRFAQ 流水线可持续消费的证据链。当你确认没有任何软题存活、每个答案都诚实且具体时Stage 3 才算真正完成——这也是概念从听起来不错走向经得起追问的分水岭。【免费下载链接】BMAD-METHODBreakthrough Method for Agile Ai Driven Development项目地址: https://gitcode.com/gh_mirrors/bm/BMAD-METHOD创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考