我管理200+ SKU的秘密：一个Obsidian库 + 一个AI Agent

如果你正在用Excel或飞书管理SKU。。。

一个你可能经历过的崩溃时刻

2024年的某个周四下午，我盯着屏幕发呆。

我需要找一份供应商报价——三个月前的。我知道我记了，我只是不知道记在哪里。找了40分钟，最终在一个名叫"XX工厂报价0923终版修改版2"的Excel里找到了它，夹在第17个标签页里。

当时我管理着190个SKU。那190个SKU的信息，散落在：

• 6个Excel表（每个格式都不一样）

• 一个飞书多维表（有一半字段是空的）

• 大约300条微信聊天记录

• 我自己的记忆

这不是管理，这是考古。

两年后，我在管理230个SKU，但我找到任何一条信息，平均不超过30秒。

不是因为我变整齐了，而是因为我换了一套系统。

先理解问题的本质：SKU增长是一个信息密度爆炸问题

很多人把"管理200个SKU难"理解为工作量问题——产品多了，事情自然多了。

这个理解是错的。

真正的问题是信息密度爆炸。

每一个SKU，背后都挂着多个维度的信息：

• 产品维度：规格/材质/尺寸/重量/认证

• 市场维度：当前排名/价格/月销量/竞争对手数量

• 运营维度：Listing版本历史/广告组结构/关键词策略

• 供应链维度：供应商联系方式/报价历史/交货周期/质量问题记录

• 财务维度：每个月的实际利润率/退款率/仓储费

200个SKU，每个SKU平均挂30个信息字段，就是6000个数据点。

如果这6000个数据点之间没有结构化的连接，没有语义关系，没有可被AI读取的格式——那你的管理就永远是在跟信息熵作战。熵增是自然规律，你用人力跟自然规律作对，早晚输。

Excel管50个SKU可以，管200个是在用线性工具处理指数问题。

为什么Obsidian是对的工具——从第一原理推起

我不是Obsidian的布道者。我只是从需求出发，发现它是目前唯一能同时满足以下条件的工具：

条件一：每个SKU是独立的"节点"，但节点之间有语义连接

传统数据库（Excel/飞书多维表）的数据模型是表格：行和列，二维关系。

我的业务需要的是图结构：一个SKU可以关联到多个竞品，一个竞品可以关联到多个市场趋势，一个市场趋势可以触发多个SKU的运营策略调整。这是多维网状关系，表格存不了。

Obsidian的双链系统，天然支持这种多对多的节点关系。这不是"好用"，这是结构上的根本契合。

条件二：纯文本格式，AI原生可读

3 文本文件是最原始的格式：没有专有格式，没有厂商锁定。当AI编程智能体出现时，这个库已经是它们可以原生处理的格式——无需迁移，无需转换层，无需API集成。当初选择的简单性，变成了意想不到的能力解锁。

条件三：可以嵌入YAML前置数据，让AI做结构化查询

这是很多人没有意识到的关键点。Obsidian笔记头部的YAML区域，相当于给每条笔记贴了一个机器可读的"标签系统"。AI可以基于这些字段做精确筛选，而不是依赖模糊的语义搜索。

这三个条件同时满足的工具，目前只有Obsidian。

系统核心：每个SKU的"数字身份证"

整套系统的最小信息单元，是一张SKU产品卡片。

这张卡片不是笔记，是结构化数据对象。它的设计原则只有一条：对人可读，对AI可查。

Markdown

---
类型: SKU产品
ASIN: B0XXXXXXXX
seller_sku: HOME-STOR-001-BLK
品类: 家居/储物
状态: 在售_主推
上架日期: 2025-03-15
供应商: "[[供应商档案_顺德XX工厂]]"
当前售价: 38.99
当前成本: 11.20
毛利率: 71.2%
本月BSR: 847
本月月销量: 1820
本月退款率: 3.2%
AI最后分析: 2026-07-20
---
# HOME-STOR-001 可折叠储物箱（黑色款）
## 产品规格
- 尺寸：45cm × 30cm × 25cm
- 材质：加厚牛津布 + 铁框架
- 重量：680g
- 认证：CE / ROHS
- 包装方式：彩盒 + 内衬泡棉
## Listing当前版本
- 主标题：[版本历史见下]
- 五点描述：最后更新 2026-06-10
- A+页面：已上线，版本2.1
- 主图数量：8张
### 标题版本历史
| 日期 | 版本 | 备注 |
|------|------|------|
| 2025-03-15 | v1.0 | 上架初版 |
| 2025-07-02 | v2.0 | 加入"Heavy Duty"关键词后转化率+12% |
| 2026-01-18 | v3.0 | 针对竞品差评改写，强调拉链质量 |
## 运营数据趋势（近6个月）
| 月份 | BSR | 月销量 | ACOS | 净利润率 |
|------|-----|--------|------|---------|
| 2026-02 | 1203 | 1240 | 28% | 18.3% |
| 2026-03 | 987 | 1560 | 24% | 21.1% |
| 2026-04 | 843 | 1780 | 22% | 23.4% |
| 2026-05 | 791 | 1890 | 21% | 24.2% |
| 2026-06 | 856 | 1750 | 23% | 22.8% |
| 2026-07 | 847 | 1820 | 22% | 23.6% |
## 供应链信息
- 供应商：[[供应商档案_顺德XX工厂]]
- 当前采购价：$11.20/件（MOQ 500件）
- 历史最低采购价：$10.80（2025-11，双十一冲量谈价）
- 交货周期：下单后18-22天
- 质量问题记录：[[质量事故_2025-08_拉链批次]]
## 竞品关联
- 主要竞品1：[[竞品卡片_B0YYYYYYYY]]（当前BSR #623，威胁级别：高）
- 主要竞品2：[[竞品卡片_B0ZZZZZZZZ]]（当前BSR #1124，威胁级别：低）
- 市场趋势参考：[[市场趋势_家居储物_2026Q3]]
## 用户评论洞察（AI自动更新）
### 高频好评主题（本月新增评论统计）
- 收纳空间大（提及43次）
- 组装简单（提及31次）
- 颜色与图片一致（提及24次）
### 高频差评主题（⚠️需关注）
- 拉链质量（提及8次，环比上月↑3次）→ 已通知QC跟进
- 尺寸略小（提及5次）→ 已在Listing五点中添加实测尺寸说明
## AI Agent分析记录
### 2026-07-20 Codex分析
> 该SKU过去3个月BSR相对稳定在800-900区间，月销量略有回升。
> 主要竞品B0YYY近期差评增加，集中在材质问题，建议在下次Listing更新中
> 强化"加厚牛津布"和"YKK级拉链"的卖点对比。
> 当前ACOS=22%处于合理范围，建议维持预算不变，关注竞品断货时机。
> 风险提示：退款率3.2%较上月上升0.4%，建议排查近期到货批次质量。
### 2026-06-15 Codex分析
> [历史记录存档...]

这张卡片有几个关键设计决策，值得单独说明：

① 版本历史内嵌在卡片里

很多团队的Listing历史散落在各地，没有人记得某次改动的原因和效果。我把每次重要改动都记在卡片里，并且记录改动带来的数据变化。6个月后，这份记录就变成了一份"什么改法有效"的真实案例库，AI可以对比分析出规律。

② 运营数据趋势表

每个月更新一行。这不是为了"有数据"，而是为了让AI能做跨时间的趋势分析。一个月的数据是快照，六个月的数据是趋势。AI看到趋势，才能做出有价值的判断。

③ AI分析记录区带时间戳

每次AI分析结果，不覆盖，而是追加，带日期。这是在建立一个AI判断的历史审计轨迹——3个月后你可以回来看：AI当时说的话，事后验证了多少？这个反馈循环，是让AI越用越准的核心机制。

双链：让200个SKU形成"有机体"而非"孤岛"

6 一个机器可读的知识库需要执行一致的模板、类型化的前置数据、可预测的章节布局，这样AI Agent才能可靠地遍历和扩展知识图谱。其核心洞察是：结构赋能AI，AI反过来强化结构——每次由AI驱动的操作都在增加交叉链接，填补空白。

在这套系统里，双链不是装饰，是功能。

举一个真实案例：

我在一个供应商档案里记录了这条信息：“该工厂2025年8月出现过一批拉链质量问题，影响了SKU：HOME-STOR-001 和 HOME-STOR-003。”

这条信息通过双链，连接到了两个SKU卡片和一张质量事故卡片。

六个月后，我在考虑给这个工厂下新订单时，问Codex：“这个供应商历史上有没有质量风险记录？”

Codex会顺着双链图谱，找到那条记录，告诉我：“2025年8月有过拉链批次问题，影响了2个SKU，当时你在Listing中添加了差异化卖点补救，退款率从4.1%降至2.8%。”

这不是AI的"智能"，这是我过去记录的真实决策信息，被AI用结构化的方式检索了出来。

AI的智慧上限 = 你知识库的信息质量上限。

SKU健康度监控：让系统替你"盯盘"

200个SKU，不可能每天人工逐一检查。

我用一条定时运行的Codex指令，每天早上自动生成一份"SKU健康度异常报告"：

text

读取所有状态为"在售_主推"的SKU产品卡片。
筛选出过去7天内满足以下任一条件的SKU：
异常条件：
A. BSR排名下滑超过300位
B. 退款率较上月均值上升超过1%
C. ACOS超过35%
D. 评分低于4.0
E. AI最后分析时间距今超过14天（需要重新分析）
对每个异常SKU：
1. 描述异常类型和数值变化
2. 从历史数据中查找是否有相似异常发生过（检索历史AI分析记录）
3. 给出处理优先级（高/中/低）和建议行动
输出格式：按优先级排序的Markdown表格
存入：/运营日报/SKU异常_[今日日期].md

每天早晨，这份报告已经在我打开电脑之前生成完毕。

我需要做的，是花10-15分钟审阅它，对"高优先级"的异常做出决策。

其余的200个SKU——没有异常的那些——我当天不需要看它们一眼。

这是"异常驱动管理"而非"全量检查管理"的核心区别。

供应链知识沉淀：最被低估的模块

大多数卖家的供应链知识，活在他们自己的脑子里或者老员工的手机里。这是一个巨大的风险：人走了，知识就消失了。

我的供应商档案卡片，记录的不只是联系方式和报价，还包括：

• 谈判历史：每次谈价的时间、背景、结果、策略

• 质量问题记录：每次出问题的批次、原因、解决方案

• 交货周期规律：旺季延误多少天、淡季提前多少天

• 付款条款演变：从30%定金到20%定金是怎么谈下来的

• 人际关系备注：采购对接人的风格、什么时候适合谈条件

这些信息，当我问Codex"明年Q4旺季提前多久备货比较安全"的时候，它可以基于过去3年的交货周期历史数据，给出一个真实的分布区间，而不是一个拍脑袋的答案。

从0到1的最小可行版本

第一步不是把200个SKU全部搬进来，那会让你在第一周就放弃。

建议从10个主推SKU开始，用2周时间搭出一个真实可用的最小版本：

第1天（2小时）：

• 安装Obsidian，建立文件夹结构

• 创建SKU产品卡片模板（复制本文模板，按你的实际情况修改字段）

第2-3天（每天1小时）：

• 把10个主推SKU的现有数据（从Excel/飞书）迁移进来

• 不求完整，先把YAML字段和基础数据填好

第4-5天（1小时）：

• 建立前5个供应商档案，和对应SKU建立双链

• 建立前3个主要竞品卡片，和对应SKU建立双链

第6-7天（2小时）：

• 接入AI（Smart Connections插件 + Claude API，或Obsidian官方CLI）

• 测试第一条查询指令：让AI读取这10个SKU，生成一份健康度摘要

第8-14天：

• 正常使用，遇到"找不到信息"的情况，记录下来

• 每次记录需求 = 下一次迭代的改进方向

两周后，你会有一个虽然不完整、但真正在工作的系统。

然后，持续迭代。现在这套系统是我用了18个月、迭代了11个版本之后的形态。你的第1版本不需要像第11版一样成熟，你只需要让它在第1周就能帮你做一件具体的事。

规模扩展时，系统的自我迭代机制

一个好的系统，在规模增长时应该越来越稳定，而不是越来越脆弱。

当我从100个SKU扩展到200个SKU时，系统没有崩溃，因为有两个机制在支撑：

机制一：模板标准化——新SKU入库的边际成本趋近于零

因为有标准化的产品卡片模板，每个新SKU入库只需要填字段，不需要重新思考结构。一个新SKU的完整录入，现在需要约20分钟。

机制二：知识库审计——每月清理，防止熵增

每月月底，我跑一次库审计指令：

• 找出超过45天未更新的SKU卡片

• 找出没有双链的孤儿笔记

• 找出YAML字段不完整的卡片

• 生成维护清单

这是给系统的"月度体检"。体检花1小时，可以让库保持在高质量状态，让AI的分析结果持续可信。

最后

管理200个SKU，最危险的不是信息太少，而是信息太多但结构太乱。

一个没有结构的信息库，随着规模增长，会以指数速度丧失价值。因为检索成本、整合成本、理解成本都在快速上升。

2026年，真正在规模增长中保持稳定的卖家，不再是广告创意最酷炫的那些，而是库存同步最紧密、订单路由最智能、数据在运营和店铺之间流动最干净的那些。这是一个结构性的、永久性的转变。

结构是系统的骨架。在你建结构的时候，感觉慢；但等规模上来之后，你会发现，当年花时间建的那副骨架，是你现在能站起来的原因。