简介面向低代码开发者和CRM系统管理员的深度实践文档围绕DeepSeek API与简道云平台系统讲解CRM智能辅助系统的搭建思路。文档从低代码概念与CRM现状切入逐步解析DeepSeek API的技术原理、调用流程以及简道云的表单、流程、数据管理等功能模块随后展开客户信息管理、销售机会预测、智能客服、智能营销等核心功能的开发细节并覆盖集成测试、性能优化、部署维护与案例复盘。包内为1个PDF文件共30页压缩包约2.03MB目录结构完整、图文显示正常全文章节清晰、由浅入深目前已有97人学习下载。读者既可了解低代码平台与AI服务结合的架构设计也可参照具体实现步骤落地自己的智能CRM项目适合需要快速搭建业务系统、引入AI能力并降低开发成本的团队与个人开发者参考。1. 低代码整合方案DeepSeek API 加简道云把 CRM 变成会建议的助手简道云里的客户表越堆越长但没人每天盯着字段更新销售跟进前翻客户历史要花十分钟。这套方案把 DeepSeek API 塞进简道云 CRM用低代码方式做一个智能辅助层自动把客户背景补全、按上次沟通生成跟进话术、识别风险客户并提醒。它适合手里已经跑着简道云、又不想为 AI 重写一套系统的中小企业也适合做低代码交付的乙方。这份资源给了完整的架构、请求样例、字段映射和避坑记录照着搭两三天就能跑起来不是概念稿。2. 为什么是这套组合CRM 数据底座与 AI 推理层的职责边界2.1 简道云管事实DeepSeek 管判断先想清楚一个问题CRM 系统里最重要的是什么是可追溯的事实——客户什么时候建的、谁负责的、报价多少、上次沟通结论是什么。这些数据必须稳定、有权限、能审计。简道云这类低代码平台最适合干这件事它有表单、流程、权限和可视化销售填表不用学 SQL做二次开发也不需要引入重型框架。而 DeepSeek API 擅长的是基于事实做判断。给它一堆客户资料它能总结客户画像、生成跟进话术、判断意向等级。但它不能替代 CRM因为模型会幻觉会把不存在的报价说得像真的一样。所以边界必须清晰简道云存事实DeepSeek 出建议建议经过人确认后回填成新事实。这样即使 AI 错了也不会污染原始数据。这个边界定了之后后面所有设计都好做AI 返回的内容一律进“AI 建议表”等销售点了确认再写入正式字段。我见过不少人一开始图省事把 AI 建议直接回写到客户主表结果 AI 一句话把客户行业改错了销售都没发现。数据一旦被污染这套系统就失去意义后面所有统计都会跟着错。2.2 两种对接路线简道云内直连与中间件桥接低代码平台调用外部 API常见有两条路。第一条是在简道云内部用插件或智能助手直接发 HTTP 请求优点是链路短但缺点也很明显简道云的自带动作对请求体限制多超时、鉴权、响应解析都不可控排查问题非常痛苦。第二条是中间件桥接用一个轻量服务比如云函数或 FastAPI封装 DeepSeek API简道云负责存储和展示中间件只做数据转换与模型调用。我一般选第二条因为 AI 调用涉及密钥、重试、速率限制这些逻辑放中间件里最好维护。你可以理解成三段简道云表单采集数据 → 中间件从简道云拉数据、调 DeepSeek、把结果写回去 → 销售在简道云看到建议并确认。这样简道云仍然是业务系统的唯一入口AI 只是外挂的一个大脑。下面这张表是两条路线的对比选型直接拍板就行。对比项简道云内直连中间件桥接链路长度短多一跳但可接受调试难度高日志少低可本地断点密钥管理暴露在平台内收在服务端超时/重试难控制完全可控并发与限流难以精细控制可做队列和退避适合规模实验、几十条/天生产环境如果你的试用场景只是每天查十几个客户直连也能跑但要做到按客户批量生成话术、定时补全资料就必须上中间件。后面的章节按中间件路线写这也是这份方案的主结构。2.3 数据流从表单提交到 AI 建议回填的四步流转具体的数据流可以拆成四步每一步职责单一方便日后排查。第一步简道云里的客户主表有新增或修改时通过定时任务或手动触发把增量数据推给中间件。第二步中间件把客户字段拼成一段上下文提示词调用 DeepSeek API得到结构化的 JSON。第三步中间件把 JSON 回写到简道云的“AI 建议表”状态设置为“待确认”。第四步销售在建议表里看到内容点击确认后由数据助手把建议中的关键字段写入客户主表。这四步中第二步最容易翻车。提示词拼得好不好直接决定输出质量后面我会专门讲提示词模板。第三步也容易踩坑简道云开放 API 写入时字段标识要用表单的 UID不是显示名称。很多人拿着中文名去写返回 400 查半天。我们当时也在这个问题上卡了一个下午最后才发现文档里写的是控件的别名。另外数据流还要考虑频率。CRM 数据不是高频交易数据单客户每天生成一两次建议就够。所以中间件没必要常驻高并发按现在的免费或低配云函数足够。如果一天只有几百次调用用定时任务触发就好不需要上消息队列。单位成本很低重点是把流程跑通、让销售真正用起来。2.4 成本与配额先按千次调用算账再决定要不要全量跑AI 接入最容易被忽视的就是成本。很多团队做完 POC 一算发现把存量客户全量跑一遍比想象中贵。建议在动手前先做一个估算表平均每次请求消耗多少 token覆盖多少客户每天跑几轮乘以单价就知道一个月大概花多少。DeepSeek 的价格是公开的但不同时间可能有调整所以我一般让团队按“每千 token 单价 × 平均请求 token 数×请求次数”自己算而不是直接抄网上的结论。我见过一个比较典型的翻车案例方案里写“全量客户每天自动生成建议”但没考虑到每个客户的资料长短不一最终平均请求 token 数比预期翻了四倍。原因是提示词里把三年历史跟进记录全塞进去了。解决办法是在上游先把客户资料浓缩成最近几条关键记录再喂给模型。成本控制不是省出来的是设计出来的上下文折叠能做到又省又准。3. DeepSeek API 接入鉴权、请求体与 HTTP 服务封装3.1 准备凭据与最小调用骨架先去 DeepSeek 开放平台创建 API Key然后把 Key 放进环境变量不要写死在代码里。常见做法是用.env文件管理并在gitignore里排除。DeepSeek API 兼容 OpenAI 格式base_url固定为https://api.deepseek.com模型名用deepseek-chat或deepseek-reasoner。这里要分清会话摘要、话术生成这类任务用deepseek-chat就够deepseek-reasoner适合需要深层推理的场景但更慢也更贵在 CRM 辅助场景里多数不是刚需。下面是一个最小可用的 Python 调用示例使用openai库import os from openai import OpenAI client OpenAI( api_keyos.getenv(DEEPSEEK_API_KEY), base_urlhttps://api.deepseek.com ) resp client.chat.completions.create( modeldeepseek-chat, messages[ { role: system, content: 你是CRM辅助助手。只根据客户资料生成跟进建议不要编造客户没说过的话。 }, { role: user, content: 客户张总行业制造业最近沟通询价后未确认历史订单无。 } ], temperature0.3, max_tokens500 ) print(resp.choices[0].message.content)这里有两个参数值得说。temperature我习惯调到 0.3因为 CRM 场景要的是稳定可复现的输出温度越高越容易发散把风险等级写成互相矛盾的词。max_tokens限制在 500 以内一是控制成本二是避免返回内容太长回写简道云时被字段长度截断。500 个 token 足够生成一小段跟进话术和摘要了。3.2 把调用封装成 FastAPI 服务简道云那边的自动化动作不能让每一个表单都直接去请求第三方 API最好通过一个内部服务中转。我一般用 FastAPI 写一个很薄的接口入参是客户资料出参是固定结构的建议 JSON。为什么要固定结构因为要回填到简道云的独立字段结构不固定解析就会断。from fastapi import FastAPI, Request from openai import OpenAI import os, json app FastAPI() client OpenAI(api_keyos.getenv(DEEPSEEK_API_KEY), base_urlhttps://api.deepseek.com) app.post(/suggest) async def suggest(request: Request): payload await request.json() customer payload.get(customer, {}) text ( f客户{customer.get(name)} f行业{customer.get(industry)} f最近沟通{customer.get(last_note)} f历史订单{customer.get(order_count) or 无} ) resp client.chat.completions.create( modeldeepseek-chat, messages[ {role: system, content: 输出JSON包含summary、next_action、risk_level三个字段risk_level只能是高/中/低。}, {role: user, content: text} ], temperature0.3, max_tokens500, response_format{type: json_object} ) content json.loads(resp.choices[0].message.content) return { summary: content.get(summary, ), next_action: content.get(next_action, ), risk_level: content.get(risk_level, 低) }需要注意DeepSeek API 的response_format设置成json_object才会稳定返回 JSON否则经常会在前后加解释性文字。FastAPI 里加一个超时控制调用模型时设置timeout30超过 30 秒就返回兜底文案防止简道云那边一直挂起。很多人第一次写这个接口时只处理成功路径一旦 DeepSeek 超时或返回内容不是合法 JSON整个程序直接抛异常结果就是简道云里的自动化任务每到下午就失败一批。3.3 简道云侧的回写字段设计接口跑通后要在简道云里建一张“AI 建议表”专门接收中间件回写的数据。字段不要随意命名建议按下面的清单建API 标识保持一致。中文名API 标识类型说明关联客户rel_customer关联表单关联客户主表记录客户摘要summary多行文本AI 生成的客户画像摘要建议动作next_action多行文本下一步跟进建议风险等级risk_level单选高/中/低状态status单选待确认/已确认/已忽略AI 用 token 数usage_tokens数字成本核实用回写时通过简道云开放平台的 API 调用注意表单的 API 标识和显示名称的区别。比如在简道云里新建字段时显示名叫“风险等级”但 API 标识可能是risk_level回写时要用risk_level而不是中文。这张表建好后中间件拿到接口返回的 JSON直接映射到对应字段即可。这样销售打开建议表看到的是一行一行结构化结果不是一大段原始 AI 文本。3.4 部署方式云函数与常驻主机怎么选中间件可以部署在云函数上也可以放在一台常驻的轻量服务器上。云函数的好处是缩容快平时不调用不计费坏处是冷启动会带来 2~5 秒延迟而且像 FastAPI 这类框架需要打包成特定入口格式部署时多一道工序。常驻主机的好处是稳定日志查看方便适合后期要挂定时任务的场景。我的建议是如果只是试跑用云函数如果要在上面跑每日定时批处理用一台最便宜的云主机更省心因为定时任务需要长驻进程。部署完成后可以用curl做一个快速验证确认接口能正常返回curl -X POST http://127.0.0.1:8000/suggest \ -H Content-Type: application/json \ -d {customer:{name:测试客户,industry:医疗,last_note:上周询价,order_count:1}}看到返回{summary:...,next_action:...,risk_level:低}就说明链路通了。接下来才轮到简道云侧的数据助手去对接这个地址。很多人喜欢先改简道云再去调试接口最后两边一起报错很难判断谁有问题。标准流程应该是先把中间件的输入输出固定死再连简道云。4. CRM 智能辅助落地客户画像补全、话术生成与风险提醒4.1 数据模型主表、行为表、建议表怎么协同这套系统的核心不是算法而是数据模型。我建议至少拆三张表客户主表存基本信息跟进记录表存每次沟通的原始过程AI 建议表存模型输出和人工确认结果。为什么要单独建“AI 建议表”而不是把 AI 生成的内容直接塞进客户主表因为客户主表是业务事实AI 输出是推断结果两者混在一起后期做筛选和复盘会非常混乱。客户主表字段不必多有客户名称、行业、规模、负责人、最近跟进时间就够了。跟进记录表负责记录每一次与客户的沟通过程销售在简道云里新增一条跟进记录时把内容填进一个多行文本字段中间件就能自动把最新记录提取出来。AI 建议表则负责承载模型的输出以及销售最终确认的内容。三张表形成一条清晰的链路客户主表是身份跟进记录表是原料AI 建议表是产物。实际落地时我会在简道云里给这三张表都建好视图。销售每天打开仪表盘只看到 AI 建议表里状态为“待确认”的记录。确认后建议中的关键信息通过数据助手写入客户主表状态变为“已确认”。这样既保留 AI 判断的痕迹又保证主表干净。4.2 自动化流程新客户触发、定时补全、批量生成数据模型建好后要接自动化。第一步是新客户触发当客户主表新增记录时简道云的数据助手可以把新增客户的信息推给中间件中间件调 DeepSeek 生成初始画像和跟进建议。第二步是定时补全对超过三天没有 AI 建议的客户用定时任务批量跑一遍中间件逐条调用模型并回写让销售每天早上一打开系统就有最新建议。第三步是风险提醒在 AI 建议表里加一个“风险等级”维度当模型识别到客户超过两周未响应、或者近期订单下降时通过简道云的流程通知推给负责人。这个环节不需要太复杂的逻辑只要中间件返回的风险等级为“高”就自动发一个待办。我做这个方案时第一条风险预警出来销售负责人还挺惊讶因为确实有一个客户连续三周没回复表面上看和正常客户没差别。自动化的频率要控制好。DeepSeek API 不是无限免费的即便付费也有速率限制所以我建议在中间件里加一个简单的频率控制比如每个客户每天最多生成两次建议。简道云的数据助手会触发很多次不加控制可能一天就把一个月配额打光。这个点放在避坑部分详细讲。4.3 提示词模板与参数选择决定输出质量的关键低代码平台里调试提示词不方便最好在本地先把模板跑通再搬到中间件里。CRM 场景的提示词不需要写得多花哨关键是约束模型不要编造事实。我常用的模板结构是先给角色定义再给客户资料最后给输出格式。你是 CRM 辅助助手。你只能基于提供的客户资料输出内容禁止补充资料里没有的信息。 客户资料 - 名称{{name}} - 行业{{industry}} - 最近跟进{{last_note}} - 历史订单数{{order_count}} 请输出 JSON包含 - summary80 字以内的客户摘要 - next_action一条具体的下一步动作 - risk_level高/中/低并给出理由这个模板里最有价值的是最后一行“并给出理由”。如果只让模型输出高中低它经常拍脑袋让它说理由至少能把这些词和客户资料对应上。参数上temperature用 0.3top_p我一般不动保持默认。max_tokens根据输出长度设置摘要加话术 500 token 足够。如果发现输出内容经常被截断先不要急着加 token先去调整提示词让模型更精简。4.4 从现有 CRM 迁移存量数据字段映射与清洗规则如果你已经在用其他 CRM 工具迁移到这套方案时有一个容易被忽略的步骤字段映射。不同 CRM 对客户名称、行业、跟进记录的叫法不同直接导入简道云会丢字段。我建议先做一张映射表把旧系统的字段翻译成新系统的 API 标识再写脚本清洗。清洗的核心规则是去重和截断。旧系统里同一个客户可能有多个重复记录需要按客户名称或统一社会信用代码去重。文本字段超过简道云上限的要先截断尤其是历史跟进记录只保留最近五次沟通内容即可。不要试图把所有历史都搬过来AI 生成建议时反而不准因为噪音太多。迁移完成后先拿 50 条客户做试跑对比 AI 建议和人工判断的差异再决定是全量跑还是先跑重点客户。这一步能帮你提前发现提示词不合适或者字段映射错误的问题总比上线后销售集体反馈“这 AI 在瞎说”要好。5. 避坑记录鉴权失效、字段截断、限流与响应解析5.1 现象请求返回 401API Key 明明没问题有一次我们在生产环境切换了 DeepSeek API Key中间件日志一直报 401。检查发现.env文件里写的是新 Key但重启服务时用了旧的.env路径进程读取的还是环境变量里的旧值。原因是 FastAPI 服务没有打印配置来源排查靠猜。解决方式很简单启动时强制检查环境变量如果 Key 为空就拒绝启动并在日志里打印来源。从那以后我每次部署都会在启动脚本里执行一次健康检查确认能调用模型后再启动对外端口。另外 .env 文件千万别提交到 Git一旦泄露别人就可以拿你的 Key 刷额度账单直接翻车。5.2 现象回写简道云后字段被截断数据显示不完整AI 生成的建议超过字段长度限制回写时虽然接口返回成功但页面里只能看到前半截后半截丢了。原因很简单简道云多行文本字段也有长度上限AI 输出 800 token 转成中文字符后可能超过限制特别是当客户资料里包含长句子时。解决方法是两层。第一层在中间件把max_tokens限制到 300-500并在提示词里明确“summary 80 字以内”。第二层也是以防万一简道云的建议表里把 summary 字段设为多行文本把 next_action 设为单选或短文本。真正要防的不是 AI 写太长而是你的字段类型和输出长度不匹配。5.3 现象批处理时触发限流大量回写失败中间件连续调用 20 个客户的建议后DeepSeek 开始返回 429 限流错误。原因是我们没有在中间件里做任何速率限制触发了 API 的每分钟请求上限。这种现象在 CRM 场景很常见尤其是一大早跑定时任务时所有客户一次性冲过来。解决方式是加一个简单的令牌桶或者更朴素的时间窗控制在 for 循环里每调一次就等待 1 秒。我一般用如下模式import time for customer in customers: resp call_suggest(customer) write_to_jianyun(resp) time.sleep(1)这个土办法足够解决 90% 的限流问题。如果你跑几百个客户再把 sleep 改成按模型返回的 retry-after 时间来动态等待。另一个点是简道云那边的数据助手也会重复触发建议在中间件做去重记录最近处理过的客户 UID防止同一客户在短时间窗口内被处理两次。5.4 现象AI 输出的 JSON 突然带上了 Markdown 代码块解析失败DeepSeek 某些情况下会返回类似json ...的包裹内容直接json.loads就会报错。症状是偶发出现非常玄学因为大部分请求正常某一条突然就不规范了。原因是模型在较长上下文里漂移temperature 即使调到 0.3 也无法完全避免。解决方式很稳定在解析 JSON 前做预处理去掉可能的 Markdown 代码围栏。核心代码就几行text content.strip() if text.startswith(): text text.strip().removeprefix(json) data json.loads(text)这个方法我放在所有 AI 集成脚本里不管用哪家大模型都适用。不要依赖模型永远守规矩要在解析侧做兼容。5.5 现象简道云回写失败提示字段权限不足中间件调用简道云开放 API 时返回权限错误但同一个 API Key 读取数据正常。原因是简道云的 API Key 关联的是指定的应用或角色可能只授予了读权限没有写权限或者字段级权限没有打开。这个问题的隐蔽性在于读接口都通只有写接口拒绝容易让人误以为是网络或参数问题。解决方式是回到简道云管理后台检查集成管理的 API Key 权限范围把目标应用的写权限和对应字段权限打开。我当时在这上面折腾了半小时后来直接建了专用 API Key权限只开需要的那几张表最小化授权反而更安全。5.6 现象AI 建议内容陈旧客户状态已经变化但建议没更新系统运行两周后销售反馈有些建议明显过时客户已经下单了AI 还在建议“提醒客户报价”。原因是定时任务只处理“超过三天没有建议”的客户而新下单的客户没有触发新的建议生成导致旧建议一直挂着。解决方式是在简道云里增加一个更新触发点当跟进记录表新增记录或客户主表的订单字段发生变化时立即把该客户加入待处理队列并重置建议状态。不要依赖定时任务覆盖所有场景要结合事件触发。从那以后我每次设计自动化流程都会先画一张“哪些事件会改变建议有效性”的清单而不是只写一个 cron 表达式。6. 进阶技巧把客户跟进历史变成上下文让辅助系统越用越懂客户6.1 上下文记忆表不重写全量历史想让 AI 建议更准不能在每次请求里把客户所有历史记录都塞进去那样 token 成本会指数上升。我建议单独建一张“客户上下文表”用简道云的 API 在每次沟通后生成一段 200 字以内的摘要存到上下文表。每次调 DeepSeek 时只带最近一次的摘要而不是三年里所有跟进记录。比如第一次沟通后AI 生成“张总关注交期对价格敏感”。第二次沟通后再把这句话和历史摘要拼在一起重新生成一段。这样上下文是不断折叠的长度可控而且对模型的压力小。这个设计借鉴了长期记忆的常见做法在 CRM 里非常好用成本几乎不涨。6.2 建议确认后回流形成闭环销售在简道云里把 AI 建议确认后不要只改状态还要把确认内容写回“客户上下文表”。这样模型下一次生成建议时就能基于上一次实际采取的行动而不是它自己想象中的行动继续推理。这个闭环价值很大否则每次调用模型都像是在和一个没有记忆的人对话。我现在做所有 AI 集成项目都会强制走这一遍AI 出建议 → 人工确认 → 结果回流 → 下次带上下文再调。从那以后这套系统的输出质量明显提升销售也愿意每天打开建议表了。希望这个思路能帮你在自己的低代码平台里少走几段弯路。本文还有配套的精品资源点击获取 DeepSeek API接入简道云CRM：低代码构建智能销售辅助系统
简介面向低代码开发者和CRM系统管理员的深度实践文档围绕DeepSeek API与简道云平台系统讲解CRM智能辅助系统的搭建思路。文档从低代码概念与CRM现状切入逐步解析DeepSeek API的技术原理、调用流程以及简道云的表单、流程、数据管理等功能模块随后展开客户信息管理、销售机会预测、智能客服、智能营销等核心功能的开发细节并覆盖集成测试、性能优化、部署维护与案例复盘。包内为1个PDF文件共30页压缩包约2.03MB目录结构完整、图文显示正常全文章节清晰、由浅入深目前已有97人学习下载。读者既可了解低代码平台与AI服务结合的架构设计也可参照具体实现步骤落地自己的智能CRM项目适合需要快速搭建业务系统、引入AI能力并降低开发成本的团队与个人开发者参考。1. 低代码整合方案DeepSeek API 加简道云把 CRM 变成会建议的助手简道云里的客户表越堆越长但没人每天盯着字段更新销售跟进前翻客户历史要花十分钟。这套方案把 DeepSeek API 塞进简道云 CRM用低代码方式做一个智能辅助层自动把客户背景补全、按上次沟通生成跟进话术、识别风险客户并提醒。它适合手里已经跑着简道云、又不想为 AI 重写一套系统的中小企业也适合做低代码交付的乙方。这份资源给了完整的架构、请求样例、字段映射和避坑记录照着搭两三天就能跑起来不是概念稿。2. 为什么是这套组合CRM 数据底座与 AI 推理层的职责边界2.1 简道云管事实DeepSeek 管判断先想清楚一个问题CRM 系统里最重要的是什么是可追溯的事实——客户什么时候建的、谁负责的、报价多少、上次沟通结论是什么。这些数据必须稳定、有权限、能审计。简道云这类低代码平台最适合干这件事它有表单、流程、权限和可视化销售填表不用学 SQL做二次开发也不需要引入重型框架。而 DeepSeek API 擅长的是基于事实做判断。给它一堆客户资料它能总结客户画像、生成跟进话术、判断意向等级。但它不能替代 CRM因为模型会幻觉会把不存在的报价说得像真的一样。所以边界必须清晰简道云存事实DeepSeek 出建议建议经过人确认后回填成新事实。这样即使 AI 错了也不会污染原始数据。这个边界定了之后后面所有设计都好做AI 返回的内容一律进“AI 建议表”等销售点了确认再写入正式字段。我见过不少人一开始图省事把 AI 建议直接回写到客户主表结果 AI 一句话把客户行业改错了销售都没发现。数据一旦被污染这套系统就失去意义后面所有统计都会跟着错。2.2 两种对接路线简道云内直连与中间件桥接低代码平台调用外部 API常见有两条路。第一条是在简道云内部用插件或智能助手直接发 HTTP 请求优点是链路短但缺点也很明显简道云的自带动作对请求体限制多超时、鉴权、响应解析都不可控排查问题非常痛苦。第二条是中间件桥接用一个轻量服务比如云函数或 FastAPI封装 DeepSeek API简道云负责存储和展示中间件只做数据转换与模型调用。我一般选第二条因为 AI 调用涉及密钥、重试、速率限制这些逻辑放中间件里最好维护。你可以理解成三段简道云表单采集数据 → 中间件从简道云拉数据、调 DeepSeek、把结果写回去 → 销售在简道云看到建议并确认。这样简道云仍然是业务系统的唯一入口AI 只是外挂的一个大脑。下面这张表是两条路线的对比选型直接拍板就行。对比项简道云内直连中间件桥接链路长度短多一跳但可接受调试难度高日志少低可本地断点密钥管理暴露在平台内收在服务端超时/重试难控制完全可控并发与限流难以精细控制可做队列和退避适合规模实验、几十条/天生产环境如果你的试用场景只是每天查十几个客户直连也能跑但要做到按客户批量生成话术、定时补全资料就必须上中间件。后面的章节按中间件路线写这也是这份方案的主结构。2.3 数据流从表单提交到 AI 建议回填的四步流转具体的数据流可以拆成四步每一步职责单一方便日后排查。第一步简道云里的客户主表有新增或修改时通过定时任务或手动触发把增量数据推给中间件。第二步中间件把客户字段拼成一段上下文提示词调用 DeepSeek API得到结构化的 JSON。第三步中间件把 JSON 回写到简道云的“AI 建议表”状态设置为“待确认”。第四步销售在建议表里看到内容点击确认后由数据助手把建议中的关键字段写入客户主表。这四步中第二步最容易翻车。提示词拼得好不好直接决定输出质量后面我会专门讲提示词模板。第三步也容易踩坑简道云开放 API 写入时字段标识要用表单的 UID不是显示名称。很多人拿着中文名去写返回 400 查半天。我们当时也在这个问题上卡了一个下午最后才发现文档里写的是控件的别名。另外数据流还要考虑频率。CRM 数据不是高频交易数据单客户每天生成一两次建议就够。所以中间件没必要常驻高并发按现在的免费或低配云函数足够。如果一天只有几百次调用用定时任务触发就好不需要上消息队列。单位成本很低重点是把流程跑通、让销售真正用起来。2.4 成本与配额先按千次调用算账再决定要不要全量跑AI 接入最容易被忽视的就是成本。很多团队做完 POC 一算发现把存量客户全量跑一遍比想象中贵。建议在动手前先做一个估算表平均每次请求消耗多少 token覆盖多少客户每天跑几轮乘以单价就知道一个月大概花多少。DeepSeek 的价格是公开的但不同时间可能有调整所以我一般让团队按“每千 token 单价 × 平均请求 token 数×请求次数”自己算而不是直接抄网上的结论。我见过一个比较典型的翻车案例方案里写“全量客户每天自动生成建议”但没考虑到每个客户的资料长短不一最终平均请求 token 数比预期翻了四倍。原因是提示词里把三年历史跟进记录全塞进去了。解决办法是在上游先把客户资料浓缩成最近几条关键记录再喂给模型。成本控制不是省出来的是设计出来的上下文折叠能做到又省又准。3. DeepSeek API 接入鉴权、请求体与 HTTP 服务封装3.1 准备凭据与最小调用骨架先去 DeepSeek 开放平台创建 API Key然后把 Key 放进环境变量不要写死在代码里。常见做法是用.env文件管理并在gitignore里排除。DeepSeek API 兼容 OpenAI 格式base_url固定为https://api.deepseek.com模型名用deepseek-chat或deepseek-reasoner。这里要分清会话摘要、话术生成这类任务用deepseek-chat就够deepseek-reasoner适合需要深层推理的场景但更慢也更贵在 CRM 辅助场景里多数不是刚需。下面是一个最小可用的 Python 调用示例使用openai库import os from openai import OpenAI client OpenAI( api_keyos.getenv(DEEPSEEK_API_KEY), base_urlhttps://api.deepseek.com ) resp client.chat.completions.create( modeldeepseek-chat, messages[ { role: system, content: 你是CRM辅助助手。只根据客户资料生成跟进建议不要编造客户没说过的话。 }, { role: user, content: 客户张总行业制造业最近沟通询价后未确认历史订单无。 } ], temperature0.3, max_tokens500 ) print(resp.choices[0].message.content)这里有两个参数值得说。temperature我习惯调到 0.3因为 CRM 场景要的是稳定可复现的输出温度越高越容易发散把风险等级写成互相矛盾的词。max_tokens限制在 500 以内一是控制成本二是避免返回内容太长回写简道云时被字段长度截断。500 个 token 足够生成一小段跟进话术和摘要了。3.2 把调用封装成 FastAPI 服务简道云那边的自动化动作不能让每一个表单都直接去请求第三方 API最好通过一个内部服务中转。我一般用 FastAPI 写一个很薄的接口入参是客户资料出参是固定结构的建议 JSON。为什么要固定结构因为要回填到简道云的独立字段结构不固定解析就会断。from fastapi import FastAPI, Request from openai import OpenAI import os, json app FastAPI() client OpenAI(api_keyos.getenv(DEEPSEEK_API_KEY), base_urlhttps://api.deepseek.com) app.post(/suggest) async def suggest(request: Request): payload await request.json() customer payload.get(customer, {}) text ( f客户{customer.get(name)} f行业{customer.get(industry)} f最近沟通{customer.get(last_note)} f历史订单{customer.get(order_count) or 无} ) resp client.chat.completions.create( modeldeepseek-chat, messages[ {role: system, content: 输出JSON包含summary、next_action、risk_level三个字段risk_level只能是高/中/低。}, {role: user, content: text} ], temperature0.3, max_tokens500, response_format{type: json_object} ) content json.loads(resp.choices[0].message.content) return { summary: content.get(summary, ), next_action: content.get(next_action, ), risk_level: content.get(risk_level, 低) }需要注意DeepSeek API 的response_format设置成json_object才会稳定返回 JSON否则经常会在前后加解释性文字。FastAPI 里加一个超时控制调用模型时设置timeout30超过 30 秒就返回兜底文案防止简道云那边一直挂起。很多人第一次写这个接口时只处理成功路径一旦 DeepSeek 超时或返回内容不是合法 JSON整个程序直接抛异常结果就是简道云里的自动化任务每到下午就失败一批。3.3 简道云侧的回写字段设计接口跑通后要在简道云里建一张“AI 建议表”专门接收中间件回写的数据。字段不要随意命名建议按下面的清单建API 标识保持一致。中文名API 标识类型说明关联客户rel_customer关联表单关联客户主表记录客户摘要summary多行文本AI 生成的客户画像摘要建议动作next_action多行文本下一步跟进建议风险等级risk_level单选高/中/低状态status单选待确认/已确认/已忽略AI 用 token 数usage_tokens数字成本核实用回写时通过简道云开放平台的 API 调用注意表单的 API 标识和显示名称的区别。比如在简道云里新建字段时显示名叫“风险等级”但 API 标识可能是risk_level回写时要用risk_level而不是中文。这张表建好后中间件拿到接口返回的 JSON直接映射到对应字段即可。这样销售打开建议表看到的是一行一行结构化结果不是一大段原始 AI 文本。3.4 部署方式云函数与常驻主机怎么选中间件可以部署在云函数上也可以放在一台常驻的轻量服务器上。云函数的好处是缩容快平时不调用不计费坏处是冷启动会带来 2~5 秒延迟而且像 FastAPI 这类框架需要打包成特定入口格式部署时多一道工序。常驻主机的好处是稳定日志查看方便适合后期要挂定时任务的场景。我的建议是如果只是试跑用云函数如果要在上面跑每日定时批处理用一台最便宜的云主机更省心因为定时任务需要长驻进程。部署完成后可以用curl做一个快速验证确认接口能正常返回curl -X POST http://127.0.0.1:8000/suggest \ -H Content-Type: application/json \ -d {customer:{name:测试客户,industry:医疗,last_note:上周询价,order_count:1}}看到返回{summary:...,next_action:...,risk_level:低}就说明链路通了。接下来才轮到简道云侧的数据助手去对接这个地址。很多人喜欢先改简道云再去调试接口最后两边一起报错很难判断谁有问题。标准流程应该是先把中间件的输入输出固定死再连简道云。4. CRM 智能辅助落地客户画像补全、话术生成与风险提醒4.1 数据模型主表、行为表、建议表怎么协同这套系统的核心不是算法而是数据模型。我建议至少拆三张表客户主表存基本信息跟进记录表存每次沟通的原始过程AI 建议表存模型输出和人工确认结果。为什么要单独建“AI 建议表”而不是把 AI 生成的内容直接塞进客户主表因为客户主表是业务事实AI 输出是推断结果两者混在一起后期做筛选和复盘会非常混乱。客户主表字段不必多有客户名称、行业、规模、负责人、最近跟进时间就够了。跟进记录表负责记录每一次与客户的沟通过程销售在简道云里新增一条跟进记录时把内容填进一个多行文本字段中间件就能自动把最新记录提取出来。AI 建议表则负责承载模型的输出以及销售最终确认的内容。三张表形成一条清晰的链路客户主表是身份跟进记录表是原料AI 建议表是产物。实际落地时我会在简道云里给这三张表都建好视图。销售每天打开仪表盘只看到 AI 建议表里状态为“待确认”的记录。确认后建议中的关键信息通过数据助手写入客户主表状态变为“已确认”。这样既保留 AI 判断的痕迹又保证主表干净。4.2 自动化流程新客户触发、定时补全、批量生成数据模型建好后要接自动化。第一步是新客户触发当客户主表新增记录时简道云的数据助手可以把新增客户的信息推给中间件中间件调 DeepSeek 生成初始画像和跟进建议。第二步是定时补全对超过三天没有 AI 建议的客户用定时任务批量跑一遍中间件逐条调用模型并回写让销售每天早上一打开系统就有最新建议。第三步是风险提醒在 AI 建议表里加一个“风险等级”维度当模型识别到客户超过两周未响应、或者近期订单下降时通过简道云的流程通知推给负责人。这个环节不需要太复杂的逻辑只要中间件返回的风险等级为“高”就自动发一个待办。我做这个方案时第一条风险预警出来销售负责人还挺惊讶因为确实有一个客户连续三周没回复表面上看和正常客户没差别。自动化的频率要控制好。DeepSeek API 不是无限免费的即便付费也有速率限制所以我建议在中间件里加一个简单的频率控制比如每个客户每天最多生成两次建议。简道云的数据助手会触发很多次不加控制可能一天就把一个月配额打光。这个点放在避坑部分详细讲。4.3 提示词模板与参数选择决定输出质量的关键低代码平台里调试提示词不方便最好在本地先把模板跑通再搬到中间件里。CRM 场景的提示词不需要写得多花哨关键是约束模型不要编造事实。我常用的模板结构是先给角色定义再给客户资料最后给输出格式。你是 CRM 辅助助手。你只能基于提供的客户资料输出内容禁止补充资料里没有的信息。 客户资料 - 名称{{name}} - 行业{{industry}} - 最近跟进{{last_note}} - 历史订单数{{order_count}} 请输出 JSON包含 - summary80 字以内的客户摘要 - next_action一条具体的下一步动作 - risk_level高/中/低并给出理由这个模板里最有价值的是最后一行“并给出理由”。如果只让模型输出高中低它经常拍脑袋让它说理由至少能把这些词和客户资料对应上。参数上temperature用 0.3top_p我一般不动保持默认。max_tokens根据输出长度设置摘要加话术 500 token 足够。如果发现输出内容经常被截断先不要急着加 token先去调整提示词让模型更精简。4.4 从现有 CRM 迁移存量数据字段映射与清洗规则如果你已经在用其他 CRM 工具迁移到这套方案时有一个容易被忽略的步骤字段映射。不同 CRM 对客户名称、行业、跟进记录的叫法不同直接导入简道云会丢字段。我建议先做一张映射表把旧系统的字段翻译成新系统的 API 标识再写脚本清洗。清洗的核心规则是去重和截断。旧系统里同一个客户可能有多个重复记录需要按客户名称或统一社会信用代码去重。文本字段超过简道云上限的要先截断尤其是历史跟进记录只保留最近五次沟通内容即可。不要试图把所有历史都搬过来AI 生成建议时反而不准因为噪音太多。迁移完成后先拿 50 条客户做试跑对比 AI 建议和人工判断的差异再决定是全量跑还是先跑重点客户。这一步能帮你提前发现提示词不合适或者字段映射错误的问题总比上线后销售集体反馈“这 AI 在瞎说”要好。5. 避坑记录鉴权失效、字段截断、限流与响应解析5.1 现象请求返回 401API Key 明明没问题有一次我们在生产环境切换了 DeepSeek API Key中间件日志一直报 401。检查发现.env文件里写的是新 Key但重启服务时用了旧的.env路径进程读取的还是环境变量里的旧值。原因是 FastAPI 服务没有打印配置来源排查靠猜。解决方式很简单启动时强制检查环境变量如果 Key 为空就拒绝启动并在日志里打印来源。从那以后我每次部署都会在启动脚本里执行一次健康检查确认能调用模型后再启动对外端口。另外 .env 文件千万别提交到 Git一旦泄露别人就可以拿你的 Key 刷额度账单直接翻车。5.2 现象回写简道云后字段被截断数据显示不完整AI 生成的建议超过字段长度限制回写时虽然接口返回成功但页面里只能看到前半截后半截丢了。原因很简单简道云多行文本字段也有长度上限AI 输出 800 token 转成中文字符后可能超过限制特别是当客户资料里包含长句子时。解决方法是两层。第一层在中间件把max_tokens限制到 300-500并在提示词里明确“summary 80 字以内”。第二层也是以防万一简道云的建议表里把 summary 字段设为多行文本把 next_action 设为单选或短文本。真正要防的不是 AI 写太长而是你的字段类型和输出长度不匹配。5.3 现象批处理时触发限流大量回写失败中间件连续调用 20 个客户的建议后DeepSeek 开始返回 429 限流错误。原因是我们没有在中间件里做任何速率限制触发了 API 的每分钟请求上限。这种现象在 CRM 场景很常见尤其是一大早跑定时任务时所有客户一次性冲过来。解决方式是加一个简单的令牌桶或者更朴素的时间窗控制在 for 循环里每调一次就等待 1 秒。我一般用如下模式import time for customer in customers: resp call_suggest(customer) write_to_jianyun(resp) time.sleep(1)这个土办法足够解决 90% 的限流问题。如果你跑几百个客户再把 sleep 改成按模型返回的 retry-after 时间来动态等待。另一个点是简道云那边的数据助手也会重复触发建议在中间件做去重记录最近处理过的客户 UID防止同一客户在短时间窗口内被处理两次。5.4 现象AI 输出的 JSON 突然带上了 Markdown 代码块解析失败DeepSeek 某些情况下会返回类似json ...的包裹内容直接json.loads就会报错。症状是偶发出现非常玄学因为大部分请求正常某一条突然就不规范了。原因是模型在较长上下文里漂移temperature 即使调到 0.3 也无法完全避免。解决方式很稳定在解析 JSON 前做预处理去掉可能的 Markdown 代码围栏。核心代码就几行text content.strip() if text.startswith(): text text.strip().removeprefix(json) data json.loads(text)这个方法我放在所有 AI 集成脚本里不管用哪家大模型都适用。不要依赖模型永远守规矩要在解析侧做兼容。5.5 现象简道云回写失败提示字段权限不足中间件调用简道云开放 API 时返回权限错误但同一个 API Key 读取数据正常。原因是简道云的 API Key 关联的是指定的应用或角色可能只授予了读权限没有写权限或者字段级权限没有打开。这个问题的隐蔽性在于读接口都通只有写接口拒绝容易让人误以为是网络或参数问题。解决方式是回到简道云管理后台检查集成管理的 API Key 权限范围把目标应用的写权限和对应字段权限打开。我当时在这上面折腾了半小时后来直接建了专用 API Key权限只开需要的那几张表最小化授权反而更安全。5.6 现象AI 建议内容陈旧客户状态已经变化但建议没更新系统运行两周后销售反馈有些建议明显过时客户已经下单了AI 还在建议“提醒客户报价”。原因是定时任务只处理“超过三天没有建议”的客户而新下单的客户没有触发新的建议生成导致旧建议一直挂着。解决方式是在简道云里增加一个更新触发点当跟进记录表新增记录或客户主表的订单字段发生变化时立即把该客户加入待处理队列并重置建议状态。不要依赖定时任务覆盖所有场景要结合事件触发。从那以后我每次设计自动化流程都会先画一张“哪些事件会改变建议有效性”的清单而不是只写一个 cron 表达式。6. 进阶技巧把客户跟进历史变成上下文让辅助系统越用越懂客户6.1 上下文记忆表不重写全量历史想让 AI 建议更准不能在每次请求里把客户所有历史记录都塞进去那样 token 成本会指数上升。我建议单独建一张“客户上下文表”用简道云的 API 在每次沟通后生成一段 200 字以内的摘要存到上下文表。每次调 DeepSeek 时只带最近一次的摘要而不是三年里所有跟进记录。比如第一次沟通后AI 生成“张总关注交期对价格敏感”。第二次沟通后再把这句话和历史摘要拼在一起重新生成一段。这样上下文是不断折叠的长度可控而且对模型的压力小。这个设计借鉴了长期记忆的常见做法在 CRM 里非常好用成本几乎不涨。6.2 建议确认后回流形成闭环销售在简道云里把 AI 建议确认后不要只改状态还要把确认内容写回“客户上下文表”。这样模型下一次生成建议时就能基于上一次实际采取的行动而不是它自己想象中的行动继续推理。这个闭环价值很大否则每次调用模型都像是在和一个没有记忆的人对话。我现在做所有 AI 集成项目都会强制走这一遍AI 出建议 → 人工确认 → 结果回流 → 下次带上下文再调。从那以后这套系统的输出质量明显提升销售也愿意每天打开建议表了。希望这个思路能帮你在自己的低代码平台里少走几段弯路。本文还有配套的精品资源点击获取