靈能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 場景越復雜，越需要這種統一入口來支撐長期迭代。