普尔存钱罐

> 一句话定位：周节奏的零钱归集 + 自动跑收益小报告，让"小钱在生钱"这件事有仪式感。

一、设计要点（产品铁律，不可违背）

1. 周节奏：每周跑一次（默认周日 20:00，无自动化时用户一提就结算）。算这一周攒了多少、涨了多少、出小报告。
2. 小单位：单次入账 ≤500 元，面向余额宝/零钱通/国债逆回购/短债基金这类几乎无风险的池子。超过 500 时提醒拆成多笔，不擅自放行。
3. 仪式感核心：报告用具体场景描述钱的价值——"你的小钱够买一杯蜜雪冰城了""够吃一顿麦当劳了"——比干巴巴的数字更打动人，这是用户坚持的动力来源。场景一律用全国通用、不指涉具体地名的生活事物。
4. 不接实时 API：所有计算本地跑。年化按用户配置的固定值（可随时改），复利估算。纯本地、零网络依赖。
5. 有自动化就跑，没自动化就对话触发：若存在每周日的自动化，让它来跑；否则用户说"结算/看看这周"时立即执行同样流程。跑完把成就报告推到当日记忆日志（append-only）。
6. 金额四轨制、变动即全量同步：钱的每次增减必须同步更新 4 个文件——① 当天时间文档 daily、② 全量金额流水 flow（append-only，永不可改）、③ 费用去向分类 categories、④ 写死的总金额 balance。任何时刻报数/读余额永远优先读 balance.json 的固化值，绝不靠重放历史、更不靠上下文记忆现算——固化值单步更新、当场落盘，是防大模型压缩与幻觉算错钱的最硬防线。

触发判定（何时自动进记账协议）：用户话语出现「钱/金额/存/花/取 + 数量 + 增加或减少」语义即立即自动触发（如"存了 50""入账 88.5""取 100 出来""漏记了 30""那笔记错了"），无需等"记账"二字。触发的第一动作永远是：读取 balance.json 写死的 total，把当前罐子总金额报给用户，然后才处理本次变动；处理完回报"最新总金额已写死为 ¥X"。

二、数据模型：普尔四账户 × 四轨记录

> 两个问题分开答：钱往哪儿去（普尔四账户，管去向与载体）｜钱怎么记（四轨制，管每笔落盘）。

普尔四账户（资金去向的顶层框架——标准普尔家庭资产象限的国内适配）

落地规则：每笔流水仍记在具体 pool（池子）上，config 里每个 pool 标注 quadrant 归属账户；账户分布 = 按 quadrant 聚合 pools 余额，报告里给出四账户分布画面与参考配比对照（配比只是参考画面，不强制、不构成理财建议）。保命钱特殊：小额医疗险 池年化 0、不参与收益估算，交保费=withdraw、到期回款=deposit，其余记录规则与普通池一致。

象限失衡提醒（阈值触发，只提示可分摊、绝不代劳）：

• 检查时机（三处共用同一规则）：① 每次记账四轨同步完成后；② 每周结算报告（固定带一行）；③ 用户主动问"分布 / 是不是偏了 / 要不要分摊"。其余时刻不主动弹。
• 计算口径（数字全来自 balance.json 的 pools 按 quadrant 聚合；锁定池也计入）：设四象限金额 = 要花的钱 a、保命的钱 b、生钱的钱 c、保本的钱 d，总额 T = a+b+c+d。对每个象限 x：其余三象限均值 m = (T−x)/3，超幅 e = x/m − 1。触发条件：x > 1.2 × m——即该象限比另外三个的平均高出 20% 以上；数学上等价于 x > T × 2/7（约占总金额 28.6%），两个口径任取、结果一致。特例：x>0 且其余三象限全为 0（整罐只在一个象限）→ 直接触发。T=0 或该象限金额为 0 → 不触发。
• 建议分摊额（确定性摊平建议：目标 = 四象限均分 T/4）：y = x − T/4——把失衡象限从 x 降到总额的四等分线，y 均摊给其余三象限（各补 y/3）；分摊后画面 = 四个象限各 T/4（示例：10/10/10/10 进账 10 变 20/10/10/10 → 建议转出 7.5，摊成 12.5/12.5/12.5/12.5）。只作提示参考，实际转多少、转进哪个池由用户定，AI 不擅自选池。若多个象限同时失衡 → 只提醒超幅 e 最大的一个，处理完再复检其余。
• 提醒文案（固定格式，数字全来自 balance，不编）：
  ⚠️ 四账户提醒：「{失衡象限}」¥{x} 高出其它三象限均值约 {e}%（占总约 {NN}%）——超过 20% 阈值，偏了。建议转出约 ¥{y} 摊平，四象限 ≈ {T/4}/{T/4}/{T/4}/{T/4}。要分摊说一声，我按记账协议帮你转；不摊也行，参考配比本就不强制。
• 触发示例（用户典型场景）：四象限 10/10/10/10（均衡，不提醒）→ 某天进账 10 到「要花的钱」变 20/10/10/10：20 > 1.2×10 触发 → 按上式提醒摊成 12.5/12.5/12.5/12.5。反过来进账 1 变 11/10/10/10：11 < 1.2×10 未触发 → 该笔全程安静，不出现任何"建议均衡"话术。
• 防重复唠叨（未触发零提醒 + 跃迁才弹）：每次检查后把结果写进 balance.json 的 alert_state（字段定义见 @references/ledger-schema.md）。一次金额变动后未触发 → 完全安静，不出现任何提醒或建议；只有"上一次检查未触发 → 本次触发"的跃迁时刻才在记账回执里提醒。若上次已触发、本次仍触发（同一象限持续失衡、用户没动）→ 记账后不重复弹，等周结算报告再带一行；用户分摊后分布回落、将来再失衡，会重新提醒。
• 分摊不是自动动作：AI 只提示，绝不擅自动钱；用户明确说"分摊 / 转 X 到 Y"后才执行，且走第三节四轨同步协议——转出池一条 withdraw + 转入池一条 deposit 两条流水（保命钱锁定部分不可转，如实说明）。

四轨制文件架构（钱的记录方式）

本地文件，路径可随环境。钱的每个事实都落在 4 条独立轨道上，各管一维，可互相验证纠正：

主从关系（最重要，不可倒置）：④ 总金额是唯一裁决。 三轨不一致时，永远以 ④ 为准去纠正 ① ②，绝不反过来拿 ①/② 改 ④。理由：balance 每笔当场写死、每次只做"当前值 ± 本笔"的单步更新，文件又极小，是四轨中最不易被长上下文压缩/幻觉搞错的数；而 flow 是全量长流水、daily 是按日长文档，都可能在长上下文里丢行/被改。因此三角核对只是探测手段，不是裁决依据——对账发现矛盾，只说明 ①/② 里有错，修复一律朝 ④ 对齐。balance 自身疑似被污染（与 flow 尾行 total_after 都对不上）→ 立即停、报人工核查，AI 不得擅自改动它（见三·对账）。③ 独立容错，不参与。

目录骨架（四轨账本体系，落地按此展开）

standard-and-poors-money-jar/
├── SKILL.md                # 主流程（高频规则），精确格式见 @references/ 各文件
├── references/             # 参考文件（用到才读，不常驻上下文）
│   ├── ledger-schema.md    #   写文件前的格式基准：flow/balance/daily/categories 字段与示例
│   ├── report-template.md  #   出报告前读：报告模板全文 + 换算规则 + 一年推演
│   └── config-defaults.md  #   默认配置：pools 年化/象限、scenes 档位、字段默认值
├── balance.json            # ④ 总金额：写死权威，报数唯一来源、矛盾唯一裁决
├── flow.jsonl              # ② 金额变动：append-only 全量流水（单文件）
├── daily/                  # ① 时间：一天一个文档
│   └── 2026-09-07.md
└── categories/             # ③ 费用去向：一分类一文件夹，首次出现才新建
    ├── 工资零头/记录.md
    ├── 餐饮/记录.md
    └── 交通/记录.md

轨② flow.jsonl —— 金额变动全量流水（完整事件史，审计用）

单文件、一行一笔、只追加：用户输入后立即追加一行，一旦写入永不修改、永不删除——哪怕记错也只追加 correction 行。整份流水 = 该 skill 在任期间的全部金额变动史。
字段铁律（id/ts/date/type/pool/amount/category/total_after/ref/note）、type 语义、示例行 → 见 @references/ledger-schema.md；写流水前先读它核对格式。

轨④ balance.json —— 总金额（写死权威，唯一裁决、最优先保证正确）

结构示例与 total/pools/updated_at/last_event/alert_state/settle 各字段规则 → 见 @references/ledger-schema.md。下方只保留写死纪律：

balance.json 写死硬化协议（总金额最优先保证正确——四轨里唯一不可被 AI 现场推翻的数）：
1. 单步确定性更新：新值永远 = 当前写死值 ± 本笔净额——一步加减，绝不碰历史、绝不做长链重算、绝不由上下文记忆推；
2. 双源交叉核对再落盘：写入前用 flow 末行 total_after 核对当前 total（应为同一数）；写入后新 total 必须 == 新追加 flow 行的 total_after，一致才算写成功；
3. 整文件覆写 + 写后读回：balance.json 内容极小，每次更新整体覆写（不追加、不局部改），写完立刻读回逐字段核对；读回不一致 → 重写一次，仍失败 → 停下报错，不许带着疑问继续；
4. 矛盾时它说了算：任何轨与它不一致 → 其它轨错、朝它对齐（见三·对账），没有例外，也不存在"以多数票改 balance"；
5. 它自己可疑时：连 flow 尾行 total_after 都对不上（意味着写入环节出错或文件被外部改动）→ 停、展示两侧数字、请用户拍板，AI 绝不擅自改 balance。

轨① daily/YYYY-MM-DD.md —— 时间（一天一个文档）

当天有金额变动就写/续当天文档（append-only，不改旧文）：当日变动表 + 当日小结 + 校验行。文档模板与示例 → 见 @references/ledger-schema.md。

轨③ categories/<分类>/记录.md —— 费用去向（一分类一文件夹）

每笔变动的 category 归属一个分类；该分类文件夹不存在就先新建（如首次出现"交通"→ 建 categories/交通/），再往 记录.md 末尾 append 一行。格式宽松（人读为主，允许小误差），示例见 @references/ledger-schema.md。不参与三角核对。

口径分层（谁信谁，别混）：
- 总金额（唯一裁决 + 报数） = 轨④ balance.json.total / .pools——对用户、报告、结算一律先读它；任何轨与它矛盾，都朝它对齐；
- 流水（完整事件史，审计） = 轨② flow.jsonl——逐笔追溯"钱怎么变的"、看分类明细、生成 daily 投影；不是裁决方；
- 估算收益（派生量） = Σ 每笔净本金贡献 × ((1 + 年化/100/365)^持有天数 − 1)，公式固定、人人可复现；不产生流水行（是对"钱在生钱"的估算，不是一笔现金变动）；
- 池内当前价值 = balance.json 该池值 + 估算收益（只展示用，不落账）。

> config.json（池子年化、scenes、周目标、失衡阈值等）的全部默认字段/默认值表、默认 pools（含 quadrant 归位）、默认 scenes 档位表 → 见 @references/config-defaults.md。改配置 = 改 config.json 对应字段，改完下次报告/结算自然生效。每周结算快照并入 balance.json 的 settle 字段（见上），不单设文件。

📂 参考文件导航（渐进披露：用到才读，不常驻上下文——执行到对应动作前先读对应文件）：
- 写 flow.jsonl / balance.json / daily/ / categories/ 任一文件前 → @references/ledger-schema.md（字段铁律与示例）
- 生成成就报告（周结算/查看罐子）前 → @references/report-template.md（模板全文与换算规则）
- 初始化 config / 查默认值 / 用户要求改配置 → @references/config-defaults.md（默认 pools/scenes/字段）

三、核心流程：四轨同步记账（金额变动的唯一入口）

用户一句"记一笔 50 到余额宝""买菜找零 88.5 存零钱通""取 100 出来"，就进入下面的协议。

管线总览（用户行为只有两种：增加金额 / 减少金额；记错归为"修正"）——无论哪种，都走同一条单一管线，没有第二条路径：
① 写入金额流：按类型记一条流水（增加 = deposit、减少 = withdraw、改错 = correction），并同步更新全部四轨（flow → daily → categories → balance），少一轨即视为操作失败、回滚重来；
② 普尔分配：流水落在哪个 pool，该 pool 的 quadrant 归属就更新哪个账户——按 quadrant 聚合 pools 余额即得四账户分布（要花/保命/生钱/保本，见第二节）；
③ 输出给用户：回执固定带写死后的新总金额；若四账户因此失衡（见第二节·象限失衡提醒）则附 ⚠️ 提醒行。
其中 ④ balance 是报数的写死权威——用户一说金额变动，它就在本次对话内被"最先读到、最后写死"，绝不拖到别的时候、绝不现场心算。

启动动作（每次记账第一步，永远先做）：读取 balance.json 的 total 与 pools（唯一裁决），把"当前罐子 ¥X（各池：…）"讲给用户再继续——绝不从流水现算，也绝不凭上下文记忆猜。

四轨同步执行体（deposit / withdraw / correction 共用，走完才算一笔成功）：
1. 读：balance.json 当前 total/pools（启动动作）；
2. 写轨② flow.jsonl：文件末尾追加一行流水——id 按全局序号递增、ts=现在、date=今天（用户给过去日期=补录，照收）、type/amount/pool/category/ref/note 按各小节规则、total_after = 读到的 total ± 本笔净额（首笔 = 本笔净额）。已写入的行永不修改；
3. 写轨① daily/当天.md：按 date 续写当天文档（不存在先建），append 该笔（凭证/类型/金额/去向/变动后总额）+ 刷新当日小结与校验行；
4. 写轨③ categories/：category 归属该分类 → 文件夹不存在先新建 categories/<分类>/，再往 记录.md 末尾 append 一行（宽松格式，允许小误差）；
5. 写死轨④ balance.json：当场单步重算——新 total = 第 1 步读到的 total ± 本笔净额（必须 == 第 2 步刚写入 flow 行的 total_after），同步更新 pools[池]、updated_at/last_event，整文件覆写落盘后立刻读回核对（写死纪律 = 第二节·轨④的硬化协议 5 条，一步都不能省）。总金额在这一刻固化，此后任何报数都直接读它——它也是未来一切矛盾的唯一裁决；
6. 三角对账（见"对账"）：以 balance 为裁决基准核对 flow / daily，全绿才算完成；
7. 回确认（固定格式，必须带写死后的新总金额）：✅ 已入账 TX-20260907-0002：¥88.50 → 余额宝（买菜找零）｜去向：工资零头｜四轨已同步｜总金额已写死：¥368.50；
8. 象限失衡检查：按第二节"象限失衡提醒"规则聚合四象限金额并对比——仅在"上次未触发 → 本次触发"的跃迁时刻，在回执下追加一行 ⚠️ 提醒（含建议转出额 y = x − T/4 与摊平后的四象限画面）；未触发或连续失衡都不弹。检查结果（无论触发与否）都覆写进 balance.json.alert_state。

deposit（存入）

1. 池子必须在 config.pools，不在 → 列出可用池子并拒绝；
2. amount 必须 >0；
3. amount > daily_cap（默认 500）→ 提示"超过设计上限，建议拆成多笔"；用户明确坚持才放行，note 注明"用户要求超额单笔"；
4. category 记收入来源（如 工资零头/卖废品/报销/红包）；说不清就默认"零钱归集"，不阻塞记账；
5. 其余见上方四轨同步执行体（流水 date=今天；用户给过去日期=补录，照收，daily 写进对应那天）。

withdraw（取出）

1. 校验链同 deposit 的 1–2；
2. category 记花费去向（如 餐饮/交通/日用）；不知道先问一句，别乱安；
3. 上限 = balance.json 里该池固化余额（净本金口径）。超了 → 报当前固化余额并拒绝。估算收益默认不单独提取（继续滚存，雪球才滚得起来）；
4. 其余见上方四轨同步执行体。

特殊：保命的钱（小额医疗险池）

• 交保费 = 一条 withdraw：pool=小额医疗险，category=保险/医疗，note=险种与期数（如"XX 小额医疗险 2026 年度保费"）；
• 到期回款/满期返还 = 一条 deposit：同 pool，note=回款；
• 该池 annual=0，不参与收益估算，balance 里显示为"已锁定在保险里的钱"；未到回款期的部分视为锁定，不可当活期取（协议上不许 withdraw 超额，取不回的部分如实说"未到回款期"）。
• 报告诚实红线：保命钱是"花小钱买保障"，不渲染利息画面。

correction（冲正 = 改错的唯一合法方式）

用户想改/删某一笔时：
1. 先展示原流水行（凭证号、日期、类型、金额、去向、备注）与当前 balance.json 固化余额；
2. 用户确认后，在 flow.jsonl 末尾追加一条 correction：ref=原凭证号，amount=需要找补的差额，note=原因（如"TX-…金额录错，多记 50，冲减"）；
3. 按四轨同步执行体，把找补净额按方向写死进 balance.json（多记→减、少记→加，方向由 ref 原流水净效果定），daily/categories 同步留痕；
4. 绝不原地修改或删除旧行——旧行永远留存，流水因此可审计。
> 单笔 correction 只处理"一笔原流水的净差额"；涉及多笔的错误，逐笔冲正，不合并、不图省事。

对账（三角核对，探测为主；矛盾裁决只认 balance——每次记账后 & 每次结算前必做）

核对动作：
1. 先固定裁决基准：读 balance.json 的 total/pools——它是唯一裁判，本身不参与"被比对的候选"；
2. 对流水：重放 flow 全部行（校验 id 唯一且递增、amount>0、pool 合法、每行 total_after == 上一行 total_after ± 本笔净额）→ 末行 total_after 必须 == balance.total，逐池合计 == balance.pools[池]，Σpools == total；
3. 对 daily：每个有流水的日期，daily/<date>.md 的当日净变动与日末总额 == flow 该日合计与 balance 对应时刻值（行数与凭证号也应一致）；
4. 发现矛盾 = 探测到 ①/② 出错（balance 当场写死、单步更新，是四轨中最不易错的数）：
- flow ≠ balance → 定位断裂行（凭证号、期望值/实际值），在 flow 末尾追加一条 correction 行把链尾找补回 balance.total（ref 指向断裂行；找补性质特殊时 ref 可留 null、note 注明"对账找补"）——flow 只追加、绝不改旧行；
- daily ≠ balance → 以 balance 为准重写当天 daily 文档的变动表与小结（daily 是按日投影，可重建，重建后仍与 flow 一致才算完）；
- balance 自身对不上 flow 尾行 total_after（写入环节出错或文件被外部改动）→ 最高级异常：立即停，展示 balance 与 flow 尾行两侧数字，请用户拍板；AI 绝不擅自改 balance；
5. 修复后必须重跑对账到全绿，才进入正常报数/结算；不许静默改任何一轨，也不存在"用多数票改 balance"。

记账示例（对 / 错）

对错对照表（负号歧义、合并记账、直接改原事件等典型错误与正确写法）→ 见 @references/ledger-schema.md，写流水前照它自查。

四、结算流程（每周一次）

1. 前置：先跑对账（见三·对账），全绿才继续。
2. 本期区间：上次结算次日 ~ 今天；首次结算 = 最早一条 deposit 的日期 ~ 今天（口径标注"开账至今"）。
3. 统计口径（当前数读轨④ balance.json，区间明细扫轨② flow；不猜、不算两遍）：
   - 累计净本金 = balance.json 写死的 total（唯一裁决，先读它）；重放仅作对账复核，不以重放结果覆盖它；
   - 本期入账 = 区间内 deposit 合计（笔数 + 金额）；本期取出 = 区间内 withdraw 合计（有取出必须在报告里明示一行）；本期入本金 = 区间内净变动额；
   - 估算增值（派生，不落流水，公式唯一版本见下）；本期增值 = 本次派生值 − balance.json.settle 上次结算快照中的派生值（老钱继续滚、新钱开始滚都包含在内，本期一分没动也照实显示那点利息）；
4. 结算把快照写进 balance.json.settle：结算日、累计净本金、累计派生增值、结算次数、打卡周数。派生增值只进快照，不产生流水行。

估算增值派生公式（唯一版本，任何人可复现，不得另起炉灶）：设某池年化 r（%），结算日 s，天数差 d(x) = (s − x.date).days（≤0 记 0）：
- deposit a → 贡献 +a × ((1 + r/100/365)^d(a) − 1)
- withdraw b → 贡献 −b × ((1 + r/100/365)^d(b) − 1)（语义：被取出的钱自取出日起不再生息，数学上与"只对留存段计息"等价）
- correction 按其找补净额 ±Δ 以自身 date 代入上述对应符号（默认与原事件同日）
- 该池估算收益 = 各贡献之和；全部池子求和 = 罐子累计派生增值。年化按 365 天、日复利。用户改年化后历史事件也按新 r 重算（口径统一、可复现）。
5. 生成成就报告（模板与换算规则见 @references/report-template.md，生成前先读）。
6. 落档：报告追加到当日记忆/日志（append-only，不改旧文）；如有 reports 目录则并存一份存档文本。
7. 向用户简报 3~5 句 + 附报告全文。

防呆：同一天重复结算会被算成一个 0 入账的空周 → 检测到当天已结算时提示并停下，建议用"只看报告不落账"的预览方式。

五、成就报告规范（仪式感的正确姿势）

诚实底线（最重要）

• 当前本金/取出等"现在有多少"的数一律取轨④ balance.json 写死的 total（四轨同步写死的权威值，见三）；区间入账扫轨② flow 明细；增值是固定派生公式的估算结果——一个数都不能编，也不许另起口径。
• 增值如实显示，允许为负（大额取出周赚的比上周少就是负）；收益只有几毛钱时，画面就是"还差 ¥X 就够第一根烤肠"，绝不说"够一杯蜜雪"。诚实才配谈仪式感。
• 报告主角是攒钱习惯（周目标、打卡、一年画面），利息只是彩蛋——本金小的时候尤其如此，别让用户误以为利息能致富。

报告模板与换算（生成报告前必读）

报告结构模板全文、⚠️ 失衡提醒行的插入位置、场景换算规则（头条大事/日常折算/盼头钩子/空罐引导）、一年推演行公式、语气规范 → 全部见 @references/report-template.md。生成成就报告（周结算/查看罐子）之前，先读该文件再动笔。

六、报告输出位置约定

• 有当日日志体系（如恒忆记忆系统 ~/.memory-system/timeline/daily/YYYY-MM-DD.md）：在"对话要点"下追加 ### 普尔存钱罐周结算 + 报告全文，append-only，绝不删除/改写已有内容，文件不存在则按该体系模板新建。
• 无日志体系：把报告存为 reports/YYYY-MM-DD_weekNN.txt 并展示给用户。
• 无论哪种，都要在对话里给用户一段口语简报。

七、常见调整（用户随时可提）

八、红线清单

1. 不联网、不查实时利率——年化永远是配置里的固定值。
2. 不编数字、不美化收益——"现在有多少"取轨④ balance.json（唯一裁决），区间明细来自轨② flow，增值数字来自固定派生公式，画面来自换算规则。
3. 四轨同步缺一不可：任何金额变动必须同步更新 daily / flow / categories / balance 四轨。只写总额不留流水、或漏了某一轨，都算操作失败，回滚重来。
4. 矛盾只认 balance（最高铁律）：任何轨与 balance 不一致，就是别的轨错——永远以 balance 为准纠正 ① ②，绝不存在"拿 ①/② 改 balance"或"多数票改 balance"；balance 自身连 flow 尾行 total_after 都对不上 → 立即停、报人工，AI 不得擅自改它。
5. 读余额只认写死值：报数、报告、回复一律读 balance.json.total，禁止靠重放流水或上下文记忆现算——重放与对话推演都可能被压缩/幻觉带偏；写死值单步更新、当场落盘，才是最可信的数。若上下文里看不到写死值 → 先读文件，不许猜。
6. flow.jsonl 永不可修改：单文件只追加，绝不原地修改或删除任何一行——它是该 skill 任期内全部金额变动的唯一完整史（审计用，不是裁决方）。金额变动只有 deposit / withdraw / correction 三种表达，改错一律 correction + ref 留痕。
7. amount 恒为正数、方向只由 type 承担——流水里出现负金额即视为数据损坏，停下追查。
8. 记账后与结算前必须跑三角对账（flow ↔ daily ↔ balance），任一断裂即停下报差、以 balance 为准修复 ①/② 后重跑到全绿，不带病出数。
9. 报告承诺感克制：所有"一年后"字样必须带"粗估、不是承诺"。
10. 结算一周最多一次有效；重复跑当天结算先提示防呆。
11. 象限失衡只提示、不代劳：AI 只报失衡与建议分摊额，绝不擅自执行分摊/跨池转账；必须用户明确开口后，才按第三节四轨同步协议记两条流水（转出池 withdraw + 转入池 deposit）。