BMAD-METHOD 的 PRFAQ 市场研究子代理:用 web-researcher 为产品概念收集竞争情报 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 1Ignition阶段系统会并行派出两个研究子代理——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 Analyzeragents/artifact-analyzer.md——扫描{planning_artifacts}与{project_knowledge}中的相关文档及用户提供的路径接收 product intent 摘要Web Researcheragents/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 完成概念澄清后构造。其内容覆盖四个维度维度说明Customer目标客户是谁具体画像而非所有人Problem要解决的客户问题具体且可感知而非抽象描述Solution direction解决方案的初步方向Domain概念所处的业务/技术领域这四要素与 SKILL.md 中 Stage 1 要求捕获的 Essentialscustomer / problem / stakes / initial concept一脉相承——只有当主流程从用户侧拿到了足够的澄清Web Researcher 的搜索才有锚点。值得注意的是SKILL.md 明确规定主工作流不亲自阅读用户提供的文件文件扫描交给 Artifact Analyzer而 Web Researcher 也不需要处理文件它只消费这份精炼的意图摘要去发起外部检索从而把文档内证据与文档外情报两条证据链彻底分离。三、执行流程三步完成高质量的市场情报收集第一步识别搜索角度Identify search angles基于 product intentWeb Researcher 需要先枚举出至少五类搜索角度它们共同构成一次完整的竞争情报覆盖直接竞争对手Direct competitors——正在解决同一问题的产品相邻方案Adjacent solutions——针对同一痛点采取不同路径的方案市场规模与趋势Market size and trends——所处领域的市场规模与发展方向行业动态Industry news——正在创造机会或风险的行业新闻与发展用户情绪User sentiment——现有方案用户的不满与抱怨点。这五类角度恰好对应了 PRFAQ 后续阶段会被反复拷问的问题Customer FAQ 中的 How is this different from [existing solution]?差异化、Internal FAQ 中的 Whats 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最后一步要求不要罗列链接而是提取信号Dont 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 ] }五个字段的语义与用途如下字段含义在 PRFAQ 中的下游用途competitive_landscape竞品对象数组名称、一句话方案描述、短板支撑 Press Release 的差异化表述与 Customer FAQ 的凭什么换回答market_context市场规模、增长趋势、相关数据点支撑 Internal FAQ 的业务可行性判断user_sentiment用户对现有方案的公开评价反哺 Stage 1 的痛点验证避免基于臆想的用户画像timing_and_opportunity为什么是现在、哪些使能因素正在变化支撑 Internal FAQ 的 Why now? 论证risks_and_considerations市场风险、竞争威胁、监管隐忧进入 The Verdict 阶段的 Cracks in the foundation 评估两条硬性约束需要特别注意总响应 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 并非孤立执行它与周边机制存在明确的协作关系与 Artifact Analyzer 并行SKILL.md 要求两者在 Contextual Gathering 中同时派出一个吃内部文档、一个吃外部网络结论在 Merge findings 中交汇输入统一两个子代理都接收 product intent 摘要保证内外证据围绕同一概念展开优雅降级Graceful degradationSKILL.md 明确写道——如果子代理不可用主工作流应内联扫描最相关的 1–2 份文档并直接执行定向网络搜索绝不阻塞工作流Never block the workflow。这意味着 Web Researcher 是可替换的优化层而非 PRFAQ 流程的硬依赖不阻塞原则无论子代理成功与否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 工作流的一部分被自动触发。实际使用路径如下运行bmad-prfaqskill请求create a PRFAQ或run the PRFAQ challenge支持--headless/-H参数以无交互方式生成初稿在 Stage 1 中提供或澄清四要素customer / problem / stakes / solution concept主工作流据此构造 product intent工作流自动并行派出 Web Researcher 与 Artifact Analyzer前者按本文第三节的流程执行 3–5 次定向搜索并返回五个字段的 JSON在 Merge findings 步骤主工作流将两个子代理的发现与用户输入合并并显式挑出挑战假设的意外信息最终情报进入 PRFAQ 文档的竞争性论述并在 Stage 5 汇入prfaq-{project_name}-distillate.mdLLM 蒸馏产物供下游 PRD 创建消费。如果子代理环境不可用可参考 SKILL.md 的降级策略自行按第三节的检索式模板执行定向搜索并将结果整理成同样的五字段结构即可手工复刻 Web Researcher 的核心能力。七、设计启示从子代理看 BMAD-METHOD 的研究治理从 web-researcher.md 这 49 行定义中可以提炼出 BMAD-METHOD 对AI 驱动的产品研究的治理思路角色即约束把市场研究分析师写成人格化 promptYou 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创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考