即刻App年轻人的同好社区
下载
置顶我的记账哲学：让财务有盈余，生活有余裕
我从大学有生活费时开始记账。
不是因为我喜欢记账，记账这件事某种程度上是反人性的，它要求持续的自律，却很难即时带来反馈。
每一笔支出、每一笔收入，都需要你在当下记得去记录。而每次对账，才是真正的折磨：数字对不上，我会有点抓狂，会反复翻流水，试图找出钱消失在了哪里。
但我还是坚持记账。因为我知道我需要了解自己的财务状况，这件事本身是对的。
后来我觉得记账其实可以不追求精确，主要是为了感知。
记账的心理压力
市面上的记账软件，大多数默认了一个前提：你应该把每一分钱都管理得清清楚楚。所以它们提供分类统计、预算警告、支出图表，功能越来越多，越来越细。
但这个前提本身，就是压力的来源。
在用各种 App 记账的过程中，我慢慢意识到两件事：
第一，小金额可以不用记。 骑一次共享单车一块五，买瓶水两块，这类支出记不记，对我的财务状况几乎没有影响。强迫自己每笔都记，只会让记账这件事变得又繁琐又脆弱，漏记一次，心里就会有负担。
第二，金额不用完全对上。 这个想法一旦接受，心理压力就小了很多。个人记账不是做审计，不需要分厘不差。允许有误差，才能让记账这件事长期坚持下去。
这两个想法，帮我把记账从一件"需要完成的任务"，变成了一件"可以自然融入生活"的事。
当接受“可以不完美”之后，记账这件事开始变得可持续。
最重要的数字
慢慢地，我发现对我来说，记账真正需要关注的核心数字，其实只有一个：每个月的净收入，也就是收入减去支出。
只要这个数字是正的，就意味着这个月有盈余，生活是可持续的，是健康的。
这也是这个 App 中文名字的来历。
在起这个名字的时候，我了解到日语里有一个词，叫做余裕（よゆう）。它描述的是空间、时间、金钱上的富余——不是绰绰有余，不是奢侈宽裕，而是"够了，还剩一点"，恰好不被逼到极限的那种状态。
临界之上的安全感，生活的松弛与从容。
我觉得这正是我想要的记账理念，也是我想要的财务理念：
每个月有盈余，慢慢积累，财务上有应对各种需求的预算，生活有余裕。这样，一切就会慢慢变好。
要有温度
除了“减少负担”，未来我还希望为记账 App 注入一些情绪价值与生活节奏感。
记账不应该只是冷冰冰的数字记录，它其实也是在记录生活和不同的人生阶段，例如：
发薪日倒数（已完成）
月末结余的小结（规划中）
某些周期性的提醒与反馈（部分完成）
这些设计并不直接提升“功能效率”，但会改变体验的温度。
它让记账从“任务”变成了一种生活的节奏感，一种对时间、收入与生活状态的感知。
可以有某种方式，让我们在记账的过程中体验到一年四季的轮转与人生的成长。
先做好基础，再做少
作为独立开发者，我现在做的事，可能看起来和上面说的有点矛盾——现阶段的盈余，还是会记录各种各样的数据，提供各种较为细的功能：周期账单、订阅管理、资产追踪……
我的策略是：先确保基础功能完善，再做减法，让复杂的功能往后退一步。
那些细节功能，应该在需要的时候自然浮现，而不是一打开 App 就把你淹没。
至于怎么做到这一点，我还在探索。但我相信，凭借自己在 AI 应用开发与数据分析上的积累，未来可以用更聪明的方式，帮用户在合适的时候看到合适的信息，而不是把所有数据都堆在你面前，让你自己去消化。
这是关于独立开发记账应用「盈余 / Yuroo」系列文章的第一篇。
这个 App 的开发，是从“我要做自己的第一个产品”开始的，同时我也知道，要做一个解决自己需求、自己会一直用的产品，于是我想到了自己用了很多年的记账 App——iCost，在记账这件事上我想我可以用自己的方式和理念做些实践：
有没有一种可能，记账可以不那么讨厌，钱也照样管得好？
有没有可能让讨厌记账的用户不那么抗拒记账？
如果这个问题可以被解决，那么它的意义就不仅仅是一个工具，而是一种更轻松、更可持续的生活方式的尝试。
当前的 App 还不够好，也有很多功能没实现，不过因为我自己要用，所以会不断迭代下去。
现在有了更先进的 AI 技术，应该想办法把最繁琐最耗力的输入与整理过程交给 AI，也许最终目标不是“把账记好”，而是让人不再需要时刻记得记账，但依然能享受记账给生活带来的节奏感。
我从大学有生活费时开始记账。
不是因为我喜欢记账，记账这件事某种程度上是反人性的，它要求持续的自律，却很难即时带来反馈。
每一笔支出、每一笔收入，都需要你在当下记得去记录。而每次对账，才是真正的折磨：数字对不上，我会有点抓狂，会反复翻流水，试图找出钱消失在了哪里。
但我还是坚持记账。因为我知道我需要了解自己的财务状况，这件事本身是对的。
后来我觉得记账其实可以不追求精确，主要是为了感知。
记账的心理压力
市面上的记账软件，大多数默认了一个前提：你应该把每一分钱都管理得清清楚楚。所以它们提供分类统计、预算警告、支出图表，功能越来越多，越来越细。
但这个前提本身，就是压力的来源。
在用各种 App 记账的过程中，我慢慢意识到两件事：
第一，小金额可以不用记。 骑一次共享单车一块五，买瓶水两块，这类支出记不记，对我的财务状况几乎没有影响。强迫自己每笔都记，只会让记账这件事变得又繁琐又脆弱，漏记一次，心里就会有负担。
第二，金额不用完全对上。 这个想法一旦接受，心理压力就小了很多。个人记账不是做审计，不需要分厘不差。允许有误差，才能让记账这件事长期坚持下去。
这两个想法，帮我把记账从一件"需要完成的任务"，变成了一件"可以自然融入生活"的事。
当接受“可以不完美”之后，记账这件事开始变得可持续。
最重要的数字
慢慢地，我发现对我来说，记账真正需要关注的核心数字，其实只有一个：每个月的净收入，也就是收入减去支出。
只要这个数字是正的，就意味着这个月有盈余，生活是可持续的，是健康的。
这也是这个 App 中文名字的来历。
在起这个名字的时候，我了解到日语里有一个词，叫做余裕（よゆう）。它描述的是空间、时间、金钱上的富余——不是绰绰有余，不是奢侈宽裕，而是"够了，还剩一点"，恰好不被逼到极限的那种状态。
临界之上的安全感，生活的松弛与从容。
我觉得这正是我想要的记账理念，也是我想要的财务理念：
每个月有盈余，慢慢积累，财务上有应对各种需求的预算，生活有余裕。这样，一切就会慢慢变好。
要有温度
除了“减少负担”，未来我还希望为记账 App 注入一些情绪价值与生活节奏感。
记账不应该只是冷冰冰的数字记录，它其实也是在记录生活和不同的人生阶段，例如：
发薪日倒数（已完成）
月末结余的小结（规划中）
某些周期性的提醒与反馈（部分完成）
这些设计并不直接提升“功能效率”，但会改变体验的温度。
它让记账从“任务”变成了一种生活的节奏感，一种对时间、收入与生活状态的感知。
可以有某种方式，让我们在记账的过程中体验到一年四季的轮转与人生的成长。
先做好基础，再做少
作为独立开发者，我现在做的事，可能看起来和上面说的有点矛盾——现阶段的盈余，还是会记录各种各样的数据，提供各种较为细的功能：周期账单、订阅管理、资产追踪……
我的策略是：先确保基础功能完善，再做减法，让复杂的功能往后退一步。
那些细节功能，应该在需要的时候自然浮现，而不是一打开 App 就把你淹没。
至于怎么做到这一点，我还在探索。但我相信，凭借自己在 AI 应用开发与数据分析上的积累，未来可以用更聪明的方式，帮用户在合适的时候看到合适的信息，而不是把所有数据都堆在你面前，让你自己去消化。
这是关于独立开发记账应用「盈余 / Yuroo」系列文章的第一篇。
这个 App 的开发，是从“我要做自己的第一个产品”开始的，同时我也知道，要做一个解决自己需求、自己会一直用的产品，于是我想到了自己用了很多年的记账 App——iCost，在记账这件事上我想我可以用自己的方式和理念做些实践：
有没有一种可能，记账可以不那么讨厌，钱也照样管得好？
有没有可能让讨厌记账的用户不那么抗拒记账？
如果这个问题可以被解决，那么它的意义就不仅仅是一个工具，而是一种更轻松、更可持续的生活方式的尝试。
当前的 App 还不够好，也有很多功能没实现，不过因为我自己要用，所以会不断迭代下去。
现在有了更先进的 AI 技术，应该想办法把最繁琐最耗力的输入与整理过程交给 AI，也许最终目标不是“把账记好”，而是让人不再需要时刻记得记账，但依然能享受记账给生活带来的节奏感。
0 00
Harness 的作用几乎与模型同等重要。
Databricks 内部用自建 benchmark 评测 coding agent 在其百万行级代码库上的表现。
四个主要发现：
1. Pareto frontier 需要混用多家厂商：OpenAI、Anthropic 和开源模型都各有站上前沿的位置,单一供应商拿不到全局最优。
2. 开源模型已经能打：GLM 5.2 进入最高能力档位,和 Opus 4.8 质量上统计意义打平,但单任务成本 $1.28 对 $1.94,明显更便宜。
3. token 单价不等于任务成本:Sonnet 5 单 token 比 Opus 4.8 便宜约 1.7 倍,但因为思考更久、读取更多上下文(多消耗 1.9 倍 token),单任务反而更贵($2.09 vs $1.94),完成率还低 6 个点(81% vs 87%)。这说明必须做任务级 benchmark,而不是只看 token 报价。
4. harness 对效率影响巨大:同一个模型换用更精简的 harness(Pi vs Claude Code/Codex 原生),成本可以差 2 倍以上而质量不变——关键在于每轮喂给模型多少上下文,Pi 的 context 量级只有约 1/3。
Databricks 内部用自建 benchmark 评测 coding agent 在其百万行级代码库上的表现。
四个主要发现：
1. Pareto frontier 需要混用多家厂商：OpenAI、Anthropic 和开源模型都各有站上前沿的位置,单一供应商拿不到全局最优。
2. 开源模型已经能打：GLM 5.2 进入最高能力档位,和 Opus 4.8 质量上统计意义打平,但单任务成本 $1.28 对 $1.94,明显更便宜。
3. token 单价不等于任务成本:Sonnet 5 单 token 比 Opus 4.8 便宜约 1.7 倍,但因为思考更久、读取更多上下文(多消耗 1.9 倍 token),单任务反而更贵($2.09 vs $1.94),完成率还低 6 个点(81% vs 87%)。这说明必须做任务级 benchmark,而不是只看 token 报价。
4. harness 对效率影响巨大:同一个模型换用更精简的 harness(Pi vs Claude Code/Codex 原生),成本可以差 2 倍以上而质量不变——关键在于每轮喂给模型多少上下文,Pi 的 context 量级只有约 1/3。
0 00
0 00
Geoffrey： 如果你能称自己为“高级软件开发者”或“高级软件工程师”，那我问你：你能不能只用 300 行代码就给我构建一个 Coding Agent？能不能在白板上画出来，讲清楚它的架构？如果你根本解释不清这东西是怎么工作的，你只是一个消费者。
剩下可做的其实还有很多。
软件模块化（modularity）、抽象（abstractions）、思考数据和数据库非常重要，身份验证、安全依然很难。但任何人都能随手生成东西了，这确实改变了游戏规则。对于那些还在纠结“我到底还有没有工作”的人，如果你保持好奇心，你就有工作。如果你在过去两年里没有保持好奇心，你就是可替代的。
剩下可做的其实还有很多。
软件模块化（modularity）、抽象（abstractions）、思考数据和数据库非常重要，身份验证、安全依然很难。但任何人都能随手生成东西了，这确实改变了游戏规则。对于那些还在纠结“我到底还有没有工作”的人，如果你保持好奇心，你就有工作。如果你在过去两年里没有保持好奇心，你就是可替代的。
0 00
人们常说有开源就先用开源，不要重复造轮子。
这种说法一般建立在以下前提：
- 开源的开发者是一个你信任的人；
- 这个开源项目是社区公认顶尖水平（不要看 star 数量了）；
- 你不懂这个开源项目所在的领域，这不是你的研究领域；
- 你是个人使用这个开源项目，这个开源项目在你的工作流中的重要性一般，不是核心组件；
- 你没有时间精力去研究与实现。
这种说法一般建立在以下前提：
- 开源的开发者是一个你信任的人；
- 这个开源项目是社区公认顶尖水平（不要看 star 数量了）；
- 你不懂这个开源项目所在的领域，这不是你的研究领域；
- 你是个人使用这个开源项目，这个开源项目在你的工作流中的重要性一般，不是核心组件；
- 你没有时间精力去研究与实现。
0 00
随着工程、产品、设计、数据科学等角色逐渐融合成一种新型角色，我在反思未来角色可能是什么样子。例如，当我观察 Claude Code 团队时，我看到了我认为的五种原型：
1. 原型设计师：提出全新的想法；大量产出想法，其中大多数不会落地
2. 构建者：快速将原型/想法转化为生产级的产品/基础设施
3. 清理者：清理用户界面，简化代码和系统，取消不必要的功能，优化性能
4. 成长者：接手已构建的产品，并对其迭代以提升产品-市场契合度
5. 维护者：负责成熟系统，确保其在扩展时安全、可靠、快速且高效
许多人同时兼具 2 种角色，有时甚至 3 种。我还注意到，这些角色并不真正与工作职能挂钩——例如，在 Anthropic 内部，有些设计师符合类别 1，有些符合 2，有些符合 3；工程师、产品经理、数据科学家也是如此。
一个健康的团队需要这些角色的混合，具体取决于产品：
- 一个新产品且尚未达到产品-市场契合度的，需要擅长 1+2+3 的人
- 一个正在成长且已找到产品-市场契合度的产品，需要 2+3+4 以及一些 5
- 一个具有强大产品-市场契合度的产品，需要 3+4+5 以及一些 2
也许未来的产品角色会更像这样，而不是今天那种特定领域的角色？
原文：
As engineering, product, design, DS, etc. melt into a new kind of role, I was reflecting on what roles might look like in the future. For example, when I look at the Claude Code team I see what I think is five archetypes:
1. Prototyper: comes up with brand new ideas; churns out many ideas, most of which don't ship
2. Builder: quickly turns a prototype/idea into production-grade product/infra
3. Sweeper: cleans up the UI, simplifies the code and system, unships, optimizes performance
4. Grower: takes a product that has been built and iterates on it to improve Product-Market Fit
5. Maintainer: owns a mature system to make it secure, reliable, fast, and efficient as it scales
Many people span across 2 roles, and sometimes 3 roles. I also notice that these roles are not really tied to job function -- eg. across Anthropic, some designers match category 1, some 2, some 3; same for engineers, PM, DS.
A healthy team needs a mix of these, depending on the product:
- A product that is new and pre-PMF needs people that are strong at 1+2+3
- A product that is growing and has found PMF needs 2+3+4 and some 5
- A product that has strong PMF needs 3+4+5 and some 2
Maybe product roles of the future will look more like this, and less like the domain-specific roles of today?
1. 原型设计师：提出全新的想法；大量产出想法，其中大多数不会落地
2. 构建者：快速将原型/想法转化为生产级的产品/基础设施
3. 清理者：清理用户界面，简化代码和系统，取消不必要的功能，优化性能
4. 成长者：接手已构建的产品，并对其迭代以提升产品-市场契合度
5. 维护者：负责成熟系统，确保其在扩展时安全、可靠、快速且高效
许多人同时兼具 2 种角色，有时甚至 3 种。我还注意到，这些角色并不真正与工作职能挂钩——例如，在 Anthropic 内部，有些设计师符合类别 1，有些符合 2，有些符合 3；工程师、产品经理、数据科学家也是如此。
一个健康的团队需要这些角色的混合，具体取决于产品：
- 一个新产品且尚未达到产品-市场契合度的，需要擅长 1+2+3 的人
- 一个正在成长且已找到产品-市场契合度的产品，需要 2+3+4 以及一些 5
- 一个具有强大产品-市场契合度的产品，需要 3+4+5 以及一些 2
也许未来的产品角色会更像这样，而不是今天那种特定领域的角色？
原文：
As engineering, product, design, DS, etc. melt into a new kind of role, I was reflecting on what roles might look like in the future. For example, when I look at the Claude Code team I see what I think is five archetypes:
1. Prototyper: comes up with brand new ideas; churns out many ideas, most of which don't ship
2. Builder: quickly turns a prototype/idea into production-grade product/infra
3. Sweeper: cleans up the UI, simplifies the code and system, unships, optimizes performance
4. Grower: takes a product that has been built and iterates on it to improve Product-Market Fit
5. Maintainer: owns a mature system to make it secure, reliable, fast, and efficient as it scales
Many people span across 2 roles, and sometimes 3 roles. I also notice that these roles are not really tied to job function -- eg. across Anthropic, some designers match category 1, some 2, some 3; same for engineers, PM, DS.
A healthy team needs a mix of these, depending on the product:
- A product that is new and pre-PMF needs people that are strong at 1+2+3
- A product that is growing and has found PMF needs 2+3+4 and some 5
- A product that has strong PMF needs 3+4+5 and some 2
Maybe product roles of the future will look more like this, and less like the domain-specific roles of today?
0 00
