01 / THE PROBLEM
让 AI 开始做预算之前，
先把问题问清楚。
我做这个项目，是希望在经济压力下，帮助收入一般、开支偏多的人先看清自己的财务状况，再寻找可行的优化方案。
「量入为出」面向没有记账、预算或储蓄习惯的人，也考虑已有储蓄、但不知道如何梳理收支的人。它从微信、支付宝账单和用户补充的信息开始。
一张账单并不能说明全部情况。收入是否稳定？转账是房租，还是还给朋友的钱？固定开支有没有遗漏？如果这些问题还不清楚，生成一张整齐的预算表也可能没有帮助。
这个 Skill 把这些判断写进流程：先了解背景，再澄清交易，最后才讨论预算与下一次复检。
02 / THE WORKFLOW
把一次回答，拆成一套工作顺序。
下面是源文件执行逻辑的概览。每一步先补齐所需信息，再进入下一步。
- 01摸清现状收入来源、固定开支、储蓄与负债，先了解背景。
- 02整理账单读取账单；不便提供文件时，可手工填写关键数字。
- 03澄清与分类区分消费、转账、收入与中性交易，对不确定项提问。
- 04评估调整空间结合实际开支与个人意愿，讨论支出和收入两侧的可能性。
- 05形成预算把已确认的信息组织为下月方案，检查金额是否闭合。
- 06月度复检重新确认收入和执行情况，随着变化更新预算。
03 / A FICTIONAL EXAMPLE
同样是转账，
含义可能完全不同。
这三个片段来自仓库的虚构演示，用来展示流程如何分类和追问。点击每一项，查看背后的判断。
虚构示例 · 金额单位：人民币元
先问用途，再决定怎样计入。
转账 ¥2,800 → 房租
看到“转账”不直接排除。先确认用途；在这个例子中，用户说明它是房租，因此计入刚需。交易方式和实际用途，需要分开判断。
转账 ¥300 → 还给朋友的钱
这个例子确认用途后，将它单列为非消费转账。它仍然影响当月现金结余，不能因为没有归入消费，就当作这笔钱没有流出。
零钱充值 ¥2,000 → 账户间移动
示例将充值视为中性交易，避免把账户之间的资金移动重复计作消费。遇到描述不清的流水，仍需要补充信息。
来源：仓库中的完整虚构演示 ↗
这里展示的是源文件中的设计示例，不是真实用户记录，也不代表已经验证了所有账单格式或实际财务效果。
04 / DESIGN CHOICES
一些写进流程的取舍。
不确定的信息，先澄清。
账单描述不一定足够清楚。流程要求对存疑交易提问，尤其是转账用途，避免用看似合理的猜测替代事实。
允许从简单的输入开始。
源文件保留手工填写关键数字的方式。拿不到完整文件时，仍可先梳理现状；缺失信息需要被看见。
把复检也写进设计。
收入和开支会变化。一次预算只是一段过程的起点，下一次使用要重新确认情况，再更新方案。
明确这套流程的边界。
Skill 将内容定位为通用教育与参考，不推荐具体金融或保险产品，也不提供法律、税务等专业意见。它不应替代针对个人情况的专业判断。
05 / CURRENT STATE
已经公开，也还有需要验证的地方。
- 已有材料：Skill 源文件、README、虚构样本、完整虚构演示和设计记录。
- 当前展示：站内流程与交易片段根据公开文件整理，没有将虚构结果包装成真实用户效果。
- 运行依赖：实际效果取决于加载 Skill 的 AI 工具、文件读取能力及提供的信息，不能假定所有平台表现相同。
- 后续验证：账单格式变化、复杂交易和持续使用效果，需要在实际测试中继续检查。
使用任何 AI 工具处理账单前，请先了解该工具的数据处理方式，并移除不必要的个人信息。这个网页不接收或处理你的账单。
06 / EXPLORE THE SOURCE
从文件和示例开始。
- 先阅读 README，了解项目范围、输入与输出。
- 查看 SKILL.md，理解具体执行顺序与边界。
- 先用仓库的虚构样本，在支持相应指令与文件读取的 AI 工具中尝试。
项目采用 MIT 许可证。使用、修改或再分发时，请阅读并保留相应许可声明。