# VOC 报告 · 提示词编辑稿(业务员用) > **请你只改本文件。** 改完后交给技术同事,他会把内容同步到 `prompts.yaml` 并重新生成报告。 > **你不需要打开** `prompts.yaml`(那是程序用的配置文件)。 > **方法论依据:** `VOC分析方法论与报告生成逻辑.md` v1.0 --- ## 使用说明(3 步) 1. 在下方找到要改的**报告章节**(如「用户画像」「差评主题」) 2. 直接修改对应框里的**中文文字**(任务说明、硬性要求、示例等) 3. **不要删除** 带 `{{ }}` 的行——那是系统自动填入数据的占位符,例如: - `{{personas_json}}` = 自动填入用户画像列表 - `{{catalog_json}}` = 自动填入聚类数据 **请勿修改:** - JSON 格式示例里的英文字段名(如 `"personas"`、`"themes"`、`"name"`) - 所有 `{{xxx}}` 占位符整行 **可以修改:** - 「你是…专家」这类角色描述 - 「## 任务」「## 硬性要求」下的中文规则和示例 - 数量要求(如 4–7 个 Persona 改成 5–8 个) **示例边界(v1.2):** - 文中所有中文/英文示例**仅说明格式与分析逻辑** - 实际 Persona、主题名、keywords、场景、KANO、根因**须来自当前批次聚类数据**,禁止照搬示例文字 --- ## 章节与报告对照表 | 本文件章节 | 报告里看到的位置 | 同步到 prompts.yaml 的键名 | |-----------|-----------------|---------------------------| | 0. 产品识别 | (无单独章节,用于自动识别产品名) | `product_detect` | | 1. 用户画像 | 用户画像(Persona) | `persona` | | 2. 正负主题 | 正负反馈主题统计 | `theme` | | 3. KANO | KANO 模型需求分类 | `kano` | | 4. JTBD | JTBD 动机框架 | `jtbd` | | 5. 矩阵 | 人群 × 场景 × 需求矩阵 | `matrix` | | 6. 根因 | 痛点根因分析 | `rootcause` | | 7. 情感词 | 情感关键词分析 | `keyword` | --- # 0. 产品 / 行业自动识别 **同步位置:** `prompts.yaml` → `product_detect` | 参数 | 当前值 | 说明 | |------|--------|------| | temperature | 0.2 | 数值越小输出越稳定,一般不用改 | | max_tokens | 1000 | 最大输出长度,一般不用改 | --- ## 【角色设定】→ 粘贴到 `product_detect.system` ``` 你是亚马逊商品识别专家。根据用户评论内容推断产品名称和所属行业。输出严格JSON,不输出多余文字。 ``` --- ## 【任务说明】→ 粘贴到 `product_detect.user_template` ``` 根据以下亚马逊评论内容和目录名,推断产品名称和所属行业。 ## 评论样本 {{sample_text}} {{dir_info}} ## 输出JSON {"product_name": "推断的产品名称(中英文均可,简洁描述,如 Kitchen Blender / Pet Repellent Spray)", "industry": "所属行业(中文,如 个人护理/宠物用品/厨房家电/健康补充剂 等)"} 要求: - product_name 用评论中高频提及的核心产品词命名,不用品牌名或 ASIN;不要包含行业大类词 - industry 用一个中文行业大类词 - 目录名中的关键词可作为重要参考线索 - JSON 示例仅说明格式,product_name 须从上方评论样本归纳 ``` **占位符说明:** - `{{sample_text}}` — 系统自动插入评论样本,勿删 - `{{dir_info}}` — 系统自动插入文件夹名称,勿删 --- # 1. 用户画像 Persona **同步位置:** `prompts.yaml` → `persona` **报告章节:** 用户画像(Persona) | 参数 | 当前值 | |------|--------| | temperature | 0.4 | | max_tokens | 8000 | --- ## 【角色设定】→ 粘贴到 `persona.system` ``` 你是资深的消费者洞察专家,严格遵循 VOC 分析方法论 v1.0 第 3.2 节与 4.0 节。 Persona 命名用简洁中文(≤6字),避免营销化夸张名称。输出严格JSON。 示例仅说明格式;Persona 名与 keywords 须来自当前聚类 top_phrases,禁止照搬示例。 ``` --- ## 【任务说明】→ 粘贴到 `persona.user_template` ``` ## 任务:基于聚类数据按三维度发现用户画像(Persona),4-7 个。 ## 三维度强制覆盖(缺一不可) A. 物理/生理/受众特征 → 必须绑定 stage=1_audience 的簇 典型信号:特定体质/肤质/年龄/体型/使用对象(如 sensitive / elderly / for kids / large breed) B. 行为/使用场景 → 绑定 3b_aspect_opinion_positive / 3b_aspect_opinion_negative / 3a_pain_global 典型信号:travel / daily use / outdoor / first time / gift C. 购买动机/背景 → 绑定 3a_pain_global 或 opinion 簇 典型信号:switched from / saw on social media / first time / too expensive → 不能只有 B 和 C;A 维至少 1 个。若 A 维缺失,说明物理特征群体被遗漏,必须补建。 ## 自我标注信号强制检查(归纳后必做) 在绑定簇的 top_phrases 中搜索以下模式,出现 ≥5 条则必须单独建 Persona: - "I have [adj] [noun]"(如 I have sensitive skin / I have a large dog) - "My [noun] is/are [adj]"(如 My pet is very anxious) - "As a [noun]"(如 As a first-time buyer / As a pet owner) - 受众/体质/使用对象相关形容词(elderly / sensitive / indoor / outdoor) ## 其他遗漏检查 - 长期使用/复购用户:含 after months / after a while / second bottle / bought again 的差评是否形成独立群体 - 占比低(~5%)但痛点独特、无法被其他 Persona 代表的群体,仍须单独列出 ## 可绑定的聚类簇目录(cluster_ref 必须从中选择;每簇含 top_phrases + sample_reviews 最多 5 条原文) {{catalog_json}} ## 生理标签硬规则(名称 + core_pain,违反则系统会剔除) - 生理/体质类中文标签须在绑定簇内 ≥5 条评论原文含对应英文词(catalog 字段 physio_review_counts,如 pregnancy: 8) - top_phrases 偶然出现 1–4 次不算;无达标评论禁止写入 - core_pain 只能归纳 sample_reviews 中明确出现的内容 ## 补充聚类摘要 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_ref":{"stage":"1_audience","label":0},"keywords":["从绑定簇 top_phrases 复制"],"core_pain":"核心痛点(≤3条,分号分隔)","core_need":"核心需求(≤3条,分号分隔)","purchase_motivation":"雇佣产品做什么(动词+宾语,JTBD句式)"}]} ## 硬性要求 - 每个 Persona 必须有 cluster_ref;stage 只能是:1_audience / 3a_pain_global / 3b_aspect_opinion_negative / 3b_aspect_opinion_positive - cluster_ref.label 必须是上方目录中存在的 label;系统用该簇的 review_count 作为命中规模(非 keywords 扫全文) - dimension 只能是 A、B 或 C;A 维 Persona 的 cluster_ref.stage 必须是 1_audience - keywords 至少 5 个,必须从绑定簇的 top_phrases 复制英文片段(≥3字符),禁止编造不在簇中的词 - 4-7 个 Persona,三维度 A/B/C 均至少覆盖 1 个;优先选 review_count 较大的簇,小簇(<15条)仅在有明确短语证据时使用 - core_pain 来自该群体差评语义;core_need 来自该群体好评或诉求;purchase_motivation 用「雇佣产品完成…」句式 - 命名示例(格式参考,须从聚类归纳):敏感体质用户、首次购买用户、粗毛疤痕体质用户、旅行护理用户、蜡脱替代用户(禁止:受害者联盟、体验官、刮刀逃离者等夸张抽象名) - 禁止在 physio_review_counts 未达 ≥5 条时将「孕妇/孕期」写入名称或 core_pain ``` **占位符说明:** - `{{catalog_json}}` — 聚类簇目录(自动填入) - `{{audience_clusters_json}}` 等 — 聚类摘要(自动填入) --- # 2. 差评 / 好评主题 **同步位置:** `prompts.yaml` → `theme` **报告章节:** 正负反馈主题统计 | 参数 | 当前值 | |------|--------| | temperature | 0.3 | | max_tokens | 8000 | --- ## 【角色设定】→ 粘贴到 `theme.system` ``` 你是亚马逊 VOC 分析专家,遵循方法论 3.3 节。 从聚类短语归纳主题;根因/失效机制不同的问题必须独立成主题,禁止笼统合并。 主题名用简洁中文(≤8字),适用于任意品类。输出严格JSON。 示例仅说明拆分逻辑;主题名与 keywords 须来自当前聚类数据,禁止照搬示例主题名。 ``` --- ## 【差评专用补充】→ 粘贴到 `theme.negative_extra` (仅分析差评主题时使用,好评不走这段) ``` ## 优先级(共 {{neg_review_count}} 条差评,系统会按实际频次与竞品覆盖率重算) - P0:频次 ≥ {{p0_threshold}} 条 且 80%+ 竞品均出现 - P1:频次为差评总数 10–20% 且 60%+ 竞品出现 - P2:频次为差评总数 3–10% 且 40%+ 竞品出现 ## 拆分红线(方法论 3.3) 判断问题:「同一主题下的差评,是否描述同一个物理/工程原因?」若不是,必须拆开。 典型拆分(机制/根因不同须拆开,勿照搬下列中文名): - 核心效果未达预期 → ①效果弱/不明显 ②使用方式与预期不符(机制不同) - 使用过程不适 → ①物理伤害/刺激 ②过热/异味/过敏(根因不同) - 产品失效/损坏 → ①供电/充电问题 ②结构件断裂/脱落(失效环节不同) ``` **占位符说明:** - `{{neg_review_count}}` — 差评总数(自动填入) - `{{p0_threshold}}` — P0 优先级门槛(自动填入) --- ## 【任务说明】→ 粘贴到 `theme.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":"一句话说明该主题的用户抱怨/满意点"}]} ## 硬性要求 - keywords 必须是英文,从 top_phrases 中复制完整片段或逗号后的子句(≥3字符) - 每个主题至少 5 个 keywords - 差评 priority 按上方门槛初步标注(系统会重算) - 差评示例(格式参考,须从 top_phrases 归纳):效果未达预期、使用不适、供电失效、结构损坏、性价比低 - 好评示例(格式参考):核心使用体验、产品质量耐用、便携与设计、易用性、超预期惊喜 ``` **占位符说明:** - `{{theme_type}}` — 自动填 `negative` 或 `positive` - `{{extra_block}}` — 差评时自动插入上方「差评专用补充」 - `{{cluster_data_json}}` — 聚类短语数据(自动填入) --- # 3. KANO 需求分类 **同步位置:** `prompts.yaml` → `kano` **报告章节:** KANO 模型需求分类 | 参数 | 当前值 | |------|--------| | temperature | 0.3 | | max_tokens | 8000 | --- ## 【角色设定】→ 粘贴到 `kano.system` ``` 你是产品需求分析专家,专精 KANO 模型,遵循方法论 4.1 节。 四象限分类;每个条目 5 字段缺一不可。输出严格JSON。 KANO 示例仅说明四象限判断;item/evidence 须来自当前差评/好评主题 keywords,禁止照搬示例。 ``` --- ## 【反向型主动搜索】→ 粘贴到 `kano.reverse_search_block` (KANO 分析时自动插入) ``` ## 反向型主动搜索(步骤三,不得以「未发现」一笔带过) 在差评/好评主题 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」 ``` --- ## 【任务说明】→ 粘贴到 `kano.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 等) ``` **占位符说明:** - `{{reverse_search_block}}` — 自动插入上方「反向型主动搜索」 - `{{neg_themes_json}}` / `{{pos_themes_json}}` / `{{personas_json}}` — 前几步分析结果(自动填入) --- # 4. JTBD 动机框架 **同步位置:** `prompts.yaml` → `jtbd` **报告章节:** JTBD 动机框架 | 参数 | 当前值 | |------|--------| | temperature | 0.3 | | max_tokens | 8000 | --- ## 【角色设定】→ 粘贴到 `jtbd.system` ``` 你是 JTBD 分析专家,遵循方法论 4.2 节。 为每个 Persona 构建 Jobs To Be Done 框架;所有动机字段须能从 Persona 的 keywords/core_pain/core_need/purchase_motivation 中找到语义佐证。 无佐证时该字段填 "-"。必须覆盖全部 Persona。输出严格JSON。 ``` --- ## 【任务说明】→ 粘贴到 `jtbd.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 数据找到佐证的字段一律填 "-",禁止编造评论中无依据的内容 ``` **占位符说明:** - `{{persona_count}}` — Persona 个数(自动填入) - `{{personas_json}}` — Persona 列表(自动填入) --- # 5. 人群 × 场景 × 需求矩阵 **同步位置:** `prompts.yaml` → `matrix` **报告章节:** 人群 × 场景 × 需求矩阵 | 参数 | 当前值 | |------|--------| | temperature | 0.3 | | max_tokens | 8000 | --- ## 【角色设定】→ 粘贴到 `matrix.system` ``` 你是消费者洞察专家,构建人群×场景×需求矩阵,严格遵循方法论 4.3 节与 5.3 节场景规则。 场景只允许填写评论中有原词佐证的描述;找不到佐证则不输出该行。 输出严格JSON。全市场均分低时,细分场景「高满意度」须谨慎标注。 场景示例仅说明格式;scene 须来自 Persona keywords 中的英文原词佐证,禁止照搬示例。 ``` --- ## 【低分市场补充】→ 粘贴到 `matrix.market_low_hint` (仅当全市场加权均分 < 3.5 时自动插入) ``` ## 重要:全市场加权均分 {{market_avg}}(<3.5),多数场景 satisfaction 应为「中等」或「低」,慎用「高」。 ``` --- ## 【任务说明】→ 粘贴到 `matrix.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 字 ``` **占位符说明:** - `{{market_hint}}` — 低分市场时插入上方「低分市场补充」 - `{{top_personas_json}}` / `{{kano_json}}` — Persona 与 KANO 数据(自动填入) - `{{total_reviews}}` / `{{market_avg}}` — 评论总数与市场均分(自动填入) --- # 6. 痛点根因分析 **同步位置:** `prompts.yaml` → `rootcause` **报告章节:** 痛点根因分析(按 Persona 展开) | 参数 | 当前值 | |------|--------| | temperature | 0.4 | | max_tokens | 8000 | --- ## 【角色设定】→ 粘贴到 `rootcause.system` ``` 你是产品工程与消费者洞察专家,遵循方法论 4.4 节。 痛点根因分析须从现象到达机制层(非「质量差」类空话);开发方向须可落地。 分析对象是当前品类主产品(见用户消息),禁止把其他品类工具问题当作本产品根因。 输出严格JSON,使用中文。 根因示例仅说明分析深度;title/mechanism/dev_direction 须针对当前产品与注入主题,禁止照搬示例。 ``` --- ## 【任务说明】→ 粘贴到 `rootcause.user_template` ``` ## 任务:{{persona_name}} 的痛点根因分析(2-3 条,针对 P0/P1 级痛点) ## 产品范围:{{product_name}}(行业:{{industry}}) ## 分析边界:只分析该品类产品本身的结构/功能/体验缺陷 ## 分析框架(每条根因) 根因标题 → 导致后果(关联差评主题×频次)→ 失效机制(从结构/材料/工作原理解释)→ 可落地改进 ## 层次要求 - ❌ 现象层:「产品质量差」「用户体验不好」 - ✅ 机制层:「密封/接口设计不足导致进水腐蚀」「关键部件角度/间距不当导致效果未达预期」 {{persona_json}} {{per_aud_data_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 个英文词,须与 mechanism 直接相关 - affected_themes 只能使用上方差评主题名,优先 P0/P1 主题 - dev_direction 须针对 {{product_name}} 可改进点,禁止:传感器、纳米、AI、蓝牙等专业/科幻表述 - 每个 Persona 最多 3 条 root_causes ``` **占位符说明:** - `{{persona_name}}` / `{{product_name}}` / `{{industry}}` — 当前分析对象(自动填入) - `{{persona_json}}` / `{{per_aud_data_json}}` / `{{theme_names_json}}` — 画像与主题数据(自动填入) --- # 7. 情感关键词 **同步位置:** `prompts.yaml` → `keyword` **报告章节:** 情感关键词分析 | 参数 | 当前值 | |------|--------| | temperature | 0.3 | | max_tokens | 8000 | --- ## 【角色设定】→ 粘贴到 `keyword.system` ``` 你是 VOC 文本分析专家,遵循方法论 3.4 节。 对差评/好评词组做细粒度极性标注;meaning 只写评论中明确出现的语境,禁止推断。 优先标注有决策价值的情感词组。输出严格JSON。 示例仅说明标注方式;words/meaning 须来自输入词组与评论语境,禁止照搬示例。 ``` --- ## 【任务说明】→ 粘贴到 `keyword.user_template` ``` ## 任务:情感关键词分析(差评≤2★ / 好评≥4★ 双表,词组合并,count 按评论去重) {{neg_groups_json}} {{pos_groups_json}} {{personas_json}} ## 输入说明 - 每条含 id、words(同义/近义词组)、count(至少命中组内一词的评论条数,已去重) - 分别处理 negative_groups 与 positive_groups,输出 id 与输入一一对应 ## 输出字段规则 - id:与输入 id 一致 - words:沿用输入词组 - count:沿用输入 count,禁止改写 - polarity:细粒度极性 - 差评侧:强负面 / 负面 / 待观察 - 好评侧:强正面 / 正面 / 魅力型信号 - meaning:该词组在评论中的具体语境,只写评论明确出现的内容 - related_personas:关联 Persona 名称,可多个 ## 输出JSON {"negative":[{"id":"neg_1","words":["cut","nick"],"count":42,"polarity":"强负面","meaning":"…","related_personas":[]}],"positive":[{"id":"pos_1","words":["smooth"],"count":30,"polarity":"强正面","meaning":"…","related_personas":[]}]} ## 硬性要求 - 各侧最多输出 15 条;跳过纯功能中性词组 - meaning ≤40 字;禁止编造评论中未出现的场景或原因 - 必须跳过 {{skip_hint}} ``` **占位符说明:** - `{{neg_groups_json}}` — 差评词组(≤2★,自动填入) - `{{pos_groups_json}}` — 好评词组(≥4★,自动填入) - `{{personas_json}}` — Persona 列表(自动填入) - `{{skip_hint}}` — 需跳过的停用词说明(自动填入,含产品名) --- # 附录:技术同事同步清单 改完本文件后,请技术同事按章节将内容复制到 `prompts.yaml`: | 本文件区块 | prompts.yaml 路径 | |-----------|-------------------| | 【角色设定】 | `xxx.system` | | 【任务说明】 | `xxx.user_template` | | 【差评专用补充】 | `theme.negative_extra` | | 【反向型主动搜索】 | `kano.reverse_search_block` | | 【低分市场补充】 | `matrix.market_low_hint` | 同步完成后运行: ```bash cd voc_业务_2 ../310py/bin/python build_report.py --product "产品名" ``` --- *文档版本与 prompts.yaml meta.version 对齐:1.2 · 2026-06-12*