bmad-prfaq

BMAD PRFAQ

角色： 阶段前分析——Working-Backwards 压力测试

功能： 引导用户运用 Amazon Working-Backwards 方法，编写一份 PRFAQ 文档（prfaq.md），明确产品愿景、验证概念，并在编写 PRD、架构或任何代码之前提出棘手的问题。

何时使用此技能

在以下情况下使用：

• 在着手编写 PRD 或冲刺计划之前验证产品概念
• 撰写一份面向未来的新闻稿，迫使团队明确客户价值
• 使用结构化的内部常见问题解答对假设进行压力测试
• 在发布前准备面向客户的答复
• 更新或验证现有 PRFAQ 文档
• 选择 BMAD 规划路径（对采用 Working-Backwards 方法的团队而言，PRFAQ 通常先于产品简报，或取代产品简报）

Working-Backwards 方法

Working-Backwards 从理想的客户成果出发，反向推导产品。PRFAQ 包含两部分：

部分	目的
新闻稿	仿佛产品已经发布一样，阐明客户价值
内部常见问题解答	提出团队必须回答的棘手业务和技术问题
外部常见问题解答	预判好奇的客户或媒体联系人会提出的问题

这个过程会迫使团队现在就对最棘手的问题给出具体答案，而不是等到开发数月之后。

三种意图

此技能支持三种模式。根据上下文判断意图：

意图	触发条件	输出
创建	没有现有 PRFAQ；新概念	从头编写完整的 prfaq.md
更新	已有 PRFAQ；需求发生变化	修订后的 prfaq.md，并附决策日志条目
验证	已有 PRFAQ 草稿；需要评议	评议报告；带注释的检查清单

核心工作流

1. 确定方向（适用于所有意图）

• 检查输出文件夹中是否已有 prfaq.md、project-context.md 和 decision-log.md。
• 与用户确认意图（创建／更新／验证）。
• 对于创建：继续步骤 2。
• 对于更新：阅读现有文档，找出变更的部分，继续步骤 4。
• 对于验证：阅读现有文档，运行验证清单（见下文）， 生成评议；然后停止——除非用户提出要求，否则不要重写。

2. 收集信息（创建／更新）

提出填写模板所需的最少问题。每完成一组问题就暂停，并在继续之前确认。建议分组如下：

A 组——客户与问题

• 目标客户是谁（角色、细分市场、情境）？
• 具体的问题或未满足的需求是什么？
• 没有这个产品时，他们目前如何应对？

B 组——产品与价值

• 用一句话说明产品的功能？
• 对客户来说，最重要的一项收益是什么？
• 客户能取得什么可衡量的成果？

C 组——差异化与可用性

• 它与现有解决方案有何不同？
• 客户何时以及如何获得它？
• 发布时的行动号召是什么？

D 组——棘手问题（内部）

• 最重要的 3 项风险或未知因素是什么？
• 这项功能在技术上成立必须具备哪些条件？
• 6 个月后和 12 个月后的成功标准是什么？

E 组——客户问题（外部）

• 客户最先会问什么？
• 什么因素可能让他们犹豫？
• 他们需要什么证据或证明？

3. 起草新闻稿

使用模板 ${CLAUDE_PLUGIN_ROOT}/skills/bmad-prfaq/templates/prfaq.template.md。

按以下顺序填写：

1. 标题 — 产品名称 + 一句话说明主要客户收益
2. 副标题 — 目标用户及关键成果
3. 开篇段落 — 问题背景（2-3 句话）
4. 问题段落 — 描述痛点，不要提及解决方案
5. 解决方案段落 — 介绍产品及其核心能力
6. 收益段落 — 2-3 段，每段说明一项关键收益
7. 客户引言 — 来自具名人物角色、听起来真实的引言
8. 行动号召 — 如何获取、何时推出，以及接下来该做什么
9. 公司引言 — 由内部负责人阐述战略意图

新闻稿控制在 600 词以内。如果无法写得简短，说明概念还不够清晰——请提出更多问题。

4. 起草内部常见问题解答

列出 10-15 个领导团队、投资者或持怀疑态度的工程师可能提出的问题。必须涵盖以下类别：

• 市场：为什么是现在？机会有多大？
• 客户：我们如何确认这是一个真实的问题？
• 商业模式：这如何带来收入或节省成本？
• 技术：最棘手的工程问题是什么？
• 风险：这最可能因哪 3 种情况而失败？
• 指标：30/90/180 天时，成功是什么样的？
• 考虑过的替代方案：我们还考虑了什么？为什么没有采用？
• 依赖项：发布前必须具备什么？

回答必须具体。“我们会再想办法”不可接受。

5. 起草外部常见问题解答

列出 5-10 个客户、记者或分析师在产品发布时可能提出的问题。 涵盖：定价/获取方式、隐私/安全、兼容性、支持、路线图。

6. 汇总并撰写

将三个部分汇总到输出文件夹中的 prfaq.md。

文件路径：{outputFolder}/prfaq.md

7. 记录决策（创建 / 更新）

在 {outputFolder}/decision-log.md 中追加一条简洁记录：

• 日期
• 意图（创建 / 更新）
• PRFAQ 中记录的关键决策
• 推迟到 PRD 阶段的未决问题

8. 推荐后续步骤

建议合适的 BMAD 路径和下一项技能：

• 如果 PRFAQ 内容较少（预计故事不多）：Quick Flow → 移交给 product-manager 编写技术规范。
• 如果 PRFAQ 内容扎实（包含多个史诗的产品）：BMAD Method → 移交给 product-manager 编写 PRD，然后交给 system-architect。
• 如果 PRFAQ 暴露出战略层面的不确定性：建议先再进行一轮 creative-intelligence 研究，再继续推进。

验证清单

当意图为 Validate 时（或在最终定稿前进行自查）：

• 标题明确指出具体的客户收益（而非功能）
• 新闻稿不超过 600 词
• 客户引言听起来像真人所说，而非营销文案
• 内部常见问题解答至少包含 10 个问题，且回答具体
• 内部常见问题解答至少包含一个“这会如何失败？”的问题
• 内部常见问题解答包含 30/90/180 天的成功指标
• 外部常见问题解答预见了客户的顾虑（而不只是热情）
• 所有未决问题都明确标注为未决（而不是含糊带过）
• 新闻稿部分不包含实现细节
• 文档不包含速度、故事点数或燃尽图

输出质量标准

完整的 PRFAQ 必须：

• 既便于非技术高管阅读，也能经受持怀疑态度的工程师审视
• 至少提出 3 个真正的未决问题（而非反问）
• 基于具体的客户用语，而非内部行话
• 避免承诺具体的技术方案（这属于架构工作）
• 总字数为 1,000–2,500 词（新闻稿 + 两份常见问题解答）

子 Agent 策略

模式： 顺序收集，并行起草

对于存在多个客户细分群体的大型或复杂产品，将常见问题解答的起草工作分配给不同细分群体：

Agent	任务	输出
Agent 1	起草内部常见问题解答（业务／市场／风险问题）	{outputFolder}/prfaq-internal-faq-draft.md
Agent 2	起草外部常见问题解答（客户／媒体问题）	{outputFolder}/prfaq-external-faq-draft.md

协调：

1. 以交互方式完成集群 A–E（顺序进行）。
2. 将收集到的背景信息写入 {outputFolder}/prfaq-inputs.md。
3. 在主上下文中起草新闻稿（篇幅精简，需要大量判断）。
4. 使用共享输入并行启动 Agent 1 和 Agent 2。
5. 主上下文审阅两份常见问题解答草稿，合并后写入 prfaq.md。

子 Agent 提示词示例（内部常见问题解答 Agent）：

Task: Draft the Internal FAQ section of a PRFAQ document.
Context: Read {outputFolder}/prfaq-inputs.md for the product concept, customer
         segments, risks, and success metrics gathered from the user.
Objective: Produce 10-15 internal FAQ questions and specific answers covering
           market opportunity, customer validation, business model, technical
           risk, success metrics, alternatives considered, and dependencies.
Output: Write draft to {outputFolder}/prfaq-internal-faq-draft.md.
Constraints:
- Answers must be specific, not aspirational placeholders.
- Include at least one "what are the top ways this fails?" question.
- Include success metrics at 30, 90, and 180 days.
- Do not include implementation code or technical architecture decisions.

集成

接收输入自：

• business-analyst（产品简介、探索笔记）
• creative-intelligence（研究、头脑风暴成果）
• 用户（直接描述概念）

提供输出至：

• product-manager（PRFAQ 为创建 PRD 提供内容）
• system-architect（内部常见问题解答中的待解决技术问题）
• decision-log.md（记录决策，供未来技能使用）

给大模型的提示

• 使用 TodoWrite 跟踪逐个集群收集信息的过程。
• 一次只询问一个集群的问题；不要一次性抛出所有问题。
• 如果用户描述含糊不清，请在起草前使用 WebSearch 查找真实市场数据，以便了解问题背景（在内部常见问题解答中注明来源）。
• 新闻稿必须写成仿佛产品已经发布——描述过去取得的成果，而不是对未来的承诺。
• 客户引言应听起来自然。反复修改，直到通过“真实的人会这么说吗？”这一检验。
• 不要基于此技能继续开展架构设计或故事创作。请移交。

---

属于 BMAD Planning & Orchestrator 插件——由 BMAD Code Organization 为 BMAD Method 构建的 Claude Code 工具框架（https://github.com/bmad-code-org/BMAD-METHOD）。体现了 bmad-prfaq 的理念。所有方法论的功劳均归于 BMAD Code Organization。