一年后再看同一个包：六个当时觉得无所谓的小决定

改包这件事，最难的判断不是"这个能不能改"，而是"这个无所谓吧"。

包名顺手改一下、版本号懒得升、文件名随手写成"最终版"、签名换了没提前说、需求原话聊完就关了窗口、那处改动为什么这么改没留一句备注——这六件事，在交付的那一分钟里，每一件都长得像"省事"。

而它们的代价，全都不在当天结算。——当天你关心的是"装上去能不能用"，这个标准很窄，窄到上面六件事一件都不影响它。——于是你把包发出去，觉得这一单很顺。

账单在更晚的时候寄到。——可能在第七天（他要给第二台机器装）、可能在第三十天（他要加一个小功能）、可能在第九十天（他自己都忘了当时怎么说的）、可能在一年后（接手的人打开目录，看见四个叫"最终版"的文件）。——而收件人，是未来的你，或者一个完全不知道前情的人。

这篇的做法有点特别：不站在"交付当天"往回看，而是把同一个包放到一年后往前看。——假设这个包一年之内还要再动三次、换一次签名、加两个页面、装到一批新机器上——那今天这六个"无所谓"，各自会在什么时候、以什么形式回来找你。

只需说话，就能让应用变成你想要的样子。而这句话要成立，有一个容易被忽略的前提：你说的那句话，得留得住。——如果一年后那句话已经找不到了，那"说一次就行"就退化成了"每次都得重说"。

一、为什么"一年后"这个视角，比"交付当天"更有用

先说清这个视角为什么值得单独拿出来讲。因为改包这个活有两套完全不同的验收标准，而人几乎只用第一套。

第一套标准叫"能不能用"。——装上去、打开、点几下，那处改动在，就过了。——这套标准的特点是：它是终局判断，一旦通过就不会再被推翻，所以它给人的反馈特别干脆。——而人会被干脆的反馈驯化：下次还是按这套标准做判断。

第二套标准叫"能不能再改"。——这个包三个月后要加东西，能不能接上？半年后要换一台机器装，装不装得进去？一年后要交给别人维护，他看不看得懂？——这套标准的特点是：它永远在被推迟，所以它永远不给你反馈。——而"没有反馈"的事情，人不会主动去做。

两套标准的成本也不对称。——第一套标准要花的力气，几乎全在"改"这件事上；第二套标准要花的力气，是交付之后那三分钟的整理。——三分钟对半天，比例悬殊到让人觉得"不做也没关系"。——但代价的方向是反的：省下三分钟，可能在三个月后变成三小时；省下三次，可能在某一天变成"这个包我不敢动了"。

还有一个更隐蔽的差别：第一套标准的收益归你，第二套标准的收益归"未来的某个人"——而那个人经常不是别人，是记不清细节的你自己。——人对"给未来的自己省事"这件事，天生缺乏动力，因为未来的自己在感觉上像个陌生人。——所以要真正把这件事做起来，不能靠意志力，得靠"默认行为"——这也是后面第十一节要讲的：让工具替你留，而不是靠你记得留。

接下来的六节，一件事一节。每节讲三样：这件事在交付当天看起来多无害、它在什么时候回来、以及回来的时候具体是什么样子。——不用记，看完之后你只要记住一句：这六件事里，只有第一件是真的需要判断，其余五件都是顺手就能做对的。

二、第一个决定：包名"顺手改一下"

包名（applicationId）是这六件事里唯一一件"改错了会有真实损失"的，所以放在最前面。

为什么有人会顺手改它？理由通常很朴素：——"这个名字是别人的，我改成自己的心里舒服"；"两个应用名字太像，改了区分得开"；"客户说要换个名字"。——前两个理由是自己想出来的，第三个理由往往是真的需求被听错了一半——客户说的"换个名字"，九成指的是图标下面显示的那个应用名，不是包名。

包名一改，系统就认为这是另一个应用。——后果是三条，一条比一条难收拾。

第一条：桌面会出现两个图标。——原来的还在，新的也在，两个都能打开，但里面的数据是两套。——交付当天客户可能会觉得"哦，那就删掉旧的"——而这一删，就是把旧应用的数据一起删了。

第二条：新包装不上旧数据。——Android 给每个应用划一块私有目录，路径是按包名分的。——包名变了，那块目录就换了；旧目录里的登录状态、草稿、离线缓存、本地数据库，新应用一律看不见。——于是"改了个界面"这件事，在用户那里变成了"要重新登录、之前存的东西没了"。

第三条，也是最贵的一条：一年后没人记得为什么要改。——一年之后要推新版本，你把包名改回去（或者别人改成第三个名字），于是同一个应用在历史上一共有三个身份。——装过旧版的机器升不上去、渠道统计对不上、客户说"我手机上怎么有两个"、备份文件不知道对应哪一版。——而这些问题的根，是当初一个"心里舒服"。

所以这一件事的判断标准很干脆：除非有明确理由，包名不动。——"应用名"和"包名"是两件事：前者是给用户看的，在资源里改一行字就能变；后者是给系统认的，改了就是另一个应用。——客户说"改个名字"，先问一句"是图标下面那行字，还是安装包里那个标识"——这一句话能省掉后面三条后果里的两条。

如果确实非改不可（比如要做成一个独立分发的新应用），那唯一正确的做法是"当新应用做"：新的名字、新的签名策略、明确告知用户这是一个需要重新安装、且不会继承旧数据的版本。——把这句话写进交付说明里，比事后解释十遍都管用。

三、第二个决定：版本号"反正只有一个版本，不升也行"

这一件比包名更常见，也更没有存在感——因为改错了，当天真的一点都看不出来。

Android 的版本信息有两个字段，很多人只记得其中一个。——versionCode 是一个整数，只给系统看，系统拿它判断"这个包比装着的那个新还是旧"；versionName 是一个字符串，给人看，桌面上、设置里显示的就是它。——覆盖安装的规则是：包名相同、签名相同、versionCode 不小于已装的那个。——三个条件缺一条，安装器就会拦下来。

所以"不升 versionCode"的后果，通常不在第一台机器上出现，而在第二台机器上出现。——第一台机器是干净的，装什么都没问题；第二台机器上已经装着上一版，你发过去的包 versionCode 和它一样，安装器会给出一个含糊的提示，翻译成中文大概是"应用未安装"。——客户看到这四个字，第一反应是"你这个包装不上"，而不是"我该先卸载"。

而"该先卸载"这个补救动作，是有代价的。——卸载会清掉这个应用的私有数据。——所以为了装上一个只改了按钮颜色的版本，用户丢掉了登录状态和本地草稿。——你很难跟他解释清楚：这不是你的包坏了，是版本号没升。

还有一个更远的后果：一年后你说不清"最新版是哪一版"。——如果每次改完版本号都是同一个数字，那你的交付历史就没有坐标了。——客户打电话说"我这台机器上的版本有问题"，你问他版本号，他念出来一个数字，而这个数字对应着你三个月里发过的七个包。——于是排查变成了猜。

正确做法其实只有一句：每次交付都升 versionCode，顺手把 versionName 也往上走一位。——versionCode 严格递增（1、2、3……或者干脆用日期编码，比如 2026011501），versionName 用"人能读"的格式（1.4.2）。——两个都动，成本是改两个字符，收益是"任何一个包都能被唯一指认"。

还有一个细节值得顺手做：把版本号写进文件名。——后面第四节会讲文件命名，但这里先说一句：版本号出现在文件名里的时候，"他手机上是哪个版本"这个问题，就从"要打开应用看"变成了"看一眼文件列表"。——而排查问题最贵的成本，永远是"信息在谁的机器上、要怎么取到"。

四、第三个决定：文件名写成"最终版"

这一件是六件里最"不像问题"的，因为它在当天完全不制造问题——它制造的是三个月后的考古现场。

先描述一个几乎人人都见过的目录：——最终版.apk、最终版2.apk、最终版-真的.apk、最终版-改签.apk、最终版-客户确认.apk、新建文件夹(2) 里的 最终版.apk。——六个文件，同一个应用，六种状态。——而它们之中，只有一个是"客户手机上装着的那个"。

这套命名的问题不在于"乱"，在于它把三个关键信息全部丢掉了：什么时候做的、哪个版本、有没有签名。——而这三样恰好是重新接手时必须先知道的。

这里有一个技术上很容易被忽略的点：放在目录里的三个产物，长得几乎一样，但只有一个能装。——打包链路走完会得到 unsigned.apk（未签名，装不上）、aligned.apk（只做了对齐，仍未签名，装不上）、signed.apk（签过名，能装）。——如果文件名不带任何标识，三个月后你面对三个大小相近的 apk，只能靠"试装一下"来分辨。——而"试装一下"这件事，在别人的机器上做，是有风险的。

一个够用一辈子的命名格式：应用名-版本号-日期-状态.apk。——比如 巡检打卡-1.4.2-20260115-signed.apk。——这个格式的价值在于：它能被排序（日期在前面或后面都行）、能被搜索（应用名）、能被指认（版本号）、能一眼看出能不能装（signed）。——四个信息位，写的时候多花五秒，找的时候省下的可能是半小时。

再进一步，文件名和"交付记录"要能对上。——你发给客户的那个文件名，最好一字不差地出现在你的项目目录里、和这次的需求原话放在一起。——因为一年后最常发生的对话是："上次那个包你还留着吗？"——而你能不能在三秒内回答，取决于文件名有没有信息。

顺便说一句"最终版"这个词为什么危险：它描述的是"关系"，不是"内容"。——"最终"意味着"这一版之后不再改了"，而这个判断在改包这个活里几乎从来不成立——需求会变、机型会变、系统会升级。——所以叫"最终版"的文件，通常会在两周内出现"最终版2"，而"最终版"三个字从此变成了噪音。

五、第四个决定：签名换了，"反正能装上就行"

这一件是六件里唯一一件"当天就可能出问题"的，但它最容易在事后变成事故——因为它的后果不是"装不上"，而是"装不上之后必须卸载，卸载会清数据"。

先解释签名到底做了什么。——签名不是加密，也不是"上锁"，它是在包上贴一张身份证：这张身份证说明"这个包是由持有这把私钥的人发布的"。——系统在覆盖安装时会做一件事：拿新包的签名跟已装应用的签名比一比，不一样就拒绝。——这条规则的目的是防止别人做一个同包名的包来顶掉你的应用、从而读到你的数据。

所以"换签名"在这套规则下的后果是确定的：——同包名、不同签名 → 覆盖安装被拒 → 只能先卸载旧版 → 卸载会清掉这个应用的私有数据 → 装上新版之后，用户面对的是一个全新的、空的、需要重新登录的应用。——四个箭头，每一个都是必然，没有例外。

为什么有人会换签名？——常见的有三种：上一次用的签名文件找不着了；这次是另一台电脑上做的，那台机器上没有配置；客户说"要用我们公司的签名"。——三种理由里，前两种是"管理问题"，第三种是"真需求"——而真需求是必须做的，问题只出在"没说"。

"没说"这两个字的代价，具体长这样：——客户在车间里，拿着手机，装不上，打电话给你；你在电话里说"要先卸载旧的"；他问"卸载了里面的数据还在吗"；你顿了一下；他听懂了那一下停顿。——然后他要决定：是现在丢掉这批没上传的记录，还是等这批活干完再说。————而这个决定本来不该由他在车间里临时做。

所以这件事的正确做法不是"避免换签名"，而是"换了要说，并且提前说"。——提前说的内容有四句，缺一句都不算说清：这次换了签名、装之前要先卸载、卸载会清掉应用里的数据、请在方便的时候再做这件事（比如这批活刚提交完）。——四句话，六十个字，能把一场事故变成一次安排。

还有一件更省事的做法：把签名文件当成项目资产，跟着项目走。——签名文件 + 别名 + 密码，三样东西放在项目目录里、跟这个应用绑定，而不是放在"某个电脑的某个文件夹"里。——因为签名一旦丢了，这个应用以后所有的版本都只能换签名，也就是每一次升级都要重装、每一次重装都要清数据——一次丢失，永久生效。

验签这件事本身是可以当场确认的，别靠猜。——签名之后跑一次 verify，让它把证书信息打出来：能打出来，说明签上了；打不出来，说明前面某一步没走完。——更稳的做法是对比：把这次打出来的证书信息和上次交付的比一比，一致就说明签名没变、可以放心覆盖安装；不一致就说明这是"需要提前通知"的那一次。——这个对比花不到一分钟，而它能提前发现的问题，代价是以"丢数据"计的。

六、第五个决定：需求原话，聊完就关了窗口

前面四件都跟"包"有关，这一件跟"话"有关。而它在一年后回来找你的时候，形式往往是一场争论。

争论长这样：——"这里不是说好了要改吗？"——"没有啊，当时说的是那个。"——"我记得是这里。"——"我当时理解的是那个意思。"——然后两边都没法证明，因为那段对话在微信里、在电话里、在一次当面沟通里，而当时谁也没想到要留。

这类争论有一个特点：它跟谁对谁错关系不大，跟"谁手上有东西"关系极大。——有原话的一方不需要提高音量，只要把那段话念出来；没有的一方，即使记忆是准的，也只能反复说"我记得"。——而"我记得"在商业沟通里的说服力，接近于零。

更常见的情况是：根本没有争论，只有沉默的返工。——客户看到成品，说"哦，我要的不是这个"，你心里觉得他要的就是这个，但你没法确认，于是你改了。——这次返工不收费、不记录、也不产生任何结论——于是下一次还会发生。——一年下来，这些无声的返工加起来，可能比正式交付的工作量还多。

留原话的成本低得不像话：把那句话复制下来，贴进这个项目里。——不需要整理成需求文档、不需要分点、不需要格式——就是原话，连错别字一起留着。——因为原话的价值不在"准确"，在"无法被重新解释"。——整理过的需求会被理解成另一个意思，原话不会。

这里有个很实用的判断标准：什么样的句子值得留？——凡是带"改成""换成""不要""加上""挪到"这几个词的句子，都值得留。——因为它们描述的是"变化"，而变化正是日后最容易扯不清的东西。——反过来，"你看着办""差不多就行""你专业你定"这类话，也值得留——不是用来对付客户，是用来自查：这种话一旦出现，说明这次的需求本身没定，你应该在动手前多问一句。

一年后原话的第二个用途，是让你自己看懂自己。——你打开一个三个月没碰的项目，看见目录里躺着一句话："把首页那个红点去掉，客户说太吵。"——一句话，你立刻想起当时的场景、为什么这么改、以及为什么没顺便改别的。——而如果这句话不在，你要么重新问客户，要么凭猜去动一个已经稳定的包——两种选择的成本，都远高于当初复制那一行字。

七、第六个决定：没写一句"这里为什么这么改"

这一件最容易被当成"多余的讲究"，因为它的读者不是客户，是三个月后的你自己——而三个月后的你，在今天的你眼里并不存在。

改包这个活有一个特殊之处：你改的不是全新的代码，是一份别人写的、你看不到源码全貌的东西。——所以你每一次改动的旁边，都站着一圈"本来就在那儿"的东西：一段看着很怪但可能是故意的逻辑、一个多余的判断、一行写法过时的代码。——你当时知道哪些能碰、哪些不能碰——而这个"知道"，没有写在任何地方。

三个月后的场景非常具体：——客户要加一个功能，你打开这个项目，看见自己上次改过的地方——现在看起来有点别扭。——你开始想：这行是原来就有的还是我加的？这个判断是故意留的还是漏了？当时为什么不顺便把它改成更顺的写法？——三个问题，每一个的答案都只能靠"再想一遍"——而"再想一遍"的结果，经常是"算了别动它"。

于是这个包开始变得"不敢动"。——不敢动的东西会越来越多，直到某一天你判断"这个包重做一遍比在这个上面改更省时间"。——而重做，意味着前面所有的历史都清零——包括你已经验证过的那些"这里不能碰"。

一句备注能拦住这条滑坡，而且它只需要写一个信息：为什么。——不是"改了什么"（那个文件本身就是证据），是"为什么这么改"和"为什么不那么改"。——比如："这里没动字号，因为容器是固定高度的，加大就会截断。"——一句话，省掉未来半小时的推理，也省掉一次"改完发现截断又改回来"的往返。

备注写在哪里，比写得多好更重要。——写在聊天记录里等于没写（找不到），写在脑子里等于没写（会忘），写在跟这个项目无关的笔记本里也等于没写（不会去看）。——唯一有效的位置是：跟这个项目在一起、打开项目就能看见的地方。——一句也行，十句也行，关键是"在同一个地方"。

这一节还有一个额外的好处，值得单独说：写给自己的备注，同时也是给客户的交付说明的素材。——你攒下的"为什么不那么改"，稍微翻译一下就是"这次没动哪些、为什么"——而这句话是交付时最能让客户安心的部分。——因为它证明你看见了他没说的东西。

八、六个决定的共同点：代价都延迟结算

六件事讲完了。把它们摆在一起看，会发现一个很整齐的规律。

六件事里，五件的当天收益都是"省下几分钟"，六件的代价都在更晚的时候出现。——而"当期收益 + 远期代价"这个组合，是所有坏习惯里最难改的一种。——因为它在你的经验里，永远是"这么做也没出事"。

这就是"延迟结算"的可怕之处：它不让因果连在一起。——包名改了，一年后才装不上——那时候你早忘了是当初那个决定；版本号没升，三十天后客户说装不上——那时候你会以为是别的原因；文件名乱，三个月后找不到——那时候你只觉得"我这人怎么这么乱"，而不是"当初该花五秒命名"。——因果被时间拉开之后，人学不到教训，只会积累一种模糊的自我评价。

所以这六件事不该靠"记住"来解决，该靠"判断标准"来解决。——一个能替代记忆的标准是：如果这个决定，一年后要由一个完全不知道前情的人来承担后果，我还会这么选吗？——这个问题不需要技术判断，只需要想象一下那个人的处境——而想象的成本，比记住六条规则低得多。

还有一个更实用的看法：这六件事里，只有第一件（包名）真的需要判断。——其余五件——升版本号、规范命名、提前说签名、留原话、写一句备注——全都不需要判断，只需要"顺手"。——而"顺手"这件事能不能发生，取决于它是不是被安排在正确的时机。——时机不是"想起来的时候"，是"交付的那一分钟"——那时文件还在、话还记得、改动还热着。

反过来看，这六件事也是六面镜子：它们照出来的不是技术水平，是一个人做这行的"可持续性"。——同样改一百个包，有人一年后还能回头改第一个，有人到第三十个就已经在重做了。——差别不在手速，在交付之后那几分钟里做了什么。

九、把六个决定放进一条时间线

下面这条时间线，是一个包在一年里的典型遭遇。左边是"什么时候"，中间是"发生了什么"，右边是"当初哪个决定在这里回来"。

这张表最值得看的是第一行和最后一行。——D0 那一行写着"六件都不出现"，这就是全部问题的根源：证明"该留东西"的最强证据，恰好是最不容易被看见的那个时刻。——而 D+365 那一行说明：六件事不会分别来找你，它们会在你最没有余力的时候一起来。

十、两个自家应用：同一个动作，两种一年后的下场

下面两个实例都来自我们自己有权修改的项目，前后差了一个"当初有没有随手留"。

实例一：巡检打卡应用，一年后要加一个新车间。

以前怎么做：——这类需求我们最早是"打开旧包、翻代码、猜上一版怎么实现的"。——巡检类的界面通常长得像：一排车间、一排检查项、一排拍照按钮。——加一个车间，理论上就是多一条数据、多一个入口——但真正卡住的地方往往不是"加"，是"上一版的车间列表是写死在布局里，还是从配置里读的"。——这两种实现，改法完全不同；而在没有备注的情况下，你只能靠读代码判断——读错了，就会出现"界面上多了一个车间，点进去是空的"。——第一次做这个需求，我们花了一个下午，其中至少两个小时在确认这件事。

现在一句话怎么做：——现在这个项目在列表里，点开就是它自己的目录：上一轮的需求原话在历史里（"车间从三个加到四个，第四个叫装配二车间"），一句话备注写着"车间列表从配置文件读，加车间只改配置，不动布局"。——于是新需求进来，我们要做的第一件事不是读代码，是读那句备注；然后一句话描述："再加一个车间，叫包装车间，排在装配二车间后面。"——改的是配置，不是布局——这个判断在三十秒内就完成了。

改完怎么验证：——三步，五分钟。——第一步，进车间列表，数一遍是不是五个，顺序对不对；第二步，点进新增的那个，看检查项是不是和别的车间一样（这一步最容易暴露"只加了入口没加数据"）；第三步，随便提交一条记录，退出去再进来，看它还在不在——在，说明写进去了，不是只画在界面上。——三步都不需要看代码，只需要点。

这个实例的关键不在"用了什么工具"，在于那两句留档：一句原话、一句备注。——它们加起来不到一百个字，把"两小时的确认"变成了"三十秒的判断"。——而它们是在一年前交付的那一分钟里顺手留下的。

实例二：设备预约应用，当年包名顺手改过。

以前怎么做：——这个应用最早是别人做的，名字里带原厂标识，我们第一次接手时觉得"改成自己的更干净"，就把包名动了。——当时验证很顺：干净机器上装上去，一切正常；客户看着新图标，说挺好。——那一次的交付说明里，我们没写包名改了。

一年后发生的事：——客户要把这个应用推给一批新机器，同时希望老机器上的预约记录能一起带过去。——问题在这里炸开：老机器上是旧包名的应用，新包名是另一个应用——两个应用可以并存，但数据不互通。——要把记录带过去，只能导出再导入；而老版本没有导出功能。——最后的处理方式是：老机器上的记录手工整理了一遍，新机器重新建。——那批记录不多，所以还能收拾——如果是一年的量，这件事就没法收场了。

现在一句话怎么做：——现在这类"要不要动包名"的判断，我们不自己做，改成一句话问客户："图标下面那行字要改，还是安装包里的标识也要改？"——九成的情况下，客户要的是前者——那就改资源里的一行字，包名不动，一年后什么都不用担心。——如果客户真的要后者，那这件事就不是"改包"，是"新做一个应用"，交付说明里必须写清"不与旧版共享数据"。

改完怎么验证：——两件事。——第一件，在一台装着旧版的机器上直接装新版，看它是不是覆盖成功、打开之后数据还在——在，说明包名和签名都没变；——第二件，在设置里看应用信息，确认应用名变了、包名没变。——这两步验证花两分钟，能拦住一年后的一次手工重建。

十一、别靠"记得留"，靠"默认就留"

讲到这里有一个现实问题：这六件事都对，但没有人在交付那天有心情做六件"未来的事"。

所以真正有效的做法，不是提高自觉性，是减少"需要自觉"的环节。——判断标准很简单：一件事如果需要"想起来才做"，它迟早不会做；如果它"本来就会发生"，那它就能持续。——而工具能做的，恰好是把"留东西"从"动作"变成"副作用"。

第一层默认：项目本身就是一个目录。——每个改过的包，在列表里有一个位置，点开就是它自己的文件夹——里面放着它的原包、它的产物、它的配置。——这一层拦住的是第四个决定（文件名乱）：因为你不需要"找地方存"，它本来就有地方；你也不需要"记住哪个是它的"，因为它跟它在一起。

第二层默认：每一轮说的话自动留在历史里。——你描述需求的那句话，不用另存——它变成这个项目的一条历史记录。——这一层拦住的是第五个决定（原话没留）：因为"复制粘贴"这个动作被省掉了，而省掉动作的东西才会被使用。——顺带一个好处：历史按条存在一个文件里，删掉一节就等于删掉一条——清理起来也是"看得见"的，不是一堆散落的文件。

第三层默认：配置跟着项目走，而不是跟着电脑走。——这里有一个分层的设计值得说清，因为它直接对上前面的签名问题：偏好类的设置跟着人走（换机器也能用），认机器的设置留在本机（比如工具链路径），而项目相关的配置——包括签名——跟着项目走。——三样东西分开存，带来的结果是：你换一台电脑打开这个项目，签名还在，不用重新找。——这一层拦住的是第四个决定里最贵的那部分：签名丢失。

第四层，也是最容易被低估的一层：改动过程有日志。——打包的时候，每一步做了什么、成没成、卡在哪一步，会被写进日志文件。——一年后要复盘"这个包当时是怎么打出来的"，翻日志比翻记忆快得多。——而日志这种东西的价值，全在"出事的时候"——它平时看起来完全没用。

四层默认叠起来，你会发现那六件事里已经有一半不需要"记得"了。——剩下的两件——升版本号、写一句备注——是唯一还需要你伸一下手的。——而这两件恰好也是收益最直接的两件：前者让"他装不上"这个电话不打来，后者让三个月后的你少一次试探。

十二、交付那一分钟，真正值得做的四件事

如果这篇只留一段，留这段。下面四件事，加起来三分钟，全都发生在"包已经发出去、但还没关电脑"的那一分钟里。

第一件：给文件换个名字。——应用名-版本号-日期-signed.apk，四个信息位凑齐就算合格。——不要叫"最终版"，不要叫"客户确认版"——那类名字描述的是当时的情绪，不是包的内容。——而名字是唯一一个"一年后还在原处、且不需要打开就能读"的信息。

第二件：写四句交付说明。——改了哪几处（一行一处，别合并）、没改哪些（尤其是"看起来该改但故意没改"的）、怎么装（要不要先卸载、要不要覆盖）、出问题找谁。——四句话，客户会把它当成"这个人的专业度"，而实际上它是你给自己留的备忘录。

第三件：确认原话在。——翻一眼这个项目的历史，看这一轮的需求原话在不在。——不在就补一条——补的时候不要"整理"，把当时的话照抄。——原话里那些口语、省略、错别字，恰好是日后判断"他当时到底什么意思"的唯一线索。

第四件：写一行"注意"。——就一行，写这一轮最容易被下一个人搞错的那一件事。——"这处没改字号是因为容器固定高度"、"这个按钮的位置是按客户要求留的，不是漏了"、"这版没动包名"。——一行字的成本，是三个月后半小时的试探。

四件事有一个共同的敌人：那个"先关了明天再说"的念头。——因为明天这三分钟会变成三十分钟：文件要重新找、原话要重新翻聊天记录、备注已经想不起为什么。——所以这四件事的正确执行时机，不是"有空的时候"，是"还没关电脑的时候"。

还有一个更省力的版本：把这四件事写在交付消息的模板里。——每次发交付消息，照着模板填——填的过程本身就是提醒。——模板不需要多好，能稳定执行才有价值；一个粗糙但每次都用的小模板，胜过一套精致但只用过一次的规范。

十三、五个经常被问到的具体问题

问一：只改一个颜色，也要升版本号吗？

要。——判断要不要升版本号的标准，不是"改得多不多"，是"要不要覆盖已装的那一个"。——只要客户机器上已经装着旧版，你发过去的新包就得让系统认出"这是新版"——而系统只认 versionCode，不看改了几个像素。——改颜色升版本号，听起来郑重得可笑；但一次"应用未安装"的电话，比这个可笑多了。

问二：包名到底能不能改？

能改，但改完它就是一个新应用，不再是"这个应用的新版本"。——这句话听起来像文字游戏，实际后果非常硬：两个应用可以并存、数据不互通、旧的那个卸载会清数据。——所以正确的问题不是"能不能改"，是"要不要把它当新应用处理"——要，就走新应用那一套（新签名策略、明确不继承数据、交付说明写清）；不要，就别动。

问三：签名文件丢了怎么办？

丢掉的那一刻，唯一的出路就是换一个新签名，而换签名意味着所有已装机器都要卸载重装、并且会清数据。——所以这个问题的正确答案在事前：把签名文件当成这个项目的一部分，跟项目放在一起，而不是放在"某台电脑的某个文件夹"里。——顺带一个习惯：每次签名之后看一眼证书信息，把它和上一次对比——一致，说明用的还是那把；不一致，就要按"换签名"来通知。

问四：客户说"随便，你定"，这种需求怎么留？

把它原样留下来，然后补一句你自己的决定。——"随便"这三个字的价值，是日后证明"这一处是我按判断做的，不是漏了"；而你补的那一句（比如"我按最保守的方式做了，只调了间距"），是日后自己看得懂的坐标。——两句话叠在一起，才是一份完整的记录：他的授权 + 你的选择。

问五：一年后真要接手别人的包，最先看什么？

四样，按顺序。——先看包名和签名（决定能不能覆盖安装、会不会清数据）；再看版本号（决定能不能升级）；再看上一轮的原话和备注（决定改动意图）；最后看有没有日志能对上"这个包是怎么打出来的"。——四样里，前两样在设置里就能看到，后两样要看有没有人留。————而"有没有人留"，就是这篇从头讲到尾的那件事。

十四、一年后的三个时刻，今天就能提前买好

最后把这件事收在三个具体时刻上。它们一定会来，区别只在于那时候你手上有没有东西。

第一个时刻：他说"还是上次那个，再改一点"。——这时候你需要的只有一样：这个项目的目录还在、上一轮的原话还在。——有，这一单的沟通成本接近于零；没有，你要么让他重说一遍，要么凭记忆开始猜——而这两件事，都在消耗他对你的耐心。

第二个时刻：他说"装不上"。——这时候你需要的是一分钟内能说清"为什么"和"怎么办"：是版本号没升、是签名换了、还是包名变了。——三种原因，三种处理方式，第一种最轻（升个号重发），第三种最重（要卸载，会清数据）。——而你能不能在电话里一分钟说清，取决于你交付时有没有写那四句话。

第三个时刻：有人问"这个应用是怎么来的"。——问的人可能是客户的新负责人、可能是接手的技术、也可能是半年后的你自己。——这时候你需要的不是技术能力，是一份能读懂的历史：改过哪几轮、每轮为了什么、有哪些地方刻意没动。——而这份历史，是每一轮那三分钟攒出来的，事后补不出来。

三个时刻有一个共同点：它们考的不是"你会不会改包"，是"你留下过什么"。——而后者这件事最不公平的地方在于：它的收益全部归未来，成本全部落在现在——于是它永远排在"等有空再说"的队列里。——所以这篇真正想说的不是"要留档"，是"把留档塞进交付那一分钟"——因为那一分钟是唯一一个成本最低的窗口。

换个角度说，改包这活的护城河，从来不是"会改"，是"改过的还能再改"。——会用工具的人越来越多，一句话就能改一个应用这件事也不再稀奇；真正拉开差距的，是第一百个包和第一个包之间的关系——它们是不是还在同一个体系里，是不是还能互相解释。——能，你就在积累；不能，你只是重复劳动了第一百次。

十五、用过的人怎么说

只需说话，就能让应用变成你想要的样子。而让这句话在一年后依然成立的，不是更聪明的模型，是那些被顺手留下来的东西：一句原话、一个规范的包名、一行备注。

安卓修改大师智改工坊的产品页在 https://www.apkeditor.cn/ai-version.aspx，官网是 www.apkeditor.cn。它做的恰好是这篇里最难靠自觉完成的部分：每个包有自己的项目目录、每轮的需求原话自动进历史、项目配置和签名跟着项目走、打包过程写日志。——你只需要记得升一次版本号、写一行备注，其余的都已经是默认行为。

---