Hishob：本地AI家庭财务仪表盘，隐私优先的记账方案

当记账遇上本地大模型

大多数记账应用只盯着一个交易账户，但家庭财务远不止于此——房贷、对冲账户、各类账单和纸质文件之间的关联，才是真正影响现金流的隐藏线索。开发者Koustubh在Dev.to上分享了他的开源项目Hishob（马拉地语意为"账目"），这是一个运行在家庭局域网内的财务仪表盘，用本地AI模型自动发现"钱都花哪了"，并给出可执行的建议。

据作者介绍，Hishob属于"gharasathi"（家庭AI）系列的一部分。早期版本跑在一台6GB内存的迷你主机上，使用3B小模型；随着需求升级，硬件换成了Mac Studio（M3 Ultra，96GB统一内存），本地运行Qwen3.5-122B-A10B模型。所有推理都在家中完成，银行流水和账单PDF不出门。

Hishob界面概览

架构拆解：五个马拉地语命名的微服务

整个系统采用Go、Python和React混合栈，部署在k3d（Kubernetes轻量发行版）集群上，核心数据存储为Neo4j图数据库和Postgres。每个服务都有一个马拉地语名字，功能分工明确：

aapla-dhan（"我们的财富"，Go）：通过澳大利亚消费者数据权（CDR，开放银行）同步银行账户到Neo4j，手动触发、每周一次。
aapla-patrakar（"我们的记者"，Go）：从Gmail标签文件夹和Nextcloud投递目录读取账单与对账单。
aapla-olakh（"我们的识别"，Go）：手写PDF解析器，提取字段并验证文档自身算术。
aapla-hushar（"我们的聪明人"，Python/FastAPI/LangGraph）：规则检测器、夜间AI分析师，以及聊天助手anna。
aapla-hishob（"我们的账目"，React）：前端仪表盘。

只有两件事需要出网，且都是只读：银行CDR接口和Gmail IMAP。其余全部在Mac Studio上本地推理。

澳大利亚消费者数据权（CDR，Consumer Data Right） 是澳大利亚政府推出的开放银行制度，于2020年起分阶段实施。它赋予消费者以机器可读格式安全获取自己银行账户数据的权利，并可将这些数据共享给经认证的第三方服务商。与传统的屏幕抓取不同，CDR通过标准化的API提供读访问，数据包括账户余额、交易明细、直接扣款和定期付款等。服务商必须通过严格的认证（如ACCC的认可）并遵守隐私与安全规范。Hishob利用CDR同步银行数据，意味着它拿到的是一手结构化交易，而不是解析网页或PDF的二手结果，这解释了为何其"支出只算一次"的规则能够可靠执行。

k3d 是在Docker容器中运行k3s（轻量级Kubernetes发行版）的工具，用于在单台机器上快速创建多节点Kubernetes集群。相比完整的Kubernetes，k3d启动快、资源占用低，非常适合家庭实验室或本地开发。Hishob把五个微服务部署在k3d上，既获得了Kubernetes的声明式部署、服务发现和滚动更新能力，又不必维护一整套生产级集群。对于运行在Mac Studio上的个人项目而言，这是一种在工程规范与资源开销之间的务实折中。

全账户视图：不只是记账，而是资产负债表

Hishob的差异化在于它把日常账户、对冲账户和房贷放在同一张图里。作者列出了几个关键设计：

支出只算一次：账户间转账、转入对冲账户不算支出；房贷本金算储蓄（增加权益），利息算真实成本。
利息与现金挂钩：对冲账户余额与实收利息并排展示，作者观察到对冲账户余额最高的月份，日均利息下降约五分之一。系统还会标记"躺在日常账户里本可对冲利息"的闲置现金。
房贷可建模：余额、对冲、还款额和估算利率都来自数据，"多放1万澳元在对冲账户会怎样"变成了计算而非猜测。
退款与冲正匹配：退款自动匹配原支付，不会误判为额外收入和支出。
不做虚假的"完整月份"：每个银行数据源独立同步，仪表盘只把数据视为完整到最旧账户的最后一笔交易，避免某个滞后数据源让当月显得"便宜"。

半自动的数据入口：刻意保留人工控制

作者明确表示Hishob不是全自动的，这是有意为之。银行交易每周手动触发同步；账单转发到专用邮箱后，Gmail过滤器按类型打标签（如gharasathi/utilities、gharasathi/childcare），夜间任务只读这些标签；其他文件投放到Nextcloud文件夹。日常操作只有两步：收到账单转发一下，每周按一次同步。

所有数据落入Neo4j知识图谱，一笔扣款、它支付的账单以及账单上的明细行彼此相连。作者强调这不是随意堆节点，而是一个小本体（ontology）：固定的节点类型和关系词汇表，只允许列出的关系，比如不允许泛泛的LINKED_TO。这带来三个好处：本地模型生成Cypher查询更可靠；每个Fact都指向来源PDF，证据成为结构的一部分；本体不限于金钱，通信→文件→PDF→事实→实体的模式同样适用于保险续期或医疗信件。

本体（ontology） 在计算机科学中是对某个领域中概念、属性及概念间关系的显式形式化描述。在知识图谱语境下，它通常定义允许的节点类型（如账户、账单、支付）和关系类型（如PAID_BY、BILLED_TO），并约束哪些组合是合法的。Hishob采用"小本体"，即刻意保持类型和关系词汇表精简固定，不允许泛泛的LINKED_TO这类无信息量的边。这种做法借鉴了语义网和知识工程的经验：约束越明确，图上的推理和查询越不容易产生歧义。对本地小模型而言，生成Cypher查询时可选的关系词汇越少，幻觉出不存在关系的概率越低；同时每条Fact都能沿本体定义的关系回溯到源PDF，使证据链成为数据结构的一部分而非事后附加。

亮点功能："anna注意到了什么"

仪表盘底部每天早晨生成一份按优先级排序的发现列表，部分来自确定性规则（涨价、未付账单、补贴缺口），部分来自夜间AI分析师。每条发现都附带证据，并提供两个按钮：Explain（anna阅读发现、调取底层数据、用平实语言解释发生了什么和怎么办）和Resolve（标记"不是问题"，夜间编辑会学习降低类似发现的排序）。

作者分享了三个真实案例：

"我们付了两次账单吗？" 同一笔电费一周内两次扣款，单看银行流水像重复扣费。Hishob读到账单原件并匹配银行记录后发现，第一笔被银行退回，第二笔才是真实支付——一笔账单，只付一次。
不知不觉损失的育儿补贴：澳大利亚儿童保育补贴每年每童最多覆盖42天缺勤，对账单显示已超限。Explain说明2月就已超限，之后每个缺勤日都按全价收费。后续提问"今年用了多少缺勤日，再多一天要花多少"也得到了答案，现在有规则在触及上限前预警。
上下文改变建议：一条建议提出协商房贷利率，作者补充数据不知道的信息——贷款是固定利率，且贷款价值比意味着新贷款方会收取房贷保险（LMI）。答案随之改变：再融资要再付LMI，固定利率重新定价有违约金，真正的杠杆是对冲账户里多留现金。

核心原则：代码计算，模型解释

这是整个系列最重要的设计约束。作者在第一季用3B模型时就学到，到122B依然成立：模型从不做金钱加法。所有总额、平均值和匹配都由代码计算，模型拿到精确数字后做它擅长的事——发现关联、解释原因、建议行动。随后事实核查器会拒绝任何包含无法追溯到数据来源的金额或百分比的发现。

夜间流水线大致是：01:30读取并归档新账单；每小时在数据变化时运行约二十个确定性检测器；02:30 AI分析师读取代码构建的"事实包"并撰写发现，再经事实核查和编辑；早晨仪表盘和anna呈现结果。

事实核查器（fact-checker） 在这里是一个独立的验证层，位于模型输出与用户界面之间。它的工作方式是：模型撰写的每条发现中若出现金额或百分比，核查器会尝试将这些数值追溯到"事实包"中代码计算出的具体字段或源PDF中的条目；无法建立追溯关系的数值会被拒绝，整条发现可能被丢弃或退回重写。这与检索增强生成（RAG）中的"引用校验"思路相近，但更严格——不仅要求有出处，还要求数值本身由确定性代码产生而非模型推算。由于大语言模型在算术上并不可靠，这种"模型只做语言、代码只做数字"的分工，使系统在保持自然语言解释力的同时，避免了AI财务建议中最危险的错误类型：看似合理但算错的数字。

这套方案意味着什么

Hishob的价值不在于用了多大的模型，而在于展示了一条可复制的路径：数据留在家里，能力足够的模型跑在旁边，本体留有扩展空间。作者在结尾提到，金钱只是起点——任何留下记录的家庭生活领域都能套用同样的模式：代码负责计数，模型负责解释。对于关注隐私、又希望获得AI分析能力的家庭用户来说，这是一个值得参考的开源实践。

系列后续将覆盖如何在Mac Studio上运行Qwen3.5-122B并保持诚实（第二部分），以及不用AI读取账单和对账单的发现（第三部分）。