场馆运营反馈调研平台 PRD

版本：V1.1
状态：Draft
更新时间：2026-03-26

本文档基于当前 BettaFish 已完成的能力与近期改造方向整理，默认采用以下前提：

• 产品定位从“舆情分析平台”转向“博物馆 / 艺术馆 / 数字展馆运营反馈调研平台”。
• 保留现有多 Agent 架构、三引擎分析界面、最终报告输出链路与 Docker 启动方式。
• 爬虫执行从 CLI 触发改为前端页面按钮触发，并纳入登录、登录状态检测、采集模式选择等控制能力。
• 模型侧优先兼容本地 Ollama 部署，当前默认接入局域网模型服务 http://192.168.220.11，模型名为 qwen3.5:27b，允许空 key。
• 上线时间、预算与正式商业化指标当前均为 TBD，本文中的 KPI 作为建议目标，待后续业务确认。

0. 当前实施状态（2026-03-26）

当前版本的 PRD 已进入“边实施边校准”的状态，以下能力已完成首版实现或验证：

• 业务入口已切换为场馆研究任务：主界面已支持围绕场馆名称、类型、研究目标、竞品 / 标杆与时间范围创建任务，并自动生成研究指令。
• 爬虫能力已具备前端手动触发闭环：支持平台登录、登录状态检测、二维码登录提示、模式切换、任务启动 / 停止及历史配置回填。
• 三引擎与报告链路已切换到场馆语义：界面主文案、报告标题、模板选择与默认报告模板均已围绕“场馆运营反馈调研”完成首版适配。
• 前端主界面已迁移为组件化工作台：当前首页由 Vue 3 + Vite + TypeScript 构建产物承载，已具备研究概览、快速跳转导航、可滚动布局和高分辨率适配。
• 本地模型兼容已收口：系统已默认兼容局域网 Ollama 服务 http://192.168.220.11，模型 qwen3.5:27b，并允许空 key 运行。
• 搜索依赖已去 Tavily 强绑定：QueryEngine 已支持在 Tavily 缺失时继续运行其他搜索路径，避免因单一搜索服务阻塞主链路。
• 前端刷新后状态保持已完成：研究任务、爬虫配置、自定义模板、当前页签、报告查看状态与历史任务列表均可在页面刷新后恢复。
• 报告任务历史已具备落盘恢复能力：报告任务快照会写入 var/reports/final/.task_registry/，并支持从历史 report_state__*.json 兜底恢复；容器重建后仍可重新进入历史报告结果。

当前仍需继续推进的重点：

• 报告页签与三引擎完成态之间仍有部分交互锁定逻辑需要进一步收口，避免用户必须通过内部函数或特定顺序才能稳定进入报告查看态。
• 场馆实体、证据、标签、问题、建议等结构化数据模型尚未系统化落库，当前仍以文件与任务快照为主。
• 竞品对比、趋势复盘与建议跟踪闭环尚未进入完整实施阶段，仍属于后续版本重点。

1. Executive Summary

Problem Statement

当前系统更擅长对“品牌舆情、传播热度、事件声量”做分析，但这类输出并不直接回答博物馆、艺术馆、数字展馆运营团队最关心的问题：用户喜欢什么、抱怨什么、哪些问题值得优先整改、同类场馆做得更好的地方是什么。

同时，现有爬虫能力与分析能力尚未以“场馆研究任务”为中心组织，登录状态、采集模式、证据归因、报告模板、界面语义仍然偏向原有舆情场景，导致系统难以形成稳定的运营改进闭环。

Proposed Solution

在保留 BettaFish 现有多 Agent、爬虫、报告生成和 Docker 部署能力的前提下，将系统重构为面向场馆运营决策的研究平台。平台围绕“场馆研究任务”组织采集、分析与报告流程，输出“优点、待改进点、改进建议、竞品对比”四类核心结果，并提供人工触发爬虫、状态检测、报告导出与高分辨率适配的统一前端体验。

Success Criteria

以下为建议 KPI，正式值待业务确认：

• 单个场馆研究任务从创建到首版 HTML 报告产出可在 15 分钟内完成，不含人工扫码登录等待时间。
• 每份报告至少沉淀 20 条可追溯证据，并能归类到不少于 6 个运营维度。
• “优点 / 待改进点 / 改进建议”三类结论的证据覆盖率达到 80% 以上，即绝大多数结论均有原始评论、帖子、页面内容或公开信息支撑。
• 爬虫控制台支持不少于 3 类常用平台的登录状态检测、人工触发与模式切换，任务成功启动率达到 90% 以上。
• 主界面在 1440p、2K、4K 宽屏下均保持核心操作区与报告浏览区布局稳定，在 1280px 宽度下无关键功能遮挡或溢出。

2. User Experience & Functionality

User Personas

• 场馆运营负责人：关注用户痛点、服务短板、可快速落地的改进建议。
• 市场与品牌负责人：关注社交传播亮点、内容种草点、竞品差异与传播机会。
• 策展 / 活动团队：关注具体展览、活动、空间动线、讲解与服务体验的用户反馈。
• 研究分析师 / 咨询顾问：需要把多平台数据快速整理为结构化结论与可交付报告。
• 场馆管理层：关注是否值得投入整改、优先级排序、阶段性复盘结果。

User Stories

Story 1：创建场馆研究任务

作为运营负责人，我希望输入场馆名称、城市、研究目标与时间范围，就能发起一项围绕该场馆的研究任务，以便系统围绕统一实体组织后续采集与分析。

Acceptance Criteria：

• 用户可填写场馆名称、别名、城市、场馆类型、研究主题、时间范围。
• 研究主题至少支持“识别优点”“识别待改进点”“生成运营建议”“竞品对比”“活动/特展复盘”。
• 任务创建后，系统生成唯一任务 ID，并进入可追踪的任务详情页。

Story 2：前端手动触发爬虫与登录

作为研究分析师，我希望在页面上直接完成平台登录、查看登录状态、选择采集模式并启动爬虫，而不是依赖 CLI，以便降低操作门槛并提高任务可控性。

Acceptance Criteria：

• 前端提供平台账号状态、二维码 / 浏览器登录提示、最近一次登录时间与状态反馈。
• 用户可选择采集平台、关键词模式、链接模式、增量采集模式等执行方式。
• 登录状态异常时，系统会在启动前给出明确提示，不会静默失败。
• 所有爬虫动作都通过 Docker 内统一服务执行，不要求宿主机手工运行脚本。

Story 3：保留并重构三引擎分析体验

作为研究分析师，我希望继续使用现有三引擎分析流程与结果界面，但其语义、提示词、指标和输出字段应调整为场馆运营场景，以便延续已有工作习惯并减少学习成本。

Acceptance Criteria：

• 保留三引擎入口、运行过程反馈与最终输出界面。
• 引擎标签、描述与字段从“舆情”转向“场馆运营反馈研究”。
• 输出结果至少包含运营维度聚类、核心证据、优点、待改进点、改进建议。

Story 4：生成管理层可读报告

作为场馆管理层，我希望直接拿到一份结构化报告，而不是零散分析结果，以便快速理解结论并安排后续动作。

Acceptance Criteria：

• 报告默认包含“场馆概览、用户反馈概览、优点、待改进点、建议优先级、竞品或标杆参考、行动建议”。
• 报告支持 HTML 导出，后续可扩展 PDF。
• 每个关键结论都能定位到证据摘要或引用来源。

Story 5：查看高分辨率可用的运营分析工作台

作为日常使用者，我希望系统在高分辨率宽屏与常规办公屏上都保持清晰、精致、可滚动和层级合理的界面体验，以便长期作为工作台使用。

Acceptance Criteria：

• 页面支持纵向滚动，不出现关键内容被固定布局截断的问题。
• 高分辨率屏幕下，页面主体最大宽度、边距、信息栅格与结果区分栏均能自适应。
• 风格统一为极简、专业、信息密度适中的运营研究界面。

Non-Goals

• 本阶段不建设完整 CRM、工单审批系统或跨部门协作流转系统。
• 本阶段不做多租户 SaaS 账单、组织级权限体系与复杂 RBAC。
• 本阶段不承诺全网全平台实时监控，只聚焦“任务驱动式调研”与后续可扩展的周期复盘。
• 本阶段不做自动化整改执行，仅输出可行动建议与优先级。

3. AI System Requirements

Tool Requirements

• 爬虫与采集：
  • 复用 MindSpider 与当前 Web 化控制台能力。
  • 支持平台登录、登录状态检测、手动触发、采集模式选择、任务状态反馈。
• 研究与分析：
  • InsightEngine：从沉淀数据中提取运营维度、优点、问题与证据。
  • QueryEngine：补充官网、新闻、地图、攻略、第三方介绍等公开资料。
  • MediaEngine：理解图文/短视频表达中的用户体验线索与传播亮点。
  • ForumEngine：组织多 Agent 讨论并收敛为诊断结论。
  • ReportEngine：生成适配场馆研究的新型报告模板。
• 模型与推理：
  • 默认兼容本地 Ollama OpenAI 兼容接口。
  • 支持空 key 配置。
  • 模型调用应尽量与现有引擎配置解耦，避免单点硬编码。
• 数据与输出：
  • 支持任务级研究结果、证据片段、标签、报告文件落盘或入库。
  • 保留现有 Streamlit 报告目录与最终聚合输出链路。

Evaluation Strategy

• 结论可信度评估：
  • 抽样检查每份报告的优点、问题、建议是否具备证据引用。
  • 建立 20 至 30 个样例场馆任务的人工对照集，验证问题识别与建议归因是否合理。
• 分类与标签评估：
  • 针对“展陈内容、空间动线、服务、票价、排队、亲子友好、拍照出片、交通配套”等维度建立人工标注样本，评估标签准确率。
• 报告可用性评估：
  • 由运营侧评审结论是否具备“可执行、可排序、可复盘”特征。
• 系统稳定性评估：
  • 统计登录成功率、采集启动成功率、报告生成成功率、任务平均耗时。

4. Technical Specifications

Architecture Overview

建议在不推倒重来的情况下，保留现有主干架构并做语义重构：

1. 前端工作台：
   • 主入口继续由 Flask + templates 驱动。
   • 保留并优化现有三引擎分析入口与报告浏览区。
   • 新增“数据采集中心 / 场馆研究任务 / 竞品对比 / 建议面板”等工作区。
2. 爬虫执行层：
   • 将 CLI 操作进一步封装为前端可调用的后端接口。
   • 登录、扫码、状态检测、启动与停止均由统一服务管理。
   • 浏览器数据、Cookie 和状态文件通过 Docker volume 持久化。
3. 多 Agent 分析层：
   • InsightEngine 负责结构化运营反馈分析。
   • QueryEngine 负责补充公开信息与竞品背景。
   • MediaEngine 负责图文/视频类表达理解。
   • ForumEngine 负责多角色讨论与结论收敛。
4. 报告生成层：
   • ReportEngine 使用新的场馆研究模板输出 HTML 报告。
   • 报告结论需回链到证据摘要。
5. 存储层：
   • 继续使用现有文件输出目录。
   • 结合 Postgres 新增任务、场馆、标签、结论、证据、建议等结构化表。

Integration Points

• 模型服务：
  • 本地 Ollama OpenAI 兼容接口，默认地址 http://192.168.220.11。
  • 支持空 key，配置入口统一在 .env 或引擎配置层。
• 数据库：
  • Postgres 负责任务与结构化结果管理。
  • 文件系统继续保存 HTML/Markdown/PDF 等最终交付物。
• 服务编排：
  • 全量服务通过 docker compose 启动。
  • 爬虫、主站、数据库、引擎辅助进程的依赖关系通过容器统一管理。
• 前端集成：
  • 复用当前三引擎 Streamlit 页面或嵌入式展示模式。
  • 统一主站负责任务管理、状态同步、入口组织与风格一致性。

Security & Privacy

• 场馆研究任务默认仅处理公开网页内容、公开评论与用户自主登录后可访问的平台页面。
• 登录状态与浏览器数据应保存在容器挂载卷中，不写入报告正文。
• 日志与错误追踪中避免输出敏感凭证。
• 后续如接入非公开或商业数据源，需单独补充授权与合规策略。

5. Risks & Roadmap

Phased Rollout

MVP

• 完成产品语义切换与首页工作台改造。
• 完成场馆研究任务创建、爬虫手动触发、登录状态检测。
• 保留三引擎界面，但输出字段转为场馆运营研究结果。
• 新增首版场馆研究报告模板，输出“优点 / 待改进点 / 建议”。
• 完成 Docker 统一部署与最小可用数据模型。

v1.1

• 引入场馆标签体系、运营维度评分、问题优先级排序。
• 引入竞品与标杆场馆对比任务。
• 优化高分辨率与宽屏体验，形成稳定的研究工作台。

v2.0

• 引入周期复盘、趋势分析、建议跟踪与任务沉淀。
• 引入更强的数据治理、权限管理与场馆资产档案。
• 支持更丰富的报告对比与长期运营观察视图。

Technical Risks

• 平台登录与反爬策略波动可能导致采集能力不稳定。
• 本地模型在总结、归因、建议生成上的稳定性可能低于云端模型，需要额外做提示词与评估集校准。
• 若仍沿用“舆情分析”语义的模板和提示词，系统输出会偏离“运营改进”目标。
• 前端若继续堆叠旧页面而不做信息架构梳理，容易造成入口混乱与高分辨率适配问题。
• 如果任务、证据、标签、结论没有结构化落库，后续竞品对比与趋势复盘会难以支撑。

Open Items

• 首版重点覆盖的平台范围待确认，建议优先从中文主流社交 / 内容 / 地图 / 点评类平台切入。
• 竞品对比是否在 MVP 进入首版交付，还是放入 v1.1，需要结合采集复杂度确认。
• 是否需要引入角色权限与任务共享能力，当前建议放在 v2.0 之后。