一、新闻模块

  1. 优化横向滑动(Carousel)设计

目前的横向滑动设计,在内容较少时体验较好,界面简洁、美观。

但随着新闻数量增加,会出现以下问题:

  • 用户需要不断左右滑动,查找效率下降;
  • 不利于快速定位目标内容;
  • 长时间浏览容易增加操作负担。

建议:

保留现有滑动设计,同时增加检索能力。

例如:

  • 板块内搜索(关键词搜索)
  • 标签(Tag)筛选
  • 时间筛选
  • 热门/最新排序

让用户既可以浏览,也可以直接查找。

  1. 新闻分类不应过于割裂

目前新闻被严格划分到不同栏目。

但实际上,一条新闻往往具有多个属性,例如:

  • AI + 金融
  • 宏观经济 + 商品市场
  • ESG + 银行业
  • 科技 + 医疗

如果只能归属于一个栏目,会导致:

  • 信息被人为割裂;
  • 用户容易遗漏相关内容;
  • 不利于知识关联。

建议:

采用多标签(Multi-tag)机制。

例如一篇新闻可以同时属于:

AI / 金融 / 大模型 / OpenAI

用户进入任意相关栏目,都能够看到该新闻。

这样既保留分类,也增强内容之间的连接。

二、论文模块

  1. 增加全文检索能力

目前用户主要通过浏览期刊来寻找论文。

存在的问题:

  • 如果不知道论文属于哪个期刊,很难找到目标论文;
  • 浏览效率较低;
  • 只能逐个进入期刊查看。

建议新增:

  • 论文标题搜索
  • 作者搜索
  • DOI 搜索
  • 关键词搜索
  • 学科搜索

让用户能够直接定位论文,而不是先找到期刊。

  1. 优化期刊浏览方式

可以参考 phds.io 的部分设计思路。

优点:

  • 选择期刊非常方便;
  • 浏览速度快。

但不建议完全采用它的交互方式。

原因:

当用户点击一个期刊后,其余期刊全部消失,容易导致:

  • 用户失去整体视图;
  • 来回切换成本较高;
  • 不利于跨期刊浏览。

建议:

提供两种浏览模式,由用户自行切换:

模式一:聚焦模式(Focus)

类似 phds.io。

点击一个期刊后,仅展示该期刊论文。

适用于:

  • 已明确目标期刊;
  • 深度浏览。

模式二:全部模式(All Journals)

参考知网(CNKI)的设计。

用户可以:

  • 同时检索多个期刊;
  • 查看多个期刊的论文;
  • 根据关键词跨期刊搜索。

这样能够兼顾:

  • 定向阅读;
  • 全局检索。

三、建立新闻、论文、Insight 三者之间的关联

目前三个模块彼此独立:

  • 新闻
  • 论文
  • Insight

用户浏览时容易形成信息孤岛。

但实际上,它们应该围绕同一主题进行关联。

例如:

新闻:

OpenAI 发布 GPT 新版本

对应:

论文:

  • Large Language Models
  • Retrieval-Augmented Generation
  • Agent Systems

Insight:

  • 对行业影响分析
  • 市场机会分析
  • 投资观点

这样用户可以沿着同一主题不断深入。

建议增加主题(Topic)系统

每一条内容都附加多个主题标签,例如:

  • AI
  • LLM
  • 金融科技
  • 商品市场
  • ESG
  • 银行业
  • 机器人

新闻、论文、Insight 共用同一套 Topic。

这样所有内容能够自动关联。

在新闻页面增加相关推荐

阅读一篇新闻后,页面底部可以自动展示:

相关新闻

  • Topic 相同
  • 热度较高
  • 最新更新

相关论文

展示:

  • 标题
  • 作者
  • 期刊
  • 年份

用户点击即可阅读全文(或跳转)。

相关 Insight

例如:

  • 行业分析
  • 深度解读
  • 市场观点
  • AI 总结

形成:

新闻 → 论文 → Insight

的知识链路,而不是三个彼此独立的模块。

四、整体产品方向建议

产品定位并不仅仅是一个新闻平台,而应构建一个围绕同一主题的知识平台(Knowledge Hub)。

核心思路是以 Topic(主题) 为中心,而不是以 内容类型(新闻 / 论文 / Insight) 为中心。

建议采用如下组织结构:

Topic(主题)

├── News(相关新闻)

├── Papers(相关论文)

├── Insights(分析解读)

├── Keywords(关键词)

└── Related Topics(相关主题)

用户可以从任意入口(新闻、论文或 Insight)进入,并围绕同一 Topic 进行连续探索,实现真正的知识关联,而非内容孤岛。

这份意见已经整理成偏产品需求文档(PRD)的风格,如果要给开发团队或设计师使用,我还可以进一步整理成「问题 → 原因 → 解决方案 → 优先级(P0/P1/P2)」的标准需求文档格式。