App+1 | Coast：用十年经验，给记账这件事一个「终点」
Matrix 是少数派的写作社区，我们主张分享真实的产品体验，有实用价值的经验与思考。我们会不定期挑选 Matrix 最优质的文章，展示来自用户的最真实的体验和观点。
文章代表作者个人观点，少数派仅对标题和排版略作修改。
AI 使用声明：文中部分解读引用 AI 进行解读分析，截图中部分生成的素材和本文的题图使用 Codex 生成。
在项目刚开始的时候，AI 就非常明确地说不建议做，因为记账这个赛道红到发黑😂，产品五花八门，功能大同小异，而且用户迁移成本巨大——大部分人不会因为你是新 App 就抛弃用了好几年的记录。更何况我自己在用的记账 App，在功能层面已经完全满足需求了。
但我还是做了。因为记了 10 年账之后，我发现了一些现有 App 都没有解决的问题。这些问题不是「功能缺失」，而是「记了这么多数据，然后呢？」这也是我决定自己做一款记账 App 的初衷。
记了 10 年账，我到底记明白了什么
从入不敷出开始
记账的起点是大学。当时我每个月的生活费都不够花，频繁向家里要钱又很不好意思。其实我的生活费在同学当中不算少，只是我自己大手大脚、没有规划。为了改善这种情况，我开始记账，初衷很朴素：至少别再月光，能攒下一点钱。这一记就记到了现在，早已变成了一种习惯。
记账让我知道了每一笔钱都去了哪里，但也给了我一种「记下了就尽在掌控」的错觉。实际上，我并没有因为记账而改变消费习惯，入不敷出的情况时有发生，甚至在毕业后还出现过向朋友借钱还信用卡的糗事。
渐渐地，我也开始反思：记账到底在记什么？记下的账要怎么用？ 前一个问题，我用了好几年时间慢慢想明白；后一个问题，则要等到很久以后。
🤖 来自 AI 的讲解：
这其实符合行为经济学中的一个发现：单纯的信息记录并不会自动改变行为。Daniel Kahneman 在《思考，快与慢》中指出，人类的消费决策大多由「系统一」（直觉）驱动，而记账属于「系统二」（理性分析）的范畴。要让记账真正发挥作用，需要将记录转化为可操作的反馈。
我的记账方法论：能不记就不记
先说第一个问题。我最初记账是事无巨细的，一瓶水、一次地铁都单独一笔，账户也按银行卡一张张分开。数据看起来很完整，但复盘的时候特别琐碎，一个月下来根本看不出什么，久而久之就懒得看了——记了那么多，最后没起到任何作用。
所以用最简单的一句话总结我 10 年的记账心得就是：能不记就不记。有些记录到最后你会发现根本用不着，不如一开始就省掉。具体到做法，主要是三件事。
第一件是减少账户。我有段时间把每张信用卡都单独建了账户，结果永远跟银行对不上账，后来想明白了，不管记得多精确，最终还款金额还是以银行 App 为准。于是我把 5 家银行的信用卡合并成一个账户，甚至把微信和支付宝也合并了，现在日常只在储蓄卡、信用卡、微付宝（微信和支付宝合并）三个账户之间选。
账户少了，接下来是合并消费。
- 地铁只用一卡通充值，一个月记一笔
- 咖啡店能充值的直接充值，之后每天喝都不用再记
- 春节来回发红包领红包不逐笔记，过完年校对一下余额就知道今年是赚了还是亏了
- 话费在某海鲜市场买大金额充值卡，既省钱又少记录
- 出去旅游，中间涉及 A 钱、外币、预约消费一堆乱七八糟的，我不会每笔都记，而是 A 钱单独算，其他不用 A 的（机票、签证、买衣服）直接记到记账中，外币换算完按完整消费记，最后合成一笔旅游花费就完事了
有几个合并消费都是在做减法，而最后一条对我影响最大的一个思路转变：按「性质」分类，而不是按「类型」。以吃饭为例，我的分类经历了三个阶段：
- 最初：「早餐、午餐、晚餐、夜宵、水果、零食」（按时间）
- 后来：「外卖、自己做、聚餐、超市」（按场景）
- 现在：「吃饭、聚餐」（按是否可以减少）
分类之所以一路这样变，是因为我发现自己看账的时候真正想回答的只有一个问题：如果我想省钱，哪些消费是可以砍的？答案是「聚餐」而不是「午餐」。交通同理，我现在只分「交通」和「打车」——「交通」是刚需，「打车」是可以选择不打的。
🤖 来自 AI 的讲解：
这种分类思路在个人理财领域有一个成熟的框架：将支出分为固定支出（Fixed）、必要支出（Needs）和弹性支出（Wants）。这也是 FIRE 运动中常用的分析维度——所谓 FIRE（Financial Independence, Retire Early），就是通过提高储蓄率、控制支出、合理投资，在传统退休年龄之前实现财务自由。
现在回头看，「哪些可以砍」这个问题其实已经在往 FIRE 的思路上走了：只有把支出按性质拆开，你才知道自己的储蓄率还有多少空间可以提高。这些思考后来也直接影响了我做产品时的分类设计。
但说实话，记账本身并不会帮你省钱或者多存钱。它的价值全在后续的分析——设预算、看趋势、找到可以优化的地方，然后真的去执行。如果只是记完就扔在那里，那记账其实就只停留在了记录。也就是说，「记什么」我想明白了，「记下的账要怎么用」依然没有答案。
那天我把账单发给了 AI
记账方法论越来越成熟，在用的 App 功能也完全够用。如果不是那天突发奇想，我可能不会动手做自己的 App。
我把多年的账单导出发给了 AI，让它帮我分析消费趋势，AI 也确实给出了很多有价值的消费指导和建议——「记下的账要怎么用」这个问题，好像第一次有了答案。
但问题是，如果我想持续获得这种分析，就得反复：导出 → 下载 → 发给 AI，流程非常割裂。
我突然意识到一件事：我已经积累了这么多年的消费数据，但这些数据除了告诉我「这个月花了多少钱」之外，几乎没有产生任何额外价值。 它没有告诉我哪笔钱该不该花，没有帮我做消费决策，也没有给我一个清晰的财务目标。
再往前追溯，长期记账中我还积累了两个痛点——没有目标和预算没用。没有目标的时候，记账就变成了机械动作，每个月记完一看又是月光，只是「知道了」而已。预算也试过各种方法设置，每次都得拉表格手动算，用不了几个月就废弃了。而且设置预算的过程显得非常「不专业」，预算总是超支或者不切实际。
数据没用起来、没有目标、预算没用，这三件事说到底是一件事：记账缺一个终点。既然已经有了 10 年的记账经验，也有了明确的痛点，那就 Vibe Coding 一个出来——于是就有了 Coast：为自由记账，一款围绕 FIRE 理念设计的记账 App。名字取自 FIRE 的一个变体「Coast FIRE」——当你积累了足够的本金，即使不再额外储蓄，靠复利也能在退休时达到财务独立。
我怎么设计 Coast 这款 App
整个 App 的框架建立在 FIRE 之上：记账的终点是财务自由，所有功能都围绕「离这个终点还有多远」来设计。下面先讲从 FIRE 长出来的几个核心功能，再统一说说其他的。
给记账一个「终点」——FIRE
FIRE（Financial Independence, Retire Early，财务独立提前退休）是这款 App 从头到尾的核心理念。我想大部分人都会想达到某种程度的这种状态——不用被工作绑定，可以做自己想做的事，同时也能正常生活下去。
🤖 来自 AI 的讲解：
FIRE 运动起源于 1992 年 Vicki Robin 和 Joe Dominguez 的著作《Your Money or Your Life》。FIRE 有几种常见的变体：
- Lean FIRE：以最低限度的生活开支实现财务独立，适合极简主义者
- Fat FIRE：在不降低现有生活水平的前提下实现财务独立
- Coast FIRE：已经积累了足够的投资本金，即使不再额外储蓄，靠复利增长也能在传统退休年龄达到财务独立
- Barista FIRE：可以做一份轻松的兼职来维持日常开支
记账 App 明明已经记录了所有的资产和负债，为什么不把这个目标直接算出来？所以我专门做了一个 FIRE 页面，把「距离财务自由还有多久」这个数字放在最显眼的位置。只要记录了资产总额，有了一段时间的消费数据，就能自动算出你距离退休的时间。
为了让这个数字更直观，我还做了两个功能：
- 敏感度滑块：可以拖动调整每月花费和收入，实时看到退休时间的变化。「每月少花 1000 元」能提前多久？拖一下就知道。
- 大额消费模拟：如果你有一笔计划中的大额支出，可以直接录入来看它对退休时间的影响。这也是一种「冷静期」——把想买的东西列出来，看看代价，过几天再决定。
每一笔消费都有「代价」
首页会展示距离 FIRE 的日期。当你记录每一笔消费，可以直接看到日期的变化——虽然消费已经发生了，但这种即时反馈会让你对花钱这件事有更直观的感受。
🤖 来自 AI 的讲解：
这在行为设计中叫做「即时反馈回路」（Immediate Feedback Loop）。研究表明，将抽象的财务数据转化为具体的、可感知的指标（比如「晚退休 3 天」），能显著提升人们对消费行为的觉察。传统记账 App 只展示「你花了多少」，而把花费转化为时间成本，则让每笔消费都有了可感知的「代价」。
分类设计：每一类钱在 FIRE 里都有角色
前面说的「按性质分类」的思路，直接变成了产品的分类体系。我把消费分成了固定支出、必要支出、弹性支出和其他支出四类，每一类在 FIRE 计算模型里都有明确的角色：固定+必要是 Lean FIRE 的基数，弹性支出是你能优化的主战场。
所以自定义分类也必须映射到一个 FIRE 角色——你可以随便改名字、换图标，但必须回答「这类钱在你的自由计算里算什么」。当然，在这个框架内你也可以按自己的需求细分。比如我就单独拆了「个人提升」和「旅游」两个一级分类，虽然本质上都属于弹性支出，但这两块对我来说花费大、值得单独追踪，混在一起就看不出各自的趋势了。
自动预算
FIRE 解决的是「没有目标」，另一个痛点「预算没用」，我用自动预算来解决。之前手动算预算的痛苦在于每次都得拉表格，所以这次干脆让 App 从历史数据里直接算出来。几个关键的设计决策：
- 用中位数不用平均数——平均数会把「上个月买了台电脑」固化成长期预算
- 全年预算优先参考去年同月——春节该高就该高，匀速预算是假的
- 可以在历史基准上再收紧一个百分比——预算的意义往往是「比过去花得少」，照搬历史等于把旧习惯合理化
说实话我一直觉得预算就是个参考，我自己也经常超。但有预算至少能看到消费曲线，心里有个概念，不至于完全随性。
其他几个功能
除了上面这些围绕 FIRE 的设计，还有几个功能来自我日常记账时遇到的具体问题。
同类商品的价格追踪——我在点同一家店的外卖时发现，同样的商品价格波动非常大，但我又记不住明确的金额。比如我常点的霸王茶姬大杯外卖，在「秋天第一杯奶茶」那天，领了券之后居然还比平时最低价贵了 7 块钱。如果不做专门的追踪，你根本不知道「正常价」是多少。所以我设计了针对同类消费的价格统计功能，可以看到某个商品的均价、最低价和价格走势。
附属消费——做 Coast 的时候我发现一个之前完全没想到的事：记账这件事居然还有文化差异。比如美国的小费文化，而且小费可以按百分比给也可以直接写金额，你刷卡的时候输入的可能只是一个小费比例，刷完了都不知道实际总共花了多少钱。这在国内几乎不存在，但如果你的用户里有海外华人或者经常出差的人，这就是刚需。所以我在记账面板里加了「附属消费」的设计——小费、税费、服务费这些可以灵活配置，不用每次都手动加减。这类需求说实话我自己一个人也想不全，后续肯定还会有更多「我没遇到过但别人天天碰到」的场景冒出来。
AI 接入
个人判断这是一个未来可能所有数据类产品都会做的事。AI 最擅长的就是处理和分析已有数据，而记账 App 天然坐拥大量结构化的个人财务数据。上面提到的这些功能不依赖 AI 就能实现，AI 后续可以作为进一步的增强——消费趋势分析、异常支出提醒、个性化的财务建议等。目前在关注苹果提供的端侧 AI 能力，计划后续接入。
Vibe Coding 过程中踩的坑
确定了要做什么之后，就开始动手了。这不是我第一个开发的 App，之前在 App Store 上架过一款 EON：订阅管理，纯免费，所有功能无限使用。EON 的功能不算复杂，但前后也开发了整整 2 个月——只开发功能可能 1 星期就做完了，剩下绝大部分时间都在优化 UI 和改 bug。到了 Coast，功能更多、逻辑也更缜密，AI 确实让开发这件事方便了很多，但 Bug 同样层出不穷，逐渐就变成了一边加功能一边改 Bug 的局面。也是在这个过程里，我发现 AI 开发本身有不少问题，踩了不少坑。
以下是我在 Vibe Coding 过程中总结的一些感悟，纯非技术出身的体会，如果有不对的地方欢迎大家补充和纠正。
别只甩一张截图问「你看这里对吗」
一开始做的时候，每次 AI 输出了不符合我预期的结果，我都非常喜欢丢一张截图发给 AI 然后破口大骂：「你看这里对吗，你怎么老是乱做」。然后 AI 就会态度诚恳地开始道歉，然后改出一个更让我崩溃的结果。
实际用下来发现，只有一些模型比如 Claude Opus 4.6 会反问你「没看出来哪有问题」，但大部分模型都是二话不说直接改。问题在于大模型对图像的理解跟人完全不一样，我们一眼就看出来有问题的地方，在它眼里可能压根不是问题，你强行让它改，它可能给你改出一个更离谱的结果。
所以跟 AI 沟通的时候一定要说清楚：圈出来哪里有问题，问题是什么，你想让它怎么改。如果你自己也不知道怎么改，可以让 AI 给你几个方案——但最好让它可视化地呈现出来，要不然光看文字描述很容易理解出偏差。
先建立设计规范
其实在 AI 时代之前，做 App 就得有设计规范来保持界面一致性，要不然看起来就像好几个不同的 App 拼在一起。到了 Vibe Coding 时代这件事更重要了，因为 AI 没有「全局审美」这个概念，它只管当前这个任务，不会自动跟其他页面保持统一。
我建议的做法是：在开发之前，让 AI 帮你整理一份设计规范文档，然后让它按照这个文档写一个你想要的页面，你反复修改调试到满意为止，之后所有新功能都必须参照这份规范来做。
否则 AI 会给每个新功能做一套新样式，最后拼凑在一起就是乱七八糟——卡片圆角不统一、图标样式种类繁多、字号也会越来越多。
这是我在开发 Coast 中发现的一件非常重要的事，因为 Coast 新加页面或功能模块非常频繁，特别离谱的是同一种类型的按钮都能写出来三种样式，我也是一边开发一边补规范，有时候忍不住回想要是一开始就把规范定好就好了。
推荐学一下 Git
如果你还没学建议先学，学完你就能体会到这段内容的价值。
最直接的收益就是省 token。有时候额度用完了但急着 push，你会指令的话自己就能直接操作，不用干等着额度恢复。同样 Git 的分支概念也能帮你少踩很多坑，尤其产品上线后，你的测试版最好不要用主分支，至少不能影响线上的稳定性。
🤖 来自 AI 的讲解：
Git 是程序员用的版本管理工具，你可以把它理解成一个无限次的「存档 / 读档」系统。对 Vibe Coding 来说，以下几个概念最值得了解：
- Commit（提交）：相当于游戏里的存档。每完成一个功能就 commit 一次，万一后面改崩了，可以随时回到这个存档点。
- Branch（分支）：相当于「开一条平行时间线」。比如你想试一个新功能，可以从主线拉一条分支出来折腾，做好了合并回去，做坏了直接删掉，主线毫发无损。
- Stash（暂存）：做到一半突然要切去修另一个 bug，但当前的改动还没改完不想提交，stash 可以把它们临时收起来，修完 bug 再放回来继续。
- Revert / Reset（回退）：AI 改了一大堆文件结果全是错的？一条命令回到上一次 commit 的状态，相当于读档。
- Merge（合并）：把分支上做好的功能合并到主线。如果两边都改了同一处代码，Git 会提示你「冲突」，需要手动选择保留哪个版本。
特别提醒：在 Vibe Coding 场景下，AI 经常会大面积修改代码，养成「每完成一个小功能就 commit」的习惯可以帮你在 AI 改坏东西的时候快速回退，而不是一句一句告诉它「把那里改回去」。
及时启用新对话
这个坑我是用真金白银踩出来的。之前一个跑了 7 天的对话，我在里面执行了一个任务，直接把 5 小时额度花了 78%，两个任务就花没了，一直到系统提醒时才发现。后来恢复额度问了 AI 才知道，因为这个对话的上下文太长了，每次交互都需要把之前所有的内容重新处理一遍，上下文越长消耗的 Token 就越多。所以建议做完一个阶段性任务就开新对话，可以在开启新对话之前让 AI 做一份交接文档，同时把设计规范、项目结构让 AI 先读取一遍，这样可以直接顺利开启下一阶段开发。
我现在维护 EON 的时候，基本上一个版本就开一个新对话，因为改动不大，一轮就能搞定。而 Coast 开发阶段改动比较多，我会按功能模块来划分对话——比如「做完 FIRE 页面」就是一个对话，做完就切新的，哪怕中间还有没聊完的话题。
🤖 来自 AI 的讲解：
Token 是大模型处理文本的最小单位，可以简单理解为「字数」。每次你跟 AI 对话，它都需要把当前对话的所有历史内容重新读一遍（这就是「上下文」），然后再生成回复。对话越长，每次交互消耗的 Token 就越多——不是线性增长，而是越往后越贵。这也是为什么长对话到后期经常出现额度突然被大量消耗的情况。
顺便分享几个我总结的省 Token 技巧：
- 任务可以批量发，但别一次塞太多——我试过一口气丢 30 个 bug 给 AI，最后检查发现有些压根没做，它自己就给「忘了」。体感下来一次 10 个左右比较稳，再多它真记不住。
- 需求没说清楚才是最大的浪费——你以为省了打字的时间，结果 AI 理解错了来来回回改三遍，每一遍都在烧 Token。多花两分钟把需求想明白，比什么技巧都管用。
- 截图记得裁剪——整屏截图发过去非常耗 Token，而且 AI 可能盯着一个你根本没想让它动的地方乱改。裁到有问题的区域再发，省 Token 的同时也省心。但记得说清楚是哪个页面啊，尤其是可能多个相似界面的截图。
- 别复制粘贴文档内容，让 AI 自己去读——直接告诉它「去读一下这个文件」就行，比如下文中两个 AI 协作的用法，不要把文档贴到对话里。贴进去等于上下文里存了两份一模一样的东西，纯浪费。
多 AI 协作
我实际在用的是 Claude 写代码，让 Codex 出图。如果中途需要生图的任务，直接让 Claude 把需求写成一份任务描述，然后让 Codex 来读这个任务去执行，完成后直接跟 Claude 说那边做完了，它就会自动读取结果继续干活。这样大大省去了反复沟通的成本。
我让 Codex 产出了包括 EON 的人格测试图和 Coast 的 3D 分类图标，都是 Claude 下任务、Codex 执行、Claude 读结果这一套流程。
同样还是为了省 Token，你最好让 Codex 先试跑几张图看看风格对不对，再执行完整的批量任务，要不然最后生出来的跟你想的差别很大，全白费了。
关于 Skill 的使用
说实话，我在开发这两款 App 时几乎没用过别人的 Skill，但我总结了自己的。实际上我已经做了 5 款 App，打算推上架的是 3 款（另一款还在开发中）。之前试过用 PM 的 Skill 写需求文档，写出来倒是挺像回事的——明确定义了哪些功能做、哪些不做，按照真实项目的节奏规划了产品排期。但问题是你在开发的时候，大部分功能都是想好了要做的，结果做到一半突然被告知「这个在产品规划里不是当前优先级」，挺割裂的。
后来我想明白了，Skill 真正解决的是重复场景下的固定流程。比如我在做 EON 时有一套发布流程：写更新日志、翻译成多国语言、同步到网站上，每次版本更新都要跑一遍，这才是适合做成 Skill 的东西——流程明确、步骤固定、反复执行。
如果要用别人的 Skill，我个人感觉是你不知道这件事该怎么做的时候，可以参考别人的思路，学习它的设计方法，然后总结出一套自己适用的。
题外话：做完 App 才是真正的开始
最后聊一点跟记账、跟 Vibe Coding 都关系不大，但我觉得比这两件事都更重要的体会。
开发一款 App 不难，花钱买苹果开发者账户上架也不难，最难的是运营。
我的 EON 从上架到现在主要就是在小红书发帖，其中有一篇「限时免费」收到了不少点赞和下载，然后就趋近于没声了。一方面是我没有找到新的宣传方式，另一方面最近工作比较忙，再加上开发 Coast 让我分身乏术，光是处理 EON 已有用户的反馈就占了大部分精力。不过我也经常在社区看到有人分享 App 上架后下载量只有几百，而我这款 App 在免费纯打赏的模式下，依然有 0.3% 的打赏率，已经远超预期了。
所以如何推广自己的 App，让别人知道你的产品是好的、是可以用的、甚至愿意付费——这是我在 Vibe Coding 之后需要持续学习和探索的方向。同时也是很多想加入开发大军的人应该提前想清楚的事：最好别头脑一热就上手做了一款 App，维护几个版本发现没人用就弃坑了。在动手开发之前，更应该先想清楚 App 怎么运营和推广。
回过头来看这整个过程——从大学时代入不敷出开始记账，到 10 年后发现记账数据没有被充分利用，再到用 Vibe Coding 把自己的想法做成了一款 App——我觉得这件事最有意思的地方在于：10 年的记账经验变成了产品设计的基础，而 Vibe Coding 让一个非技术出身的人有能力把这些想法实现出来。 这在以前是不太敢想的事。
结语
少数派是我十多年来一直访问的社区，这篇算是新号的第一篇投稿，希望对正在记账或者想要 Vibe Coding 的朋友有所帮助。
另外，记账是一件非常个人化的事情，以上文章中的所有内容均是本人生活体验思考，相信每个人要解决的生活场景不尽相同，但仍希望能够对你有所帮助。
我目前开发的两款 App 均已上架 App Store，欢迎大家下载使用。
KioskNews shows a cleaned-up reading view extracted from the publisher’s page — the original always lives on their site, not ours.