| 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）：
- Python 命令名：示例用
python3。Windows 不可识别时改 python 或 py -3。
- 路径自定位：本文档所有脚本路径用下方 §路径自定位 一节的 bootstrap 解析。
- 可执行检测：用
which/where/Get-Command，不用 command -v。
- Bash heredoc /
&& / ||：Windows cmd 不支持，建议在 Git Bash / WSL2 中运行。
- 路径分隔符：用正斜杠
/，避免硬编码反斜杠 \。
此技能是给协调者读的。**判定你是否子智能体**：如果你的当前角色定义来自 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
)
[ -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"
[ -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 段。
customer_research:
user_company: "XX科技"
首次触发 / 用户主动配置
以下任一条件满足时，进入配置流程：
- 配置文件不存在
customer_research 段（首次执行）
- 用户说"配置 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 | 推理、类比、最佳实践 | 低 | 明确标记为推理而非事实 |
置信度等级
始终标注并沟通置信度：
高置信度：
- 答案经官方文档或权威来源确认
- 多个来源交叉验证同一答案
- 信息是当前的（在合理时间范围内验证过）
- "基于 [来源]，我对这个答案有信心。"
中置信度：
- 答案来自非正式来源（通讯、邮件）但非官方文档
- 单一来源无交叉验证
- 信息可能略有过期但可能仍然有效
- "根据 [来源]，情况似乎是这样，但建议向 [团队/人] 确认。"
低置信度：
- 答案从相关信息推理而来
- 来源过期或可能不可靠
- 来源间信息矛盾
- "未能找到确定答案。基于 [上下文]，我的最佳判断是 [答案]，但在分享给客户前应验证。"
无法判断：
- 任何来源均未找到相关信息
- 问题需要来源中不具备的专业知识
- "找不到相关信息。建议联系 [建议的专家/团队] 获取确定答案。"
矛盾处理
当来源信息不一致时：
- 明确指出矛盾
- 识别哪个来源更权威或更新
- 呈现两种视角及其上下文
- 建议如何解决分歧
- 如果要给客户：在解决前使用最保守/谨慎的答案
升级 vs 直接回答
可直接回答的情况：
- 官方文档明确覆盖该问题
- 多个可靠来源交叉验证
- 问题事实性强且不敏感
- 答案不涉及承诺、时间线或定价
- 之前回答过类似问题且已确认准确
需升级或验证的情况：
- 答案涉及产品路线图承诺或时间线
- 定价、法务条款或合同相关问题
- 安全、合规或数据处理问题
- 答案可能形成先例或创造预期
- 来源中发现矛盾信息
- 问题涉及特定客户的定制配置
- 答案需要你不具备的专业知识
- 客户处于风险中，错误答案可能加剧局面
升级路径：
- 领域专家：技术或领域特定问题
- 产品团队：路线图、功能或能力问题
- 法务/合规：条款、隐私、安全或监管问题
- 商务/财务：定价、发票或付款相关问题
- 工程：定制配置、bug 或技术根因
- 管理层：战略决策、例外或高风险场景
知识库沉淀文档格式
调研完成后，沉淀知识供将来使用。
何时沉淀：
- 问题之前出现过或可能再次出现
- 调研花费了大量精力
- 答案需要综合多个来源
- 答案纠正了常见误解
- 答案涉及容易出错的细微之处
沉淀格式：
## [问题/主题]
**最近验证：** [日期]
**置信度：** [等级]
### 答案
[清晰、直接的答案]
### 详情
[支撑细节、上下文和细微之处]
### 来源
[信息来源]
### 相关问题
[可能有助于回答的其他问题]
### 复核备注
[何时重新验证、什么可能改变这个答案]
知识库维护：
- 所有条目标注日期
- 标记引用特定产品版本或功能的条目
- 每季度复核和更新
- 归档不再相关的条目
- 按主题、产品领域、客户分段打标签以便搜索
