很多朋友听到“家庭AI工作系统”这七个字第一反应都是家里又不是公司搞这么正式干嘛我的回答是正因为场景是家才更需要一套能扛事的系统。我是业余玩家不懂深度学习连Python也就写过几十行但过去两个月我硬是把家里的信息整理、日程提醒、文档问答和例行事务自动化全交给了AI——准确说是一套由本地大模型、云端API、手机上的自动化通知和笔记本里的知识库拼起来的组合拳。这篇工作日记就是记录我怎么用“业余小白”的水平把AI工具链搭成一个真正干活的系统。它适合所有不想当程序员、但想让AI替自己打工的朋友参考。我不打算写教程式的说教只想把真实选择、踩过的坑、调通的步骤都摊开讲清楚。1. 先把“家庭AI工作系统”拆成一盘棋在动手之前我花了两天时间反复问自己一个问题家里到底缺什么AI市面上的AI助手App不少但它们本质上都是一个“聊天框”你问一句它答一句从不主动干活。我想要的是另一个东西——一个能消化信息、记住家事、定时跑流程的“数字管家”。想清楚这一点原本模糊的需求就变成一个可以拆解的棋盘了。1.1 我到底想让AI帮我干什么我先把需求写在纸上分成了四类每类对应一个“岗位”信息消化员处理微信群里的公告、收藏夹里的长文章、邮箱里的账单通知。它要能读进去压缩成摘要再告诉我“这件事要不要处理”。生活调度员管日程。缴费单哪天到期、孩子的兴趣班几点接、爸妈的体检预约是否冲突。它要能把散落在日历、短信、邮件里的时间点汇总成一张表。家庭记忆库解决“我家XX东西在哪儿”“上次买的滤芯是什么型号”这种查询问题。AI需要能“认识”我家的私有文档而不是凭空乱编。例行事务自动化每天定时跑一遍把前三个岗位产出的结果打包成“家庭日报”推到我的手机上我起床看一眼就行。这四个需求其实对应了四种技术能力文本摘要、结构化调度、检索问答、自动化编排。这也是我后来搭系统的底层逻辑——不是在找一个大而全的AI而是把不同能力拆给不同工具再串起来。一开始我犯过一个错误试图让一个大模型聊天窗口全包结果它既记不住我家的事也不会主动提醒我最后当然以失败收场。1.2 选型原则跑得快、养得起、修得动既然要长期用选型就不能光看“谁的模型聪明”。我给自己定了三条底线后来证明这三条几乎帮我避开了所有大坑。跑得快家里没有企业级的GPU服务器只有一台带中端显卡的台式机和一台普通笔记本。任何一个环节如果推理延迟超过十几秒我就不会用它。所以模型不是越大越好是“刚刚好”最好。养得起云端API是按token计费的本地部署则要算电费和硬件折旧。我给自己定的预算是每月不超过50块钱——这很宽裕了家庭场景每天几十次调用用国产主流模型API完全够。修得动每个模块尽量独立知识库挂了不影响日报推送云端API挂了本地模型还能顶上。坏哪儿修哪儿而不是整个系统重建。我实测过一个组件出问题如果牵连全局排查成本会指数级上升。这三条原则听起来朴素但它们让后续的搭建从一个“项目”变成了“可持续维护的系统”。尤其是“修得动”这条后面在换模型、调提示词的时候救了我无数次。1.3 系统的四层结构从聊天窗口到数据底座整个系统说到底就四层我用大白话描述一下交互层用户看得见摸得着的东西主要是微信群机器人、手机备忘录、一个简单的网页聊天窗口。调度层定时任务和自动化脚本的集合。它负责“到点干什么”“数据传给谁”相当于整个系统的心脏。模型层AI能力的提供方包括云端API和本地部署的Ollama两块并存。数据层家庭知识库的载体包括文档目录、向量数据库、各类配置清单。平时我感知最多的是交互层但真正的功夫都花在下面三层。特别是数据层我后面踩的坑一半都是因为“数据没整理干净就喂给AI了”。家庭场景的数据虽然量小但类型杂既有PDF说明书又有图片拍的收据还有语音备忘录转换出来的文字每类都得先清洗。这个四层结构也帮我养成了一个习惯谈起“家庭AI系统”我不会只盯着某一个聪明的模型而是看整条流水线通不通。2. 核心细节解析模型选型、本地部署与提示词调教很多人一开始最容易忽视的环节就是“模型层”。说白了这套系统里的AI到底聪不聪明80%取决于你选的模型和调用它的方式而不是你用了多贵的外壳工具。所以我把这块单独拎出来讲一讲我当时的真实决策过程。2.1 大模型怎么选云端API和本地部署的两难我为云端和本地分别做了调研也分别都试了一遍。云端API路线接入方便文档完善模型能力也强。我测了几个国内主流平台的入门级模型用默认参数跑摘要、问答这些都比我预想的好得多。最大的问题只有一个私密性。家庭对话里难免出现身份证号、孩子学校、银行卡尾号之类的东西即便厂商承诺不留存我心里还是不太踏实。另外云端API要联网万一家里断网整个系统就瘫了。本地部署路线用Ollama这类工具把模型跑在自己的电脑上。好处是彻底私密离线可用调用的边际成本几乎为零。坏处也很明显吃硬件。我的台式机是i5处理器加16G内存、6G显存的中端显卡实测只能舒服地跑7B~8B参数级别的模型。这个级别的模型智能程度和云端大模型有明显差距偶尔会犯一些基础错误比如把“高筋面粉”理解成“高蛋白面粉”。我的最终策略是混合使用隐私性要求高的任务比如整理家人生病记录、算家庭开支走本地模型对智能程度要求高、又不涉及隐私的任务比如写旅游攻略、做菜谱规划、长文精读走云端API。这样既控制了成本又保住了隐私底线还兼顾了整体智商。2.2 我的本地部署Ollama实操记录本地部署我选了Ollama理由很简单它在Windows和Linux上装起来都很傻瓜自带模型仓库还有HTTP API可以给其他脚本调用。我的安装和下载命令长这样Windows用户直接下载安装包即可Linux用脚本# Linux一键安装 curl -fsSL https://ollama.com/install.sh | sh # 拉取模型我最终常用的是这两个 ollama pull qwen2.5:7b ollama pull deepseek-r1:7b # 查看本地已拥有的模型 ollama list # 跑起来试试 ollama run qwen2.5:7b部署本身很简单真正需要耐心的是模型选择。7B参数听起来不大但在家用硬件上已经是甜点位。我用同一个Prompt测试了多个模型记录下它们的输出质量、速度、占用资源最后留下了两个一个负责日常问答和摘要一个负责稍微需要逻辑推理的任务。这里有一个关键参数叫“量化等级”通俗点说就是把模型从32位浮点数压缩成更小位数的近似值文件体积小了速度更快但精度会损失一点。我选了Q4_K_M它在体积、速度和准确性上比较均衡实测内存占用约5~6G16G内存的电脑能跑起来不会卡到没法用。如果你的电脑没有独立显卡纯CPU推理也不是不行但要有心理预期。我拿那台旧笔记本实测过7B模型CPU推理的速度大概是每秒5~7个token生成一段200字的摘要要等半分钟。用在一两个低频任务上能忍但绝对撑不起“每天定时批量摘要”。所以我的建议是主力机必须有靠谱的GPU至少要6G显存没有的话就把本地模型定位成“偶尔用的备胎”日常还是交云端。2.3 提示词工程让模型听话的通用模板我踩过最大的一个坑就是以为大模型能脑补我的意图。事实证明让它“整理一下”和让它“按我的格式整理”效果天差地别。后来我把常用的提示词总结成一个四段式模板几乎可以复用到所有家庭场景你是我的家庭助理名叫 [角色名]。 任务目标需要完成的具体事项越清晰越好。 输入材料原始数据多长都行。 输出要求指定格式、指定长度、指定对象比如“用表格列出每项不超过20个字最后给出1条行动建议”。 注意点比如“不要编造数据”“不确定就说不确定”。举个例子。我让AI帮忙整理缴费清单最初的提示词是“看看这些账单提醒我该交什么费”结果输出非常散。后来改成四段式你是我的生活调度员。 任务目标从以下缴费记录中找出未来30天内到期的项目并生成提醒清单。 输入材料粘贴短信和网页截图提取的文本 输出要求按“项目名称 | 到期日 | 预估金额 | 支付方式”的表格输出如有不确定项标“待确认”。 注意点不要把已过期的项目列进来。效果立竿见影每次输出的格式都基本一致我甚至可以把它直接转发到家里群里基本不用改。所以如果你也想搭自己的家庭系统我强烈建议一开始别追求模型聪明先花半小时把提示词模板打磨好。同一套模板用在本地模型和云端模型上输出都能稳定很多。这是我整个项目里性价比最高的半小时。3. 实操过程四套工作流的搭建实录有了模型层真正的“系统感”来自于工作流。我从需求里挑出四套最常用的组合每套都经历了从“想法”到“脚本”到“日常稳定跑”的过程下面是我的搭建实录。3.1 信息消化员把群公告和长文章变成摘要卡片这个模块最早启动因为需求最痛——家里微信群里的通知密密麻麻物业发的停水通知、家长群布置的作业、亲戚转发的中老年养生文章全混在一起。我不想被信息轰炸只想知道“哪件事需要我处理”。我当时的实现路径是用 FreshRSS 把公众号和博客订阅好再写一个定时脚本把当天未读的文章抓下来交给模型生成摘要然后推到微信群机器人。这里有一个关键决策推送的形式。我测试过两种一种是长文摘要直接全文发群里另一种是生成“一句话结论 行动建议”的摘要卡片。最后我选了后者因为家里人根本没耐心读长摘要他们需要的是“停水了”“明天要带户口本”这种一眼能扫到的结论。脚本核心代码很简单思路就是三步抓取 → 调API → 推送。我贴一段伪代码框架import requests # 1. 从数据库拉取未处理文章 articles get_unread_articles() for art in articles: # 2. 调云端模型生成摘要 prompt f你是信息消化员。目标压缩为一句话结论和两条行动建议。输入{art.content} summary call_llm_api(prompt) # 3. 推送摘要到家庭群机器人 push_message(f {art.title}\n{summary})运行实测一篇文章从抓取到推送大约5秒每天固定跑三次早中晚成本几乎可以忽略。这模块最大的经验是摘要的质量取决于你给它划的重点而不是它自己抓重点。我一开始没有在提示词里点明“只提取和家庭生活相关的信息”结果它连着三天把一篇关于程序员招聘的技术文章摘要推到了家庭群家人差点以为我要跳槽。加了限定词之后这种乌龙就基本消失了。3.2 生活调度员把邮箱、日历和缴费单串起来生活调度模块解决的是“什么时候该干什么”。我从最痛的需求入手家庭缴费和孩子的兴趣班时间。实现的思路和第一个模块类似但输入源不同。我拉了一个简单的数据源列表邮箱里的电子账单、手机日历里的日程、一张手工维护的家庭缴费Excel表。然后用一个“每日晨检”脚本每天早晨七点跑一次读取未来7天的日历事件生成“今日安排”清单。扫描邮箱收件箱识别账单主题提取到期日期。和Excel表比对找出30天内到期的项目生成提醒。这个流程跑通后我对“调度层”有了新的理解它不需要很聪明但必须准时、不漏、不重复。为了做到不重复我给每个提醒加了“状态字段”已提醒、已处理、已过期。不然同一个缴费单会被每天提醒家人都快被我逼疯了。实测调整了三轮最后的状态机很简单未处理 → 已提醒 → 已确认。看起来没啥技术含量但对于家庭这种低频需求足够用了。这里还要分享一个避坑点不要再让AI对Excel表做自由发挥。我最早让AI自己判断“哪些缴费项目要提醒”结果它经常把“上个月已付”的项目也算进去。后来我在提示词里明确规定“只检查状态字段为‘待处理’的项”就再没出过错。AI擅长的是整理和摘要而不是替你拍板“这事重不重要”。3.3 家庭记忆库让AI“认识”你的家RAG轻量实践这应该是整个系统里听起来最“硬核”的模块但我用了一个很轻量级的方式实现了“最小可用版”。先解释一下RAG检索增强生成。通俗讲AI平时像一个满脑子都是常识但对你家一无所知的新管家RAG就是塞给他一个“家庭档案本”他碰到问题先查档案再回答。完整的RAG涉及文档切分、向量化、向量存储、召回排序听起来很吓人。但对于家庭场景我找到了两条实际路线路线A轻量替代把家庭常用资料整理成几个Markdown文件——说明书、证件清单、药品清单、家装记录、菜谱。然后在给云端AI的提示词里附上相关文件内容让它“参考以下资料回答”。这本质上就是“伪RAG”靠把上下文塞进API实现。优点是零成本、零搭建缺点是文件一多提示词就装不下了。路线B真·入门级RAG用本地的Ollama 一个向量库把文档切块后变成向量存起来。用户提问时先在向量库里搜索最相关的几段连同问题一起交给模型。我用的是Chroma数据库和现成的嵌入模型代码非常少from sentence_transformers import SentenceTransformer import chromadb # 生成文档的向量表示 model SentenceTransformer(paraphrase-multilingual-MiniLM-L12-v2) # 存进Chroma collection.add(documentsdocs, idsids, embeddingsembeddings) # 查询时先向量检索TopK相关文档再把这些文档拼进提示词这套方案跑起来后效果非常“惊艳”又“真实”。我第一次问“上次给车换的空调滤芯是什么型号”它准确从档案里给出了答案因为我早就把四儿子店的保养记录截图存进了知识库。但我也发现了两个没料到的问题一是中文资料的分块位置很影响召回同一段话被切成两半检索就漏了二是模型的答案容易“一本正经地胡说八道”明明档案里没写的内容它可能脑补。所以我在提示词里强制加了“若档案中没有相关内容请直接说不知道”。如果你不想折腾代码我推荐一个更符合家庭场景的折中方案用支持文件上传的云端AI产品把家里资料整理成文档上传然后在对话里明确要求“基于我上传的资料回答”。实测大多数主流平台都能做到反正我自己后来好多场景就是用这种方式省下了一堆维护工作。自己搭RAG更像是一次学习之旅让我理解了原理但“最小可用系统”其实不需要那么复杂。3.4 例行自动化把整个家的一天压缩成一张日报我把前三个模块缝合在一起的“总装车间”是一个每天早晨自动推送的“家庭日报”。一开始我有两个选择用n8n这类可视化自动化工具搭建全流程还是用系统自带的定时任务加Python脚本。我最后选了后者因为n8n固然配置方便但对家庭这种“三天两头要改需求”的场景图形化节点反而让人眼花缭乱改一处逻辑要找半天。反过来脚本版虽然“土”但逻辑全在眼前改起来直截了当。我的日报形态大概是这样今日天气小雨记得带伞 今日安排 09:30 孩子乐高课带水杯 19:00 小区停水提前储水 待办缴费 · 水费 7月账单预计80元8月5日到期 家庭备忘 · 空调滤芯已记入档案下次更换时间6个月后整个日报的生成流程用cron定时器在早上7点跑一次0 7 * * * /usr/bin/python3 /home/pi/family_bot.py /home/pi/family_bot.log 21脚本做的事情说穿了就是“按顺序调用前面写的函数”先读天气API再调日历读今天安排再查Excel表里的待缴账单最后把这几段文本拼在一起发给家庭群。重点在于模块之间通过“临时文件”而不是直连数据库传递数据这样任何一个环节出错我只要看日志就能快速定位不会出现“因为知识库挂了导致天气也发不出来”的连锁故障。实测下来这套自动化最耗时的不是写代码而是调试“家庭日报的措辞”。我老婆第一次看到日报时说“你弄了一堆代码就为了早上给我发条信息微信里本来就有天气啊。”这句话点醒了我——自动化的价值不在“多了一个信息渠道”而在“把分散在不同App里的信息聚合到一个地方并且附带判断”。后来我在日报里增加了“今日是否需要特殊行动”这栏把停水、放假、堵车预警这类高优先级信息提取出来家人对日报的依赖度才真正起来。4. 常见问题排查与避坑清单任何系统跑久了都会出怪问题家庭AI系统也不例外。我把这两个月遇到过的典型问题整理成一个排查表算是给自己备忘也给后来者一个少走弯路的参考。4.1 本地模型响应慢卡死几分钟这个我遇到过两次一次是启动时加载模型很慢一次是同时跑了两个大模型导致内存耗尽。排查思路很直接看任务管理器内存占用是否超过90%再看模型量化等级Q8比Q4慢不少再看是否有其他程序抢显卡。实测发现浏览器开了一堆标签页时显存被浏览器“偷走”一截给模型留下的可用显存就捉襟见肘了。解决办法分三步关无关程序、换量化更低的模型、在Ollama的启动参数里显式限制上下文长度Ollama里叫num_ctx。我之前默认上下文是4096后来改成2048响应速度快了接近一半代价是能接受的“输入材料上限变短”——家庭场景通常不需要超长上下文。4.2 模型输出质量忽高忽低同一个问题两次答案不一样这种问题几乎必现因为大模型的采样机制天生带随机性。我不追求“每次都一模一样”但追求“每次都符合格式”。做法是把生成温度调低常见API和Ollama都支持temperature参数一般在0.2~0.4之间同时把提示词里的输出要求写到很细甚至给一个“输出模板”。另一个好用的技巧是让模型“先思考再回答”在提示词里加“请先整理步骤再输出最终结果”很多本地模型在复杂任务上的表现会明显改善。说白了模型偶尔犯迷糊不可怕可怕的是你用不可控的方式调用它。4.3 隐私与成本几个被忽略的雷区安全这块我格外重视毕竟家里的事不想外传。我给自己定了几条铁律绝不把身份证号、银行卡号、完整医疗报告发给云端模型。需要处理这些内容时一律走本地模型方案。云端API用量做预算。家庭场景每天几十次调用token量其实很小但我还是设置了一个月度限额提醒防止哪天脚本失控疯狂调用账单吓人。本地部署不是绝对保险。Ollama默认开放局域网访问如果家里有其他设备连同一个Wi-Fi最好给API加一个访问令牌或绑定本机回环地址别让“邻居家的设备”也能调用你的模型。这个细节很容易被忽略特别是在某些路由器默认AP隔离没开的情况下。还有一个容易被忽视的成本是“调试时间”。我最初总想一鼓作气全搭完结果每个模块都调得不精细。后来我换成“一次只调一个模块稳定了再动下一个”的节奏整体效率反而高了很多。这套系统的真正价值其实不是你下载了多少AI工具而是你愿意花多少心思把工具嵌进日常的琐碎里去。4.4 避坑清单速查表问题现象核心原因我的处理办法本地模型要等半分钟才回复模型太大 / 上下文太长 / 显卡被占用换7B量化模型、限制num_ctx、关掉占用显存的程序摘要内容偏题提示词没限定范围在提示词里写明“只提取与家庭相关”的限定条件知识库问答时胡编向量检索没召回或模型过度自信加“不确定就说不知道”的条件并检查文档切块是否断章取义提醒反复推送同一件事状态没有标记“已处理”给提醒逻辑加状态字段已提醒的自动静默家里宽带断网后系统瘫痪全部依赖云端API核心日程提醒切换到本地模型云端仅做增强路由这张表里的每一条都是我实际折腾出来的不一定适合所有人但如果你准备搞一套类似的系统应该有至少一两条能帮你躲开我踩过的坑。最后再分享一个我坚持到现在的小习惯给这套系统单独建一个日志文件夹凡是我改过提示词、换过模型、修过脚本都随手记一笔时间与改动原因。家庭AI系统和公司项目最大的不同是你没有一个“产品经理”帮你记住需求变更——你自己就是产品经理、开发者和运维。日志虽然随手但回看时能帮你厘清“为什么这里要这么做”不然过一个月你再回头看自己写的脚本大概率会一脸茫然。踩过几次坑之后我越来越觉得这套系统的上限不是由模型智商决定的而是由你对家庭需求的观察细致程度决定的。AI只是那个任劳任怨的管家真正定规矩的还是你自己。