“大龙虾”这个外号最近在中老年朋友圈和科技群里都挺常见说的就是 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账单拆解钱到底花在哪里我实际踩完一遍之后账单大概长这样项目费用说明DeepSeek API充值9-10元核心成本日常使用能撑一到两周常驻运行设备0元用家里旧笔记本或公司淘汰的小主机电费约2-5元/月旧笔记本功耗低实测约15W-25W域名0-5元只做定时推送则不需要做对话接口才需要消息推送服务0元用国内免费的Webhook/聚合推送服务也就是说如果只是让助理每天定时给你汇报天气、整理待办、汇总邮件那除了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, modeldeepseek-chat): headers { Authorization: fBearer {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, jsonpayload, headersheaders, timeout60) 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主动找到你。我实际用下来的消息通道有三类各有优劣方案优点缺点适合场景企业微信群机器人Webhook群里所有人都能看到适合团队共享需要能登录企业微信后台团队值班提醒、每日汇总Server酱 / PushPlus直接推送到你自己的微信免费额度够用单向推送不能回复对话个人日报、告警通知飞书/钉钉自定义机器人接口灵活回调能力强配置相对麻烦需要双向对话的场景以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, jsondata, timeout10) 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, hour8, minute30)真正拉开差距的是提示词。同样是问大龙虾随便问和认真设计出来的结果天差地别。我常用的提示词模板长这样你是我的私人AI助理风格简洁、直接、不啰嗦。 我有如下任务需要你完成{任务描述}。 要求 1. 先输出结论再给理由 2. 不超过200字 3. 不要使用markdown符号 4. 如果需要行动建议最后单独一行输出行动建议xxx这里的关键不是“让AI更聪明”而是通过约束输出格式让下游程序好解析。比如我让它最后一行输出“行动建议xxx”这样脚本拿到结果后可以直接判断有没有Action需要执行。AI是内容生成器调度逻辑才是助理的大脑。另外一个容易忽略的点给AI足够上下文。我每周会准备一份“本周待办”“本周关注的邮件关键词”“当前项目进度”等素材塞进prompt里作为背景它生成的早报就会有针对性而不是全网热搜复读机。3. 实操过程与核心环节实现从脚本到7x24服务3.1 环境准备找一台能常年开机的设备这一节针对“24小时不关机”这个核心需求。你可以选设备优先级我排一下旧笔记本功耗低、自带电池断电还能扛一会最推荐。我用的就是一台8年前的ThinkPad拆掉屏幕当主机用。迷你主机/开发板功耗极低但需要额外买电源和存储预算会高一点。低配云服务器新用户优惠时一个月几块钱能拿下但免费期结束后费用会涨长期持有成本不低。公司/家里的其他常开电脑如果有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, modeldeepseek-chat): headers {Authorization: fBearer {DEEPSEEK_API_KEY}} payload { model: model, messages: [{role: user, content: prompt}], temperature: 0.7, max_tokens: 800, } resp requests.post(DEEPSEEK_URL, jsonpayload, headersheaders, timeout60) 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, jsondata, timeout10) 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(timezoneAsia/Shanghai) scheduler.add_job(morning_brief, cron, hour8, minute30) scheduler.add_job(evening_summary, cron, hour21, minute0) print(助理调度已启动24小时运行中CtrlC退出) scheduler.start()关于APScheduler有两点经验和你说一定要指定时区timezoneAsia/Shanghai否则默认UTC时间会导致早晨8点变成下午4点我第一次就犯了这错误连续几天在傍晚收到“早上好”。BlockingScheduler会一直占住终端适合配systemd时使用如果你是临时测试可以直接跑想退出按CtrlC。3.3 部署成24小时服务systemd守护进程脚本能跑只是第一步真正“不关机”是第二步。你不可能让脚本裸跑在SSH终端里因为一旦你断开SSH进程就可能被杀死。正确的做法是用systemd把它变成系统服务由系统来管理它的生命周期。我写一个service文件放到/etc/systemd/system/ai-assistant.service[Unit] DescriptionAI Assistant Service Afternetwork.target [Service] Typesimple User你的用户名 WorkingDirectory/home/你的用户名/ai-assistant EnvironmentDEEPSEEK_API_KEYsk-你的key EnvironmentPUSHPLUS_TOKEN你的token ExecStart/home/你的用户名/ai-assistant/venv/bin/python /home/你的用户名/ai-assistant/assistant.py Restartalways RestartSec10 [Install] WantedBymulti-user.target然后执行sudo systemctl daemon-reload sudo systemctl enable ai-assistant sudo systemctl start ai-assistant systemctl status ai-assistant这里Restartalways是关键它保证即使脚本因为网络波动或者意外抛异常挂了系统也会在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(host0.0.0.0, port8000)这等于把你的助理包装成了一个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、超时这是新手最容易遇到的一批报错我把典型问题整理成了速查表现象可能原因解决办法401 UnauthorizedAPI Key错误或已过期检查环境变量和脚本里的Key是否一致重新复制Key429 Too Many Requests请求频率超限或余额不足查看开放平台余额充钱降低调用频率超时/Connection Error网络波动或服务端响应慢增加timeout60参数加上重试机制返回空内容prompt被安全策略拦截或max_tokens太小调整prompt调大max_tokens我自己的处理办法是在代码里加三层重试import time def ask_deepseek_with_retry(prompt, retries3): for i in range(retries): try: return ask_deepseek(prompt) except Exception as exc: print(f第{i1}次调用失败: {exc}) time.sleep(2 ** i) raise RuntimeError(连续多次调用失败)用指数退避2的幂次递增等待时间能有效规避服务端瞬时抖动。这个技巧虽然不起眼但在跑一周的过程中至少能帮你少收一半的错报推送。4.2 机器人没有收到消息排查从“链路最末端”往回走我遇到过很多次“AI已经回复了但我没收到微信推送”的情况。经验是不要从最前端猜从最后端往后查。先确认推送服务有没有收到请求再确认token对不对最后才往上游查。具体步骤手动执行一次推送脚本看终端输出看脚本打印的HTTP状态码PushPlus成功会返回code: 200去PushPlus后台看历史消息记录如果推送服务正常再检查定时任务是否真的触发了脚本。我曾经排查了半天代码结果发现是旧笔记本晚上休眠了systemd服务虽然挂着但系统睡死过去定时任务根本没有执行者。后来我在BIOS里关闭了休眠才彻底解决。Linux服务器的“24小时不关机”前提是系统不睡眠这个坑很容易被忽略。4.3 运行久了内存和日志暴涨Python服务跑一周之后我注意到内存占用悄悄升高了。主要有两个原因日志没有轮转越积越多某个第三方库内部缓存或线程泄漏。我的解决办法很简单给systemd服务加上日志大小限制。在service文件中的[Service]段加上StandardOutputjournal StandardErrorjournal同时限制systemd日志journalctl --vacuum-time3d sudo systemctl edit ai-assistant这样日志最多保留三天写满就自动清不会把硬盘撑爆。内存方面如果发现是某个函数导致异常挂起就在函数内部把大对象显式del掉配合gc.collect()一般能压住。4.4 费用失控让AI助理别当“碎钞机”按量付费虽然便宜但如果不控制也会出现余额十分钟清零的情况。最典型的场景是误写了死循环比如while True里面直接调API一个意外就烧掉几块钱。我给自己设了三条规矩所有调用必须经过带超时和重试的封装函数避免无限等待设置单次max_tokens上限比如不超过800杜绝一次生成上万字定时任务里加汇总逻辑比如一小时最多触发几次用简单计数器限流。其实对个人助理这个频率来说一天几十次请求按DeepSeek的定价9块9撑一两周是完全没问题的。真正的费用炸弹永远是自己手痒去测试“无限对话”或者让助理去处理超长文本。4.5 安全与隐私AI助理不该乱说最后说一个很多人忽略的点你把什么数据喂给了API就得接受它被传输到大模型服务端。所以我的原则是不要把密码、密钥、身份证号等敏感信息直接塞进prompt涉及公司商业机密的内部材料宁可不做AI总结也不要裸传如果以后要玩更重的RAG检索增强建议自己搭向量化再过滤这是另一个话题。经过这一周的实际运行我对这套“9块9部署好大龙虾”的方案还是有相当的信心。它最大的价值不是省了多少钱而是用极低的试错成本让你真正摸到“一个人也能拥有AI助理”的完整路径。踩过的坑基本都在上面了你要做的只是抄作业、跑起来、然后按自己的需求一点点改。哪怕一开始只跑个定时早报也会让你觉得这一周过得特别踏实。