从 pack_br 到 pack_mx，差在哪

pack_mx 上线的复盘会上，项目经理把排期表投到屏幕上。原本为开发预留的两周窗口，实际只用了三天。屏幕上多出来的，不是一串代码提交记录，而是一份清单：语言、币种、许可证、单证、地址格式、打印模板，一行一条，一共几十条。有人问，从巴西的 pack_br 换到墨西哥的 pack_mx，为什么能这么省事？答案不在于“省了代码”，而在于这些差异，当初压根就没写进主干。这不是运气，是做区域包时特意把这些差异关在主干之外的结果——排期表上省下来的每一行，都是前一版设计攒下的余量。

先看结果：省下的到底是什么

那份清单拆开看，其实只有六个大类。语言从 pt-BR 换成 es-MX；币种从 BRL 换成 MXN；许可证与报关单证整包替换；电子发票从 NF-e 换成墨西哥那一套；地址与打印模板跟着本地习惯换；税制口径按当地配置走。

真正没动的，是主干：订购、发运、清关、分摊、PDI、海外仓、销售交付、售后那一整套流程逻辑，一行没改。因为主干处理的是“一台车从下单到交付要经过哪些环节”，而“这个环节在本国具体要交什么、按什么税率”，本来就该是配置。

往回查：差异为什么没长进主干

这里要往回追一件事：为什么别的团队做多国，差异会一路长进代码里？

多数时候，是因为系统里没有“包”这个位置。一个新国家上来，需求以“这个国家要不要多一个字段”的形式提，开发就在流程里加一个判断；第二个国家再来，又加一个。加到第三个国家，主干里到处是“如果是 A 国就……”的分支，任何一个国家的规则一变，都要回头翻主干的代码。差异不是一天长的，是一次一次“顺手加一下”攒出来的。

反过来的判断是：差异一开始就该关在包里。包有边界，改包不会牵动主干；主干有边界，加国家不会牵动别人。这条边界划清楚了，多国并跑才不是一场代码的灾难。

两个包摆在一起，差在哪

把 pack_br 与 pack_mx 的差异列出来，会更容易看懂“包”这个概念。

巴西的差异，集中在认证与单一窗口。 pack_br 里，许可证要同时管 IBAMA、INMETRO、ANATEL 等；报关单证这边，巴西的单一窗口正把旧的 DI 与 LI 换成 DUIMP，2026 年 4 月的关停之后，海运与空运的大部分情形已经强制走 DUIMP，后面还排了 8 月 31 日与 12 月 1 日的节点。同一个市场，报关入口一年之内换了一轮——这在包里表现为“单证类型与过渡期”这栏的变化。

墨西哥的差异，集中在关税分档。 2026 年 4 月 23 日，墨西哥签署并公布了关税修正法令，对 185 个税号产品分 5% 到 35% 六档加征进口关税，4 月 24 日起生效；而 2026 年 1 月 1 日生效的那一轮，已经把 1463 个税号的税率抬到 10% 到 50%。税率被切成很多档，意味着同一批车里不同配置、不同税号的成本口径都要分开算——这在包里表现为“税务配置与税号映射”这栏的变化。

第三个市场的差异，又是另一类。 泰国在 EV 3.5 激励政策里要求享受优惠的车企本地化生产，2026 年的补偿比例是“进口 1 辆、本地生产 2 辆”。这不是税号问题，而是“进口量与本地生产量要挂钩”的口径问题——在包里表现为“本地化义务”这栏。

三个市场，三种完全不同的差异。但它们都能被同一套结构接住。

差异装进包，主干才敢不动。

公开报道里的证据

差异为什么必须被单独管理，公开报道里其实有答案。

巴西的单一窗口迁移是最典型的例子。DUIMP 正在逐步取代 DI 与 LI，把过去散在几个单据里的海关、商业、财务、税务信息收进一份记录；迁移期是双轨并行的，什么时候切、哪一类货物必须走新通道，节点一个接一个。如果系统里的“报关单证”是一段写死的逻辑，那每关停一次旧通道，就得改一次代码；如果它是包里的一个字段，那就是改一次配置。

墨西哥的关税分档也是同理。税率被切成 5% 到 35% 六档，还叠着 2026 年 1 月那轮的 10% 到 50%，涉及上千个税号。这种结构下，“整批一个平均税率”的算法根本站不住，必须按税号、按配置分别落到单车上。而税号与税率的对应关系，天然就是配置项，不是代码。

把差异关进包

这一环，算数·海辕的做法是给每个市场一个区域包，让差异有地方可去。

pack_br、pack_mx、pack_ph 按同一套接口扩展：语言、币种、许可证、报关单证、电子发票、仓库、齐套口径，全部写在包里；主干处理登录、流程、角色与权限，不随国家改动。以巴西为例，pack_br 里的许可证（INMETRO、ANATEL、IBAMA、ANVISA、MAPA）与报关单证（LI、DI、DUIMP）都是配置项，换市场时整包替换；墨西哥的 pack_mx 则是另一套税务配置与税号映射。

落到实际，这件事的效果是：第二个国家的边际成本，远低于第一个。汽车出口 · 外贸流程 · 当地税务 · 海外 4S 店管理，四块各自成模块，接起来是一条链；区域包负责的，是这条链在每个国家“接什么地方”的问题。

边际成本，才是多国复制的胜负手

第二个国家省下来的，比看上去更多。

第一个市场，通常是“从零搭一套”：主干要建、流程要理、角色权限要定、区域包要填。这里面大部分工作，是任何一个海外市场都要用到的——订购怎么走、发运怎么记、清关怎么跟、单车成本怎么摊、门店怎么交付、售后怎么接。这部分工作只做一次。

从第二个市场开始，真正新增的，只有“这一国和上一国不一样”的那部分。差异被收进包，新增的边际工作就只剩：确认差异清单、填包、验证。前面那份“上线只花三天”的排期表，省下的正是这一大块。

这也是“国家越多、代码越不该动”的另一面：不是代码不想动，是每动一次，多国并跑的维护成本就往上翻一层。

差异清单，是怎么确认出来的

“换包”听起来轻巧，但差异确认这一步不能省，也省不了。

一个实务上的办法，是拿上一个市场的包当模板，逐栏问“这一国变不变”：

语言变不变？巴西是 pt-BR，墨西哥是 es-MX。

币种与核算口径变不变？BRL 与 MXN，各挂各的本币核算。

许可证变不变？巴西那一串证，在墨西哥换成另一套。

报关单证变不变？巴西正从 DI、LI 迁到 DUIMP；墨西哥的入口是另一套。

税制变不变？巴西是 35% 与 14% 的分档，墨西哥是 5% 到 35% 的六档。

仓库与地址格式变不变？港口、内陆仓、地址写法都要重填。

逐栏问完，清单就出来了。清单越长，说明两个市场的差异越大；但不管多长，它都停在“包”这一层，不往主干走。

这一步看起来琐碎，却是多国复制里最值钱的一步：它把“要不要重做系统”这个让人焦虑的大问题，拆成了几十个小问题，每一个都有明确答案。

三个国家的包，共用一套骨架

把 pack_br、pack_mx、pack_ph 摆在一起，会发现一件有意思的事：三个包长得不一样，但骨架是一样的。

骨架就是那几栏——语言、币种、许可证、报关单证、仓库、齐套口径。每个国家填的内容不同，装的槽位相同。正因为槽位相同，换包才是“替换”而不是“重写”；也正因为骨架统一，一个人可以同时管三个国家，而不会因为口径各异而乱套。

这背后是一个设计选择：先把“每个市场都有的那几件事”抽象出来，再让具体的市场去填。抽象做得越准，后面每加一个国家的成本就越低。

反过来，如果一开始不是按骨架设计，而是按“巴西需要什么就加什么”，那 pack_mx 就得另起一套，第三个市场又另起一套——看着是尊重差异，实际是把差异变成了一堆再也理不清的一次性代码。

一句收尾

多国并跑真正的风险，从来不是功能不够，是差异没有边界。有了包，国家就不是代码里的分支，而是配置里的一行。

相关页面：产品矩阵、区域与海外交付、案例与演示、资源与洞察；如需按自己的链路逐项核对，可 联系我们。

说明：本文为〈算数·海辕〉实务观察，用于说明出海业务链路与系统能力，不含真实客户数据与虚构经营数字；所列税率、门槛与认证要求以目的国当期法规为准，数据来源见文末。