venue-operations-research-platform-plan.md 16.2 KB

Raw Blame History Permalink



场馆运营市场反馈调研平台改进方案（V0）

版本：V0.2

状态：Working Draft

更新时间：2026-03-26


0. 当前落地进展（2026-03-26）

本方案已从“纯规划”进入“Phase 1 持续实施”阶段，以下能力已经在仓库中完成首版实现，并完成 Docker 环境下的可用性验证：


场馆研究工作台已完成首版落地：首页主语义已经切换为“场馆运营反馈调研平台”，支持场馆名称、城市、场馆类型、研究重点、时间范围、竞品 / 标杆场馆等输入，并可自动生成研究指令。
场馆研究任务已支持保存与恢复：app.py 当前通过 var/logs/venue_research_tasks.json 维护任务快照，前端刷新后可恢复当前任务摘要、输入表单、研究指令和任务切换状态。
爬虫控制台已完成 Web 化封装：backend/crawler/ 当前提供 /api/crawler/options、/api/crawler/state、/api/crawler/login/check、/api/crawler/login/start、/api/crawler/login/cancel、/api/crawler/start、/api/crawler/stop 等接口，支持平台登录、登录状态检测、二维码提示、模式切换与历史配置回填；根目录 crawler_web.py 仅保留兼容转发。
报告中心已支持任务列表与历史恢复：ReportEngine/flask_interface.py 已新增 /api/report/tasks，并让 /api/report/status 返回任务快照；报告任务会落盘到 var/reports/final/.task_registry/，容器重建后仍可恢复历史结果入口。
前端工作台已完成 Vue 组件化迁移：当前主界面已由 frontend/ 下的 Vue 3 + Vite + TypeScript 工程承载，app.py 优先返回 static/frontend/index.html，templates/index.html 仅保留兜底页，前端已拆分为研究任务、采集中心、三引擎工作台、报告中心、配置抽屉等多个组件与 composable。
前端状态保持已完成：当前已通过 bettafish.frontendState.v2、bettafish.crawlerState.v2、bettafish.workspaceState.v2、bettafish.reportState.v2 与 bettafish.reportTemplate.v1 持久化研究任务、爬虫配置、活动引擎、自定义模板、报告查看状态与任务切换状态。
模型与搜索兼容改造已完成首版：系统当前默认兼容本地 Ollama OpenAI 兼容接口 http://192.168.220.11，模型为 qwen3.5:27b，允许空 key；同时 QueryEngine 已去除对 Tavily 的启动强依赖，可在未配置 Tavily 时继续使用其他搜索路径。
场馆报告模板已接入主链路：ReportEngine 已新增“场馆运营反馈调研报告模板”，并在模板选择、标题生成与 HTML 渲染层优先适配场馆运营反馈类查询。
Docker 统一部署已持续验证：当前通过 docker compose -f infra/docker/docker-compose.yml -f infra/docker/docker-compose.override.yml up -d --build 启动 bettafish 与 bettafish-db 两个服务，数据库健康检查正常，报告状态、任务历史与历史结果回读接口均已验证可用。
UI 第二轮重构已完成：当前工作台已新增顶部研究概览、快速跳转导航、组件化的研究任务表单、爬虫控制子模块、引擎页签子模块与报告任务/预览子模块，并完成高分辨率屏幕下的布局收口与页面可滚动验证。


当前可以判断，MVP 第一轮已经从“换壳方案”推进到“可运行工作台”。下一阶段的重点不再是单纯把入口做出来，而是继续推进结构化数据模型、竞品对比、任务闭环与更稳定的报告交互。


1. 背景与目标

当前项目 BettaFish 的核心定位是“舆情分析平台”，更偏向品牌、事件、公共话题的声量与情绪分析。

你的新目标更聚焦也更有业务价值：


服务对象从泛品牌/泛舆情，转为博物馆、艺术馆、数字艺术馆、展览馆、文旅场馆等运营团队
研究目标从“舆情走势判断”，转为“运营反馈调研 + 优缺点识别 + 改进建议支持”
输出结果从“舆情分析报告”，转为“场馆运营诊断报告 / 用户体验改进报告 / 市场反馈研究报告”


因此，这次改造不是简单改 UI 文案，而是要把项目升级为一个面向场馆运营决策的研究平台。


2. 新平台定位


2.1 建议定位

一个面向博物馆、艺术馆、数字展馆等场馆的运营反馈调研平台，通过爬虫、公开网络数据、用户评论和多源内容分析，系统识别场馆的优势、短板、改进优先级和市场机会，辅助运营团队优化服务、内容和市场策略。


2.2 目标用户


场馆馆长 / 运营负责人
市场品牌负责人
用户体验负责人
活动策展团队
文旅投资与咨询团队
区域文旅主管部门


2.3 核心输出


场馆优势清单
待改进问题清单
证据支持的用户反馈摘要
多平台口碑差异分析
竞品/同类型场馆对比
分级改进建议（高优先级 / 中优先级 / 长期优化）


3. 当前项目中可直接复用的能力

基于当前代码结构，以下能力可以直接复用，不建议推倒重来：


3.1 数据采集能力


MindSpider 多平台爬虫能力
当前已做好的前端触发式登录、状态检测、采集控制台
Docker 化运行方式
采集历史、配置回填、任务状态管理


3.2 多 Agent 分析能力


InsightEngine：适合保留为“结构化评论/数据库深挖分析引擎”

QueryEngine：适合保留为“外部公开网页/资讯/平台信息补充引擎”

MediaEngine：适合保留为“多模态内容与用户表达分析引擎”

ForumEngine：适合保留为“多视角交叉讨论与结论收敛机制”

ReportEngine：适合保留为“最终报告与可视化输出引擎”


3.3 交互与交付能力


现有三引擎分析主界面
当前控制台式运行反馈
HTML 报告生成链路
Docker 单体启动方式


4. 必须调整的核心方向


4.1 产品语义与业务模型必须重构

当前系统大量使用：


舆情
品牌声誉
危机传播
话题热度
舆论走势


这些表述不再是主语义，未来应替换为：


场馆运营反馈
用户体验洞察
服务短板识别
内容与展陈评价
到访决策因素
改进建议优先级


4.2 分析对象从“事件/品牌”改为“场馆实体”

平台分析对象应围绕“场馆档案”展开，而不是一个泛搜索词。

建议新增统一的 Venue 概念：


场馆名称
场馆别名
场馆类型
所在城市/商圈
主营展览类型
客群定位
票价区间
竞品列表


这样后续的爬虫、搜索、报告、对比都能围绕统一实体进行。


4.3 输出逻辑从“描述现象”改为“支持运营改进”

最终报告不应只说“大家评价如何”，而应回答：


用户最认可什么
用户最不满意什么
问题集中在哪些运营环节
哪些问题影响复购/推荐/到访决策
哪些建议最值得优先落地


5. 建议的新产品能力结构


5.1 场馆研究主页

新增“场馆研究任务”入口，用户输入的不是泛查询，而是：


场馆名称
城市
场馆类型
分析周期
研究目标


研究目标建议预设为：


识别场馆优点与亮点
识别待改进点
生成运营改进建议
对比同类场馆
评估某次展览/活动反馈


5.2 数据采集中心

把当前爬虫控制台升级为“数据采集中心”：


平台登录与状态检测
采集模式选择
关键词采集
指定场馆/展览/内容链接采集
评论、点赞、收藏、转发等结构化字段采集
周期性增量采集


建议新增“场馆研究预设”：


场馆名 + 城市
场馆名 + 打卡/避雷/值不值得去
场馆名 + 门票/排队/体验/服务
场馆名 + 亲子/拍照/展览/互动


5.3 场馆反馈分析中心

围绕运营场景新增标准分析维度：


展陈内容评价
空间与动线体验
服务态度与讲解质量
票价与性价比
排队与预约体验
拍照与社交传播价值
亲子/情侣/学生/游客等客群差异
交通、停车、餐饮、周边配套
活动/特展反馈
复购与推荐意愿


5.4 场馆改进建议中心

新增“建议引擎”，把问题转为可执行事项：


高优先级问题
可快速修复项
中期改进项
长期品牌建设项


建议输出格式：


问题描述
证据来源
影响范围
对运营的潜在影响
建议动作
优先级


5.5 竞品与标杆对比

新增“同类场馆对比分析”：


同城市竞品
同类型数字艺术馆/博物馆
高口碑标杆场馆
价格带相近场馆


输出对比维度：


用户好评点差异
差评集中点差异
社交传播特征差异
到访决策因素差异
可借鉴做法


6. 对现有五大引擎的重构建议


6.1 InsightEngine

建议新定位：


场馆反馈数据库分析引擎


主要职责：


从采集入库的数据中提取核心反馈
按维度做聚合统计
识别高频优点与高频问题
识别不同客群的评价差异


需要改动：


prompts 从舆情分析改为场馆运营反馈分析

keyword_optimizer 从“舆情搜索词”改为“用户自然表达的到访反馈搜索词”

search tools 结果聚合从“话题热度”转为“体验维度统计”


6.2 QueryEngine

建议新定位：


场馆公开信息与外部评价补充引擎


主要职责：


获取官网、OTA、地图、新闻、攻略、媒体报道
补充营业信息、票价信息、展览信息、活动信息
获取竞品资料和行业参考案例


重点不是“新闻检索”，而是“研究补证”。


6.3 MediaEngine

建议新定位：


用户表达与多模态内容理解引擎


主要职责：


分析短视频/图文内容中的体验表达
提取“适合拍照”“排队很长”“互动感强”“讲解太少”等视觉化线索
分析用户内容传播中最容易形成正向种草和负向避雷的要素


6.4 ForumEngine

建议新定位：


运营研究讨论板


主持逻辑建议由“多 Agent 讨论舆情”改为：


一个 Agent 负责优点总结
一个 Agent 负责问题诊断
一个 Agent 负责竞品比较
一个 Agent 负责运营建议收敛


最终由 Host 汇总成“场馆运营诊断结论”。


6.5 ReportEngine

建议新定位：


场馆运营改进报告引擎


建议新增报告模板：


场馆运营反馈诊断报告模板
博物馆/艺术馆用户体验改进报告模板
场馆竞品对标研究报告模板
特展/活动反馈复盘报告模板
月度场馆市场反馈监测报告模板


7. 数据模型重构建议


7.1 建议新增核心实体


Venue
VenueAlias
VenueResearchTask
VenueFeedbackItem
VenueIssue
VenueStrength
VenueImprovementSuggestion
VenueBenchmark


7.2 建议新增标签体系

给每条评论/内容打结构化标签，便于后续统计：


展览内容
空间环境
票价
排队
服务
导览讲解
亲子友好
拍照出片
科技互动
餐饮配套
交通停车
性价比
推荐意愿
复购意愿


7.3 建议新增评分维度

不只做情感极性，建议增加业务评分：


总体满意度
性价比评分
体验完成度
服务评分
空间动线评分
展陈吸引力评分
社交传播价值评分
复购可能性评分


8. 前端产品重构建议


8.1 首页主入口

把当前“请输入要分析的内容”改成更业务化入口：


输入场馆名称
选择研究目标
选择时间范围
选择是否联动爬虫补采


8.2 新增页面模块


场馆总览
数据采集中心
反馈分析面板
优点/问题对照面板
竞品对比面板
改进建议面板
报告导出页


8.3 结果展示方式

建议最终结果不要只是一份长报告，还要有结构化看板：


优点 Top 10
待改进点 Top 10
高频证据卡片
不同平台评价差异
客群差异图
改进优先级矩阵


9. Prompt 与模板层的重点改造

这是本轮重构中最关键的部分之一。


9.1 Insight Prompt 改造方向

从：


舆情热度
传播路径
情绪走势


改为：


用户为什么喜欢这个场馆
用户为什么不满意
哪些运营环节最容易被吐槽
哪些亮点最值得保留和放大


9.2 Report 模板改造方向

建议标准报告结构改为：


场馆基本认知与市场定位
用户反馈总体概览
核心优点分析
核心待改进点分析
不同客群与平台差异
竞品参考与差距识别
改进建议优先级清单
结论与行动建议


9.3 关键词优化器改造方向

当前优化器过于“舆情数据库取数导向”，要改成更贴近真实用户表达：


值不值得去
排队久不久
适不适合带孩子
出片吗
性价比如何
服务怎么样
展览值不值票价


10. 推荐的阶段实施路线


Phase 1：产品换壳但保留内核

目标：


完成产品定位替换
保留当前架构与三大分析主界面
让系统能生成“场馆运营反馈报告”


范围：


首页文案和任务入口改造
Prompt 改造
报告模板新增
结果页字段改名
新增“优点/待改进点/建议”输出结构


这是最快能出结果的 MVP。


Phase 2：场馆专用数据模型与标签体系

目标：


让分析不是泛评论总结，而是结构化运营洞察


范围：


数据表扩展
标签体系落库
增加运营维度评分
增加问题分类与建议分类


Phase 3：竞品与标杆研究能力

目标：


从“看自己”升级到“看自己 + 看同行”


范围：


竞品实体
对比分析逻辑
标杆案例提炼
对标报告模板


Phase 4：运营看板化

目标：


从报告工具升级为日常运营研究平台


范围：


仪表盘
周报/月报
场馆反馈趋势
问题闭环跟踪
改进事项复盘


11. 推荐的 MVP 功能清单

如果你要尽快做出第一个可用版本，我建议 MVP 只做下面这些：


输入场馆名称并发起研究任务
触发爬虫补采相关评论与内容
汇总多平台反馈
自动生成“优点 / 待改进点 / 改进建议”报告
支持按平台和客群查看差异
支持导出 HTML 报告


先不要在 MVP 做：


完整 CRM/工单系统
复杂权限系统
实时监控大屏
多租户 SaaS
运营改进行动闭环流程化审批


12. 关键风险


12.1 数据源风险


不同平台的可采性和风控强度不稳定
某些场馆评论量可能不足


12.2 结论可信度风险


如果只做情感分析，容易停留在泛结论
必须增加“证据引用 + 维度归类 + 问题优先级”


12.3 产品定位漂移风险


如果继续沿用“舆情”框架过多，会让结果像品牌监测工具
必须坚持围绕“运营改进”来设计分析逻辑和页面结构


13. 我对你的重构建议


建议的总体策略

不是重写整套系统，而是“保留架构，替换语义，重做模板，逐步升级数据模型”。


优先级建议


先改产品定位、Prompt、报告模板、前端文案
再改场馆标签体系与数据结构
再做竞品分析和运营看板


这样做的好处


可以最快得到第一个可演示版本
不会破坏你已经跑通的 Docker、爬虫、Agent、报告链路
后续每一阶段都能独立验证成效


14. 待确认项

这份方案基于以下默认假设：


你的首批目标对象是博物馆、艺术馆、数字艺术馆等线下场馆
你更重视“优点 / 问题 / 建议”而不是纯热度监测
你希望继续保留当前多 Agent 架构和 Docker 启动方式


后续正式落 PRD 前，建议你尽快确认三件事：


首个版本是否只做中文场馆与中文平台
是否要把 OTA / 地图 / 大众点评类数据纳入重点范围
最终交付更偏“研究报告工具”还是“持续运营看板平台”


当前 PRD、Backlog 与项目记忆文档已经建立完毕。若继续推进实施，下一步最合适的是：


收口报告页签与历史结果恢复的交互逻辑，保证报告查看态稳定。
启动 Venue、证据、标签、建议等结构化数据模型建设。
在结构化结果稳定后，继续推进竞品对比、趋势复盘与建议闭环。