一套系统卖给十个客户：白牌交付里那三样归谁

把一套系统卖给十个客户，每个客户要自己的名字、自己的图标、自己的配色，这件事在签约那天看起来很简单：改十次包而已。

真正难的是第十一个月。那时候十个包里有一半改过需求，有两个客户换了对接人，有一个客户自己在外面找人动了包，还有一个客户的图标在系统升级之后变成了一个白方块。而所有这些问题，都会先打到你这里。

这一篇讲白牌交付：它为什么不是「改十次包」、三样东西必须在签约前就说清归谁、十个客户的差异应该放在哪一层、以及一年之后那次集体升级怎么走。官网是 www.apkeditor.cn。

一、白牌不是「改十次包」，是「养十条线」

先把这个误解拆掉，后面所有做法才立得住。

改十次包，是一次性的工作量。十个客户、十个名字、十个图标，一周能做完。做完的那一刻，十个包看起来都挺好。但包是会变的。系统要升级、需求要调整、客户要加功能、系统版本更新导致某个界面错位。每一次变化，都要在十个包上各做一遍。

这就是白牌真正的成本结构：首次交付占两成，后面一年的维护占八成。而绝大多数团队在报价的时候，只算了前两成。

所以白牌这件事的衡量标准，不是「十个包做得多漂亮」，而是「一次改动，能不能在十个包上各做一次而不出错」。前者是手艺，后者是产线。

产线的意思是：同一份代码、同一套资源结构、同一份差异清单、同一个打包流程。客户的差异全部收敛到一个地方，改代码的人不需要知道有十个客户，改品牌的人不需要碰代码。

这条线建起来之前，每加一个客户都是线性增长的成本；建起来之后，加客户变成了一件很轻的事。差别不在技术，在第一天有没有把结构想对。

我们内部做过对照。第一批五个客户是「来一个做一个」，第二个客户花了两天，第五个还是两天，因为每次都要重新翻一遍资源、重新找一遍哪里写死了名字。第二批五个客户改成先做差异表，第一个客户三天，后面四个各半天。

二、客户买的不是包，是「这是他自己的系统」

这一点想明白了，才知道该往哪儿使劲。

客户为什么要白牌？因为他不希望自己的员工、自己的客户看到另一个品牌。这背后是三层诉求，一层比一层深。

第一层是表面：名字、图标、启动页、配色。这一层最容易做，也最容易被当成全部。做完之后，客户打开看一眼，说「行」，然后就签收了。

第二层是内容：术语、字段名、默认值、示例数据。这一层开始有难度。同样一个「工单」，便利店叫「补货单」，药店叫「处方复核单」，物业叫「报修单」。如果界面里全是别的行业的词，客户会立刻觉得「这不是给我做的」。

第三层是通道：更新从哪儿来、出问题找谁、数据在谁那儿。这一层最容易被忽略，也最影响长期关系。一个更新提示里写着你公司名字的应用，哪怕界面全是客户的品牌，客户心里也知道这不是他的。

三层里，第一层决定了客户签不签，第二层决定了他用不用得下去，第三层决定了他第二年还续不续。而钱主要在后两层。

所以白牌交付的第一件事，不是打开工具改名字，而是坐下来问客户三个问题：这个应用在他那边叫什么、他打算自己维护还是一直交给你、他的数据最终落在谁的系统里。

三个问题的答案，决定后面所有的结构。答不上来就开工，等于把三个月后的返工提前预定了。

三、第一样：名字与图标归谁

这一样听起来最不用谈，实际上最容易吵。

名字和图标是品牌资产，而白牌客户的诉求是「这个资产归我」。但包是你打的，素材是你准备的，设计可能是你做的。等客户换了供应商，他能不能说「这个图标是我的」？这句话在签约时没人问，在分手时一定会问。

所以有三件事要写下来。第一，素材由谁提供。客户提供原始 logo 和配色，你只做适配，产权最清楚；你代做设计，就要说清版权归谁。第二，名字由谁定。客户定的名字，风险在他那边（比如重名、侵权）；你建议的名字，出了事你要担一部分。第三，改名字要不要另外收费。白牌客户最常见的额外要求是「我们改名了」「我们换 logo 了」。合同里没写，就会变成一次免费的返工。

这三件事里，第三件最实际。我们内部的合同模板里有一句话：交付后一年内，品牌素材（名称、图标、启动页文案）的变更包含在维护里，一年后单独计价。这句话不复杂，但它把「改个名字而已」这件小事从争辩变成了一条规则。

还有一个技术上的连带：名字不只是桌面上的那四个字。它还会出现在启动页、关于页、通知标题、分享文案、协议页、错误提示里。改一次名字，要动的可能是八九处。这就是为什么「改个名字」在报价里不能按一次算。

所以更稳的做法是：把所有会出现品牌名的位置，集中到一个地方。一个配置文件、一份资源表，改一处，全部跟着变。这件事在做第一个客户的时候就该做，因为它是唯一一件「越晚做成本越高」的事。

我们踩过一次。第一个客户的包里，品牌名散落在六处：应用名、启动页标语、关于页底部、分享文案、通知栏标题、协议页抬头。第二个客户改的时候漏了通知栏和协议页，用户装上去之后，通知里还是旧名字。那次之后才把这些收拢到一处。

四、第二样：更新通道归谁

这一样最容易被当成技术细节，实际上它是商业关系的分界线。

更新通道，就是「谁能给这个应用发新版本」。它有三种归属方式，对应三种完全不同的合作关系。

第一种，通道在你这里。客户永远从你这里拿新版本，他不能自己发。好处是版本可控，不会出现客户自己改坏了来找你；坏处是每一次升级都要经过你，你被绑定在这条线上。这是最常见的做法，也是最省事的做法。

第二种，通道在客户这里。你给他一份可发布的包，他自己传到他的分发渠道。好处是他自由，坏处是你再也管不住版本：三个月后他装的是哪一版，你不知道。

第三种，两边都有。你负责出包，他负责在自己的渠道分发。这是现实中最常见的形态，也是最容易出事的一种。因为「谁负责出包」和「谁负责发布」分开之后，中间那一步很容易断。

三种里，真正需要写进合同的只有一件事：客户能不能自己改包。能，就要接受「他改坏了你要能看出来」；不能，就要给他一条明确的求助路径。

还有一个连带问题：更新提示里的那句「发现新版本」，是谁的口吻？是你的产品，还是他的系统？这一句决定了客户对「这是谁的软件」的判断，比界面上任何一个 logo 都直接。

我们的做法是：白牌客户的更新提示，一律用中性表述，比如「发现新版本，建议更新」，不出现任何一方的主体名。既不是你的，也不是他的，是这套系统自己的。这一句话，省掉了无数次解释。

五、第三样：数据与账号归谁

这一样最敏感，也最少有人在签约时提。

白牌客户的员工用这个应用产生的数据，存在哪里？存在你的服务器上，还是他的服务器上，还是各存一部分？这个问题不写清，后面每一次故障都会变成一次信任危机。

三种常见结构。第一种，全部在你这边。你提供一套多租户系统，每个客户一个空间。好处是维护简单，坏处是客户会问「我的数据你能不能看到」，而答案通常是能。

第二种，全部在客户那边。你交付一套可以独立部署的系统，数据在他自己的机房或者他的云账号里。好处是客户放心，坏处是每个客户一套环境，运维成本翻倍。

第三种，混合。业务数据在客户那边，账号和配置在你这儿。这是折中方案，也是最容易出问题的方案，因为它把一次故障拆成了两半，排查时两边都要看。

不管选哪种，有三句话必须写进交付文档。第一，数据存在哪里，谁能访问。第二，客户要求导出数据时，多久能给、什么格式。第三，合作终止时，数据怎么处理、保留多久。

第三句最容易被忽略，也最贵。合作终止那天，客户第一句话通常是「把我的数据给我」。如果格式是自定义的，导出要现写代码；如果数据库里有其他客户的数据，导出还要做隔离。这些事在终止那天做，成本是提前做的好几倍。

所以更稳的做法是：从第一天起，就有一个「一键导出本客户全部数据」的功能。它平时没人用，但它的存在本身就是一种承诺。客户知道随时能走，反而更愿意留下。

六、十个客户的差异，只能放在一层

三样归属谈完之后，才轮到技术。而技术上只有一个问题真正重要：差异放在哪。

差异如果散在代码里，十个客户就是十个分支，半年之后没人敢合并。差异如果只放在一层，十个客户就还是同一份代码。这一层的选择，决定这条线能不能长期活下去。

在实际项目里，差异会出现在四个层次。第一层是资源：名字、图标、配色、启动页图。第二层是配置：首页放哪几个入口、默认打开哪个页、哪些功能可见。第三层是文案与术语：同一个字段在不同行业叫什么。第四层是逻辑：某个客户要多一个审批环节、多一个字段校验。

前两层几乎一定可以外置，因为它们本来就是数据。第三层大部分可以外置，做成一份术语表。第四层只能进代码，而它也是最危险的一层。

所以有一条很实用的原则：能外置的绝不进代码，必须进代码的绝不超过三处。三处是经验值，超过三处，就说明这个需求应该做成通用功能，而不是客户定制。

这条原则的执行方式是：每个客户一份配置文件，里面只有四块内容：品牌素材、首页入口、术语替换、功能开关。改一个客户，只改这一份文件；打包的时候把这份文件塞进去，其余全部相同。

这样做的好处很直接。代码只有一个版本，系统升级时十个客户一起升；出问题只需要查一处，因为代码是同一份；新客户上线只需要写一份配置，不需要另开分支。

代价也有。配置本身要有校验：字段写错了、图片尺寸不对、术语表漏了一项，都不会报错，只会表现成「某个界面怪怪的」。所以配置需要一个检查动作，打包前跑一遍，把明显的错误挡住。

七、第一个实例：五个客户共用一套更新配置

这是我们自己做白牌时踩的最实的一个坑，值得完整讲一遍。

当时五个客户，图省事，共用了一套更新配置：一个后台、一个版本号入口、一份更新说明。逻辑是「反正是同一套系统，版本号一样，更新内容也一样」。

第二个客户上线两周后，第一个客户的用户收到了更新提示，点进去装上了第二个客户的包。品牌、名字、图标全变了。

原因很直接：更新配置里有一个下载地址，而那个地址是按「最新版本」查的，不区分客户。第一个客户的用户查到的「最新版本」，是第二个客户刚发的那一版。

这件事的严重程度被低估了。它不是「装错了包」，而是「一个客户的员工，桌面上突然出现了另一个客户的品牌」。这在商业上很尴尬，解释起来尤其难。

修法有三步。第一步，更新配置按客户拆开，一个客户一套，互不可见。第二步，下载地址带上客户标识，服务端校验，不匹配就拒绝。第三步，版本号按客户独立递增，不再共用。

第三步是这次事故真正的根因。共用版本号意味着「谁后发谁覆盖」，而五个客户的发布节奏根本不一样。第一个客户一个月发一次，第二个客户一周发一次，共用版本号必然混乱。

这件事之后我们定了一条：白牌客户之间，不共用任何「会指向具体某个包」的东西。更新配置、下载地址、版本号、推送通道，四样全部按客户独立。可以共用的是代码和资源结构，不能共用的是出口。

八、第二个实例：客户要自己发版，我们给了什么

另一个客户规模比较大，有自己的 IT 部门，明确要求「包我们自己发，不经过你们」。

这个要求合理，但它带来一个必须回答的问题：他自己发的包，和我们发的包，是不是同一个东西？如果不是，以后出了问题，责任说不清。

我们的做法是给他三样东西，而不是一个包。

第一样，一份可复现的打包说明。写清楚用哪个版本的工具、改哪几个文件、签名用哪一份、打完怎么验。一页纸，五个步骤。这份说明的作用不是让他学会，是让「他打出来的包」和我们打出来的可以对比。

第二样，一份校验清单。打完包之后逐项核对：应用名对不对、图标有没有角标、启动页文案对不对、版本号有没有递增、签名指纹是不是那一份。五项，两分钟。

第三样，一个「包体检」的入口。他打完之后把包发给我们，我们跑一遍检查，回一句「可以发」或者「版本号没加」。这一步看起来是我们多干了活，实际上省掉了后面所有的扯皮。

三样东西给出去之后，关系反而更清楚了。他负责发，我们负责「这个包对不对」。出了问题，先看包体检的记录，是谁的问题一目了然。

这件事有个反直觉的结论：客户要自己发版，不是要脱离你，是要掌握节奏。把「怎么发才对」教给他，他反而更依赖你；把包丢给他不管，他发错一次就不敢再发了。

九、交给客户自己改，边界画在哪

白牌做久了，一定会遇到一个问题：客户想自己改。这是个好信号，说明他真把这个应用当成自己的东西。但边界不画清，后面会很难看。

边界可以按「改坏了谁承担」来划。三个区间。

第一个区间，随便改：名字、图标、启动页文案、关于页里的联系方式。这几个地方改错了，最多是显示不对，不会影响功能。把它们做成客户自己能操作的形式，比如一份配置表加一个重新打包的入口，客户改完自己出包。

第二个区间，改之前要问你：首页入口的增减、术语替换、默认打开哪个页面。这些改动会影响用户的路径，改错了不会报错，但会让「演示时讲的流程」和实际不一样。做法是给他一份模板，改完发给你看一眼再打包。

第三个区间，不要给他：权限、包名、签名、版本号规则。这四个是「改错了整个包就废了」的东西。权限删多了功能静默失效，包名改了数据全丢，签名换了装不上，版本号错了升不上去。这四样不是不信任客户，是它们本来就不该由使用者来定。

三个区间的分界线，可以用一句话概括：改错了「看得见」的，给他；改错了「看不见」的，你留着。看得见的问题，客户自己会发现；看不见的问题，要等到某天突然爆发。

还有一个具体的做法值得推广：给客户一个「改完自检」的小工具或者清单，五到八项，改完自己打勾。这个动作把「我改完了」变成「我确认过这几点」。它不解决所有问题，但它把大部分低级错误挡在了客户那边。

我们内部的经验是：给了边界之后，客户自己改的比例会明显上升，而找你返工的比例会明显下降。因为他不确定的地方会先问，而不是先改了再说。

十、白牌的报价结构：三段，不是一次

这一节不谈具体数字，只谈结构。因为结构错了，数字怎么填都是错的。

白牌项目的报价，通常被写成「一套多少钱」。这个写法在第一个客户那里成立，从第二个开始就不成立，因为第二个客户的成本里有很大一块是「复用第一个的成果」。

更贴近实际的结构是三段。第一段，一次性交付：品牌适配、配置编写、打包、验收。第二段，年度维护：系统升级跟着升、品牌微调、问题响应。第三段，按次计费：超出边界的定制、额外的行业版本、数据迁移。

三段里，第二段最容易被漏掉，也最影响长期。很多白牌项目第一年做得很好，第二年客户要升级系统，报价一出，客户觉得「你怎么又要钱」。原因是第一年没把「维护」这件事单独标出来。

第二段的价值在于它把关系从「项目」变成「服务」。客户每年付一笔，换的是「系统跟着更新、出问题有人管、品牌随时能调」。这笔钱对他来说是可预期的，对你来说是可预期的收入。而按次计费的模式，双方都在赌。

第三段要写清「什么算超出边界」。不能写「重大变更另计」，因为「重大」这个词一定会被争。要写成具体的：新增一个功能模块、新增一个行业版本、数据结构变更导致迁移、跨平台适配。四类，写死。

还有一个经常被忘的成本项：素材制作。客户给的 logo 是 jpg、是带白底的、是 800 像素的、是横版但应用要方版。把它做成能用的图标，可能是半天到一天的活。这一项要么单独报，要么写进「素材由客户提供合格文件」的前提里。

我们现在的做法是：报价单里把「素材适配」单独列一行，哪怕报价是零，也要列出来。列出来客户才知道这是一件有成本的事；不列，他就会觉得「不就是换个图吗」。

十一、一年之后：十个客户怎么一起升级

白牌线跑到第二年，最大的考验来了：底层系统要升级，十个客户要不要一起升？

这件事没有标准答案，但有三种典型做法，各自适合不同的客户结构。

第一种，全部一起升。同一天，十个客户都换到新版本。好处是版本统一，维护成本最低；坏处是风险集中，一旦新版本有问题，十个客户同时出状况。适合客户数量少、且都是长期合作的情况。

第二种，分批升。先升两个配合度高的，观察一周，再升剩下的。这是最常见的做法，代价是要同时维护两个版本一段时间。而「同时维护两个版本」的成本，往往被低估。

第三种，按客户节奏升。每个客户自己决定什么时候升，你只负责出包。好处是客户满意，坏处是半年后可能有五个版本在跑，任何一个问题都要在五个版本上分别确认。

三种做法里，真正的关键是：升级之前，有没有一份「这次升了什么」的清单。清单要能对客户讲清楚三件事：哪些行为变了、哪些界面变了、哪些数据要迁。

第三件事最重要。数据结构变了，升级就不是换一个包，而是一次迁移。而迁移的风险跟客户的数据量、数据脏乱程度直接相关。十个客户里，一定有一个的数据是最乱的，而他会是升级过程里唯一出问题的那一个。

所以更稳的顺序是：先升数据最乱的那个客户。反直觉，但有效：如果他都没问题，其他人基本不会有问题。反过来，先升最干净的那个，等于把风险留到最后。

还有一件事要提前做：每个客户的「当前版本」要有记录。十个客户分别在哪个版本，谁能查、怎么查。没有这张表，升级就变成了一次盲发。

十二、八个问题，签约前就该问清

下面这八个问题，是我们做过几轮白牌之后总结的。每一个都对应过一次真实的争辩。

问题一：客户要的是白牌，还是定制？白牌是「同一套系统换个牌子」，定制是「按他的流程改功能」。这两件事的工作量和后续成本差一个数量级，签约前必须分清。判断标准很简单：如果他的需求需要改代码，那就是定制。

问题二：他的员工有多少人，分布在几个地方？这决定升级的方式。几十个人可以逐个通知，几百个人就得靠推送和强制更新。而强制更新这件事，客户未必同意。

问题三：他自己的 IT 能力到什么程度？有没有人能装包、能不能改一张图、懂不懂签名。这决定你给他多少自助能力。给多了他改坏，给少了他天天找你。

问题四：这个名字和图标，是他提供的还是你做的？产权问题前面讲过，但这里要多问一句：他有没有在别处用过这个品牌？如果有，图标和应用名要一致，不然员工会认不出来。

问题五：他的数据能不能出他的网络？有些客户（尤其是制造业、医疗）明确要求数据不出内网。这一条一旦成立，整套架构就要改，不是加个配置能解决的。

问题六：他会不会自己再找别人改？这个问题不太好问，但必须知道答案。如果他找了别人改，签名可能变，签名一变，你后续的包就装不上了。

问题七：他那边谁是对接人，这个人稳不稳定？白牌项目的所有沟通都会经过一个人。这个人一走，前面所有的口头共识都会失效。所以共识要落成文档，不能只停在聊天记录里。

问题八：如果明年他不续了，会发生什么？这个问题最不舒服，但它决定你要不要在一开始就把数据导出、文档、源码这些东西准备好。想清楚退出，才谈得上长期。

八个问题里，第一和第八最重要。第一个决定这个活该不该接，第八个决定这个活能不能体面地结束。中间六个，决定过程顺不顺。

十三、八项验收：交付前逐条打勾

白牌交付的验收，和普通改包不一样。普通改包验的是「这个包好不好用」，白牌验的是「这个包是不是他这个客户的」。八项，缺一项都会在交付后被指出来。

第八项是白牌特有的，也是最要命的一项。普通改包不存在「更新指错」的问题，因为只有一个应用；白牌有十个，指错一次就是把别人的品牌装到自己的员工手机上。前面第七节那个事故，就是这一项没验。

第五项也值得单独说。通知栏标题和分享文案，往往不在资源文件里，而在代码里写死。改资源的工具改不到它们，装上去之后一切正常，直到某天员工收到一条通知，抬头写着别的名字。验证方法很简单：发一条测试通知、分享一次给同事，两分钟。

这八项跑完大概二十分钟。二十分钟换掉交付后一个月的解释，这个交换在任何项目里都划算。我们现在的做法是把它印在交付单背面，客户签收时一起签。

再多说一句关于第三项和第六项。启动页和协议页这两处，是白牌交付里最容易被「看起来改完了」骗过去的两个地方。启动页只在冷启动出现一两秒，热启动看不到；协议页藏在设置里，验收时没人翻。而这两处恰恰是客户最容易碰到的：每次打开应用都会看到启动页，合规检查一定会翻协议页。

所以验这两项有一个小技巧：先把应用从后台彻底划掉，再点图标打开，这样看到的才是真正的启动页；协议页则直接在设置里翻到底，不要用搜索。两个动作，二十秒，但它们能挡住两次返工。

十四、一次返工的账：两个客户的品牌弄反了

把第七节那个事故算一遍，会看到很典型的白牌成本结构。

发现时间：两周。第一个客户的员工在群里问了一句「我们公司什么时候改名字了」，才有人注意到。修复时间：两天。拆配置、改地址、加校验、重新打包、五个客户各发一次。

解释时间：三周。第一个客户要一份书面说明，为什么他的员工会看到别人的品牌；第二个客户也来问，是不是他的数据也被看到了。三周里没有一行代码，全在修复关系。

三笔加起来，比例大概是 1 比 1 比 8。修复一天，解释一周——这就是白牌事故的成本结构。而它和普通改包事故的区别在于：普通改包出问题，影响的是「功能」；白牌出问题，影响的是「信任」。

更麻烦的是，这种事故会留下永久性的印象。客户以后每次看到更新提示，都会多看一眼是不是自己的牌子。这个动作一旦形成，你做的每一件事都要多解释一句。

所以白牌这件事，真正的杠杆不在「做得快」，在「不出错」。一次品牌串台的代价，可能等于十个客户的利润。

这件事之后我们改了三处流程。一是打包前必须看「这个包里的品牌标识是哪个客户」，写在打包单第一行。二是每个客户的包里带一个不可见的客户标识，出问题能立刻反查。三是交付验收的第八项从「可选」改成「必查」。

三处改动加起来不到半天，但它们把「会不会串台」从一件靠记性的事，变成了一件有检查的事。流程的价值就在这儿：它不让你更聪明，它让你不必那么聪明。

十五、把「做一个白牌」写成一句能执行的话

「下个月有个客户要白牌版本，你安排一下」——这句话派下去，做出来的一定和你想的不一样。

一句能执行的话：这次给新客户做白牌包：应用名用他提供的名字，图标用他给的方版 logo，配色沿用我们的主色不改；首页三个入口保留补货、盘点、报表，其余入口从首页移除；版本号从这一批的号段里取下一个，独立递增；更新配置新建一套，只指向他自己的下载地址；签名沿用同一份，不许重新生成；交付前按八项验收逐条打勾，第八项必须点一次「检查更新」确认指向自己。

这句话里有六个必须写清的点。第一，名字和图标从哪儿来，避免做到一半再要素材。第二，首页放哪几个，这一条决定这个包给他的第一印象。第三，版本号从哪儿取，避免和别的客户撞。第四，更新配置新建，这是第八项验收能不能过的前提。第五，签名不许换，一句话挡住后面所有装不上的问题。第六，验收按哪张表，写清「第八项必须点」，而不是「验收一下」。

还可以补两条。一是「素材不合规就退回」：客户给的图太糊、带白底、尺寸不对，先退回要合格的，不要自己硬修。二是「改完记一行账」：这个客户用了哪个号段、哪份签名、哪套更新配置，写进客户档案。下一批客户来的时候，这一行账能省掉一次翻查。

我们内部现在把白牌交付写成一张六行的单子：名字与图标、首页三入口、版本号、更新配置、签名、验收表。六行填完，做的人不用再问。写这张单子十五分钟，能省掉一次串台。

十六、三句话，把这件事收住

第一句：白牌不是改十次包，是养十条线。首次交付只是开头，后面一年的维护才是主体。想清楚这一点，才会在第一天就把结构搭对，而不是把十个包各改一遍。

第二句：品牌、更新、数据，三样必须在签约前说清归谁。这三样决定了第二年还续不续，也决定了分手那天能不能体面。它们不是技术问题，是关系问题，而关系问题只能用文字解决。

第三句：十个客户的差异，只能放在一层。资源、配置、术语可以外置，逻辑进代码的不能超过三处。差异散在代码里，十个客户就是十个分支；差异收在一层，十个客户还是同一份代码。

三句合起来是一件事：白牌卖的是一套系统被十个人当成自己的那种感觉，而支撑这种感觉的，是一条能重复的线。线搭好了，加客户很轻；线没搭好，每个客户都是一次重来。

最后补一个很实际的观察。白牌做到第五个客户左右，团队里会有人开始抱怨「每个客户都要重新看一遍」。这不是能力问题，是这条线还没成形。成形的标志是：来一个新客户，第一个反应是「去把那张差异表拿出来」，而不是「先把包解开看看」。

这个转变通常发生在三件事都做完之后：品牌名收拢到一处、首页入口做成配置、八项验收印成一张纸。三件都不难，难的是它们必须在「还没有第十个客户」的时候做。等到第十个客户来了再做，就是一边救火一边改结构。

所以如果只能给一条建议：在做第二个客户的时候，就按第十个客户的结构去做。第二个客户是最合适的时机，因为你已经知道差异在哪，成本还没堆起来。而第三个、第四个客户，都会沿着第二个的结构长出来。

十七、附：一页速查

下面这张表把全文压成八行，谈白牌或者准备交付的时候可以对着看。

这八行里，最容易被划过去的是「三样归属」。因为它不像技术问题，所以没人愿意在技术评审上讨论它。但它一旦没谈清，后面每一个技术决定都会变成一次谈判：这个功能加不加、这个改动收不收钱、这个包谁来发。先把归属定下来，技术才有得选。

还有一句可以写在最前面：白牌交付的目标不是「做出十个包」，是「让第十一个客户来的时候，你能在一周内交付，而且不心虚」。前者是一次项目，后者是一条产线。而产线的判断标准很简单：新人能不能照着单子做出来。

顺带说一句，白牌交付里那些「只动资源和配置」的活，最耗时间的其实是十个包各打一遍。安卓修改大师智改工坊把品牌素材替换、首页入口调整、回编和签名放在一次流程里，改完可以真机预览再确认，产品介绍页在 这里，官网 www.apkeditor.cn 上有完整的功能说明。

十八、用过的人怎么说

这一篇里的两个实例，都是我们自己维护的应用：一个门店经营管理平台，一套现场巡检端。白牌这件事的难处不在改包，在「十个客户各自是一个活的主体」：他们会改名、会换对接人、会自己找人动包、会有各自的升级节奏。文中的三样归属、差异分层和八项验收，都是从这类真实摩擦里长出来的。

合规提醒：本文所有实例均针对自有版权或已获授权的应用，用于企业内部维护、白牌交付与合法定制。白牌交付前请确认你拥有目标应用及相关品牌素材的合法使用权，不得为他人的应用或品牌制作冒充分发版本，也不得通过改包规避授权校验。

白牌卖的是一种「这是我自己的系统」的感觉。而感觉这种东西，只有在不出错的时候才成立。

安卓修改大师智改工坊能做的，是把改包之后那一串动作一次落到位：品牌、入口、版本号、更新通道一次改到位，改完可以真机预览再确认。说清楚，就够了。