打通电商和仓储，没那么简单

你所在的公司，最近在做一个大项目：把电商系统和仓储系统打通。

业务方说：“很简单，订单下来后，自动传给仓库，仓库发货后，自动回传运单号。”

你觉得确实很简单。这不就是“A系统告诉B系统一件事”吗？

但立项之后，你发现事情没那么简单。

电商系统的订单状态叫“已支付”，仓储系统能识别的状态叫“待发货”。明明是一个意思，但系统不认。

电商系统用的订单号是“DD202401001”，仓储系统只接受“ORD-2024-001”。格式对不上。

电商系统说“实时同步”，仓储系统说“我们只支持每小时批量导入”。

你夹在两个系统之间，好像在听它们互相说“我听不懂它在说什么”。

你突然意识到一个问题：系统之间不是不想说话，是它们根本“说不到一起去”。

---

API是系统之间的“翻译官”和“契约”

系统之间必须“说话”，因为没有一个系统能搞定所有事。

电商系统管交易，仓储系统管库存，财务系统管钱，物流系统管配送。每一个系统都是“专家”，只懂自己的那一亩三分地。

但业务是连续的。一笔订单，要从交易流到仓储，流到物流，流到财务。

问题不是“系统要不要说话”，而是“怎么让它们说得通、说得稳、说得安全”。

API就是系统之间的“翻译官”和“契约”。没有契约的翻译，是不可靠的沟通。

它解决的不是“能不能说话”的问题，而是：

• 用什么语言说？（协议）
• 说什么内容？（数据格式）
• 怎么说？（调用方式）
• 说错了怎么办？（错误处理）

没有API，系统之间的沟通就像两个说不同语言的人，靠比划和猜。偶尔能蒙对，但大多数时候会出大错。

有了API，就是两个人先签了一份合同：你说英语，我说中文，我们找一个双方都懂的翻译，按照固定的流程沟通。

API的本质，是“降低沟通成本，提高沟通确定性”。

---

跨国贸易类比：没有API vs 有API

我们用“跨国贸易”这个类比，把API解决的问题讲清楚。

没有API的世界：人肉代购

你想从日本买一个限定版手办。

你怎么做？你找一个在日本的朋友，跟他说：“帮我买那个手办。”

朋友去店里看了，拍了张照片发给你：“是这款吗？”

你说：“对，就是它。”

朋友买下来，寄给你。你收到后，把钱转给他。

这个过程，每次都要重复沟通。如果换一个朋友，又要重新说一遍。如果朋友不懂手办，可能买错。

这就是系统之间“点对点直接对接”的方式。每次对接都是定制的、临时的、高成本的。

有API的世界：亚马逊

现在，你打开亚马逊日本站。

你看到商品页面：图片、价格、规格、库存、配送时间，一目了然。

你点击“购买”，输入地址，付款。系统自动处理：扣款、通知仓库、生成运单、更新物流信息。

你全程不需要跟任何人沟通。你甚至不知道背后有几个系统在协作。

这就是API在做的事。

亚马逊的电商系统、库存系统、支付系统、物流系统之间，通过API提前定义好了“沟通规则”：

• 订单数据用什么格式传
• 库存扣减用什么方式调
• 支付结果怎么通知
• 运单号怎么回传

这些规则写成了“接口文档”，就像一份国际贸易合同。所有系统都遵守这份合同，不需要每次重新沟通。

---

API解决的三个核心问题

问题一：格式统一

电商系统说“已支付”，仓储系统说“待发货”。API在这中间做翻译：告诉电商系统“你要传‘status: paid’”，告诉仓储系统“你会收到‘status: paid’，意思是待发货”。

不用翻译，两个系统永远对不上。

问题二：解耦

如果没有API，电商系统要直接调用仓储系统的内部功能。仓储系统改了一行代码，电商系统就崩了。

有了API，两个系统之间隔了一层“墙”。仓储系统只要保证API接口不变，内部随便怎么改，电商系统都不受影响。

这就是“解耦”——让系统之间不那么“黏”，可以各自独立演化。

问题三：安全和管控

如果没有统一的API，每个系统都直接暴露自己的内部功能，就像你家大门直接对着马路，谁都能进来。

API是“门卫”。它控制谁能进来、能做什么、能拿什么数据。你不经过门卫，就进不来。

---

两个致命错误：只关心业务逻辑、不关心系统之间的“说话方式”

错误一：把“同步”当成一个简单的业务需求

BA最常见的错误，是 “只关心业务逻辑，不关心系统之间的‘说话方式’”。

我见过一个真实案例。

BA写了一个需求：“用户下单后，系统自动同步到ERP。”

开发问：“同步方式是什么？实时还是定时？数据是全量还是增量？”

BA说：“同步就是同步啊，用户下单了ERP里就能看到。”

开发按照“实时同步”做了：每下一单，立即调ERP接口创建订单。

上线后，ERP挂了。

因为ERP系统设计的是“每小时批量导入”，不是“实时单笔创建”。它的数据库连接池、事务处理能力，都扛不住高频的实时调用。

开发找BA说：“这个同步方式有问题，ERP扛不住。”

BA说：“那我怎么知道ERP扛不住？我又不懂技术。”

你看，问题出在哪？

BA把“同步”当成一个业务需求，但“同步”背后有太多技术含义：实时还是批量、同步还是异步、全量还是增量、重试还是忽略……

这些不是“技术细节”，是“系统之间怎么说话”的核心规则。如果BA不问清楚，开发就会按自己的理解做，而那个理解往往是错的。

错误二：不知道API的“使用门槛”

另一个常见错误是：不知道API的“提供方”和“消费方”之间的权力关系。

BA经常觉得“有接口就能调”，但现实是：很多API是有“门槛”的。

• 第三方API有调用次数限制（QPS限制）
• 内部API有维护窗口（每周二凌晨升级）
• 有些API要收费（按调用次数计费）
• 有些API只对特定合作伙伴开放

如果你不问清楚这些“门槛”，你的需求可能根本实现不了，或者实现后成本爆炸。

---

系统沟通五要素：定义系统之间的对话规则

我送你一个模型，叫 “系统沟通五要素”。

以后你遇到任何“A系统要和B系统对接”的需求，用这五个要素把沟通方式定义清楚：

要素一：谁说话？（系统边界）

• 哪个系统是“发起方”？（电商系统？）
• 哪个系统是“接收方”？（仓储系统？）
• 还有没有第三方？（物流商？支付渠道？）

要素二：说什么？（数据内容）

• 传递什么数据？（订单信息？商品信息？状态变更？）
• 数据格式是什么？（JSON？XML？固定格式的文本？）
• 哪些字段是必填的？（少了任何一个，对方都不认）

要素三：怎么说？（调用方式）

• 实时还是定时？（用户点完立刻调？还是每小时跑一次批？）
• 同步还是异步？（等着对方返回？还是发完就完事？）
• 批量还是单条？（一次传100个订单？还是一个一个传？）

要素四：说错了怎么办？（异常处理）

• 对方没回应怎么办？（超时多久？重试几次？）
• 对方说“数据不对”怎么办？（记录日志？人工介入？）
• 对方挂了怎么办？（熔断？降级？）

要素五：有什么限制？（约束条件）

• 调用频率限制？（一秒最多调几次？）
• 调用时间限制？（只能在几点到几点调？）
• 数据量限制？（一次最多传多少数据？）

你把这五个要素填清楚，开发拿到后就知道“这个对接要怎么做”。你不填，开发就会按“最简单的方案”做——而最简单的方案，往往扛不住真实业务。

---

三个问题，检验你是否真懂系统对接

下次你写“系统对接”类需求时，用这三个问题自检：

问题1：我有没有问清楚“对方系统能接受什么样的调用方式”？

• 实时还是批量？同步还是异步？
• 如果你没问，你可能在逼一个只支持批量的系统做实时——它做不了，或者会崩。

问题2：我有没有定义“失败后怎么办”？

• 调用失败了，业务流程怎么走？等？重试？人工介入？
• 如果你没定义，开发会按“丢了就丢了”做，数据就没了。

问题3：我知道这个API的“使用门槛”吗？

• 有调用次数限制吗？收费吗？有维护窗口吗？
• 如果你不知道，你可能设计出一个“理论上可行，实际上跑不通”的方案。

---

回头看：你已经走了多远

第一篇：为什么需要懂技术——因为不懂，连AI的错都看不出来。

第二篇：怎么学技术——类比、问问题、一句话讲清。

第三篇：为什么开发总怼你——把“说明”翻译成“定义”。

第四篇：技术世界在解决什么问题——存、传、算、显。

第五篇：点一下按钮发生了什么——微观请求之旅。

第六篇：怎么看懂系统架构图——宏观三段式（入口-处理-出口）。

第七篇：为什么电脑可以同时做多件事——操作系统的三个职责（CPU、内存、文件）。

第八篇：前端 vs 后端，到底谁在干活？——前后端分工矩阵。

第九篇：为什么系统会“没反应”？——状态四象限（用户感知设计）。

第十篇：什么是API？——API三问（端点、参数、响应）。

第十一篇：为什么系统之间必须“说话”？——系统沟通五要素。

文章	核心问题	你学会了什么
01	为什么需要懂技术？	不懂技术，连AI的错都看不出来
02	怎么学技术？	类比、问问题、一句话讲清
03	为什么开发总怼你？	把“说明”翻译成“定义”
04	技术到底在解决什么？	存-传-算-显（底层框架）
05	点一下按钮发生了什么？	微观请求之旅
06	怎么看懂系统架构图？	宏观三段式
07	为什么电脑可以同时做多件事？	操作系统的三个职责
08	前端和后端谁干什么？	前后端分工矩阵
09	为什么系统会“没反应”？	状态四象限
10	什么是API？	API三问
11	为什么系统之间必须“说话”？	系统沟通五要素

---

你现在拥有了十一个视角，可以全方位地理解一个系统：

• 知道系统在做什么（四原色）
• 知道一次点击怎么跑（请求之旅）
• 知道整个系统怎么组织（宏观三段式）
• 知道底层资源怎么调度（操作系统）
• 知道前后端怎么分工（分工矩阵）
• 知道用户应该看到什么（状态四象限）
• 知道系统之间怎么说话（API三问 + 沟通五要素）

下一篇文章，我们把视角从“为什么”拉到“怎么做”：看懂接口文档，其实只需要这3个概念。

你会发现，那些密密麻麻的接口文档，其实只有三种信息。

---

系统之间必须“说话”，但不是随便说。

系统复杂，不是因为它们在“做事”，而是因为它们在“沟通”。

API是它们之间的“官方语言”和“沟通协议”。

当你懂了API，你就懂了系统之间是怎么协作的。你就不会再说“同步一下就行”，而是会说“实时同步，JSON格式，超时3秒重试2次，失败后进队列人工处理”。

这种精确性，是BA和优秀BA之间的分水岭。

---

今日行动：

找一个你们公司正在做的“系统对接”项目（或者你熟悉的两个系统之间的交互），用“系统沟通五要素”分析一下：

1. 谁说话？（发起方、接收方）
2. 说什么？（数据内容、格式、必填字段）
3. 怎么说？（实时/定时、同步/异步、批量/单条）
4. 说错了怎么办？（超时、重试、降级）
5. 有什么限制？（频率、时间、数据量）

把分析结果发到评论区，我会选出3个典型场景，在后续文章中专门分析。

---

👉 还没关注的，点个关注，每天一篇，60天打通BA技术任督二脉。

PS：如果你也曾经被“同步一下就行”坑过，把这篇文章转给那个和你一样困惑的BA朋友。

---

【知识卡片】

没有API的世界

人肉代购：每次都要重新沟通，定制、临时、高成本

有API的世界

亚马逊：提前定好规则，系统自动协作，标准化、可复用、低成本

API解决的三个核心问题

1. 格式统一（翻译）
2. 解耦（隔墙）
3. 安全和管控（门卫）

系统沟通五要素

谁说话？说什么？怎么说？说错了怎么办？有什么限制？