产品动态报告

它解决什么问题

产品团队的信息来源是散的：技术侧的模型与平台更新、竞品的版本与定价调整、市场需求的迁移、监管与合规要求，往往分散在邮件订阅、社群和新闻源里。手工整理一份周报或月报，真正耗时的不是写，而是检索、核对来源、判断哪条值得跟进。

产品动态收集与影响分析 把这件事拆成可重复执行的流程：先锁定分析对象，再按四类维度检索，汇总成结构化报告，最后把值得跟进的信号转成带优先级的改进项。

核心能力与关键步骤

• 范围确认：产品/领域、关注竞品、时间窗口（默认近 30 天，支持「本月 / 本季度 / 近 90 天」）。未明确时先追问，而不是自行假设。
• 四类动态检索：科技进步、竞品动态、市场进步、政策进步。读取 references/search-strategy.md，替换 {{PRODUCT}} / {{TIME}} 后每类跑 2–3 组查询，必要时用 WebFetch 取正文细节。
• 结构化汇总：每条动态记录来源名、日期、URL，按模板逐条写出动态描述、来源、关联分析、潜在影响/风险，政策类额外标注风险等级（高/中/低）。
• 影响分析表：跨四类信号转成 5–12 条改进项，字段包含影响描述、改进建议、优先级（P0/P1/P2）、类型（功能/体验/合规/增长）、建议周期、负责方，并按优先级排序。
• 产出与交付：套用 assets/product-dynamics-template.md 生成 Markdown 报告，保存到工作区并用 present_files 预览；需要时可把某条 P0 展开成需求文档或路线图条目。

适用边界与注意点

• 报告质量取决于检索质量：查询模板与信源建议写在 references/search-strategy.md，改模板前先跑一轮小范围验证。
• 中文产品以中文查询为主，出海竞品补英文查询；政策类回溯近 90 天（发布到生效常有延迟），竞品类保持近 30–60 天。
• 所有动态必须带来源链接，无法核实的标注「待核实」，不要臆断。
• 它产出的是结构化情报与建议，不替代决策：优先级判断与负责方归属仍需人工确认。