VOICE CATALOG HANDOFF

音色维护，不是把 ID 塞进列表

我们现在维护的是一份可回溯的音色目录：原始数据要留住，展示状态要可控，翻译和关键词要经过处理。新增音色可以很多，但进首页下拉框的必须是被明确放行的那一批。

125 当前 catalog 总数
61 首页下拉会展示
40 官方 Best for v3
0 当前重复 voice id
DATA FLOW

先留原始数据，再生成前端目录

这套流程最重要的边界是：`voices2.json` 像原始档案，`voices.json` 才是给前端用的整理稿。不要把试听失败、隐藏、V3 风险这些判断写丢。

VOICE ADDITION PIPELINE ElevenLabs API 按 voice id 查询 voices2.json 保留原始字段 整理与判断 翻译、提取、V3 风险 voices.json 前端可读目录 人工试听 决定展示或隐藏 首页音色下拉 只读被放行的音色 LEGEND 需要人工判断的关键点 落到文件的数据

真正要保护的是中间那一步：翻译、关键词、V3 风险、展示状态都在这里定。后台化也应该围绕这一步做审核，而不是绕过它。

DISPLAY SWITCHES

这几个开关别混用

前端展示条件很短，但含义很细：官方推荐、手动放行、人工隐藏，要分开表达。

字段 该怎么用 容易踩的坑
bestForV3 只给最早官方 Best for v3 集合。 手动试听通过，也不要把它改成 true。
showInVoiceSelector 非官方集合里，人工确认要展示的音色。 这是手动放行开关，不是 V3 官方认证。
hidden 保留元数据，但首页不展示。 不要删除历史音色。隐藏比删除更好回滚。
versionTag 标记 ASMR、broadcast_v2 这类版本或批次。 不要写进 displayName，用户会看到。
v3CloneTypeAssessment 标记 designed_voice、pvc_risk 或 unknown。 它是风险提示，不是绝对结论。
(voice.bestForV3 || voice.showInVoiceSelector) && !voice.hidden
CURRENT GROUPS

当前目录里有五类来源

来源 范围 总数 展示 说明
官方 Best for v3 首批 1-40 40 25 bestForV3: true，但仍允许人工隐藏。
手动追加候选 41-86 46 13 试听通过才设置 showInVoiceSelector。
手动追加 ASMR 87-93 7 7 versionTag: "ASMR"，可被搜索命中。
Voice Design V1 1000-1015 16 0 历史实验保留，当前不展示。
Broadcast V2 设计音色 1100-1115 16 16 正式采用的设计音色，标记 designed_voice。
NORMALIZATION

从原始字段到用户能看懂的字段

原始数据要完整

  • voice_id、name、category、preview_url 必须留。
  • verified_languages 要保留每个语种的试听入口。
  • usage_character_count_1y 和 cloned_by_count 用于排序和热度参考。

前端字段要克制

  • displayName 尽量单名，方便记忆。
  • subtitle 放关键词，少重复主标题。
  • 新增风格词要同步中文映射，否则前端搜得到但看不懂。
CURRENT PRACTICE

现在不是固定脚本一键决定

当前更接近半自动：脚本负责查询和批量整理，模型按既定规则辅助翻译、提取和判断，最后由人工试听确认展示状态。

处理项 现在怎么做 后台化后怎么做
displayName 按规则和人工判断改成单名，复杂名称会被简化。 自动给建议，后台允许人工改。
subtitle 从 name、description、style 里提关键词，再人工调整。 自动提取关键词，人工确认是否重复或不准。
标签翻译 新词需要同步到前端映射表。 维护一份后台词典，运营可补中文名和同义词。
V3 风险 按来源和 category 判断，professional 标记为 pvc_risk。 系统自动提示风险，但展示与否由人工确认。
source_order 按批次手动分配连续区间。 后台按批次自动分配，也允许管理员微调。
versionTag 按本次来源手动写 ASMR、broadcast_v2 等。 新增时选择批次标签，发布后写入 catalog。

关键判断：模型适合做第一版建议，不适合直接决定线上展示。音色这件事有主观试听和业务偏好，后台必须给人修改入口。

ADMIN CONFIG

做成后台可配置，可行，但不要全自动上线

这件事适合做成后台流程。难点不是把 ID 写进文件，而是把 API 原始信息变成可展示、可搜索、可回滚的目录项。

STEP 1

ID 导入

运营粘贴一批 voice id。后台拉 ElevenLabs 原始信息，先写 raw snapshot，不直接展示。

STEP 2

自动预处理

生成 displayName、subtitle、中文标签、V3 风险、source_order 和 versionTag 建议值。

STEP 3

人工审核发布

页面内试听多语种，修改翻译，选择显示或隐藏。最后再发布到前端目录。

建议做法：后台负责拉取、预处理、差异预览和审核记录；人工负责试听和最终放行。这样既省掉重复手工处理，也不会把质量判断交给规则硬猜。

ADMIN UI

后台应该让人能管完整目录

后台不是只做新增入口。它应该覆盖“看全量、听效果、改字段、设状态、发上线”的完整维护动作。

能力 页面里要能做什么 建议状态
全量音色列表 按语言、性别、年龄、来源批次、展示状态、V3 风险、标签搜索和筛选。 必做
多语种试听 展示默认试听和 verifiedLanguages 里的不同语种试听，页面内播放暂停。 必做
字段编辑 编辑 displayName、subtitle、语言、年龄、性别、风格、用途、标签翻译。 必做
上线状态 设置显示、隐藏、待审核。显示时写 showInVoiceSelector，隐藏时保留原因。 必做
手动新增 支持粘贴单个或批量 voice id，拉取失败时保留错误信息，允许重试。 必做
删除 默认做软删除或归档，不物理删除 raw。只有草稿和误导入可硬删除。 建议
发布预览 发布前看到新增、修改、隐藏、删除的 diff，以及展示数量变化。 必做
SUGGESTED MODEL

如果后台化，可以这样拆数据

表或配置 放什么 为什么要分开
voice_raw_sources API 返回原文、抓取时间、来源 URL、请求批次。 以后翻译规则变了，可以重新生成 catalog。
voice_catalog_entries 前端字段、展示状态、排序、中文标题、副标题。 首页只读整理后的稳定数据。
voice_review_events 谁改了显示状态、隐藏原因、版本标记和备注。 避免“为什么这个音色不见了”查不回来。
voice_label_dictionary Energetic、ASMR、Whisper 等词的中文映射。 新增关键词不需要每次改前端代码。
GUARDRAILS

后台发布前要拦住这些事

  • 同一个 voice_id 只能有一条 catalog 记录，重复导入只更新 raw 或进入待确认。
  • bestForV3 只能由官方集合导入产生，后台不提供随手勾选。
  • category: professional 默认提示 V3 风险，不能静默进入展示列表。
  • 发布前展示 diff：新增几条、隐藏几条、展示数量从多少变多少。
  • 每次发布保留版本快照，回滚要比重新手改 JSON 更快。
DEVELOPER NOTE

给开发的短版结论

音色维护可以后台化。MVP 不必先做复杂运营系统，先做“ID 导入 + raw 保存 + 自动预处理 + 人工审核 + 发布快照”就够。核心原则是：raw 永远留住，catalog 可以重算；展示状态必须可审计；翻译和关键词可以机器建议，但最终由人确认。