两个 AI 部门：一个存档，一个办事

10 月 14 日，PFEx 多了第二个 AI 角色：事务部。在那之前，应用里只有一个 AI，就是研究部的首席策略官。

两个部门看起来都是"应用里的 AI"，但底层是两种设计，我先把这条分界说清楚，再讲事务部怎么从一个对话框长成了会办事的 agent。

一个存档，一个对话

研究部是非即时的。它的首席策略官只在一周、一月、一年收口的时候出稿，写完就归档，按体裁和期数留在那里，随时翻得回去。它和用户的关系是单向的：我写，你读。你把账记完，它给你一份复盘。它能读账本，但你不能追问它。

事务部是即时的。你随时可以问它账，它当场去读，当场回答。它没有"出稿"这个动作，只有一问一答。

这条分界是我故意立的设计前提，不是实现细节。研究部的承诺是"值得留下来的一份"，所以要有周期、有定稿、有归档；事务部的承诺是"随时问得到"，所以要有读的能力、答的能力，以及当场把事办掉的能力。想要前者，就不能让它是即时的；想要后者，就不能把答案提前钉死。

从能聊，到能办事

事务部刚上线时，我的想法很朴素：让它能读账，能被追问。

第一版我走了最省事的路，把汇总好的数字直接拼进系统提示，让模型照着答。很快发现不行：这样它只能回答我预先写进提示的那些事，多问一句就露馅。所以改成给它读的能力。十个只读工具，加一层只能跑只读查询的沙箱，覆盖概览、分类支出与收入、账户余额、流水、净额序列、账户 K 线、预算状态、龙虎榜、周期对比。新问题不再需要我提前写进提示，它自己去账本里查。

但能读只是半个 agent。对话往下走，我开始对它提要求：帮我把这笔删了、把这个账户改了、把那条周期规则停了。与其让它只告诉我"你去某某页面改一下"，不如让它真的动手。

于是我把 App 内的数据操作做成了技能，交给它调用：

• 交易流水：建、改、删，转账，余额校准
• 账户：建、改、删
• 分类：建、改、删
• 预算（月度与全局）：建、改、删
• 计划预算（一次性专项）：建、改、删
• 周期规则（预约委托）：建、改、删
• 预埋单：建、改、删，确认

这么一套铺下来，App 里几乎任何一次数据操作，都能找到对应的技能。事务部于是不再是一个"能聊的对话框"，而是一个能替你动手的私人财务 agent。这是这个功能我觉得最值得记的一句：它的形态变了，从对话变成了办事。

但它不能静默改账

技能给了它动账本的能力，我却不敢让它直接落库。所以中间留了一层：任何写技能都不立刻生效，只生成一份草案，摆到界面上，等用户点批复才真正执行。模型可以起草，不能签字。

原则很简单：读可以放开，写必须隔着人的一次确认。账本是用户唯一的真相，模型不该有静默改它的权力。

同一次提交里，我把快照删了

这件事和上面其实是同一件。以前有三张快照表，由一个后台任务定期写。一旦 AI 能自己从流水里查，这些预计算就从资产变成了负担，还多出一类"副本和推导对不上"的 bug：这个月到底赚了多少，界面上会出现两个答案。所以我把它们删了，所有统计改成直接从流水算。删掉冗余之后，功能反而更少 bug。

小结

• 研究部和事务部是两种模式，前者非即时存档，后者即时对话。这不是两种玩法，是两个不同的产品承诺。
• 事务部真正值得记的转变，是从"能聊的对话框"变成了"能动手的 agent"：读有只读工具，写有覆盖全 App 的技能。
• 写的那一步我留给了人：模型起草，用户批复。读放开，写收手。