# 频道搜索 Agent 化改造 · 交互设计规格 v1 | 属性 | 内容 | |---|---| | 模块名称 | channel_search_agent_upgrade | | 文档阶段 | Design | | 状态 | Draft v1 | | 关联 Spec | spec_v1.md | | 创建日期 | 2026-03-19 | --- ## 一、设计总原则 本次设计采用一个核心策略： `外部稳定，内部惊喜` 展开解释： - 搜索框外：保持现有 Nox 搜索页骨架与效率感 - 搜索框内：当进入 Agent 模式时，局部切换到更独立、更 AI 风格的视觉与交互状态 这意味着本次设计不是全页 AI 化，也不是做一个聊天产品，而是： `把搜索框变成一个会思考、会继续追问、但仍然像搜索框的主控件` ## 设计维护约束 - 当前阶段虽然主要通过 Demo 推进讨论，但 Design 文档必须持续跟进 Demo 的稳定结论。 - 不允许出现“Demo 已经演化，但 Design 仍停留在旧状态定义”的情况。 - 若 Demo 改动涉及状态、层级、视觉语义或控件职责变化，必须同步更新本文件。 - 当前 Demo 中若已经显式展示 Agent 输出槽位，则命名必须与 `agent_response_contract_v1.md` 保持一致。 - 当前阶段 Demo 默认固定使用 `B AI 材质型`，其余视觉方案先隐藏，待搜索框内部交互与状态收敛后再重新开放皮肤比较。 --- ## 二、主控件骨架 ### 2.1 组件定义 搜索框升级为 `可原位扩展的搜索容器`，内部固定包含四层： 1. `输入层` 2. `会话层` 3. `追问层` 4. `条件层` 四层全部位于同一容器内部，不拆出独立面板。 ### 2.2 默认收起态 收起态尽量接近当前搜索框心智： - 保留搜索 icon - 保留平台上下文 - 保留主输入区 - 右侧保留核心操作按钮 但相比旧搜索框，需预留更明显的可扩展空间感。 ### 2.3 展开态 当用户输入自然语言并触发 Agent 搜索后，搜索框在原位向下扩展。 展开后的视觉目标： - 第一眼仍被认知为“搜索框” - 第二眼发现其内部已经进入“智能搜索模式” ### 2.4 兼容态总览 搜索框在视觉上不是只有“收起 / 展开”两种，而是至少有五种感知态： 1. `经典收起态` 2. `URL 识别态` 3. `Agent 展开初始态` 4. `Agent 追问态` 5. `Agent 修正态` 其中： - `关键词` 默认停留在 `经典收起态` - `URL` 默认先进入 `URL 识别态` - `自然语言 / 混合输入` 才进入完整 `Agent 展开态` --- ## 三、视觉策略 ### 3.1 搜索框外部：保持原状 默认保持不做结构性重做的区域： - 顶部导航 - 页面背景 - 搜索框以下的结果列表骨架 - 排序区 - 搜索框外的大部分筛选器位置 目的： - 保持用户熟悉感 - 保持信息密度 - 保持专业搜索工具心智 ### 3.2 搜索框内部：局部 AI 化 展开态内部允许做明显 AI 风格异化，重点通过 `材质与层次` 表达： - 更独立的容器边界 - 更有层次的内部卡片 - 更强的表面材质差异 - 局部高亮、柔和光感或边界辉光 - 更清晰的状态层与条件层区分 不建议通过以下方式制造 AI 感： - 大量聊天气泡 - 过重拟人文案 - 大面积全屏渐变 - 全页样式同步变色 ### 3.3 惊喜感的来源 惊喜感应来自这条体验： 1. 用户进入页面时，仍觉得这是熟悉的搜索页 2. 用户输入自然语言后，搜索框在原位展开 3. 展开后的搜索框内部材质、边界、层级明显变化 4. 用户感受到“我进入了一个更聪明的模式”，但周围页面没变 --- ## 四、四层结构细化 ### 4.1 输入层 职责： - 承接首输 - 承接追加要求 - 承接用户对追问的回答 设计要求： - 输入区永远在视觉上最强 - 即使处于追问态，用户也仍在同一输入区作答 - 输入框不切换到聊天消息流样式 #### 输入层的兼容要求 - **关键词模式** - 输入层外观与当前搜索框尽量一致 - 不因为输入一个短关键词就突然长高 - 必须保留 `输入态 -> 完成态 tag` 的编辑器语义 - 已有 tag 进入编辑时，应被理解为 `editing_keyword`，而不是新建一个普通 draft - 经典态允许 `多个关键词 tag + 一个 anchor badge + 一个尾部输入位` 的组合编辑形态 - **URL 模式** - 输入层在提交后进入短暂 `识别中` 状态 - 如识别成功，优先以轻量反馈结束，不强制展开 - 精确识别成功后，输入层应收敛为 `committed_anchor` - **自然语言模式** - 输入层在提交后成为展开态的主锚点 - 用户后续回答追问仍回到这里输入 - 原始 query 被系统吸收后，输入层应切换为 `followup_waiting` - **混合模式** - 输入层需要支持展示“原始输入 + 已拆解摘要”的双重感知 - 若存在精确 URL 锚点，稳定中间态应表现为 `committed_anchor + followup_waiting` ### 4.2 会话层 职责： - 呈现当前任务摘要 - 呈现平台上下文 - 呈现系统当前动作 建议内容： - `当前在搜：YouTube 频道` - `系统已理解：美国 / 汽配 / 5k-20k / 近期活跃` - `正在根据新增条件刷新结果` 设计要求： - 是搜索框内部的状态反馈，不是消息气泡 - 视觉弱于输入层，强于静态说明文案 ### 4.3 追问层 职责： - 在必要时抛出一个高价值澄清问题 设计要求： - 一次只出现一个问题 - 追问可搭配轻量建议按钮 - 追问不应占据过高空间 - 追问看起来像搜索系统在求补充，而不是聊天机器人在闲聊 ### 4.4 条件层 职责： - 持续展示结构化条件 - 让用户理解当前结果是怎么来的 建议结构： - 用户明确条件 - Agent 推断条件 - 手动补充条件 设计要求： - conditions 必须易扫读 - 可删除、可修改、可冲突提示 - 来源差异需要有视觉区分，但不能过花 --- ## 五、关键状态设计 ### 5.1 默认收起态 - 与现有搜索框最接近 - 未进入 AI 模式 - 服务于 `纯关键词` 与大多数 `纯 URL` 起搜路径 #### 视觉要求 - 保持现有搜索框尺寸和节奏 - 只允许增加极轻量的智能提示，不抢原功能心智 #### 关键词编辑器语义 默认收起态下，关键词输入区本身就是一个轻量查询编辑器，而不是单纯文本框。 需支持： - 正在输入的关键词文本 - 已完成的关键词 tag - 多个 tag 并列 - 光标始终处于最后一个可输入位 关键词完成态 tag 建议结构： - 左侧：关键词文本 - 中部：分隔线 - 右侧：匹配目标文案 + 下拉箭头 若开启排除： - 该 tag 在颜色、边框或标识上必须明显变化 - 但不应破坏整行排版稳定性 #### 经典态去说明化 结合当前 Demo 迭代结论，经典态需要进一步收敛为“查询编辑器”而不是“带说明的组件面板”： - 不应长期显示解释性副文案 - 不应常驻同时出现多个高权重按钮 - 不应在经典态中加入与查询编辑无关的状态块 - 经典态的注意力中心只能是： - 搜索 icon - tag / 输入文本 - 当前光标 ### 5.2 展开初始态 - 搜索框开始扩展 - 会话层与条件层出现 - 内部材质切换 #### 触发规则 - 用户提交纯自然语言 - 用户提交混合输入 - 用户在经典搜索后主动选择转为智能搜索 ### 5.2A URL 识别态 - 这是介于经典态与完整展开态之间的 `短态` - 视觉目标不是“进入 AI 模式”，而是“系统正在快速确认这个链接” #### 视觉要求 - 高度只轻微增加 - 输入框下方出现一条状态带，而不是完整四层容器 - 状态带可使用： - 识别中 spinner - 平台图标 - 极短说明文案 - 材质变化应明显弱于完整展开态 #### 结束方式 - 识别成功：快速退回经典结果浏览节奏 - 识别失败或需修正：升级为 `URL 修正态` ### 5.3 首轮召回进行中 - 搜索框内给出明确 loading 状态 - 外部结果区开始刷新，但注意力仍停留在搜索框 ### 5.4 首轮召回完成 - 会话层显示当前已理解内容 - 条件层固定下来 - 结果区同步稳定可看 - 不再显示 loading 动画 - 应切换为稳定态提示，而不是继续制造“系统仍在处理中”的误导 ### 5.5 搜索框内追问态 - 追问插入搜索框内部 - 用户直接在同一输入区回答 - 这是稳定态，不应继续显示 loading #### 视觉要求 - 追问像“搜索系统请求补充”，不是消息气泡 - 追问区应贴近输入层，形成连续任务感 - 输入光标的焦点必须仍在搜索框内 ### 5.6 条件冲突态 - 冲突条件高亮 - 给出“删除某条件 / 放宽某条件 / 回答一个追问”三类建议之一 ### 5.7 有条件无结果修正态 - 搜索框内部展示修正建议 - 外部结果区不承担主要修正说明 - 这是稳定态，不应继续显示 loading ### 5.7A URL 修正态 - 仅在 URL 无法识别、平台不匹配或类型不支持时出现 - 视觉上比完整 Agent 态更轻 - 重点是帮助用户修正 URL，而不是把 URL 搜索强行转成聊天搜索 #### 推荐文案气质 - `未识别到可用频道链接` - `该链接属于 Instagram，当前页面为 YouTube 频道搜索` - `当前版本暂不支持用该类链接起搜` 避免： - `我不太明白你的意思` - `我们再聊聊你想找什么` --- ## 六、关键词 Tag 编辑器与混合输入视觉表达 ### 6.1 关键词输入态 输入态应接近你补充的旧版截图语义： - 没有 tag 的内容直接显示为文本输入 - 视觉中心仍然是光标和文本本身 - 搜索 icon、平台切换、频道/视频切换保持原有节奏 ### 6.2 关键词完成态 完成态关键词转为 pill/tag 后，应满足： - 与输入态明显不同 - 但仍然属于同一个搜索框内部 - tag 更像“查询片段”，而不是通用筛选器 chip - tag 需要更轻、更扁、更低对比 - tag 不应有明显按钮感或组件库 chip 感 ### 6.3 多关键词并列 多关键词并列时： - tag 间距和高度要稳定 - 新输入位必须清楚 - 不应因为 tag 增多立刻把搜索框做成“复杂表单” ### 6.4 匹配目标下拉 匹配目标下拉建议作为单个关键词 tag 的附属弹层： - 当前选项高亮 - 文案按来源语义直给 - 底部单独放 `排除该关键词` 开关 - 弹层位置必须紧贴当前 tag，不应像远离锚点的独立 popover - 用户应感知为“tag 长出了菜单”，不是“页面弹出设置框” ### 6.5 排除态 排除态不建议只靠一个小开关表达，tag 本体也应同步变化，例如： - 更深边框 - 反相底色 - 小型“排除”标识 ### 6.5A 经典态与展开态的语义分界 当前迭代要求两类气质严格分离： - 经典态： - 极简 - 快 - 连续输入感强 - 几乎没有面板感 - 展开态： - 才允许逐步引入 AI 材质、层次、状态反馈 因此，展开态的卡片语义不得反向污染经典态。 ### 6.6 会话层的“解析先行”原则 混合输入进入展开态后，第一屏不应直接塞满追问，而应优先展示系统解析摘要。 建议顺序： 1. 当前锚点 2. 已生效硬条件 3. 作为参考的软条件 4. 如有必要，再抛一个追问 ### 6.7 锚点可视化 当混合输入中存在高优先级锚点时，搜索框内部应有明显锚点卡： - `URL 锁定频道` - `已识别频道名` - `当前平台锚点` 锚点卡视觉要求： - 比普通条件 chip 更稳定 - 不应与可随意删除的普通条件看起来完全一样 ### 6.8 软条件可视化 软条件不应伪装成已经严格生效的过滤器。 建议样式： - 作为 `参考偏好` 单独分组 - 视觉弱于硬条件 - 可在旁边标注： - `参考` - `待澄清` - `已推断` ### 6.9 混合输入中的追问时机 混合输入场景下，追问要更克制。 优先顺序应为： 1. 先解释系统怎么理解输入 2. 先给一轮结果 3. 只在影响很大时补一个问题 不建议： - 一进入展开态就连续抛两个以上问题 - 在用户已经给了 URL 锚点时，立刻把会话推成开放式聊天 ### 6.10 经典态升级为 Agent 态的视觉路径 这是当前阶段必须显式设计的两条路径： 1. `关键词起手 -> 升级为 Agent 态` 2. `URL 起手 -> 升级为 Agent 态` 这两条路径的共同原则： - 升级前已提交的查询片段不能消失 - 新触发升级的自然语言不能简单继续堆在原输入框里 - 升级后必须同时保留： - 已提交片段 - 一个新的可输入位 - 系统对当前任务的解释 #### 关键词起手升级 - 升级前：关键词 tag 是主角 - 升级中：关键词 tag 保留，新增自然语言被系统吸收进解释层 - 升级后：关键词 tag 变成前置显式条件，任务摘要与条件层进入搜索框内部 #### URL 起手升级 - 升级前：URL 是精确锚点 - 升级中：系统先说明 URL 仍然是不是主锚点 - 升级后：URL 以 anchor 形式保留，自然语言被拆成硬条件/软偏好/追问 ### 5.8 unsupported / sensitive - 搜索框内部清晰提示 - 保持专业克制，不做强烈错误弹窗 ### 5.9 历史恢复态 - 恢复任务摘要 - 恢复条件层 - 恢复搜索框展开状态 --- ## 六、材质与层次建议 ### 6.1 容器层 - 收起态：贴近现有搜索框 - 展开态：边界更完整，像一个独立智能模块 建议变化维度： - 边框厚度或亮度提升 - 阴影更有悬浮感 - 背景从普通纯色切到更有质感的浅层材质 ### 6.2 内部卡片层 搜索框内部各层不应只靠分隔线区分，建议采用轻卡片分层： - 会话层：最轻 - 追问层：中等强调 - 条件层：最稳定、最结构化 ### 6.3 光感与高亮 可使用局部 AI 感高亮，但要克制： - 只在搜索框展开态内部使用 - 不外溢到结果区和整页背景 - 用于表达“系统正在思考/更新/理解” --- ## 七、关键词 / URL / 自然语言的视觉兼容 ### 7.1 关键词模式 关键词模式应表现为： - 外观几乎等于经典搜索框 - 内部不出现复杂会话卡片 - 可在输入区下缘给一个很轻的提示入口，如： - “补充地区、粉丝量等可进入智能搜索” ### 7.2 URL 模式 URL 模式应表现为： - 提交后短暂进入 `识别中` - `识别中` 阶段保持轻量，不展开成完整 Agent 会话层 - 若识别成功，不进入完整 Agent 态，而进入一个 `锚点搜索就绪` 的轻解释态 - 该轻解释态允许搜索框高度轻微增加，但不应膨胀成自然语言 / 混合输入那种多层会话结构 - 若识别失败，再升级为 `URL 修正态` #### URL 精确识别成功 - URL 精确识别成功后，不应继续以原始长链接作为主要输入表现 - 应收敛成一个 `anchor badge` - 该 badge 的视觉语义要与 `升级路径-URL起手` 系列状态保持一致 - 用户应感知为： - “这条 URL 已被系统识别成一个确定频道” - 而不是“输入框里还躺着一串等待继续处理的原始链接” - 成功识别后的搜索框内部，允许出现一个轻量但完整的解释层： - `status` - `task_summary` - 必要时的 `conditions` - 其中： - `status` 用于说明“锚点搜索已就绪” - `task_summary` 用于说明“当前按哪个频道作为锚点、正在做什么召回” - `conditions` 用于说明锚点与默认排序等结构化语义 - 这层解释必须明显轻于 Agent 展开态： - 不出现复杂追问卡片 - 不出现多层会话堆叠 - 不把 URL-only 误做成完整聊天态 - 结果区语义应表现为： - `锚点频道` 置顶 - 其余频道按相似程度默认排序 - 若存在“只查看该频道”的入口，应作为次级动作，而不是默认主结果语义 ### 7.3 自然语言模式 自然语言模式应表现为： - 搜索框明确展开 - 会话层、条件层、状态层快速显现 - 用户感知为“搜索框进入智能模式” ### 7.4 混合输入模式 混合输入模式应表现为： - 默认进入展开态 - 搜索框内部需要明确告诉用户系统当前怎样理解这串输入 - 尤其当输入同时包含 `URL + 自然语言` 时，需高亮当前优先级规则 #### 推荐排布 - 第一行：原始输入 - 第二行：系统解析摘要 - 第三行：锚点 / 硬条件 / 软条件 - 第四行：必要时的单个追问 --- ## 八、关键交互动线 ### 8.1 纯关键词 1. 用户输入关键词 2. 搜索框保持经典态 3. 返回结果 4. 用户若想继续缩小范围，可： - 用外部筛选器 - 在搜索框中补一句自然语言，升级为 Agent 态 ### 8.2 纯 URL 1. 用户输入 URL 2. 搜索框进入轻量识别态 3. 若识别成功，锁定锚点频道并进入相似频道召回 4. 若识别失败，进入搜索框内修正态 ### 8.3 纯自然语言 1. 用户输入自然语言 2. 搜索框展开 3. 首轮结果返回 4. 必要时在搜索框内追问 5. 用户继续 refine ### 8.4 混合输入 1. 用户输入关键词/URL + 自然语言 2. 搜索框展开 3. 会话层先解释当前解析结果 4. 条件层同步显示显式条件与推断条件 5. 结果区随当前 session 刷新 --- ## 七、与现有筛选器和结果区的关系 ### 7.1 与外部筛选器 - 外部筛选器继续存在 - 但其状态必须同步到搜索框内部条件层 ### 7.2 与结果区 结果区保持现有主节奏： - 浏览 - 比较 - 排序 - 批量操作 搜索框负责： - 控制 - 澄清 - 条件解释 ### 7.3 与 AI 语气 文案建议是 `轻助手增强`，不是强人格助手： - 多用“已理解”“建议补充”“可继续缩小范围” - 少用“我来帮你”“我猜你想要” --- ## 八、设计验收标准 - 用户从首输到追问回答，全程不离开搜索框 - 展开的搜索框内部明显更独立、更 AI 风格 - 搜索框外区域保持当前搜索页熟悉感 - 条件层始终存在且易懂 - 追问不演化成长聊天流 - 结果区不被主控件的展开态压迫到失去可读性