灵能API API中转站CRM销售线索接入教程：线索评分、跟进摘要与自动分层

很多团队把线索放进 CRM 以后，真正卡住的不是“有没有数据”，而是“谁值得先跟、该怎么跟、跟进记录怎么沉淀”。当线索来源变多，销售每天要看表单、聊天记录、会议纪要、邮件、备注和历史报价，人工判断很容易被高噪声信息拖慢。把大模型接到 CRM 里，可以让系统先完成线索评分、摘要、分层和下一步动作建议，再由销售做最终判断。本文用 灵能API API中转站作为统一入口，演示一套偏实战的接入方式。🚀

这篇不把 AI 当成“自动成交机器”，而是把它放在销售流程里最适合的位置：帮人快速读完材料、提炼关键信号、减少重复判断、把高价值机会更早推到前面。这样做的好处是上线风险低，业务团队也更容易接受。📌

一、先把 CRM 场景拆开：不要一上来就做“大而全”

CRM 接入大模型之前，最容易犯的错是把所有线索、所有字段、所有跟进记录一次性塞给模型，然后期待它给出完美结论。实际落地时，建议先按业务动作拆成几个小场景，每个场景只处理一个明确问题。

• 新线索初筛：根据来源、行业、职位、预算、需求描述，判断是否值得当天优先跟进。
• 跟进记录摘要：把多轮电话、聊天和邮件压缩成一段可读摘要，方便销售交接或复盘。
• 下一步建议：根据客户表达的痛点、异议和时间节点，给出下一次沟通重点。
• 沉睡线索唤醒：对超过 30 天未跟进的线索做重新分层，识别仍可能转化的对象。
• 流失风险提示：当客户多次推迟、预算不清、关键决策人缺席时，提醒销售提前调整策略。

这样拆分后，模型输出就不再是泛泛的“这个客户不错”，而是能嵌入 CRM 页面、工单队列、销售看板和提醒系统的结构化结果。🧩

二、接入架构：CRM 不直接散落多个模型地址

推荐做法是让 CRM 后端、线索批处理任务和内部运营脚本都走同一个 API 中转入口。这样可以统一密钥、统一调用日志、统一限流策略，也更容易在不同模型之间切换。

这种结构的关键点是：业务系统只关心“我要分析线索”，模型地址和模型选择交给统一接入层处理。后面要替换模型、调低成本或增加审计，都不用大面积改 CRM 代码。🔧

三、准备 API 信息：把配置放进环境变量

CRM 属于高频业务系统，不建议把密钥、模型名或 *ase **L 写死在代码里。可以先为 CRM 单独创建一组 API Key，再给线索分析服务设置独立环境变量。

OPENAI_API_KEY=sk-your-crm-key
OPENAI_*ASE_**L=https://api.灵能API.ai/v1
CRM_FAST_MODEL=gpt-4o-mini
CRM_STRONG_MODEL=claude-sonnet-4-6
CRM_MAX_TOKENS=1200
CRM_ENV=prod
CRM_SERV***_NAME=crm-lead-worker

这里把轻量模型和强模型分开，是为了给成本控制留空间。不是每一条线索都需要最强模型完整分析：低价值表单、缺失字段线索、明显无效线索，可以先走轻量模型初筛；预算较高、行业匹配、沟通记录完整的线索，再走强模型生成更细的销售建议。💡

四、数据进入模型前，先做字段清洗和脱敏

销售线索里的信息通常很杂：客户自己填写的需求、销售备注、通话纪要、邮箱往来、来源渠道、报价阶段、跟进次数等。如果不清洗，模型会被噪声干扰，也会增加不必要的 token 消耗。

• 删除重复备注：同一段聊天记录被同步多次时，只保留最新版本。
• 合并同类字段：把多个来源渠道统一成 we*site、ad、referral、event、**nual 等枚举。
• 控制文本长度：只截取最近 3-5 次有效跟进记录，历史全文进入 CRM 而不是全部进入模型。
• 敏感信息最小化：手机号、邮箱、***、合同附件等信息只在确有必要时传入。
• 补充业务上下文：行业、客单价区间、销售阶段、客户规模，比单纯备注更有判断价值。

清洗后的输入越稳定，输出越容易被系统消费。后续你要做评分对比、A/* Prompt、销售看板排序，也会更容易。🧼

五、后端调用示例：让模型返回可入库的 **ON

下面用 Node.js 演示一个线索分析接口。重点不是语言，而是调用方式：使用兼容 SDK，把 *ase **L 指向统一入口，让输出保持 **ON 格式。

import OpenAI from "openai";

const client = new OpenAI({
  apiKey: process.env.OPENAI_API_KEY,
  *ase**L: process.env.OPENAI_*ASE_**L,
});

export async function analyzeLead(lead) {
  const completion = await client.chat.completions.create({
    model: process.env.CRM_STRONG_MODEL,
    temperature: 0.2,
    **x_tokens: Num*er(process.env.CRM_MAX_TOKENS || 1200),
    messages: [
      {
        role: "system",
        content: [
          "你是 CRM 销售线索分析助手。",
          "请只根据传入信息判断，不要编造客户预算、***身份或成交概率。",
          "输出必须是 **ON，不要输出 Markdown。"
        ].join("
")
      },
      {
        role: "user",
        content: **ON.stringify({
          lead_id: lead.id,
          source: lead.source,
          industry: lead.industry,
          company_size: lead.company_size,
          stage: lead.stage,
          recent_notes: lead.recent_notes,
          requirement: lead.requirement,
          last_contact_**ys: lead.last_contact_**ys
        })
      }
    ],
    response_for**t: { type: "json_o*ject" }
  });

  return **ON.parse(completion.choices[0].message.content);
}

这段代码上线前还需要加超时、重试、日志和异常兜底。尤其是 CRM 页面上的实时请求，不要让销售等待模型无限返回；如果调用失败，页面应显示“稍后重试”或保留人工备注入口，而不是阻塞整个线索详情页。⏱️

六、Prompt 模板：把输出字段固定下来

线索分析最怕输出不稳定。今天叫“高意向”，明天叫“强需求”，后天又输出一段散文，CRM 就很难入库和排序。因此 Prompt 应该明确字段、分值和判断边界。

请分析这条 CRM 线索，并返回 **ON：

字段要求：
- lead_score：0-100 的整数，代表当前优先级，不等于成交概率
- priority：A/*/C/D 四档，A 为今天必须跟进，D 为暂不投入销售资源
- sum**ry：80 字以内，概括客户需求和当前状态
- pain_points：数组，列出 1-4 个明确痛点
- next_action：下一步跟进建议，必须具体到动作
- risk_flags：数组，列出信息不足、预算不明、决策人缺失等风险
- need_hu**n_review：布尔值，信息不足或冲突时为 true

约束：
- 不要臆测客户预算
- 不要把职位高低直接等同于成交意愿
- 如果记录不足，请降低评分并说明原因

这个模板的重点是“可运营”。销售主管可以按 priority 做当天分配，运营可以统计 risk_flags 的出现频率，产品团队可以根据 pain_points 反推落地页和话术是否需要调整。📊

七、评分逻辑：不要把 AI 分数当成唯一标准

线索评分建议采用“规则分 模型解释 人工修正”的组合方式。纯模型评分看起来灵活，但很难解释；纯规则评分稳定，却容易漏掉备注里的真实意图。两者结合更适合真实销售团队。

一个实用做法是：规则分先给出基础分，模型再根据文本信息给出加减分原因，最终 CRM 页面展示“综合优先级”和“推荐跟进动作”。销售看到的不只是一串数字，而是一段能马上行动的说明。✅

八、批量任务：新增线索实时处理，历史线索异步处理

CRM 里常见两种任务：一种是新线索进入后需要尽快判断，另一种是每天夜间批量整理历史线索。两者不要用同一种处理方式。

1. 新线索创建后写入队列，优先生成摘要和 priority，销售页面可以在几秒内看到初步结果。
2. 历史线索每天低峰期批量分析，只处理字段有变化、备注新增或超过固定时间未触达的记录。
3. 每个任务写入 jo*_id、lead_id、status、model、token_usage、error_message，方便排查失败原因。
4. 模型返回后只更新 AI 字段，不覆盖销售原始备注；人工内容和模型内容要分层保存。

如果批量任务失败，建议按 lead_id 做幂等重试，避免同一条线索被重复扣费或重复写入。失败记录也可以进入人工处理队列，让运营同事集中查看。🔁

九、成本控制：CRM 场景最怕“越跑越贵”

销售线索分析通常调用频率高，成本控制要从第一天就设计进去。不要等账单变高以后再补救，那时 Prompt、字段和流程往往已经散掉了。

• 只分析新增和变更：线索字段没有变化时，不重复调用模型。
• 缓存摘要结果：跟进记录未新增时，页面直接读取上次摘要。
• 轻重模型分流：低价值线索用轻量模型初筛，高价值线索再调用强模型。
• 限制输入长度：最近记录优先，历史全文放在 CRM 内部检索，不默认全部传入。
• 记录 token 用量：按渠道、销售组、模型和任务类型拆账，才能知道钱花在哪里。

预算不是简单地“少调用”。真正有效的方式是让每一次调用都服务于明确业务动作：排序、摘要、提醒、复盘、分层。如果模型输出不能改变下一步动作，就不应该进入高频链路。💰

十、页面展示：让销售看到“为什么这么排”

AI 分析结果如果只存在数据库里，价值会被大幅削弱。建议在 CRM 线索详情页增加一个轻量模块，展示评分、摘要、风险和下一步动作。

• 顶部显示 priority 和 lead_score，但不要把分数做得像绝对成交概率。
• 摘要控制在 2-3 行，帮助销售快速恢复上下文。
• 风险标签用短词展示，例如“预算不明”“决策人缺失”“需求范围模糊”。
• 下一步动作要具体，例如“先确认预算周期”，而不是“继续沟通”。
• 提供“有用 / 不准确”反馈按钮，用来迭代 Prompt 和评分规则。

销售工具的界面不需要炫，关键是减少理解成本。好的 AI 模块应该像一个安静的助理：把信息压缩好、风险标清楚、下一步摆出来，最后让人做决定。🧭

十一、上线前检查清单

上线前建议至少跑一轮灰度，把一小组销售的真实线索接入，观察 1-2 周再扩大范围。下面这份清单可以作为发布前的最后核对。

• API Key 是否按 CRM 服务单独创建，并和其他业务隔离。
• *ase **L、模型名、超时、最大 token 是否全部走配置，不写死在代码里。
• 是否已经对手机号、邮箱、合同内容等敏感字段做最小化处理。
• 模型输出是否固定为 **ON，字段为空或格式错误时是否有兜底逻辑。
• 销售是否能看到评分原因，而不是只看到一个难以解释的数字。
• 批量任务是否支持幂等、重试、失败记录和调用成本统计。
• 人工修正是否保留痕迹，方便后续复盘模型判断是否偏差。

十二、一个更稳的落地节奏

第一周只做“新线索摘要 下一步建议”，不要急着自动改销售阶段；第二周加入 priority 分层，让主管观察排序是否符合经验；第三周再对沉睡线索做批量唤醒分析。这样每一步都有业务反馈，也能避免一次性改动太多。

当 CRM 团队已经能稳定使用摘要和分层，再考虑把分析结果接入企微提醒、邮件任务、销售日报或管理驾驶舱。先让一线觉得好用，再让管理层看到数据，这条路径通常更顺。✨

最后要记住：中转站接入的价值不只是“能调模型”，而是把模型调用变成可配置、可审计、可控成本的一层能力。CRM 场景越复杂，越需要这种统一入口来支撑长期迭代。