简介这份《DeepSeek指导手册从入门到精通》是一份面向AI助手新用户、技术人员及内容创作者的实操型PDF文档围绕DeepSeek平台从零基础到高阶应用展开覆盖账户创建、控制台功能、高效提问法则、文档分析、代码自动生成、论文辅助、自媒体运营与个性化知识库搭建等场景兼顾学习管理与自动化脚本需求。资源包共1个PDF文件大小约1.27MB内容按准备篇、基础对话篇、效率飞跃篇、场景实战篇等模块组织配有具体指令示例、避坑指南与操作提示便于按章节检索学习。目前已有2744人学习下载适合希望系统掌握AI辅助工作流、提升内容生产与学习效率的读者参考。1. 从“会聊天”到“能干活”DeepSeek指导手册到底在解决什么问题很多人第一次用 DeepSeek 是在网页对话框里问几个问题觉得“哦挺聪明”然后就关掉了。过几天再打开还是问同样类型的问题还是把它当搜索引擎用。这不是 DeepSeek 的问题是使用方式的问题。一份真正能落地的 DeepSeek 指导手册核心不是教你“怎么问问题”而是教你把它从一个对话玩具变成嵌入工作流的执行引擎。入门到精通的分界线不在于你背了多少提示词模板而在于你是否理解三件事模型的能力边界在哪、API 调用时参数怎么影响输出、本地或云端部署时资源怎么分配。这篇内容面向的是已经用过 DeepSeek 但觉得“没发挥出来”的开发者、运维和自动化需求方我会按“先跑通最小闭环、再调参数、最后避坑”的顺序把从调用到部署的完整路径拆开讲。如果你只想要一个“帮我写周报”的提示词那不用往下看如果你想让它接入 Codex、跑在 Jetson Orin 上、或者用 vLLM 做批量推理那接下来的内容就是给你准备的。2. 先跑通再谈精通DeepSeek API 调用的最小闭环2.1 从 API Key 到第一次成功返回不管后面是接 Codex、做本地部署还是搞智能体第一步永远是拿到一个能跑通的 API 调用。DeepSeek 的 API 兼容 OpenAI 的接口格式这意味着你不需要学一套全新的 SDK用 openai 的 Python 包改一下 base_url 就能用。常见做法是先把 key 放到环境变量里不要硬编码在脚本里这是血泪经验——一旦代码进了 gitkey 就等于公开了。import os from openai import OpenAI # 从环境变量读取不要写死在代码里 client OpenAI( api_keyos.environ.get(DEEPSEEK_API_KEY), base_urlhttps://api.deepseek.com/v1 # 注意结尾的 /v1 ) response client.chat.completions.create( modeldeepseek-chat, # 通用对话模型 messages[ {role: system, content: 你是一个只输出 JSON 的助手}, {role: user, content: 列出三个常见的 HTTP 状态码及其含义} ], temperature0.3, # 低温度适合结构化输出 max_tokens512 ) print(response.choices[0].message.content)这段代码的逻辑很直白构造一个 OpenAI 客户端把 base_url 指向 DeepSeek 的端点然后发一条标准的 chat completion 请求。参数上model目前常用的是deepseek-chat和deepseek-reasoner前者适合日常对话和结构化任务后者适合需要推理链的场景。temperature设成 0.3 是为了让输出更稳定如果你要它写创意文案可以调到 0.8 以上。max_tokens控制的是输出长度不是输入长度设太小会导致回答被截断设太大则浪费额度。第一次跑通之后你会看到返回的 JSON 里除了 content还有 usage 字段里面记录了 prompt_tokens 和 completion_tokens这是后面算成本的依据。2.2 参数怎么调temperature、top_p 和 max_tokens 的实际影响很多人调 API 时只改 prompt不动参数结果就是“有时候好有时候坏”然后归结为玄学。其实 temperature 和 top_p 是控制随机性的两个旋钮但不要同时调一般只动一个。temperature 越高输出越多样但越容易跑偏top_p 是核采样0.9 意味着只从累积概率前 90% 的词里选比 temperature 更平滑。我的习惯是结构化抽取任务用 temperature0.1top_p 不动创意生成用 temperature0.8top_p0.95。max_tokens 要根据任务设比如做分类任务输出就几个字设 64 就够了做长文摘要至少设 1024。还有一个容易忽略的参数是stream设为 True 时返回的是流式数据适合做打字机效果但如果你要解析完整 JSON流式反而麻烦建议先关掉。# 结构化抽取场景的参数组合 response client.chat.completions.create( modeldeepseek-chat, messages[ {role: system, content: 从用户文本中抽取姓名、电话、地址输出 JSON}, {role: user, content: 张三13800138000北京市海淀区中关村大街1号} ], temperature0.1, # 极低随机性保证每次输出格式一致 max_tokens256, response_format{type: json_object} # 强制 JSON 输出 )这里用到了response_format参数设为 json_object 后模型会尽量输出合法 JSON。但注意这个参数不是万能的如果 prompt 里没提 JSON模型可能还是输出普通文本。所以 system message 里一定要明确“输出 JSON”。另外DeepSeek 的 JSON 模式对字段名没有强制约束你需要在 prompt 里把字段名写清楚否则它可能用中文键名。参数调完之后建议用同一段输入跑 5 次看输出是否稳定如果 5 次里有 2 次格式不一样说明 temperature 还是太高或者 prompt 不够明确。3. 把 DeepSeek 接进你的工具链Codex、ccswitch 与本地部署3.1 接入 Codex 和 ccswitch 的配置要点Codex 和 ccswitch 是最近热搜里频繁出现的词前者是代码生成工具后者是配置切换工具。把 DeepSeek 接入 Codex 的常见做法是修改 Codex 的配置文件把默认的模型端点指向 DeepSeek 的 API。具体来说Codex 通常读取一个 config 文件里面有一个model_provider字段你需要在 provider 列表里加一个 DeepSeek 的条目填入 base_url 和 api_key。ccswitch 的作用是让你在多个 provider 之间快速切换比如白天用 DeepSeek晚上用另一个模型不用手动改配置文件。# 以 ccswitch 为例添加一个 DeepSeek 配置 ccswitch add deepseek \ --base-url https://api.deepseek.com/v1 \ --api-key $DEEPSEEK_API_KEY \ --model deepseek-chat # 切换到 DeepSeek ccswitch use deepseek # 查看当前生效的配置 ccswitch current这段命令的逻辑是先注册一个名为 deepseek 的配置然后激活它。参数上--base-url必须带/v1否则 Codex 可能拼出错误的路径--model指定默认模型如果你要用推理模型改成deepseek-reasoner。ccswitch 本身不存储 key 的明文它读的是环境变量所以$DEEPSEEK_API_KEY要提前 export。配置完成后在 Codex 里发一条代码补全请求看返回是否正常。如果报 401检查 key 是否过期如果报 404检查 base_url 是不是多写了或少写了/v1。3.2 本地部署 DeepSeek 的显存与量化选择本地部署是另一个高频需求尤其是 Jetson Orin 这类边缘设备。DeepSeek 的模型尺寸决定了显存门槛7B 级别的模型FP16 需要约 14GB 显存INT8 量化后约 7GBINT4 量化后约 4GB。Jetson Orin 常见版本是 8GB 或 16GB 显存所以 7B 模型用 INT4 量化是可以跑的但推理速度不会太快。如果要用 vLLM 部署它对显存的管理更高效支持 PagedAttention但 vLLM 对 Jetson 的支持需要额外编译不是 pip install 就能搞定。# 使用 vLLM 启动 DeepSeek 7B 的 INT4 量化版本 python -m vllm.entrypoints.openai.api_server \ --model deepseek-ai/deepseek-llm-7b-chat \ --quantization awq \ --dtype float16 \ --max-model-len 4096 \ --gpu-memory-utilization 0.9 \ --port 8000参数说明--quantization awq指定使用 AWQ 量化需要模型本身有 AWQ 权重--max-model-len控制上下文长度设太大显存会爆--gpu-memory-utilization 0.9表示用 90% 的显存留一点给系统。启动后你会看到一个兼容 OpenAI 的端点跑在 8000 端口然后用前面的 OpenAI 客户端把 base_url 改成http://localhost:8000/v1就能调用。注意本地部署的模型能力通常比云端 API 弱因为云端可能是更大的模型所以本地部署适合对延迟敏感、数据不能出内网的场景不适合追求最强效果的场景。4. 避坑与排查DeepSeek 使用中最容易翻车的五个地方4.1 现象API 返回 400提示 context length exceeded原因通常是你把整个文档塞进了 prompt超过了模型的最大上下文。DeepSeek 的上下文窗口是有限的虽然不同版本不一样但常见的是 64K 或 128K token。一个中文字大约 1.5 个 token所以 64K 大约能放 4 万字。解决方法是做分块把长文档切成 2000 字左右的片段分别抽取信息再合并。不要试图用“请总结以下内容”来绕过长度限制超了就是超了。4.2 现象输出 JSON 解析失败多出 markdown 代码块标记原因是你虽然设了response_format{type: json_object}但模型仍然可能在 JSON 外面包一层json。解决方法是解析前先做字符串清洗去掉开头的json 和结尾的。更稳妥的做法是在 system message 里加一句“不要用 markdown 代码块包裹 JSON”。如果还是不行就上正则提取第一个{到最后一个}之间的内容。4.3 现象本地部署时显存溢出进程被 kill原因通常是 max_model_len 设得太大或者 gpu_memory_utilization 设成了 1.0。解决方法是先把 max_model_len 降到 2048把 gpu_memory_utilization 降到 0.8跑通后再逐步往上加。另外Jetson 设备上要注意共享显存的问题系统和模型抢内存是常态建议在启动脚本里加--swap-space 4来用一点磁盘交换但速度会慢。4.4 现象接入 Codex 后补全速度极慢原因可能是你用了推理模型deepseek-reasoner来做代码补全推理模型会先输出思考过程延迟自然高。解决方法是把 Codex 的模型换成deepseek-chat并且把 max_tokens 调小比如 128因为代码补全不需要长输出。另外检查网络延迟如果 API 端点在国外加一层本地缓存或代理会改善但注意不要违反使用条款。4.5 现象同一段 prompt 今天好用明天不好用原因可能是模型版本在后台更新了或者你的 temperature 设得偏高导致输出不稳定。解决方法是把 temperature 降到 0.2 以下并且在 prompt 里加 few-shot 示例用两三个输入输出对来锚定格式。如果还是不稳定考虑把关键任务拆成多个步骤每一步只做一件事减少单次调用的复杂度。5. 进阶技巧用 DeepSeek 做批量结构化抽取的完整链路当你已经能稳定调用 API 之后下一步是把单次调用变成批量流水线。我一般会用一个 Python 脚本读 CSV逐行构造 prompt调用 API解析 JSON写回 CSV。关键点是加并发控制和重试机制否则遇到限流就全挂。下面是一个可复现的最小实现用concurrent.futures做线程池用tenacity做重试。import csv import json from concurrent.futures import ThreadPoolExecutor, as_completed from tenacity import retry, stop_after_attempt, wait_exponential from openai import OpenAI client OpenAI(api_keyyour-key, base_urlhttps://api.deepseek.com/v1) retry(stopstop_after_attempt(3), waitwait_exponential(multiplier1, min2, max10)) def extract_one(text): resp client.chat.completions.create( modeldeepseek-chat, messages[ {role: system, content: 抽取公司名和金额输出 JSON键为 company 和 amount}, {role: user, content: text} ], temperature0.1, max_tokens128, response_format{type: json_object} ) return json.loads(resp.choices[0].message.content) def process_csv(input_path, output_path, max_workers5): rows [] with open(input_path, r, encodingutf-8) as f: reader csv.DictReader(f) for row in reader: rows.append(row) results [] with ThreadPoolExecutor(max_workersmax_workers) as executor: future_map {executor.submit(extract_one, r[text]): r for r in rows} for future in as_completed(future_map): row future_map[future] try: data future.result() row.update(data) except Exception as e: row[error] str(e) results.append(row) with open(output_path, w, encodingutf-8, newline) as f: writer csv.DictWriter(f, fieldnamesresults[0].keys()) writer.writeheader() writer.writerows(results) if __name__ __main__: process_csv(input.csv, output.csv, max_workers5)这段代码的逻辑是读入 CSV每一行取 text 字段丢给 extract_one 函数。extract_one 里用 tenacity 装饰器做重试最多 3 次等待时间指数增长。线程池大小设为 5是因为 DeepSeek 的 API 有并发限制设太大容易被限流。解析 JSON 时如果失败会抛异常被外层捕获后写入 error 字段不会中断整个流程。跑完之后output.csv 里会多出 company 和 amount 两列。参数上max_workers可以根据你的账户等级调整但建议从 3 开始试稳定后再加。wait_exponential的 min 和 max 控制重试间隔避免频繁重试被 ban。这个链路跑通之后你可以把 extract_one 里的 prompt 换成任何抽取任务比如合同条款、日志摘要、工单分类。唯一要注意的是每次调用都会消耗 token批量之前先算一下成本别跑完了才发现额度不够。我自己的习惯是先用 10 条数据做小批量验证确认输出格式和准确率都达标再全量跑。希望帮到你。本文还有配套的精品资源点击获取 DeepSeek从入门到精通：API调用、参数调优与本地部署实战指南
简介这份《DeepSeek指导手册从入门到精通》是一份面向AI助手新用户、技术人员及内容创作者的实操型PDF文档围绕DeepSeek平台从零基础到高阶应用展开覆盖账户创建、控制台功能、高效提问法则、文档分析、代码自动生成、论文辅助、自媒体运营与个性化知识库搭建等场景兼顾学习管理与自动化脚本需求。资源包共1个PDF文件大小约1.27MB内容按准备篇、基础对话篇、效率飞跃篇、场景实战篇等模块组织配有具体指令示例、避坑指南与操作提示便于按章节检索学习。目前已有2744人学习下载适合希望系统掌握AI辅助工作流、提升内容生产与学习效率的读者参考。1. 从“会聊天”到“能干活”DeepSeek指导手册到底在解决什么问题很多人第一次用 DeepSeek 是在网页对话框里问几个问题觉得“哦挺聪明”然后就关掉了。过几天再打开还是问同样类型的问题还是把它当搜索引擎用。这不是 DeepSeek 的问题是使用方式的问题。一份真正能落地的 DeepSeek 指导手册核心不是教你“怎么问问题”而是教你把它从一个对话玩具变成嵌入工作流的执行引擎。入门到精通的分界线不在于你背了多少提示词模板而在于你是否理解三件事模型的能力边界在哪、API 调用时参数怎么影响输出、本地或云端部署时资源怎么分配。这篇内容面向的是已经用过 DeepSeek 但觉得“没发挥出来”的开发者、运维和自动化需求方我会按“先跑通最小闭环、再调参数、最后避坑”的顺序把从调用到部署的完整路径拆开讲。如果你只想要一个“帮我写周报”的提示词那不用往下看如果你想让它接入 Codex、跑在 Jetson Orin 上、或者用 vLLM 做批量推理那接下来的内容就是给你准备的。2. 先跑通再谈精通DeepSeek API 调用的最小闭环2.1 从 API Key 到第一次成功返回不管后面是接 Codex、做本地部署还是搞智能体第一步永远是拿到一个能跑通的 API 调用。DeepSeek 的 API 兼容 OpenAI 的接口格式这意味着你不需要学一套全新的 SDK用 openai 的 Python 包改一下 base_url 就能用。常见做法是先把 key 放到环境变量里不要硬编码在脚本里这是血泪经验——一旦代码进了 gitkey 就等于公开了。import os from openai import OpenAI # 从环境变量读取不要写死在代码里 client OpenAI( api_keyos.environ.get(DEEPSEEK_API_KEY), base_urlhttps://api.deepseek.com/v1 # 注意结尾的 /v1 ) response client.chat.completions.create( modeldeepseek-chat, # 通用对话模型 messages[ {role: system, content: 你是一个只输出 JSON 的助手}, {role: user, content: 列出三个常见的 HTTP 状态码及其含义} ], temperature0.3, # 低温度适合结构化输出 max_tokens512 ) print(response.choices[0].message.content)这段代码的逻辑很直白构造一个 OpenAI 客户端把 base_url 指向 DeepSeek 的端点然后发一条标准的 chat completion 请求。参数上model目前常用的是deepseek-chat和deepseek-reasoner前者适合日常对话和结构化任务后者适合需要推理链的场景。temperature设成 0.3 是为了让输出更稳定如果你要它写创意文案可以调到 0.8 以上。max_tokens控制的是输出长度不是输入长度设太小会导致回答被截断设太大则浪费额度。第一次跑通之后你会看到返回的 JSON 里除了 content还有 usage 字段里面记录了 prompt_tokens 和 completion_tokens这是后面算成本的依据。2.2 参数怎么调temperature、top_p 和 max_tokens 的实际影响很多人调 API 时只改 prompt不动参数结果就是“有时候好有时候坏”然后归结为玄学。其实 temperature 和 top_p 是控制随机性的两个旋钮但不要同时调一般只动一个。temperature 越高输出越多样但越容易跑偏top_p 是核采样0.9 意味着只从累积概率前 90% 的词里选比 temperature 更平滑。我的习惯是结构化抽取任务用 temperature0.1top_p 不动创意生成用 temperature0.8top_p0.95。max_tokens 要根据任务设比如做分类任务输出就几个字设 64 就够了做长文摘要至少设 1024。还有一个容易忽略的参数是stream设为 True 时返回的是流式数据适合做打字机效果但如果你要解析完整 JSON流式反而麻烦建议先关掉。# 结构化抽取场景的参数组合 response client.chat.completions.create( modeldeepseek-chat, messages[ {role: system, content: 从用户文本中抽取姓名、电话、地址输出 JSON}, {role: user, content: 张三13800138000北京市海淀区中关村大街1号} ], temperature0.1, # 极低随机性保证每次输出格式一致 max_tokens256, response_format{type: json_object} # 强制 JSON 输出 )这里用到了response_format参数设为 json_object 后模型会尽量输出合法 JSON。但注意这个参数不是万能的如果 prompt 里没提 JSON模型可能还是输出普通文本。所以 system message 里一定要明确“输出 JSON”。另外DeepSeek 的 JSON 模式对字段名没有强制约束你需要在 prompt 里把字段名写清楚否则它可能用中文键名。参数调完之后建议用同一段输入跑 5 次看输出是否稳定如果 5 次里有 2 次格式不一样说明 temperature 还是太高或者 prompt 不够明确。3. 把 DeepSeek 接进你的工具链Codex、ccswitch 与本地部署3.1 接入 Codex 和 ccswitch 的配置要点Codex 和 ccswitch 是最近热搜里频繁出现的词前者是代码生成工具后者是配置切换工具。把 DeepSeek 接入 Codex 的常见做法是修改 Codex 的配置文件把默认的模型端点指向 DeepSeek 的 API。具体来说Codex 通常读取一个 config 文件里面有一个model_provider字段你需要在 provider 列表里加一个 DeepSeek 的条目填入 base_url 和 api_key。ccswitch 的作用是让你在多个 provider 之间快速切换比如白天用 DeepSeek晚上用另一个模型不用手动改配置文件。# 以 ccswitch 为例添加一个 DeepSeek 配置 ccswitch add deepseek \ --base-url https://api.deepseek.com/v1 \ --api-key $DEEPSEEK_API_KEY \ --model deepseek-chat # 切换到 DeepSeek ccswitch use deepseek # 查看当前生效的配置 ccswitch current这段命令的逻辑是先注册一个名为 deepseek 的配置然后激活它。参数上--base-url必须带/v1否则 Codex 可能拼出错误的路径--model指定默认模型如果你要用推理模型改成deepseek-reasoner。ccswitch 本身不存储 key 的明文它读的是环境变量所以$DEEPSEEK_API_KEY要提前 export。配置完成后在 Codex 里发一条代码补全请求看返回是否正常。如果报 401检查 key 是否过期如果报 404检查 base_url 是不是多写了或少写了/v1。3.2 本地部署 DeepSeek 的显存与量化选择本地部署是另一个高频需求尤其是 Jetson Orin 这类边缘设备。DeepSeek 的模型尺寸决定了显存门槛7B 级别的模型FP16 需要约 14GB 显存INT8 量化后约 7GBINT4 量化后约 4GB。Jetson Orin 常见版本是 8GB 或 16GB 显存所以 7B 模型用 INT4 量化是可以跑的但推理速度不会太快。如果要用 vLLM 部署它对显存的管理更高效支持 PagedAttention但 vLLM 对 Jetson 的支持需要额外编译不是 pip install 就能搞定。# 使用 vLLM 启动 DeepSeek 7B 的 INT4 量化版本 python -m vllm.entrypoints.openai.api_server \ --model deepseek-ai/deepseek-llm-7b-chat \ --quantization awq \ --dtype float16 \ --max-model-len 4096 \ --gpu-memory-utilization 0.9 \ --port 8000参数说明--quantization awq指定使用 AWQ 量化需要模型本身有 AWQ 权重--max-model-len控制上下文长度设太大显存会爆--gpu-memory-utilization 0.9表示用 90% 的显存留一点给系统。启动后你会看到一个兼容 OpenAI 的端点跑在 8000 端口然后用前面的 OpenAI 客户端把 base_url 改成http://localhost:8000/v1就能调用。注意本地部署的模型能力通常比云端 API 弱因为云端可能是更大的模型所以本地部署适合对延迟敏感、数据不能出内网的场景不适合追求最强效果的场景。4. 避坑与排查DeepSeek 使用中最容易翻车的五个地方4.1 现象API 返回 400提示 context length exceeded原因通常是你把整个文档塞进了 prompt超过了模型的最大上下文。DeepSeek 的上下文窗口是有限的虽然不同版本不一样但常见的是 64K 或 128K token。一个中文字大约 1.5 个 token所以 64K 大约能放 4 万字。解决方法是做分块把长文档切成 2000 字左右的片段分别抽取信息再合并。不要试图用“请总结以下内容”来绕过长度限制超了就是超了。4.2 现象输出 JSON 解析失败多出 markdown 代码块标记原因是你虽然设了response_format{type: json_object}但模型仍然可能在 JSON 外面包一层json。解决方法是解析前先做字符串清洗去掉开头的json 和结尾的。更稳妥的做法是在 system message 里加一句“不要用 markdown 代码块包裹 JSON”。如果还是不行就上正则提取第一个{到最后一个}之间的内容。4.3 现象本地部署时显存溢出进程被 kill原因通常是 max_model_len 设得太大或者 gpu_memory_utilization 设成了 1.0。解决方法是先把 max_model_len 降到 2048把 gpu_memory_utilization 降到 0.8跑通后再逐步往上加。另外Jetson 设备上要注意共享显存的问题系统和模型抢内存是常态建议在启动脚本里加--swap-space 4来用一点磁盘交换但速度会慢。4.4 现象接入 Codex 后补全速度极慢原因可能是你用了推理模型deepseek-reasoner来做代码补全推理模型会先输出思考过程延迟自然高。解决方法是把 Codex 的模型换成deepseek-chat并且把 max_tokens 调小比如 128因为代码补全不需要长输出。另外检查网络延迟如果 API 端点在国外加一层本地缓存或代理会改善但注意不要违反使用条款。4.5 现象同一段 prompt 今天好用明天不好用原因可能是模型版本在后台更新了或者你的 temperature 设得偏高导致输出不稳定。解决方法是把 temperature 降到 0.2 以下并且在 prompt 里加 few-shot 示例用两三个输入输出对来锚定格式。如果还是不稳定考虑把关键任务拆成多个步骤每一步只做一件事减少单次调用的复杂度。5. 进阶技巧用 DeepSeek 做批量结构化抽取的完整链路当你已经能稳定调用 API 之后下一步是把单次调用变成批量流水线。我一般会用一个 Python 脚本读 CSV逐行构造 prompt调用 API解析 JSON写回 CSV。关键点是加并发控制和重试机制否则遇到限流就全挂。下面是一个可复现的最小实现用concurrent.futures做线程池用tenacity做重试。import csv import json from concurrent.futures import ThreadPoolExecutor, as_completed from tenacity import retry, stop_after_attempt, wait_exponential from openai import OpenAI client OpenAI(api_keyyour-key, base_urlhttps://api.deepseek.com/v1) retry(stopstop_after_attempt(3), waitwait_exponential(multiplier1, min2, max10)) def extract_one(text): resp client.chat.completions.create( modeldeepseek-chat, messages[ {role: system, content: 抽取公司名和金额输出 JSON键为 company 和 amount}, {role: user, content: text} ], temperature0.1, max_tokens128, response_format{type: json_object} ) return json.loads(resp.choices[0].message.content) def process_csv(input_path, output_path, max_workers5): rows [] with open(input_path, r, encodingutf-8) as f: reader csv.DictReader(f) for row in reader: rows.append(row) results [] with ThreadPoolExecutor(max_workersmax_workers) as executor: future_map {executor.submit(extract_one, r[text]): r for r in rows} for future in as_completed(future_map): row future_map[future] try: data future.result() row.update(data) except Exception as e: row[error] str(e) results.append(row) with open(output_path, w, encodingutf-8, newline) as f: writer csv.DictWriter(f, fieldnamesresults[0].keys()) writer.writeheader() writer.writerows(results) if __name__ __main__: process_csv(input.csv, output.csv, max_workers5)这段代码的逻辑是读入 CSV每一行取 text 字段丢给 extract_one 函数。extract_one 里用 tenacity 装饰器做重试最多 3 次等待时间指数增长。线程池大小设为 5是因为 DeepSeek 的 API 有并发限制设太大容易被限流。解析 JSON 时如果失败会抛异常被外层捕获后写入 error 字段不会中断整个流程。跑完之后output.csv 里会多出 company 和 amount 两列。参数上max_workers可以根据你的账户等级调整但建议从 3 开始试稳定后再加。wait_exponential的 min 和 max 控制重试间隔避免频繁重试被 ban。这个链路跑通之后你可以把 extract_one 里的 prompt 换成任何抽取任务比如合同条款、日志摘要、工单分类。唯一要注意的是每次调用都会消耗 token批量之前先算一下成本别跑完了才发现额度不够。我自己的习惯是先用 10 条数据做小批量验证确认输出格式和准确率都达标再全量跑。希望帮到你。本文还有配套的精品资源点击获取