DeepSeek API 的调用成本最近又被大家盯上了。关于价格调整的讨论很多有人说涨幅夸张有人说要看具体模型和时段。不管最终价格表怎么变一个更值得思考的问题是你的 token 到底花在了哪里不少开发者和运营团队把 DeepSeek 接进业务流程后发现 token 消耗速度远超预期。仔细一查大量请求都花在重复性操作上——把同一份表格反复清洗、把同样格式的日报反复生成、把同一个网页的数据反复抓取。这些流程根本不是“智能推理”而是“机械劳动”。用大模型做机械劳动等于拿跑车送快递。这篇文章想聊一个更省钱的组合思路重复流程交给 RPA 自动跑只有需要判断和生成的地方才调用 DeepSeek从源头减少 token 消耗。文章会拆解 token 计费的基本逻辑对比 AI 处理和规则化自动化的边界给出可直接复用的 DeepSeek API 调用示例和 RPA 落地思路最后补充常见的 token 报错排查与工程建议。读完你可以回答三个问题你的项目里哪些流程在白白烧 token哪些流程可以用 RPA 替代如果仍然需要调用大模型如何让每一万个 token 都花在刀刃上1. 先从成本焦虑说起重复流程是 token 消耗的大头很多人对 token 的感知是抽象的直到收到账单才意识到问题。一次 API 调用的费用不高但业务流程是 7×24 小时跑的。假设你的脚本每 5 分钟调用一次接口处理新数据每次消耗 2000 token一天就是 57.6 万 token。这还没算上下文增长、失败重试、日志打印带来的额外开销。更隐蔽的是很多重复任务根本不需要“智能”。比如把 Excel 里的日期列统一改成YYYY-MM-DD格式。从每篇公众号文章的标题中提取关键词写入数据库。定时把某个目录下的 PDF 文件名整理成清单。在后台系统里把订单状态从“待审核”改为“已发货”。这类任务的特点是规则明确、流程固定、输入输出结构清晰。用大模型来处理本质上是让模型猜你想要的规则还要为每一次猜测支付 token 费用。而 RPA 或传统脚本处理这类任务一次开发永远免费执行。这就是本文的核心判断AI 的成本优势在“非标准化判断”RPA 的成本优势在“标准化执行”。把后者硬塞给前者才是涨价焦虑的真正来源。1.1 什么样的业务在烧 token业务类型典型例子适合 AI 吗适合 RPA/脚本吗文本生成写周报、写营销文案、生成代码注释适合不适合信息抽取从非结构化文本提取实体、摘要适合视规则复杂度而定分类判断判断用户反馈是投诉还是咨询适合若关键词规则可覆盖则适合数据搬运从一个系统复制到另一个系统不适合非常适合文件处理批量重命名、格式转换不适合非常适合规则校验检查必填字段、格式错误不适合非常适合这个表格不是绝对的。比如信息抽取如果文本格式足够规律用正则表达式就能解决如果文本千奇百怪才需要大模型兜底。判断标准只有一个这个任务的结果是否高度依赖于理解上下文。1.2 先问自己三个问题在把任何流程接入 DeepSeek 之前可以先问三个问题这个流程每次处理的输入结构是不是基本一致的期望的输出是不是可以预先定义出明确的规则如果换了人来做是不是只需要熟练工而不需要专家如果三个问题都是“是”那么这个流程大概率不需要大模型。2. token 与 RPA把两个基本概念讲透2.1 token 到底是什么token 是模型处理文本的最小单位。可以粗略理解为“字”或“词”的切分片段但两者并不完全相等。英文中一个 token 通常是一个子词中文中一个 token 可能对应一个字到一个词。不同的分词器规则不同同一段文本在不同模型下的 token 数量也会有差异。在 API 调用中token 消耗分两部分输入 token和输出 token。输入包含你的系统提示词、历史对话、当前问题输出是模型生成的回复。大多数模型的计费方式是两端都收钱而且输出 token 的单价通常高于输入 token。重复流程烧 token 的典型原因有三个提示词过长。每次调用都带着一大段系统提示词和历史记录而这些内容每次都是重复的。没有错误处理。模型偶尔返回格式错误脚本只能重新调用上一次的 token 就白花了。不需要 AI 的任务也调了 AI。比如一个简单的字段拼接也要让模型帮你做。2.2 RPA 是什么RPARobotic Process Automation机器人流程自动化是一类软件工具通过模拟人在电脑上的操作把重复、规则明确的业务流程自动化。常见的 RPA 工具包括影刀 RPA、UiPath、Blue Prism 等也包括你用 Python 写的自动化脚本。RPA 的核心能力有三个界面操作、数据处理、流程编排。它可以打开网页、点击按钮、填写表单、读取 Excel、调用接口、发送消息。很多人以为 RPA 需要写大量代码其实现代 RPA 工具已经提供了图形化编排界面。你可以在画布上拖拽“打开网页”“读取表格”“填写输入框”等组件然后串联起来。但这不代表 RPA 不需要编程思维。你仍然需要理解变量、循环、条件判断、异常处理这些基本概念。好消息是这些概念比学习大模型提示词更稳定——今天的 RPA 组件两年后大概率还能用今天精心调教的提示词模型一升级可能就失效了。2.3 两者的关系不是替代而是分层用一句话概括RPA 负责“手”AI 负责“脑”。一个稳定的自动化流程应该让 RPA 处理所有确定性的操作只把真正需要理解、判断、生成的部分交给 AI。举个例子。一个订单审核流程RPA 从邮件附件下载 Excel。RPA 逐行读取订单先按金额和地区做规则判断。金额小于 1000 且地区无异常的订单直接通过。只有规则判断“拿不准”的订单才调用 DeepSeek 生成审核意见。RPA 把审核结果写回 Excel再发送通知邮件。这个流程中DeepSeek 只处理少量异常订单token 消耗可能只有全量 AI 处理的 5% 到 20%。3. 场景拆解哪些流程应该先用 RPA 替代3.1 表格与数据清洗市面上的表格清洗任务绝大多数用 Pandas 或者 Excel 公式就能完成。比如去除空格、统一日期格式、替换特定文本。按条件筛选行、去重、排序。多表关联合并。这些操作如果用 DeepSeek API 处理你需要把整个表格内容塞进提示词再让模型输出处理后的表格。表格稍微大一点token 消耗立刻飙升而且模型的输出格式不一定稳定你还得写解析逻辑。正确的方案是用代码或 RPA 直接处理表格只有“清洗规则本身”需要推理时才考虑 AI。比如你不知道某列数据应该统一成什么格式可以让 AI 看一小段样本提出规则然后你把这个规则固化到代码里。3.2 网页数据采集用 RPA 做网页数据采集是很多团队的实际需求。RPA 可以打开目标网页、滚动页面、点击翻页、提取字段、保存数据。这里要注意平台规则和使用边界。采集公开数据需要在合规范围内进行并遵守目标网站的 robots 协议、服务条款和访问频率限制。RPA 工具本身只是自动化操作没有好坏之分但操作者必须对使用方式负责。高频访问、绕过登录限制、抓取非公开数据都是不合适的。一个稳妥的做法是对公开页面控制请求间隔模拟正常用户节奏对需要登录的业务系统确保自己拥有合法账号和授权对不确定的采集行为先咨询法务或参考网站官方 API。3.3 系统间的数据搬运企业内部经常有多个系统ERP、CRM、财务系统、OA。数据要在系统之间流转而很多系统没有对外 API或者 API 权限申请流程漫长。这时 RPA 的价值就体现出来了从 A 系统界面读取数据填写到 B 系统界面。这类流程稳定、重复、价值明确是完全不依赖大模型的典型场景。唯一的风险是界面改版会导致 RPA 组件失效所以需要维护一个“界面选择器”的修复机制。3.4 定时任务与批量处理每天早上生成报表、每小时同步一次数据、每周清理临时文件——这些任务用系统的定时任务或 RPA 的定时触发功能就能完成。搭配通知机制比如发送到钉钉、企业微信或邮件。4. DeepSeek API 调用示例从源头控制 token 消耗如果你确认某些环节确实需要 AI接下来的问题是如何把 token 消耗降到最低。下面以 Python 为例演示一个相对克制的 DeepSeek API 调用方式。4.1 最基本的一次调用# 文件路径deepseek_demo.py from openai import OpenAI client OpenAI( api_key你的 API Key, base_urlhttps://api.deepseek.com ) def ask_deepseek(prompt, system_promptNone): messages [] if system_prompt: messages.append({role: system, content: system_prompt}) messages.append({role: user, content: prompt}) resp client.chat.completions.create( modeldeepseek-chat, messagesmessages, max_tokens500, temperature0.3 ) return resp.choices[0].message.content if __name__ __main__: result ask_deepseek( system_prompt你是一个简洁的文本分类助手只输出分类结果。, prompt请将这句话分类为咨询、投诉、建议。\n\n句子你们家的物流太慢了三天没收到货。 ) print(result)这段代码有几点值得注意base_url指向 DeepSeek 的兼容接口地址。这里使用了 OpenAI SDK 的兼容模式方便迁移。具体地址和参数以官方最新文档为准。max_tokens500限制输出长度避免模型自由发挥产生大量无意义内容。temperature0.3让输出更稳定短分类任务不需要创造性。每次调用只包含必要的 system 和 user 消息不携带历史对话。4.2 控制上下文的几种方式在真实项目中一个常见错误是把所有历史消息都传给模型。如果每次调用都带 30 条历史消息token 消耗会成倍增长。方式一只传最近 N 条消息def ask_with_recent_history(new_prompt, history, system_prompt, max_history6): messages [] if system_prompt: messages.append({role: system, content: system_prompt}) # 只取最近 max_history 条历史记录 messages.extend(history[-max_history:]) messages.append({role: user, content: new_prompt}) # 调用逻辑省略方式二先做摘要再传上下文如果历史信息必须全部保留可以把旧的对话先交给模型做摘要只把摘要和新问题一起传入。这种方法本文不展开代码但要明白一个原则模型不需要看到原始细节只需要看到与当前任务相关的结论。方式三结构化提示词减少冗余描述把 prompt 从一段话改成结构化字段既清晰又省 token。# 不太省 token 的写法 prompt 请帮我看看这句话然后判断它属于哪一类如果是投诉就写投诉如果是咨询就写咨询你们家的物流太慢了 # 相对省 token 的写法 prompt 分类以下文本为【咨询/投诉/建议】你们家的物流太慢了4.3 用缓存和批处理降低调用频率如果同样的请求会反复出现可以用一个简单的字典缓存结果# 文件路径token_cache_demo.py from functools import lru_cache lru_cache(maxsize200) def classify_cached(text: str) - str: # 这里调用上面的 ask_deepseek省略细节 return ask_deepseek( system_prompt只输出投诉/咨询/建议三个词之一。, promptf分类{text} ) # 同样的文本只会在第一次调用 API后续都走缓存 print(classify_cached(你们家的物流太慢了)) print(classify_cached(你们家的物流太慢了))更进一步可以把不同批次的文本合并到一次请求中def classify_batch(texts): prompt 对以下每条文本分类逐条输出结果\n for i, t in enumerate(texts, 1): prompt f{i}. {t}\n result ask_deepseek( system_prompt每条一行输出格式序号 类别, promptprompt, max_tokens200 ) return result批处理可以节省重复的请求开销但要注意输出长度限制不要一次塞太多文本。如果文本量很大建议每条单独调用或用本地分类模型。5. RPA 落地以影刀 RPA 为例的自动化流程先说明一点RPA 工具的版本和界面更新很快下面用影刀 RPA 作为示例重点讲通用流程设计思路具体组件名称以你安装的版本为准。如果你用的是 UiPath 或其他工具思路同样适用。5.1 RPA 能做什么一个日报生成的例子假设每天需要完成这样的工作打开销售后台导出前一天的订单明细。计算各地区的销售金额汇总。把汇总数据填入日报模板。把日报发送到工作群。传统做法是人工完成每天大约花 10 到 15 分钟。用 RPA 可以把流程串联起来每天定时自动执行。流程拆解如下定时触发器每天 08:30 启动。打开后台网页输入账号密码登录。点击“订单导出”等待文件下载完成。读取 Excel按地区分组汇总。打开日报模板填入汇总数据。调用企业微信或钉钉机器人接口发送日报。这里完全没有调用大模型token 消耗为零。5.2 RPA 与代码的分工RPA 适合处理“界面操作”但如果只是处理本地文件直接用 Python 脚本可能更轻量。一个实用的原则是需要操作网页、桌面软件、Excel 界面 → 用 RPA。只需要在本地处理文件、调用 API、写数据库 → 用 Python。很多 RPA 工具支持在流程中调用 Python 脚本所以最舒服的姿势是RPA 负责获取界面数据Python 负责数据处理接口负责系统集成。5.3 一个结合了调用的 RPA 流程设计看一个需要 AI 参与的流程。比如运营团队需要从客户反馈中提取产品改进建议RPA 读取“反馈汇总.xlsx”中的新增记录。对每条记录做关键词预判如果包含“卡顿”“闪退”“报错”直接归类为“缺陷”。预判无法确定的记录调用 DeepSeek 做文本分类。RPA 把结果写回 Excel并生成统计表格。这个设计的核心是“规则先行AI 兜底”。大多数反馈可以用关键词命中真正需要模型判断的只是少数复杂表达。6. 混合架构的核心规则过滤 RPA 调度 AI 兜底6.1 三层架构一个适合中小团队落地的混合架构可以是第一层规则层代码/RPA 内置条件 - 正则表达式、关键词匹配、阈值判断 - 成本0 token 第二层调度层RPA 或任务队列 - 控制流程顺序、重试、异常处理 - 成本0 token 第三层AI 层DeepSeek API - 语义理解、文本生成、复杂分类 - 成本按真实业务量计算设计目标是让 80% 以上的请求在第一层就被消化AI 只处理剩余 20% 甚至更少的请求。6.2 用代码实现一个规则过滤器下面是一个简单的示例先做规则过滤再决定是否调用 AI。# 文件路径hybrid_classifier.py import re def rule_filter(text: str): 返回处理结果或 None表示需要 AI 兜底 text text.strip() if any(word in text for word in [卡顿, 闪退, 崩溃, 无响应]): return 缺陷 if any(word in text for word in [太慢, 打不开, 一直转圈]): return 性能问题 if re.search(r建议|希望|能不能, text): return 需求建议 return None # 规则无法确定 def classify(text: str): result rule_filter(text) if result: return result, rule # 规则兜不住再调用 AI ai_result ask_deepseek( system_prompt将反馈分类为缺陷/性能问题/需求建议/其他只输出类别。, promptf反馈内容{text} ) return ai_result, ai # 测试 samples [ 新版本经常卡顿很影响体验, 希望支持深色模式, 订单页加载一直转圈, ] for s in samples: result, source classify(s) print(f{s} - {result} ({source}))这是能直接跑通的最小示例。实际项目中还可以把规则配置到字典或数据库里方便业务人员维护。6.3 用 RPA 编排整个流程在 RPA 工具中流程往往由多个模块组成“读取数据”模块从 Excel 或数据库读取待处理记录。“规则判断”模块调用本地代码或内置条件判断。“AI 处理”模块调用 HTTP 接口请求 DeepSeek。“回写数据”模块把结果写回表格。“异常通知”模块失败时发送告警。RPA 的异常处理也重要。如果 AI 接口偶发失败不应该直接让整个流程崩溃而是把失败记录单独标记稍后重试。7. 运行结果与效果验证7.1 如何判断优化是否有效验证 token 优化效果不能只看感觉需要建立三个指标API 调用次数每天实际发起了多少次请求。总 token 消耗在 DeepSeek 控制台查看每日用量。任务完成率自动化流程成功处理了多少条数据有多少条需要人工介入。建议先跑一周纯规则方案的基线数据再启动 AI 兜底方案对比两类指标。7.2 预期对比假设原来所有反馈都调用 AI 分类每天处理 2000 条反馈。每条平均消耗 300 输入 token 30 输出 token。日均约 66 万 token。加入规则过滤后假设 80% 的记录被关键词命中只有 20% 的记录调用 AI即 400 条。日均约 13.2 万 token。加入缓存后如果 20% 的 AI 请求是重复文本日均约 10.6 万 token。这些数值是估算不同业务差异很大但比例关系基本符合经验。优化空间通常不是百分之十而是数倍。7.3 运行日志与监控在实际项目中建议给每条处理记录添加来源标记rule还是ai。这样可以统计规则命中率发现规则漏判较多时及时补充规则。日志格式参考{ timestamp: 2025-01-10T09:30:00, text_id: 12345, source: rule, result: 缺陷, token_cost: 0, elapsed_ms: 3 }如果source字段为ai记录中还要包含模型的usage字段方便按天聚合 token 消耗。8. 常见问题与排查思路8.1 DeepSeek API 与 token 相关报错问题现象可能原因排查方式解决方案调用时报token exchange failed认证或网络链路异常token 换取失败查看服务端错误日志确认请求 URL 和网络链路检查 API Key 是否正确、网络是否可达、代理或防火墙策略是否放行提示token endpoint returned 403 forbidden请求被服务端拒绝常见原因是地区限制或权限不足核对账号权限、地区策略、请求头信息确认账号地区是否在服务范围内参考官方文档调整配置提示access token could not be refreshed本地保存的登录态过期refresh token 失效重新登录检查刷新逻辑重建登录态必要时手动重新获取 API Keytoken 消耗比预期高上下文太长、失败重试、批处理不足在控制台查看调用明细和输入输出 token 分布精简提示词、限制 max_tokens、启用缓存和批处理模型输出格式不稳定prompt 描述不清晰或 temperature 设置过高检查返回内容和日志结构化 prompt降低 temperature增加输出格式约束需要特别提醒的是token exchange failed这类报错通常发生在“身份认证”环节而不是模型推理环节。看到这个错误时第一反应不该是调 prompt而是检查认证配置和网络链路。8.2 RPA 流程常见问题问题现象可能原因排查方式解决方案RPA 点击失效页面改版、元素选择器失效查看选择器错误提示在 RPA 工具中重新拾取元素更新选择器尽量使用稳定的属性如 id 或 data 字段表格变量取值错误列名或索引不对在流程中增加日志输出查看读取结果使用列名定位避免硬编码列号运行到一半卡住网络等待、弹窗遮挡检查超时设置观察屏幕画面增加超时重试配置弹窗关闭逻辑数据量过大导致时间太长串行处理每条记录查看执行日志耗时分布考虑分批并行或改用 Python 脚本做数据预处理8.3 如何排查 token 消耗异常第一步去 DeepSeek 控制台查看当天的调用次数和 token 用量。第二步在代码中打印每次调用的usage字段定位是哪些请求消耗最大。# 打印 usage 示例 resp client.chat.completions.create( modeldeepseek-chat, messagesmessages, max_tokens500 ) usage resp.usage print(fprompt_tokens{usage.prompt_tokens}, completion_tokens{usage.completion_tokens}, total_tokens{usage.total_tokens})第三步分析请求日志看有没有重复调用、超长上下文、失败重试。通常问题在第二步就暴露了。9. 最佳实践与工程建议9.1 Token 预算先于代码接入 DeepSeek API 之前先给业务定一个 token 预算。比如每天最多消耗多少 token、单个请求最多多少 token、异常时是否需要熔断。预算不是上限而是成本意识的起点。9.2 提示词即配置把提示词和系统配置放在同一个配置文件中而不是散落在代码里。这样升级提示词时不需要重新发版。# 文件路径prompts.properties classify.system你是一个文本分类助手只输出类别。 classify.user分类以下文本为【咨询/投诉/建议】{text} summarize.system你是一个摘要助手输出不超过50字的摘要。在代码中读取这些配置既可以统一管理也能方便做 A/B 测试。9.3 规则优先模型兜底规则和大模型不是二选一而是先后关系。先写关键词、正则、阈值判断再让 AI 处理规则覆盖不到的情况。把这个原则落实到代码结构上就是规则函数和 AI 函数的分层。9.4 不要把所有数据都塞进上下文很多人在调用模型时习惯把整张表的数据拼进 prompt。这是 token 爆炸最常见的原因。正确做法是先本地筛选出关键字段再传入模型或者把长文本切分成 chunk逐个处理。9.5 RPA 流程的健壮性RPA 流程上线后要注意三点定时任务要有异常告警否则流程悄悄失败业务方第二天才发现。文件路径和系统环境尽量稳定避免因为路径变化导致流程中断。涉及登录态的流程要设计“登录失败自动通知”的节点而不是一直重试。9.6 安全与权限边界如果 RPA 处理的业务系统涉及账号密码不建议把密码明文写在脚本或组件里。可以使用操作系统的凭据管理器、环境变量或专用的密钥管理服务。权限遵循最小化原则RPA 用的账号只要能完成指定操作即可不要给管理员权限。在数据处理方面如果流程涉及用户隐私或企业敏感数据要提前确认数据保存、传输、脱敏的合规要求。自动化不会改变数据的敏感属性只会放大处理速度。10. 总结与后续学习方向回到最初的问题DeepSeek 调用成本高到底是因为模型涨价还是因为你用错了场景从技术角度看更常见的答案是后者。token 是宝贵的计算资源只应该花在真正需要语义理解的地方。重复性、规则明确的流程适合用 RPA 或脚本自动执行真正需要判断的文本处理再接入 DeepSeek。一个健康的架构是让规则层消化大部分请求RPA 负责调度和操作AI 只做关键判断。下一步可以从一个小流程开始实践找一个每天重复操作 10 分钟以上的任务先把它拆成 RPA 和 AI 两步用规则过滤看看能拦截多少请求。注意不要一开始就追求大而全的自动化平台先把一条流程跑通再把经验复制到其他场景。如果你已经在使用 DeepSeek API建议先打印一次调用的 usage 字段看看单次请求的 token 分布再统计一天的调用日志。这个动作本身不耗费多少时间但对成本优化很关键。建议先收藏这篇文章中的代码示例和排查表下次接到重复流程时先想想这个需求需要模型推理还是只需要规则执行答案不同成本可以相差数倍。
