9块9搞定7x24小时AI助理：DeepSeek API+调度推送全攻略

“大龙虾”这个外号，最近在中老年朋友圈和科技群里都挺常见，说的就是 DeepSeek。本来我一个搞运维的，平时最烦追热点，但这套东西我确实自己折腾了几天，效果超出预期：用接近9块9的开销，在公司旁边租的旧笔记本上跑了一个7x24小时不关机的AI助理，既当定时汇报助手，又当微信群里的智能答疑前台，偶尔还能帮我生成日报和周报。

先说结论：这不是玄学，也不是标题党。9块9买不了多少菜，但用来给“大龙虾”API充个值，再配合一台能长期开机的便宜设备，完全能搭出一个实用的个人助理。整套链路核心就三件事：DeepSeek 的 API、一个能跑Python的常驻环境、一个能送到你手机/群里的消息通道。我会把成本拆解、技术选型、代码实现、踩坑记录全写出来。

这篇文章适合的人，画像是这样的：会用一点Python终端命令，想折腾点真实有用的AI工具，但又不想买显卡、不想学K8s、不想被大模型框架折腾疯的普通人。如果你正好属于这一类，往下看就够了。

1. 整体设计：9块9怎么花，为什么这么花

1.1 首先说清楚：为什么不本地部署大模型

标题下面挂了一堆“deepseek本地部署”“ollama部署大模型”“vllm部署deepseek”之类的热搜词，确实，本地部署大模型是很多人的第一反应。但如果你真的只有9块9预算，本地部署这条路从一开始就是死胡同。

原因很简单：本地跑一个有质量的对话模型，要么吃显卡显存，要么吃大内存。一张勉强能跑14B模型的显卡，二手价都是千元起；哪怕用纯CPU跑量化小模型，一台设备的电费一个月也不止9块9。更别提推理速度慢到让你怀疑人生——一句话可能要等两分钟，助理变网友，聊两句人跑了，你还在等回复。

所以我的第一选择是：用API，不用自建模型。DeepSeek开放平台的API是典型的按量付费，日常聊天、总结、写日报这类轻量场景，充一次9块9的额度能跑很久。省掉硬件、省掉部署、省掉电费，性价比最高。

这个思路说白了就是：大龙虾养在家里你得喂饲料，养在别人池塘里你按斤买就行。对个人助理这种长尾低频场景，按量付费是最理性的方案。

1.2 9块9账单拆解：钱到底花在哪里

我实际踩完一遍之后，账单大概长这样：

也就是说，如果只是让助理每天定时给你汇报天气、整理待办、汇总邮件，那除了API充值和几块钱电费，基本零成本。9块9这个数字，实际上对应的是“API充值+杂费”的组合，不是一次性买断。

有一点要提前警告：如果未来某天你被各种热搜词带偏，非要上“vllm部署”“ragflow docker部署”这种重型架构，9块9是绝对不够的。这些折腾方向本质上是企业级玩法，需要内存、GPU、Redis向量库，个人场景严重超配。你的目标是“助理”，不是“AI中台”。

1.3 技术链路：一个前台接线员的类比

整套系统的运行逻辑，其实特别像一个公司前台：

• 你（用户）把需求丢给前台，前台不需要自己懂所有事；
• 前台拿起电话打给大龙虾（DeepSeek API），大龙虾算完给出答案；
• 前台再把答案整理成一句人话，通过广播（推送通道）传给你。

技术链路就是这样：

定时任务/消息触发 → Python调度脚本 → DeepSeek API（大龙虾思考） ↓ 推送通道（企业微信/Server酱/PushPlus） → 你能看到结果

中期如果要做对话机器人，就再加一层回调接口：微信/飞书收到消息后回调到你的服务，服务再提交给DeepSeek，最后把回复发回去。这里会涉及公网入口和域名，但也不是什么难事，后面会提。

选这条链路而不是“全自研对话系统”，是因为它把复杂的事情模块化拆开了：思考交给大模型，触发交给调度器，送达交给推送服务。哪一环出问题，你就修哪一环，不用推翻重来。我第一次跑通时，最直观的感受就是：成就感来得特别快。

2. 核心组件拆解：大龙虾API、消息通道、调度逻辑

2.1 DeepSeek API接入：90秒跑通“思考”

这一部分很简单，别被“API接入”四个字吓到。本质就是发一个HTTP请求过去，拿一段JSON回来。我直接把代码贴出来，你复制就能用。

先到DeepSeek开放平台注册账号，创建API Key，这个Key就是一串类似sk-xxxx的字符串，用来证明“你是谁”。整个过程大概5分钟，不需要实名认证之外的任何门槛。

然后写一个最简请求：

import requests API_KEY = "sk-你的key" API_URL = "https://api.deepseek.com/chat/completions" def ask_deepseek(prompt, model="deepseek-chat"): headers = { "Authorization": f"Bearer {API_KEY}", "Content-Type": "application/json" } payload = { "model": model, "messages": [ {"role": "user", "content": prompt} ], "temperature": 0.7, "max_tokens": 1024 } resp = requests.post(API_URL, json=payload, headers=headers, timeout=60) resp.raise_for_status() data = resp.json() return data["choices"][0]["message"]["content"] print(ask_deepseek("用一句话介绍你自己"))

这里有几个参数说清楚：

• model：日常对话用deepseek-chat，需要复杂推理用deepseek-reasoner。我默认chat，速度更快，日常足够。
• temperature：控制随机性。写诗八卦可以调高到0.9，做事实性回答建议0.3以下。
• max_tokens：限制最长回复长度，防止它一口气写八千字小作文。

我测试的返回值本身是一个标准OpenAI格式的JSON，解析到choices[0].message.content就是正文。为了调试方便，我一般会额外打印整个响应，确认状态码是不是200。

加一个建议：把API Key存成环境变量，别硬编码在脚本里。我习惯在脚本开头读os.getenv("DEEPSEEK_API_KEY")，这样即便以后把脚本分享给别人，也不会泄露密钥。今天是自己的脚本无所谓，但哪天你扩展成给别人用，这就是事故。

2.2 消息通道选择：怎么把答案送到你眼前

模型回复出来了，只是第一步。你不大可能为了看个回答，每天都在服务器上敲Python，所以要解决的第二个问题就是：怎么让AI主动找到你。

我实际用下来的消息通道有三类，各有优劣：

以PushPlus为例，注册之后会拿到一个token，然后发送一个GET请求就能推送消息到微信：

import requests PUSHPLUS_TOKEN = "你的token" def push_wx(title, content): url = "https://www.pushplus.plus/send" data = { "token": PUSHPLUS_TOKEN, "title": title, "content": content } resp = requests.post(url, json=data, timeout=10) if resp.status_code == 200 and resp.json().get("code") == 200: print("推送成功") else: print("推送失败", resp.text)

企业微信机器人的思路也类似：往一个Webhook地址POST一条JSON消息，群里就会收到机器人发的文本。两个通道我都在用：个人消息走PushPlus，团队消息走企业微信。

如果你追求的是“能对话的AI助理”，那就需要反过来：让微信/飞书的消息可以进到你的服务。这里一定会涉及到“回调地址”，也就是你的服务需要一个公网能访问到的URL。个人低预算方案里，比较实际的做法是：

• 有公网IP：路由器做个端口映射把8000端口映射出去；
• 没有公网IP：用云服务器部署，家庭服务只负责定时任务；
• 不想买服务器：可以用内网穿透类工具，但费用和稳定性需要权衡。

我踩过最大的坑是：一开始没有公网入口，导致Webhook回调测试迟迟不过。后来我放弃了“一步到位做对话”，先做定时推送，再慢慢加对话，节奏就顺多了。

2.3 调度逻辑与提示词设计：让助理像个人

助理之所以“像助理”，不是因为背后有AI，而是因为你在调度逻辑里给它安排了活、限定了格式。

调度层我用的是最朴素的方案：APScheduler库做定时任务，或者干脆用系统crontab。定时任务的核心是“什么时间，调用什么函数”，逻辑很简单：

def daily_morning_report(): prompt = "你是我的私人助理。请根据以下素材整理一条今日要闻简报，控制在200字内：..." answer = ask_deepseek(prompt) push_wx("今日早报", answer) # 每天早上8点30分执行 scheduler.add_job(daily_morning_report, "cron", hour=8, minute=30)

真正拉开差距的是提示词。同样是问大龙虾，随便问和认真设计出来的结果天差地别。我常用的提示词模板长这样：

你是我的私人AI助理，风格简洁、直接、不啰嗦。 我有如下任务需要你完成：{任务描述}。 要求： 1. 先输出结论，再给理由 2. 不超过200字 3. 不要使用markdown符号 4. 如果需要行动建议，最后单独一行输出：行动建议：xxx

这里的关键不是“让AI更聪明”，而是通过约束输出格式，让下游程序好解析。比如我让它最后一行输出“行动建议：xxx”，这样脚本拿到结果后可以直接判断有没有Action需要执行。AI是内容生成器，调度逻辑才是助理的大脑。

另外一个容易忽略的点：给AI足够上下文。我每周会准备一份“本周待办”“本周关注的邮件关键词”“当前项目进度”等素材，塞进prompt里作为背景，它生成的早报就会有针对性，而不是全网热搜复读机。

3. 实操过程与核心环节实现：从脚本到7x24服务

3.1 环境准备：找一台能常年开机的设备

这一节针对“24小时不关机”这个核心需求。你可以选设备，优先级我排一下：

1. 旧笔记本：功耗低、自带电池（断电还能扛一会），最推荐。我用的就是一台8年前的ThinkPad，拆掉屏幕当主机用。
2. 迷你主机/开发板：功耗极低，但需要额外买电源和存储，预算会高一点。
3. 低配云服务器：新用户优惠时一个月几块钱能拿下，但免费期结束后费用会涨，长期持有成本不低。
4. 公司/家里的其他常开电脑：如果有NAS或软路由，直接在上面开个Docker容器最省心。

选设备时重点看两件事：能不能装Python3、能不能24小时开着。至于性能，我负责任地说，这个助理脚本跑起来连CPU的1%都用不到，你不需要为它买任何新硬件。

安装Python环境，我建议用虚拟环境，不为别的，就为了以后折腾坏了好收拾：

mkdir -p ~/ai-assistant && cd ~/ai-assistant python3 -m venv venv source venv/bin/activate pip install requests apscheduler flask

虚拟环境的好处是：依赖全部锁在项目目录里，不会污染系统Python，也不会因为升级系统包导致脚本身亡。我在生产服务器上吃过太多“系统Python被搞坏”的亏，现在一律强制虚拟环境。

3.2 写助理脚本：一个完整的最小实现

下面给一个整体脚本，把推送、调度、API调用都串起来。这个脚本是我实际跑过的简化版，逻辑清晰，适合照抄：

import os import requests from apscheduler.schedulers.blocking import BlockingScheduler DEEPSEEK_API_KEY = os.getenv("DEEPSEEK_API_KEY", "sk-你的key") DEEPSEEK_URL = "https://api.deepseek.com/chat/completions" PUSHPLUS_TOKEN = os.getenv("PUSHPLUS_TOKEN", "你的token") def ask_deepseek(prompt, model="deepseek-chat"): headers = {"Authorization": f"Bearer {DEEPSEEK_API_KEY}"} payload = { "model": model, "messages": [{"role": "user", "content": prompt}], "temperature": 0.7, "max_tokens": 800, } resp = requests.post(DEEPSEEK_URL, json=payload, headers=headers, timeout=60) resp.raise_for_status() return resp.json()["choices"][0]["message"]["content"] def push_wechat(title, content): data = {"token": PUSHPLUS_TOKEN, "title": title, "content": content} resp = requests.post("https://www.pushplus.plus/send", json=data, timeout=10) print("推送状态", resp.status_code, resp.text[:120]) def morning_brief(): prompt = """ 你是我的私人AI助理。 现在是早上8点半，请根据今天的日期，帮我生成一份简短工作日报大纲： - 昨日重点事项回顾（假设我有项目A、项目B两个项目） - 今日推荐推进事项 - 一句话鼓励 控制在180字以内，不要用markdown语法。 """ try: reply = ask_deepseek(prompt) push_wechat("早上好，这是今天的简报", reply) except Exception as exc: push_wechat("助理出错了", str(exc)) def evening_summary(): prompt = "请帮我生成一个晚间复盘模板，包含任务完成度、明日计划、需要协调事项三个小节，每小节两句话，总字数150字内。" try: reply = ask_deepseek(prompt) push_wechat("晚间复盘", reply) except Exception as exc: push_wechat("复盘生成出错", str(exc)) if __name__ == "__main__": scheduler = BlockingScheduler(timezone="Asia/Shanghai") scheduler.add_job(morning_brief, "cron", hour=8, minute=30) scheduler.add_job(evening_summary, "cron", hour=21, minute=0) print("助理调度已启动，24小时运行中，Ctrl+C退出") scheduler.start()

关于APScheduler，有两点经验和你说：

• 一定要指定时区timezone="Asia/Shanghai"，否则默认UTC时间会导致早晨8点变成下午4点，我第一次就犯了这错误，连续几天在傍晚收到“早上好”。
• BlockingScheduler会一直占住终端，适合配systemd时使用；如果你是临时测试，可以直接跑；想退出按Ctrl+C。

3.3 部署成24小时服务：systemd守护进程

脚本能跑只是第一步，真正“不关机”是第二步。你不可能让脚本裸跑在SSH终端里，因为一旦你断开SSH，进程就可能被杀死。正确的做法是用systemd把它变成系统服务，由系统来管理它的生命周期。

我写一个service文件，放到/etc/systemd/system/ai-assistant.service：

[Unit] Description=AI Assistant Service After=network.target [Service] Type=simple User=你的用户名 WorkingDirectory=/home/你的用户名/ai-assistant Environment=DEEPSEEK_API_KEY=sk-你的key Environment=PUSHPLUS_TOKEN=你的token ExecStart=/home/你的用户名/ai-assistant/venv/bin/python /home/你的用户名/ai-assistant/assistant.py Restart=always RestartSec=10 [Install] WantedBy=multi-user.target

然后执行：

sudo systemctl daemon-reload sudo systemctl enable ai-assistant sudo systemctl start ai-assistant systemctl status ai-assistant

这里Restart=always是关键，它保证即使脚本因为网络波动或者意外抛异常挂了，系统也会在10秒后把它拉起来。这比你自己写while True循环要靠谱得多，系统的守护比人的守护持久。

如果你不喜欢systemd，也有简单粗暴的替代方案：nohup python assistant.py &配合crontab定时检查进程是否存在。我早期就是靠这个跑的，但后来重启一次机器，忘了重新挂载，助理就“失联”了好几天。换了systemd之后，开机自启、崩溃重启全部自动，省心太多。

可能有人会问：为什么不用Docker？也可以。但在一台旧笔记本上，系统自带Python3就够用，再加Docker会多出一层内存开销，没必要。当然，如果以后你要把服务搬到NAS或者云服务器上，Docker化会是更规范的选择，代码逻辑不用变，只要打包镜像就行。

3.4 从“定时通知”扩展到“对话式助理”

定时通知只是助理的第一阶段。第二阶段，我建议做“对话入口”，哪怕先从本地命令行试起。在脚本里加一项：

from flask import Flask, request, jsonify app = Flask(__name__) @app.route("/chat", methods=["POST"]) def chat(): data = request.get_json() user_msg = data.get("message", "") try: reply = ask_deepseek(user_msg) return jsonify({"reply": reply}) except Exception as exc: return jsonify({"reply": f"出错了：{exc}"}), 500 # 在主函数里启动Flask app.run(host="0.0.0.0", port=8000)

这等于把你的助理包装成了一个HTTP接口。有了这个接口，你可以在电脑上随便发POST请求调用它：

curl -X POST http://localhost:8000/chat -H "Content-Type: application/json" -d '{"message":"帮我总结一下这篇文章的要点"}'

到了这一步，距离“微信里直接对话”就只差一层回调绑定了。你可以把它接到支持回调的机器人平台上，回调地址填http://你的服务器:8000/chat，平台再把用户的提问POST过来，你的接口返回的reply就会回给用户。

这一步我强烈建议放到第二阶段再做，因为一旦开放公网入口，就要考虑鉴权、频率限制和安全防护，复杂度会上升一个量级。第一版先把定时任务跑稳，再开放对话，才是稳步迭代的正确节奏。

4. 常见问题与排查技巧实录

4.1 API调用失败：401、429、超时

这是新手最容易遇到的一批报错，我把典型问题整理成了速查表：

我自己的处理办法是在代码里加三层重试：

import time def ask_deepseek_with_retry(prompt, retries=3): for i in range(retries): try: return ask_deepseek(prompt) except Exception as exc: print(f"第{i+1}次调用失败: {exc}") time.sleep(2 ** i) raise RuntimeError("连续多次调用失败")

用指数退避（2的幂次递增等待时间）能有效规避服务端瞬时抖动。这个技巧虽然不起眼，但在跑一周的过程中，至少能帮你少收一半的错报推送。

4.2 机器人没有收到消息：排查从“链路最末端”往回走

我遇到过很多次“AI已经回复了，但我没收到微信推送”的情况。经验是：不要从最前端猜，从最后端往后查。先确认推送服务有没有收到请求，再确认token对不对，最后才往上游查。

具体步骤：

1. 手动执行一次推送脚本，看终端输出；
2. 看脚本打印的HTTP状态码，PushPlus成功会返回"code": 200；
3. 去PushPlus后台看历史消息记录；
4. 如果推送服务正常，再检查定时任务是否真的触发了脚本。

我曾经排查了半天代码，结果发现是旧笔记本晚上休眠了，systemd服务虽然挂着，但系统睡死过去，定时任务根本没有执行者。后来我在BIOS里关闭了休眠，才彻底解决。Linux服务器的“24小时不关机”前提是系统不睡眠，这个坑很容易被忽略。

4.3 运行久了内存和日志暴涨

Python服务跑一周之后，我注意到内存占用悄悄升高了。主要有两个原因：

• 日志没有轮转，越积越多；
• 某个第三方库内部缓存或线程泄漏。

我的解决办法很简单：给systemd服务加上日志大小限制。在service文件中的[Service]段加上：

StandardOutput=journal StandardError=journal

同时限制systemd日志：

journalctl --vacuum-time=3d sudo systemctl edit ai-assistant

这样日志最多保留三天，写满就自动清，不会把硬盘撑爆。内存方面，如果发现是某个函数导致异常挂起，就在函数内部把大对象显式del掉，配合gc.collect()，一般能压住。

4.4 费用失控：让AI助理别当“碎钞机”

按量付费虽然便宜，但如果不控制，也会出现余额十分钟清零的情况。最典型的场景是误写了死循环，比如while True里面直接调API，一个意外就烧掉几块钱。我给自己设了三条规矩：

1. 所有调用必须经过带超时和重试的封装函数，避免无限等待；
2. 设置单次max_tokens上限，比如不超过800，杜绝一次生成上万字；
3. 定时任务里加汇总逻辑，比如一小时最多触发几次，用简单计数器限流。

其实对个人助理这个频率来说，一天几十次请求，按DeepSeek的定价，9块9撑一两周是完全没问题的。真正的费用炸弹永远是自己手痒去测试“无限对话”，或者让助理去处理超长文本。

4.5 安全与隐私：AI助理不该乱说

最后说一个很多人忽略的点：你把什么数据喂给了API，就得接受它被传输到大模型服务端。所以我的原则是：

• 不要把密码、密钥、身份证号等敏感信息直接塞进prompt；
• 涉及公司商业机密的内部材料，宁可不做AI总结，也不要裸传；
• 如果以后要玩更重的RAG（检索增强），建议自己搭向量化再过滤，这是另一个话题。

经过这一周的实际运行，我对这套“9块9部署好大龙虾”的方案还是有相当的信心。它最大的价值不是省了多少钱，而是用极低的试错成本，让你真正摸到“一个人也能拥有AI助理”的完整路径。踩过的坑基本都在上面了，你要做的只是抄作业、跑起来、然后按自己的需求一点点改。哪怕一开始只跑个定时早报，也会让你觉得这一周过得特别踏实。