企业官网建设流程全解析

BMAD-METHOD 的 PRFAQ 市场研究子代理：用 web-researcher 为产品概念收集竞争情报

【免费下载链接】BMAD-METHODBreakthrough Method for Agile Ai Driven Development项目地址: https://gitcode.com/gh_mirrors/bm/BMAD-METHOD

导读

bmad-prfaq是 BMAD-METHOD 方法体系中落地 Amazon Working Backwards（先写成品新闻稿、再回答最尖锐客户与内部问题）的规划类技能模块。在它的 Stage 1（Ignition）阶段，系统会并行派出两个研究子代理——Artifact Analyzer 负责扫描项目内文档，Web Researcher则专职通过联网检索获取竞争格局、市场环境与行业动态，为 PRFAQ 的每一个竞争性论断提供真实世界的数据支撑。本文以 agents/web-researcher.md 为骨架，完整解析该子代理的输入契约、三步执行流程与 JSON 输出规范，并结合 SKILL.md 中调用侧的上下文收集逻辑，说明如何将其嵌入 Working Backwards 主流程。读完本文，你将掌握：如何定义"质量优先"的定向搜索策略、如何把零散检索结果收敛为五个结构化的市场情报字段，以及如何为 Web Researcher 配置优雅降级路径。

一、定位：PRFAQ 流程中的外部情报子代理

在bmad-prfaq的五阶段工作流（Ignition → Press Release → Customer FAQ → Internal FAQ → The Verdict）中，Web Researcher 并不是一个独立运行的工具，而是 Stage 1 的Contextual Gathering（上下文收集）环节中被并行派出的两个子代理之一。SKILL.md 中对应调用逻辑如下：

Artifact Analyzer（agents/artifact-analyzer.md）——扫描{planning_artifacts}与{project_knowledge}中的相关文档及用户提供的路径，接收 product intent 摘要；Web Researcher（agents/web-researcher.md）——搜索与概念相关的竞争格局、市场背景与当前行业数据，同样接收 product intent 摘要。

两者"并行派出"（Fan out in parallel）的设计意图很明确：内部证据与外部情报同时汇聚，之后在 SKILL.md 的"Merge findings"步骤中与用户分享的内容合并，凡是能挑战或丰富用户既有假设的意外发现都会被显式抛出。bmad-manifest.json中该能力被登记为working-backwards（菜单码WB），属于plan阶段、前置依赖brainstorming与perform-research、后续衔接create-prd的可选能力，产出位置指向{planning_artifacts}——也就是说，Web Researcher 采集到的竞争情报最终会汇入 PRFAQ 文档并影响下游 PRD 的输入质量。

二、输入契约：一份 Product Intent 摘要

Web Researcher 收到的唯一输入是Product intent——对产品概念的摘要，由调用方（主 skill 的工作流）在 Stage 1 完成概念澄清后构造。其内容覆盖四个维度：

这四要素与 SKILL.md 中 Stage 1 要求捕获的 "Essentials"（customer / problem / stakes / initial concept）一脉相承——只有当主流程从用户侧拿到了足够的澄清，Web Researcher 的搜索才有锚点。值得注意的是，SKILL.md 明确规定主工作流"不亲自阅读用户提供的文件"，文件扫描交给 Artifact Analyzer，而 Web Researcher 也不需要处理文件，它只消费这份精炼的意图摘要去发起外部检索，从而把"文档内证据"与"文档外情报"两条证据链彻底分离。

三、执行流程：三步完成高质量的市场情报收集

第一步：识别搜索角度（Identify search angles）

基于 product intent，Web Researcher 需要先枚举出至少五类搜索角度，它们共同构成一次完整的竞争情报覆盖：

1. 直接竞争对手（Direct competitors）——正在解决同一问题的产品；
2. 相邻方案（Adjacent solutions）——针对同一痛点采取不同路径的方案；
3. 市场规模与趋势（Market size and trends）——所处领域的市场规模与发展方向；
4. 行业动态（Industry news）——正在创造机会或风险的行业新闻与发展；
5. 用户情绪（User sentiment）——现有方案用户的不满与抱怨点。

这五类角度恰好对应了 PRFAQ 后续阶段会被反复拷问的问题：Customer FAQ 中的 "How is this different from [existing solution]?"（差异化）、Internal FAQ 中的 "What's the competitive moat?"（护城河）以及 "Why us? Why now?"（时机）。先想清楚"要查什么"，再动手搜索，是避免被搜索引擎带偏的关键。

第二步：执行 3–5 次定向搜索（Execute 3–5 targeted web searches）

文档对此给出了一个核心原则：质量优先于数量（quality over quantity）。推荐的检索式模板包括：

• "[problem domain] solutions comparison"——问题领域的方案对比；
• "[competitor names] alternatives"——已知竞品的替代品（前提是已识别出竞品）；
• "[industry] market trends [current year]"——行业当年市场趋势；
• "[target user type] pain points [domain]"——目标用户在某领域的痛点。

将搜索次数限制在 3–5 次、每次检索目标明确的检索式，是为了保证后续 JSON 输出的每条 bullet 都来自经过筛选的定向结果，而非泛泛的排名页摘要。这与 SKILL.md 中 "All competitive, market, and feasibility claims in the output must be verified against current real-world data" 的硬性要求直接呼应——PRFAQ 不允许建立在"昨天的假设"之上。

第三步：综合发现（Synthesize findings）

最后一步要求不要罗列链接，而是提取信号（Don't just list links. Extract the signal）。原始检索结果需要经过抽象与归并，才能进入输出 JSON。这步是把"搜索结果"升维为"市场洞察"的关键：同一条信息可能同时支撑多个输出字段，例如某条行业报告既贡献了market_context的规模数据，也影响了timing_and_opportunity的时机判断。

四、输出契约：约束严格的 JSON 结构

Web Researcher 的输出格式是整篇文档中最具工程约束的部分——只允许返回一个 JSON 对象，禁止任何前言、评论或附加说明：

{ "competitive_landscape": [ {"name": "competitor", "approach": "one-line description", "gaps": "where they fall short"} ], "market_context": [ "bullet — market size, growth trends, relevant data points" ], "user_sentiment": [ "bullet — what users say about existing solutions" ], "timing_and_opportunity": [ "bullet — why now, enabling shifts" ], "risks_and_considerations": [ "bullet — market risks, competitive threats, regulatory concerns" ] }

五个字段的语义与用途如下：

两条硬性约束需要特别注意：

• 总响应 < 1,000 tokens——这是对子代理输出的 token 预算，确保并行派出的多个子代理结果能在一个上下文窗口内被主工作流合并处理，不会挤占主对话空间；
• 每节最多 5 条 bullet——强制"提取信号"而非"倾倒信息"，让合并方（Merge findings）能快速抓住最有冲击力的发现。

作为对照，Artifact Analyzer 的输出契约是 ≤1,500 tokens、6 个字段（documents_found / key_insights / user_market_context / technical_context / ideas_and_decisions / raw_detail_worth_preserving）。两者预算与字段不同，但"无前言、纯 JSON、限 token、限条目"的结构化契约风格一致——这是 BMAD-METHOD 子代理设计的统一模式：用强契约约束弱模型行为的不确定性。

五、在完整工作流中的协同与降级路径

Web Researcher 并非孤立执行，它与周边机制存在明确的协作关系：

1. 与 Artifact Analyzer 并行：SKILL.md 要求两者在 Contextual Gathering 中同时派出，一个吃内部文档、一个吃外部网络，结论在 Merge findings 中交汇；
2. 输入统一：两个子代理都接收 product intent 摘要，保证内外证据围绕同一概念展开；
3. 优雅降级（Graceful degradation）：SKILL.md 明确写道——如果子代理不可用，主工作流应内联扫描最相关的 1–2 份文档并直接执行定向网络搜索，"绝不阻塞工作流"（Never block the workflow）。这意味着 Web Researcher 是可替换的优化层，而非 PRFAQ 流程的硬依赖；
4. 不阻塞原则：无论子代理成功与否，Stage 1 的推进（创建{planning_artifacts}/prfaq-{project_name}.md、进入 Stage 2）都不被研究环节卡死，研究结论只作为输入素材和假设挑战者存在。

从模块配置看，customize.toml暴露了activation_steps_prepend/activation_steps_append/persistent_facts/on_complete等 [workflow] 命名空间配置项，团队可以在不修改 skill 源码的前提下注入合规检查、加载持久化事实（如"所有简报必须包含监管风险章节"）或追加激活步骤——这些钩子同样可以用于约束或补充 Web Researcher 的执行上下文。

六、快速上手：如何在实践中使用该子代理

Web Researcher 不提供独立 CLI，而是作为bmad-prfaqskill 工作流的一部分被自动触发。实际使用路径如下：

1. 运行bmad-prfaqskill（请求"create a PRFAQ"或"run the PRFAQ challenge"），支持--headless/-H参数以无交互方式生成初稿；
2. 在 Stage 1 中提供或澄清四要素（customer / problem / stakes / solution concept），主工作流据此构造 product intent；
3. 工作流自动并行派出 Web Researcher 与 Artifact Analyzer，前者按本文第三节的流程执行 3–5 次定向搜索并返回五个字段的 JSON；
4. 在 Merge findings 步骤，主工作流将两个子代理的发现与用户输入合并，并显式挑出挑战假设的意外信息；
5. 最终情报进入 PRFAQ 文档的竞争性论述，并在 Stage 5 汇入prfaq-{project_name}-distillate.md（LLM 蒸馏产物），供下游 PRD 创建消费。

如果子代理环境不可用，可参考 SKILL.md 的降级策略：自行按第三节的检索式模板执行定向搜索，并将结果整理成同样的五字段结构，即可手工复刻 Web Researcher 的核心能力。

七、设计启示：从子代理看 BMAD-METHOD 的研究治理

从 web-researcher.md 这 49 行定义中，可以提炼出 BMAD-METHOD 对"AI 驱动的产品研究"的治理思路：

• 角色即约束：把"市场研究分析师"写成人格化 prompt（You are a market research analyst），明确职责边界，避免子代理越界做文档扫描（那是 Artifact Analyzer 的活）；
• 流程即检查单：三步流程（角度识别 → 定向搜索 → 综合）把不可控的"上网查资料"变成可复现、可审计的固定步骤；
• 契约即护栏：JSON schema + token 上限 + bullet 上限，从格式层保证了并行子代理输出的可合并性与信息密度；
• 降级即韧性：显式声明子代理不可用时的工作流替代路径，确保研究环节永远不会成为 PRFAQ 流程的单点故障。

这套模式的价值在于：它把通常高度依赖个人经验的"竞品调研"，工程化成了一个输入明确、流程固定、输出可被下游 LLM 直接消费的标准化子代理——这也正是bmad-prfaq能稳定产出研究地基扎实的 PRFAQ，而非空谈新闻稿的原因所在。

【免费下载链接】BMAD-METHODBreakthrough Method for Agile Ai Driven Development项目地址: https://gitcode.com/gh_mirrors/bm/BMAD-METHOD