# Research

> 多源客户调研——对客户问题、产品主题或账户相关查询进行系统性多源调研， 带来源归属和置信度评分。 触发：「调研客户 / 查一下 XX 公司背景 / 做一个客户调研 / research customer / 客户背景调查 / 行业调研 / 竞品调研 / 摸排客户需求」。 适用场景：方案撰写前的客户画像准备、竞品分析、技术可行性验证、历史沟通回顾。 不直接写方案（solution-master 接管）、不直接画图（drawio 接管）。

- Skill: `tubeliu/research` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add tubeliu/research`
- Raw SKILL.md: https://api.skillmd.com/api/skills/tubeliu/research/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Research & Search
- Author: tubeliu (https://skillmd.com/u/tubeliu)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/tubeliu/research

---


# /customer-research — 多源客户调研

> **跨平台兼容性 checklist**（Windows / macOS / Linux）：
> 1. **Python 命令名**：示例用 `python3`。Windows 不可识别时改 `python` 或 `py -3`。
> 2. **路径自定位**：本文档所有脚本路径用下方 §路径自定位 一节的 bootstrap 解析。
> 3. **可执行检测**：用 `which`/`where`/`Get-Command`，不用 `command -v`。
> 4. **Bash heredoc / `&&` / `||`**：Windows cmd 不支持，建议在 Git Bash / WSL2 中运行。
> 5. **路径分隔符**：用正斜杠 `/`，避免硬编码反斜杠 `\`。

<SUBAGENT-STOP>
此技能是给协调者读的。**判定你是否子智能体**：如果你的当前角色定义来自 Task prompt 而非 SKILL.md 自然加载（即调用方在 Task 工具的 prompt 字段里塞了 agents/<role>.md 的内容），你就是子智能体；跳过本 SKILL.md 的工作流编排部分，只执行 Task prompt 给你的具体任务。
</SUBAGENT-STOP>

## 路径自定位

**首次调用本 skill 的脚本前，先跑一次以下 bootstrap 解析 SKILL_DIR**（后续命令用 `$SKILL_DIR/scripts/...`）：

```bash
SKILL_DIR=$(python3 - <<'PYEOF' 2>/dev/null
import json, os, sys
p = os.path.expanduser('~/.claude/plugins/installed_plugins.json')
if os.path.exists(p):
    d = json.load(open(p))
    for entries in d.get('plugins', {}).values():
        for e in (entries if isinstance(entries, list) else [entries]):
            if isinstance(e, dict) and '/customer-research/' in e.get('installPath', ''):
                print(e['installPath'] + '/skills/research'); sys.exit(0)
PYEOF
)

# vercel CLI fallback (skill subdir is 'research')
[ -z "$SKILL_DIR" ] && for d in ~/.cursor/skills ~/.agents/skills .cursor/skills .agents/skills; do
    [ -d "$d/customer-research/skills/research" ] && SKILL_DIR="$d/customer-research/skills/research" && break
    [ -d "$d/customer-research" ] && SKILL_DIR="$d/customer-research" && break
done

# 用户预设环境变量
[ -z "$SKILL_DIR" ] && [ -n "${CUSTOMER_RESEARCH_PLUGIN_PATH:-}" ] && SKILL_DIR="$CUSTOMER_RESEARCH_PLUGIN_PATH/skills/research"

# dev 态
[ -z "$SKILL_DIR" ] && [ -d "./customer-research/skills/research" ] && SKILL_DIR="$(pwd)/customer-research/skills/research"

if [ -z "$SKILL_DIR" ]; then
    echo "[ERROR] 找不到 customer-research skill 安装位置。" >&2
    echo "请设置：export CUSTOMER_RESEARCH_PLUGIN_PATH=/path/to/customer-research" >&2
    exit 1
fi
```

**错误恢复 protocol**：bootstrap 退出 1 时不要重试，把 stderr 转述给用户并请求 `/plugin install customer-research@presales-skills` 或手工 export 环境变量。

---

## 配置管理

配置文件：`~/.config/presales-skills/config.yaml`，`customer_research` 段。

```yaml
customer_research:
  user_company: "XX科技"    # 用户所在企业（你自己的公司），调研时用于上下文定位
```

### 首次触发 / 用户主动配置

**以下任一条件满足时，进入配置流程：**

1. 配置文件不存在 `customer_research` 段（首次执行）
2. 用户说"配置 customer-research" / "设置我的公司" / "configure customer-research"

**配置流程：**

```
向用户提问（必须用 AskUserQuestion 工具，不要自行假设）：
  "您所在的企业名称是哪家？（即您自己的公司，用于调研时的上下文定位）"

用户明确回答后，写入配置：
  python3 ${SKILL_DIR}/scripts/cr_config.py set user_company "<用户输入>"
```

<EXTREMELY-IMPORTANT>
`user_company` 是**用户自己的公司**（固定的），不是调研目标企业。
- 调研目标企业在每次调研请求中指定（如"调研吉林高速集团"），不存配置
- 禁止从上下文自动推断 user_company——必须用 AskUserQuestion 向用户确认
- 用户说"调研吉林高速集团" → 这是调研目标，不写入配置
- 用户说"我们是 XX 科技" → 这才是 user_company，写入配置
</EXTREMELY-IMPORTANT>

**配置读取：** 每次调研前先读取 `user_company`：

```bash
USER_COMPANY=$(python3 ${SKILL_DIR}/scripts/cr_config.py get user_company "")
```

- 如果 `user_company` 非空，调研时自动注入上下文："我方企业：**${USER_COMPANY}**。站在 ${USER_COMPANY} 的视角调研，关注与我方产品/方案的契合点、竞对关系、切入机会。"
- 如果为空，**必须进入配置流程**（见上方"首次触发"），向用户确认企业名称并写入配置后，再开始调研。不要跳过、不要假设。

---

## 使用方式

```
/customer-research <调研问题或主题>
```

## 工作流

### 1. 解析调研请求

识别调研类型：
- **客户画像**：了解目标客户的基本情况（行业、规模、技术栈、组织架构）
- **问题调研**：某个技术/业务问题的背景调查（如"这个客户用过竞品吗？"）
- **账户上下文**：与特定客户的历史互动（如"我们上次给 XX 公司报过什么方案？"）
- **主题研究**：售前工作相关的通用主题（如"智慧高速行业趋势"）

搜索前先明确：
- 这是一个有确定答案的事实性问题？
- 这是一个需要多角度信息的上下文性问题？
- 这是一个范围还在定义中的探索性问题？
- 答案的受众是谁（内部团队、客户、管理层）？

### 2. 搜索可用数据源

按以下分层系统性搜索，不要只看第一个结果——交叉验证。

**第一层 — 权威内部资料（置信度：高）：**
- 产品文档、技术白皮书、解决方案手册
- 内部知识库、FAQ、政策文档
- 产品路线图（内部视角）：功能时间线、优先级

**第二层 — 业务上下文（置信度：中高）：**
- CRM 记录：客户档案、沟通历史、历史报价、商机详情
- 历史方案/标书：该客户或同类客户的历史产出物
- 会议纪要：之前的讨论、决策、承诺

**第三层 — 团队沟通记录（置信度：中）：**
- 即时通讯：相关频道中是否讨论过此话题
- 邮件：与此主题相关的往来邮件
- 日历备注：会议议程和会后笔记

**第四层 — 外部资料（置信度：中低）：**
- 网络搜索：官方文档、行业报告、社区论坛
- 公开知识库、帮助中心、发布说明
- 第三方文档：集成伙伴、互补工具

**第五层 — 推理与类比（置信度：低，直接来源不足时使用）：**
- 类似场景：类似问题之前是怎么处理的
- 同类客户：可比客户的经验
- 行业最佳实践：行业标准和通行做法

### 3. 综合产出

将搜索结果编译为结构化调研简报：

```
## 调研：[问题/主题]

### 结论
[清晰、直接的回答——先给结论]

**置信度：** [高 / 中 / 低]
[解释置信度的依据]

### 关键发现

**来自 [来源 1]：**
- [具体发现]
- [具体发现]

**来自 [来源 2]：**
- [具体发现]

### 上下文与细微之处
[注意事项、边界条件、额外上下文]

### 来源
1. [来源名称/链接] — [贡献了什么信息]
2. [来源名称/链接] — [贡献了什么信息]
3. [来源名称/链接] — [贡献了什么信息]

### 未确认 / 待补充
- [无法确认的信息]
- [可能需要向领域专家核实的内容]

### 建议后续动作
- [如果需要给客户回复]
- [如果需要进一步调研]
- [需要咨询谁来核实]
```

### 4. 数据源不足时的处理

如果没有找到有用信息：

- 进行网络调研
- 向用户询问内部上下文：
  - "在已连接的数据源中没找到相关信息。你有内部文档或知识库文章涉及这个话题吗？"
  - "你的团队之前讨论过这个话题吗？有哪个沟通渠道我应该查一下？"
  - "有没有领域专家会知道答案？"
- 透明说明局限性：
  - "这个回答仅基于网络调研——在分享给客户前请先核实内部文档。"
  - "我找到了一个可能的答案，但无法从权威内部来源确认。"

### 5. 客户面向注意事项

如果调研结果将用于回复客户：

- 涉及产品路线图、定价、法务或安全话题时，标记需要审核
- 如果答案与之前可能已沟通的内容不一致，注明
- 建议适当的免责声明
- 主动提出代拟回复："需要我根据这些发现草拟给客户的回复吗？"

### 6. 知识沉淀

调研完成后，建议沉淀知识：

- "要把这些发现保存到知识库供将来参考吗？"
- "要基于这次调研创建一个 FAQ 条目吗？"
- "这个值得记录——要草拟一个 runbook 条目吗？"

这有助于积累组织知识，减少团队内的重复调研。

---

## 来源分层与置信度

### 按来源分层的置信度

| 层级 | 来源类型 | 置信度 | 备注 |
|------|----------|--------|------|
| 1 | 官方内部文档、知识库、政策 | **高** | 除非明显过期（检查日期）|
| 2 | CRM、历史方案、会议纪要 | **中高** | 可能有主观性或不完整 |
| 3 | 即时通讯、邮件、日历备注 | **中** | 非正式，可能脱离上下文或推测性 |
| 4 | 网络、论坛、第三方文档 | **中低** | 可能不反映你的具体情况 |
| 5 | 推理、类比、最佳实践 | **低** | 明确标记为推理而非事实 |

### 置信度等级

始终标注并沟通置信度：

**高置信度：**
- 答案经官方文档或权威来源确认
- 多个来源交叉验证同一答案
- 信息是当前的（在合理时间范围内验证过）
- "基于 [来源]，我对这个答案有信心。"

**中置信度：**
- 答案来自非正式来源（通讯、邮件）但非官方文档
- 单一来源无交叉验证
- 信息可能略有过期但可能仍然有效
- "根据 [来源]，情况似乎是这样，但建议向 [团队/人] 确认。"

**低置信度：**
- 答案从相关信息推理而来
- 来源过期或可能不可靠
- 来源间信息矛盾
- "未能找到确定答案。基于 [上下文]，我的最佳判断是 [答案]，但在分享给客户前应验证。"

**无法判断：**
- 任何来源均未找到相关信息
- 问题需要来源中不具备的专业知识
- "找不到相关信息。建议联系 [建议的专家/团队] 获取确定答案。"

### 矛盾处理

当来源信息不一致时：
1. 明确指出矛盾
2. 识别哪个来源更权威或更新
3. 呈现两种视角及其上下文
4. 建议如何解决分歧
5. 如果要给客户：在解决前使用最保守/谨慎的答案

---

## 升级 vs 直接回答

### 可直接回答的情况：
- 官方文档明确覆盖该问题
- 多个可靠来源交叉验证
- 问题事实性强且不敏感
- 答案不涉及承诺、时间线或定价
- 之前回答过类似问题且已确认准确

### 需升级或验证的情况：
- 答案涉及产品路线图承诺或时间线
- 定价、法务条款或合同相关问题
- 安全、合规或数据处理问题
- 答案可能形成先例或创造预期
- 来源中发现矛盾信息
- 问题涉及特定客户的定制配置
- 答案需要你不具备的专业知识
- 客户处于风险中，错误答案可能加剧局面

### 升级路径：
1. **领域专家**：技术或领域特定问题
2. **产品团队**：路线图、功能或能力问题
3. **法务/合规**：条款、隐私、安全或监管问题
4. **商务/财务**：定价、发票或付款相关问题
5. **工程**：定制配置、bug 或技术根因
6. **管理层**：战略决策、例外或高风险场景

---

## 知识库沉淀文档格式

调研完成后，沉淀知识供将来使用。

### 何时沉淀：
- 问题之前出现过或可能再次出现
- 调研花费了大量精力
- 答案需要综合多个来源
- 答案纠正了常见误解
- 答案涉及容易出错的细微之处

### 沉淀格式：
```
## [问题/主题]

**最近验证：** [日期]
**置信度：** [等级]

### 答案
[清晰、直接的答案]

### 详情
[支撑细节、上下文和细微之处]

### 来源
[信息来源]

### 相关问题
[可能有助于回答的其他问题]

### 复核备注
[何时重新验证、什么可能改变这个答案]
```

### 知识库维护：
- 所有条目标注日期
- 标记引用特定产品版本或功能的条目
- 每季度复核和更新
- 归档不再相关的条目
- 按主题、产品领域、客户分段打标签以便搜索

<SUBAGENT-STOP>