开发者自建AI原生私有贾维斯式家庭系统 分析落地难点

我这几个月一直在给自己家开发这种，AI原生私有系统。说说这种产品对于我们来说，都想要，都想尽可能的私人定制化，完全把自己变成超级个体，一个贾维斯似的存在是不是？

然后夏天到了，我暂时需要做一些硬件，一些家具，去把这个系统应用的基础设施给准备好。

好，现在说这个系统的问题，以及为什么离用户还太远。

按照这个原帖子，你都能猜出来他们做了什么技术。一个调用大模型中枢+一些简单硬件，最多就是存储和音箱。靠上下文来完成所谓的“智能”。我就简单说一下3个层面，就不可能产品化： access layer, 模块化，长期记忆。

Access layer 首先真正如我们这样的严肃用户，是不可能靠“聊天”来完成个性化和所有信息输入的。开玩笑，自己已经忙成狗了，还每天告诉你我明天想吃啥。我期待智能中枢推导我安排做饭的唯一两个入口就是冰箱的传感器和我记得上传的超市购物小票。

Access layer 一定是一个非常routine, 严肃的，自动化的流程。比如我有一个专门为这个系统设置的邮箱，我转发到这个邮箱的邮件都是账单，孩子学校的通知等重要邮件。这些邮件需要你自动读取，对象化，什么是日历对象，什么是账单对象，什么是重要备注对象。我就干一件事情，那就是转发，后续流程给我自动做好，排优先级，十分有必要的时候才做成notification审核。

还有一种access是OCR和相机拍照，比如一些纸介质的账单，税表，和我需要管理的街机/homelab库存。这些也很严肃，需要长期存档保留原件。反正，只要录入，都是严肃和昂贵信息，不是老大爷随口聊天。谁没事闲着和AI聊天。

模块化 这个是最重要的一个内容。散漫聊天，散漫上下文，文档式上下文，连个数据库都没有，连user都不创建，更别提user的权限了（难道家长和孩子是一个权限？）是不可能创造任何能够管理人生和家庭这种复杂性度的AI系统的。

日历需要，会计账单流水需要模块，税务需要模块吧。这些模块如果共享所谓的松散上下文，那就是一团浆糊。所以模块之间，Access layer和模块间，需要创造一个投递机制，去把关联的信息投递过去。如果能做到每年快到报税的时候，一键输出所有税务相关的信息和这些信息的原始凭证，那才叫勉强合格。

长期记忆 全靠上下文？上下文啥玩意现在我们应该玩清楚了。我有一个库专门收这种Context Object, 我管他叫loose pool, 松散的，水池子。哪家公司的档案室的文档是松散水池子？任何有价值的信息必须是高度精炼，结构化，被纠正过的，有完整时间线状态的信息。这些信息需要提炼，规整，进入一个安全的存储地，不是云就是NAS。那么这些内容的提取，又是一个重要功能。

真的能用的，还需要跟这个家庭的“物理”系统关联，传感器，IoT智能家居，如果有库存需求，还需要配上合理的家具，几百个元器件，需要有序储存，AI需要规则，你不能乱放然后给他拍个照。所以我天天在做家具啊。

总结： System is larger than the model， 系统大于模型。模型是可替换的，但是系统内部的协议需要逐渐稳定下来。协议和系统稳定，我不管外面中美模型斗成啥样，对于消费者都是有利的。推动人类进步，人均贾维斯了。

刚才和一个推友在说这件事情，您说的非常正确，比如摄像头，什么叫“多快好省”呢？我如果全分析，那耗死我的token了。

但是我如果把我最核心的问题定位了，比如我家的问题就是住家/homelab在一起，homelab有大量需要维护游戏机的工具比如万用表示波器，还有入库出库需要和游戏机绑定的元器件和主板。这些东西都不知道放在那里。我专门做的几个储存架子，摄像头对准他们，需要的时候再拍照，去找，配合标签系统，那就是“多快好省”系统。