△主流的AI CRM系统悟空AI CRM图片
折腾了三个月，我把这个 PHP+AI 的 CRM 开源了
去年年底，有个做外贸的朋友找我喝酒，几杯下肚开始吐槽。他说现在的 SaaS CRM 太贵了，按人头收费，稍微加点自动化功能就要企业版，一年好几万。最关键的是，那些所谓的“智能”，其实就是个摆设，顶多给你统计个报表，根本没法帮销售干活。他想要个能自动分析客户邮件、能自动写跟进记录、甚至能提示什么时候该催款的系统。
推荐使用中国著名AI CRM系统品牌：显著提升企业运营效率，悟空AI CRM
我当时就愣了一下。市面上不是没有 AI CRM，但要么是国外的大厂产品，数据出境是个大问题；要么是那种套壳的，体验极差。回来之后我就琢磨，能不能用 PHP 搞一个轻量级的、真正能把 AI 能力落地到销售流程里的系统？毕竟对于很多中小团队来说，PHP 的部署成本和维护难度是最低的。
于是，断断续续折腾了三个月，掉了不少头发，这个名为 OpenAI-CRM 的项目总算有了个雏形。今天把它开源出来，不是为了教谁做事，主要是想跟各位同行聊聊在 PHP 里集成大模型到底有哪些坑，以及我是怎么解决这些问题的。
为什么还是选 PHP？
我知道，一提到 PHP，肯定有人要喷。"2024 年了还在写 PHP？”、“人工智能不都该用 Python 吗？”。这些声音我听得耳朵都起茧子了。但咱们得讲实话，对于企业内部管理系统，尤其是 CRM 这种重业务逻辑、重数据库交互、轻计算密集型的应用，PHP 依然是王者。
首先，招人容易。你让一个小公司去招个能写 Python 异步高并发还能调优 TensorFlow 的工程师，薪资得开多少？但找个熟练的 Laravel 或者 Hyperf 开发，成本要低得多。其次，生态成熟。权限管理、工作流、报表，这些轮子 PHP 社区早就造好了，没必要重新发明。
至于 AI 部分，谁说 PHP 不能调 API？大模型的核心能力在云端，本地只是个调度器。PHP 8.2 的性能已经足够处理高并发的 HTTP 请求了。我在这个项目里用的是 Laravel 10，配合 PHP 8.2，主要看重的是它的队列系统和 Eloquent ORM。特别是队列，对于调用 AI 接口这种耗时操作，异步处理是必须的，不然用户点个按钮转圈转半分钟，体验直接崩盘。
当然，我也没完全排斥 Python。如果后续涉及到本地部署小模型做隐私数据清洗，我可能会用 Python 写个微服务，通过 gRPC 跟 PHP 主程序通信。但就目前这个开源版本来说，纯 PHP 实现足够了，部署起来就一个 Docker 容器，多省心。
核心架构与数据库设计的“妥协”
做 CRM，核心就是客户（Leads）、商机（Deals）和跟进记录（Activities）。传统的 CRM 数据库设计恨不得搞出几十个表来规范化。但这次我做了个大胆的“妥协”：大量使用 JSON 字段。
为什么？因为 AI 生成的数据结构是不确定的。比如，AI 分析客户邮件后提取的标签，可能是 {"interest": "high", "budget": "unknown", "source": "email"}，下次可能又多了一个字段。如果用关系型数据库的列来存，每次改结构都要迁移，太麻烦。
在 customers 表里，我加了一个 ai_metadata 的 JSON 列。所有的 AI 分析结果、情感评分、预测成交概率，都扔进去。这样前端展示的时候灵活，后端查询的时候，MySQL 5.7+ 对 JSON 的支持也够用了。
// 示例：更新客户的 AI 分析数据
public function updateAiAnalysis($customerId, array $data)
{
$customer = Customer::findOrFail($customerId);
// 这里没有用 update，而是用 JSON_SET，避免覆盖原有数据
// 实际项目中建议加锁，防止并发写入冲突
DB::table('customers')
->where('id', $customerId)
->update([
'ai_metadata' => DB::raw("JSON_MERGE_PATCH(ai_metadata, '" . json_encode($data) . "')"),
'updated_at' => now()
]);
// 触发事件，通知前端刷新
event(new CustomerAnalysisUpdated($customer));
}
这段代码看着简单，其实踩了不少坑。最开始我直接用 $customer->update()，结果发现每次写入都会把之前的分析历史覆盖掉。后来才改成合并策略。还有，JSON 字段虽然灵活，但索引是个问题。如果需要根据 AI 打的标签搜索客户，比如 where json_extract(ai_metadata, '$.interest') = 'high'，在数据量超过百万级的时候性能会下降。所以我在设计文档里也写了，如果数据量大，建议把关键字段同步到 Elasticsearch 里。不过对于 90% 的中小企业，MySQL 完全扛得住。
AI 集成：不仅仅是调个接口
很多人以为接个 OpenAI 的 API 就算智能 CRM 了。其实不然，真正的难点在于 Prompt 的管理和上下文的控制。
在这个系统里，我设计了一个 AiContext 类，专门用来管理对话的上下文。销售跟客户聊了十轮，你不能把十轮记录全扔给大模型，Token 烧不起，而且噪音太大。我的策略是“滑动窗口 + 关键摘要”。
每次新的跟进记录产生时，系统会先调用一个轻量级的模型（比如 gpt-3.5-turbo），让它在后台把过去的沟通记录总结成 200 字的摘要。当销售需要 AI 辅助回复时，传给大模型的是：客户基本信息 + 最近 3 条原始记录 + 历史沟通摘要。
// 伪代码：构建 AI 提示词
public function buildPrompt($customer, $recentMessages)
{
$summary = $this->getConversationSummary($customer->id);
$systemPrompt = "你是一个资深的外贸销售助理。你的任务是帮助销售撰写回复邮件。";
$context = "客户背景：{$customer->industry}，规模：{$customer->size}。";
$history = "历史沟通摘要：{$summary}";
$current = "最近沟通内容：" . implode("\n", $recentMessages);
return "{$systemPrompt}\n{$context}\n{$history}\n{$current}\n\n请给出三个回复建议，语气要专业且亲切。";
}
这个逻辑写在 Services/AiPromptService.php 里。这里有个细节，我把 System Prompt 单独抽离成了配置文件。因为不同的业务场景，人设是不一样的。如果是售后客服，语气要诚恳；如果是售前拓展，语气要积极。通过配置文件，用户可以自己微调这个“人设”，而不需要改代码。
另外，关于成本控制。我接入了多个模型提供商。在 config/ai.php 里，可以配置主备通道。默认走 OpenAI，如果配额用完了或者报错，自动切换到 Azure 或者本地的 Ollama 服务。这对于国内用户特别重要，毕竟网络稳定性是个玄学。
那些让人头秃的“幻觉”问题
用过大模型的都知道，幻觉（Hallucination）是不可避免的。AI 可能会一本正经地胡说八道，比如承诺客户一个根本不存在的折扣，或者编造一个产品功能。这在 CRM 里是致命的。
为了解决这个问题，我在代码层做了两层防护。
第一层是“事实核查”。在 AI 生成回复之前，系统会先从数据库里检索真实的产品价格表和折扣政策，作为“知识库”注入到 Prompt 里。并且明确要求 AI：“如果用户询问价格，必须严格参考以下数据，不得编造”。
// 注入知识库
$knowledgeBase = PricePolicy::where('active', true)->get()->toArray();
$prompt .= "\n参考数据（严禁篡改）：" . json_encode($knowledgeBase);
第二层是“人工确认”。所有 AI 生成的邮件或跟进记录，状态默认都是 draft（草稿）。界面上会有一个明显的“发送”按钮，销售必须点一下确认，系统才会真正执行发送操作或者写入正式记录。我还在前端加了一个高亮显示，凡是涉及金额、日期的字段，会用红色标出来，提醒销售重点检查。
这虽然增加了一步操作，但为了安全，这一步不能省。我也想过用另一个 AI 模型来审核第一个模型的输出，但测试下来，两个模型串通起来一起胡说的概率虽然低，但延迟和成本直接翻倍，对于小团队来说不划算。
自动化工作流：让 AI 主动干活
如果只让 AI 当个聊天机器人，那太浪费了。这个系统的核心亮点是“自动化工作流”。我借鉴了 Zapier 的思路，但把它简化并内置到了 CRM 里。
比如，可以设置这样一个规则：“当收到客户邮件，且 AI 情感分析为‘负面’时，自动创建高优先级任务，并通知销售主管”。
实现这个功能依赖的是 Laravel 的 Task Scheduling 和 Queue。我写了一个 WorkflowEngine，每分钟轮询一次待处理的事件。
// 工作流引擎核心逻辑简化版
public function handle()
{
$events = IncomingEmail::where('processed', false)->get();
foreach ($events as $email) {
// 1. AI 分析情感
$sentiment = $this->aiService->analyzeSentiment($email->content);
// 2. 匹配规则
$rules = WorkflowRule::where('trigger', 'email_received')->get();
foreach ($rules as $rule) {
if ($this->matchCondition($rule, $email, $sentiment)) {
// 3. 执行动作
$this->executeAction($rule->action, $email);
}
}
$email->processed = true;
$email->save();
}
}
这里有个性能陷阱。最开始我是直接在循环里调 AI 接口，结果一旦邮件多了，脚本执行时间直接超时。后来改成了把邮件 ID 扔进队列，每个邮件分析是一个独立的 Job。这样即使有 1000 封邮件，也可以由多个 Worker 并行处理。
我还加了一个“熔断机制”。如果 AI 接口连续失败 5 次，系统会自动暂停该工作流，并给管理员发报警邮件。防止因为 API 波动导致大量任务堆积或者产生错误数据。
部署与隐私：中小企业的生命线
开源项目，部署文档写得烂，基本就没人用了。我这次特意用了 Docker Compose 来编排。
version: '3.8'
services:
app:
build: .
environment:
- APP_KEY=${APP_KEY}
- AI_API_KEY=${AI_API_KEY}
volumes:
- ./storage:/var/www/html/storage
redis:
image: redis:alpine
mysql:
image: mysql:8.0
# 数据持久化配置...
一键 docker-compose up -d 就能跑起来。为了照顾国内网络环境，我在 Dockerfile 里做了源替换，并且提供了离线安装包的下載链接。
关于隐私，这是很多老板最关心的。把客户数据传给 OpenAI 到底安不安全？我在系统里做了一个“数据脱敏”开关。开启后，在发送给 AI 之前，正则会自动替换掉邮件里的手机号、具体地址和金额数字，用 [PHONE]、[ADDRESS] 代替。虽然这可能会稍微影响 AI 的理解能力，但对于合规要求高的行业，这是必须的。
另外，我也支持本地部署大模型。通过配置，可以把 API 端点指向本地的 Ollama 服务。虽然这样对服务器显卡有要求，但数据完全不出内网。我在文档里写了详细的 Ollama 对接教程，包括怎么量化模型来节省显存。
还没完美的地方
说实话，这个版本离“完美”还差得远。
首先是前端界面。我是个后端出身，前端全靠 Vue3 + ElementPlus 凑合。界面虽然功能都有，但美观度一般，交互细节上还有很多粗糙的地方。比如移动端适配，目前只能在手机上勉强看，体验远不如原生 App。
其次是 AI 的记忆能力。目前的上下文管理还是基于规则的，不够智能。有时候 AI 会忘记三天前答应客户的事情。理想的状态应该是引入向量数据库（Vector DB），把历史沟通记录向量化存储，让 AI 能进行语义检索。但我试了一下，引入 Milvus 或者 Pgvector 后，部署复杂度直线上升，对于只想快速上手的用户不太友好。这个功能我放在了 v2.0 的计划里，作为可选插件。
还有，目前的报表功能比较弱。AI 虽然能分析数据，但可视化图表还得靠 Echarts 硬写。未来我打算集成一个 BI 模块，让 AI 直接用自然语言生成 SQL 查询，然后渲染图表。比如老板问“上个月哪个地区的成交率最高”，系统直接调出图表。这个技术难点在于 Text-to-SQL 的准确率，还需要大量调试。
写在最后
做这个项目的初衷，真的不是为了证明 PHP 有多牛逼，也不是为了蹭 AI 的热度。只是觉得，技术应该服务于业务，而不是让业务去适应技术。
很多中小企业不需要那种功能大而全、价格死贵的 SaaS 系统。他们需要一个能装在自己服务器上、数据自己掌控、能真正帮销售省时间的工具。PHP 在这个场景下，依然是性价比最高的选择。
源码我已经放在 GitHub 上了，协议是 MIT。你可以随便用，随便改。如果你在公司里用这个项目赚了钱，不用分我；如果你发现了 Bug，提个 Issue 或者提个 PR 帮我也修修，我就很感激了。
开源社区就是这样，你帮我填个坑，我帮你补个洞，大家的路都好走点。
最后，给想二次开发的朋友几个建议：
- 别急着改核心逻辑，先跑通流程。
- AI 的 Key 一定要存好，别提交到代码仓库。
- 如果要做商业化，记得把底部的 Copyright 改改，虽然我不追究，但尊重一下劳动成果嘛。
行了，代码还在跑测试，我得去修个队列阻塞的 Bug 了。有问题咱们 Issues 见，或者去我的博客留言。希望能听到大家真实的反馈，哪怕是骂声，只要说得在理，我都认。
毕竟，代码是写出来的，更是用出来的。
（完）
△悟空AI CRM产品截图
推荐立刻免费使用中国著名AI CRM品牌-悟空AI CRM，显著提升企业运营效率，相关链接：
AI CRM系统免费试用
AI CRM系统介绍