# 频道搜索 Agent 化改造 · 业务规格说明 v1

| 属性 | 内容 |
|---|---|
| 模块名称 | channel_search_agent_upgrade |
| 文档阶段 | Spec |
| 状态 | Draft v1 |
| 关联 Input | input_v1.md |
| 创建日期 | 2026-03-19 |

---

## 一、功能概述

本次迭代的目标是把频道搜索从：

`关键词 / URL / 显式筛选器 / 外挂式 AI 助手`

升级为：

`可原位扩展的 Agent 搜索框 + 条件透明 + 结果联动`

本期能力作用于各平台的 `频道搜索页`，以统一模块复用的方式接入 YouTube、Instagram、TikTok、X 等页面，但单次搜索仍只在当前平台的频道结果集中执行。

---

## 二、统一对象模型

### 2.1 Search Session

一次频道搜索任务的唯一上下文容器，承载：

- 用户原始输入
- 当前平台
- 当前结构化条件
- 当前派生条件
- 当前追问
- 当前结果状态
- 当前结果摘要

**规则**：
- 同一用户在同一平台页的一次连续搜索行为，只能存在一个激活的 `Search Session`
- Agent refine、手动筛选修改、结果刷新必须落在同一 session 中

### 2.2 Input Intent

用户在搜索框中提交的原始表达，支持四类：

| 类型 | 示例 |
|---|---|
| 关键词 | `swim vest` |
| URL | `https://www.youtube.com/@...` |
| 自然语言 | `帮我找美国做汽配评测、最近活跃、粉丝 5k-20k 的 YouTube 红人` |
| 混合输入 | `Hollyland 麦克风，美国，IG，粉丝 1w+，均播 3000+` |

### 2.3 Condition Graph

由系统将 `Input Intent` 映射为结构化搜索条件后的结果集合。

Condition Graph 至少包含三类节点：

- `Explicit Conditions`
  - 用户明确说出的条件
- `Derived Rules`
  - 系统根据用户意图推断出的隐式规则
- `Manual Conditions`
  - 用户通过显式筛选器或 chips 编辑后加入/修改的条件

### 2.4 Clarification Loop

当首轮召回后仍存在高影响歧义时，系统在搜索框内部发起的轻量追问机制。

### 2.5 Agent State

| 状态 | 含义 |
|---|---|
| `idle` | 未展开或未发起搜索 |
| `retrieving` | 正在执行首轮或后续搜索 |
| `results_ready` | 已有结果可浏览 |
| `clarifying` | 当前存在需要用户回答的追问 |
| `refining` | 用户回答追问或改条件后，系统正在刷新 |
| `empty_repair` | 有条件但无召回，进入修正引导 |
| `unsupported` | 不支持或敏感需求 |

---

## 三、输入与搜索执行规则

### 3.1 主流程

用户在搜索框中输入任意支持类型内容后：

1. 系统解析原始输入
2. 生成首轮 `Condition Graph`
3. 立即执行搜索
4. 返回首轮结果
5. 如存在高影响歧义，再进入 `Clarification Loop`

### 3.1A 输入类型兼容矩阵

| 输入类型 | 默认表现 | 是否自动展开为 Agent 模式 | 结果执行方式 |
|---|---|---|---|
| 纯关键词 | 兼容原搜索框心智 | ❌ 默认不展开 | 走原有关键词搜索路径 |
| 纯 URL | 先识别 URL 类型 | ❌ 识别成功时不展开；⚠️ 无法识别或需修正时展开 | 走 URL 识别 + 锚点相似频道搜索路径 |
| 纯自然语言 | 进入智能搜索模式 | ✅ | 先生成 Condition Graph，再执行首轮搜索 |
| 混合输入 | 进入智能搜索模式 | ✅ | 统一解析后执行首轮搜索 |

**设计原则**：

- 原始搜索框的 `关键词` 和 `URL` 能力必须继续可用
- `Agent 展开态` 不是新的唯一入口，而是针对自然语言与复杂混合输入的增强模式
- 不允许因为用户只输入一个关键词或一个 URL，就强制把所有人拉进复杂展开态
- 纯 URL 的默认结果语义统一为 `锚点搜索`

### 3.2 默认执行策略

- 默认策略固定为 `先搜后追问`
- 系统不得因为存在一般性模糊表达而阻塞首轮搜索
- 只有在无法继续产生有意义结果，或关键条件会显著改变结果集时，才允许进入 `clarifying`

### 3.3 老用户兼容规则

- 纯关键词输入不得被强制拉入多轮 AI 追问
- 纯 URL 输入仍按现有 URL 识别逻辑起搜，但识别成功后的默认结果语义改为锚点搜索
- 老用户在手动筛选器中修改条件时，不要求额外进入聊天式流程

### 3.4 关键词输入兼容规则

#### 3.4.1 纯关键词模式

- 当输入被识别为 `纯关键词` 时，搜索框保持 `收起态 / 经典态`
- 用户提交后直接执行原有关键词搜索
- 搜索结果区与原有排序、筛选、翻页逻辑保持一致

#### 3.4.1A 关键词的输入态与完成态

关键词输入采用两段式编辑：

| 状态 | 含义 | 表现 |
|---|---|---|
| `draft_keyword` | 当前正在输入、尚未固化的关键词文本 | 普通输入光标态 |
| `committed_keyword` | 已被确认并固化的关键词片段 | Tag / pill 形态 |

当 `draft_keyword` 被固化后：

- 当前词组转为一个独立 tag
- tag 与此前已存在的 tag 并列
- 输入光标回到新的空输入位，允许继续输入下一个关键词

#### 3.4.1B 完成态触发条件

以下动作可将当前 `draft_keyword` 固化为 `committed_keyword`：

- 用户按 `Enter`
- 输入框失去焦点
- 用户点击搜索或其他会触发搜索的提交动作，且当前输入非空

#### 3.4.1C 多关键词并列规则

- 搜索框必须支持多个 `committed_keyword` 并列展示
- 每个关键词 tag 独立存在
- 任一 tag 可单独编辑、删除、改匹配目标
- 搜索框末尾始终保留一个继续输入的新光标位

#### 3.4.1C-2 经典态中的关键词 + URL 复合种子

经典态下，搜索框还应允许形成一个复合查询种子：

- `0..n` 个 `committed_keyword`
- `0..1` 个 `committed_anchor`
- `1` 个尾部 `draft_keyword`

解释：

- 用户可以先输入若干关键词
- 再插入一个精确 URL / 频道锚点
- 然后继续输入下一个关键词

约束：

- `committed_anchor` 最多只能存在一个
- 该形态仍属于 `compact_classic`
- 不因出现 `关键词 + URL` 组合就自动升级为 Agent 态
- 只有当用户继续补充自然语言任务描述时，才允许进入升级路径

#### 3.4.1C-1 已有关键词的编辑

- 点击一个已有关键词 tag 时，必须允许进入 `editing_keyword`
- `editing_keyword` 的语义是“正在修改这个已有 tag”，不是“新建一个 draft 词”
- 编辑提交后回到 `committed_keyword`
- 编辑取消后恢复原 tag
- 若编辑中被清空并确认删除，则：
  - 若仍有其他 tag，输入层回到 `committed_keyword`
  - 若这是最后一个 tag，输入层回到 `empty_input`

#### 3.4.1D 每个关键词的匹配目标

每个 `committed_keyword` 都必须支持单独配置匹配目标，候选项为：

- 按频道标签
- 按频道名
- 按频道简介
- 按发布内容
- 从全部来源

默认值：

- 若用户未主动切换，则沿用产品当前关键词搜索默认匹配目标
- 本期建议默认视图先按 `按频道标签` 展示，最终默认项待评审确认

#### 3.4.1E 排除关键词

每个关键词 tag 的匹配目标面板底部支持：

- `排除该关键词`

开启后：

- 该关键词转为排除条件
- 视觉上必须与普通正向 tag 拉开差异
- 不得影响其他关键词 tag 的正向匹配语义

#### 3.4.1F 匹配目标菜单的附着关系

匹配目标菜单必须被定义为：

- `当前关键词 tag 的附属菜单`

而不是：

- 独立浮层
- 通用页面弹窗

因此必须满足：

- 菜单从当前被点击的关键词 tag 下沿或右下沿展开
- 菜单与 tag 的视觉距离最小化
- 用户应感知为“在编辑这个关键词的匹配语义”，而不是“打开了一个独立设置面板”

#### 3.4.2 关键词模式下的最小智能增强

在不破坏经典路径前提下，允许增加轻量增强，但不得强制展开：

- 搜索框可显示轻提示，如“可继续补充地区、粉丝量、活跃度等要求”
- 搜索结果返回后，若系统判断有明显 refine 价值，可在搜索框内显示低干扰的 `转为智能搜索` 提示
- 用户未主动接纳该提示时，不自动进入 `clarifying`
- 现有关键词 tag 体系必须被完整保留，不能退化为单字符串输入

**补充约束**：

- 经典关键词模式下，不应长期显示解释性副文案
- 经典关键词模式下，不应常驻多个高权重按钮
- 经典态的视觉中心必须始终落在：
  - 搜索 icon
  - 已完成关键词 tag
  - 当前输入光标

#### 3.4.3 关键词搜索后的升级条件

只有在以下场景允许从关键词模式升级到展开态：

- 用户主动在原词后继续补一句自然语言要求
- 用户点击搜索框内的 `转为智能搜索`
- 当前搜索结果为空，且系统存在明确的修正建议

#### 3.4.4 关键词 tag 与 Agent 模式的关系

当关键词模式升级为 Agent 展开态后：

- 已有 `committed_keyword` 继续保留
- 每个关键词 tag 的匹配目标继续生效
- 这些关键词进入 `Explicit Conditions`
- Agent 不得在无提示情况下改写已有关键词的匹配目标

#### 3.4.5 关键词起手升级路径

当用户已经处于经典关键词态，并继续补充一段自然语言时：

- 该行为应被解释为 `从经典态升级为 Agent 态`
- 已有关键词 tag 保留
- 新自然语言被解释为搜索任务增量，而不是再固化为普通关键词 tag
- 升级后搜索框内至少保留：
  - 已有关键词片段
  - 一个新的可输入位
  - 系统生成的任务摘要 / 条件解释

### 3.5 URL 输入兼容规则

#### 3.5.1 支持范围

本期继续兼容当前搜索框已支持的 URL 搜索能力，包括现有已支持的频道类链接、站内详情链接与其他既有 URL 输入类型。

#### 3.5.2 纯 URL 模式

- 用户输入 `纯 URL` 时，系统先进入 `URL resolving` 过程
- 若 URL 识别成功且可直接映射为现有精确搜索路径：
  - 搜索框保持经典态或仅进入极轻量识别态
  - 不自动展开为完整 Agent 模式
  - 不再把默认结果定义为“只看这个频道”
  - 而是进入 `锚点搜索`
  - 视觉上应收敛为一个精确锚点 badge，而不是继续以整段原始长 URL 作为主输入表现

`锚点搜索` 的统一定义：

- 先把 URL 解析为一个明确频道锚点
- 在搜索框内显式展示该锚点频道
- 结果列表中将 `锚点频道` 置顶固定
- 其余结果默认召回与该频道相似的其他频道
- 相似结果默认按相似程度排序，但允许用户切换到其它排序方式
- 在 URL 已锁定为锚点后，允许用户继续追加关键词，形成 `URL+关键词种子`
- 该种子态与 `关键词+URL种子` 共享同一输入语义：`0..1 anchor + 0..n keyword + 1 draft`

#### 3.5.2A URL 精确识别成功后的视觉规则

- 当 URL 已成功识别并锁定到单一频道目标时：
  - 原始长 URL 不再作为主视觉文本保留
  - 搜索框应改为展示 `anchor badge`
  - 该 badge 与“URL 起手升级为 Agent 态”时保留的 URL 锚点视觉语义保持一致
- 输入层语义应同步切换为 `committed_anchor`
- 目标是让用户理解：
  - 系统已经把这条链接解析成一个明确对象
  - 当前正在围绕这个对象召回相似频道，而不是只停留在精确频道查看

补充约束：

- 在经典态查询编辑器中，`anchor badge` 最多只允许出现一个
- 若用户再次输入第二个精确 URL，不应静默并存；必须要求用户替换或清空已有锚点
- `锚点频道` 不应混入普通相似结果排序流中
- 若产品保留“只查看该频道”的能力，应作为低干扰次级动作，而不是 URL-only 的默认结果语义

#### 3.5.3 URL 异常与修正

若出现以下情况，允许搜索框进入展开修正态：

- URL 无法识别
- URL 类型受支持但内容失效
- URL 与当前平台页不匹配，需要用户确认处理方式

进入展开修正态后：

- 追问仍必须留在搜索框内部
- 问题只围绕 URL 修正本身
- 不得把用户带去独立 AI 面板

#### 3.5.3B `anchor + keyword` 下的 URL 失败例外

当用户输入里同时有 URL 与 keyword，但 URL 解析失败无法生成 anchor 时：

- 系统只判定 URL 失败，不判定整条查询失败
- keyword 必须保留为可继续搜索的显式条件
- 默认进入搜索框内 `expanded_repair`

用户侧修正动作基线：

- `A_REPAIR_FIX_URL`
  - 修正 URL 并重试解析
- `A_REPAIR_REMOVE_ANCHOR_KEEP_KEYWORDS`
  - 删除 URL，仅保留 keyword 搜索
- `A_REPAIR_SWITCH_TO_NL`
  - 改为自然语言描述，并进入 Agent 解析

补充约束：

- 该例外路径不做前置冲突判别；失败原因限定在 URL 解析侧
- 删除 URL 后，不得清空已有 keyword
- 切到自然语言路径后，原 keyword 仍作为显式条件参与后续解析

#### 3.5.3C 低召回统一修正（`low_recall`）

以下两类情况统一走同一修正分支：

- `anchor-only` 相似结果极少或质量不足
- `anchor + keyword` 首轮可见结果极少、过窄或可用性不足

统一规则：

- 结果仍然展示给用户，不当作“无结果”
- 会话保持 `results_ready`
- 额外记录：
  - `repair_reason = low_recall`
  - `repair_hint_visible = true`
- 容器保持当前态，不自动切到 `expanded_repair`
- 用户通过搜索框内部轻提示入口手动展开后，才进入完整修正区
- 不区分是否是 anchor-only / anchor+keyword 的入口，修正动作采用同一组语义

动作语义基线：

- `A_HINT_OPEN_REPAIR_LOW_RECALL`
- `A_HINT_DISMISS_LOW_RECALL`
- `A_REPAIR_REPLACE_ANCHOR`
- `A_REPAIR_EXPAND_RECALL_SCOPE`
- `A_REPAIR_REMOVE_ANCHOR_KEEP_KEYWORDS`
- `A_REPAIR_SWITCH_TO_NL`

补充约束：

- 低召回不等于“完全无结果”，但应复用同一修正通道，避免分裂成两套交互体系
- `A_REPAIR_REMOVE_ANCHOR_KEEP_KEYWORDS` 在 anchor-only 场景可退化为“删除锚点并回到经典输入”
- 低召回提示入口的位置基线为：搜索框内部、查询行下方的第二行提示条
- 该提示入口承担告知与展开职责，替代自动展开带来的遮挡问题

#### 3.5.3D 修正成功后的结果表达

当修正态重新搜索成功后：

- 会话层回到 `results_ready`
- 不再单独新增“修正后已恢复结果”状态
- 必须在上下文中记录：
  - `source_stage = post_repair`

这样既能保留“这是修正后恢复出来的结果”语义，又避免为了来源差异继续膨胀新状态。

#### 3.5.3A URL 识别微状态

为避免 URL 搜索一上来就过度展开，本期将 `compact_resolving` 再细分为以下微状态：

| 微状态 | 含义 | UI 目标 |
|---|---|---|
| `resolving` | 正在识别 URL 类型与目标资源 | 给用户极轻量进度反馈，不打断搜索节奏 |
| `resolved_exact` | 已识别为当前平台可直达的精确目标 | 快速返回结果，并结束识别态 |
| `resolved_mismatch` | URL 可识别，但与当前平台页不匹配 | 在搜索框内给出平台修正提示 |
| `resolved_unsupported` | URL 结构可识别，但当前版本不支持此类型 | 在搜索框内给出限制说明 |
| `resolved_invalid` | URL 格式错误、资源失效或无法解析 | 在搜索框内进入修正态 |

**规则**：

- `resolved_exact` 不进入完整 Agent 模式，除非用户继续追加自然语言补充
- `resolved_mismatch / resolved_unsupported / resolved_invalid` 可以进入 `expanded_repair`
- URL 识别态的目标是“尽快判断是否还能保持经典路径”，而不是默认升级为智能搜索

#### 3.5.4 URL 与自然语言混合输入

URL 与自然语言同时出现时，按以下优先级处理：

1. 若 URL 可映射为 `单一精确频道`
   - URL 优先
   - 搜索框进入展开态，但以 `精确目标已锁定` 的方式展示
   - 系统需在搜索框内明确提示：
     - 当前按 URL 精确定位目标
     - 其他自然语言描述不会自动扩展为“找类似频道”
2. 若 URL 不能形成单一精确目标，但仍可提供上下文
   - 进入完整 Agent 模式
   - URL 作为 `Explicit Condition` 或 `Context Anchor`
3. 若 URL 不支持与自然语言混合解析
   - 搜索框内给出明确提示
   - 不允许静默忽略其中一部分输入

**本期约束**：

- “给我找和这个 URL 类似的频道” 不作为默认能力承诺
- 若用户同时输入精确 URL 与泛化自然语言需求，系统应优先保证精确 URL 行为不被破坏

#### 3.5.4A URL 起手升级路径

当用户已经成功输入并识别一个精确 URL，然后继续补充自然语言时：

- URL 保留为 `anchor`
- 新自然语言作为 refine 增量进入 Agent 解释
- 输入层应表现为 `committed_anchor + followup_waiting`
- 该路径属于 `经典 URL 起手 -> Agent 态升级`
- 系统必须先向用户说明当前的优先级关系：
  - URL 是否仍锁定精确目标
  - 新自然语言会被当作硬条件、软偏好，还是触发追问

### 3.5.5 URL 修正提示规则

URL 修正提示必须短、明确、只回答当前卡点，不做泛化对话。

| 场景 | 提示方向 |
|---|---|
| 平台不匹配 | 明示“当前在 YouTube 频道搜索页，该链接属于 Instagram/TikTok/X” |
| 链接不完整 | 明示“当前无法识别该链接，可直接粘贴频道主页链接或只输入频道名” |
| 类型不支持 | 明示“当前版本不支持用该类链接起搜” |
| 资源失效 | 明示“未能识别该链接对应的频道” |

提示后允许的动作仅限：

- 修改 URL
- 删除 URL 改为关键词 / 自然语言
- 接受平台切换建议（若后续版本支持）

### 3.7 混合输入解析规则

#### 3.7.1 混合输入的判定条件

任一输入同时包含以下两类及以上信息，即视为混合输入：

- 关键词或品牌词
- URL
- 自然语言句子
- 显式条件片段（如“美国”“1w+”“最近活跃”）

#### 3.7.2 混合输入的解析顺序

本期固定采用如下解析顺序：

1. `Anchor 识别`
   - 是否存在精确 URL / 精确频道名 / 明确平台指向
2. `Hard Filters 提取`
   - 地区、平台、粉丝量、活跃度、语言、类目等
3. `Soft Intent 提取`
   - 调性、性价比、近期表现、排除偏好等
4. `As-is 结构化落地`
   - 将 anchor / explicit keyword / hard filters / soft intent 原样落到结构层
5. `Clarify or Search`
   - 默认能先搜则先搜
   - 不对 `anchor + keyword` 做前置冲突判别
   - 只有结果异常或高影响歧义时才再追问

补充规则：

- 当 `anchor + keyword` 同时出现时，系统默认执行：
  1. 锁定 `anchor`
  2. 召回相似频道候选
  3. 让 `keyword` 在首轮用户可见结果里已经生效
- 这里不要求产品把底层实现写死为某一种算法顺序；可以是候选过滤、rerank、post-filter 等不同实现
- 但对用户可见语义必须稳定为：
  - `anchor` 与 `keyword` 同时生效
  - `anchor` 作为参考频道置顶保留
  - 相似频道结果已经过 `keyword` 约束收敛

#### 3.7.3 混合输入的优先级层级

| 优先级 | 类型 | 说明 |
|---|---|---|
| P0 | 精确 URL / 精确单一频道锚点 | 优先保证其行为不被破坏 |
| P1 | 用户显式硬条件 | 如地区、平台、粉丝量、时间范围 |
| P2 | 用户软性偏好 | 如调性、风格、高级感、性价比 |
| P3 | 系统派生规则 | 仅在不与 P0-P2 明确冲突时生效 |

#### 3.7.4 混合输入中的系统提示要求

当用户输入较复杂的混合输入时，搜索框会话层必须先回答两个问题：

1. `系统当前按什么在搜`
2. `哪些描述已生效，哪些只是参考或待澄清`

例如：

- `已按 URL 锁定频道：@abc`
- `已生效条件：美国 / 英语 / 近 30 天活跃`
- `待澄清：你说的“性价比高”目前会先作为参考，不直接过滤结果`

#### 3.7.5 混合输入中的软条件处理

以下类型默认不作为首轮硬过滤条件，而是作为软条件：

- 高级感
- 性价比高
- 调性合适
- 内容质量高
- 更像真人推荐

这些条件的默认处理方式是：

- 进入会话层说明
- 若有足够映射规则，则转为 `Derived Rules`
- 若没有稳定映射规则，则在首轮结果后进入轻量追问

#### 3.7.6 混合输入中的冲突处理

常见冲突示例：

- URL 已锁定某频道，但自然语言又要求“找更多类似频道”
- 当前平台为 YouTube，但自然语言要求 Instagram 红人
- 用户要求“粉丝 1w-5w”，同时又给出明显超大号 URL

处理原则：

- 先保住 P0 锚点语义
- 不静默改写用户意图
- V1 对 `anchor + keyword` 不做前置冲突判别
- 默认先按原样执行首轮搜索
- 只有当结果为空、明显异常或出现高影响歧义时，才进入 repair / clarify

补充说明：

- `anchor` 在该路径中承担 `pinned reference` 角色，不参与普通相似结果排序
- `keyword` 作用于相似频道结果集，而不决定是否隐藏 `anchor`
- 因此即使某个 `keyword` 与 `anchor` 本身看起来不完全匹配，V1 仍然保留 `anchor` 置顶显示，由用户理解它是参考对象而非普通召回结果

### 3.6 搜索框展开/收起状态机

#### 3.6.1 视觉状态

| 状态 | 含义 |
|---|---|
| `compact_classic` | 经典收起态，服务关键词与 URL 主路径 |
| `compact_resolving` | URL 识别中的轻量状态 |
| `expanded_agent` | 已进入完整 Agent 模式 |
| `expanded_clarifying` | 展开态下正在追问 |
| `expanded_repair` | 展开态下正在做空结果或 URL 修正 |

#### 3.6.2 状态切换规则

- `compact_classic -> compact_resolving`
  - 用户提交纯 URL
- `compact_classic -> expanded_agent`
  - 用户提交纯自然语言
  - 用户提交混合输入
  - 用户在关键词搜索后主动转为智能搜索
- `compact_resolving -> compact_classic`
  - URL 成功识别并完成原有精确搜索
- `compact_resolving -> expanded_repair`
  - URL 识别失败或需修正
- `expanded_agent -> expanded_clarifying`
  - 首轮结果后存在高影响歧义
- `expanded_agent -> expanded_repair`
  - 有条件无结果
- `expanded_agent -> compact_classic`
  - 用户主动清空当前 session 并回退
- Agent 回退到经典态时，必须满足：
  - 无未完成追问
  - 无进行中的 repair 卡点
  - 当前只剩显式 tag 和/或单一 anchor

#### 3.6.3 收起规则

展开态不会因为首轮结果返回而自动收起。

只有以下情况允许收起：

- 用户主动点击收起 / 新搜索
- 用户清空当前输入与条件并重置 session
- 用户切换到一个全新经典搜索任务

不得出现：

- 系统在追问结束后自动把搜索框缩回去
- 用户还在当前 session 中时，因结果刷新导致容器自动收起

---

## 四、追问规则

### 4.1 追问触发条件

只有以下类型问题允许触发追问：

- 目标平台或地区范围对结果集影响极大
- 粉丝量级 / 活跃度 / 内容类别表达过于模糊
- 用户要求之间存在明显冲突
- 当前结果为空，且系统存在高价值修正建议

### 4.2 追问约束

- 单次只展示一个最高价值问题
- 追问必须出现在搜索框容器内部
- 追问不能拆到：
  - 抽屉
  - 侧栏
  - 下方独立消息区
- 用户回答追问后，系统立即回到 `refining` 并刷新结果

### 4.3 追问结束条件

以下情况结束当前 Clarification Loop：

- 用户已回答关键歧义
- 结果已达到可浏览状态
- 系统判断继续追问收益低
- 用户主动改为手动筛选

---

## 五、条件透明与同步规则

### 5.1 条件可见性

结构化条件必须持续可见，默认展示于搜索框容器内部。

### 5.2 条件来源标识

每个条件项至少需要具备来源标识：

- `用户输入`
- `Agent 推断`
- `手动修改`

### 5.3 双向同步规则

- 用户通过搜索框追加一句自然语言 -> 更新 Condition Graph
- 用户编辑条件 chip -> 更新当前 Search Session 摘要
- 用户通过显式筛选器修改条件 -> 同步回 Search Session

不得出现“两套条件状态并行漂移”的情况。

### 5.4 条件冲突

若条件之间冲突：

- 进入 `clarifying` 或 `empty_repair`
- 在搜索框内部提示冲突点
- 不允许无提示静默覆盖

---

## 六、零结果与受限响应

### 6.1 零结果分型

| 类型 | 定义 | 响应 |
|---|---|---|
| 无条件零状态 | 用户尚未输入有效搜索条件 | 展示榜单/推荐态 |
| 有条件无召回 | 当前条件导致无结果 | 进入 `empty_repair`，在搜索框内给修正建议 |

### 6.2 有条件无召回时的规则

- 保留当前条件可见
- 在搜索框内部给出 1-3 条高价值修正建议
- 用户可以：
  - 点击建议
  - 回答追问
  - 手动删改条件

### 6.3 unsupported / sensitive

对不支持或敏感需求：

- 不返回伪装成成功的普通结果
- 明确提示限制原因
- 如存在安全替代建议，可在搜索框内部给出

---

## 七、视觉与容器级业务约束

### 7.1 搜索框认知保持

即使展开后增加追问、状态、条件摘要，用户仍应认知为：

`一个被升级的搜索框`

而不是：

- 聊天窗口
- 浮层助手
- 独立工作台

### 7.2 局部 AI 化边界

- 搜索框内部允许使用：
  - 独立面板
  - 特殊边界
  - 层叠卡片
  - 发光
  - 质感背景
- 搜索框外部默认不变：
  - 页面导航
  - 结果区
  - 排序区
  - 外部列表骨架

### 7.3 展开与收起

- 搜索框展开和收起必须平滑切换
- 不允许造成页面重排失控
- 不允许展开态压迫结果区到无法阅读

---

## 八、验收标准

- 用户可以通过自然语言直接发起频道搜索
- 首轮搜索在无关键阻塞条件时必须先返回结果
- 追问仅在必要时触发，且必须留在搜索框内部
- 结构化条件必须持续可见并可编辑
- 手动筛选、自然语言 refine、条件 chips 必须同 session 同步
- 老用户纯关键词 / 纯 URL 搜索路径不得劣化
- 有条件无结果时必须进入搜索框内修正态
- 搜索框展开态允许明显 AI 化，但搜索框外区域保持现有搜索页稳定感