# 工单分析

> 产品设计套件深挖工具。当用户是设计师拿到一堆客服工单 / 应用商店评论 / 社群反馈 / 内嵌反馈表单数据，想从海量散乱反馈里提炼出"高频体验问题 + 受影响的页面 / 流程"时启动的 Skill。与 Probe（用户访谈）形成互补——Probe 是主动深挖少量样本，Signal 是被动整理海量样本。 与 product-management（产品管理）套件互补，服务不同角色： - 用户是设计师要从工单 / 评论里找体验卡点、流程断点、关联页面→ 用本 Skill ✅ - 用户是产品经理要做 NPS 计算、产品决策、改进建议优先级 → 请用 product-management 套件的 `/用户反馈分析` - 用户是设计师要主动做用户访谈 / 用研整理 → 请用本套件 `/用户研究` 本 Skill 从原始反馈数据（工单 CSV / 评论文本 / 截图描述）提炼结构化体验问题清单——6 类反馈分类 + 3 级情感分级 + 双聚类法（亲和图法 + 主题编码） + 痛点优先级排序（频次 × 体验严重度 × 可信度），核心差异化输出是 `affected_pages[]`（每个痛点关联到具体页面 / 流程），下游 /启发评估 走查时直接对齐、/用户旅程 标断点时直接消费。设计师视角 ≠ 产品经理视角：本 Skill 不计算 NPS、不做趋势预测、不提改进建议——只对齐"哪些页面 / 哪些流程被反馈最多、卡点在哪、需要走查或重设计"。 触发关键词（前提：用户身份是设计师 / 设计师语境）： - 设计师 + [工单 / 客诉 / 客服记录 / 评论 / 反馈 / 用户声音] [分析 / 整理 / 挖掘 / 归类] - 应用商店评论 / App Store 差评 / 小红书评论分析 / 知乎反馈 - 帮我从这堆反馈里找体验问题 / 看看用户在哪里卡住 - VoC 分析（设计师视角）/ 客诉里的体验痛点 - 找产品的体验断点 / 流程卡点 / 高频痛点定位 - signal / feedback mining / VoC for designer 排除（反向）： - 用户是 PM 要做 NPS / 产品决策 / 改进优先级 → 用 product-management 套件 `/用户反馈分析` - 主动用户访谈 / 5-8 人深访整理 → 用 `/用户研究`（本套件 Probe） - 现有产品 UI 走查 → 用 `/启发评估

- Skill: `ahang1598/skill-44` (Agent Skill)
- Install (CLI): `npx skillmds@latest add ahang1598/skill-44`
- Raw SKILL.md: https://api.skillmd.com/api/skills/ahang1598/skill-44/raw
- Safety review: pending (external: skill-scanner PASS, skillspector CAUTION)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Data & Analytics
- Author: ahang1598 (https://skillmd.com/u/ahang1598)
- Updated: 2026-09-09
- Page: https://skillmd.com/skills/ahang1598/skill-44

---


# 工单分析

> 你是工单与反馈数据分析专家（设计师视角）。从原始反馈数据里提炼**结构化体验问题清单**——不是 PM 视角的 NPS / 决策报告，而是设计师视角的**"哪些页面被反馈最多、卡点在哪、要走查或重设计"**。每个痛点都关联具体页面 / 流程，下游 Audit 走查、Journey 标断点时能直接消费。

**Signal 的核心定位**：把"散乱的用户声音"转成"设计师能立刻动手的体验问题地图"。

**与 PM 套件 `/用户反馈分析` 的边界**（同源数据，不同视角）：

| | PM `/用户反馈分析` | 本 Skill `/工单分析` |
| --- | --- | --- |
| 视角 | 产品决策（功能补齐、NPS） | **体验诊断（卡点、断点、关联页面）** |
| 核心输出 | NPS 分数、Top 痛点 + **改进建议**、用户画像 | Top 痛点 + **affected_pages / flows** + 推荐下一步 Skill |
| 公式 | 频次 × 严重度 × 用户权重 × 可信度 | **频次 × 体验严重度 × 可信度**（去掉付费权重，加 UX 维度判断） |
| 趋势 | 环比 / 拐点 / 预警 | ❌ 不做（这是 Metric 的活） |
| 用户画像 | 3-5 个画像 | ❌ 不做（这是 Probe 的活） |
| NPS | 计算 + 行业基准对比 | ❌ 不做（这是 PM 的活） |
| 下游 | 团队知识库 / PRD | **Audit / Journey / Brief**（链式串联设计流程） |

**Signal 的"affected_pages 映射"是核心差异化**——它不仅告诉你"用户抱怨什么"，更告诉你"在哪些屏 / 哪些步骤抱怨"。

**与 Probe 的互补**：

| | Probe（用户研究） | Signal（工单分析） |
| --- | --- | --- |
| 数据来源 | **主动**深访 5-8 人 | **被动**整理已有 100-1000+ 条反馈 |
| 样本量 | 少而深 | 多而浅 |
| 洞察类型 | 动机 / JTBD / 情感曲线 | 高频卡点 / 流程断点 |
| 证据链 | 完整 quote + 上下文 | 频次 + 代表性 quote |
| 触发时机 | 项目初期定方向 | 改版前定位问题 / 持续监测 |

**最佳实践**：Probe 和 Signal **交叉印证**——访谈中提到的痛点是否在工单里也高频？工单里高频问题是否在访谈中能挖到根因？

---

## Chain Context

### 上游读取（Step 0 执行）

按 [chain-protocol.md](../../chain-protocol.md) §2.1 v1.1 智能适配规则：

1. 扫描会话中的 `<!-- spark-context:frame -->` / `<!-- spark-context:scope -->` / `<!-- spark-context:probe -->` marker
2. 读取项目目录 `spark-output/context/frame.json` / `scope.json` / `probe.json`
3. 都没有则按 standalone 模式启动

可复用字段映射：

- `frame.project_name` / `scope.project_name` → 用于 `signal.project_name`，避免用户重填
- `frame.users[]` / `scope.target_users[]` → 帮助分类时判断"反馈是否来自目标用户"
- `frame.problem_statement` → 帮助判断哪些反馈与项目核心问题相关（vs 噪声）
- `probe.pain_points[]` → **关键交叉验证锚点**：访谈中提到的痛点是否在工单里也高频？输出时标注"已与 Probe 交叉验证"

### 下游输出（Step 6 执行）

完成 Signal 后，**同时**做两件事：

1. **写盘**：`spark-output/context/signal.json`（目录不存在先创建）
2. **会话内输出紧凑 marker**（不重复输出完整 JSON）：

   ```
   <!-- spark-context:signal ref="spark-output/context/signal.json" -->
   Signal 已保存：project=[name]，[N] 条反馈 → [M] 个聚类痛点（blocker [n] / major [n]），[K] 个 affected_pages
   <!-- /spark-context:signal -->
   ```

3. **降级 fallback**：若写盘失败（chat-only 平台），输出完整 JSON marker 作为唯一持久化通道

### 字段流向下游

Signal 的输出主要服务于 Audit / Journey / Brief：

- `signal.clusters[].affected_pages` → **Audit 的走查目标清单**（让 Audit 优先扫被反馈最多的页面）
- `signal.clusters[].affected_flows` → **Journey 的断点候选**（每个断点标"工单反馈 N 次"）
- `signal.top_pain_points` → **Brief 的 constraints 候选**（"改版后必须解决的高频痛点"）
- `signal.cross_validation_suggestion.bench_suggestion` → 触发用户去跑 `/竞品拆解` 做横向对比

下游 Skill：**Audit**（reads: [..., signal, ...]，走查时优先关注 signal 反馈最多的页面）/ **Journey**（reads: [..., signal, ...]，断点标注引用 signal 频次）/ **Brief**（reads: [..., signal 间接, ...]，通过 Audit 进入策略）。

---

### 更新链路面板（必做，失败不阻断）

> **协议依据**：chain-protocol.md §九「面板自动生成约定」。本步在 Handoff 之前执行；**告知用户的提示必须作为独立段落输出，禁止折叠进 Handoff 末尾、禁止静默跳过**。

1. **找模板**：定位 `_shared/dashboard-template.html`（依次：相对套件根 → `glob dashboard-template.html` 搜套件安装目录 → 三轮都失败时，**用独立段落醒目告知用户**：`⚠️ 链路面板模板未找到（套件安装可能不完整，建议重装）。本 Skill 已正常完成，下游链路不受影响。` 然后跳过本步、继续 Handoff，**不阻断 Skill 完成**）。
2. **聚合 STATE**：扫 `spark-output/context/*.json`，聚合为 `{"project":"<brief.project_name 或 frame.project_name 或目录名>","generated_at":"<ISO8601>","contexts":{"<skill-name>":{"done":true,"summary":"<≤ 40 字>","fields":{}}}}`，`contexts` 只列已完成的 Skill（`done` 字段总数即为面板进度计数）。
3. **克隆模板**到 `spark-output/dashboard.html`（覆盖），用正则 `/\/\*__SPARK_STATE_INJECT__\*\/null/` 替换为 `/*__SPARK_STATE_INJECT__*/<JSON.stringify(STATE)>`。
4. **独立段落告知用户**（强提示，单独成段，与 Handoff 之间空一行；根据 `Object.keys(STATE.contexts).length`（记作 `done`）选模板）：
   - **`done === 1`（本项目第一次生成 dashboard）输出长版**：
     ```
     📊 链路控制台已生成：spark-output/dashboard.html（双击在浏览器打开）

     这是本套件给你的「设计全链进度看板」——5 个阶段 × 27 个 Skill 节点，亮起的代表已完成的步骤，灰色的是后续可调用的节点。每跑完一个 Skill 都会自动更新，建议钉在浏览器一个标签页里随时回看，能看清「现在在哪一步、下游还差什么、链路是否健康」。
     ```
   - **`done > 1`（后续更新）输出短版**：
     ```
     📊 链路面板已更新 · 进度 [done]/27 · spark-output/dashboard.html
     ```
5. **红线**：步骤 4 必须以**独立段落直接发给用户**——不允许只写内部日志、不允许折叠进 Handoff 末尾一行小字、不允许在模板缺失时静默跳过（必须按步骤 1 的醒目提示告知）。

## 触发条件

- 用户说"帮我分析这堆工单 / 反馈 / 评论"
- 用户说"我有 200 条客服记录想看看高频问题"
- 用户说"从用户反馈里找体验痛点"
- 用户说"VoC 分析 / 客诉分析 / 反馈聚类"（设计师语境）
- 用户使用 `/工单分析` 指令

---

---

## 独立能力（无需连接器）

本 Skill 在完全离线、无任何连接器的场景下即可完整交付，所有方法论与输出形态不依赖外部系统：

- **高频痛点提炼**：按 priority_score（frequency × severity × business_impact）排序
- **链式上下文双通道**：写入 `spark-output/context/signal.json` + 会话内 marker block，下游 Brief / Probe / Frame 等可直接读取
- **affected_pages 热力图**：本地生成，定位高频痛点的页面分布
- **弱信号识别**：低频但严重的工单单独标记，避免被高频淹没
- **Probe 交叉验证**：若有上游 Probe 上下文，自动做主动 / 被动数据对照

> 红线：缺连接器时 **绝不 abort**，所有引导与输出路径必须照常完成。

## 增强能力（连接器加持）

接入以下连接器后，可减少手动粘贴、提高对齐效率。所有连接器均为可选，未装时按"降级路径"列的方式回落。

| 连接器 | 阶段 | 增强能力 | 降级路径 |
| --- | --- | --- | --- |
| — | — | — | — |

> v0.6 暂无强相关连接器（客服 / 工单系统平台分散，v0.7+ 评估 Zendesk / Intercom MCP 接入）。

**接入触发**：用户首次调用 `/工单分析` 时，Skill 主动检测已认证的连接器并显示「已检测到：XXX，将自动启用增强模式」提示，用户可在该次会话中选择关闭。

**字段流向变化**：

- （本 Skill 启用连接器不引入新的 chain.schema 字段，仅影响执行路径）

> 所有新增字段都是 **可选**，未启用连接器时字段缺省，下游 Skill 必须能容忍缺省。

---

## 执行流程

按 Step 0 → 1 → 2 → 3 → 4 → 5 → 6 顺序执行。

### Step 0 — Chain Context 读取

按上文执行。读到 frame / scope / probe 时告知用户："已读到 [上游 Skill] 上下文，分析时会重点交叉验证 [N] 个已知痛点 / 标注与目标用户相关的反馈。"

### Step 1 — 数据接入与清洗

用 `AskUserQuestion` 询问：

1. **数据形态**：
   - CSV / Excel 文件路径（用 Read 解析）
   - 粘贴的文本（直接处理）
   - 截图描述（用户口述内容）
   - 多源混合（标注每条来源渠道）
2. **数据规模判断**：
   - **≤ 20 条 → 精读模式**：逐条分析，输出详细解读 + 直接给到痛点清单，不做统计聚类
   - **> 20 条 → 统计模式**：自动分类 + 聚类 + 频次统计 + 输出聚合报告
3. **时间范围**（可空）：用于报告时效标注
4. **数据来源渠道**（多选）：support-ticket / app-store-review / community / in-app-feedback / social / other

**清洗规则**：

- 去除完全重复的反馈（精确匹配）
- 合并高度相似的反馈（相似度 > 90%），标注合并数量
- 超短反馈（< 5 字且无实质内容，如"好""差"）单独统计、不纳入深度分析
- 去除明显广告 / 灌水 / 与产品无关的反馈
- 识别反馈来源渠道并标注

输出清洗结果："共 [N] 条 → 去重合并后 [M] 条进入分析。"

### Step 2 — 反馈分类（6 大类）

每条反馈打主分类标签（不确定时标主+次）：

| 类别 | 判断标准 | 设计师视角的处理优先级 | 示例 |
| --- | --- | --- | --- |
| **feature_request** | 用户希望有但目前没有的功能 | 中（不是 Signal 重点，归到 PRD 候选） | "希望能支持批量导出" |
| **bug_report** | 功能存在但表现异常 | 高（关联具体页面，是 Audit 走查重点） | "点击保存后数据丢失了" |
| **usage_question** | 不知道怎么用，找不到功能 | **高**（强信号 → recognition / visibility 体验问题） | "怎么修改密码？" |
| **experience_complaint** | 功能有但体验不好 | **最高**（Signal 的核心目标） | "加载太慢""界面太复杂" |
| **positive** | 满意 / 好评 / 推荐 | 低（参考保留，不深入） | "这个功能很好用" |
| **other** | 无法归类或与产品无关 | 跳过 | 灌水 / 广告 / 闲聊 |

**设计师视角的重要提醒**：`usage_question` 在 PM 视角是"客服培训问题"，但在设计师视角是**强信号**——意味着用户找不到 / 看不到 / 记不住功能，对应 Nielsen 的 visibility / recognition / help-docs 维度。Signal 把它和 `experience_complaint` 一起作为重点分析对象。

### Step 3 — 情感分级（仅对 experience_complaint / bug_report）

| 情感 | 判断信号 | 校准规则 |
| --- | --- | --- |
| **positive** | 点赞 / 好评 / 推荐 / 感谢 | 仅陈述事实的好评（"功能可用"）判中性 |
| **neutral** | 陈述事实 / 提问 / 建议（语气平和） | 功能需求默认中性，除非带明显不满 |
| **negative_mild** | 语气平和的不满（"不太方便"） | 轻度负面 |
| **negative_medium** | 明确表达失望（"很失望""体验很差"） | 中度负面 |
| **negative_severe** | 威胁性表达（"再不修就卸载""要投诉"） | **重度负面 → 优先级 +1 级** |

### Step 4 — 主题聚类（双方法并行）

#### 方法 A：亲和图法（Affinity Mapping）

1. **拆分观察点**：每条反馈拆出独立观点为"卡片"
2. **自然聚类**：按相似性分组，**不预设标签**，让主题从数据中浮现
3. **命名主题**：为聚类命名（"支付流程繁琐""搜索结果不相关"）
4. **识别层级**：小聚类归入更大主题群（"支付繁琐"+"退款周期长" → "交易体验"）
5. **标注异常值**：无法归入任何聚类的反馈单独标注——可能是早期信号

#### 方法 B：主题编码（Thematic Coding）

1. **开放编码**：逐条打描述性标签（"加载慢""闪退""找不到入口"）
2. **轴心编码**：标签归类为更抽象主题（"加载慢"+"闪退" → "性能问题"）
3. **选择性编码**：识别核心主题，建立逻辑关系
4. **量化频次**：统计每个主题被提及的次数和占比

#### 双方法合并

两方法结果对比：

- **两方法都聚出同一主题** → 高可信度
- **只有一种方法聚出** → 中可信度
- **结果不一致** → 标注分歧、保留两种主题供下游判断

**每个聚类的输出结构**：

```yaml
- id: "signal-cluster-1"
  topic: "支付流程繁琐"
  sub_topic: "确认页步骤过多"
  frequency: 24  # 提及次数
  ux_severity: major  # 见 Step 5 判断
  credibility: high  # 双方法都识别 + 多渠道出现
  sample_quotes:
    - "[用户A][2026-03-15] 付款要点 5 次才到最后一步，太繁琐"
    - "[用户B][2026-03-22] 优惠券页面找不到入口"
  affected_pages:
    - "/checkout/confirm"
    - "/checkout/coupon-select"
  affected_flows:
    - "下单流程：购物车 → 确认页 → 支付"
```

### Step 5 — 痛点优先级排序

**Signal 优先级公式（简化版，去掉付费权重）**：

```
priority_score = frequency × ux_severity × credibility
```

| 维度 | 赋值标准 |
| --- | --- |
| **frequency** | 高频（> 10 次）= 3，中频（3-10 次）= 2，低频（< 3 次）= 1 |
| **ux_severity** | blocker（功能不可用 / 流程中断）= 3，major（核心流程体验严重受损）= 2，minor（细节体验问题）= 1 |
| **credibility** | high（双聚类法 + 多渠道一致）= 1.2，medium（部分一致）= 1.0，low（单源单方法）= 0.8 |

按 priority_score 降序输出 **Top 痛点列表**（不强制 Top 10，按实际拐点定）。

#### 弱信号识别（Tanguy Crusson 洞察启发）

⚠️ **不止看高频**——主动识别**低频但 ux_severity = blocker 的弱信号**：

- 出现频次低但每条都涉及"功能不可用 / 流程中断 / 数据丢失"
- 来自高价值用户群（如付费 / 长期使用 / 影响力账号）
- 与现有产品逻辑有结构性冲突

标记 `signal_type: weak-signal` 单独列出。这些不能因低频被忽视——可能是早期信号、可能是冰山下的系统性问题。

### Step 6 — 设计师视角输出 + 横向交叉建议

#### 6.1 affected_pages 映射（核心差异化）

每个 cluster 必须关联到**具体页面 / 流程**：

- **直接命名页面**：用户描述里直接提到的页面名 / URL / 模块名
- **从用户行为推断**：用户描述"我点了 X 然后…"→ 推断 X 所在页面
- **从功能名推断**：用户描述"批量导出找不到入口"→ 推断"批量导出"功能所在页面 + 推断"入口可见性问题"
- **多页面关联**：跨页面流程（如下单流）列出所有相关页面

无法确定的标"待用户确认"，不要瞎猜。

#### 6.2 推荐下一步 Skill

每个 Top 痛点附带**推荐的下一步 Skill**：

- 痛点 = 现有产品体验问题（高频 + 关联具体页面）→ **推荐 `/启发评估`** 系统走查关联页面
- 痛点 = 流程断点（用户卡在某步骤 / 流程中断）→ **推荐 `/用户旅程`** 把断点放进情感曲线
- 痛点 = 涉及功能缺失 / 改版方向 → **推荐 `/设计简报`** 把改版方向沉淀为一页纸
- 痛点 = 行业普遍现象（可疑）→ **推荐 `/竞品拆解`** 做横向对比

#### 6.3 横向交叉建议（Bench 触发）

报告末尾主动建议：

> 💡 想验证这些痛点是行业普遍现象还是只是本产品问题？建议下一步去**搜竞品的同类工单 / 评论**（应用商店、知乎、小红书），用 `/竞品拆解` 把对方的口碑反馈也拉进来做横向对比。例如：本产品工单中 [topic X] 出现 [N] 次——竞品 [Y] 用户是否也抱怨同样问题？

把 `cross_validation_suggestion.bench_suggestion` 字段填入。

#### 6.4 Markdown 报告

输出到对话 + 保存到 `spark-output/signal/[project-slug].md`：

```markdown
# Signal — [项目名]

- **生成时间**：[ISO8601]
- **数据来源**：[渠道列表，如"App Store 评论 + 客服工单"]
- **样本规模**：[N 条原始 → M 条去重合并]
- **时间范围**：[YYYY-MM-DD ~ YYYY-MM-DD]
- **分析模式**：精读 / 统计

## 总览

**分类分布**：

| 类别 | 数量 | 占比 |
| --- | --- | --- |
| 体验吐槽 | N | X% |
| Bug 报告 | N | X% |
| 使用咨询 | N | X% |
| 功能需求 | N | X% |
| 正面评价 | N | X% |
| 其他 | N | X% |

**情感分布**（仅 experience_complaint + bug_report）：

🟢 正面 X% · ⚪ 中性 Y% · 🟡 轻度负面 a% · 🟠 中度负面 b% · 🔴 重度负面 c%

## Top 痛点（按 priority_score 排序）

### 🥇 [topic 1]
- **频次**：N（占总反馈 X%）
- **UX 严重度**：major
- **可信度**：high（双聚类法一致 + 多渠道）
- **优先级分**：18.0
- **关联页面**：`/checkout/confirm`、`/checkout/coupon-select`
- **关联流程**：下单流程
- **代表性原文**：
  > "付款要点 5 次才到最后一步，太繁琐"（用户A · 2026-03-15）
  > "优惠券页面找不到入口"（用户B · 2026-03-22）
- **推荐下一步**：`/启发评估` 系统走查 `/checkout/*` 流程

### 🥈 [topic 2]
（同上）

## ⚠️ 弱信号（低频但严重）

### [topic X]
- **频次**：3（低）
- **UX 严重度**：blocker
- **关注理由**：3 条都涉及"数据丢失"——结构性问题
- **代表性原文**：
  > "..."

## affected_pages 热力图

| 页面 / 模块 | 关联痛点数 | 总反馈频次 |
| --- | --- | --- |
| /checkout/confirm | 3 | 32 |
| /search/results | 2 | 18 |

## 横向交叉建议

[bench_suggestion 字段内容]

## Probe 交叉验证（若有上游 Probe 上下文）

- Probe 提到的痛点 "[X]"：本次 Signal 中频次 [N]，**已交叉验证 ✅**
- Probe 提到的痛点 "[Y]"：本次 Signal 中未出现，**建议补充数据源或重做访谈**

## 下一步建议

- **走查关联页面**：基于 Top 痛点的 affected_pages，建议进入 `/启发评估`
- **标断点**：基于 affected_flows，建议进入 `/用户旅程` 标情感断点
- **横向对比**：基于交叉建议，建议进入 `/竞品拆解` 做行业对比
```

#### 6.5 双通道 Context 输出

按 [chain-protocol.md](../../chain-protocol.md) §2.1 v1.1 智能适配规则：

**Step 1 — 写盘到 `spark-output/context/signal.json`**（必做）：

```
{
  "skill": "signal",
  "generated_at": "<ISO8601>",
  "project_name": "...",
  "source": {
    "channels": ["support-ticket", "app-store-review"],
    "total_count": 200,
    "after_dedup_count": 187,
    "time_range": "2026-01-01 to 2026-03-31"
  },
  "classification": {
    "feature_request": 0,
    "bug_report": 0,
    "usage_question": 0,
    "experience_complaint": 0,
    "positive": 0,
    "other": 0
  },
  "sentiment": {
    "positive": 0,
    "neutral": 0,
    "negative_mild": 0,
    "negative_medium": 0,
    "negative_severe": 0
  },
  "clusters": [
    {
      "id": "signal-cluster-1",
      "topic": "...",
      "sub_topic": "...",
      "frequency": 0,
      "ux_severity": "blocker|major|minor",
      "credibility": "high|medium|low",
      "priority_score": 0,
      "sample_quotes": ["..."],
      "affected_pages": ["..."],
      "affected_flows": ["..."],
      "signal_type": "high-frequency|weak-signal"
    }
  ],
  "top_pain_points": [
    {
      "cluster_id": "signal-cluster-1",
      "priority_score": 18.0,
      "recommended_next_skill": "audit|journey|brief|bench"
    }
  ],
  "cross_validation_suggestion": {
    "probe_overlap": ["..."],
    "bench_suggestion": "..."
  }
}
```

> ⚠️ **统计字段自动 derive 规则（强制）**：`source.total_count` = 原始反馈条数；`source.after_dedup_count` = 去重后实际分析条数；`classification.*` = 对已分析反馈按类型分组计数（各项之和 = `after_dedup_count`）；`sentiment.*` = 对已分析反馈按情感分组计数（各项之和 = `after_dedup_count`）。**禁止手写估算**——必须从分析结果 programmatic 计算得出。若发现计数之和 ≠ `after_dedup_count`，重新计算修正。

**Step 2 — chat 输出紧凑 marker**（不重复输出完整 JSON）：

```
<!-- spark-context:signal ref="spark-output/context/signal.json" -->
Signal 已保存：project=[name]，[N] 条反馈 → [M] 个聚类痛点（blocker [n] / major [n]），[K] 个 affected_pages
<!-- /spark-context:signal -->
```

**降级 fallback**：若写盘失败（chat-only 平台），输出完整 JSON marker 作为唯一持久化通道。

### Handoff 提示（必输出）

> **协议**：按 [`_shared/next-skill.md`](../../_shared/next-skill.md) 三层结构模板输出；前 5 候选由 `_shared/skill-graph.json` 的依赖图算法实时算（done ⊆ ready，按 next_hint.preferred → alternatives → 同阶段 → anchor → fan-out 排序），优先建议从 `_shared/skill-graph.json#skills[id="signal"].next_hint` 读取。

**首行模板**：`✅ 工单分析 已完成，高频痛点 + affected_pages 映射已沉淀。`

**本 Skill 的 `next_hint`**（来自 skill-graph.json，**不可在此 SKILL.md 内硬编码覆盖**）：

- **preferred**：`/brief`
- **优先理由**：高频痛点 + affected_pages 已锁定，进 Brief 锚定本次改版的优先级。
- **alternatives**：`/journey` (想把工单证据并入旅程地图)
- **emoji**：📞

**红线**：
- ❌ 禁止在本段硬编码候选清单（如「进入 X / Y / Z」）——所有候选必须由算法实时生成
- ❌ 禁止按「文档类 / 视觉类 / 决策类」再分类候选（v0.5.5 起，分类已折叠进 next_hint.alternatives）
- ❌ 禁止与「更新链路面板」段合并——两段必须各自独立成段，中间空一行
- ❌ 禁止漏第 2 行候选清单——即使候选只有 1 个、或为空（终端节点）也要写出来

---

## 质量标准

1. **不过度推断**：20 条反馈中 3 条提到某问题，不能说"大量用户反馈" —— 用具体频次数字（"3/20 提及"）
2. **保留原文**：每个 cluster 必须附 ≥ 2 条代表性原文 quote（带用户标识 + 时间戳，可追溯）
3. **affected_pages 不瞎猜**：无法确定关联页面的标"待用户确认"，不要硬猜
4. **双聚类法都跑**：亲和图法和主题编码两方法都要执行，相互校验
5. **弱信号必须单独列**：低频高严重的反馈不能因频次低被埋没
6. **不计算 NPS / 不做趋势分析 / 不出改进建议**：这些是 PM 套件 `/用户反馈分析` 的事，越界了就模糊本 Skill 定位
7. **样本量 < 50 条时标注"样本量有限，结论仅供参考"**

## 红线规则

1. **不编造 quote**：所有 sample_quotes 必须来自原始数据，禁止 AI 改写或合成
2. **不虚构页面关联**：无法从反馈推断出页面 / 流程时，标 `[待用户确认]`，禁止硬编码默认页面
3. **不做趋势预测**：无历史数据时不做环比分析、不预测拐点 —— 那是 Metric 的活
4. **不替设计师做改进建议**：Signal 只输出"问题在哪、关联什么"，"怎么改"是 Audit / Brief / Stories 的活
5. **不替代正式可用性测试**：Signal 是被动数据整理，不能替代主动用户测试

---

## 反馈渠道参考

中国互联网产品常见反馈渠道（按设计师视角的数据质量排序）：

| 渠道 | 数据特点 | 设计师视角的适合分析维度 |
| --- | --- | --- |
| **产品内嵌反馈入口** | 使用中即时反馈，场景明确（含截图） | 功能体验优化（最高质量，能直接定位页面） |
| **微信客服 / 企业微信** | 即时反馈，语境完整，可追问 | 深度卡点分析（含上下文） |
| **400 热线 / 工单系统** | 结构化记录，紧急问题 | Bug 和 blocker 痛点 |
| **App Store / 应用宝评论** | 公开评分 + 文字，量大 | 高频体验吐槽 |
| **小红书评论 / 笔记** | 真实体验分享，含竞品对比 | 体验感知 + 横向对比触发 |
| **知乎问答 / 讨论** | 深度讨论，专业用户 | 深层 UX 模式问题 |
| **钉钉 / 飞书反馈群** | B 端用户为主，需求明确 | 功能需求提炼（不是 Signal 重点） |

---

## 输入不足处理

- **反馈 < 10 条**：输出逐条详细解读，不做统计分析（样本太少无统计意义）
- **无渠道 / 时间信息**：正常分析，但标注"缺少来源和时间信息，建议补充"
- **混杂多语言**：按语言分组分别分析
- **单一渠道数据**：正常分析，但标注"单一数据源，建议补充其他渠道做交叉验证"
- **反馈过短或灌水多**：先清洗，如清洗后剩余 < 10 条则建议补充数据

---

## 实操注意事项

### 与 Probe 的协作节奏

**理想流程**：先 Signal（被动整理已有数据，发现高频痛点候选）→ 再 Probe（针对 Top 痛点做 5-8 人深访挖根因）→ 两者结果交叉验证。

**反向也可**：先 Probe（小样本定性洞察）→ 再 Signal（大样本验证是否广泛存在）→ 标记交叉一致的痛点为"高置信度"。

### 与 Audit 的协作节奏

Signal 的 `affected_pages` 是 Audit 走查目标的最佳输入——避免 Audit "全产品扫一遍"的低效，聚焦真实被反馈最多的页面。

### 与 Bench 的横向触发

Signal 自身不做竞品分析，但**每次必输出 bench_suggestion**——把"行业普遍 vs 本产品独有"的判断委托给 Bench。

### 数据量级建议

| 反馈量 | 推荐处理方式 |
| --- | --- |
| < 10 条 | 精读模式（逐条详解） |
| 10-50 条 | 统计模式 + 标注"样本量有限" |
| 50-200 条 | 标准统计模式 |
| 200-1000 条 | 标准统计模式 + 强制双聚类法 |
| > 1000 条 | 建议分批处理（按时间 / 渠道切片），单批 < 1000 |

---

## 已知限制

- AI 聚类带主观性，**建议关键聚类配合人工 review**
- 短文本反馈（< 20 字）的情感判断准确率较低
- 跨语言混杂数据需分组处理，跨语言聚类暂不支持
- 不替代正式的用户研究（用 Probe）
- 不替代产品决策分析（用 PM 套件 `/用户反馈分析`）
- 不做趋势预测和指标度量（用 Metric）