# 为什么我们的库存是一本只增不改的账

> 在库数是一个和，不是一个格子里的数。这对一家两个人、在两个平台卖同一批货的公司意味着什么。

- Site: Awensora (文霄国际) · Awensora Group LLC
- Page: https://awensora.com/zh/journal/append-only-ledger · Markdown: https://awensora.com/zh/journal/append-only-ledger.md
- English: https://awensora.com/journal/append-only-ledger
- Updated: 2026-09-27

---
*2026-09-27*

多数小店把库存记成表格里的一个数。卖出一件，减一；盘一次货，把格子改成新数。一直好用，直到某天对不上，而那时没人说得清为什么。

我们改用一本账。每一次库存变动都是一行：哪个 SKU、哪个位置、带正负号的数量、原因、谁做的，以及引发它的订单或盘点的编号。行只会增加。一个 SKU 的在库数，就是它所有行的和。

```
on_hand(sku) = Σ delta   （该 sku 的每一行）
```

## 这改变了什么

**纠错也是一行。** 盘点发现账上 12 盒、架上 11 盒，我们不改任何东西。新增一行 delta −1、原因 `count`，历史里同时留着错误和修正。

**每个渠道的数都从同一个数字推出来。** TikTok Shop 和 eBay 各有一个挂牌数量，都由同一个在库数减去未发货订单的预留量推送出去。一个渠道卖出，另一个渠道几分钟内跟着减，任何平台都不可能显示比货架上更多的数。

**从未盘点过的 SKU 不推送。** 从平台 listing 导入的是平台的数，不是现实。某个 SKU 在有人实物盘点之前，worker 拒绝为它推送任何数量，并在提醒里列出等着盘点的 SKU。

**人和 agent 留下同样的痕迹。** Claude 通过 MCP 记的一次库存变动，是一行带用户 ID 的记录，和在浏览器里做的一模一样。自动化没有第二条更松的路。

## 代价是什么

一点纪律，以及一条求和而不是读值的查询。对一家两个人加几个 agent 的公司，这笔交易划算。"我们到底有多少货"只在这一个地方回答，也没有人需要记得去更新它。
---

Awensora Group LLC · Dunn Loring, Virginia · hello@awensora.com
Where to buy: TikTok Shop (Awensora) https://vt.tiktok.com/ZTySM73t1/ · eBay (sorajapanshop) https://www.ebay.com/usr/sorajapanshop
Catalogue: https://awensora.com/products.json · For agents: https://awensora.com/agents.md · Index: https://awensora.com/llms.txt