REQ_id_extract_v2.md 28 KB
REQ · ID提取 需求重整 v2（已实施 · v8 三段式落地）
✅ 状态：已实施。本文就是 v8 那次改造的依据（删 5 / 合并 7 / 改名 6 / 置灰 3 / 保留 17 与三段式结构都已落地）。保留作需求原始记录。
对象：
tiktok-app界面「任务 › ID提取」的四张脚本卡 + 功能设置。 目标：不再往上加功能，而是把已经存在但互相矛盾的需求理清，让每个控件都有唯一、可执行的语义。 依据：《实施规格书_飞舟脚本_2026-10-13》（资料库JZf9xTgLXBFgjXJ4dJWVsU）+ 现有代码实测。 配套：PLAN_id_extract.md（执行功能方案）。本文只谈要什么，不谈怎么实现。
0. 摘要
乱不在控件多少，在于每个控件没有唯一的行为定义。
实测：ID提取共 38 个业务字段（+4 个 checked +4 个 expanded）。其中 10 个是"纯开关"
—— 勾上之后旁边没有任何输入或选择，执行时无从下手；而其中 4 个与它所在的卡片同名
（"自定关注或粉丝页面提 ID"、"自定评论页面提 ID"、"文本 UID 裂变提 ID"、"关键词视频提 ID"），
等于"勾了这张卡之后再确认一次要不要用这张卡"。
四张卡也不是四个功能，而是「起点（人从哪来）」×「深度（要不要再展开一层）」 的 4 个不完整组合。于是同一批人能用不同卡抓到，用户不知道该选哪个； 而想同时要两种来源时，单选约束又不允许——这条约束本身就是分类错了的信号。
1. 乱在哪：10 条具体问题
每条都给证据，不是感觉。
1.1 四个开关与卡片同义反复（4 处）
| 卡片 | 卡内第一个开关 | 问题 |
|---|---|---|
| 脚本一 · 粉丝页提 ID | 「自定关注或粉丝页面提 ID」默认 ✓ | 和卡名重复 |
| 脚本二 · 评论页提 ID | 「自定评论页面提 ID」默认 ✓ | 和卡名重复 |
| 脚本三 · 文本 UID 裂变提 ID | 「文本 UID 裂变提 ID」默认 ✗（代码 true） | 与卡名一字不差 |
| 脚本四 · 关键词视频提 ID | 「关键词视频提 ID」默认 ✗（代码 true） | 与卡名一字不差 |
后果：用户已经通过单选圆点选了这张卡，再看一个"要不要启用"的开关，只能猜： 关掉它是不是等于不选这张卡？如果等于，为什么不直接取消勾选？如果不等于，那它到底关掉了什么？ 执行侧也无法回答这个问题 —— 这正是语义缺失的直接体现。
1.2 脚本一把三种互斥起点塞进一张卡（最严重的结构问题）
脚本一里同时存在三条取材路径，靠 2 个开关区分，且没有定义"三个都开"或"都不开"的行为：
| 控件 | 隐含的起点 |
|---|---|
| 主播 ID（输入框）+ 进入页面（下拉） | 指定账号主页 |
| 自定页面提 ID（纯开关） | 搜索结果里的用户 |
| 使用文本 ID（开关 + 路径） | 文本文件里的 UID |
其中「自定页面提 ID」勾上后没有任何输入（page-id.js:126 只有 W.checkRow，无右侧控件）
—— 自定义哪个页面？执行时从哪开始？无解。
而「使用文本 ID」做的事与脚本三的「裂变文本」是同一件事（两者默认路径完全相同，都是
/sdcard/Download/tiktok_app/uid_list.txt）。
1.3 10 个纯开关，勾上之后无所指
勾选后既没有输入、也没有选择，因此无法确定执行行为：
| 卡片 | 纯开关 |
|---|---|
| s1 | 自定关注或粉丝页面提 ID、自定页面提 ID |
| s2 | 自定评论页面提 ID、提取评论的人的粉丝 ID |
| s3 | 文本 UID 裂变提 ID、UID 博主去重 |
| s4 | 关键词视频提 ID、关键词提取主播粉丝 ID、关键词提取评论区 ID、关键词提取评论的人的粉丝 ID |
只有 s1 的「主播去重」是"开关 + 右侧下拉"的完整形态（buildToggleRow 的 rightOf）。
同一个项目里两种开关形态并存，用户无法从外观判断哪个开关后面还有东西。
1.4 同名不同义：「进入页面」在两张卡里指两件事
| 位置 | 候选值 | 实际含义 |
|---|---|---|
s1 enterPage |
粉丝页 / 评论页 / 主页 / 关注页 | "去哪个页面取材" |
s3 enterPage |
同上（默认关注页） | "对文本里的 uid 展开哪个列表" |
同一个下拉名、同一套候选值、两套语义。用户在 s3 看到"进入页面=关注页"， 会以为脚本要"进入某个关注页"，实际是"取这些 uid 的关注列表"。
1.5 去重散落三处，且没人知道它们的关系
| 位置 | 控件 | 管什么？ |
|---|---|---|
| s1 | 主播去重（开关）+ 去重模式（ID 模式/文本模式） | 主播？全部 ID？ |
| s3 | UID 博主去重（纯开关） | 与上面是同一个东西吗？ |
| 功能设置 | 云端去重（开关）+ 表名 + 连通测试 | 本地与云端是并存还是互斥？ |
三处描述同一件事的不同侧面，分布在不同卡片与不同区域。"主播去重"这个词尤其含糊 —— 产物是 ID，不是主播；到底去重对象是"取材起点"还是"输出的每一个 ID"？
1.6 「裂变」这个词承担了三个未定义的语义
脚本三的卡名与开关都叫"文本 UID 裂变"，但"裂变"至少可以指： ① 文本里的 uid → 取这些人的粉丝/关注（一层展开）； ② 文本里是关键词 → 搜人 → 再展开； ③ 文本里的 uid → 直接产出（不展开）。 三种实现的工作量差几倍，而界面完全一样。
1.7 脚本四四个开关是"层层嵌套"，却排成四个平级项
文案都以「关键词」开头、长度接近、控件形态相同：
关键词视频提 ID ✗
关键词提取主播粉丝 ID ✗
关键词提取评论区 ID ✗
关键词提取评论的人的粉丝 ID ✗
实际关系是：视频来源 → 作者 → 作者的粉丝 / 评论区 / 评论者的粉丝（第 1 个是根， 后 3 个是并列的可选扩展）。排成四项平级，用户读不出"1 是根，2/3/4 是扩展"， 更读不出"2 和 3 是同一层，4 是更深一层"。
1.8 功能设置的 14 项，混了三种性质的东西
| 性质 | 项 | 问题 |
|---|---|---|
| 过滤条件（会丢人） | 私密、无头像、语言、区域、四组数量门槛 | 与"检测"混在一起 |
| 检测方式（决定怎么判） | 昵称个签检测（通杀/仅昵称/仅个签） | 它是前者的取样字段，不是独立设置 |
| 需要外部能力的开关 | 云端去重、AI 头像识别、AI 性别、AI 年龄 | 当前都没有承载者，却能打开 |
「提取区域」的说明文案更直接暴露问题：弹窗写"勾选后，只提取符合上方国家简码的账号"
（page-id.js:362），但这一行根本没有勾选框，上面是一个输入框。
1.9 默认值与规格书不一致（2 处）
| 字段 | 规格书 C3 | 代码 |
|---|---|---|
s3 uidFission |
✗ | true |
s4 keywordEnabled |
✗ | true |
代码里这么写是有理由的（都设 ✗ 的话，脚本三/四展开后整片是关的，用户会以为坏了）， 但这恰好说明：这些开关本身就不该存在 —— 一个"默认必须打开、否则页面看起来是坏的"的开关， 是没有信息量的。
1.10 单选约束与用户的真实意图冲突
规格书写「单选：同一时间仅可运行一个脚本」。但用户的真实需求常常是组合的： "先抓关键词视频的作者，再把文本里这批 uid 的粉丝也抓一遍"。 当前结构下做不到，只能分两次运行、两次产出去手动合并。
2. 病根（两条，改界面之前必须先认）
2.1 需求只描述了"控件长什么样"，没描述"执行时意味着什么"
规格书是从画布反推出的字段表：它准确记录了"这一行有一个复选框、默认 ✓"， 但没有记录"勾上之后，脚本要做什么、不勾要做什么、和别的开关同时勾时听谁的"。
这就是为什么做执行方案时被迫猜了三处语义（主播 ID 留空 / customFansPage / 裂变）。
"界面乱"和"执行要猜"是同一个病。所以本次重整的主产出不是排版，
而是给每个控件补上唯一的行为定义。
2.2 分类维度不唯一：四张卡是「起点 × 深度」的不完整组合
真正的两个维度是：
- 起点（人从哪来）：指定账号 / 搜索结果 / 某个视频的评论区 / 文本文件 / 当前屏幕
- 深度（要不要再走一层）：只要这个人 / 再取他的粉丝·关注
把四张卡拆到这两个维度上：
| 旧卡 | 起点 | 深度 | 它缺的能力（被塞在别处了） |
|---|---|---|---|
| s1 粉丝页 | 指定账号主页 | 1 层（列表） | 缺"搜索用户"（塞在 s1 自己的 customPage）、缺"文本"（塞在 useTextId） |
| s2 评论页 | 某视频评论区 | 0~1 层 | 缺"视频从哪来" —— 只有"自定评论页面"= 假定用户已停在评论区 |
| s3 文本 | 文本文件 | 1 层 | 缺"直接用文本里的 uid"（不展开） |
| s4 关键词视频 | 搜索视频 | 0~2 层（3 种扩展） | 缺"搜索用户"起点 |
四张卡各缺一块、各有别人没有的一块，合起来才完整。 所以"选一个脚本"这个动作本身就是在替用户做减法，而用户往往不想减。
3. 新需求：三段式
任何"ID 提取"工具都只有三步。把结构改成这三步，四个脚本自然消失。
① 取材 从哪儿找人 → 可累加的取材清单（1 条或多条，串行执行）
② 过滤 只要什么样的人 → 一组共用条件（所有取材都适用）
③ 输出 要多少、存哪 → 上限 + 去重 + 文件
3.1 取材：5 种起点 + 1 个深度选项
用户只需回答两件事：从哪开始、要不要再往下走一层。
| # | 起点 | 用户要提供 | 能取到 | 能否再展开一层 |
|---|---|---|---|---|
| A | 指定账号 | 账号（多个用 # 分隔） |
粉丝列表 / 关注列表 / 主页展示的账号 | ✅ 展开后可再取粉丝/关注 |
| B | 搜索结果 | 类型（用户 / 视频）+ 关键词 | 用户搜索结果里的人 / 视频的作者 | ✅ 同上 |
| C | 某个视频的评论区 | 视频从哪来（当前屏幕 / 关键词搜到的） | 评论者 | ✅ 取评论者的粉丝 |
| D | 文本文件 | 文件路径 | 文件里的每一行 uid | ✅ 取这些人的粉丝/关注 |
| E | 当前屏幕 | 无 | 屏幕上这个列表里的人 | ❌ 已是最底 |
规则（必须写进需求，否则又会含糊）：
- 一条取材 = 一个起点 + 它需要的输入 + 它的深度选项。选了起点才出现该起点的输入， 不会再有"勾上却无所指"的开关。
- 取材可以有多条，按顺序串行执行（同一台手机只有一个前台，没有并发可言）。 多条之间共用同一份去重集合与同一个输出文件。
- 深度最多 2 层（列表里的人 → 这些人的粉丝）。 原因：100 个粉丝 × 每人 100 粉丝 = 1 万次用户页打开，在真机上不现实，也会让账号看起来异常。 第 3 层直接不给选项。
- 每条取材至少要有 1 个可执行输入，否则这条不予启动（启动前拦住并指出是哪一条缺什么）。
3.2 旧四张卡 → 新取材的三条常用配置（等价物）
改结构不等于丢掉用户熟悉的用法。三个常见场景在新结构下的写法：
| 用户想干的 | 旧操作 | 新操作 |
|---|---|---|
| 抓某个主播的粉丝 | 脚本一（默认就是） | 一条取材：指定账号 xxx → 取「粉丝列表」 |
| 抓关键词视频的作者的粉丝 | 脚本四 | 一条取材：搜索结果「视频 + 关键词」→ 取「作者」→ 深度「作者粉丝」 |
| 把文本里这批 uid 的粉丝抓一遍 | 脚本三 | 一条取材：文本文件 → 深度「这些人的粉丝」 |
并且多了一个旧结构做不到的能力：以上三条可以同时配（三条取材串行跑，共用一个输出）。
3.3 过滤：从 14 项收敛成 2 组，逐项写明执行语义
A 组 · 只要这样的账号
| 项 | 执行语义（必须唯一） | 现状定性 |
|---|---|---|
| 过滤私密账户 | 读不到"私密"提示 → 保留；读到 → 丢 | 可做 |
| 过滤无头像账户 | 头像是默认占位图 → 丢 | 可做（需像素判定） |
| 语言 | 取昵称 + 个签的字符组成：中文占比 ≥ 阈值 → 中文；拉丁 ≥ 阈值 → 英文；都不满足 → 丢 | 可做（纯本地） |
| 昵称个签检测 | 不是一个过滤条件，是上面"语言"的取样范围：通杀 / 只看昵称 / 只看个签 | 需改名并归到"语言"下面 |
| 提取区域 | TikTok 用户页不显示国家，无可用的判定数据源 | 标「暂不支持」，不给可开的开关 |
| AI 头像识别 / AI 性别 / AI 年龄 | 需要模型，本期无承载者 | 标「暂不支持」 |
B 组 · 数值门槛
| 项 | 执行语义 |
|---|---|
| 关注量 / 粉丝量 / 获赞量 / 视频量（各 min~max） | 读用户页数字（1.2M / 12.3K / 1.2万 都要能解析）→ 落在区间内才保留 |
C 组 · 去重与输出（从脚本卡里全部收上来，只出现一次）
| 项 | 执行语义 |
|---|---|
| 本地去重 | 与"历史已提取"（跨轮）+ "本次已收"（同轮）比对，重复的跳过。默认开 |
| 云端去重 | 未配置服务地址时不生效，并在日志里明说「本次仅本地去重」，不静默 |
| 提取上限 | 凑满 N 个即结束。0 = 不限，但受引擎的物理护栏约束（最大时长 / 最大翻屏数），到护栏时如实说明 |
关键规则："暂不支持"的项必须是灰的并带一个 ⓘ 说明原因，不能给一个能打开、 打开后什么也不发生的开关。现在的「云端去重」就是这样：开关能开，但"连通测试"只会告诉你 "当前未配置服务地址"。
3.4 界面结构（新）
┌─ ID提取 ────────────────────────────────────┐
│ │
│ ① 取材 │
│ 说明：可添加多条，按顺序执行；共用同一份去重与输出 │
│ │
│ ┌ 第 1 条 ─────────────────────────────┐ │
│ │ 起点 [指定账号 ▾] │ │
│ │ 账号 [ID1#ID2#ID3 ] │ │
│ │ 取 ☑ 粉丝列表 ☑ 关注列表 ☐ 主页展示 │ │
│ │ 深度 ☐ 再取这些人的粉丝（最多 2 层） │ │
│ └──────────────────────────────────────┘ │
│ ┌ 第 2 条 ─────────────────────────────┐ │
│ │ 起点 [文本文件 ▾] │ │
│ │ 文件 [/sdcard/Download/tiktok_app/uid_list.txt] [选择] │
│ │ 深度 ☑ 再取这些人的粉丝 │ │
│ └──────────────────────────────────────┘ │
│ [+ 添加一条取材] │
│ │
│ ② 只要这样的账号 │
│ ☑ 过滤私密 ☑ 过滤无头像 │
│ 语言 [通杀 ▾] 取样 [昵称+个签 ▾] │
│ 区域 [暂不支持 ⓘ] │
│ 关注量 [0]~[500000] 粉丝量 [0]~[500000] │
│ 获赞量 [0]~[500000] 视频量 [0]~[500000] │
│ │
│ ③ 输出 │
│ 提取满 [0=不限] 个后停止 │
│ 去重 ☑ 本地 ☐ 云端（需先在「我的」配置服务） │
│ 文件：uid_20261017_1100.txt（自动命名） │
└──────────────────────────────────────────────┘
与旧页面相比去掉的东西（都是本次诊断出来的问题源）：
| 去掉 | 原因 |
|---|---|
| 四张"脚本"卡 + 单选圆点 | 起点与深度是两个维度，不该做成 4 个互斥选项（§2.2） |
| 「单选：同一时间仅可运行一个脚本」说明 | 约束随结构消失：取材是串行清单，本来就只有一个在跑 |
| 4 个同义反复的开关 | §1.1 |
| 6 个"勾上却无所指"的纯开关 | §1.3 —— 全部变成"选了起点才出现的输入" |
| 脚本卡里的三个去重控件 | 收到 ③ 只出现一次（§1.5） |
| 「↓ 下方还有功能设置」滚动指引 | 页面从"4 卡 + 长设置"变成三段，一屏半就能看完 |
| 「当前脚本：xxx」提示条 | 没有"当前脚本"这个概念了 |
3.5 三个必须回答的行为定义（旧需求完全没写）
这三条是本次重整最实质的产出，不是排版能替代的：
- 一条取材跑完、列表翻到底了怎么办？ → 换下一条取材，不算失败。 全部取材都跑完才结束，终态是「已完成」。
- 深度展开的人要不要也过一遍过滤？ → 要。过滤对所有被收录的 ID 一视同仁 （否则"粉丝的粉丝"会绕过 14 项条件混进产物，这是最容易被忽略的一处）。
- 同一个 ID 在两条取材里都出现了怎么办？ → 后出现的那次跳过，且不占用上限名额 （否则用户设了 100 个上限，实际只拿到 60 个新的）。
4. 逐字段处置表（38 个业务字段，一个不落）
| # | 旧路径 | 处置 | 新归属 |
|---|---|---|---|
| 1 | s1.customFansPage | 删 | 被「起点=指定账号 + 取哪个列表」取代 |
| 2 | s1.customPage | 删 | 它是"起点=搜索结果·用户"，独立成一条取材 |
| 3 | s1.dedupeEnabled | 移 | ③ 输出 · 本地去重 |
| 4 | s1.dedupe | 移 + 简化 | 与 UID 博主去重合并；"ID 模式/文本模式"的差别只是集合来源，不必单独让用户选 |
| 5 | s1.enterPage | 改名 + 收窄 | ① 取材 · 「取哪些列表」（多选：粉丝/关注/主页展示），只在起点=指定账号时出现 |
| 6 | s1.anchorIds | 保留 + 改名 | ① 取材 · 「账号」 |
| 7 | s1.useTextId | 删（合并） | 选「文本文件」这个起点即等于要用文本，不需要再确认一次 |
| 8 | s1.textIdPath | 保留 + 改名 | ① 取材 · 「文件」（与 s3 是同一个概念，只留一份） |
| 9 | s2.customCommentPage | 删 | 起点=评论区的输入改为「视频从哪来」 |
| 10 | s2.commenterFans | 合并 | ① 取材 · 深度「再取这些人的粉丝」 |
| 11 | s3.uidFission | 删 | 同义反复（§1.1） |
| 12 | s3.uidDedupe | 删（合并） | 统一去重 |
| 13 | s3.enterPage | 改名 | ① 取材 · 深度里的「展开哪个列表」（粉丝/关注）—— 与 #5 分名，避免同名不同义 |
| 14 | s3.fissionTextPath | 合并 | 与 #8 合并为同一个「文件」 |
| 15 | s4.keywordEnabled | 删 | 同义反复 |
| 16 | s4.keyword | 保留 + 改名 | ① 取材 · 「关键词」 |
| 17 | s4.anchorFans | 合并 | ① 取材 · 深度里的「作者粉丝」 |
| 18 | s4.commentArea | 保留 | ① 取材 · 与「作者粉丝」并列的一个取材范围 |
| 19 | s4.commenterFans | 合并 | ① 取材 · 深度的第 2 层「评论者的粉丝」 |
| 20 | features.filterPrivate | 保留 | ② 只要这样的账号 |
| 21 | features.filterNoAvatar | 保留 | ② |
| 22 | features.regionCodes | 保留但置灰 | ② · 标「暂不支持」+ ⓘ 说明原因 |
| 23 | features.langRegion | 保留 | ② |
| 24 | features.nicknameCheck | 改名 + 归属 | ② · 「取样范围」（通杀/昵称/个签），挂在语言下面 |
| 25 | features.cloudDedupe | 保留 | ③ 去重 |
| 26 | features.cloudTable | 保留 | ③ 去重（选云端后才出现） |
| 27 | features.aiAvatar | 保留但置灰 | ② · 标「暂不支持」 |
| 28 | features.aiGender | 保留但置灰 | ②（依赖 #27） |
| 29 | features.aiAgeMax | 保留但置灰 | ②（依赖 #27） |
| 30-37 | features.{follow,fans,likes,videos}{Min,Max} | 保留 | ② 数值门槛（8 个，一行一个区间） |
| 38 | features.extractLimit | 保留 | ③ 输出 |
统计：删 5、合并 7、改名 6、置灰 3、原样保留 17（= 38）。 没有一个字段是"想不出来才删的" —— 每一条删/合并都对应 §1 里的一个具体问题。
5. 两档落地
A 档 · 只清语义，不动结构（保守）
保留四张卡、单选、功能设置卡。做 6 件事：
- 删掉 4 个同义反复的开关（§1.1）→ 直接消除"关掉它等于不选这张卡"的疑问
- 6 个"纯开关"逐个补上它缺的输入/选择，或改成"选了才出现的行"（§1.3）
- 两张卡的
enterPage分名：s1「取哪些列表」、s3「展开哪个列表」（§1.4） - 三个去重控件收到功能设置，只出现一次（§1.5）
- 功能设置按 A/B/C 三组重排；3 项置灰标「暂不支持」；改掉「提取区域」那句与控件不符的说明（§1.8）
- 修 s3/s4 的默认值（§1.9）
- 优点：改动局限在
page-id.js+store.js的文案与少量字段；配置迁移小；与规格书差距小。 - 缺点：§1.2（s1 塞了三个起点）、§1.10（不能组合）依然存在。 用户仍然要面对"四选一"，而脚本一仍然是个"万能卡"。
B 档 · 改成三段式（推荐）
按 §3 重做页面结构：取材清单 + 过滤 + 输出。
- 优点：一次性解决 §1.1–1.10 全部十条。多了一个真实能力：多种取材组合成一轮运行。
- 缺点：① 与规格书 C1–C5 的画板结构偏离较大（需要你明确授权偏离）；
② 取材是不定长列表，
Store.FIELDS那套"一项一控件"的标量表放不下， 要新建一个Sources模块（照Records的先例：另一个 storage key，不塞进字段表）； ③ 要做 v6 → v7 迁移（把四张卡的checked翻译成"一条取材"，我已有完整的映射方案）。
推荐：先 A 后 B，但只把 A 当作过渡
A 档的 6 件事里有 4 件是 B 档的前置工作（删同义开关、补纯开关的输入、去重收口、置灰标注）， 做了不浪费。但如果只能做一档，选 B —— A 档做完，用户最不满的那条（"想同时抓两种来源"） 仍然无解。
6. 迁移（仅 B 档需要，v6 → v7）
现有用户配置按"当时勾的是哪张卡"翻译成一条取材，一个字段都不丢：
| 旧状态 | 新配置 |
|---|---|
| s1 选中 | 取材 #1：起点=指定账号，账号=anchorIds，取=enterPage 对应的列表 |
s1 选中 且 useTextId=true |
取材 #1：起点=文本文件，文件=textIdPath |
s1 选中 且 customPage=true |
取材 #1：起点=搜索结果·用户（关键词留空，启动时要求补） |
| s2 选中 | 取材 #1：起点=评论区，视频来源=当前屏幕 |
| s3 选中 | 取材 #1：起点=文本文件，文件=fissionTextPath，深度=enterPage |
| s4 选中 | 取材 #1：起点=搜索结果·视频，关键词=keyword；深度按三个开关逐项映射 |
dedupeEnabled / uidDedupe / 云端三项 |
统一映射到 ③ 的去重 |
| 四张卡都未选 | 取材清单为空 → 启动时拦住「请先添加一条取材」（与现在的 F1 弹窗同形） |
迁移必须幂等（跑两次结果一样）且可回退（旧字段保留不删，只做读取时翻译）。
7. 待拍板
- 走 A 档还是 B 档？（推荐 B；A 只当过渡）
- 允许偏离规格书 C1–C5 的画板结构吗？ —— B 档必然偏离。 规格书是"可执行规格"，但它记录的是控件，没记录行为；本次重整的价值恰在行为。
- "暂不支持"的 4 项（区域 + AI 三项）：置灰保留（推荐），还是从界面删掉？ 置灰+ⓘ 的好处是用户知道"以后会有"，坏处是界面仍有一行用不了的东西。
- 深度最多 2 层这个限制接受吗？（推荐接受，理由在 §3.1）
- 取材条数上限给几条？（我建议 5 条，够覆盖全部组合，也不至于让页面长到滚不完）
8. 与 PLAN_id_extract.md（执行方案）的关系
两份文档是互相印证的，不是重复：
- 执行方案里把四个脚本抽象成 6 种取材源，是因为只能那样才能写出可执行的流程；
- 本文反过来证明：执行层不得不做的抽象，正好说明界面的分类维度错了。
- 执行方案里"被迫猜的三处语义"（主播 ID 留空 /
customFansPage/ 裂变）， 在本文 §3 里全部变成明确的行为定义 —— 两处文档要么一起改，要么一起不改。
若采纳 B 档，执行方案的哪些结论会变：
| 执行方案里的内容 | B 档下是否需要改 |
|---|---|
| 6 种取材源抽象 | 不变，它已经是三段式的直接映射 |
engine-config.json 的 id.source 单对象 |
要改：变成 id.sources 数组 |
| 14 项功能设置的分级（A/B/C） | 不变 |
产物与去重（uid_*.txt + uid_extracted.txt） |
不变 |
| 分阶段实施 P0–P5 | 不变，但 P3 的"只做脚本一"改为"只做一条取材（指定账号）" |
| 界面侧 6 处改动 | 要改：buildIdConfig 从读 4 张卡变成读取材清单 |
附：一页对照
旧（四张卡 × 互斥） 新（三段式 × 可累加）
───────────────────────── ─────────────────────────
脚本一 · 粉丝页提 ID ┐
├ 自定关注或粉丝页面 ✓ │ ① 取材（可多条，串行）
├ 自定页面 ✗ │ 起点[指定账号] 账号[__] 取☑粉丝☑关注
├ 主播去重 ✓ + 模式 │ 起点[文本文件] 文件[__] 深度☑粉丝
├ 进入页面=粉丝页 │ 起点[搜索视频] 关键词[__] 深度☑作者☑评论区
├ 主播 ID [__] │
└ 使用文本 ID ✗ + 路径 ┘ ② 只要这样的账号
脚本二 · 评论页提 ID ☑私密 ☑无头像 语言[通杀] 取样[昵称+个签]
├ 自定评论页面 ✓ ┐ 区域[暂不支持ⓘ]
└ 提取评论的人的粉丝 ✗ │ 关注量[0]~[500000] 粉丝量[0]~[500000]
脚本三 · 文本 UID 裂变 │ 获赞量[0]~[500000] 视频量[0]~[500000]
├ 文本 UID 裂变提 ID ✗ │
├ UID 博主去重 ✓ │ ③ 输出
├ 进入页面=关注页 │ 提取满[0]个后停止
└ 裂变文本 [__] │ 去重 ☑本地 ☐云端
脚本四 · 关键词视频 │ 文件 uid_20261017_1100.txt（自动）
├ 关键词视频提 ID ✗ │
├ 关键词主播 [fashion] │ ← 10 个纯开关 → 0 个
├ 关键词提取主播粉丝 ✗ │ ← 3 处去重 → 1 处
├ 关键词提取评论区 ✗ │ ← 2 个同名不同义的"进入页面" → 各自分名
└ 关键词提取评论的人的粉丝 ✗ ┘ ← 单选约束 → 消失（本来就该串行）
─────────────────────────
功能设置 14 项（混了过滤/检测/待支持三种性质）