企业官网建设流程全解析

DeepSeek API 价格调整之后，很多人第一反应是“又要多烧钱了”，第二反应是“能不能少调几次接口”。如果业务里大量重复流程还在一次次手动复制粘贴、重复调用大模型，token 消耗确实会快速累积。这篇文章不聊模型本身怎么调优，而是讲一个更省成本的思路：把重复流程交给 RPA 自动跑，让大模型只处理真正需要推理的环节，从调用次数、上下文长度、失败重试三个层面把 token 花销压下来。

先给结论：RPA 并不是要取代 DeepSeek，而是负责那些“不需要动脑”的环节，比如文件读取、表格整理、页面跳转、结果回填；DeepSeek 只承担生成、总结、判断这类不可替代的步骤。两者结合，既保留 AI 能力，又避免让大模型在琐碎流程上空转。这样做之后，一个常见的日报生成流程，我可以把每次 API 调用消耗控制在原有方案的 1/3 到 1/5，前提是流程设计合理。

这篇文章会围绕一个具体场景展开：用 RPA 驱动 DeepSeek API 完成批量文章改写和报告生成，并给出可复制的工程化配置、调用示例和成本控制方法。

1. 核心能力速览

这个组合的核心思路是：RPA 处理“流程”，DeepSeek 处理“文本”。比如你要整理 50 份 PDF 摘要，RPA 负责遍历文件、提取文本、调用 API、把结果写回表格，DeepSeek 只负责把每一段文本压缩成摘要。如果写代码调 API，RPA 的价值不大；但如果流程里包含网页登录、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_KEY=sk-xxxxxxxxxxxxxxxx

Python 读取：

import os api_key = os.environ.get("DEEPSEEK_API_KEY") if not api_key: raise RuntimeError("请先配置 DEEPSEEK_API_KEY 环境变量")

3.3 数据准备

在跑流程之前，把输入素材整理成结构化表格。比如你要批量生成商品文案，Excel 字段先设计好：

RPA 读取 Excel 时会按行循环，每一行代表一次独立的 API 任务。如果字段没设计好，后面写 prompt 逻辑会比较别扭。

4. 安装部署与启动方式

这里给出两种启动路径：一种用影刀 RPA 的图形化流程，适合非程序员；一种用 Python 脚本，适合需要更精细控制批量任务和错误处理的场景。

4.1 影刀 RPA 流程搭建

安装影刀 RPA 后，新建一个自动化流程，包含以下组件：

1. 读取 Excel 数据：遍历输入表格每一行。
2. 检查缓存：如果该行已经生成过结果，直接跳过。
3. 调用 DeepSeek API：通过“发送 HTTP 请求”组件，把 prompt 拼好并 POST 给 API。
4. 解析响应：从 JSON 返回里提取需要的内容字段。
5. 写入结果：把返回值写到 Excel 对应单元格或新文件。
6. 异常重试：请求失败时等待几秒后重试，连续失败则记录日志并跳过。

影刀 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": f"Bearer {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, headers=HEADERS, json=payload, timeout=120) 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(encoding="utf-8").splitlines()) results = [] with open(input_file, encoding="utf-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( title=row["title"], keywords=row["keywords"], platform=row["platform"], length=int(row["length"]) ) results.append({ "id": task_id, "title": row["title"], "output": content }) with open(cache_file, "a", encoding="utf-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 能正常响应、返回字段解析正确。

操作步骤：

1. 准备一条 200 字以内的简单任务。
2. 手动调用一次 API，查看返回内容。
3. 检查返回 JSON 里是否有choices[0].message.content字段。

预期结果：

• HTTP 200 状态码。
• 返回内容包含完整文案，而不是报错信息。
• 响应时间在 30 秒以内。

判断标准：返回内容可读、无截断、无格式错乱、没有出现标题和正文混杂。

5.2 批量任务缓存验证

测试目的：验证缓存逻辑能否避免重复消耗。

操作步骤：

1. 用 5 条任务跑第一轮，记录输入 token 总和。
2. 不删除缓存文件，重跑同一批任务。
3. 观察控制台是否打印[跳过]，以及是否产生新的 API 请求。

预期结果：第二轮没有新请求，日志中 5 条全部跳过。

判断标准：如果第二轮产生了相同请求，说明缓存键值设置有问题，需要检查是否用了唯一 ID 作为缓存依据。

5.3 失败重试验证

测试目的：确认网络抖动或接口报错时，任务不会被永久卡住。

操作步骤：

1. 故意把 API_URL 改成一个不存在的地址。
2. 跑 1 条任务。
3. 观察重试日志。

预期结果：脚本连续重试 3 次，每次间隔 5 秒，最后记录为失败并继续下一条任务，而不是整个进程崩溃。

判断标准：日志中有明确的失败次数和最终跳过标记。

5.4 输出质量对比

测试目的：验证 prompt 结构是否稳定，是否因为上下文裁剪导致输出变差。

操作步骤：

1. 同一批输入，分别用完整上下文 prompt 和精简 prompt 各跑一次。
2. 对比输出结果质量。

预期结果：精简 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 消耗的六个策略：

1. 精简 system prompt，不要把规则写成长篇小说。能放进代码的条件判断就不要让模型处理。
2. 每次请求只发送当条任务需要的最低上下文。
3. 相同前缀的模板内容在代码里拼接，而不是让模型翻找。
4. 设置合理的max_tokens，避免模型自由发挥输出超长废话。
5. 相同结果不重复调用，用缓存文件或数据库记录 task_id。
6. 固定不变的参考内容不要写进每个 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, headers=headers, json=payload, timeout=60) 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 流程可能是：

1. RPA 打开业务系统，登录。
2. 按日期范围筛选订单列表。
3. 把每一条订单的备注、金额、客户名称读入 Excel。
4. 对每一行调用 DeepSeek API，生成个性化工单备注。
5. 将生成结果写回系统表单。
6. 页面翻页，重复执行，直到全部完成。

这种场景里，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 服务端完成，本地不做模型推理。如果你的电脑性能很差，只需要确保浏览器、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 系统，做成一条从采集到发布的完整内容流水线。

建议先保存这篇文章，等下一次你要批量处理文本类任务时，再回来对照搭流程。