Case 01 AI CRM

项目概览

让销售在飞书里直接问业务，而不是先学会一套 CRM。

DifyCRM 是一套围绕获客与销售跟进设计的轻量 AI CRM。 销售不必离开熟悉的飞书，也不必记住复杂菜单：问一句客户近况、这周先跟谁， 系统就从真实业务数据中整理出可以继续行动的答案。

我负责从业务场景、信息架构到系统落地的完整设计。 项目重点不是增加一个聊天入口，而是让对话真正连接线索、客户、商机与跟进记录。

项目范围：获客分析、线索评分、客户转化、跟进记录与销售回顾
使用入口：飞书对话
核心原则：AI 负责理解与组织，业务系统负责记录与执行

业务问题

对许多中小团队来说，线索并不少，只是散在表格、群聊和个人记忆里。 销售要花时间找上下文，优先级靠经验判断；管理者看到的是一堆记录， 却很难快速回答「哪些机会值得本周投入」。

我把目标收敛为一个简单体验：在沟通发生的地方，直接得到可行动的业务答案。 用户不需要理解数据存在哪，也不需要把自然语言改写成系统命令； 但每个金额、状态和负责人仍来自可追溯的 CRM 数据，而不是模型临时编出的答案。

核心体验

飞书助手覆盖获客到跟进的完整业务动作，而不是只有少数演示脚本。当前已支持：

下面只展开三个高频时刻，方便快速理解产品怎么用。

1. 跟进前，先把客户情况讲清楚

销售可以直接问：帮我看看云启科技周总这条线索，现在什么情况？

界面示意加载中
演示截图

2. 线索很多时，先找出最值得投入的机会

销售或主管可以问：这周销售侧优先跟哪几条？给我按把握排一下。

界面示意加载中
演示截图

3. 每周回顾时，把数据变成行动清单

助手汇总本周线索变化、漏斗状态和下一步建议，减少人工拼报表。

界面示意加载中
演示截图

方案设计

系统按 Agent 链路组织：先理解用户在问什么，再决定走哪条工具路径。 话术与知识走检索，画像与交易数据走结构化存储，写操作必须落到明确的业务函数。

例如「周总现在什么情况」会先被识别为客户洞察类意图：画像与交易字段查 MySQL， 跟进建议可叠加 RAG 中的话术材料，最后再合成一条可执行的回复。

关键取舍

设计原则： ① 业务规则只维护在 Domain API，避免同一规则在多处漂移； ② 金额、状态、负责人等结构化字段只查 MySQL，确保结果可核对； ③ 自然语言最终转换为明确的 function calling，让每次查询和写入都有边界。

业务动作

用户面对的是自然语言，系统内部面对的是清晰的意图、参数和工具函数。 Agent 负责把前者转换为后者，再由 Domain API 完成查询或写入。

自然语言示例 Function calling 业务结果
录入线索：周总，云启科技… create_lead 写入线索并自动评分
列出当前线索 list_leads 按评分等排序只读列表
给线索重新评分 score_lead 更新评分与原因
把线索转成客户 convert_lead 创建客户与商机
跟进一下周总… add_followup 跟进记录 + 摘要与下一步
打开我的面板 dashboard 待跟进、高分线索、建议
看一下销售漏斗 funnel_stats 阶段分布与解读
各渠道获客怎么样 acquisition_stats 渠道线索 / 转化 / 成本
Agent 统一入口接收自然语言；识别意图后调用上表工具函数，再把结构化结果写回飞书。

产品边界

实现参考

以下内容用于说明项目如何组织和复现，不影响上面的产品主线。

项目结构

DifyCRM/
  src/       FastAPI 业务服务
  sql/       建表与演示数据
  scripts/   初始化与启动
  dify/      工作流 DSL 与集成说明
  docs/      入门地图、DEMO、PRD

主要 Function calling

函数说明
create_channel / create_campaign渠道与营销活动
create_lead / list_leads / score_lead / convert_lead线索全链路
create_customer / list_customers客户管理
add_followup跟进记录与摘要
source_stats / acquisition_stats / funnel_stats / dashboard分析与面板
help能力说明

部署关系

Dify、LangBot 与飞书接入属于独立的运行环境；本业务仓提供 Domain API、数据结构和工作流 DSL。