不少人下载壹号国际App以后做的第一件事，是直接点进"风险"或"碳数据"页面，结果发现里面几乎是空白，只有一行提示"暂无关联数据"。这不是App还没做完，而是系统的数据结构决定的：风险提示和碳数据都不是挂在企业身上的，而是挂在具体的Supplier（供应商）和Product（产品）之间的关系上。没有这层关系，App不知道该把一条港口拥堵信息、一份供应商能耗异常，归到哪个订单、哪件产品名下。

首页为什么不能先给一个笼统的风险总览

如果App在没有供应商数据的情况下，直接给用户展示一个"综合风险中等"之类的结论，这个结论其实没有信息量——它既没有告诉用户风险来自哪个供应商、哪个工厂，也没有说明这个风险有没有货物暴露在里面。壹号国际App的逻辑反过来：先要知道用户有哪些Supplier、这些供应商对应哪些Product，才能把外部事件（港口延误、极端天气、供应商能耗异常）和具体的订单、库存关联起来，变成一个可以判断、可以操作的提示，而不是一条泛泛的新闻式推送。

第一步：建立供应商档案

打开App后的"供应商管理"模块，新增一家供应商需要填写的不只是名称，还包括几个关键字段：Supplier ID（系统会自动生成，也可以填入企业内部原有的供应商编码）、所在Country/Region、主要生产的Factory地址、联系方式，以及这家供应商在企业采购体系里的层级（一级供应商还是通过一级供应商间接合作的二级供应商）。这些字段看起来基础，但它们是后续所有风险判断和碳排放分摊的锚点——没有工厂地址，系统无法判断这家供应商会不会受到某次台风或港口拥堵的影响；没有层级信息，系统也无法区分风险应该直接展示给用户，还是需要先经过一级供应商传导。

第二步：把产品和供应商关联起来

供应商建好之后，下一步是在"产品管理"里新增Product，并把它指向具体的Supplier和Factory。一个产品记录通常包括产品名称、内部SKU编码、主要材料构成（Material）、供应该产品的一家或多家供应商、以及默认的Lead Time（交货周期）。这一步容易被忽略，因为很多用户以为建了供应商就够了，但App的风险提示逻辑是订单级、产品级的——一次港口拥堵只有在"某产品由某供应商供货、这批货正在经过该港口"这个条件成立时，才会变成对这个用户有意义的提示，而不是全平台所有用户都收到同一条泛泛的区域预警。

场景：一家户外家具出口企业的操作顺序

以一家做户外家具出口的企业为例。这家企业主要生产藤编躺椅和户外餐桌，材料来自两家供应商：一家在东南亚提供藤编原材料并完成初加工，另一家在国内负责金属框架和组装。用户第一次使用App时，先在供应商管理里分别建立这两家供应商的档案，填入各自的Factory地址、主要产品类别、层级关系（藤编原料供应商标记为通过组装厂间接合作的二级供应商）。接着在产品管理里新建"户外藤编躺椅"这一Product，把材料构成拆成藤编面料和金属框架两部分，分别关联到对应的供应商。做完这两步以后，用户再回到风险页面，才能看到系统根据这条Supplier—Product关系，主动提示"藤编原料供应商所在地区近期有台风预警，可能影响躺椅这款产品的到货节奏"，而不是一条和自己业务无关的区域新闻。

一个产品可以关联不止一家供应商

还是这家户外家具企业，藤编躺椅的金属框架其实同时有两家供应商在供货：一家是长期合作的主力供应商，另一家产能较小，平时只承接旺季溢出的订单。App在产品关联环节允许一个Product对应多个Supplier，并可以标注主供应商和备选供应商（Alternate Supplier）的角色。这一步经常被用户简化成"只填一家"，但如果金属框架的主力供应商所在地区突然出现停电或原材料短缺，系统能不能提示"还有一家备选供应商可以承接"，完全取决于关联关系里有没有把第二家供应商也录进去。少填这一层，风险提示到最后只能停在"暴露"，没办法进一步给出"有没有退路"的判断。

录入过程中常见的几个疏漏

从实际使用情况看，第一次录入供应商和产品关系时，容易出现几类问题：一是只填了供应商名称和联系人，没有补全Factory的具体地址，导致后续港口、天气类事件无法准确匹配到这家工厂所在的地理位置；二是产品的材料构成填得过于笼统，比如只写"藤编家具"而不拆分面料和框架两种材料，碳项目建立时就没办法分别对应到两家供应商；三是新增产品之后忘记关联到已有供应商，产品单独存在，导致App提示"该产品暂无供应商关联"。这几类问题都不会导致App报错，只是让后续的风险判断和碳数据停留在一个不完整的状态，需要用户自己回头检查补全。

录入不是一次性的，是持续维护的基础数据

供应商和产品关系建立完以后，也不是从此一劳永逸。供应商更换工厂、产品切换材料供应商、新增一款SKU，都需要回到App里更新对应关系，系统才能持续给出准确的风险暴露判断，这也是供应链风险大模型能不能给出有价值信号的基础前提——模型能识别的信号再多，如果底层的供应商工厂地址、产品材料构成是过期的，输出的提示也会跟着失真。同样，建立出口产品碳项目时，系统需要知道这件产品用了哪些材料、材料来自哪家供应商、供应商工厂用什么能源结构，这些信息全部依赖于前面建立好的Supplier—Product关系。如果用户跳过供应商录入直接去建碳项目，系统能提供的只是通用的行业平均值，而不是贴近这家企业真实生产情况的产品碳强度，这也是为什么同一件产品换一家工厂碳强度会不同这个判断，在App里必须落到具体的供应商工厂数据上才成立。

把基础数据当成供应链数字档案来维护

把供应商和产品关系当成企业供应链的数字档案来维护，而不是注册时走一遍的表单流程，是使用壹号国际App比较容易被低估的一步。很多企业习惯把供应商信息留在采购部门的Excel表格或邮件往来里，App里的录入被当成"额外多做一遍"的重复工作。但从数据链路上看，港口事件能不能定位到具体订单、碳项目能不能算出贴近真实情况的产品碳强度，起点都是这份Supplier—Product关系是不是及时更新的。第一次使用时花时间把供应商档案和产品关联建完整，后续App给出的每一条风险提示和碳数据，才有真正对应的业务对象，而不是一堆孤立的数字。