九天交付家庭财务应用的 AI 编程复盘

用 AI Agent 做家庭财务系统，九天能做到什么程度？作者交出的 Keepard 已经接入多国银行、自动归类交易、汇总资产，并让夫妻两人连续近两个月每天使用。但真正值得看的不是开发速度，而是这套系统怎样被约束到可用。

这份复盘给出的结论是：代码可以交给 Agent，业务边界、验收和运维仍要有人负责。约 2,700 美元的 API 折算成本中，72% 花在重读上下文，生成代码只占 13%。对前端和全栈开发者，这比「九天上线」更有参考价值。

九天交付，靠的是持续验收

作者是软件公司的 CTO 和联合创始人。他想解决的事情很具体：家庭账户分散在多个国家、多个银行，每月都要花一个晚上整理 Excel，还经常拖延一两周。

Keepard 把这项工作拆成交易采集、支出核算、分类和资产汇总。乌克兰 Monobank 通过个人 API token 接入；Wise、Revolut 和部分欧洲银行通过 Enable Banking 接入。作者称后者对个人自有账户免费，授权走银行自己的同意流程。其他乌克兰银行则没接通：形式上有开放银行服务，普通个人账户实际用不了。

这个前提很重要。它证明的是作者这组账户能够接入，不能据此推断国内银行卡也能照搬。

开发发生在 9 月 11—19 日，共九个自然日。仓库产生了 643 次提交、约 200 个已合并 PR、61 次数据库迁移和 659 个测试。作者每天投入约 3—4 小时，负责终端命令、配置、外部服务注册，以及查看和纠正结果。

前两天使用 Codex，48 小时产生约 4,000 条响应，也耗尽了两次周订阅额度，其中一次来自获准重置。第三天起换成 Claude Code，后七天产生 10,930 条响应。这里的响应数不是用户指令数：作者共发出 446 条提示词，中位长度只有 26 个词，还经常用语音输入。

提示可以很短，因为后面跟着反馈。作者会拿手机实际操作，再指出哪里不对。一次「电脑又热又慢」的抱怨，最终查出十个并行 git worktree 让 macOS 索引器面对 160,000 个文件，其中包括 node_modules，随后补了安装后排除索引的脚本。

Agent 的「完成」只是待验证的结果，手机上的实际操作才是验收的一部分。

财务系统先把账算对，再让模型分类

Keepard 没有把所有资金流出都算成消费。本人账户之间的转账、投资和非家庭支出要排除；退款要冲减原有支出，不能另记一笔收入。否则报表做得再漂亮，也会把家庭开销算错。

分类按三层处理：先匹配商户和描述规则，再利用系统已有记录，最后才调用模型。无法确定的交易通过 Telegram 询问夫妻双方，趁人还记得用途时补齐信息。

模型适合处理描述含糊的交易，不适合决定金额运算。作者把这些边界写进 AGENTS.md：

• 银行访问只读，不付款、不转账。
• 金额存为最小货币单位的整数，不用浮点数。
• 自有账户之间的转账不计入支出。
• 模型只建议类别，算术由普通代码完成。
• 人工判断优先于模型结果。

作者说，这些规则都来自实际返工，写入后没有再次出现。但原文没有提供规则覆盖率或分类准确率，不能把这段经历当作可靠性证明。

分析页支持按类别、时期、归属人和币种查看，汇率采用当天数据；每个数字都能点进底层交易。月度与类别交叉的表格，则帮助用户看清开销集中在哪里。

资产页另行汇总账户、存款、券商、加密资产和现金，统一币种，每月保存快照。银行余额自动更新，其他资产通过数据源或每月手填补齐。它也支持 PWA、Telegram 收据附件和现金记账，不过作者明确说，收据和现金很少使用，其他功能才是每天在用。

上下文贵，就要减少重复解释和返工

按 API token 价格折算，开发约需 2,700 美元，其中 72% 用于模型重读代码库、文档和对话历史，生成代码只占 13%。作者实际支付的是每月 100 美元的 Claude 订阅，而且还用于其他工作。

两者不能混为一谈：前者是折算成本，后者是作者的实际付款。原文也没有拆解剩余 15%，或提供可直接复算的计费明细。

降低成本的重点因此落在约束上。最初的前端有五份金额格式化逻辑、22 个手写 select，各页面颜色也不统一。作者随后以 Tremor 为视觉参考，在已有 shadcn/ui 和 Tailwind 上整理设计套件，没有安装 Tremor。

套件包含一页 DESIGN.md、组件索引、手机与桌面截图脚本，以及自动检查：组件里不能出现十六进制颜色，金额格式化只能放在指定文件，bundle 不能超过 150 KB。前端随后在一夜间分六阶段重做。

这些措施让 Agent 有统一词汇和明确边界。不过，150 KB 是项目门槛，原文没有说明是压缩前还是压缩后、总包还是入口包，不能直接拿来当通用标准。

技术栈是全程 TypeScript，后端 Node、PostgreSQL，前端 React、Vite、Tailwind、shadcn/ui，Playwright 负责截图和端到端检查，Docker 部署。作者建议起步时固定语言、框架、数据库和组件库，再用一个命令统一执行类型、测试、lint 和体积检查，但没有给出具体命令。

协作流程也有边界：实现 Agent 各自在 git worktree 工作，不提交、不推送、不接触密钥，只返回 diff；编排 Agent 审查并运行检查后合并。SSH、push、发布脚本等权限提前列明，部署仍需作者确认。他还建议在容器里开发，以缩小自动执行的影响范围。

运行侧则用健康页检查银行导入、Telegram worker、备份、授权到期时间和 AI 预算，并显示最近事件距今多久。

VPS 每月约 10 欧元，还与另一项目共用；分类器在 OpenAI 上设每月 10 美元硬预算，健康页标出 0.50 美元缓冲。请求发送前先预留费用，避免只在事后发现超支。系统每天把加密备份存到独立存储，模型接触支付描述，不接触完整账单。

我的判断

这份复盘最可信的部分，是作者没有把「生成代码」当成交付终点。账务规则、统一组件、可追溯数据、预算和健康检查，才让演示页面变成了持续使用的工具。

但「九天做完」有很强的前提。作者有技术和产品判断能力，需求来自自己的家庭，使用者少，银行接入范围明确。他没有认真比较现成产品，也没有给出人工开发、其他模型或不同 Agent 流程的对照数据。所以它更适合作为个人工具的经验报告，不能用来推算一般团队的交付周期。

659 个测试和约 200 个 PR 能说明工作量，不能单独证明质量。数据存在自有服务器、备份加密，也不能自动等同于安全保障。作者承认这不是银行级安全，原文没有展开安全审计和恢复演练。

相比只写长提示词，我更赞成把规则变成检查、把金额计算留给确定性代码。不过，文档写入后「错误再没发生」仍是作者的观察，不能替代程序校验。最后提到的 InHouse AI Starter Kit 才刚用于两个内部项目，也还谈不上经过广泛验证。

能拿来做什么

• 开始个人全栈工具前，先验证最难的外部接口是否真的可用，再固定技术栈和验收入口；尤其别把某家银行可接入当作普遍条件。
• 用 Agent 做 React 页面时，先准备设计规则、组件索引和手机截图检查，再让它扩展页面，减少重复组件和整站返工。
• 在 Node 中处理金额和分类时，把整数存储、转账排除、退款冲减和人工覆盖做成程序规则，让模型只处理不确定的描述。
• 给持续运行的 AI 工具同时加上费用预留、硬预算和健康页，让调用成本、任务停摆、授权过期和备份异常都有明确入口可查。