DeepSeek API 价格调整之后很多人第一反应是“又要多烧钱了”第二反应是“能不能少调几次接口”。如果业务里大量重复流程还在一次次手动复制粘贴、重复调用大模型token 消耗确实会快速累积。这篇文章不聊模型本身怎么调优而是讲一个更省成本的思路把重复流程交给 RPA 自动跑让大模型只处理真正需要推理的环节从调用次数、上下文长度、失败重试三个层面把 token 花销压下来。先给结论RPA 并不是要取代 DeepSeek而是负责那些“不需要动脑”的环节比如文件读取、表格整理、页面跳转、结果回填DeepSeek 只承担生成、总结、判断这类不可替代的步骤。两者结合既保留 AI 能力又避免让大模型在琐碎流程上空转。这样做之后一个常见的日报生成流程我可以把每次 API 调用消耗控制在原有方案的 1/3 到 1/5前提是流程设计合理。这篇文章会围绕一个具体场景展开用 RPA 驱动 DeepSeek API 完成批量文章改写和报告生成并给出可复制的工程化配置、调用示例和成本控制方法。1. 核心能力速览能力项说明项目类型大模型 API RPA 流程自动化组合方案核心目标通过 RPA 接管重复操作降低 DeepSeek API 调用频率与 token 消耗技术栈DeepSeek API、Python、影刀 RPA或同类 RPA 工具、HTTP 接口启动方式RPA 编辑器内运行流程 / Python 脚本调度 / 定时触发主要功能批量文本处理、日报生成、网页数据抓取、结果自动回填、失败重试token 控制手段缓存复用、上下文裁剪、失败重试、批量合并、结果落地复用适合场景内容生产、数据整理、客服话术生成、周报日报、测试数据构造不适合场景单次对话式需求、强实时交互、需要高自由度创作的长文生成硬件要求普通办公电脑即可无需 GPUAPI 调用为主这个组合的核心思路是RPA 处理“流程”DeepSeek 处理“文本”。比如你要整理 50 份 PDF 摘要RPA 负责遍历文件、提取文本、调用 API、把结果写回表格DeepSeek 只负责把每一段文本压缩成摘要。如果写代码调 APIRPA 的价值不大但如果流程里包含网页登录、Excel 操作、定时触发、异常重试RPA 就能把零散环节串成完整链路。2. 为什么 token 烧得快问题出在重复调用很多人对 token 消耗的理解是“我让 AI 写得越多越贵”实际上大部分浪费来自三类情况。第一重复相同请求。同样是“帮我校对这段话”如果每次都把完整上下文发给 API而模型并不需要理解全部背景才能完成任务就会多付输入费用。尤其当你把长篇资料、历史对话、系统提示词全塞进去哪怕生成结果只有几百字输入 token 依然是几千甚至上万。第二失败任务没有重试策略。API 偶发超时、网络抖动、限流流程直接断了下一次人工重跑又把之前烧掉的 token 再烧一遍。没有缓存、没有结果落地、没有断点续跑每次失败都等于重复计费。第三上下文被不必要地撑大。比如你要生成 20 篇短视频脚本正确做法是一次只发送当篇的主题和参考素材错误做法是把 20 篇参考全部拼进一个 prompt让模型自己翻找。后者输入 token 可能是前者的 20 倍输出质量并不会更好。RPA 的作用就是在这些环节加一层“拦截器”先检查有没有缓存再裁剪上下文最后自动重试。把每一次 API 调用都变成可审计、可复用、可量化的任务而不是靠人手一次次点发送。3. 环境准备与前置条件这套方案不需要 GPU也不需要专门的大模型部署环境核心工作围绕三块内容展开。3.1 软件环境Windows 10/11 系统RPA 工具对 Windows 兼容性最好。影刀 RPA 客户端或者任意支持 HTTP 请求和 Excel/网页操作的 RPA 工具。Python 3.9 及以上版本用于编写 API 调用辅助脚本也可以用 RPA 内置的 HTTP 组件代替。DeepSeek API Key从官方开放平台创建。本地目录结构建议input/放待处理素材output/放结果cache/放已处理记录logs/放运行日志。3.2 网络与接口准备DeepSeek API 走标准 HTTPS 调用通常不需要额外网络配置。但要注意API 服务地址、端口、鉴权方式要以官方文档为准。如果企业内网有代理RPA 和 Python 脚本需要单独配置代理变量否则请求直接失败。API Key 是敏感信息不要硬编码进 RPA 流程或提交到代码仓库建议通过环境变量读取。用环境变量管理 Key 的示例set DEEPSEEK_API_KEYsk-xxxxxxxxxxxxxxxxPython 读取import os api_key os.environ.get(DEEPSEEK_API_KEY) if not api_key: raise RuntimeError(请先配置 DEEPSEEK_API_KEY 环境变量)3.3 数据准备在跑流程之前把输入素材整理成结构化表格。比如你要批量生成商品文案Excel 字段先设计好商品名称卖点关键词目标平台字数要求参考风格无线蓝牙耳机降噪、续航、舒适电商详情页200字专业简约RPA 读取 Excel 时会按行循环每一行代表一次独立的 API 任务。如果字段没设计好后面写 prompt 逻辑会比较别扭。4. 安装部署与启动方式这里给出两种启动路径一种用影刀 RPA 的图形化流程适合非程序员一种用 Python 脚本适合需要更精细控制批量任务和错误处理的场景。4.1 影刀 RPA 流程搭建安装影刀 RPA 后新建一个自动化流程包含以下组件读取 Excel 数据遍历输入表格每一行。检查缓存如果该行已经生成过结果直接跳过。调用 DeepSeek API通过“发送 HTTP 请求”组件把 prompt 拼好并 POST 给 API。解析响应从 JSON 返回里提取需要的内容字段。写入结果把返回值写到 Excel 对应单元格或新文件。异常重试请求失败时等待几秒后重试连续失败则记录日志并跳过。影刀 RPA 的 HTTP 请求组件可以直接指定 JSON body使用流程变量填充 prompt。这个路径适合不需要写代码、主要操作 Excel 和网页的用户。4.2 Python 脚本启动如果你更习惯代码方式可以用 Python requests 实现同样的批量流程。import csv import json import os import time import requests from pathlib import Path API_URL https://api.deepseek.com/chat/completions # 实际地址以官方文档为准 API_KEY os.environ.get(DEEPSEEK_API_KEY) HEADERS { Authorization: fBearer {API_KEY}, Content-Type: application/json } SYSTEM_PROMPT 你是一名电商文案助手只输出文案正文不要输出额外解释。 def generate_copy(title: str, keywords: str, platform: str, length: int) - str: user_content ( f商品名称{title}\n f卖点关键词{keywords}\n f目标平台{platform}\n f字数要求{length}字\n\n f请基于以上信息生成一条完整文案。 ) payload { model: deepseek-chat, messages: [ {role: system, content: SYSTEM_PROMPT}, {role: user, content: user_content} ], temperature: 0.9, max_tokens: 2048 } response requests.post(API_URL, headersHEADERS, jsonpayload, timeout120) response.raise_for_status() data response.json() return data[choices][0][message][content] def main(): input_file Path(input/tasks.csv) cache_file Path(cache/done.txt) output_file Path(output/results.csv) done_ids set() if cache_file.exists(): done_ids set(cache_file.read_text(encodingutf-8).splitlines()) results [] with open(input_file, encodingutf-8) as f: reader csv.DictReader(f) for row in reader: task_id row[id] if task_id in done_ids: print(f[跳过] {task_id} 已处理) continue for attempt in range(3): try: content generate_copy( titlerow[title], keywordsrow[keywords], platformrow[platform], lengthint(row[length]) ) results.append({ id: task_id, title: row[title], output: content }) with open(cache_file, a, encodingutf-8) as cf: cf.write(task_id \n) print(f[完成] {task_id}) break except Exception as e: print(f[失败] {task_id} 第{attempt 1}次: {e}) time.sleep(5) else: print(f[跳过] {task_id} 连续失败进入日志)这个脚本的核心逻辑是读取任务清单、跳过已完成、最多重试 3 次、把已完成任务 ID 写入缓存文件。即使中途断掉重新执行也会从断点继续不会重复计费。5. 功能测试与效果验证搭建完流程后不要直接跑全量数据。先用 3 到 5 条任务做小批量验证确认 prompt 效果和 token 消耗符合预期再放开全量。5.1 基础生成能力测试测试目的确认 API 能正常响应、返回字段解析正确。操作步骤准备一条 200 字以内的简单任务。手动调用一次 API查看返回内容。检查返回 JSON 里是否有choices[0].message.content字段。预期结果HTTP 200 状态码。返回内容包含完整文案而不是报错信息。响应时间在 30 秒以内。判断标准返回内容可读、无截断、无格式错乱、没有出现标题和正文混杂。5.2 批量任务缓存验证测试目的验证缓存逻辑能否避免重复消耗。操作步骤用 5 条任务跑第一轮记录输入 token 总和。不删除缓存文件重跑同一批任务。观察控制台是否打印[跳过]以及是否产生新的 API 请求。预期结果第二轮没有新请求日志中 5 条全部跳过。判断标准如果第二轮产生了相同请求说明缓存键值设置有问题需要检查是否用了唯一 ID 作为缓存依据。5.3 失败重试验证测试目的确认网络抖动或接口报错时任务不会被永久卡住。操作步骤故意把 API_URL 改成一个不存在的地址。跑 1 条任务。观察重试日志。预期结果脚本连续重试 3 次每次间隔 5 秒最后记录为失败并继续下一条任务而不是整个进程崩溃。判断标准日志中有明确的失败次数和最终跳过标记。5.4 输出质量对比测试目的验证 prompt 结构是否稳定是否因为上下文裁剪导致输出变差。操作步骤同一批输入分别用完整上下文 prompt 和精简 prompt 各跑一次。对比输出结果质量。预期结果精简 prompt 的输出在信息完整性上没有明显下降但输入 token 显著减少。判断标准如果精简后输出经常丢失关键卖点说明 prompt 里该保留的约束没有保留需要调整而不是简单删内容。6. 接口 API 调用与 token 成本控制DeepSeek API 调用本身是一个标准的 OpenAI 兼容接口但成本控制的关键在请求设计上。6.1 请求参数设计示例报文{ model: deepseek-chat, messages: [ { role: system, content: 你只负责写文案不回答其他问题。 }, { role: user, content: 商品保温杯卖点保温12小时、便携、304不锈钢字数150。 } ], temperature: 0.8, max_tokens: 1024, stream: false }控制 token 消耗的六个策略精简 system prompt不要把规则写成长篇小说。能放进代码的条件判断就不要让模型处理。每次请求只发送当条任务需要的最低上下文。相同前缀的模板内容在代码里拼接而不是让模型翻找。设置合理的max_tokens避免模型自由发挥输出超长废话。相同结果不重复调用用缓存文件或数据库记录 task_id。固定不变的参考内容不要写进每个 prompt可以在模型输出后用代码做二次校验。6.2 Python 调用示例import requests url https://api.deepseek.com/chat/completions # 以官方文档为准 payload { model: deepseek-chat, messages: [ {role: system, content: 你是日报生成助手只输出要点。}, {role: user, content: 今日事项开会、写文档、修bug。请生成3条日报要点。} ], temperature: 0.6, max_tokens: 512 } headers { Authorization: Bearer YOUR_API_KEY, Content-Type: application/json } response requests.post(url, headersheaders, jsonpayload, timeout60) data response.json() print(data[choices][0][message][content])6.3 批量任务队列设计批量任务的目录结构可以参考deepseek_rpa/ ├── input/ │ ├── tasks.csv │ └── source_files/ ├── output/ │ ├── results.csv │ └── generated_texts/ ├── cache/ │ └── done.txt ├── logs/ │ └── error.log └── run_flow.py批量任务运行建议每执行一条任务立即写缓存不要等全部跑完再写。日志要包含任务 ID、开始时间、结束时间、HTTP 状态码、token 用量。连续失败超过 3 次的自动放入错误清单等人工处理。批量数量大时在两条请求之间加 1 到 2 秒延迟避免触发限流。6.4 RPA 结合 API 的典型流程RPA 在真实业务里往往要处理“登录网页、读取表格、下载文件、填写表单”这些大模型做不了的操作。一个完整的 RPA 流程可能是RPA 打开业务系统登录。按日期范围筛选订单列表。把每一条订单的备注、金额、客户名称读入 Excel。对每一行调用 DeepSeek API生成个性化工单备注。将生成结果写回系统表单。页面翻页重复执行直到全部完成。这种场景里RPA 省掉的是“人一次次复制粘贴到对话框再复制回来”的重复时间DeepSeek 只负责生成文本不做网页操作。两者分工明确。7. 资源占用与性能观察这套组合是轻量本地部署只需要关注网络、内存和磁盘占用。7.1 内存与 CPU 占用RPA 工具运行时一般在几百 MB 内存量级Python 脚本相对更轻几十 MB 就能跑。整个过程不涉及大模型本地推理所以没有 GPU 压力。这里说的量级是常见水平具体以你安装的 RPA 版本和脚本复杂度为准。7.2 API 响应时间响应时间主要取决于输入 prompt 长度和max_tokens设置。几十字输入几百字输出通常在几秒到十几秒之间。如果响应时间突然涨到 1 分钟以上不要盲目加大超时时间先检查是不是输入了超长文本模型需要更多时间处理。是不是网络到 API 服务端延迟升高。是不是max_tokens设置过大模型输出超长。7.3 如何观察 token 消耗在 Python 脚本中添加 token 用量输出print(prompt_tokens:, data[usage][prompt_tokens]) print(completion_tokens:, data[usage][completion_tokens]) print(total_tokens:, data[usage][total_tokens])在 RPA 流程中则可以把返回 JSON 里的usage字段解析出来写入日志或统计表。批量任务跑完后汇总所有任务的 total_tokens就能估算本轮运行的实际开销。7.4 如何降低消耗给每条任务设置字数上限输出截断比想象中常见。对长文章做分段处理而不是一次性让模型读完全部再改写。能合并的任务合并成一个请求比如把 5 个短问题放进一条 prompt让模型分条返回。建立结果复用机制同一个输入素材只让模型处理一次。这几种方法在一起使用通常能压掉一半以上不必要的输入 token。8. 常见问题与排查方法问题现象可能原因排查方式解决方案API 返回 401 或 403API Key 错误、权限不足检查环境变量和 Key 是否匹配重新生成 Key并把 Key 放到环境变量读取请求超时网络不稳定或参数过大查看错误日志确认超时时间增加 timeout或缩小单次任务规模返回内容为空max_tokens 太小模型输出被截断查看 completion_tokens 是否等于 max_tokens增大 max_tokens或裁剪 system prompt批量任务中途停止RPA 页面元素定位失败查看 RPA 日志和截图调整页面选择器增加异常重试同一任务反复计费缓存逻辑失效或没有写缓存检查 cache 文件路径和 task_id 唯一性确保成功结束立即写缓存文件Excel 读取乱码编码格式不支持检查文件编码Excel 另存为 UTF-8 CSV或先转编码并发请求被限流请求间隔过短查看 HTTP 429 状态码增加请求间隔限制并发数输出质量不稳定prompt 约束不足或 temperature 过高固定 model 和 temperature多测几条把 temperature 降到 0.6 左右并完善 system prompt这里显存问题不存在因为所有推理都在 API 服务端完成本地不做模型推理。如果你的电脑性能很差只需要确保浏览器、RPA、脚本同时跑时不卡顿。9. 最佳实践与使用建议9.1 流程设计原则第一次跑通之前不要追求“全自动无人值守”。先把单条任务从读取到写回全部打通再叠加定时触发和批量循环。每次只改一个变量比如先观察 prompt 效果再调缓存逻辑最后加失败重试。给每条任务设置唯一 task_id。这个 ID 既是缓存键也是日志索引还是重试判断依据。没有唯一 ID批量任务就没法做断点续跑。9.2 数据与输出管理输入、输出、缓存、日志分开目录存放不要全部堆积在一个文件夹。批量跑完之后把结果和 token 用量统计一起归档方便复盘成本。9.3 合规与安全调用 API 前确认业务场景符合平台服务条款。涉及客户数据、公司内部文档、个人隐私信息时必须先在本地做脱敏处理。批量生成内容发布前要做人工复核尤其涉及事实性表述、数据引用、代运营发布时。API Key 只放在受控环境中不要提交到代码仓库、发给他人或在日志里明文打印。如果 RPA 操作的是第三方系统比如自动登录、采集、回填必须确认有合法授权遵守平台规则不得用于绕过访问限制、批量抓取受限数据或任何破坏系统正常秩序的用途。使用 DeepSeek 生成的内容在法律和平台允许范围内可以继续使用但涉及知识产权的部分要保留判断。9.4 成本预算思路不要只在月初看一眼接口账单。更好的做法是每跑完一批任务就统计 total_tokens 和对应任务数量得到单任务平均消耗。然后根据未来业务量估算月消耗做到心里有数。比如 1000 条文案任务每条任务平均消耗 1500 token那一轮批量任务就是 150 万 token成本可以直接按接口定价算出来。如果单任务平均消耗异常偏高大概率不是模型涨价而是 prompt 设计有问题优先检查是不是塞了太多不必要内容。10. 总结与下一步DeepSeek 这类大模型 API 的价格调整是不可控的但 token 消耗的多少却可以通过流程设计来控制。RPA 在这里最大的价值不是“替代 AI”而是把 AI 从一个被反复调用的“临时工”变成一个按需取用的“专属服务”。重复的搬运、判断、重试、记录交给 RPA模型只做理解和生成成本自然降下来。刚开始实践时先做一个最小的流程用 RPA 读 Excel、调 API、写结果、断点续跑。跑通之后再加定时触发、页面操作、多轮处理。最容易踩的坑主要集中在三处一是 prompt 里塞了太多不必要上下文二是缓存没做好导致重复调用三是批量失败后没有重试和审计机制。这三处解决掉这套方案基本就稳定了。后续可以继续扩展的方向很多给 RPA 流程加一个 web 管理面板把批量任务提交变成网页按钮接入消息推送任务跑完发通知把缓存升级成数据库支持更复杂的去重和复用甚至可以把 DeepSeek 生成的文本自动导入到 CMS 系统做成一条从采集到发布的完整内容流水线。建议先保存这篇文章等下一次你要批量处理文本类任务时再回来对照搭流程。
DeepSeek API成本优化：用RPA自动化降低token消耗的实用指南
DeepSeek API 价格调整之后很多人第一反应是“又要多烧钱了”第二反应是“能不能少调几次接口”。如果业务里大量重复流程还在一次次手动复制粘贴、重复调用大模型token 消耗确实会快速累积。这篇文章不聊模型本身怎么调优而是讲一个更省成本的思路把重复流程交给 RPA 自动跑让大模型只处理真正需要推理的环节从调用次数、上下文长度、失败重试三个层面把 token 花销压下来。先给结论RPA 并不是要取代 DeepSeek而是负责那些“不需要动脑”的环节比如文件读取、表格整理、页面跳转、结果回填DeepSeek 只承担生成、总结、判断这类不可替代的步骤。两者结合既保留 AI 能力又避免让大模型在琐碎流程上空转。这样做之后一个常见的日报生成流程我可以把每次 API 调用消耗控制在原有方案的 1/3 到 1/5前提是流程设计合理。这篇文章会围绕一个具体场景展开用 RPA 驱动 DeepSeek API 完成批量文章改写和报告生成并给出可复制的工程化配置、调用示例和成本控制方法。1. 核心能力速览能力项说明项目类型大模型 API RPA 流程自动化组合方案核心目标通过 RPA 接管重复操作降低 DeepSeek API 调用频率与 token 消耗技术栈DeepSeek API、Python、影刀 RPA或同类 RPA 工具、HTTP 接口启动方式RPA 编辑器内运行流程 / Python 脚本调度 / 定时触发主要功能批量文本处理、日报生成、网页数据抓取、结果自动回填、失败重试token 控制手段缓存复用、上下文裁剪、失败重试、批量合并、结果落地复用适合场景内容生产、数据整理、客服话术生成、周报日报、测试数据构造不适合场景单次对话式需求、强实时交互、需要高自由度创作的长文生成硬件要求普通办公电脑即可无需 GPUAPI 调用为主这个组合的核心思路是RPA 处理“流程”DeepSeek 处理“文本”。比如你要整理 50 份 PDF 摘要RPA 负责遍历文件、提取文本、调用 API、把结果写回表格DeepSeek 只负责把每一段文本压缩成摘要。如果写代码调 APIRPA 的价值不大但如果流程里包含网页登录、Excel 操作、定时触发、异常重试RPA 就能把零散环节串成完整链路。2. 为什么 token 烧得快问题出在重复调用很多人对 token 消耗的理解是“我让 AI 写得越多越贵”实际上大部分浪费来自三类情况。第一重复相同请求。同样是“帮我校对这段话”如果每次都把完整上下文发给 API而模型并不需要理解全部背景才能完成任务就会多付输入费用。尤其当你把长篇资料、历史对话、系统提示词全塞进去哪怕生成结果只有几百字输入 token 依然是几千甚至上万。第二失败任务没有重试策略。API 偶发超时、网络抖动、限流流程直接断了下一次人工重跑又把之前烧掉的 token 再烧一遍。没有缓存、没有结果落地、没有断点续跑每次失败都等于重复计费。第三上下文被不必要地撑大。比如你要生成 20 篇短视频脚本正确做法是一次只发送当篇的主题和参考素材错误做法是把 20 篇参考全部拼进一个 prompt让模型自己翻找。后者输入 token 可能是前者的 20 倍输出质量并不会更好。RPA 的作用就是在这些环节加一层“拦截器”先检查有没有缓存再裁剪上下文最后自动重试。把每一次 API 调用都变成可审计、可复用、可量化的任务而不是靠人手一次次点发送。3. 环境准备与前置条件这套方案不需要 GPU也不需要专门的大模型部署环境核心工作围绕三块内容展开。3.1 软件环境Windows 10/11 系统RPA 工具对 Windows 兼容性最好。影刀 RPA 客户端或者任意支持 HTTP 请求和 Excel/网页操作的 RPA 工具。Python 3.9 及以上版本用于编写 API 调用辅助脚本也可以用 RPA 内置的 HTTP 组件代替。DeepSeek API Key从官方开放平台创建。本地目录结构建议input/放待处理素材output/放结果cache/放已处理记录logs/放运行日志。3.2 网络与接口准备DeepSeek API 走标准 HTTPS 调用通常不需要额外网络配置。但要注意API 服务地址、端口、鉴权方式要以官方文档为准。如果企业内网有代理RPA 和 Python 脚本需要单独配置代理变量否则请求直接失败。API Key 是敏感信息不要硬编码进 RPA 流程或提交到代码仓库建议通过环境变量读取。用环境变量管理 Key 的示例set DEEPSEEK_API_KEYsk-xxxxxxxxxxxxxxxxPython 读取import os api_key os.environ.get(DEEPSEEK_API_KEY) if not api_key: raise RuntimeError(请先配置 DEEPSEEK_API_KEY 环境变量)3.3 数据准备在跑流程之前把输入素材整理成结构化表格。比如你要批量生成商品文案Excel 字段先设计好商品名称卖点关键词目标平台字数要求参考风格无线蓝牙耳机降噪、续航、舒适电商详情页200字专业简约RPA 读取 Excel 时会按行循环每一行代表一次独立的 API 任务。如果字段没设计好后面写 prompt 逻辑会比较别扭。4. 安装部署与启动方式这里给出两种启动路径一种用影刀 RPA 的图形化流程适合非程序员一种用 Python 脚本适合需要更精细控制批量任务和错误处理的场景。4.1 影刀 RPA 流程搭建安装影刀 RPA 后新建一个自动化流程包含以下组件读取 Excel 数据遍历输入表格每一行。检查缓存如果该行已经生成过结果直接跳过。调用 DeepSeek API通过“发送 HTTP 请求”组件把 prompt 拼好并 POST 给 API。解析响应从 JSON 返回里提取需要的内容字段。写入结果把返回值写到 Excel 对应单元格或新文件。异常重试请求失败时等待几秒后重试连续失败则记录日志并跳过。影刀 RPA 的 HTTP 请求组件可以直接指定 JSON body使用流程变量填充 prompt。这个路径适合不需要写代码、主要操作 Excel 和网页的用户。4.2 Python 脚本启动如果你更习惯代码方式可以用 Python requests 实现同样的批量流程。import csv import json import os import time import requests from pathlib import Path API_URL https://api.deepseek.com/chat/completions # 实际地址以官方文档为准 API_KEY os.environ.get(DEEPSEEK_API_KEY) HEADERS { Authorization: fBearer {API_KEY}, Content-Type: application/json } SYSTEM_PROMPT 你是一名电商文案助手只输出文案正文不要输出额外解释。 def generate_copy(title: str, keywords: str, platform: str, length: int) - str: user_content ( f商品名称{title}\n f卖点关键词{keywords}\n f目标平台{platform}\n f字数要求{length}字\n\n f请基于以上信息生成一条完整文案。 ) payload { model: deepseek-chat, messages: [ {role: system, content: SYSTEM_PROMPT}, {role: user, content: user_content} ], temperature: 0.9, max_tokens: 2048 } response requests.post(API_URL, headersHEADERS, jsonpayload, timeout120) response.raise_for_status() data response.json() return data[choices][0][message][content] def main(): input_file Path(input/tasks.csv) cache_file Path(cache/done.txt) output_file Path(output/results.csv) done_ids set() if cache_file.exists(): done_ids set(cache_file.read_text(encodingutf-8).splitlines()) results [] with open(input_file, encodingutf-8) as f: reader csv.DictReader(f) for row in reader: task_id row[id] if task_id in done_ids: print(f[跳过] {task_id} 已处理) continue for attempt in range(3): try: content generate_copy( titlerow[title], keywordsrow[keywords], platformrow[platform], lengthint(row[length]) ) results.append({ id: task_id, title: row[title], output: content }) with open(cache_file, a, encodingutf-8) as cf: cf.write(task_id \n) print(f[完成] {task_id}) break except Exception as e: print(f[失败] {task_id} 第{attempt 1}次: {e}) time.sleep(5) else: print(f[跳过] {task_id} 连续失败进入日志)这个脚本的核心逻辑是读取任务清单、跳过已完成、最多重试 3 次、把已完成任务 ID 写入缓存文件。即使中途断掉重新执行也会从断点继续不会重复计费。5. 功能测试与效果验证搭建完流程后不要直接跑全量数据。先用 3 到 5 条任务做小批量验证确认 prompt 效果和 token 消耗符合预期再放开全量。5.1 基础生成能力测试测试目的确认 API 能正常响应、返回字段解析正确。操作步骤准备一条 200 字以内的简单任务。手动调用一次 API查看返回内容。检查返回 JSON 里是否有choices[0].message.content字段。预期结果HTTP 200 状态码。返回内容包含完整文案而不是报错信息。响应时间在 30 秒以内。判断标准返回内容可读、无截断、无格式错乱、没有出现标题和正文混杂。5.2 批量任务缓存验证测试目的验证缓存逻辑能否避免重复消耗。操作步骤用 5 条任务跑第一轮记录输入 token 总和。不删除缓存文件重跑同一批任务。观察控制台是否打印[跳过]以及是否产生新的 API 请求。预期结果第二轮没有新请求日志中 5 条全部跳过。判断标准如果第二轮产生了相同请求说明缓存键值设置有问题需要检查是否用了唯一 ID 作为缓存依据。5.3 失败重试验证测试目的确认网络抖动或接口报错时任务不会被永久卡住。操作步骤故意把 API_URL 改成一个不存在的地址。跑 1 条任务。观察重试日志。预期结果脚本连续重试 3 次每次间隔 5 秒最后记录为失败并继续下一条任务而不是整个进程崩溃。判断标准日志中有明确的失败次数和最终跳过标记。5.4 输出质量对比测试目的验证 prompt 结构是否稳定是否因为上下文裁剪导致输出变差。操作步骤同一批输入分别用完整上下文 prompt 和精简 prompt 各跑一次。对比输出结果质量。预期结果精简 prompt 的输出在信息完整性上没有明显下降但输入 token 显著减少。判断标准如果精简后输出经常丢失关键卖点说明 prompt 里该保留的约束没有保留需要调整而不是简单删内容。6. 接口 API 调用与 token 成本控制DeepSeek API 调用本身是一个标准的 OpenAI 兼容接口但成本控制的关键在请求设计上。6.1 请求参数设计示例报文{ model: deepseek-chat, messages: [ { role: system, content: 你只负责写文案不回答其他问题。 }, { role: user, content: 商品保温杯卖点保温12小时、便携、304不锈钢字数150。 } ], temperature: 0.8, max_tokens: 1024, stream: false }控制 token 消耗的六个策略精简 system prompt不要把规则写成长篇小说。能放进代码的条件判断就不要让模型处理。每次请求只发送当条任务需要的最低上下文。相同前缀的模板内容在代码里拼接而不是让模型翻找。设置合理的max_tokens避免模型自由发挥输出超长废话。相同结果不重复调用用缓存文件或数据库记录 task_id。固定不变的参考内容不要写进每个 prompt可以在模型输出后用代码做二次校验。6.2 Python 调用示例import requests url https://api.deepseek.com/chat/completions # 以官方文档为准 payload { model: deepseek-chat, messages: [ {role: system, content: 你是日报生成助手只输出要点。}, {role: user, content: 今日事项开会、写文档、修bug。请生成3条日报要点。} ], temperature: 0.6, max_tokens: 512 } headers { Authorization: Bearer YOUR_API_KEY, Content-Type: application/json } response requests.post(url, headersheaders, jsonpayload, timeout60) data response.json() print(data[choices][0][message][content])6.3 批量任务队列设计批量任务的目录结构可以参考deepseek_rpa/ ├── input/ │ ├── tasks.csv │ └── source_files/ ├── output/ │ ├── results.csv │ └── generated_texts/ ├── cache/ │ └── done.txt ├── logs/ │ └── error.log └── run_flow.py批量任务运行建议每执行一条任务立即写缓存不要等全部跑完再写。日志要包含任务 ID、开始时间、结束时间、HTTP 状态码、token 用量。连续失败超过 3 次的自动放入错误清单等人工处理。批量数量大时在两条请求之间加 1 到 2 秒延迟避免触发限流。6.4 RPA 结合 API 的典型流程RPA 在真实业务里往往要处理“登录网页、读取表格、下载文件、填写表单”这些大模型做不了的操作。一个完整的 RPA 流程可能是RPA 打开业务系统登录。按日期范围筛选订单列表。把每一条订单的备注、金额、客户名称读入 Excel。对每一行调用 DeepSeek API生成个性化工单备注。将生成结果写回系统表单。页面翻页重复执行直到全部完成。这种场景里RPA 省掉的是“人一次次复制粘贴到对话框再复制回来”的重复时间DeepSeek 只负责生成文本不做网页操作。两者分工明确。7. 资源占用与性能观察这套组合是轻量本地部署只需要关注网络、内存和磁盘占用。7.1 内存与 CPU 占用RPA 工具运行时一般在几百 MB 内存量级Python 脚本相对更轻几十 MB 就能跑。整个过程不涉及大模型本地推理所以没有 GPU 压力。这里说的量级是常见水平具体以你安装的 RPA 版本和脚本复杂度为准。7.2 API 响应时间响应时间主要取决于输入 prompt 长度和max_tokens设置。几十字输入几百字输出通常在几秒到十几秒之间。如果响应时间突然涨到 1 分钟以上不要盲目加大超时时间先检查是不是输入了超长文本模型需要更多时间处理。是不是网络到 API 服务端延迟升高。是不是max_tokens设置过大模型输出超长。7.3 如何观察 token 消耗在 Python 脚本中添加 token 用量输出print(prompt_tokens:, data[usage][prompt_tokens]) print(completion_tokens:, data[usage][completion_tokens]) print(total_tokens:, data[usage][total_tokens])在 RPA 流程中则可以把返回 JSON 里的usage字段解析出来写入日志或统计表。批量任务跑完后汇总所有任务的 total_tokens就能估算本轮运行的实际开销。7.4 如何降低消耗给每条任务设置字数上限输出截断比想象中常见。对长文章做分段处理而不是一次性让模型读完全部再改写。能合并的任务合并成一个请求比如把 5 个短问题放进一条 prompt让模型分条返回。建立结果复用机制同一个输入素材只让模型处理一次。这几种方法在一起使用通常能压掉一半以上不必要的输入 token。8. 常见问题与排查方法问题现象可能原因排查方式解决方案API 返回 401 或 403API Key 错误、权限不足检查环境变量和 Key 是否匹配重新生成 Key并把 Key 放到环境变量读取请求超时网络不稳定或参数过大查看错误日志确认超时时间增加 timeout或缩小单次任务规模返回内容为空max_tokens 太小模型输出被截断查看 completion_tokens 是否等于 max_tokens增大 max_tokens或裁剪 system prompt批量任务中途停止RPA 页面元素定位失败查看 RPA 日志和截图调整页面选择器增加异常重试同一任务反复计费缓存逻辑失效或没有写缓存检查 cache 文件路径和 task_id 唯一性确保成功结束立即写缓存文件Excel 读取乱码编码格式不支持检查文件编码Excel 另存为 UTF-8 CSV或先转编码并发请求被限流请求间隔过短查看 HTTP 429 状态码增加请求间隔限制并发数输出质量不稳定prompt 约束不足或 temperature 过高固定 model 和 temperature多测几条把 temperature 降到 0.6 左右并完善 system prompt这里显存问题不存在因为所有推理都在 API 服务端完成本地不做模型推理。如果你的电脑性能很差只需要确保浏览器、RPA、脚本同时跑时不卡顿。9. 最佳实践与使用建议9.1 流程设计原则第一次跑通之前不要追求“全自动无人值守”。先把单条任务从读取到写回全部打通再叠加定时触发和批量循环。每次只改一个变量比如先观察 prompt 效果再调缓存逻辑最后加失败重试。给每条任务设置唯一 task_id。这个 ID 既是缓存键也是日志索引还是重试判断依据。没有唯一 ID批量任务就没法做断点续跑。9.2 数据与输出管理输入、输出、缓存、日志分开目录存放不要全部堆积在一个文件夹。批量跑完之后把结果和 token 用量统计一起归档方便复盘成本。9.3 合规与安全调用 API 前确认业务场景符合平台服务条款。涉及客户数据、公司内部文档、个人隐私信息时必须先在本地做脱敏处理。批量生成内容发布前要做人工复核尤其涉及事实性表述、数据引用、代运营发布时。API Key 只放在受控环境中不要提交到代码仓库、发给他人或在日志里明文打印。如果 RPA 操作的是第三方系统比如自动登录、采集、回填必须确认有合法授权遵守平台规则不得用于绕过访问限制、批量抓取受限数据或任何破坏系统正常秩序的用途。使用 DeepSeek 生成的内容在法律和平台允许范围内可以继续使用但涉及知识产权的部分要保留判断。9.4 成本预算思路不要只在月初看一眼接口账单。更好的做法是每跑完一批任务就统计 total_tokens 和对应任务数量得到单任务平均消耗。然后根据未来业务量估算月消耗做到心里有数。比如 1000 条文案任务每条任务平均消耗 1500 token那一轮批量任务就是 150 万 token成本可以直接按接口定价算出来。如果单任务平均消耗异常偏高大概率不是模型涨价而是 prompt 设计有问题优先检查是不是塞了太多不必要内容。10. 总结与下一步DeepSeek 这类大模型 API 的价格调整是不可控的但 token 消耗的多少却可以通过流程设计来控制。RPA 在这里最大的价值不是“替代 AI”而是把 AI 从一个被反复调用的“临时工”变成一个按需取用的“专属服务”。重复的搬运、判断、重试、记录交给 RPA模型只做理解和生成成本自然降下来。刚开始实践时先做一个最小的流程用 RPA 读 Excel、调 API、写结果、断点续跑。跑通之后再加定时触发、页面操作、多轮处理。最容易踩的坑主要集中在三处一是 prompt 里塞了太多不必要上下文二是缓存没做好导致重复调用三是批量失败后没有重试和审计机制。这三处解决掉这套方案基本就稳定了。后续可以继续扩展的方向很多给 RPA 流程加一个 web 管理面板把批量任务提交变成网页按钮接入消息推送任务跑完发通知把缓存升级成数据库支持更复杂的去重和复用甚至可以把 DeepSeek 生成的文本自动导入到 CMS 系统做成一条从采集到发布的完整内容流水线。建议先保存这篇文章等下一次你要批量处理文本类任务时再回来对照搭流程。
