Django 做一个 AI 销售助手：读取客户记录。自动生成跟进计划

销售助手最容易做成一个“看起来很聪明”的聊天框：把整张客户表塞给大模型，让它再允许它自动发消息。演示很顺，真正接入 CRM 后却会遇到三个痛点：

• 客户数据过量——模型需要处理海量历史记录。导致输出不准确、性能低下。怎么说呢，
• 模型输出不稳定——同一请求可能得到不同的建议。难以验证与追踪，
• 一次误操作就可能直接打扰客户——错误的自动化推送会造成声誉损失。

先把 AI 放在正确的位置

在这个流程里Django 与 AI 的职责是分离的：

• Django 负责身份、组织范围、查询和任务落库；
• Python 规则负责过滤已关闭商机、限制条数和计算风险分；
• AI 只把已经筛选的业务事实组织成标题、优先级、截止时间和理由；
• 人决定是否执行，确认后程序才创建任务。

从真实 CRM 字段构造最小上下文

RuyiDjangoCRM 的客户记录包含名称、领域、

AI 不需要看到所有字段。销售跟进场景里可以只给它：

def compact_context:
open_items = not in {"CLOSED_WON","CLOSED_LOST"}
]
ranked = sorted
return {
"account": {
"id"这方面。account,"name": account,"industry": account.get,},"opportunities": ranked,}

风险排序不要全部交给大模型

"哪些商机更该先跟进"包含可计算事实。示例采用一个朴素评分：目前这个阶段停留越久分数越高；金额达到 10 万加 1 分；成交概率达到 80% 加 1 分。

def risk_score:
score = min),30)
score += 1 if float)>= 100_000 else 0
score += 1 if int)>= 80 else 0
return score

This is a simple yet explainable starting point;enterprises can replace thresholds with ir own sales rules and test validation.

让模型只返回严格 JSON

The tool call should have clear semantics: name。precise type and boundaries. For this assistant model output can be narrowed to five fields:

{
"opportunity_id": "o1","title": "确认年度续费决策时间","priority": "High","due_in_days": 5,"reason": "金额较高，且已在方案阶段停留15天。"
}

The server n validates that:

• The fields match exactly; no extras.
• priority is one of "Low","Medium","High".
• The due date falls within an acceptable range.
• The opportunity ID exists in this query result.

人工确认后才创建任务

The preview stage returns context and plan without writing to database:

preview = {"context": context。"plan": plan,"created": False}
if not confirmed:
return preview
# on confirmation:
task = crm_create("tasks",{
"title": plan.title,"status":"New","priority":plan.priority,"due_date": computed_due_date,"description":plan.reason,"_opportunity_id":plan.opportunity_id,})

The due date is computed by server based on “X days from now”;models cannot provide arbitrary dates. The task uses existing CRM API so remains under user identity and organization scope constraints.

测试验证了什么？

• C01: 高金额且长时间停滞的商机会被排到前面。按理说，
• C02: 已成交或关闭的商机会不会出现在跟进列表中。
• C03: 客户邮箱不会进入模型上下文。
• C04: 未确认时不产生任何写操作。
• C05: 确认后创建并关联正确商机。
• C06: 截止日期由服务端计算而非模型直接提供。
• C07: 未知优先级、多余字段或不可见商机会被拒绝。
• C08: 模型上下文最多保留10条商机，以防数据泛化过度。

This minimal experiment uses an in-memory CRM and fixed model output—no external API key needed—run with python -m unittest -v .

来源与证据

示例代码与最小实验保存在同一工作目录。 真实项目证据固定在 RuyiDjangoCRM 提交 1fc5290f :MCP 查询与注册相关定向测试通过 Django 任务接口与商机老化相关测试通过。不过， 这篇文章没有将这些测试扩张为“AI 销售策略正确”的结论。它们仅证明字段/接口/边界可运行。

python -m unittest -v

`

最终

`
一个能上线的 AI 销售助手价值不在于说了多少漂亮话，而在于能否把现有业务数据变成一条可检查、 可确认且可追踪的接下来行动。至于最稳妥起点是，Django 保管事实和权限规则完成筛选；老实说，AI生成计划；人确认后才创建任务。等这条链路准确率/可观测性/使用者反馈稳定。再考虑会议摘要、 历史偏好或自动沟通，成本与风险更可控。

`

---