三个校区一套应用：一份基准、一张差异表、几次打包

先说一个很常见的处境：你手上有一个自己做的应用，功能是通用的，但要给三个地方用。——三个地方的名字不一样、主色不一样、客服电话不一样、公告栏里要写各自的通知——而功能完全一样。

这种"一套功能、多份身份"的需求，在现实里到处都是：多个校区、多个门店、多个事业部、多个客户。——而它的难处不在"改"，在"改完之后怎么维护"——因为从第二份开始，你面对的不再是"一个应用"，而是"一组必须保持一致的应用"。

而大多数人的第一反应是"复制三份工程"，然后各改各的。——这个做法在第一个月没问题，在第三个月会开始疼：你改了一处逻辑，得记得在另外两份里也改一遍；而某一次你忘了，于是三个版本开始分叉。——再往后，你不敢动任何一份——因为你不确定另外两份改到哪儿了。

「安卓修改大师智改工坊」在这件事上的思路很简单：一份基准、一份差异清单、多次打包。——也就是说，你要维护的不是三份工程，而是"一份工程 + 一张写着三份差异的表"。——而这张表，才是这类项目真正的资产。

只需说话，就能让应用变成你想要的样子。而"多份身份"这个场景里，这句话的用法是：用一句话说清"这次要改什么"，然后对着差异清单挨个打。想先看看项目目录长什么样，可以从 https://www.apkeditor.cn/ai-version.aspx 下载「安卓修改大师智改工坊」，导入一个自己的应用建个项目，再看一眼它的 config.ini——那张表该记什么，看过就懂了。

一、先把差异列出来：通常会变的有八处

多份身份这件事，第一件该做的不是动手，是列清单。而我们做过几个这类项目之后，发现通常会变的就那八处。

一是应用名。——桌面上显示的那个名字，三个校区各不相同。——这处改动有个隐藏的连带项：应用名的长度不一样，桌面上图标下面的文字可能被截断——所以最好一次确认三个名字的显示效果。

二是应用图标。——通常是在同一个图形上换颜色或者换角标。——这处最容易踩密度档的坑（后面单独讲）。

三是启动页。——背景色加一个校名/店名。——这处建议只换配色和文字，不要换版式——因为版式一换，三份的视觉就不再是"同一个应用的不同身份"，而是"三个不同的应用"。

四是主色。——按钮、标题栏、高亮色跟着变。——这处最省事也最容易漏：省事是因为它通常是同一个资源，漏是因为有些页面把颜色写死了。——所以要有一份"哪些页面会用到主色"的清单——而这份清单靠翻一遍应用、把用主色的位置记下来就够了。

五是客服电话和地址。——这类信息通常在"关于"页或者帮助页。——而这处要特别小心：它们不只是显示——有些应用会把电话号码做成可点击的拨号——所以改的时候连长什么样都得对。

六是域名或服务地址。——如果应用要连自己的后台，这一处必须变。——而它是"看不见的差异"——界面上完全体现不出来，装错了版本也不会立刻报错，只会在某个功能上莫名其妙地失败。——所以这处必须写进差异清单的第一行。

七是公告与活动位。——首页那条滚动通知、或者某个活动入口——各写各的。——这处变化最频繁，而它恰好是最适合"每次单独改一句话"的地方。

八是包名和签名。——这一处最技术，也最容易被前面的清单忽略。——如果你希望三个版本能装在同一个手机上（比如管理员要同时看三个校区），那包名必须不同；而如果包名不同，签名是否相同就不影响互装——但每一个包名配哪份签名，仍然要固定下来。

把这八处列成一张表，你会发现它的形状很特别：前七处是"看得见的差异"，第八处是"决定它们怎么共存的差异"。——而很多人只列前七处——于是三个包在同一个手机上互相覆盖，装一个顶掉一个。——而这个问题的解法不是"小心一点"，是在清单里给第八处留一行。

有人会问：为什么不直接讲"怎么用工具把三个包做出来"，要先讲一张表？——因为这类项目的失败，几乎都不是"不会改"，是"没想清要改什么"。——工具能替你改一个字、换一张图、打一个包，但它替不了你决定"这三个身份到底差在哪"。——而那张表定下来之后，剩下的都是机械动作——机械动作恰恰是工具最擅长的部分。

二、为什么不复制三份工程

"复制三份、各改各的"是最直觉的做法，而它的问题不在于"做的时候麻烦"，在于"三个月后不敢动"。

问题一：改一处要改三次，而"三次"里必有一次会漏。——这不是态度问题，是注意力问题——你在第二份里改了同样的地方，第三份改到一半被别的事打断，回来就忘了。——而漏掉的那一处，通常不会立刻暴露——它会等到某个校区反馈"我们这儿好像没变"，你才发现。

问题二：三份工程会慢慢分叉，而分叉之后就没法合并了。——第一周它们只差那八处；第三个月，A 校区加了个"课表提醒"，B 校区说要"改成周视图"——于是 A 和 B 的代码结构开始不同。——而以改包这种方式工作，你手上没有版本控制——"把 A 的那个功能搬到 C"这件事，只能靠人一点点找。

问题三：三份工程意味着三份历史，而"这个改动什么时候做的"再也没法回答。——因为每个项目目录里各有一份 history.ini，记录的是各自被改过什么。——而如果你想知道"主色那次调整是怎么定的"，你得在三个历史里找同一个时间点——而它们的时间还未必对得上。

那正确的做法是什么？一句话：把"共同的部分"集中在一处改，把"不同的部分"当成参数。——而在改包这个工具里，这个思路落到操作上就是：一个"基准项目"，加上一份"差异清单"，然后用同一套话术打三个包。

为什么不是"一个项目打三次"？——因为一个项目只有一个 config.ini、一份签名、一个 history.ini——打三次就是同一份配置打三次，出来的包一模一样。——所以三个身份要三个项目，但三个项目的建立方式可以是"复制同一个已改好的项目目录"，然后各自改那八处。

再补一个容易忽略的细节：这三个项目各自有一份源包拷贝。——建项目的时候，工具会把源包复制进项目目录——所以三个项目目录里各躺着一份 apk，加起来占的是三个包的空间。——这个设计看着像"浪费"，其实是有意的：每个项目目录自成一体，你把它拷给别人、或者哪天删掉它，都不会牵动另外两个。——而项目目录里的 config.ini 记着这个项目的名字、源包位置、图标和签名设置——所以源包文件本身叫什么名字都无所谓，关键是别在项目还在用的时候把它挪走。——真想省空间，该删的是"已经交付完的旧项目"，而不是去动还在维护的那三个。

这里有一个很省事的操作，值得说清：项目目录是可以整个拷贝的。——你把基准项目的那个八位名字的文件夹拷两份、改成两个不同的目录名，刷新列表，就有了三个项目——它们的工程、配置、历史完全一样。——然后你只需要在每个项目里改"属于它自己的那几处"。

而这个做法最大的好处，是它把"共同改动"变成了一件只做一次的事：——下次要改共同的功能（比如加一个新页面），你先在基准项目里改、验证、打包；确认没问题之后，把这个项目目录再拷一份，然后把另外两份的身份字段按各自的清单重新对一遍。——而"对一遍身份字段"这件事，通常就是一句需求改文案、一张图换配色，然后各打一次包。

顺便说清一件事：这个做法听起来像"手工做版本管理"，确实如此。——而它之所以够用，是因为这类项目的差异是"少而稳定"的——八个字段、一年改几次。——如果你发现差异已经多到"每次都要重新想一遍"，那说明该考虑别的办法了（比如从源头做多渠道构建）——那不是改包能解决的问题，硬撑只会越来越慢。

三、差异清单写成什么样

这张表不需要什么工具——一张表格就够。但它的列怎么定，决定了它好不好用。

我们的列是这样的：差异项、A、B、C、备注。——行是那八处，列是三个身份——而"备注"那一列用来写"这处的改动要注意什么"。——而这张表最有价值的一列，其实是备注。

差异项	备注（这处要注意什么）
应用名	长度不同会影响桌面文字显示
图标	准备多个密度档；别把九图换成普通图
启动页	只换配色和文字，不换版式
主色	先列出哪些页面用到主色
电话与地址	注意是不是可点击的拨号
服务地址	界面上看不出来，装错不报错——写第一行
公告与活动	变化最频繁，适合每轮单独改
包名与签名	决定能不能并存，一开始就定

现在说那三个坑，每一个都值得提前知道。

坑一：图标只给了一张大图。——三个校区各给一张 1024 的图，看起来够"高清"，但装到手机上可能变糊——因为系统要的是对应密度档的尺寸，而它只能从你给的那一张缩。——正确做法是让设计一次导出多个尺寸；如果只能给一张，至少给最大的那一档，让程序往下缩。

坑二：包名打算"以后再说"。——包名是这份清单里唯一"越晚改越贵"的一项。——因为它写在清单文件里，还被别处引用——改它可能要连带改若干处引用，属于"较重的改动"。——而如果三个校区将来会装在同一台管理机上，那包名从一开始就得不同——否则后改的时候，前面装过的机器全要卸载重装。

坑三：签名以为"反正都是我们打的"。——三个身份可以是同一份签名——只要它们不装在同一台设备上、或者包名不同。——但如果你为了省事，中途换了某个身份的签名，那这个身份之前装过的所有设备，升级时都得卸载。——而设备清单通常比你想的长。

这三个坑有个共同点：它们都不是"改的时候出错"，是"决定的时候没想到"。——而多身份项目的成本，八成花在这类"决定"上——所以那张表的备注列，其实是在替未来的你记事。

顺便把图标这一处说得更具体一点，因为它是三个身份里最容易做出差别、也最容易出问题的一处。——常见的做法是"同一个图形、换主色"——这样三个图标放在一起，一眼能看出是一套，也一眼能看出不是同一个。——而要做这件事，改的其实只有一张图，但它要按密度档分别导出——否则系统在某个密度上只能拿一张小图放大，看起来就是"糊"。——而这个细节之所以值得写进备注列，是因为下次你换图形的时候，会想不起上一次是怎么导的。

四、两个自家应用：从"复制三份"到"一份加一张表"

我们做过两个这类项目。第一个是走弯路走出来的，第二个是照着第一个的经验直接做对的。

例子一：三个校区共用的教务查询应用。

以前怎么做：——这是内部应用，一开始只有一个校区用。第二个校区要的时候，我们的做法是"复制一份工程，把名字和颜色改掉"。——改的时候还挺顺——毕竟只差那几处；而问题在两个月后：主应用加了一个"成绩单导出"的功能，我们得在另外两份里各做一遍。——而做第二份的时候，我们发现第一份里有一处文案写错了——于是那一轮其实改了三处，只有一处是功能。

更麻烦的是第三个月：——第三个校区提了一个只属于他们的需求（要在首页加一个"食堂菜单"入口）。——而这个需求如果只加在第三份里，三份就开始分叉了——以后每次共同改动，都得先想"这个改动会不会碰到那个食堂入口"。——那一次我们停下来重做了一遍：把三份的差异压回那张八行的表，其余的全都对齐到同一份。

现在一句话怎么做：——共同改动只在基准项目里做，一句话说清——比如"在首页顶部加一条滚动公告，内容先写『本周课表已更新』"。——验证通过之后，把这个项目的目录拷出两份，各自改名字、配色、公告内容——每一处都是一句话的量级。

改完怎么验证：——三次打包、三次装机，每次只看四样：桌面上的名字对不对、启动页的校名对不对、首页主色对不对、"关于"页的电话对不对。——四样都对，这一轮就算过了——而这四样恰好覆盖了八处差异里"看得见"的那四类。

例子二：两家门店共用的会员端。

以前怎么做：——这个是给我们自己两家门店做的会员查询应用，功能是查积分、看优惠券。——第一次做的时候我们想"就两家，干脆做两个完全独立的项目"——结果是：优惠券的规则一改，两边都要改；而两边的版本号慢慢就不一致了，某天店员说"我这台看不到新券"，查了半天发现是那台装的是上一版。

现在一句话怎么做：——一份基准加两个身份，而两家门店的差异其实只有三处：店名、主色、客服电话。——于是那句需求可以写得很具体："把首页顶部标题改成某某店会员中心，主色改成这个色值，底部客服电话改成这个号码，其它不要动。"——而"其它不要动"这四个字，是这类改动里必须有的——因为改动越少，越不容易带出意外。

改完怎么验证：——两台门店的平板上各装一次，各看三处：标题、主色、电话；然后各查一次积分，确认服务地址没装错。——最后这一下最关键——因为服务地址是"看不见的差异"，只有真查一次才知道连的是不是自己的后台。

这两个例子的区别很清楚：第一个是"先做了再想"，第二个是"先想了再做"。——而两者最后的形态一模一样——都是一份基准加一张表。——差别在于：第一个花了三个月才到这儿，第二个第一天就在这儿。——而那张表其实不需要什么洞察力——它只是把"你已经在做的事"写下来而已。

五、一次共同改动的六个步骤

知道原理之后，落到操作上是一条固定流程。我们内部把它叫"六个步骤"，每次共同改动都按这个走。

第一步：在基准项目里改。——不碰另外两份。——这一步的关键是"只改共同的部分"——如果这个改动只在某个校区生效，那它不该走这条路，它该单独在那个身份里改。

第二步：在基准上验证。——装到一台测试机上，把这次改的地方看一遍。——为什么一定要在这一步验证？因为接下来你要把这份工程复制两次——如果这里有个错误，你会把它复制成三份。

第三步：拷两份目录，覆盖原来的两个身份。——也就是"用新的基准工程，替换掉另外两份的工程部分"。——而这里有个顺序讲究：先把旧的目录改名留着（比如加个 -old 后缀），再把新的拷进去——这样万一出事，旧工程还在。

第四步：各自对一遍身份字段。——名字、图标、启动页、主色、电话、服务地址、公告——按那张表挨个过。——这一步最枯燥，但它就是这套做法的成本所在——而它的成本是"八行乘以二"，不是"重做两个应用"。

第五步：三次打包。——三个项目各点一次打包。——而这一步有一个必须核对的东西：每次都看一眼 pack.log 里那行"签名方式"和证书指纹——三份应该指向同一份签名（如果你用的是同名同签名的策略）。

第六步：三次装机，各看四样。——名字、启动页、主色、电话。——再补一次"真查一次数据"（确认服务地址对）。——而这四样加一次查询，恰好是"看得见的差异"加"看不见的差异"。

这套流程的时间预算，我们量过几次：——基准改动加验证，取决于改动本身；后面的三步（拷贝、对字段、打包）大概二十到三十分钟；装机验证三台，十分钟左右。——也就是说，一次共同改动的"额外成本"是半小时——而它的收益是"三份永远一致"。

步骤	大概耗时
基准改动 + 验证	看改动大小
拷两份、对字段	十五分钟左右
三次打包	十到十五分钟
三台装机各看四样	十分钟左右

这套流程里，第三步的"先改名留着"值得再强调一次。——因为它是唯一一步"可能把旧东西弄丢"的操作——而加上一个 -old 后缀，成本是两秒，收益是"出事能退回去"。——而这个习惯在小项目里显得多余，在"三份必须同时正确"的项目里，它是你唯一的保险。

第六步其实还能更省一点，前提是你信任前五步。——我们的做法是"第一台看全部、后两台只看两样"：第一台把四样加一次查询都过一遍；后两台只看"名字"和"查一次数据"。——因为如果三份来自同一次拷贝，那启动页和主色的差异是"照着表对出来"的——出错概率低；而名字和服务地址是最容易对错的两项。——这个"分级验证"省下的时间不多，但它让"每轮都完整验证"这件事变得可行——而不可行的流程，最后一定被跳过。

六、三份包怎么管：命名、归档、台帐

多身份项目真正的麻烦，往往不在改，在"改完之后"。三个包长得几乎一样、名字只差一个字、存在三个目录里——而你要记住哪台机器装的是哪个。

第一件事：给包改名。——程序打出来的包叫 signed.apk——三份都叫这个名字，拷到同一个文件夹里就会互相覆盖。——所以每次打包完，第一件事是把它拷出来、改成"应用名-身份-版本-日期"。——而这个命名规则里，"身份"那一项不能省——因为应用名往往是一样的（叫"教务查询"），只有身份不同。

第二件事：建一个归档目录，按身份分文件夹。——不是为了好看，是为了"找的时候不用回忆"。——而它还有一个实际作用：当某台设备上的版本出问题，你能立刻找到"这台装的是哪一份"。——而这件事在只有一个身份的项目里靠记忆就够，在三个身份的项目里靠记忆一定会错。

第三件事：一张台帐，记四列——设备、身份、版本号、装机日期。——设备那一列写清楚是"哪个校区哪台机器"（比如"东校区前台平板"）；版本号写那个整数；装机日期写你装的那天。——这张表的价值在半年后：当有人说"我这台好像不对"，你能在十秒内回答"你那台装的是哪个版本"。

为什么版本号要写那个整数，而不是那个给人看的字符串？——因为覆盖安装的判断用的是整数——而字符串可能被构建脚本写成固定值，于是三份的字符串都一样。——而"一样"的字符串，在排查时提供的线索是零。

顺便说三个更细的习惯，都是踩出来的。

习惯一：打包之前先确认当前打开的是哪个项目。——因为三个项目的界面长得几乎一样——同一个应用、同一个图标（如果图标还没换）、只差名字。——而在错误的项目里改一句话、打一次包，你会得到一个"看起来对但其实错"的包。

习惯二：给三个项目的名字加上身份前缀。——比如"东-教务查询"、"西-教务查询"、"南-教务查询"。——列表是按创建时间排的，前缀让它们挨在一起——而"挨在一起"本身就减少了一半的选错机会。

习惯三：每轮改动完，把三个包的指纹各记一次。——如果三份用的是同一份签名，三个指纹应该一样——不一样就说明有一份用错了签名。——而这个核对只需要看 pack.log，不用任何工具。

这三件事加起来，成本大概是一次性二十分钟，加每轮五分钟。——而它们挡掉的是那种最耗时间的困惑："我明明改了啊，怎么还是老的？"————而这个困惑在多身份项目里出现的频率，是单身份项目的三倍——因为有三份"明明改了"的可能。

台帐用什么记都行——在线表格、本地表格、甚至一张纸贴在机房里。——关键是"只有一份"，而不是"每个校区各记一份"。——而这个"只有一份"的要求，本质上是在保证：当你问"东校区那台装的是哪一版"时，有一个唯一可信的答案。

七、一年之后：加第四个身份要多久

判断一套做法好不好，最好的办法是看它在"计划外"的时候好不好用。而这类项目最常见的计划外事件，是"再来一个"。

假设现在有三个校区，第四个月来了第四个。——如果当初是"三份独立工程"，这时候你要做的是：挑一份当模板、改八处、再考虑"要不要把它前面错过的改动补上"。——而"补上"这件事没人能确定——因为你不知道另外两份这几个月改过什么。

而如果用的是"一份基准加一张表"，加第四个身份就是：拷一份基准目录、对一遍那八行、打一次包、装一台机器。——整个过程半小时，而且你很清楚自己没漏——因为漏没漏是"对照一张表"，不是"回忆"。

这个差别，在数字上更明显。——三份独立工程，加第四个的成本随"离开多久"增长——离开三个月，你得先弄清这三个月改了什么。——一份基准，加第四个的成本是固定的——半小时，与时间无关。——而"成本固定"这件事，对排期的人来说价值很大：你能承诺"下周就能上"。

顺便说一个更微妙的收益：加第四个身份的时候，你会顺手发现前面三个的问题。——因为对那张表的过程，就是一次全量核对——你可能发现某个校区的电话早换了、某个公告还是去年的。——而这个"顺手发现"，在三份独立工程的模式下不会发生——因为你没有那张表可对。

再往远看一点：一年之后，这套东西会长成什么样？——大概是这样：项目列表里有四个项目，名字带身份前缀；归档目录里有四个文件夹，每个里面按日期存着历次打包；一张台帐记着每台设备装的是哪一版。——而这三样东西合起来，就是"这个应用在我们手上的全部状态"。

而如果中间有人接手，这三样东西就是他需要的一切。——他不需要问你"第四个校区当时是怎么加的"——他看一眼那张表和归档目录就明白了。————这也是我在别的文章里反复说的那件事：好的工作方式，会让"交接"变成一次拷贝，而不是一次讲解。

加第四个身份时的那句需求，其实可以写得很短。——"这个是第四个校区，名字叫某某，主色用这个色值，启动页的校名改成这个，客服电话是这个号码，公告先写『欢迎使用』，其它和基准保持一致。"——一句话里包含了六处差异，剩下的两处（图标、服务地址）单独处理——图标要附件，地址要确认。——而这句话之所以能这么写，是因为"基准"已经是一个确定的东西——你在描述差异，不是在描述整个应用。

八、这套做法的边界：什么时候该停

一种方法被讲清楚之后，最容易被误用。所以这一章专门讲"什么时候它不适用"。

信号一：差异项超过十五处。——八处是"能记住并对一遍"的量；十五处之后，对一遍本身成了负担，而且会漏。——这时候真正该做的不是"更仔细地对"，是问一句"这些差异为什么这么多"——往往是因为各身份开始各自演化，那已经不是"一套功能多份身份"，是"多个应用"。

信号二：某个身份开始要"只有它才有"的功能，而且越来越多。——第一个专属功能可以接受（加进去，其它身份不用）；第三个开始，你就会陷入"每加一个功能都要想三遍会不会冲突"。——这时候该做的是把它拆出去——那个身份单独一条线，其它的继续共用。

信号三：身份数量超过五个，而且还在加。——五个以内的拷贝加对表，成本还能接受；十个的时候，你会开始希望"这件事能自动"。——而"自动"意味着回到源头去做——那是另一条路（构建时注入差异），不是改包能解决的。

说清这条分界很重要，因为改包这个方式有它擅长的位置。——它擅长的是"你手上没有源码、或者不方便改源码"的情况——比如接手别人的应用、比如内部应用的原作者已经不在、比如你只想做界面层的调整。——而在这种前提下，它能把"多身份"这件事做得很好——只要身份数量不多、差异稳定。

反过来，如果你手上有源码、而且身份会一直增加，那从源头做多渠道构建才是正解。——改包的优势是"不用碰源码就能改"，而当你本来就拥有源码时，这个优势就消失了。——而这个判断，很多团队会拖到很晚才做——因为改包"还能用"，直到某天突然不能用了。

而这三个信号有一个共同的好处：它们都是"可以提前观察到的"。——你不需要等到出事才判断——你只需要每半年数一下差异项有几行、专属功能有几个、身份有几个。————而数这三个数，比"感觉自己越来越累"要可靠得多。

再补一个"审计"的动作，半年做一次就够：打开基准项目的目录，看一眼那张差异表还是不是八行。——如果多出来几行，问一句"这几处是怎么来的"——往往能发现某个身份悄悄长出了自己的东西。——而发现的越早，把它塞回表里越容易；等到它变成一串功能，就只能拆线了。

九、同一个方法，换三个场景

"一份基准加一张表"这个方法，不只适用于校区。它适用的是"同一套功能、多个身份"这一整类问题。

场景一：多个事业部共用一个内部工具。——差异通常在：部门名、审批流程的入口名称、默认筛选条件、以及"关于"页里的联系人。——而这里有个特别之处：审批相关的措辞必须和各自的实际流程对上——所以那张表里要加一列"术语对照"（同一个东西在 A 部门叫"工单"，在 B 部门叫"任务单"）。——而这一列是被最多人忽略的——因为术语差异不影响功能，只影响"用的人觉不觉得这是给自己做的"。

场景二：给不同客户做的定制版。——这一类最需要谨慎，因为客户版通常涉及"谁能看到什么"。——差异表里除了那八处，还要加"品牌归属"——启动页、关于页、甚至安装后的应用名，都应该明确是客户的品牌。——而更关键的是合规：只做你自己有权修改的应用，客户版尤其要把授权写清——这一条比任何技术细节都重要。

场景三：渠道专供版。——这一类差异最少，通常只有三处：应用名后缀、启动页、某个入口的默认值。——而它的特殊之处是"数量可能多"——三个渠道、五个渠道。——这时候前两条边界就开始起作用了：数量上去了，拷贝加对表的成本会线性增长——而如果渠道还会继续加，就该考虑回到源头。

渠道版还有一处特别容易出错：版本号。——同一个应用装在不同渠道的手机上，如果版本号一路往前推，就会有人拿"版本号更高"的包去覆盖另一个渠道的包——而它们的包名可能相同。——所以渠道版的做法是：包名保持不变（渠道之间本来就不共存），每个渠道的包都从同一份基准工程出，版本号在整个应用层面统一往上走，不要给某个渠道单独"跳号"。——而如果渠道之间必须共存，那就回到第八处：包名加后缀，签名各自固定。

三个场景的差异表，其实可以共用一张骨架。——骨架是那八行；场景决定的是"备注列写什么"。——事业部场景备注里写术语；客户场景备注里写品牌归属和授权；渠道场景备注里写"这个渠道独有的默认值"。——而骨架之所以能共用，是因为这八行覆盖的是"应用的身份"——而身份这件事，到哪儿都是那几样。

最后说一个跨场景都适用的小技巧：把差异表存进基准项目的目录里。——存成一个文本文件，和工程放在一起。——这样"项目和它的差异说明"永远在一起——你拷目录的时候，表跟着走；你交接的时候，表也跟着走。——而如果表存在别处（比如某个在线文档），半年后你很可能忘了它在哪儿——而项目目录你不会忘。

十、五个最常被问到的问题

问一：三个身份能不能共用一个项目？——不能。因为一个项目只有一份配置、一份签名、一份历史——打出来的包是同一个包。——而"共用一个基准工程"是另一回事——那是三个项目，只是它们的工程来自同一次拷贝。

问二：改了基准之后，另外两份怎么"同步"？——我们的做法是"整目录替换"：先把旧的那份改名留着，再把基准目录拷过来，然后把身份字段对一遍。——为什么不"只拷改动的文件"？因为改包这个流程里你不知道改了哪些文件——而目录整体替换是确定的。

而整目录替换之后，至少核对三样：项目名、图标、签名。——这三样在 config.ini 里各有自己的字段，最容易被"刚拷过来那份"带成基准的值。——核对的方式很土：刷新列表看一眼名称和图标，再打一个小包装上，看包名对不对。——三分钟能做完，而漏掉其中任意一样，交付当天就会有人问"这是哪个校区的"。

问三：三份的历史会不会丢？——会——如果整目录替换的话，另外两份的 history.ini 会被基准的覆盖。——所以替换之前，把另外两份的 history.ini 单独留一份（拷到归档目录），需要的时候能查。——而如果你很在意这个，可以改成"只替换工程目录（apktool）和 build"，保留各自的 config 与 history——代价是操作更细，容易漏。

问四：能不能让 AI 一次改完三个？——实际做下来不建议——因为你面对的是三个项目、三次打包、三套验证。——而"一次一句需求"的好处是每一步都能验证；三件事混在一轮里，出问题时你不知道是哪一处带的。

问五：差异表要写多细？——细到"照着它就能把一份改成另一份"。——而判断标准很实际：如果三个月后的你拿到这张表，能不能不看应用就完成一次身份切换？能，就够细了。

十一、一张 A4 的落地清单

最后把整篇文章压成一张清单。如果你明天就要开始做这件事，按这个顺序走。

顺序	要做的事
1	列出八处差异，写第一版表
2	定包名与签名策略（要不要并存）
3	建基准项目，把共同部分改到位
4	拷目录，建出其余身份
5	各打一次包，看签名指纹是否一致
6	各装一台，看名字/启动页/主色/电话
7	各查一次真实数据，确认服务地址
8	把差异表存进基准目录，建归档与台帐

这八步里，第 2 步和第 8 步最容易被跳过，而它们恰好是最"未来向"的两步。————第 2 步决定"以后改起来贵不贵"，第 8 步决定"以后还认不认得"。而中间六步，都是当天就能看到结果的。————人总是愿意做"当天能看到结果"的事，所以这两步需要刻意提醒自己。

十二、用过的人怎么说

五条里，四条讲的是"合"，一条讲的是"该分了"。————而这两件事其实是同一套判断的两面：差异少就合，差异多就分。————而判断依据不是感觉，是那张表有几行、有几个专属功能、有几个身份。

还有一条提到"装错了才发现"，这一条特别值得记住。————多身份项目里，最贵的错误不是"改错了一个字"，是"把正确的包装到了错误的地方"——因为它不会报错，只会安静地跑在错的后台上。————而防它的办法很土：装完真查一次数据。

这几条反馈合起来，其实就是一句话：多身份项目的功夫，八成在"改之前"和"改之后"，只有两成在"改"。————而那两成，恰好是工具最擅长的部分——所以你花钱买工具，买的其实是"可以少花点力气在那两成上"，然后把力气放到另外八成。

---

只需说话，就能让应用变成你想要的样子。——而"变成三个校区各自的样子"，也只需要把同一句话说三遍——这就是安卓修改大师智改工坊在多身份场景里省下的那部分力气。