这个方向我非常认同，而且比“简单新闻爬虫”更适合你现在这套技术栈，也更有长期价值。

一句话评价：

这不是一个爬虫项目，而是一个“面向投资决策的事件驱动情报系统”。

它的核心价值不在“抓到多少新闻”，而在于：

1. 把分散信息结构化
2. 把事件映射到股票/板块
3. 用 AI 做归因、聚合、评分、推送
4. 最终沉淀成一个可扩展的 个人 AI 投研平台

一、我对你这个方案的整体判断

我觉得这个项目非常适合按下面这个目标来设计：

短期目标

先做一个 可稳定运行的 MVP：

• 自动采集新闻/公告/政策
• AI 提取股票、板块、情绪、事件类型
• 存 PostgreSQL
• 建 Elasticsearch 检索
• 做 Telegram 推送
• 每日生成早报/午报/晚报

中期目标

做成一个 “热点和事件分析引擎”：

• 热点板块统计
• 事件评分体系
• 消息聚合去重
• 个股画像/板块画像
• 持仓相关提醒

长期目标

演进成 AI 投研基础设施：

• 自动选股
• 板块轮动识别
• 公告结构化解析
• 策略回测
• 风险预警
• Agent 化分析

二、我建议的架构调整：先“模块化单体”，再微服务

你提到“直接按微服务 + AI Agent 思路设计”，这个方向没问题，但我建议：

不要一开始就拆太细的微服务

原因很现实：

• 采集站点多，变化频繁，先保证可维护性
• AI 调用链长，调试成本高
• 早期最难的是“数据质量 + 规则迭代”，不是服务拆分
• 微服务会引入：
  • 服务注册
  • 配置中心
  • 链路追踪
  • 分布式事务/幂等
  • 运维复杂度

最优策略

第一阶段：模块化单体

一个 Spring Boot 主工程，按业务拆包/拆模块：

• collector-news
• collector-announcement
• collector-policy
• collector-market
• ai-analysis
• scoring-engine
• search-service
• push-service
• report-service

配合：

• PostgreSQL
• Redis
• Elasticsearch
• Quartz
• 可选 Kafka

这样代码结构已经接近微服务边界，以后要拆非常容易。

第二阶段：再拆微服务

当出现下面情况时再拆：

• 采集任务量明显增大
• AI 分析吞吐上不去
• 推送和报表生成影响主流程
• 不同模块需要独立扩容

三、系统核心不是“采集”，而是“事件标准化”

你当前方案已经很接近正确答案了，我再往前推一步：

建议增加一个统一“事件表”

因为新闻、公告、政策，本质上最后都应该沉淀为一个“投资事件”。

比如：

• 工信部发布机器人政策
• 某龙头公司中标大单
• 某上市公司回购
• 北向资金持续流入新能源
• 某行业出现集体涨价

这些原始来源不同，但最终都应该映射成统一事件结构。

推荐事件中心模型

1）原始数据表

分别存抓到的内容：

• news_raw
• announcement_raw
• policy_raw
• capital_flow_raw

这些表负责：

• 原始留档
• 去重
• 回溯
• 重新分析

2）标准化事件表 event

这个表是系统最重要的一张表。

建议字段：

• id
• event_type
  例如：政策、公告、资金流、行业新闻、业绩预告、减持、回购、中标
• source_type
  news / announcement / policy / capital_flow
• source_id
• title
• summary
• content
• publish_time
• crawl_time
• sentiment
  positive / negative / neutral
• impact_level
  1~5
• duration_type
  intraday / short / medium / long
• is_major
• score
• status
  new / analyzed / pushed / aggregated
• created_at
• updated_at

3）事件关联表

因为一个事件可能关联多个股票、多个板块。

event_stock

• event_id
• stock_code
• stock_name
• relation_type
  直接相关 / 间接受益 / 龙头 / 跟涨
• confidence

event_sector

• event_id
• sector_id
• sector_name
• confidence

event_tag

• event_id
• tag
• tag_type
  概念 / 行业 / 风险 / 关键词

这样设计之后：

• 新闻可以转事件
• 公告可以转事件
• 政策可以转事件
• 资金流可以转事件

后面的搜索、推送、聚合、评分，全部围绕 event 做。

这会让你的系统架构一下子清晰很多。

四、AI 分析层建议不要只做“提取”，要做“两段式处理”

你给的 JSON 输出已经很好了，但我建议 AI 分析拆成两层。

第一层：结构化提取

输入原始内容，输出稳定 JSON：

{
  "eventType": "POLICY",
  "sentiment": "POSITIVE",
  "impactLevel": 4,
  "durationType": "MEDIUM",
  "industries": ["机器人", "工业自动化"],
  "concepts": ["人形机器人", "智能制造"],
  "stocks": [
    {"code": "300024", "name": "机器人", "reason": "概念相关"},
    {"code": "300124", "name": "汇川技术", "reason": "工业自动化龙头"}
  ],
  "summary": "工信部发布机器人产业创新行动计划，利好机器人及工业自动化方向。",
  "reason": "政策支持将提升行业景气度，并可能带来订单和资本关注。",
  "keywords": ["工信部", "机器人", "行动计划"],
  "positive": true
}

这一步强调：

• 格式稳定
• 可落库
• 可回放
• 可容错

第二层：规则增强 / 知识库校验

AI 输出不是最终结果，要经过规则引擎二次处理：

比如：

• AI 说“机器人”是股票，但实际上它也可能是板块名
• AI 提到“工业自动化”，需要匹配你知识库里的标准板块名
• AI 提到“宁王”，需要映射成“宁德时代”
• AI 识别出“工信部”，评分规则自动加分

所以流程应该是：

原始数据 → AI 提取 → 知识库标准化 → 评分引擎 → 事件入库

而不是直接把 AI 结果原封不动存进去。

五、知识库设计非常关键，建议一开始就做

你已经提到 stock、sector，这是对的，我建议再丰富一点。

核心基础表

stock

• code
• name
• market
• industry
• concepts
• is_active

sector

• id
• name
• type
  行业 / 概念 / 地域 / 风格
• description

stock_sector_rel

• stock_code
• sector_id
• relation_strength

建议增加别名字典

entity_alias

这个很重要，解决 AI 和爬虫提取中的同义词问题。

• id
• entity_type
  stock / sector / agency / concept
• standard_name
• alias_name

例如：

• 工信部 → 工业和信息化部
• 宁王 → 宁德时代
• 机器人概念 → 机器人
• AI → 人工智能

这个表会显著提升识别准确率。

建议增加机构/政策来源表

authority_source

• id
• name
• level
  国务院 / 部委 / 监管 / 地方
• weight_score

例如：

• 国务院：30
• 工信部：20
• 央行：20
• 证监会：20
• 财政部：18

这样评分不需要写死在代码里。

六、评分系统建议设计成“规则引擎 + AI 辅助”，不要全交给大模型

你提的评分系统很靠谱，我建议拆成三部分。

1）来源权重

例如：

• 国务院 +30
• 工信部 +20
• 证监会 +20
• 龙头公司 +15
• 行业龙头财报超预期 +15

2）事件类型权重

例如：

• 回购 +8
• 中标 +10
• 业绩预增 +12
• 大额订单 +10
• 减持 -15
• ST -40
• 立案调查 -50

3）传播/热度修正

例如：

• 同类新闻 1 小时内出现 10 次以上：+5
• 多个权威媒体同时报道：+5
• 龙头股 + 热门板块叠加：+8
• 历史类似事件短期有效性高：+若干

评分结果建议输出多维度

不要只存一个总分，可以存：

• source_score
• event_score
• heat_score
• ai_score
• final_score

这样后续你能看清楚某个事件“为什么分高”。

七、消息聚合是这个系统体验的分水岭

你说得非常对：

如果一天 200 条消息全推送，系统就废了。

所以必须做聚合。

聚合维度建议

按板块聚合

例：

• 机器人
• 创新药
• AI 算力
• 消费电子

按股票聚合

例：

• 宁德时代相关消息 7 条
• 中际旭创相关消息 4 条

按事件类型聚合

例：

• 政策
• 业绩
• 公告
• 资金流

聚合逻辑建议

实时推送

只推：

• 高分重大事件
• 龙头股事件
• 政策级事件
• 突发风险事件

定时报表

再聚合：

• 早报
• 午报
• 收盘总结
• 晚间公告

聚合实现思路

可先用简单规则：

• 标题相似度
• 关键词 overlap
• 相同板块/相同股票
• 时间窗口聚类（如 30 分钟/2 小时）

后续再升级成：

• 向量 embedding 聚类
• 主题归并
• 事件去重

八、Elasticsearch 的定位：不要只是全文检索，要做“情报检索”

你提的搜索能力很好，但我建议目标更清晰一点：

不是让用户搜“新闻”，而是搜“投资信号”。

ES 索引建议

event_index

核心索引字段：

• title
• summary
• content
• source
• publishTime
• eventType
• sentiment
• impactLevel
• score
• stocks
• sectors
• tags
• authority
• durationType

支持的查询场景

1）板块情报检索

• 机器人 利好 最近7天
• 创新药 政策 最近30天

2）个股事件检索

• 宁德时代 最近一个月
• 中际旭创 公告 利空

3）风险检索

• 减持 + 业绩下滑
• 立案调查 + ST

4）热点趋势

• 最近 24h 板块热度排行
• 最近 7 天政策驱动排行

九、采集层技术建议：按“站点难度”分级

这个很重要，避免一上来全部用 Playwright，成本太高。

第一类：静态页面 / API 可抓

优先用：

• OkHttp
• Jsoup

优点：

• 轻量
• 快
• 好维护

第二类：有签名 / 异步接口

尝试：

• 抓接口
• 分析请求参数
• 模拟 headers/cookies

第三类：强动态页面

再上：

• Playwright

只对少数站点使用，不要全站点浏览器化。

采集模块建议统一接口

定义：

• Collector
• Parser
• Normalizer

例如：

• EastMoneyNewsCollector
• CninfoAnnouncementCollector
• MiitPolicyCollector

每个站点都实现统一接口，后续扩展很轻松。

十、调度与异步处理建议

初期推荐

Quartz + 异步线程池

完全够用：

• 新闻每 2~5 分钟
• 公告每 1 分钟
• 政策每 10~30 分钟
• 热点统计每小时
• 日报定时生成

Kafka 要不要上？

我的建议：

第一版可以不上

因为早期数据量没那么大，先走数据库状态机也可以：

• 抓取后写 raw
• 状态 NEW
• AI 处理后改 ANALYZED
• 推送后改 PUSHED

什么时候加 Kafka

当你遇到这些问题时：

• 采集和 AI 分析互相阻塞
• 推送、统计、入 ES 耦合严重
• 峰值期间处理延迟明显
• 想做失败重试和削峰填谷

那时再加 Kafka 最自然。

十一、我建议的第一版模块划分

1. collector-service

负责：

• 新闻采集
• 公告采集
• 政策采集
• 资金流采集
• 原始数据入库
• 去重

2. analysis-service

负责：

• 调用大模型
• 结构化提取
• 实体识别
• 情绪分析
• 持续时间判断
• 摘要生成

3. knowledge-service

负责：

• 股票库
• 板块库
• 别名库
• 机构来源库
• 实体标准化

4. scoring-service

负责：

• 规则引擎
• 多维评分
• 热度加权
• 风险修正

5. search-service

负责：

• ES 建索引
• 检索
• 高级筛选
• 聚合统计

6. push-service

负责：

• Telegram
• 企业微信
• 邮件
• 实时事件推送
• 定时报表推送

7. web-api

负责：

• 前端接口
• 查询
• 报表
• 热点榜
• 事件详情
• 自选股管理

十二、数据库表我建议这样分层

原始层

• news_raw
• announcement_raw
• policy_raw
• capital_flow_raw

标准事件层

• event
• event_stock
• event_sector
• event_tag

知识库层

• stock
• sector
• stock_sector_rel
• entity_alias
• authority_source

分析结果层

• event_analysis
• event_score_detail
• event_push_log

用户层

• watchlist
• user_subscription
• push_channel_config

十三、前端第一版不需要复杂，先做 5 个页面就够了

MVP 页面建议

1. 首页仪表盘
   • 今日事件数
   • 热点板块排行
   • 利好/利空分布
   • 重大事件列表
2. 事件列表页
   • 按时间、板块、股票、情绪、来源筛选
3. 事件详情页
   • 原文
   • AI 摘要
   • 关联股票
   • 关联板块
   • 评分明细
   • 相似事件
4. 热点分析页
   • 24h / 7d 板块热度
   • 趋势图
   • 新闻数量
   • 情绪分布
5. 自选股/订阅页
   • 关注股票
   • 关注板块
   • 推送设置

十四、这类项目的真正难点，我提前帮你指出来

这个项目真正难的不是 CRUD，也不是 Spring Boot，而是下面几个问题：

1）去重

同一条消息可能来自多个媒体转载。

要处理：

• URL 去重
• 标题相似去重
• 内容 hash 去重
• 同主题聚合

2）实体识别准确率

AI 会有幻觉，也会误识别。

要靠：

• 知识库
• 别名字典
• 规则校验
• 人工修正规则

3）时效性

投资情报系统最怕晚。

所以：

• 抓取要快
• 分析要异步
• 推送要分级

4）误报和过度推送

不是所有消息都值得打扰用户。

必须做：

• 阈值控制
• 聚合摘要
• 高频降噪
• 龙头优先

5）合规与站点稳定性

采集公告、新闻、政策时要注意：

• 网站 robots / 使用条款
• 访问频率控制
• IP 封禁风险
• 页面结构变化

这个一定要预留监控和告警。

十五、我建议你按 3 个阶段推进

阶段一：MVP（2~4 周）

目标：打通主链路

功能

• 采集 3 类数据：新闻、公告、政策
• PostgreSQL 入库
• AI 结构化分析
• 事件表落库
• Telegram 推送
• ES 检索
• 简单 Web 列表页

重点

• 去重
• 稳定调度
• AI JSON 输出稳定
• 基础评分

阶段二：增强版（4~8 周）

目标：让系统“有判断力”

功能

• 热点板块统计
• 消息聚合
• 评分细化
• 自选股订阅
• 早报/午报/晚报
• 资金流接入
• 相似事件归并

阶段三：投研版（持续迭代）

目标：形成竞争力

功能

• 板块轮动分析
• 个股关系图谱
• 公告要素提取
• AI 每日复盘
• 事件驱动选股
• 回测和风险预警

十六、如果让我来定义“第一版最值得做的功能”

我会砍掉一部分复杂度，保留最有价值的部分。

最小可用版本

数据源

• 东方财富新闻
• 财联社
• 巨潮公告
• 工信部/证监会政策

核心能力

• 采集
• 去重
• AI 提取板块/股票/情绪
• 评分
• Telegram 推送
• ES 搜索
• 热点榜

先不急着做

• Kafka
• 多节点调度
• 复杂 Agent 编排
• 回测
• 关系图谱
• 多模型路由优化

这样最容易把系统跑起来。

十七、我给你的最终建议

结论一

这个项目方向是对的，而且很适合长期投入。

结论二

核心不是“爬虫平台”，而是：

采集 → 标准化事件 → AI 分析 → 评分 → 聚合 → 推送 → 检索

结论三

第一版建议：

模块化单体 + PostgreSQL + Redis + Elasticsearch + Quartz + Telegram + AI 统一网关

而不是一开始就上完整微服务。

结论四

从架构上，一定要围绕 event 事件中心模型 来设计，这会决定后面是否容易扩展到：

• 自动选股
• 热点分析
• 公告解析
• 回测
• 风险预警

如果你愿意，我下一步可以直接帮你继续往下做三件事之一：

1. 给你输出一版完整的数据库表结构设计（PostgreSQL DDL）
2. 给你画一版 Spring Boot 项目目录结构和模块拆分
3. 给你设计第一版 AI 分析接口协议和 JSON Schema

如果你想更落地一点，我建议我下一条直接给你：

“AI 投资情报平台 V1 的数据库设计 + 核心表 DDL”。

• Previous
  回测脚本