从客服到代码审查:5 个 DeepSeek 落地案例和完整源码
DeepSeek 实战案例分享|附源码
近年来,大模型在企业办公、内容生产、知识库问答、代码辅助、数据分析等场景中快速落地。相比早期“只能聊天”的使用方式,如今的大模型更像一个可编程的智能能力中台:我们可以通过 API 将其接入现有业务系统,让它承担摘要生成、智能问答、自动分类、结构化抽取、代码生成等任务。
DeepSeek 作为国产大模型中的代表之一,因其较强的推理能力、较高的性价比以及良好的 API 兼容性,受到了不少开发者和企业团队的关注。本文将通过几个真实开发中常见的实战案例,演示如何使用 DeepSeek API 完成智能客服、文档摘要、结构化信息抽取和代码助手等功能,并附上可运行的源码示例,方便你快速改造到自己的项目中。
一、准备工作
在开始之前,我们需要完成以下准备:
- 注册并获取 DeepSeek API Key;
- 准备 Python 开发环境;
- 安装必要依赖;
- 熟悉基础调用方式。
本文示例主要使用 Python 编写,适合后端服务、脚本工具、数据处理任务等场景。
二、安装依赖
建议使用 Python 3.9 及以上版本。
pip install openai python-dotenv flask requests
DeepSeek API 在调用方式上兼容 OpenAI SDK,因此我们可以直接使用 openai 包完成调用。
为了避免将 API Key 写死在代码中,推荐使用 .env 文件管理环境变量。
项目目录结构如下:
deepseek-demo/
├── .env
├── deepseek_client.py
├── case_01_chatbot.py
├── case_02_summary.py
├── case_03_extract.py
├── case_04_code_review.py
└── app.py
在项目根目录创建 .env 文件:
DEEPSEEK_API_KEY=你的DeepSeek_API_Key
DEEPSEEK_BASE_URL=https://api.deepseek.com
注意:请不要将
.env文件提交到 Git 仓库,避免密钥泄露。
三、封装 DeepSeek 调用客户端
在正式写业务代码之前,我们先封装一个通用客户端,方便后续复用。
deepseek_client.py
import os
from dotenv import load_dotenv
from openai import OpenAI
load_dotenv()
class DeepSeekClient:
def __init__(self):
self.api_key = os.getenv("DEEPSEEK_API_KEY")
self.base_url = os.getenv("DEEPSEEK_BASE_URL", "https://api.deepseek.com")
if not self.api_key:
raise ValueError("请先在 .env 文件中配置 DEEPSEEK_API_KEY")
self.client = OpenAI(
api_key=self.api_key,
base_url=self.base_url
)
def chat(
self,
messages,
model="deepseek-chat",
temperature=0.7,
max_tokens=2048
):
"""
通用对话接口
"""
response = self.client.chat.completions.create(
model=model,
messages=messages,
temperature=temperature,
max_tokens=max_tokens
)
return response.choices[0].message.content
if __name__ == "__main__":
ds = DeepSeekClient()
result = ds.chat([
{"role": "system", "content": "你是一个专业的技术助手。"},
{"role": "user", "content": "请用一句话介绍 DeepSeek。"}
])
print(result)
运行测试:
python deepseek_client.py
如果能够正常输出结果,说明基础环境已经配置完成。
四、案例一:智能客服机器人
智能客服是大模型最常见的落地场景之一。传统客服机器人依赖大量规则和 FAQ 配置,维护成本高,且对用户自然语言的理解能力有限。而基于 DeepSeek 的客服机器人可以理解用户问题,并根据预设知识进行回答。
业务需求
假设我们经营一个电商平台,需要客服机器人回答以下问题:
- 订单多久发货;
- 如何申请退款;
- 是否支持七天无理由退货;
- 物流异常怎么办;
- 会员积分如何使用。
为了避免模型胡乱编造,我们可以在系统提示词中加入明确的业务规则。
源码:case_01_chatbot.py
from deepseek_client import DeepSeekClient
SYSTEM_PROMPT = """
你是某电商平台的智能客服助手,请严格根据以下规则回答用户问题:
1. 普通商品下单后 48 小时内发货;
2. 生鲜商品下单后 24 小时内发货;
3. 用户收到商品后 7 天内,未拆封且不影响二次销售,可申请七天无理由退货;
4. 生鲜、定制类、虚拟商品不支持七天无理由退货;
5. 退款申请审核通过后,1-3 个工作日原路退回;
6. 如果物流超过 72 小时未更新,请引导用户提供订单号,由人工客服处理;
7. 会员积分可在下单页抵扣现金,100 积分抵扣 1 元;
8. 如果用户问题超出以上范围,请说明暂时无法确认,并建议联系人工客服。
回答要求:
- 语气礼貌、简洁;
- 不要编造规则中没有的信息;
- 如果需要订单号,请提醒用户不要提供银行卡、密码等敏感信息。
"""
def ask_customer_service(question):
ds = DeepSeekClient()
messages = [
{"role": "system", "content": SYSTEM_PROMPT},
{"role": "user", "content": question}
]
return ds.chat(messages, temperature=0.3)
if __name__ == "__main__":
questions = [
"我昨天买的普通商品什么时候发货?",
"生鲜商品可以七天无理由退货吗?",
"我的物流三天没动了怎么办?",
"积分怎么用?"
]
for q in questions:
print("用户:", q)
print("客服:", ask_customer_service(q))
print("-" * 50)
实战分析
这个案例的核心不在于“调用模型”,而在于“限制模型回答范围”。在企业应用中,大模型最常见的问题是幻觉,即编造不存在的规则或信息。因此我们需要通过系统提示词明确告诉模型:
- 只能基于给定规则回答;
- 超出范围要转人工;
- 不允许编造;
- 涉及隐私和敏感信息时要提醒用户。
如果后续业务规则越来越多,建议不要全部写在 Prompt 中,而是接入知识库检索,也就是常见的 RAG 架构。
五、案例二:长文档自动摘要
很多企业内部有大量会议纪要、调研报告、合同文本、产品需求文档。人工阅读成本很高,而大模型非常适合做摘要、提炼重点和生成行动项。
业务需求
输入一段较长文本,让 DeepSeek 输出:
- 一句话总结;
- 核心要点;
- 待办事项;
- 风险提醒。
源码:case_02_summary.py
from deepseek_client import DeepSeekClient
def summarize_document(text):
ds = DeepSeekClient()
prompt = f"""
请阅读以下文档,并按照指定格式输出摘要。
文档内容:
{text}
请严格按照以下 Markdown 格式输出:
## 一句话总结
用一句话概括文档核心内容。
## 核心要点
- 要点1
- 要点2
- 要点3
## 待办事项
- [ ] 事项1:负责人/时间,如果文档未提及则写“未明确”
- [ ] 事项2:负责人/时间,如果文档未提及则写“未明确”
## 风险提醒
- 风险1
- 风险2
要求:
1. 不要添加文档中没有的信息;
2. 表达简洁清晰;
3. 如果某部分没有相关内容,请写“未提及”。
"""
messages = [
{"role": "system", "content": "你是一个专业的企业文档分析助手,擅长提炼重点和总结行动项。"},
{"role": "user", "content": prompt}
]
return ds.chat(messages, temperature=0.2, max_tokens=2048)
if __name__ == "__main__":
sample_text = """
本次产品会议主要讨论了会员中心 2.0 版本的规划。当前会员中心存在页面信息分散、
用户权益展示不清晰、积分使用路径较深等问题。产品团队计划在下个版本中重构会员首页,
将会员等级、可用积分、优惠券、专属权益统一展示。
研发侧表示,当前积分系统接口较老,需要先进行接口梳理和部分重构,预计需要两周时间。
设计团队将在本周五前输出新版会员首页原型。运营团队建议增加会员成长任务,例如每日签到、
完善资料、购买指定商品获取成长值。
风险方面,研发负责人提到积分系统历史逻辑复杂,如果直接改造可能影响下单抵扣功能。
会议决定先由研发团队完成技术方案评估,再确定是否与会员中心 2.0 同期上线。
"""
print(summarize_document(sample_text))
实战分析
文档摘要类任务推荐将输出格式固定下来。这样做有几个好处:
- 前端展示更容易;
- 后续数据入库更方便;
- 结果稳定性更高;
- 便于批量处理大量文档。
如果文档很长,超过模型上下文限制,可以采用“分段摘要 + 汇总摘要”的方式:
- 将文档切分成多个片段;
- 对每个片段生成局部摘要;
- 将所有局部摘要再输入模型生成总摘要。
六、案例三:结构化信息抽取
很多业务系统需要从非结构化文本中抽取结构化字段。例如从简历中抽取姓名、学历、技能;从合同中抽取甲方、乙方、金额、期限;从客服工单中抽取问题类型、优先级、情绪倾向。
业务需求
输入一段用户反馈,自动抽取:
- 用户意图;
- 问题类型;
- 情绪倾向;
- 是否需要人工介入;
- 建议处理优先级。
输出必须是 JSON,方便程序直接解析。
源码:case_03_extract.py
import json
from deepseek_client import DeepSeekClient
def extract_ticket_info(feedback):
ds = DeepSeekClient()
prompt = f"""
请从以下用户反馈中抽取结构化信息,并只返回 JSON,不要输出任何解释。
用户反馈:
{feedback}
JSON 字段要求:
{{
"intent": "用户主要意图",
"category": "问题类型,可选值:物流问题、退款问题、商品质量、账号问题、投诉建议、其他",
"sentiment": "情绪倾向,可选值:正向、中性、负向",
"need_human": true 或 false,
"priority": "优先级,可选值:低、中、高",
"reason": "判断理由,控制在50字以内"
}}
判断规则:
1. 如果用户表达强烈不满、投诉、威胁差评,need_human 为 true;
2. 涉及退款失败、物流长时间异常、商品破损,优先级至少为中;
3. 如果无法判断,category 填“其他”;
4. 必须返回合法 JSON。
"""
messages = [
{"role": "system", "content": "你是一个专业的客服工单分类系统,只输出合法 JSON。"},
{"role": "user", "content": prompt}
]
result = ds.chat(messages, temperature=0.1, max_tokens=1024)
try:
return json.loads(result)
except json.JSONDecodeError:
# 简单容错:如果模型输出被 Markdown 包裹,尝试清洗
cleaned = result.strip()
cleaned = cleaned.replace("```json", "").replace("```", "").strip()
return json.loads(cleaned)
if __name__ == "__main__":
feedback = "我买的杯子收到就是碎的,联系了两天没人处理,再不给我退款我就投诉你们!"
info = extract_ticket_info(feedback)
print(json.dumps(info, ensure_ascii=False, indent=2))
示例输出
{
"intent": "要求处理破损商品并退款",
"category": "商品质量",
"sentiment": "负向",
"need_human": true,
"priority": "高",
"reason": "商品破损且用户表示将投诉"
}
实战分析
结构化抽取是大模型在企业系统中非常有价值的场景。它可以作为传统规则系统的补充,尤其适合处理表达多样、不规则、难以穷举的文本。
不过在生产环境中要注意:
-
必须做 JSON 解析校验
不要默认模型输出一定合法,应加入异常处理。 -
字段值要限制枚举范围
比如问题类型只能从指定列表中选择,便于后续统计。 -
关键业务不要完全依赖模型判断
例如退款审批、风控拦截等场景,建议模型只提供辅助判断,最终由规则或人工确认。
七、案例四:代码 Review 助手
DeepSeek 在代码理解、问题定位和重构建议方面表现不错。我们可以用它实现一个简单的代码 Review 工具,对提交的代码进行自动检查。
业务需求
输入一段代码,让模型分析:
- 是否存在明显 Bug;
- 是否存在性能问题;
- 是否存在安全风险;
- 是否有可读性优化建议;
- 给出修改建议。
源码:case_04_code_review.py
from deepseek_client import DeepSeekClient
def review_code(code, language="Python"):
ds = DeepSeekClient()
prompt = f"""
请对以下 {language} 代码进行 Code Review。
代码如下:
```{language}
{code}
请按照以下格式输出:
总体评价
简要说明代码整体质量。
潜在 Bug
- 如果没有,请写“未发现明显问题”。
性能问题
- 如果没有,请写“未发现明显问题”。
安全风险
- 如果没有,请写“未发现明显问题”。
可读性与可维护性建议
- 建议1
- 建议2
修改示例
如果有必要,请给出优化后的关键代码片段。 """
messages = [
{"role": "system", "content": "你是一个资深软件工程师,擅长代码审查、安全分析和性能优化。"},
{"role": "user", "content": prompt}
]
return ds.chat(messages, temperature=0.2, max_tokens=2048)
if name == "main": bad_code = """ import sqlite3
def login(username, password): conn = sqlite3.connect("user.db") cursor = conn.cursor() sql = "select * from users where username='%s' and password='%s'" % (username, password) cursor.execute(sql) user = cursor.fetchone() conn.close() return user is not None """
print(review_code(bad_code, "Python"))
### 可能的 Review 结果
模型通常会指出:
- 存在 SQL 注入风险;
- 密码不应该明文比较;
- 数据库连接缺少异常处理;
- 建议使用参数化查询;
- 建议使用密码哈希。
优化示例:
```python
import sqlite3
import hashlib
def hash_password(password):
return hashlib.sha256(password.encode("utf-8")).hexdigest()
def login(username, password):
conn = sqlite3.connect("user.db")
try:
cursor = conn.cursor()
sql = "select * from users where username=? and password_hash=?"
cursor.execute(sql, (username, hash_password(password)))
user = cursor.fetchone()
return user is not None
finally:
conn.close()
实战分析
代码助手适合用于:
- 提交前自查;
- Pull Request 初步 Review;
- 安全漏洞扫描辅助;
- 老代码重构建议;
- 新人代码学习。
但需要注意,大模型给出的建议不一定全部正确,尤其涉及复杂业务逻辑时,仍需要开发人员进行判断。
八、案例五:使用 Flask 封装一个 DeepSeek Web API
前面的案例都是命令行脚本。实际项目中,我们更常见的方式是将 DeepSeek 能力封装成 HTTP 接口,供前端或其他服务调用。
下面我们实现一个简单的 Flask 服务,提供 /chat 接口。
源码:app.py
from flask import Flask, request, jsonify
from deepseek_client import DeepSeekClient
app = Flask(__name__)
ds = DeepSeekClient()
@app.route("/chat", methods=["POST"])
def chat():
data = request.get_json()
if not data:
return jsonify({"error": "请求体不能为空"}), 400
question = data.get("question")
if not question:
return jsonify({"error": "question 字段不能为空"}), 400
system_prompt = data.get(
"system_prompt",
"你是一个专业、友好、可靠的 AI 助手。"
)
try:
answer = ds.chat([
{"role": "system", "content": system_prompt},
{"role": "user", "content": question}
])
return jsonify({
"question": question,
"answer": answer
})
except Exception as e:
return jsonify({
"error": "调用 DeepSeek 失败",
"detail": str(e)
}), 500
if __name__ == "__main__":
app.run(host="0.0.0.0", port=5000, debug=True)
启动服务:
python app.py
使用 curl 测试:
curl -X POST http://localhost:5000/chat \
-H "Content-Type: application/json" \
-d '{
"question": "请帮我写一段会员中心改版的产品介绍",
"system_prompt": "你是一个资深互联网产品经理,擅长写产品文案。"
}'
返回示例:
{
"question": "请帮我写一段会员中心改版的产品介绍",
"answer": "全新的会员中心将会员等级、积分、优惠券与专属权益集中展示..."
}
九、生产环境最佳实践
如果只是写 Demo,能够调用模型就足够了。但如果要在真实业务中使用 DeepSeek,还需要考虑稳定性、安全性、成本和可维护性。
1. API Key 不要写死在代码中
错误示例:
api_key = "sk-xxxx"
正确做法:
api_key = os.getenv("DEEPSEEK_API_KEY")
并且要避免将 .env 文件提交到 Git 仓库。
2. 设置合理的超时和重试机制
网络请求可能失败,模型服务也可能出现短暂波动。建议加入重试机制,例如:
import time
def call_with_retry(func, retries=3, delay=1):
last_error = None
for i in range(retries):
try:
return func()
except Exception as e:
last_error = e
time.sleep(delay * (i + 1))
raise last_error
调用时:
result = call_with_retry(lambda: ds.chat(messages))
3. 控制 Prompt 长度
Prompt 越长,成本越高,响应越慢。实际开发中可以通过以下方式优化:
- 去掉无关上下文;
- 对长文档先分块;
- 只传必要字段;
- 对历史对话做摘要压缩;
- 使用缓存避免重复请求。
4. 明确输出格式
如果希望模型返回 JSON,就要在 Prompt 中明确要求:
只返回合法 JSON,不要输出 Markdown,不要输出解释说明。
同时后端仍然要做解析校验,不要完全相信模型输出。
5. 做好敏感信息过滤
用户输入中可能包含手机号、身份证、银行卡号、地址等敏感信息。如果业务不需要,建议在发送给模型前做脱敏处理。
示例:
import re
def mask_phone(text):
return re.sub(r"(1[3-9]\d)\d{4}(\d{4})", r"\1****\2", text)
content = "我的手机号是13812345678,请帮我查订单"
print(mask_phone(content))
输出:
我的手机号是138****5678,请帮我查订单
6. 人工兜底机制
在客服、金融、医疗、法律等高风险场景中,大模型不能作为最终决策者。合理的设计是:
- 模型负责理解和初步判断;
- 规则系统负责硬性校验;
- 人工负责复杂和高风险决策;
- 全流程保留日志,便于追溯。
十、一个完整的调用流程建议
在真实项目中,一个较完整的 DeepSeek 调用流程可以设计为:
用户输入
↓
敏感信息过滤
↓
意图识别
↓
检索业务知识库
↓
组装 Prompt
↓
调用 DeepSeek
↓
结果格式校验
↓
安全审核
↓
返回用户 / 转人工
↓
日志记录与效果评估
这种流程比直接“用户问什么就丢给模型”更加可靠,也更适合企业级应用。
十一、总结
本文通过多个实战案例介绍了如何将 DeepSeek 接入实际业务场景,包括:
- 智能客服机器人;
- 长文档自动摘要;
- 用户反馈结构化抽取;
- 代码 Review 助手;
- Flask API 服务封装。
从开发角度看,DeepSeek 的接入成本并不高,核心难点主要在于业务设计和工程化落地。一个可用的大模型应用,不只是简单调用一次 API,而是需要围绕 Prompt 设计、上下文管理、异常处理、结果校验、数据安全、成本控制和人工兜底进行系统设计。
如果你刚开始尝试 DeepSeek,建议先从低风险、高频、文本密集型任务入手,例如文档摘要、客服辅助、工单分类、代码解释等。等流程稳定后,再逐步接入更复杂的业务系统。
最后,大模型不是替代所有系统的“万能工具”,而是增强现有系统智能化能力的组件。真正优秀的 AI 应用,往往不是让模型单独完成所有事情,而是让模型与业务规则、知识库、数据库、人工流程协同工作。这样才能既发挥模型的理解和生成能力,又保证业务结果的稳定、可控和可追溯。