Hello-AI Explore 项目发现体验分析与优化方案

更新日期：2026-08-02
范围：public/explore/ 原生探索页及其派生数据生成逻辑
目标：把 Explore 从“项目陈列与筛选页面”升级为“帮助用户表达目标、形成候选、持续收敛并完成选型的项目发现工具”。

1. 执行结论

Explore 已经具备搜索、分类筛选、潜力评分、相关项目、收藏、对比和任务路线等良好基础。当前的主要矛盾不是功能缺失，而是这些能力仍围绕“展示项目”组织，用户需要自己理解分类、判断信号并从数千条结果中完成收敛。

本轮优化应围绕一条连续发现路径重组页面：

表达目标 → 选择决策偏好 → 获得解释型短名单 → 继续缩小结果 → 对比与收藏 → 从历史继续探索

最高优先级不是增加更多榜单，而是减少用户每一步面对的选择数量，并明确告诉用户：

1. 为什么这个项目会出现在这里；
2. 它更适合快速试用、生产选型、追踪新项目，还是挖掘小而美项目；
3. 下一步应该缩小哪个维度，或把哪些项目放进同一组比较。

2. 现状审计

2.1 已有优势

• 数据规模与可信度较强：项目总量、活跃项目量、分类、更新时间均有明确展示。
• 已有纯静态高交互架构，不依赖后端即可完成搜索、筛选、详情和对比。
• 项目数据已有 potential、freshness、maturity、focus、topicSignal 五维信号。
• 已生成任务路径、赛道洞察、榜单、相似项目、适用场景、注意点和下一步建议。
• URL 已同步查询、分类、标签、活跃度、Stars 和排序，便于分享筛选结果。
• 本地收藏、对比和最近浏览已经形成后续个性化发现的基础。

2.2 核心问题

A. 任务路径名义上在缩小范围，实际召回过宽

当前六条任务路径每条匹配约 8,100–8,500 个项目，而活跃项目总数约 9,232。原因是任务匹配将分类和通用质量分直接加入阈值，即便项目没有足够的任务语义命中，也容易进入候选。

结果是：

• “构建 Agent”和“搭建 RAG”都接近全库搜索，任务入口缺乏区分度；
• 一张任务卡里“优先试用”取完候选后，生产候选和近期活跃轨道经常为空；
• 用户看到一个很大的候选数字，却不知道系统究竟替自己排除了什么。

B. 首屏仍以内容陈列为主，没有形成决策动作

Radar 依次展示任务路径、赛道概览、四类榜单。它能制造“项目很多、数据很全”的感受，但用户打开页面后仍需自己决定：

• 应该先进入哪条路径；
• 更看重成熟度、活跃度还是低门槛；
• 任务路径中的几个项目为什么值得先看；
• 看完一个项目后，如何形成一组可比较候选。

首屏缺少一个能把“我的目标”和“系统推荐”连接起来的交互工作台。

C. Explorer 能筛选，但不擅长帮助用户逐步收敛

现有 Explorer 是典型的左侧筛选器 + 右侧结果列表：

• 标签是全局热门标签，而不是当前结果中最能继续缩小范围的标签；
• 结果页没有基于当前结果提示“下一步可按什么维度缩小”；
• 无结果时只提示更换关键词，没有提供一键放宽条件；
• “潜力、相关度、最近活跃、Stars、新收录”是排序方式，不是用户容易理解的选型目标；
• 选型简报虽挑出 3 个项目，但没有一键加入对比，也没有根据用户偏好改变推荐角色。

D. 推荐缺少一致、可解释的“为什么”

卡片显示 Stars、更新时间和探索信号，搜索时也有“命中标签/简介”提示，但这些信息没有被组织成明确推荐理由。例如：

• “适合生产候选：成熟度 86，近期仍有更新”；
• “隐藏宝石：探索分高，但 Stars 尚未过度集中”；
• “与你收藏的 X 同属 RAG Frameworks，并共享 GraphRAG / document-parser 标签”。

推荐若不能解释，用户仍会回到 GitHub 自己从头判断。

E. 移动端筛选阻塞结果发现

在 390px 宽度下进入 Explorer，分类、子类、标签、活跃度和 Stars 会全部平铺在结果之前。用户必须滚动很长距离才能看到第一条结果，页面从“探索工具”退化成“筛选项清单”。

移动端应使用底部筛选面板或抽屉，只在主页面保留当前条件、结果数量和“筛选”入口。

F. 已有数据资产未充分消费

• search-index.json 已生成任务快捷查询和同义词，但前端和 Worker 仍各自硬编码一份配置。
• categoryInsights 的近期活跃数量、平均探索分、领跑项目没有进入 UI。
• 收藏、最近浏览和相关项目尚未形成“继续探索”推荐。
• 相似项目只有项目名称与描述，没有共享标签或同类关系说明。
• Explore 派生数据快照落后于源项目数据，需要重新生成。

3. 目标用户与发现任务

3.1 用户类型

用户	典型问题	页面应提供的价值
快速试用者	“今天想找一个能跑起来的 Agent / RAG 工具”	少量起步候选、明确试用理由、快速打开 GitHub
技术选型者	“哪些项目更成熟、仍活跃、适合进入生产评估”	成熟候选、风险提示、自动短名单和对比
趋势探索者	“最近有什么新方向、小而美项目”	新且活跃、高潜低星、跨赛道延展
学习者	“我想系统理解一个方向，从哪里开始”	任务路线、学习资源、框架与样例的分层组合
回访用户	“上次收藏了几个项目，接下来还可以看什么”	基于收藏/最近浏览的连续发现与解释型推荐

3.2 需要优化的用户旅程

新用户

1. 在首屏选择“我想做什么”；
2. 再选择“我更看重什么”；
3. 系统立即给出 3–4 个带理由的短名单；
4. 用户可以进入 Explorer 继续筛选，或一键把短名单加入对比；
5. Explorer 根据当前结果给出下一步缩小建议。

有明确关键词的用户

1. 搜索 MCP、GraphRAG、Claude Code 等关键词；
2. 卡片展示命中原因和推荐理由；
3. 结果上方给出当前结果中最有区分度的子类与标签；
4. 一键形成 3 个不同角色的候选；
5. 进入对比后按成熟、活跃、聚焦、热度等维度判断。

回访用户

1. 查看收藏与最近浏览；
2. 系统从相关项目中排除已看项目；
3. 展示“因为你收藏/看过 X，所以推荐 Y”；
4. 继续收藏、对比或沿标签深入。

4. 本轮落地方案

4.1 新增“发现工作台”

Radar 首屏新增目标与偏好组合器：

• 目标：构建 Agent、搭建 RAG、本地模型、多模态、开发工具、学习 AI 工程；
• 偏好：综合推荐、生产优先、最近活跃、隐藏宝石；
• 输出：3–4 个解释型候选项目；
• 动作：进入 Explorer 继续筛选、一键加入对比、查看项目详情。

任务卡上的数量是“直接命中任务语义”的候选信号，不把它伪装成最终搜索结果总数；进入 Explorer 后，用户可以沿相关关键词继续扩展或收窄范围。

这会把首屏从“六张任务卡”改成真正可操作的发现入口。

Radar 内容底部同步增加一个醒目的 Explorer 收尾入口，复用当前任务目标。用户即使浏览完全部雷达榜单，也能明确知道下一步是进入 Explorer 继续筛选，而不会把页面末尾误认为探索终点。

4.2 修正任务路径生成

• 项目必须至少命中一个任务语义词，类别只作为加分项，不能独立召回；
• 任务总数使用有效语义候选计算；
• 每条路径输出四种互补候选：综合推荐、生产候选、近期活跃、隐藏宝石；
• 各轨道优先去重和保持子类多样性；
• 保留纯派生方案，不修改 data/projects.json。

4.3 引入“选型偏好”而不只是排序

Explorer 增加四个用户可理解的选型镜头：

选型镜头	主要信号	适用场景
综合推荐	相关度、探索分、成熟度、活跃度	不确定从哪里开始
生产优先	成熟度、Stars、持续更新、聚焦度	技术选型和团队评估
最近活跃	更新时间、新收录、探索分	跟进生态变化
隐藏宝石	高探索分、高聚焦、较低 Stars	发现尚未过度曝光的项目

选型镜头进入 URL，并由搜索 Worker 和主线程回退逻辑使用同一套规则。

4.4 动态“继续缩小”建议

根据当前结果实时统计最有代表性的子类和标签，展示带数量的下一步筛选项。它们不是全局热门，而是针对当前查询生成，例如：

继续缩小：Agent Frameworks 82 · Browser Automation 31 · MCP 46 · Multi-Agent 28

用户每点击一次，结果和下一步建议都会继续更新，形成渐进式探索。

4.5 升级解释型短名单

将现有“选型简报”升级为“推荐起点”：

• 根据当前选型镜头生成 3 个不同角色的候选；
• 每个候选显示明确理由，而不是只展示一个分数；
• 增加“一键加入对比”；
• 推荐尽量保持项目或子类多样性，避免三个项目高度重复。

4.6 项目卡片与详情强化推荐原因

项目卡增加一条紧凑的“推荐理由”，可能来自：

• 当前搜索命中字段；
• 当前选型镜头；
• 高成熟度、近期活跃或高聚焦信号；
• 与当前任务的分类/标签匹配。

详情中的相关项目增加关系说明，例如“同属 Agent Frameworks”“共享 MCP / automation”。同时补充键盘关闭、焦点恢复和对话框语义。

4.7 移动端改为筛选底部面板

• 主结果页只显示“筛选”按钮、已选条件和结果数量；
• 点击后打开可滚动的底部筛选面板；
• 面板底部提供“查看 N 个结果”动作；
• 打开面板时锁定背景滚动，支持遮罩和 Escape 关闭；
• 保证首条推荐与首条结果在移动端快速可见。

4.8 连续探索

Saved 页面新增“继续探索”：

• 从收藏和最近浏览的相关项目中聚合候选；
• 排除已经收藏或浏览的项目；
• 展示推荐来源：“因为你看过 X”；
• 按探索信号和来源频次排序。

5. 视觉与交互方向

保留当前米白纸张、墨色、绿色信号、衬线标题与等宽数据标签的“编辑部项目雷达”气质，不进行泛化的渐变卡片换皮。

调整重点：

• 让绿色只承担“可行动、被选中、推荐信号”，减少平均分配；
• 首屏形成明确的左侧目标选择、右侧推荐输出，而不是六张等权卡片；
• 结果页用层级区分“选型镜头、推荐起点、继续缩小、完整结果”；
• 卡片内容从“字段罗列”改成“项目价值 → 推荐理由 → 证据信号 → 下一步动作”；
• 移动端减少同时暴露的控件，优先呈现推荐与结果；
• 所有交互元素补齐可见焦点态、触摸尺寸和 reduced-motion；
• 长列表卡片使用 content-visibility 降低渲染成本。

6. 成功指标

若后续接入轻量匿名事件统计，建议关注：

指标	说明	期望方向
首次有效动作时间	打开页面到选择目标、搜索或打开项目详情	降低
首屏到项目详情转化	Radar 访问后打开详情的比例	提升
短名单使用率	一键加入对比或手动加入对比的会话占比	提升
结果收敛深度	每次会话使用的筛选/继续缩小次数	适度提升
零结果恢复率	零结果后通过放宽条件继续探索的比例	提升
相关项目点击率	详情中继续打开相关项目的比例	提升
回访连续探索率	Saved/最近浏览用户继续打开新项目的比例	提升

本轮无埋点时可用以下产品验收替代：

• 每条任务路径候选数显著低于全库规模，并有清晰差异；
• 每条任务路径四个轨道均能稳定给出候选；
• 390px 移动端进入 Explorer 后不再先铺满全部筛选项；
• 任意有结果的查询都能给出解释型短名单和动态缩小建议；
• 用户可一键把推荐短名单加入对比；
• 相关项目展示共享关系说明；
• 键盘可聚焦主要控件、用 Escape 关闭详情/筛选面板；
• 构建、数据生成及桌面/移动端浏览器验证通过。

7. 能力边界与后续演进

当前推荐是基于分类、标签、topics、描述、Stars 与时间的规则系统，不是向量语义检索，也没有 Stars 增长、release、issue、license、语言和部署成本等完整选型信号。这些内部信号只用于排序，页面应优先展示用户可验证的项目信息，避免宣称项目已被证明生产可用或未来一定高潜。

后续优先级：

1. 引入受控分面标签并支持同分面 OR、跨分面 AND；
2. 为相关项目保留相似度分数和理由，减少前端重复推导；
3. 记录历史快照，计算真实活跃趋势和 Stars 增速；
4. 增加 license、language、self-hosted、部署复杂度等决策字段；
5. 在静态规则效果稳定后，再评估 embedding / Meilisearch 向量搜索；
6. 增加轻量匿名埋点，用真实发现路径持续调整任务、镜头和推荐权重。

8. 数据发布流程

npm run publish 会在文档生成与构建之前先执行 npm run explore:generate-data。因此每次正式发布都会基于当时的 data/projects.json 自动刷新 Explore 的目录、分面、任务路线、相关项目和搜索索引，不再需要手动运行单独的数据生成命令。

9. 页面文案原则

Explore 的推荐规则与评分只用于后台排序，不在页面中直接展示“探索分”“成熟度”“聚焦度”等内部指标。用户可见文案保持简短，只呈现项目类型、Stars、更新时间、标签和明确操作。

• 标题直接说明内容，例如“你想找什么？”“按分类浏览”“推荐项目”；
• 操作直接使用“查看全部”“加入对比”“筛选”等常见表达；
• 不使用“任务语义”“赛道信号”“选型镜头”“继续收敛”等内部术语；
• 不重复解释已显示的信息，例如同一张卡片不再重复说明 Stars 和更新时间；
• 推荐原因优先使用搜索命中、同类关系和收藏来源等用户可验证的信息。