research

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

/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. 路径分隔符：用正斜杠 /，避免硬编码反斜杠 \。

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

路径自定位

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

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=

 [ -z  ]; 
      >&2
      >&2
     1

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

---

配置管理

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

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 "<用户输入>"

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

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

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. 管理层：战略决策、例外或高风险场景

---

知识库沉淀文档格式

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

何时沉淀：

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

沉淀格式：

## [问题/主题]

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

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

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

### 来源
[信息来源]

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

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

知识库维护：

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