DeepSeek API Token 成本飙升？用 RPA 把重复流程从 AI 调用中剥离

DeepSeek API 的 token 价格调整最近成了不少开发者群里讨论最多的话题之一。有人晒出账单发现成本翻了几倍有人开始怀疑是不是自己的调用姿势有问题还有人已经在琢磨要不要换模型。但从我接触到的项目情况看真正的开销大头往往不是“该用 AI 的地方用多了”而是大量 token 被浪费在了完全不需要智能的重复流程上。也就是说重复流程用 RPA 自动跑才是更直接的省钱思路。本文会先拆解 DeepSeek 这类大模型 API 的 token 消耗模型再讲清楚 RPA 与 AI 的边界最后给出一个完整可落地的方案用 Python 实现轻量 RPA把固定操作从 AI 调用中剥离让大模型只处理真正需要语义理解的部分。读完你应该能自己定位出项目中“烧 token”的环节并做一次可量化的成本优化。1. 涨价背后开发者真正该算的是一笔 token 账DeepSeek API 的价格调整官方文档在不同时间点有过变更。从公开反馈和社区讨论看部分场景的涨幅确实可能达到 350% 量级尤其是长上下文、高并发、多轮对话这类调用。这里不讨论具体价格数字因为模型版本、计费区间、缓存命中与否都会影响最终单价。更值得关注的是你的 token 消耗速度是否匹配真实的业务价值。以我见过的一个客服工单分类项目为例。团队每天调用 DeepSeek 处理约 2 万条工单每条工单平均 600 字加上系统提示词、历史记录、输出模板单次调用约消耗 1500 到 2000 token。听起来不多但一天就是 3000 万到 4000 万 token。涨价之后月成本直接增加了十几万。可实际看一下工单分类这个任务80% 的工单根本不需要深度理解关键词匹配加规则引擎就能分对。真正需要大模型处理的只有那些语义模糊、包含长文本叙事、规则无法判断的长尾工单。这个现象在大量项目里都存在把 AI 当成万能执行器让大模型去处理本可以用脚本、定时任务、RPA 完成的固定步骤。AI 确实能做但它的成本结构决定了它只适合处理“非确定性”任务。所以面对 token 涨价第一个反应不应该是焦虑而是重新审视调用链哪些调用是在用大模型做重复劳动1.1 三类最容易烧 token 的场景模板化内容生成周报、日报、告警摘要、固定格式邮件。这些内容有明确结构用模板加变量渲染即可AI 参与只会增加 token。批量数据处理逐条调用 API 做格式转换、字段抽取、分类打标。数据量大时token 消耗成倍放大。多轮对话中反复回传历史每次接口调用都带着完整上下文历史越长单次 token 越高。这三种场景的共同特点是流程固定、输入规则明确、输出格式稳定。它们更适合交给 RPA 脚本去执行而不是每次都让大模型从头“思考”一遍。2. 理解两个概念API Token 与 RPA 自动化的边界2.1 token 到底是什么在 DeepSeek、OpenAI 这类大模型 API 中token 是模型处理文本的基本单位。它不等同于英文单词也不等同于中文字符。简单理解token 就是模型把一个句子切分后得到的最小片段。一段英文文本大致 0.75 个 token 对应一个单词中文场景下通常 1 个汉字可能对应 1 到 2 个 token。但这不是关键关键是 API 计费同时计算输入 token你发送给模型的全部文本包括系统提示词、用户问题、历史上下文、工具返回结果。输出 token模型生成的全部回复文本。所以一次看似简单的调用实际消耗 输入 token 输出 token。如果加上多轮对话中的历史累积输入 token 会成倍增长。这也是很多项目“感觉没调几次账单却很高”的主要原因。2.2 RPA 是什么RPARobotic Process Automation机器人流程自动化是一种通过模拟人在电脑上的操作来完成固定业务流程的技术。它不靠大模型理解语义而是靠规则、选择器、脚本和触发条件来执行任务。RPA 的典型能力包括模拟鼠标点击、键盘输入。读取和写入 Excel、CSV、数据库。调用 HTTP 接口。操作浏览器或桌面应用。根据条件分支执行不同流程。和 AI 调用相比RPA 的成本几乎可以忽略脚本写好后重复执行不产生额外费用速度更快结果更稳定。2.3 两者不是替代关系而是分工关系常规的项目做法是用 RPA 完成“确定性动作”用 AI 完成“非确定性判断”。维度AIDeepSeek APIRPA 脚本成本模型按 token 计费单次调用随输入输出量增长按运行次数计费主要消耗 CPU/内存适合任务语义理解、生成、总结、推理重复点击、录入、数据搬运、格式转换可变性同一输入可能输出不同结果同一输入永远输出相同结果稳定性受模型版本、上下文长度影响只受脚本逻辑和环境稳定性影响执行速度秒级到分钟级毫秒级到秒级一个常见的误区是RPA 还是太“重”只有企业级项目才用得上。实际上一个 Python 脚本 Playwright 或 Selenium就是轻量 RPA如果项目里已经用 Excel 处理数据那 Python openpyxl 也算半自动 RPA。关键是思维转变能让机器按规则跑完的流程就不要让大模型参与。3. 省钱的核心思路把“重复动作”从 AI 调用中剥离我们先对比两种架构。3.1 传统做法所有步骤都调 AI原始数据 - 用户输入 - AI 生成结果 - 写入系统在这种模式下每一行数据、每一次操作都可能触发一次 API 调用。上下文越长token 越多。对于每天几千条的数据量账单自然水涨船高。3.2 优化做法RPA 完成重复动作AI 只做决策原始数据 - 规则前置处理RPA/脚本截断、清洗、格式化 - 关键片段送入 AI - AI 输出结构化结果 - RPA 回填系统完成后续流程这里的核心变化是不再把整段原始数据原封不动地发给模型而是先用规则脚本做预处理只把真正需要语义理解的关键片段交给 AI再由 AI 返回结构化结果最后由脚本自动写入目标系统。举一个具体例子。某运营团队每天需要把几十条用户反馈整理成表格分类为“功能问题”“体验问题”“建议”并给出处理优先级。传统做法是把整条反馈发给 AI 分类优化后做法是用脚本先做规则匹配如果反馈中包含“闪退”“崩溃”“卡死”等关键词直接判定为高优先级功能问题无需 AI。只有规则无法命中的反馈才发送给 DeepSeek。AI 返回 JSON 格式的分类结果脚本解析后写回 Excel。这一步优化可能让 80% 的调用消失token 成本直接降到原来的五分之一以下。3.3 哪些流程适合改造哪些不适合适合改造的流程流程稳定重复执行频率高。输入输出格式固定有明确的判断规则。现有 AI 调用中大量 token 是系统提示词和上下文回传。不适合改造的流程开放域对话用户输入不可控。需要深度推理、创作、复杂指令遵循的任务。输入文本本身极短、调用量极低改造收益不大。判断标准也很简单如果删掉 AI 生成的环节剩下的工作能不能用 if/else、正则、模板、HTTP 请求完成能就把它从 AI 调用中挪走。4. 环境准备与工具选型下面用一个最小可运行项目来演示完整思路。项目目标将一批本地 Excel 中的用户反馈做分类并控制 token 消耗。4.1 工具与版本本文演示使用 Python 实现轻量 RPA原因很简单Python 可以同时处理 Excel 读取、HTTP 调用、浏览器操作和流程编排不依赖重型 RPA 平台。如果你所在团队已经使用影刀 RPA、UiPath 这类平台思路同样适用。建议环境Python 3.10 或更高版本。依赖库requests 或 openai SDK、openpyxl、python-dotenv。可选playwright用于模拟浏览器操作类流程。DeepSeek API Key接口地址和模型名称以官方文档为准。# 创建虚拟环境 python -m venv venv source venv/bin/activate # Windows 下为 venv\Scripts\activate # 安装依赖 pip install requests openpyxl python-dotenv playwright playwright install chromium4.2 项目结构project/ ├── .env ├── config.py ├── rpa_runner.py ├── ai_client.py ├── data/ │ ├── feedback_raw.xlsx │ └── feedback_result.xlsx └── logs/ └── token_usage.log4.3 配置文件# config.py import os from dotenv import load_dotenv load_dotenv() API_KEY os.getenv(DEEPSEEK_API_KEY) API_URL os.getenv(DEEPSEEK_API_URL, https://api.deepseek.com/chat/completions) MODEL os.getenv(DEEPSEEK_MODEL, deepseek-chat) INPUT_FILE data/feedback_raw.xlsx OUTPUT_FILE data/feedback_result.xlsx# .env DEEPSEEK_API_KEYyour_api_key_here DEEPSEEK_API_URLhttps://api.deepseek.com/chat/completions DEEPSEEK_MODELdeepseek-chat注意接口地址和模型名请以 DeepSeek 官方文档为准。实际项目里模型名称可能随版本更新例如 deepseek-chat 或 deepseek-reasoner请按自己的订阅权限填写。5. 核心流程拆解整个优化流程分为五步。5.1 统计基线 token 消耗先不要急着优化先搞清楚当前每个环节消耗多少 token。DeepSeek API 的响应中通常包含usage字段记录本次调用的prompt_tokens、completion_tokens和total_tokens。在每次调用的日志里记录这些数值。5.2 找出重复流程节点画出当前调用链标出哪些步骤是固定的。比如系统提示词是否每一轮都在重复传上下文窗口是否包含了大量无关历史是否存在“把整份文档发过去只为了让模型输出一个标题”的情况这些节点就是可以改造的候选。5.3 设计 RPA 前置处理编写脚本对输入数据做清洗和截断。规则包括关键词匹配、正则提取、长度截断、无关内容过滤。这一步之后需要发给 AI 的内容会显著变小。5.4 AI 只做语义决策设计尽量精简的系统提示词要求模型只返回结构化结果不做多余解释。使用 JSON 输出模式让后续解析更稳定。5.5 回填与校验脚本解析 AI 返回结果后写入 Excel 或目标系统并记录 token 消耗。可以加一个校验环节如果 AI 输出格式异常直接重试或标记人工审核而不是把错误数据写回。6. 完整示例与代码实现6.1 示例一记录 DeepSeek 调用与 token 日志# ai_client.py import json import time import requests from config import API_KEY, API_URL, MODEL def call_deepseek(system_prompt: str, user_content: str, max_tokens: int 512): 调用 DeepSeek API并记录 token 消耗。 返回 (result_text, usage_dict, ok_flag) headers { Authorization: fBearer {API_KEY}, Content-Type: application/json, } payload { model: MODEL, messages: [ {role: system, content: system_prompt}, {role: user, content: user_content}, ], max_tokens: max_tokens, temperature: 0.2, } start time.time() resp requests.post(API_URL, headersheaders, jsonpayload, timeout30) elapsed time.time() - start if resp.status_code ! 200: return , {}, False data resp.json() usage data.get(usage, {}) content data[choices][0][message][content] # 写入日志后续可用于分析成本 with open(logs/token_usage.log, a, encodingutf-8) as f: f.write(json.dumps({ time: time.strftime(%Y-%m-%d %H:%M:%S), prompt_tokens: usage.get(prompt_tokens, 0), completion_tokens: usage.get(completion_tokens, 0), total_tokens: usage.get(total_tokens, 0), elapsed_sec: round(elapsed, 2), }) \n) return content, usage, True这段代码的核心点是把usage落盘。只有拿到这些数据你才能量化优化效果否则一切节省成本的说法都是拍脑袋。6.2 示例二规则前置处理减少输入 token下面这段代码演示如何用规则把原始反馈“瘦身”只保留关键片段。# rpa_runner.py import re # 关键词规则映射 KEYWORD_RULES { 闪退: 功能问题, 崩溃: 功能问题, 卡死: 功能问题, 无法登录: 功能问题, 太贵: 建议, 希望: 建议, 体验差: 体验问题, 界面: 体验问题, 不好用: 体验问题, } def extract_key_sentence(text: str, max_len: int 120) - str: 截断文本去掉过长上下文只保留核心句子。 # 按句分割 sentences re.split(r[。!?], text) sentences [s.strip() for s in sentences if s.strip()] # 优先保留包含关键词的句子 for sent in sentences: if any(word in sent for word in KEYWORD_RULES.keys()): return sent[:max_len] # 没有关键词时取第一句和最后一句 result (sentences[0] if sentences else )[:max_len] if len(sentences) 1: result (。 sentences[-1])[:max_len] return result def classify_by_rule(text: str): 先用规则判断能判断的直接返回不需要调用 AI。 for keyword, category in KEYWORD_RULES.items(): if keyword in text: priority 高 if keyword in (闪退, 崩溃, 卡死, 无法登录) else 中 return {category: category, priority: priority, by: rule} return None这段代码的收益在于大部分简单反馈根本不会走到 API 调用这一步。即使最终必须调用 AI输入内容也只有 120 字以内的关键句而不是整段 600 字原文。输入 token 直接下降 60% 以上。6.3 示例三主流程AI 只处理规则无法判定的样本# main.py import json from openpyxl import load_workbook from ai_client import call_deepseek from rpa_runner import classify_by_rule, extract_key_sentence SYSTEM_PROMPT 你是一个用户反馈分类助手。请根据用户反馈内容输出 JSON 格式结果 {category: 功能问题|体验问题|建议, priority: 高|中|低, reason: 简短理由} 只输出 JSON不要输出其他内容。 def process_feedback(): wb load_workbook(data/feedback_raw.xlsx) ws wb.active result_wb load_workbook(data/feedback_result.xlsx) result_ws result_wb.active total_rows ws.max_row rule_hit 0 ai_called 0 # 从第 2 行开始读取 for row_idx in range(2, total_rows 1): raw_text ws.cell(rowrow_idx, column1).value if not raw_text: continue # 第一步规则判定 rule_result classify_by_rule(raw_text) if rule_result: rule_hit 1 final_result rule_result else: # 第二步截断文本后调 AI short_text extract_key_sentence(raw_text) ai_content, usage, ok call_deepseek(SYSTEM_PROMPT, short_text) ai_called 1 if not ok: final_result {category: 未知, priority: 低, reason: AI调用失败} else: try: final_result json.loads(ai_content) except json.JSONDecodeError: final_result {category: 未知, priority: 低, reason: AI输出解析失败} # 第三步写回结果表 result_ws.cell(rowrow_idx, column1, valueraw_text) result_ws.cell(rowrow_idx, column2, valuefinal_result.get(category)) result_ws.cell(rowrow_idx, column3, valuefinal_result.get(priority)) result_ws.cell(rowrow_idx, column4, valuefinal_result.get(reason)) result_ws.cell(rowrow_idx, column5, valuefinal_result.get(by, ai)) result_wb.save(data/feedback_result.xlsx) print(f总行数: {total_rows - 1}) print(f规则命中: {rule_hit}) print(fAI 调用: {ai_called}) print(fAI 调用占比: {ai_called / (total_rows - 1) * 100:.1f}%) if __name__ __main__: process_feedback()这段代码是整个项目的骨架。执行后控制台会输出 AI 调用占比。如果规则覆盖做得好AI 调用占比应该在 20% 以下token 成本随之大幅降低。6.4 示例四token 用量统计脚本最后给一个简单的统计脚本用来查看token_usage.log里的总消耗量。# analyze_tokens.py import json from collections import defaultdict total_prompt 0 total_completion 0 total_calls 0 with open(logs/token_usage.log, r, encodingutf-8) as f: for line in f: line line.strip() if not line: continue data json.loads(line) total_prompt data[prompt_tokens] total_completion data[completion_tokens] total_calls 1 print(f调用次数: {total_calls}) print(f输入 token 总计: {total_prompt}) print(f输出 token 总计: {total_completion}) print(f全部 token 总计: {total_prompt total_completion})这个脚本是优化效果验证的关键依据。改造前先跑一遍记录基线改造后再跑一遍对比差异。7. 运行结果与效果验证7.1 运行命令python main.py7.2 预期输出示例总行数: 200 规则命中: 168 AI 调用: 32 AI 调用占比: 16.0%这意味着200 条反馈里只有 32 条触发 DeepSeek API剩余 168 条被规则直接消化。假设每条反馈原文 600 字原方案输入 token 为 200 条完整文本新方案为 32 条截断文本输入 token 总量通常会降到原来的 10% 到 20%。7.3 成功判断标准可以从三个维度验证token 总量运行python analyze_tokens.py观察总 token 是否明显下降。正确率随机抽样 50 条规则命中的样本人工核对分类是否正确。耗时对比改造前后的总运行时长。规则命中后直接写结果比 API 调用快得多。如果 token 下降但正确率明显变差说明规则边界设计过宽需要回退部分样本到 AI。7.4 失败时的首选排查路径如果程序运行失败按以下顺序排查查看token_usage.log是否在生成如果完全没有日志说明请求没发出去检查 API Key 和网络。查看feedback_result.xlsx是否写入如果没写入检查 Excel 文件是否被占用或者路径是否有权限。查看API 调用失败的数量如果大量失败检查 API 限额、模型名称和超时时间。8. 常见问题与排查思路问题现象可能原因排查方式解决方案token 消耗仍然很高系统提示词过长或每轮重复传历史查看日志中的 prompt_tokens 分布精简 system prompt使用截断后的输入片段大量调用返回 403API Key 失效或无权限检查响应体内容和状态码刷新 Key确认服务开通范围和地区限制调用超时单次请求 context 过长查看响应时间和 total_tokens降低 max_tokens进一步截断输入规则命中率过低关键词设计过窄或文本表述太口语化统计规则命中的样本比例增加同义词、正则表达式扩大规则覆盖AI 输出解析失败模型返回了 JSON 以外的文本打印原始输出内容加强提示词约束用 JSON mode增加解析容错Excel 文件被占用文件正被 Excel 客户端打开检查进程或文件锁定关闭 Excel或使用副本路径9. 工程建议与最佳实践9.1 把 token 用量当成第一类监控指标很多团队监控接口错误率、响应时间却不关心 token 消耗。建议在日志中记录每次调用的 usage并用脚本每天统计一次。一旦 token 总量异常增长说明某条流程可能出现了新的重复调用需要及时干预。9.2 优先用规则和脚本能不开 API 就不开这不是反对 AI而是给 AI 找到更合适的位置。在真实项目中绝大多数“AI 处理数据”的任务都可以拆成“规则前置 AI 兜底”的模式。规则解决 80%AI 解决 20%成本自然最优。9.3 系统提示词要精简系统提示词越长每一轮调用都在重复付费。能压缩到 50 个 token 的提示词就不要写 500 个 token。同时要明确要求模型只输出结构化内容避免生成大段无用的开场白和解释。9.4 设置 API 调用兜底与重试策略调用失败时要区分可重试和不可重试。网络超时可重试401/403 类错误不要重试直接报警。重试使用指数退避避免击穿接口限制。9.5 涉及批量任务和敏感数据时的安全提醒生产环境操作前必须先在小样本上验证。如果数据包含个人隐私或业务机密调用外部 API 时要做好脱敏最好只传必要字段。RPA 脚本操作业务系统时应使用最小权限账号并在测试环境验证。需要写数据库或修改线上数据时先评估影响范围准备好回滚方案。10. 总结与后续学习方向DeepSeek API 涨价这件事本质上是在提醒开发者大模型是一种昂贵且有限的计算资源它不是用来执行重复劳动的。token 计费模型决定了只有把输入和输出控制在最少必要限度成本才是可控的。本文给出的方案是“规则前置 RPA 自动化 AI 兜底判断”通过 Excel 数据分类这个案例完整跑通了从日志统计、规则匹配、AI 调用、结果回填到效果验证的全流程。如果你正在维护一个频繁调用大模型 API 的项目下一步可以先做三件事在代码里记录每次调用的 token 用量拿到自己的基线数据。找出调用量最大的 3 个场景判断哪些动作是纯重复流程。按本文的示例实现一个最小改造对比优化前后的 token 总量。再往后可以继续深入的方向包括用本地小模型处理隐私数据、在 RPA 中接入页面操作实现更复杂的跨系统流程、用向量数据库缓存常见问题的答案。建议先把本文的日志统计脚本跑起来因为无论后续怎么优化没有数据支撑成本优化都无从谈起。