# v7.4.1 Input 文档 > **版本**：v7.4.1 > **功能名**：其他社媒搜索 - Twitter/X 搜索与频道详情页 > **状态**：✅ Input 已完成（已与当前 session 结论对齐） > **文档定位**：当前共识草案，只记录已确认事实、当前意图、待确认项 > **前置背景**：[@v740_background.md](./v740_background.md) --- ## 一、文档使用说明 本文档不是方案定稿，也不是 Spec。 当前阶段只做三件事： 1. 记录已经确认的旧版事实，避免后续讨论建立在错误基线上。 2. 记录本次迭代的真实意图，避免 AI 直接把“要做什么”误写成“已经决定怎么做”。 3. 把待确认的数据、计算口径、后续版本事项单独下沉，避免混入本期范围。 为避免混淆，本文档中的内容分为三类： - **已确认事实**：来自现有版本界面、当前讨论、已有内部材料，可作为当前基线。 - **当前意图**：本轮已达成的方向性共识，是后续 Spec 的输入。 - **待确认项**：需要与数据组、设计或后续版本再核的内容，当前不写死。 --- ## 二、740 基线事实 ### 2.1 旧框架 **已确认事实** - `740` 已经存在「其他社媒搜索」这套页面框架。 - 当前页面包含：平台切换、搜索框、搜索框附近一级筛选、筛选抽屉、结果列表。 - `741` 搜索侧继续沿用这套旧框架，不重做整页骨架。 ### 2.2 740 的 Twitter 本质 **已确认事实** - `740` 的 Twitter 区块不是站内 Twitter 能力，而是站内结果中的一层 Twitter 外壳展示。 - 结果卡左侧展示 Twitter 占位头像和 `@handle`。 - 卡片右侧展示的近期内容不是 Twitter 内容，而是关联平台内容。 - 用户点击头像、名称、`@handle` 后，会跳转到站外 Twitter/X，而不是 Nox 站内详情页。 - 因此，`740` 的 Twitter 链路本质上是： - 站内暴露关联信息 - 站外完成深看 ### 2.3 740 与 741 的继承关系 **已确认事实** - `741` 只改 Twitter 这条链路。 - Facebook 在 `741` 中保持 `740` 现状不动。 - `741` 不是重做“其他社媒搜索”产品，而是在旧框架内替换 Twitter 能力内核。 --- ## 三、741 为什么现在做 ### 3.1 触发原因 **当前意图** 本次 `741` 被提上来，优先级判断为： 1. 销售与客户已经明确在要 Twitter 搜索与详情能力。 2. 真实 Twitter 数据能力已经具备一定基础，不产品化会造成浪费。 3. `740` 的站内 Twitter 体验过于占位化，已无法承接真实业务需求。 ### 3.2 本次迭代的本质 **当前意图** `741` 的本质不是“给旧卡片多补几个字段”，而是把 Twitter 这条链路从： - `740`：站内关联展示 + 站外跳出查看 升级为： - `741`：站内可发现 + 站内可深看 --- ## 四、741 的整体拆分 ### 4.1 三段目标 **当前意图** 本次 `741` 拆为三个层次理解： 1. **741-1 搜索侧升级** - 在旧框架内，把 Twitter 搜索从桥接/关联展示切换为真实 Twitter 对象搜索。 - 同时补齐搜索结果真实展示与筛选能力。 2. **741-2 详情侧新建** - 从 0 建立站内 Twitter 频道详情页。 - 它是标准频道详情页，不是搜索附属页。 3. **741-3 流程补环** - 在搜索与详情基本能力明确后，回头检查整条链路还缺哪些必要闭环。 - 当前阶段先把必要动作锚点记录出来，不强行扩写后续版本内容。 --- ## 五、741-1 搜索侧输入 ### 5.1 搜索对象与框架 **已确认事实** - `741` 搜索侧继续沿用 `740` 的页面框架。 - 结果页整体仍保留旧框架下的混合/并列结构。 **当前意图** - Twitter 搜索对象切为真实 Twitter 账号。 - 不再依赖 YouTube 桥接逻辑作为 Twitter 搜索主体。 - Twitter 区块要从“Twitter 外壳 + 非 Twitter 主数据”改为“真实 Twitter 结果卡”。 ### 5.2 搜索结果主任务 **当前意图** `741-1` 搜索结果页的第一任务是：**发现可用账号**。 对应地，搜索结果页优先承担： - 让用户知道有哪些 Twitter 账号可选。 - 让用户快速识别账号的大致价值。 - 让用户判断是否值得进入详情页深看。 它不是第一步就做深度评估，也不是先做最复杂筛选。 ### 5.3 搜索结果卡片主信息 **当前意图** Twitter 结果卡第一版最不能缺的信息包括： - 头像 - 频道名 / 别名 - 频道类别 - 频道地区 - 粉丝数 - 内容总数 - 平均互动率 - 预估曝光量 如果还有空间，补充近期贴文预览。 ### 5.4 近期贴文预览方式 **当前意图** Twitter 结果卡中的近期贴文预览采用混合策略： - 有媒体时，优先展示缩略图。 - 无媒体时，展示 Tweet 文本卡。 目标不是照搬 Instagram 的纯图片结果，而是在 Twitter 语境下兼顾内容感与信息密度。 ### 5.5 搜索结果跳转入口 **当前意图** 从搜索结果进入 Twitter 详情页的主入口限定为： - 头像 - 频道名 - `@handle` 不把整张卡片都设计成详情页跳转入口。 ### 5.6 搜索筛选结构 **当前意图** 搜索框附近展示三个主筛选项，参考现有 Instagram 搜索： - 频道类别 - 频道地区 - 粉丝量 完整筛选项全集放在筛选抽屉中。 ### 5.7 抽屉筛选全集 **当前意图** 频道组： - 语言 - 最后更新日期 - 平均互动率 - 预估曝光量 - 平均观看量 - 平均点赞量 - 平均收藏量 - 平均评论量 受众组： - 受众地区 - 受众年龄 - 受众性别占比 - 受众语言 ### 5.8 搜索侧边界说明 **已确认事实** - Facebook 不在本期修改范围内。 **当前意图** - 受众组筛选保留在筛选抽屉中，但本期不交付真实筛选能力。 - 受众组筛选整组置灰，并以 `敬请期待` 占位曝光承接。 - 搜索结果默认按综合排序理解，而不是单纯按最新或热度排序。 - 无搜索条件时，结果列表展示默认推荐/热门账号列表，而不是独立榜单页。 --- ## 六、741-2 详情侧输入 ### 6.1 详情页定位 **当前意图** - Twitter 详情页是标准频道详情页。 - 它与 YouTube / TikTok / Instagram 频道详情页同等级。 - 它不是搜索结果的展开层，也不是一个临时补充页。 ### 6.2 主要参考对象 **已确认事实** - 第一优先参考对象是现有 Instagram / TikTok 频道详情页。 - YouTube 详情页可作为平行参考，但不是第一主参考。 ### 6.3 详情页主框架 **当前意图** Twitter 详情页沿用现有社媒频道详情页骨架，保留四分区结构： - 数据总览 - 受众数据 - 内容数据 - 品牌数据 其中本期正式交付聚焦： - 数据总览 - 内容数据 其中本期以占位曝光承接： - 受众数据 - 品牌数据 ### 6.3A 详情页访问方式 **当前意图** - 详情页主入口仍来自搜索结果卡中的头像、频道名、`@handle`。 - 本期支持详情页直达访问。 - 直达访问来源包括搜索结果页、分享链接、其他模块对 Twitter 详情页的引用链接等任意有效入口。 - 当前阶段不写死 URL 结构与主键方案，只要求链接可唯一定位账号。 - 不可识别 / 非法路由参数走 404。 - 账号存在但暂无可展示数据时，走产品级空态，不走 404。 ### 6.4 分区优先级 **当前意图** 第一版优先级为： - 第一优先：数据总览 - 第二优先：内容数据 - 第三优先：受众数据（占位曝光） - 第四优先：品牌数据（占位曝光） 这里的含义不是把受众数据或品牌数据做重，而是允许本期分区在第一版呈现**非对称深度**。 ### 6.5 页头摘要指标 **当前意图** 页头摘要指标属于全局层，**不算在“数据总览” tab 内**，且必须要做。 当前最不能缺的四个指标： - 粉丝量 - 最近发布时间 - 平均曝光量 - 平均互动率 其中： - `平均曝光量` 暂以“平均近期内容曝光量”理解，暂不锁死最终计算口径。 - `平均互动率` 页头层优先表达近期内容视角，账号总体层面的互动表现可在下层模块展开。 ### 6.5A 数据时效与趋势口径 **当前意图** - 账号基础信息与趋势数据按 T+1 日更口径理解。 - 互动率与最近 Tweet 数据按详情页请求时读取最新已采集数据。 - 粉丝趋势默认基于天级历史数据表展示近 30 天趋势。 ### 6.6 数据总览分区 **当前意图** 第一版最不能缺的模块： - 基本数据的核心指标卡 - 增长数据 **待确认项** - 频道质量 - 合作价格 / CPM 这两类区域依赖数据组额外计算，当前不默认作为第一版必做项。 ### 6.7 内容数据分区 **当前意图** 第一版最不能缺的模块： - 基本数据 - 内容标签 - 发布时间频率分析 - 全量内容列表 + 筛选 #### 全量内容列表 筛选： - 发布日期 - 文字内容匹配 排序： - 按发布日期 - 按点赞量 - 按评论量 - 按互动率 默认排序： - 默认按发布日期倒序。 展示方式： - 采用高信息密度卡片流，而不是纯表格或纯原生 Tweet 长列表。 单条 Tweet 卡片最不能缺的元素： - 正文摘录 - 首图（如果有） - 发布日期 - 观看量 - 点赞量 - 评论量 ### 6.8 受众数据分区 **当前意图** - 第一版保留 `受众数据` 这个 tab 的结构位，并正常可点击进入。 - 但该分区当前不交付真实受众画像能力，只做明确占位曝光。 - 占位页与品牌数据共用同一套模板，只更换标题。 ### 6.9 品牌数据分区 **当前意图** - 第一版保留 `品牌数据` 这个 tab 的结构位。 - 但该分区当前不交付真实品牌能力，只做明确占位曝光。 - 它不是 `741` 这一版的关键交付重点。 - 占位页与受众数据共用同一套模板，只更换标题。 --- ## 七、流程闭环与后续动作 ### 7.1 本期主闭环 **当前意图** `741` 第一版优先做顺这条链路： - 搜索发现 Twitter 账号 - 进入站内 Twitter 详情页 - 看懂账号与内容表现 - 支持判断是否值得进一步跟进 ### 7.2 必要动作锚点 **当前意图** 虽然本期主交付重心是“发现 + 深看 + 判断”，但以下动作仍然是这条链路中的必要锚点： - 收藏 - 联系网红 ### 7.3 当前处理方式 **当前意图** - 收藏动作默认沿用已有收藏逻辑。 - 是否支持对 Twitter 频道对象执行收藏，交由后续版本承接。 - 联系网红应在文档中保留为后续版本 TODO。 - 本期不强行扩写完整商务动作闭环。 --- ## 八、当前参考锚点 ### 8.1 内部旧版与平行功能 **已确认事实** - `740` 旧版结果页：提供了当前要被替换的 Twitter 链路基线。 - Instagram 搜索结果页：是 `741-1` 搜索结果信息分层和筛选结构的重要参考。 - Instagram / TikTok 频道详情页：是 `741-2` 详情页四分区骨架的重要参考。 ### 8.2 当前参考原则 **当前意图** - 搜索侧优先参考 Instagram 搜索结果的卡片分层与筛选布局。 - 详情侧优先参考 Instagram / TikTok 详情页的页面骨架。 - 参考是为了复用成熟结构，不意味着直接照抄平台数据模块。 --- ## 九、待确认项 ### 9.1 数据与字段 - 搜索卡片与详情页各模块的实际字段清单是否全部可用。 - 平均曝光量的最终计算口径。 - Tweet 内容字段对“文本卡 / 媒体卡”两种展示的支持程度。 - 详情页 URL 结构最终采用 `handle`、`ID` 还是混合方案。 ### 9.2 详情页能力边界 - 数据总览中是否存在第一版可交付的“频道质量”替代方案。 - 品牌数据 tab 是否有最低可交付内容，而不只是空占位。 ### 9.3 交互与闭环 - Twitter 频道对象何时接入现有收藏能力。 - 联系网红动作在后续版本由哪一条产品链路承接。 --- ## 十、参考资料 | 文档 | 路径 | 说明 | |------|------|------| | v7.4.0 背景 | [v740_background.md](./v740_background.md) | 前置版本决策记录 | | Twitter 数据字段 | [twitter_data_fields.md](./twitter_data_fields.md) | 已整理字段与样例 | | 数据样例 | [twitter_data_sample_raw.json](./twitter_data_sample_raw.json) | 账号数据样例 | | 推文样例 | [twitter_tweet_sample_raw.json](./twitter_tweet_sample_raw.json) | 推文数据样例 | | 执行计划 | [_plan.md](./_plan.md) | 当前执行进度 | --- ## 十一、Changelog | 日期 | 版本 | 变更内容 | 作者 | |------|------|----------|------| | 2026-03-16 | v1 | 初始版本（仅搜索功能） | Claude | | 2026-03-16 | v2 | 扩展为搜索 + 详情页合并版 | Claude | | 2026-03-17 | v3 | 按五层结构重组 | Claude | | 2026-03-18 | v4 | 基于当前共识重写：按“已确认事实 / 当前意图 / 待确认项”重构 Input | Codex | | 2026-03-19 | v4.1 | 与当前 session 对齐：受众/品牌改为占位曝光、详情页支持多入口直达且不写死主键方案 | Codex |