amz_review_analyse/voc_业务_2/提示词编辑稿.md

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

同步完成后运行：

cd voc_业务_2
../310py/bin/python build_report.py --product "产品名"

---

文档版本与 prompts.yaml meta.version 对齐：1.2 · 2026-06-12