一门课一个安装包：内容型多版本，和身份型有什么不一样

先描述一个很具体的处境：你手上有一个自己做的课程学习应用，功能是看视频、看讲义、做练习。——而它现在要给十几门课用——每门课的名字不一样、封面不一样、章节目录不一样、讲课老师不一样，报名入口指向的客服也不一样。——于是你做了十几份安装包，学员报名哪门课，你就发哪个包给他。

这种"一门课一个包"的做法，和上一批文章里讲的"多校区、多门店"看起来是一回事，其实是两回事。——多校区那种，变的是"身份"——名字、颜色、电话，八处左右，长期稳定，一年改几次。——而一门课一个包，变的是"内容"——课程名、封面、目录、老师，它们跟着课程走，而课程是有生命周期的：开课、结课、下一期。

这个差别听起来很学术，而它带来的是完全不同的两个麻烦。——身份型多版本的麻烦是"怕改漏"——三份工程改三遍，漏一处就有人发现不了。——内容型多版本的麻烦是"怕改错"——十几个包长得几乎一样，你把 A 课的封面打进了 B 课的包，装上去能跑、能看视频，只是第一屏是错的课。

「安卓修改大师智改工坊」在这件事上能帮的，还是那句：把"这一版要什么样"说成一段话，它去改、它去打包。——而"内容型多版本"真正的功夫，在于你怎么组织这些包、怎么命名、怎么验证——这部分工具替不了你。

只需说话，就能让应用变成你想要的样子。而"一门课一个包"这个场景里，这句话的正确读法是：把"这门课要什么样"说清楚，而不是把"这门课的内容"说进去——内容该留在数据里，包里只放"这门课长什么样"。想先看看建项目和打包长什么样，可以从 https://www.apkeditor.cn/ai-version.aspx 下载「安卓修改大师智改工坊」，拿一个自己的应用走一遍——走完之后你会更清楚哪些东西适合放进包里，哪些不适合。

一、身份型差异和内容型差异，差别到底在哪

把两类差异放在一起看，差别会非常清楚。——身份型差异是"这个应用是谁的"——它回答的是归属问题，所以它的数量由"有多少个使用方"决定，增长很慢。——内容型差异是"这个应用讲什么"——它回答的是内容问题，所以它的数量由"有多少门课、多少期"决定，增长可以很快。

对比项	身份型（多校区、多门店）	内容型（一门课一个包）
数量由什么决定	有多少个使用方	有多少门课、多少期
变化频率	低，一年几次	高，每开一期就动一次
最怕的错误	改漏了一处	把 A 课的东西打进 B 课的包
错误的暴露方式	有人反馈"我们这儿没变"	当场就能看出来，但常在发出去之后
最该做的事	一份基准工程加一张差异表	一套命名规则加一次装前核对

这张表最重要的一行是"最怕的错误"。——身份型怕的是"漏"，因为漏掉的那一处通常不影响使用，只是"这个校区觉得这不是给自己做的"——它不会报错，只会慢慢积累不满。——内容型怕的是"错"，因为错的那一处会直接影响学员看到的第一屏——而学员不会给你第二次机会去解释"这个封面只是搞错了"。

第二重要的一行是"变化频率"。——身份型一年改几次，所以"慢一点、仔细一点"是可行的策略。——而内容型每开一期就要动一次——十几门课、每门课一年两期，那就是一年二三十次打包——而二三十次里只要有一次张冠李戴，你的学员群里就会出现一条"老师，我打开是我没报的课"。

还有一个更隐蔽的差别：身份型差异是"平级的"，内容型差异是有层级的。——三个校区之间没有从属关系，A 校区的改动和 B 校区无关。——而一门课有"课程"和"班期"两层——"数据分析基础"这门课的封面，第三期和第四期是一样的；而"第三期"的目录，可能比第四期少两章。——于是你要决定：包是按课程出，还是按班期出？

这个决定没有标准答案，但有一个判断方法：看学员怎么拿到包。——如果学员是"报了这门课就装这个包、一直用到结课"，那按课程出就够了——包里的目录和课程大纲对得上就行。——如果学员是"每一期都重新发一次包"，那按班期出更合适——因为每一期的目录、老师、甚至练习都不一样。

而"按班期出"会带来一个后果：包的数量翻倍。——十门课、一年两期，就是二十个包；如果还有"周末班""企业内训班"，那就三十个。——三十个包放在一个文件夹里，靠肉眼分辨是不现实的——所以到这个数量，命名规则就不是"讲究"，是"必需品"。

写到这里可以给一句话的结论：身份型多版本，靠"一张表"管住；内容型多版本，靠"一套命名"管住。——前者的核心资产是差异清单，后者的核心资产是文件名的规则。——而这两样东西，都不需要写代码——它们需要的是"在动手之前想清楚"。

二、一门课的包里，真正会变的七处

把"给这门课做个包"拆开，会落到七处具体的改动。——而这七处和"多校区"那八处有重叠，也有两处是内容型独有的。——分清楚哪些是重叠的、哪些是独有的，你就知道哪些经验可以搬、哪些必须重新想。

一是应用名，也就是课程名。——这是最容易出问题的一处，因为课程名通常比"应用名"长得多——"数据分析基础 · 第四期"这样的名字，在桌面上一定被截断。——而截断之后，学员看到的是"数据分析基…"——不同课程的名字前几个字又常常一样（"数据分析基础"和"数据分析进阶"），于是桌面上一排图标，谁也分不清哪个是哪个。

这一处有个很实用的解法：把区分信息放到前面。——"基础 · 数据分析"比"数据分析基础"更容易分辨，因为前两个字就不一样。——如果课程是分期的，那一期二期可以和课程名拆开——桌面名只放课程，期数放在启动页和首页里。——因为桌面上那十几个像素，装不下"完整"，只能装下"能区分"。

二是图标。——课程通常有一张方形的封面或者主图，很多人直接拿它当图标。——而这里有两个坑：一是图里往往有字，缩到桌面尺寸之后字就糊成一片；二是课程封面常常是竖版海报裁出来的，裁成方形之后主体偏了。——所以图标的做法最好是"另做一张"——一句课程缩写、一个色块、一个符号，比一张完整的海报更适合桌面。

三是启动页。——这是最值得改的一处，因为它承担的是"确认"功能——学员打开应用的第一眼，就知道"我装对了"。——所以启动页上最该出现的是课程名和期数，而不是一张漂亮但看不出是什么的图。——而这也正是"内容型"最容易踩坑的地方：启动页做得太像，十几个包打开都一样，学员根本没法确认自己装的是哪门课。

四是首页标题和副标题。——这两行字是"包内身份"的核心——它比应用名长，可以写全，而且不受桌面截断的限制。——所以真正该写全的信息，放在这里：课程全名、期数、开课日期、讲师姓名。——而这一处也是"一个包对不对"最快的验证点——装完打开，看首页标题，一秒就能判断。

五是主色。——课程之间用主色区分，是一个成本很低、效果很好的办法——学员看到蓝色就知道是基础课，看到橙色就知道是进阶课。——而主色最好和图标、启动页共用一个色系——三处一致，学员才会形成"这个颜色=这门课"的印象。——而如果三处各用各的颜色，那这个印象就建立不起来，颜色也就白换了。

六是章节目录。——这是内容型独有的一处，也是唯一一处"改了会直接影响使用"的地方。——而它有一个特点：目录通常是结构化的——章、节、顺序、标题——所以它最不该"手改"，最该"从一份数据里读"。——而如果这个应用的目录本来就存在服务端，那包里就不该再放一份——两份目录一定会不一致，而不一致的那一天，学员会在群里问"为什么我这儿少一章"。

七是讲师介绍和报名入口。——这两处放在一起说，因为它们都是"人"的信息——一个讲"谁教"，一个讲"找谁"。——而它们的变化频率比课程名高：讲师可能换，客服可能换，报名入口的指向也可能换（这一期走这个表单，下一期走那个）。——所以这两处最好做成"一句话就能改"的东西，而不是分散在好几个页面里——分散就意味着每次改都要翻代码。

七处之外还有一处，不在清单里但每次都得动：版本号。——内容型多版本的版本号，建议和课程绑定而不只是"往上加"——比如"第四期"就让它成为版本号的一部分。——因为学员报的是"第四期"，而你手上同时有第三期和第四期的包——如果两个包的版本号只差一格，你在电话里根本说不清"你装的是哪个"。

三、哪些东西该留在包外：一条比技术更重要的边界

"一门课一个包"这句话，很容易被理解成"把一门课装进一个包"——而这两件事差别很大。——前者是"这个包属于这门课"，后者是"这门课的内容全在包里"。——而做错这一步，你会得到一个越用越难受的东西。

先说清楚为什么不该把内容打进包。——因为包是一个"整体替换"的东西——你改了包里任何一个字节，学员要拿到的就是"整个新包"。——而内容是会一直变的：加一节课、改一段讲义、换一道题——如果这些都在包里，那"改一道题"就等于"重发一个几百兆的包"。

而这个代价不只是"发得慢"。——学员每收到一个新包，就要卸载重装、或者覆盖安装——而覆盖安装的前提是包名相同、签名相同、版本号不降——三个条件里任何一个出问题，他就卡在那儿，然后找你。——于是"改一道题"这件事，变成了"一轮客服"。

那什么该进包？给三条判断标准，按顺序问。——第一问：这个东西一年会变几次？变一次以上，就不该进包。——第二问：它有多大？如果它让包体积翻倍，就再想一次。——第三问：它需不需要"没网也能用"？需要，才考虑进包。

按这三条问一遍，答案通常很清楚。——课程名、封面、图标、主色、讲师姓名、报名入口——它们小、变得不多、而且"没网也得显示"——所以进包。——视频、讲义、题库——它们大、变得勤、而且"没网"这件事可以靠提前下载解决——所以不进包。——而章节目录在中间地带：它的"骨架"（有几章、什么顺序）适合进包做兜底，它的"内容"（每节的标题和时长）适合从服务端读。

这个分法有一个很形象的比喻：包是壳，内容是水。——壳决定"这是哪个瓶子"——形状、标签、颜色——而水是可以换的。——而如果反过来，把水冻在壳里，那换水就得换瓶子——而瓶子是要发给学员的。

顺着这个比喻再往下一层：既然是"壳"，那它就该尽量简单。——一个只装身份的包，通常只有几十兆甚至十几兆——学员下载快、安装快、你重打也快。——而一个装了几百兆内容的包，会让你在做每一个决定时都心疼——于是你会开始"能不重发就不重发"，而"不敢更新"是内容型产品最糟的状态。

还有一个现实问题：包越大，出错的面越大。——因为包里每一份内容都可能带着它自己的问题——一份讲义打不开、一段视频编码不对、一道题的图片缺失。——而这些问题在"壳很薄"的时候几乎不存在——壳里只有名字、颜色、几张图，它们出问题的可能性本来就低。——所以"把内容留在包外"不只是为了更新方便，也是为了让"这个包对不对"变回一个容易回答的问题。

再说一个常见的反例，因为它太常见了。——有人把一整本讲义（两百多页 PDF）打进包，理由是"学员没网也能看"。——结果第一次改错别字的时候，他要重新打一个包含整本讲义的包，发给三百个学员——而这三百个人里，有两百八十个正在用旧版看视频。——最后他做的事是：把讲义从包里拿出来，改成"首次打开时下载"——而这本来是最开始就该做的选择。

而"该留在包外"这件事，还有一层和本文主题直接相关的好处：它决定了你要维护多少个包。——如果内容在包外，那"一门课一个包"就只是"十三张不同的皮"——皮很轻，改起来很快。——如果内容在包里，那每一个包都是一个"必须完整、必须正确、必须能装"的大东西——而十几个大东西，你顾不过来。

所以这一节的结论可以写得很短：包里只放"这门课长什么样"，不放"这门课讲什么"。——而这条边界一旦定下来，后面所有的事都变简单了——包变小了、更新变快了、以及"改错"的代价从"重发三百个包"降到"改一个字段"。——而它不需要任何技术能力——它只需要你在动手之前，把"这个东西会不会变"问自己一遍。

四、两个自家应用的实例：一门课一个包怎么落地

两个例子，都是我们自己内部在用的应用。——一个偏"学"，一个偏"练"，而它们恰好覆盖了内容型多版本的两种典型节奏。——每个例子还是三句话：以前怎么做、现在一句话怎么做、改完怎么验证。

例一：自家的内部培训学习端。——这个应用是我们自己做的，用来给新同事看入职课程——一共六门课，每门课有自己的封面、简介、讲师和章节目录。——新同事入职时，人事会把"他该看的那几门课"对应的包装给他。

以前怎么做：——六门课对应六次编译——改课程名、改封面、改讲师、改目录标题，然后一个一个等编译完成。——而最难受的不是慢，是"改一门课要动一次工程"——你改完第一门、正在等编译，突然想起第二门的讲师名写错了，于是排队；六门课排下来，一个下午就过去了。——而改完之后，六份工程已经分叉了——它们各自有不同的改动，谁也不记得哪一份是最新的。

现在一句话怎么做：——拿同一个源包，建六个项目——项目名就是课程名，每个项目里发一段话："应用名改成『入职课 · 信息安全』，启动页标题改成课程全名，首页副标题写『第 3 版 · 讲师 王工』，主色改成这个色，章节目录按附件这五行改，讲义入口保留，报名和答疑入口指向这个地址。"——六段话，六个项目，各自打包。——而"同一份工程"这件事没有变——变的是每一个项目里那几处。

改完怎么验证：——这里有一个内容型专用的验证法——"三看一比"。——看桌面名（能不能分清六门课）、看启动页（是不是这门课）、看首页副标题（讲师和版本对不对）。——然后把六个包并排放在一起，比一眼——如果六个包看起来"像是同一门课的不同版本"，那就说明区分度不够，得回头改名字或者改颜色。

例二：自家的认证练习端。——这是我们内部做的一个刷题应用，按认证方向分成四个包：基础、进阶、运维、安全。——它的节奏比学习端快——每季度题库更新一次，四个包都要跟着更新一次。

以前怎么做：——四个工程、四份题库文件——而题库是打进包里的。——于是每季度更新，等于"四个包各重打一次、每个包都是一百多兆"——而打完之后要发给所有在练的人，一个人发一次，一个季度发一轮。——最尴尬的一次是：一个人同时练基础和进阶，他先装了基础的新包，进阶的还是旧的——两个包在同一个手机上，题目版本不一样，他自己都乱了。

现在一句话怎么做：——题库从包里拿出去，改成"打开时检查更新"——包里只留"这个方向叫什么、图标是什么、主色是什么、题量大概多少"。——于是每季度更新的动作变成：四个项目各发一句话——"应用名带上一季度标记，首页副标题写『2026 春季题库』，版本号加一格"——然后各打一次包。——包从一百多兆掉到十几兆，发起来也不心疼了。

改完怎么验证：——这次多了一步"跨包互看"——把基础和进阶两个包装在同一台手机上，打开，看它们能不能同时存在、各自的首页是不是写着各自的季度。——这一步是因为那次"两个包版本不一样"的事故加上的——而它只用一台手机、两分钟，却能提前发现"包名撞了""副标题写串了"这类问题。——而这类问题的共同点是：单独看每个包都正常，放在一起才露馅。

五、三十个包怎么不打架：命名、归档、留几份

包的数量一多，最先崩的不是技术，是"找东西"。——你会经历这样一个下午：学员说他的包打不开，你想给他发一个新的，然后你在桌面上、下载文件夹里、微信文件传输助手里各找到三个 apk，而没有一个能确定是哪门课哪一期。

命名规则的目的是"看名字就知道是什么"，而它需要四段信息。——第一段是课程代号，第二段是期数，第三段是打包日期，第四段是版本号。——四段用短横线连起来，比如"data-04-20260412-v12.apk"——二十几个字符，一眼看全。

为什么第一段要用代号而不是中文课程名？——因为文件名会经过很多次"传递"——微信、邮件、U 盘、某些老旧的传输工具——而中文字符在这些环节里偶尔会变成乱码。——而乱码之后的文件名，等于没有名字。——所以代号用英文小写加数字，中文课程名放在台帐里对照——这样即使文件名被转成了乱码，你还能靠代号认出来。

第二段"期数"是最容易被省掉的一段，而它恰恰最不该省。——因为同一门课的第三期和第四期，包长得几乎一样——封面可能只差一个角标，目录可能只差两章。——而学员报的是"第四期"，他手上如果是第三期的包，他会看到少了的内容，然后问你"是不是漏发了"。——名字里带上期数，你和他在电话里就能对上：是 03 还是 04。

第三段日期和第四段版本号，其实是"同一件事的两种表达"。——日期回答"什么时候打的"，版本号回答"比手上这个新不新"。——而两个都留的原因很实在：日期给人看（你自己记得住"上周三那版"），版本号给机器看（安装的时候系统会比它）。

再说归档。三层目录就够了：按年、按课程、按包。——"2026 / data / 包文件"——这样一年下来，"去年那门课的包还在不在"这个问题，十秒钟能回答。——而如果所有包都平铺在一个文件夹里，三十个之后你就放弃整理了——因为整理的成本已经大于"重新打一个"的成本。

归档这件事还有一个容易被忽略的好处：它让"重打一个旧包"变成可能。——因为包是文件，删了就没了；而项目目录还在，你随时能照着同样的七处再打一次。——而前提是——那个项目目录没被删掉。——所以"留两份包"和"留两个项目"其实是同一件事的两面：包是给人发的，项目是给以后重打的。

每一层留几份？建议每个课程每个期数只留两份：最新的一份、和"上一份"。——留最新的，是为了发给新学员；留上一份，是为了"新包出问题时能退回"。——而再往前的不必留——因为学员用的是最新版，而"三个月前那一版"几乎不会被要。——如果真的被要了，你还有项目目录——重打一次比翻档案快。

而"留两份"这件事有个前提：包的名字得和项目名对得上。——所以建项目的时候，项目名就用那四段——"data-04-20260412"。——这样项目列表、包文件名、台帐里的记录，三处是同一个字符串——你从任何一处都能找到另外两处。——反过来，如果项目叫"数据分析第四期"、包叫"最终版.apk"、台帐里写"4期"——那这三处就是三个孤立的东西。

最后是台帐。一行一条记录，五列：代号、课程名、期数、包文件名、发给谁。——它不需要多漂亮，一个表格文件就够。——而它最大的作用是"回答三个月后的自己"——当有人问"我手上这个包是第几期的"，你把代号念给他，他看桌面上的名字就能答上来。

六、内容型最容易出的三类错，和一套装前核对法

内容型的错，几乎全落在三类里。——而这三类有一个共同的可怕之处：它们都不会让应用崩——应用照常打开、照常播视频、照常做题，只是"内容不是这门课的"。——而一个不崩的错误，才是最容易被放过去的错误。

第一类：张冠李戴。——把 A 课的封面打进了 B 课的包，或者把 C 课的讲师名写进了 D 课的首页。——而它最常发生在"连着做几个包"的时候——你刚做完 data 的包，接着做 ops，手上的素材还是上一门的那一套，于是名字改了、图忘了换。——而它最容易露馅的地方是启动页——学员打开第一眼就看见"这不是我报的课"。

第二类：比例错。——封面图被裁、被拉、被压扁。——这一类的根源是"一张图到处用"——同一张课程主图，既当启动页（竖屏或全屏），又当图标（正方形），又当首页头图（宽横幅）。——三个位置三种比例，一张图硬塞进去，必然有一处是变形的。——而变形这件事，你在电脑上看预览是看不出来的——因为预览会按比例显示，而装到机器上才会满屏铺开。

顺带说一个和封面有关的细节：深浅色。——如果应用的界面有浅色和深色两套，而封面是一张白底图，那在深色界面里它会显得特别刺眼；反过来，一张深色封面放在浅色界面上会像一块补丁。——所以封面最好自带留白、或者干脆用纯色块加文字——它在两种界面里都不会难看。——而这个判断只能靠"真的切一次主题看一眼"，不能靠想象。

第三类：目录对不上。——包里的目录和大纲不一致——少了最后一章、多了上一期的一节、或者顺序错了。——而它的根源通常是"两份目录"——一份在服务端、一份在包里。——两份东西只要存在，就一定会有一天不一致；而不一致的那一天，学员会在第三章卡住，然后问你"第六章在哪"。

针对这三类，一套"装前核对"可以这么走。——第一步是"并排看"——把所有包的项目列表（或者图标）放在一起看一眼，看有没有两个长得一样的。——长得一样，说明区分度不够，先改名字或颜色，别急着打包装机。

第二步是"单包三看"——装一台机器，看桌面名、看启动页、看首页副标题。——这三处就是"包内身份"的三个落点——三处都对，这个包基本不会张冠李戴。——而这一步只要一台机器、两分钟——它是所有验证里性价比最高的一步。

第三步是"跨包互看"——把同一门课的两个期、或者同一个人要用的两个包，装在同一台机器上。——看它们能不能同时存在（包名有没有撞）、看各自的副标题是不是各自的期数。——这一步专门对付"单独看都对、放在一起才露馅"的问题——而那类问题在内容型里特别多，因为包与包之间的差异本来就小。

还有一个很土、但很有效的习惯：让别人帮你念一遍。——你把包打开，把桌面名、启动页文字、首页副标题念给对方听，让对方对照着课程大纲核对。——为什么有效？因为你自己念的时候，眼睛会自动"看对"——你脑子里想的是"信息安全"，看到的也是"信息安全"，哪怕屏幕上写的是"信息安全基础"。——而别人没有这个预期，他会直接告诉你"这里多了两个字"。

这三步加起来，一个包大约五分钟。——而如果你的包里"内容"很少、"皮"很薄，那这五分钟就足以覆盖绝大部分风险——因为内容型的错，八成都发生在这三处。——而剩下的两成——目录对不上——不是靠验证解决的，是靠"只留一份目录"解决的。

七、什么时候"一门课一个包"就不再划算了

任何方法都有它的边界，而"一门课一个包"的边界画在三个地方。——越过去之后，它不会突然不能用，只是每件事都变慢一点——而慢到某个程度，你会开始怀疑是不是方法错了。

第一个边界：课程数量的增长速度超过你的维护速度。——六门课的时候，一人一天能全打一遍；二十门课的时候，一天打不完；到五十门课，这件事就变成"必须排期"。——而到了那个程度，更划算的做法是"一个包加一个选课页"——只发一个包，学员在里面选课程，包里的内容按选择动态加载。

第二个边界：差异只剩"封面"一处。——如果十几门课除了封面和名字，其它全都一样——那"一个包一个选课页"其实更合适。——因为"一门课一个包"的价值在于"学员装上去就是这门课，不用选"——而如果这个价值不明显，那维护十几个包的成本就是白花的。——换句话说：包的价值在于"省掉一次选择"，而选择本身如果不到三秒，这个价值就很小。

而现实中更常见的是混合方案，它值得说清楚。——把课程分成两档：主推的三五门课各出一个包，剩下的课全部收进一个"更多课程"的包里。——这样学员最常报的那几门，装上去就是那门课；而冷门的课也有地方去，不需要你为每一门都维护一个包。——而分档的界线很简单：看报名量——前几名单独出，剩下的合并。

第三个边界：课程之间的差异已经不是"皮"，而是"功能"。——比如一门课要做直播、另一门要做代码判题、第三门要做小组讨论——那就不是"同一个应用换皮"了，那是三个不同的产品。——而用打包这条路去承载功能差异，最后一定会变成"一个包里塞了三套功能，靠开关切换"——那时候你维护的不是十几个包，是一个越来越难懂的包。

这三条边界有一个共同的信号：你开始觉得"每次都要重新想一遍"。——当一件事从"照着清单做"变成"每次都要想"，说明清单已经装不下它了。——而这时候正确的动作不是"再努力一点"，是"回头看这条路还合不合适"。

而反过来说，只要还在这三条边界之内，"一门课一个包"就是最省事的做法。——因为它把"选择"这个动作从学员身上拿走了——报名哪门课，就装哪个包，打开就是这门课。——而学员少一次选择，你就少一类"我选错了怎么办"的咨询。

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

问一：十几门课，是不是要建十几个项目？——是。因为一个项目只有一份配置、一份签名、一份历史——一个项目打出来的永远是同一个包。——而"十几个项目"并不意味着"十几份工程"——它们可以都从同一个已改好的项目目录拷出来，各自只改那七处。

问二：能不能一个包，让学员自己选课程？——能，而且课程多的时候更合适。——但要想清楚一件事：这个"选课"的界面，是本来就有，还是要新做？——如果本来就有，那直接用它；如果要做，那这是"开发新功能"，不是"打包"——别把两件事混在一起估算工时。

问三：包名要不要每门课都不一样？——如果学员可能同时装两门课，就必须不一样——否则装第二门会顶掉第一门。——而如果学员一次只学一门，那包名可以一样——但版本号要往上走，否则装不上已经装了旧课的那台机器。——这里没有对错，只有"你的学员怎么用"。

问四：一门课改了封面，要不要重新发所有学员？——看这个封面在哪儿。——如果封面只出现在"启动页"和"桌面图标"，那它在包里，必须重发；如果封面是首页从服务端读的图，那改一次就够了，不用重发。——而这就是上一节说的"该留在包外"的具体价值——它让"改一张图"从"发三百个包"变成"换一个文件"。

问五：结课之后，那个包和那个项目怎么办？——包留一份（带名字的），项目目录留到下一期开课之前。——为什么项目要留？因为下一期九成是在这一期上改——你把目录拷一份、改期数、改目录、改讲师，比从零建项目快得多。——而下一期开完，再删上一期的项目——这样任何时候你手上都只有"这一期"和"上一期"两个项目。

九、开课之前，把这张表勾一遍

下面十项，是按"漏了会出事"挑出来的。——它比"完整清单"短，所以在真实的时间压力下更容易被真的执行——而一张会被执行的短表，比一张被忽略的长表有用得多。

序号	开课前要确认的一项
1	课程代号定了，四段命名规则写下来了
2	这一期的目录只有一份来源，包里不再存第二份
3	封面按三种比例各准备了一张，不是一张到处塞
4	图标按密度档给齐，而且是一张"看得清"的图
5	应用名短到能在桌面完整显示，区分信息放在前面
6	首页副标题写清了课程全名、期数、讲师、版本
7	签名和上一期一致，学员能直接覆盖安装
8	版本号比上一期高，而且能看出是哪一期
9	在装过上一期的机器上装一次，确认能覆盖
10	所有包并排看过一眼，没有两个长得一样

这十项里，第 2、9、10 三项最容易被跳过，而它们恰好是最"省事看起来不值"的三项。——第 2 项要你去改服务的结构（不是打包的事），第 9 项要你找一台装过旧版的机器，第 10 项要你把包放在一起看一眼。——而它们能挡掉的，正好是那一类"装上能跑但是错的"问题。

再补一条不在表里、但很省事的做法：把这一期所有的包放在一个文件夹里一起发。——因为学员往往不只报一门课——他可能同时报了基础和进阶，而你分四次单发，就要解释四遍"哪个是哪个"。——一个文件夹、几个包、一段话术，能省掉三轮来回。——而文件夹的名字就用课程代号那几段的前两段，比如"2026-spring"——学员一看就知道这是这一期的全部，不会再去问"还有没有别的"。——而这件事的前提仍然是命名：包名不统一的时候，一个文件夹里放四个包，只会让混乱更集中。

还有一件表里没写、但值得做的事：给学员一段说明话术。——因为"装哪个包"这件事，在你看来很清楚，在学员看来不是——他可能已经装了上一期，也可能装了另一门课。——而一段三行的话术能省掉一半咨询：这一期叫什么、装之前要不要卸载旧版、装完看哪里确认。

而这段话术有一句几乎是万能的："装完打开，看首页那行小字，写着第几期就是你装的第几期。"——因为它把"确认"这个动作，从"需要技术支持"变成了"看一眼"。——而这一句之所以能成立，正是因为前面把"期数"写进了首页副标题——清单第三项和这句话术，是同一件事的两头。

十、用过的人怎么说

五条里，三条讲"改得快"，一条讲"张冠李戴"，一条讲"该收了"。——而"改得快"这三条有一个共同的落点：它们都不是"打包变快了"，而是"范围变小了"——改一门课只影响一门课。——而这一点，恰恰是"一个项目一个包"这个结构带来的，不是工具带来的。

那句"做到第十几个包的时候我放弃了"，值得单独说一句。——它不是失败，是判断对了——因为方法的边界就在那儿，而能在边界处换方法，比硬撑到底更专业。——而判断的依据不是感觉，是"每次都要重新想一遍"这个信号。

---

只需说话，就能让应用变成你想要的样子。——而"变成这门课的样子"，也就是把七处说清楚、把内容留在包外、再把名字定得让人分得清——这三件事做完，安卓修改大师智改工坊要做的，只是把它们变成十几个包。