# VOC 报告 LLM 提示词配置
# ─────────────────────────────────────────────────────────────
# 业务员修改指南：
#   1. 直接编辑本文件中的 system / user_template / 子模板
#   2. 保留 {{占位符}} 不动（运行时自动填入聚类数据等）
#   3. 保存后重新运行 build_report.py 或 run_pipeline.py 即可生效
#   4. 勿改 JSON 输出字段名（如 personas、themes、kano），否则报告解析失败
# 说明文档（业务员改）：提示词编辑稿.md
# 方法论依据：VOC分析方法论与报告生成逻辑.md v1.0
# ─────────────────────────────────────────────────────────────

meta:
  version: "1.2"
  updated: "2026-06-12"
  disclaimer: |
    本文件中的中文/英文示例仅说明输出格式与分析逻辑。
    实际 Persona、主题名、keywords、场景、KANO 条目、根因须来自当前批次聚类数据与注入 JSON，禁止照搬示例文字。

# ── 0. 产品/行业自动识别（pipeline 产品名为空时）──
product_detect:
  temperature: 0.2
  max_tokens: 1000
  system: |
    你是亚马逊商品识别专家。根据用户评论内容推断产品名称和所属行业。输出严格JSON，不输出多余文字。
  user_template: |
    根据以下亚马逊评论内容和目录名，推断产品名称和所属行业。

    ## 评论样本
    {{sample_text}}
    {{dir_info}}
    ## 输出JSON
    {"product_name": "推断的产品名称（中英文均可，简洁描述，如 Kitchen Blender / Pet Repellent Spray）", "industry": "所属行业（中文，如 个人护理/宠物用品/厨房家电/健康补充剂 等）"}

    要求：
    - product_name 用评论中高频提及的核心产品词命名，不用品牌名或 ASIN；不要包含行业大类词
    - industry 用一个中文行业大类词
    - 目录名中的关键词可作为重要参考线索
    - JSON 示例仅说明格式，product_name 须从上方评论样本归纳

# ── 1. 用户画像 Persona ──
persona:
  temperature: 0.4
  max_tokens: 8000
  system: |
    你是资深的消费者洞察专家，严格遵循 VOC 分析方法论 v1.0 第 3.2 节与 4.0 节。
    Persona 命名用简洁中文（≤6字），避免营销化夸张名称。输出严格JSON。
    示例仅说明格式；Persona 名与 keywords 须来自当前聚类 top_phrases 与 sample_reviews，禁止照搬示例。
  user_template: |
    ## 任务：基于聚类数据按三维度发现用户画像（Persona），4-7 个。

    ## 分析产品（product_detect / config 已识别，Persona 须针对该品类）
    产品：{{product_name}} | 行业：{{industry}}
    purchase_motivation 用「雇佣{{product_name}}完成…」JTBD 句式；Persona 痛点/需求须与该产品使用场景一致，禁止脱离品类写无关人群。

    ## 三维度强制覆盖（缺一不可）
    A. 物理/生理/受众特征 → 从 catalog 中 suggested_dimension="A" 的簇中选择
       典型信号：特定体质/肤质/年龄/体型/使用对象（如 sensitive skin / coarse hair / pregnant / bikini area）
    B. 行为/使用场景 / 具体痛点 → 从 catalog 中 suggested_dimension="B" 的簇中选择
       典型信号：travel / first time / pulls hair / battery dead / durability
    C. 购买动机/背景 → 从 catalog 中 suggested_dimension="C" 的簇中选择
       典型信号：switched from / saw on social media / too expensive
    → 每个 Persona 必须同时绑 B 或 C 维的具体痛点/需求簇，用于精准计算占比。

    ## 自我标注信号强制检查（归纳后必做）
    在绑定簇的 top_phrases / sample_reviews 中搜索以下模式，出现 ≥5 条且 eligible_physio_labels 达标时才可建对应生理 Persona：
    - "I have [adj] [noun]"（如 I have sensitive skin）
    - "My [noun] is/are [adj]"
    - "As a [noun]"
    - 若 eligible_physio_labels 为空或不包含对应维度，禁止在名称/core_pain 写生理标签

    ## 其他遗漏检查
    - 长期使用/复购用户：含 after months / second bottle / bought again 的差评是否形成独立群体
    - 占比低（~5%）但痛点独特、无法被其他 Persona 代表的群体，仍须单独列出

    ## 可绑定的聚类簇目录（cluster_refs 必须从中选择）
    每簇含：semantic_label、suggested_dimension（A/B/C建议维度）、eligible_physio_labels（仅≥5条佐证的生理维度）、top_phrases、sample_reviews
    {{catalog_json}}

    ## 生理标签硬规则（进 LLM 前已过滤，仅 eligible_physio_labels 中的维度可用于命名）
    - catalog 仅展示 eligible_physio_labels（评论佐证≥5条）；未出现的生理标签禁止写入名称或 core_pain
    - top_phrases 仅出现 1–4 次不算数；不得凭品类常识脑补
    - sample_reviews 为溯源原文，core_pain 只能归纳其中明确出现的内容

    ## 补充聚类摘要
    audience_clusters: {{audience_clusters_json}}
    global_pains: {{global_pains_json}}
    global_negative: {{global_negative_json}}
    global_positive: {{global_positive_json}}

    ## 输出JSON
    {"personas":[{"name":"≤6中文字","dimension":"A","cluster_refs":{"A":{"stage":"3b_aspect_opinion_negative","label":2},"B":{"stage":"3b_aspect_opinion_negative","label":5},"C":{"stage":"3a_pain_global","label":1}},"keywords":["从绑定簇 top_phrases 复制"],"core_pain":"核心痛点（≤3条，分号分隔）","core_need":"核心需求（≤3条，分号分隔）","purchase_motivation":"雇佣产品做什么（动词+宾语，JTBD句式）"}]}

    ## 硬性要求
    - 每个 Persona 必须有 cluster_refs；A/B/C 三维均从 suggested_dimension 匹配的簇中选择
    - A 维 stage 允许: 3a_pain_global / 3b_aspect_opinion_negative / 3b_aspect_opinion_positive（从 suggested_dimension="A" 的簇中选）
    - B 维 stage 允许: 3a_pain_global / 3b_aspect_opinion_negative / 3b_aspect_opinion_positive（从 suggested_dimension="B" 的簇中选）
    - C 维 stage 允许: 3a_pain_global / 3b_aspect_opinion_negative / 3b_aspect_opinion_positive（从 suggested_dimension="C" 的簇中选）
    - 每个 Persona 必须至少绑 1 个 B 或 C 维簇（具体痛点/需求/场景），用于 keyword 过滤占比
    - cluster_refs 各维 label 必须是上方 catalog 中存在的 label；绑定前先看 semantic_label 与 suggested_dimension
    - 系统以 A 维锚点簇 + B/C 维 keywords 过滤计算占比
    - dimension 表示该 Persona 主类型（A/B/C 之一）；cluster_refs.A 始终必填
    - keywords 至少 5 个，必须从所有已绑定簇的 top_phrases 复制英文片段（≥3字符），禁止编造不在簇中的词
    - 4-7 个 Persona，三维度 A/B/C 均至少覆盖 1 个；小簇（<15条）仅在有明确短语证据时使用
    - core_pain 来自该群体差评语义；core_need 来自该群体好评或诉求；purchase_motivation 用「雇佣产品完成…」句式
    - 命名须从聚类归纳；生理类命名仅当 eligible_physio_labels 含对应维度时才允许
    - 禁止在 eligible_physio_labels 未列出的生理标签写入名称或 core_pain

# ── 2. 差评/好评主题 ──
theme:
  temperature: 0.3
  max_tokens: 8000
  system: |
    你是亚马逊 VOC 分析专家，遵循方法论 3.3 节。
    从聚类短语归纳主题；根因/失效机制不同的问题必须独立成主题，禁止笼统合并。
    主题名用简洁中文（≤8字），适用于任意品类。输出严格JSON。
    示例仅说明拆分逻辑；主题名与 keywords 须来自当前聚类数据，禁止照搬示例主题名。
  negative_extra: |
    ## 优先级（共 {{neg_review_count}} 条差评，系统会按实际频次与竞品覆盖率重算）
    - P0：频次 ≥ {{p0_threshold}} 条 且 80%+ 竞品均出现
    - P1：频次为差评总数 10–20% 且 60%+ 竞品出现
    - P2：频次为差评总数 3–10% 且 40%+ 竞品出现

    ## 拆分红线（方法论 3.3）
    判断问题：「同一主题下的差评，是否描述同一个物理/工程原因？」若不是，必须拆开。
    典型拆分（机制/根因不同须拆开，勿照搬下列中文名）：
    - 核心效果未达预期 → ①效果弱/不明显 ②使用方式与预期不符（机制不同）
    - 使用过程不适 → ①物理伤害/刺激 ②过热/异味/过敏（根因不同）
    - 产品失效/损坏 → ①供电/充电问题 ②结构件断裂/脱落（失效环节不同）
  user_template: |
    ## 任务：归纳 {{theme_type}} 主题（适用于当前品类，勿预设具体产品类型）
    {{extra_block}}

    ## 归纳原则
    - 从 top_phrases 中归纳 4–8 个主题，差评主题应覆盖 80%+ 差评内容（长尾可合并为「其他」）
    - keywords 语义相近但失效机制不同 → 必须拆成独立主题
    - 好评主题可与差评维度对应但用正向表述（如 核心使用体验 ↔ 核心效果未达预期）
    - 示例主题名仅作格式与拆分参考；实际 name/keywords 必须来自上方 cluster 数据的 top_phrases

    ## 数据
    {{cluster_data_json}}

    ## 输出JSON
    {"themes":[{"name":"≤8中文字","keywords":["english phrase from top_phrases"],"priority":"P0/P1/P2（仅差评）","description":"差评必填：与相近主题的根因拆分理由，格式「与XX根因不同：…」；好评可写满意点一句话"}]}

    ## 硬性要求
    - keywords 必须是英文，从 top_phrases 中复制完整片段或逗号后的子句（≥3字符）
    - 每个主题至少 5 个 keywords
    - 差评 priority 按上方门槛初步标注（系统会重算）
    - 差评示例（格式参考，须从 top_phrases 归纳）：效果未达预期、使用不适、供电失效、结构损坏、性价比低
    - 好评示例（格式参考）：核心使用体验、产品质量耐用、便携与设计、易用性、超预期惊喜

# ── 3. KANO 需求分类 ──
kano:
  temperature: 0.3
  max_tokens: 8000
  system: |
    你是产品需求分析专家，专精 KANO 模型，遵循方法论 4.1 节。
    四象限分类；每个条目 5 字段缺一不可。输出严格JSON。
    KANO 示例仅说明四象限判断；item/evidence 须来自当前差评/好评主题 keywords，禁止照搬示例。
  reverse_search_block: |
    ## 反向型主动搜索（步骤三，不得以「未发现」一笔带过）
    在差评/好评主题 keywords 中检索以下词组及同义表达，记录出现频次：
    - 过于复杂：too many parts / too complicated / confusing / hard to use
    - 过于嘈杂：too loud / so loud / noise / noisy
    - 功能多余：don't need / unnecessary / didn't ask for / useless feature
    - 操作繁琐：takes too long / too many steps / annoying to clean
    处理规则：
    - 任一词组频次 ≥5 → 输出 reverse 类型条目并附 evidence
    - 全部词组总频次 <5 → 必须输出 1 条 type=reverse 的占位条目，item 写「本品类暂无明确反向需求」，evidence 写「经主动搜索 [列出搜索词]，共 N 条，低于阈值 5」
  user_template: |
    ## 任务：KANO 四象限分类

    ## 分类标准（含常见误判）
    - 基本型 Must-be：P0 级差评 + 好评中几乎无人因「做到了 X」而表扬
      ❌ 误判：核心性能指标（好坏都会被提及）→ 期望型
      ✅ 正确：开箱即能用、供电正常、关键部件不脱落
    - 期望型 Performance：好评差评均出现，做得越好评分越高
      ❌ 误判：续航/容量 → 基本型（超长续航会被特别称赞）
      ✅ 正确：核心效果、续航/容量、易清洁程度
    - 魅力型 Attractive：好评中出现 love/obsessed/amazing/didn't expect/bonus；差评中几乎不出现
      ❌ 误判：附赠配件 → 期望型（无人因缺该配件差评）
      ✅ 正确：电量/状态显示、超预期配件、意外惊喜功能
    - 反向型 Reverse：用户主动抱怨某「功能」是负担（功能过载/太吵/太复杂）
      ❌ 误判：产品损坏/充电故障 → 基本型（无人「希望产品损坏」）

    {{reverse_search_block}}

    ## 操作步骤
    1. 基本型：从 P0/P1 差评主题出发，检查好评是否几乎无人表扬该点
    2. 期望型 vs 魅力型：差评有人因「不够好」→ 期望型；好评有 love/amazing 且竞品普遍缺失 → 魅力型
    3. 反向型：执行上方主动搜索，按规则输出

    ## 差评主题
    {{neg_themes_json}}
    ## 好评主题
    {{pos_themes_json}}
    ## Persona
    {{personas_json}}

    ## 输出JSON
    {"kano":[{"type":"must-be/performance/attractive/reverse","item":"单条需求（动词+名词，禁止用逗号/顿号合并多条）","evidence":"评论频次证据+代表性英文片段（≤80字）","affected_persona":"主要 Persona","reason":"≤60字，解释为何是该类型而非其他类型","competitor_status":"竞品是否满足及满足程度"}]}

    ## 硬性要求
    - 每条 item 只写一条需求，禁止在 item 中用逗号合并
    - 至少 8 条记录；must-be / performance / attractive 均需覆盖；reverse 按搜索规则输出（含占位条目）
    - evidence 须含频次级别（如 P0/P1）或条数估计 + 英文原文片段
    - 质量缺陷、充电故障、配件脱落 → must-be，不是 reverse
    - reverse 仅限用户主动排斥功能过载（too many parts / too complicated / too loud 等）

# ── 4. JTBD 动机框架 ──
jtbd:
  temperature: 0.3
  max_tokens: 8000
  system: |
    你是 JTBD 分析专家，遵循方法论 4.2 节。
    为每个 Persona 构建 Jobs To Be Done 框架；所有动机字段须能从 Persona 的 keywords/core_pain/core_need/purchase_motivation 中找到语义佐证。
    无佐证时该字段填 "-"。必须覆盖全部 Persona。输出严格JSON。
  user_template: |
    ## 任务：为 {{persona_count}} 个 Persona 构建 JTBD
    {{personas_json}}

    ## 填写规则
    | 字段 | 规则 |
    | core_job | 动词+宾语，用户想完成的任务；须与 Persona 数据语义一致 |
    | functional_motivation | 实用层面驱动（效率/效果/成本/便携），禁止写情感词 |
    | emotional_motivation | 情绪/心理驱动（自信/焦虑/掌控感/安心），禁止写功能词 |
    | social_motivation | 他人视角/社交驱动（如送礼、伴侣评价、公开场合）；无评论佐证填 "-" |
    | trigger | 购买触发时机，须来自 Persona 数据中的具体事件描述；无佐证填 "-" |

    ## 输出JSON
    {"jtbd":[{"persona":"名称","core_job":"核心Job","functional_motivation":"功能性动机","emotional_motivation":"情感性动机","social_motivation":"社会性动机或-","trigger":"触发时机或-"}]}

    ## 硬性要求
    - 必须覆盖全部 {{persona_count}} 个 Persona，一人一行
    - functional 与 emotional 字段内容不可互换
    - 所有字段（含 core_job / trigger）须与对应 Persona 的 keywords / core_pain / core_need / purchase_motivation 语义一致
    - 无法从 Persona 数据找到佐证的字段一律填 "-"，禁止编造评论中无依据的内容

# ── 5. 人群×场景×需求矩阵 ──
matrix:
  temperature: 0.3
  max_tokens: 8000
  system: |
    你是消费者洞察专家，构建人群×场景×需求矩阵，严格遵循方法论 4.3 节与 5.3 节场景规则。
    场景只允许填写评论中有原词佐证的描述；找不到佐证则不输出该行。
    输出严格JSON。全市场均分低时，细分场景「高满意度」须谨慎标注。
    场景示例仅说明格式；scene 须来自 Persona keywords 中的英文原词佐证，禁止照搬示例。
  market_low_hint: |
    ## 重要：全市场加权均分 {{market_avg}}（<3.5），多数场景 satisfaction 应为「中等」或「低」，慎用「高」。
  user_template: |
    ## 任务：为以下 Persona 构建矩阵（仅输出这些 Persona，最多 4 个）

    ## 场景规则（方法论 5.3，核心规则）
    【强制】scene 只允许填写 Persona 的 keywords / 聚类短语中能找到英文原词佐证的场景。
    禁止基于产品功能、品类常识或逻辑推断填写场景。
    - ≥5 条评论出现该场景词 → 可填写（如 travel / outdoor / kitchen / office — 以 top_phrases 为准）
    - 2–4 条 → 不输出该行
    - <2 条 → 不输出该行（禁止输出 scene 为 — 的行）

    错误示例：
    - 日常使用（daily 是使用频率非场景）
    - 节日前突击（评论无对应原词）
    - 任何场所（泛化代替留空）
    正确示例：具体地点/情境（须在 keywords 中找到英文原词且 ≥5 条）

    ## 需求列映射
    - must_be_needs：KANO 基本型 + 该群体 P0 差评主题名
    - performance_needs：KANO 期望型 + 该群体 P1 差评主题名
    - attractive_needs：KANO 魅力型 + 该群体好评加分点

    ## 满意度评级
    - 高：该群体均分参考 ≥4.0
    - 中等：3.3–3.9
    - 低：＜3.3

    ## 每个 Persona 最多 2 个有效场景行
    {{market_hint}}
    {{top_personas_json}}
    {{kano_json}}
    ## 总评论数: {{total_reviews}} · 全市场均分: {{market_avg}}

    ## 输出JSON
    {"matrix":[{"persona":"名称","pct":35,"scene":"具体场景（须有评论原词佐证）","must_be_needs":"基本型关键词","performance_needs":"期望型关键词","attractive_needs":"魅力型关键词","satisfaction":"高/中等/低","satisfaction_note":"≤25字"}]}

    ## 硬性要求
    - 禁止输出 scene 为 —、-、N/A 或空的行
    - 每个 Persona 最多 2 行；全报告最多 4 个 Persona
    - must_be_needs / performance_needs / attractive_needs 各 ≤12 字，用顿号分隔关键词，禁止完整句子
    - must_be_needs 须使用差评主题中文名（来自当前批次主题，非示例）
    - satisfaction_note ≤25 字

# ── 6. 痛点根因分析 ──
rootcause:
  temperature: 0.4
  max_tokens: 8000
  system: |
    你是产品工程与消费者洞察专家，遵循方法论 4.4 节。
    痛点根因分析须从现象到达机制层（非「质量差」类空话）；开发方向须可落地。
    分析对象是当前品类主产品（见用户消息），禁止把其他品类工具问题当作本产品根因。
    输出严格JSON，使用中文。
    根因示例仅说明分析深度；title/mechanism/dev_direction 须针对当前产品与注入主题，禁止照搬示例。
  user_template: |
    ## 任务：{{persona_name}} 的痛点根因分析（2-3 条，针对 P0/P1 级痛点）

    ## 产品范围：{{product_name}}（行业：{{industry}}）
    ## 分析边界：只分析该品类产品本身的结构/功能/体验缺陷

    ## 分析框架（每条根因）
    根因标题 → 导致后果（关联差评主题×频次）→ 失效机制（从结构/材料/工作原理解释）→ 可落地改进

    ## 层次要求
    - ❌ 现象层：「产品质量差」「用户体验不好」
    - ✅ 机制层：「密封/接口设计不足导致进水腐蚀」「关键部件角度/间距不当导致效果未达预期」

    {{persona_json}}
    {{bound_clusters_json}}

    ## 可用差评主题名（affected_themes 只能从中选择）
    {{theme_names_json}}

    ## 输出JSON
    {"root_causes":[{"title":"根因标题（≤20字）","mechanism":"失效机制（≤120字，白话，禁止医学/化学术语堆砌）","quote_keywords":["用于匹配评论的英文词"],"dev_direction":"可落地改进（≤80字：结构/材料/工艺/说明/品控等）"}],"affected_themes":["主题名"]}

    ## 硬性要求
    - quotes 字段不要输出（引用由系统从真实评论回填）
    - quote_keywords 每条根因 2-4 个**买家评论常见英文词/短语**（如 pull, dull, broke, charge, shower, waterproof, loud, trim, smooth, irritation, snag, waste），须与 mechanism 语义相关
    - quote_keywords 禁止生僻工程术语（如 O-ring、IPX7、DLC、magnetic charging、martensitic）；mechanism 可写工程细节，quote_keywords 必须像亚马逊买家口语
    - 优先从 bound_clusters 聚类 top_phrases 中选取真实出现的英文片段
    - affected_themes 只能使用上方差评主题名，优先 P0/P1 主题
    - dev_direction 须针对 {{product_name}} 可改进点
    - 每个 Persona 最多 3 条 root_causes

# ── 7. 情感关键词 ──
keyword:
  temperature: 0.3
  max_tokens: 8000
  system: |
    你是 VOC 文本分析专家，遵循方法论 3.4 节。
    为已统计好的差评/好评词组补充语境与极性标签；count 由系统提供不可修改。
    meaning 只写评论中明确出现的语境，禁止推断。输出严格JSON。
  user_template: |
    ## 任务：为下列词组补充「评论中使用语境」与「情感极性标签」（差评 ≤2★ / 好评 ≥4★，count 已按评论去重）

    ## 差评词组（≤2★，系统统计 count）
    {{neg_groups_json}}

    ## 好评词组（≥4★，系统统计 count）
    {{pos_groups_json}}

    ## Persona 列表
    {{personas_json}}

    ## 输出JSON
    {"negative":[{"id":"g0","words":"可微调英文词组展示","polarity_label":"强负面/负面","meaning":"≤50字语境","related_personas":["Persona名"]}],"positive":[{"id":"g0","polarity_label":"强正面/强正面情感/魅力型信号/正面场景/正面","meaning":"≤50字","related_personas":[]}]}

    ## 极性标签规则
    - 差评：强负面（割伤/拉扯/灼痛等）| 负面（其他抱怨）
    - 好评：强正面 | 强正面情感（love）| 魅力型信号（amazing/cute/附赠）| 正面场景（shower/travel）| 正面

    ## 硬性要求
    - 必须为输入中每个 id 各输出一条，不得遗漏；不得新增 id
    - 不得修改 count；words 可微调英文展示，须与 match_keywords 语义一致
    - related_personas 只能使用上方 Persona 名称；无明确关联时可填「全部群体」
    - meaning ≤50 字；禁止编造评论中未出现的内容