amz_review_analyse/voc_业务_2/提示词编辑稿.md
OnesvmWhoops cb6692c0c0 新增 voc_业务_2 报告流水线,并完善聚类与词频模块。
包含 Persona 锚定聚类、LLM 报告生成、方法论文档及 .gitignore 更新,便于在 Gitee 独立部署。

Co-authored-by: Cursor <cursoragent@cursor.com>
2026-06-15 17:12:39 +08:00

611 lines
25 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# 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`
(仅当全市场加权均分 &lt; 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*