客户透镜

要解决什么问题

销售或售前往往要在见客户前把一家公司的工商身份、股权结构、招聘信号、招投标角色和风险线索拼清楚，但信息散落在企查查类 API、官网、新闻和招采站里，还容易把同名主体、母子公司和品牌运营方混在一起。更麻烦的是：调研写成长报告，CRM 里仍要手工填字段，事实和「我觉得他可能需要云」的假设也常混在一起。

客户透镜面向「只研究一个已指定企业主体」的场景：只用公开、合法、可定位的信息，不做批量获客，也不碰 CRM 外联、绕过登录或非公开个人信息。

技能如何工作

最高优先级是 CRM-first：输出契约固定为 crm-customer-list.v2，且只含一个客户；stage 为 lead，grade 为 B（等级由销售在 CRM 里定）。公开事实必须投影到 CRM 已支持的 fields 以及 orgChain、marketNews、hiringSignals、bidding、qualifications、businessBrief 等板块，不得要求 CRM 为新页面或新字段改产品。

典型流程可以概括为：

• 锁定主体：至少两个独立来源确认标准名称，尽量核对统一社会信用代码、注册地、法人与官网；主体冲突未消解则停止交付。
• 规划来源与 MCP：按 playbook 依次用企信慧眼、天眼查、企查查交叉核验，再用官网、监管、法院、招采原文等补足可点击证据；工具不可用会在 source_coverage 里标明。
• 研究矩阵与证据账本：按维度填写 verified / partial / not_found 等覆盖状态；主张引用 E001 起编号的证据，冲突写入 conflicts[]。
• 交付：从 Schema 脚手架生成 JSON，再由 render-research.mjs 生成 Markdown/HTML；须通过 Schema 校验、质量审计与三文件一致性检查。

可选模块 deepResearch.sales_strategy（含腾讯产品线机会、竞品、面客议程等）一律标为推测与待确认，不写入 CRM 公开事实字段；deepResearch 本身也不供 CRM 页面消费。

适用边界

• 不得输出 opportunityIntelligence，不得伪造跟进记录、预算或已确认需求。
• 没有 Node.js 或无法跑交付脚本时，只能报告交付被阻止，不能手写三份文件冒充完成。
• 股权穿透、人员关系仅记录公开可证信息；不得把推测写成事实，也不得用「暂无」「未知」占位 CRM 字段。