---
name: jd-selling-point-evidence
description: 将商品事实、目标人群、竞品表达、评论与问大家材料整理成可追溯的卖点证据矩阵，并生成前三卖点及标题、主图、详情页、短视频 brief。用于京东及其他电商商品上新、卖点提炼、页面改版、内容策划、竞品复盘或营销表达合规自查；当材料不完整时，必须列出未知项与验证动作，不得补造事实。
---

# 京东商品卖点证据矩阵

先建立证据，再写卖点。把事实、用户声音、竞品表达与内部假设分开，确保每条对外表达都能回到来源。

## 工作原则

1. 只把可核验材料当作事实。不要把竞品话术、单条评论或内部推测改写成己方商品事实。
2. 保留限定条件。规格、测试环境、适用人群、时间范围和版本不得在改写时丢失。
3. 降级表达，不补齐证据。证据不足时改为审慎措辞，或放入“未知项与验证动作”。
4. 先做决策资产，再做文案。先输出矩阵和前三卖点，再生成各渠道 brief。
5. 不上传 Cookie、后台截图中的账号信息、订单号、手机号或未脱敏的用户资料。

需要判断证据等级、表达边界或评分时，读取 [references/evidence-rules.md](references/evidence-rules.md)。生成四类内容 brief 时，读取 [references/channel-briefs.md](references/channel-briefs.md)。

## 输入

至少收集以下四类材料；缺少任一类时继续执行，但明确缺口：

- **商品事实**：品类、型号、规格、材质、功能、适用条件、测试报告、认证、包装和服务承诺。
- **目标人群**：角色、使用场景、任务、痛点、顾虑、购买门槛；说明判断依据。
- **竞品表达**：原文、竞品名称、来源位置、观察日期；仅用于发现表达机会和同质化风险。
- **用户证据**：己方或竞品的评论、问大家、客服反馈、退换原因；标明来源对象、日期和样本范围。

若用户尚未整理材料，复制 [assets/product-input.template.json](assets/product-input.template.json) 填写。仅需了解格式时可查看 [assets/example-input.example.json](assets/example-input.example.json)；该文件明确标注为示例数据。

## 标准流程

### 1. 登记与清洗证据

使用脚本生成稳定编号、去重并发现缺失来源：

```bash
python scripts/normalize_evidence.py --input product-input.json --output-dir normalized
```

读取输出的 `normalized-evidence.json` 和 `evidence-register.md`。不要把脚本的“可追溯”标记理解为真实性认证；它只表示来源字段是否齐全。

若输入不是 JSON，先按原意转换为模板结构。转换时不要摘要原文，不要补充日期、来源或验证状态。

### 2. 分离事实、声音、表达与假设

逐条判断：

- 商品资料或检测文件能直接支持什么；
- 用户声音反映了什么感受或问题，但不能证明什么普遍结论；
- 竞品正在怎样表达，但不能因此证明己方也具备；
- 哪些只是待验证的运营假设。

发现冲突时同时保留两条材料，标记冲突点，并把核验动作列入未知项。不要自行选取更有利的一条。

### 3. 建立卖点证据矩阵

每行只表达一个清晰因果链，使用以下字段：

| 字段 | 要求 |
|---|---|
| 卖点 ID | 使用 `SP-01` 起的稳定编号 |
| 用户痛点/任务 | 指明人群和场景，不写空泛的“追求品质” |
| 商品功能/事实 | 引用 `Fxxx`；若没有事实证据则标为待验证 |
| 用户利益 | 解释该功能在场景中带来的结果，不扩大因果 |
| 证据 | 列出全部关联证据 ID，不写“有数据显示” |
| 安全表达 | 给出保留限定条件的对外表达 |
| 证据等级 | A/B/C/D，按证据规则判断 |
| 风险与缺口 | 写清不能说什么、还缺什么 |

不要为了矩阵完整而强行连接痛点和功能。没有合理机制或证据时拆开处理。

### 4. 选出前三卖点

按“人群相关性、证据强度、差异化、表达清晰度、风险”五个维度分别评 1–5 分，并展示评分理由。评分用于排序，不伪装成市场统计结论。

前三名必须：

- 面向不同决策障碍，避免同义重复；
- 至少有一条商品事实支撑；
- 说明适用人群、场景和限定条件；
- 标记尚未经过转化数据验证的卖点假设。

### 5. 生成渠道 brief

基于同一组卖点和证据，分别输出：

1. 标题 brief；
2. 主图 brief；
3. 详情页 brief；
4. 短视频 brief。

每个 brief 都要引用卖点 ID 和证据 ID，并包含“不可表达/待核验”字段。不要直接生成无证据的极限词、功效承诺、官方背书或虚构体验。

### 6. 输出未知项与验证动作

按优先级列出：未知项、影响的卖点、为什么重要、验证方法、所需来源、建议负责人和下一步。区分：

- 上线前必须验证；
- 可在 A/B 测试中验证；
- 暂不影响上线但应持续收集。

## 固定交付顺序

使用 [assets/deliverable-template.md](assets/deliverable-template.md) 的结构，依次输出：

1. 输入完整度与边界；
2. 证据登记摘要；
3. 卖点证据矩阵；
4. 前三卖点与排序依据；
5. 标题、主图、详情页、短视频 brief；
6. 未知项与验证动作；
7. 发布前检查。

所有示例、模拟评论或假设数据必须在紧邻位置标注“示例数据”或“假设，待验证”。

## 发布前检查

- 每条外部表达能否回溯到证据 ID？
- 是否把竞品表达误写成己方事实？
- 是否把少量用户声音写成普遍结论？
- 数字、单位、适用条件和测试环境是否保留？
- 是否出现无法证明的“第一、唯一、100%、彻底”等绝对表达？
- 是否列出冲突证据、未知项和验证动作？
- 是否清除了账号、订单与个人敏感信息？
- 是否提醒最终内容仍需品牌方及平台规则复核？