第 9 节：一次危险的串账问题

小产品从自用走向多人使用时，最怕的不是页面不好看。

最怕的是数据边界不清楚。

蜡笔小账本就遇到过一个很典型的问题：别人通过飞书发消息记账，结果看起来像记到了我的账本里。

这件事一出现，就不能当成普通 bug。

因为记账数据是私人数据。

一旦串账，用户对产品的信任会立刻消失。

先分清 App 账号和飞书身份

这个问题一开始容易误判。

用户说：“别人注册后登录，怎么还能看到我的账单？”

听起来像 App 多用户隔离坏了。

但检查后发现，App 账号本身的数据隔离是正常的。不同账号登录，各自读取自己的数据。

真正的问题在飞书侧。

飞书用户和 App 账号不是同一个身份。

一个人注册了 App，不代表他的飞书身份已经和这个 App 账号绑定。

如果这层关系没处理好，机器人收到消息时，就不知道这条账应该记到谁那里。

自用时方便的逻辑，公开后会变危险

早期为了方便自己用，曾经有一种逻辑：

如果飞书用户没有绑定，就退回记到“主人账本”。

自用时，这很顺手。

我不绑定也能记。

机器人收到消息就能进我的账。

但一旦别人开始用，这个逻辑就变成风险。

别人没绑定时发的账，也可能进到主人账本。

这就是典型的自用逻辑和公开产品逻辑冲突。

自用时省一步。

公开时出事故。

数据问题不能靠解释解决

面对这种问题，不能只在说明里写“请先绑定”。

说明可以减少错误，但不能替代系统边界。

真正的修复应该是：

未绑定用户发消息，一律不记账。

机器人只提示：请先绑定账号。

绑定完成后，再允许记账。

这样虽然多了一步，但边界清楚。

每一笔飞书记账都能找到明确的 App 账号。

安全边界要由系统强制，而不是靠用户记得。

这类问题要优先修

产品迭代时，bug 也有优先级。

有些 bug 是体验问题，比如按钮文字不好懂、页面有点挤。

有些 bug 是数据问题。

数据问题要优先处理。

因为它影响的是信任。

尤其是记账、账号、隐私相关产品，只要涉及“别人的数据会不会进我的账本”“我会不会看到别人的账”，就必须马上停下来修。

功能可以慢一点。

边界不能含糊。

复盘时不要只看代码

这次串账风险表面上是代码逻辑。

但更深一层，是产品从自用到公开时，没有及时切换默认假设。

自用工具默认用户就是我。

公开产品默认用户不是我。

这两个世界完全不同。

一旦进入多人使用，所有“如果不知道是谁，就记到我这里”的逻辑，都要重新检查。

公开产品最怕的不是功能少。

而是默认边界还停留在自用阶段。

本节小结

串账问题提醒我：小产品可以从自用开始，但不能带着自用逻辑公开。

飞书记账必须先绑定，未绑定就不准记。

这让流程稍微多一步，却换来了清楚的数据边界。

下一节，我们会继续讲这个转变：为什么取消“方便自己”的逻辑，产品才真正适合给别人用。

FAQ

App 账号隔离正常，为什么飞书还会串账？

因为飞书身份和 App 账号是两套身份。只有绑定后，机器人才能知道消息属于哪个 App 账号。

未绑定用户为什么不能默认记到主人账本？

自用时方便，但多人使用时会造成别人账目进入主人账本，属于数据边界风险。

这种问题能靠文案提醒解决吗？

不能只靠文案。文案可以引导用户，但系统必须强制未绑定不能记账。

为什么记账产品的数据问题优先级高？

因为记账数据属于私人信息，一旦出现串账或错账，用户信任会受到直接影响。

自用工具公开前要检查什么？

重点检查账号、权限、默认用户、数据目录、未登录状态和第三方身份绑定，所有“默认归我”的逻辑都要重新审视。