循环打包做多轮微调：同一需求、不同版本、自动归档

安卓修改大师智改工坊 · 循环打包与版本归档实战笔记

循环打包这件事，听起来像“把同一个需求多跑几遍”，真正做起来却很容易乱：第二轮改了图标，第三轮又回到旧图标；活动图换了三版，群里还在传第一版；打包日志散落在不同目录，出了问题找不到是哪一轮。本文把“同一需求、不同版本、自动归档”拆成一套可执行的手上流程，用的产品是智能修改电脑版。

固定口号先放在这里：只需说话，就能让应用变成你想要的样子。这句话适合描述单轮修改，也适合描述多轮微调。前提是每一轮都说清楚“这一轮只改什么”，并且给成品留下清楚的名字和记录。否则，循环越多，版本越乱。

官方介绍与下载页：https://www.apkeditor.cn/ai-version.aspx。本文只讨论自家应用或已获授权应用的改包与打包，不涉及修改他人应用，也不涉及绕过任何安全机制。

一、先定思路：循环打包解决的是版本管理，不是“多改几次”

单轮改包的目标很直接：把需求改进去，打出成品，装上能跑。循环打包多了一层目标：同一份需求基线不变，每一轮只引入一个可比较的变化，并且让这一轮的成品、日志、验收结果互相对应。如果做不到这三点，所谓循环就只是重复劳动。

在智能修改电脑版里，一个项目有自己独立的工作目录，里面有源码包、反编译工程、打包产物和日志。循环打包应该始终围绕同一个项目、同一份源码展开，而不是每轮新建一个项目、重新导入一次 APK。项目固定下来，历史记录才能连着看，配置、附件、打包参数也不会每轮漂移。项目目录里会写 config.ini 和 history.ini，history.ini 保留的是用户原话；这些记录在多轮微调时很有价值，能帮你回看上一轮到底怎么说的。

多轮微调最怕两件事：一是“改多了”，第二轮的改动把第一轮已经验收的内容又带回去；二是“说不清”，成品文件名叫“最终版”“真的最终版”“最终版2”，过两天谁也不敢确认哪一个是客户点头的版本。循环打包的规则，本质上就是围绕这两件事做约束。

我的建议是守住三条底线。第一条，一轮只改一个主要变量：这一轮换活动图，就不要再顺手改启动页；这一轮调文案，就不要同时换主题色。第二条，一轮只产出一个主成品，中间文件可以有，但对外发布的只能有一个明确文件。第三条，一轮结束必须留下三样东西：可安装的成品、打包日志、验收结论。三样凑齐，这一轮才算闭环。

循环打包适合哪些场景？活动页多套素材的比选、图标和应用名的多版本微调、同一应用给不同客户做品牌变体、内部工具在不同环境之间切换、界面文案的逐轮打磨。这些场景的共同点是：需求方向已经明确，剩下的是小步调整和版本比较。反过来，如果要做的是大规模功能重构、涉及复杂原生逻辑的改造，或者根本没有验收标准，就不要硬套循环。轮次越多，返工越重。

还有一点要说清楚：循环不等于“无人值守地一直跑”。智能修改电脑版会在 AI 完成后留下 ai_done.flag，主窗口每 2 秒轮询一次，读到就删除，等待上限是 1 小时。这套机制适合一轮一轮地交接，不适合把十轮任务一次性堆进去就不管。每一轮打包完成后，至少要看一眼成品是否装得上、页面是否对，再决定下一轮怎么改。所谓自动归档，是规则和脚本帮你减少手工劳动，不是替你承担验收责任。

二、循环任务设置：把一轮拆成七个固定动作

很多人设置循环任务，第一反应是“找一个循环按钮”。实际更稳的做法，是把一轮拆成固定动作，让每一轮都按同一顺序执行。智能修改电脑版负责 AI 修改、回编、对齐、签名和安装预览；轮次管理、命名规则、归档目录由你事先定好。工具做工具的事，流程做流程的事，两者不要混在一起。

开始之前，先把六个参数定下来：项目用哪一个、源码包用哪一份、本轮唯一变量是什么、成品叫什么名字、成品放在哪个目录、什么条件下停止循环。这六个参数不需要写得很长，一张表就够。把它们贴在项目说明里，下一轮开始前对照一遍，比凭记忆可靠得多。

参数定好之后，把一轮拆成七个动作。这七个动作听起来多，熟练以后其实是一条线，难点不在操作，而在“不跳步”。

1. 轮次登记。在轮次表里写下轮次编号、本轮目标、唯一变量、输出文件名和验收人。编号从 r01 开始，不要用“最终版”这类无法排序的名字。
2. 需求模板。把上一轮的需求原话复制过来，只替换本轮变量。智能修改电脑版详情页有 3000 条话术，分界面美化、弹窗引流、去除限制、常规修改、混淆去毒、插件添加六类，可以点选填入输入框；多轮微调时把它当作措辞参考，不要把六类需求一次全塞进去。
3. 附件核对。如果本轮要换图片、字体或其他素材，用附件系统一次多选，每个文件写清用途，用途不少于 10 个字。附件会校验存在、非目录、非 0 字节、可读，拼成序号、路径和说明随需求发出。素材名和轮次对不上，是循环打包最常见的错误来源之一。
4. 触发本轮修改。点“立刻修改”，原文和日期会写进 history.ini，需求送进右侧 AI 工作区执行。同一时间只保留一轮在跑，不要在主窗口和 AI 工作区里各点一次。
5. 等待交接信号。AI 完成后会在项目目录留下 ai_done.flag，主窗口每 2 秒轮询，读到即删。等待期间不要手动新建或删除这个文件，也不要急着开下一轮。
6. 四步打包与安装验收。回编、对齐、签名、校验会依次执行，全过程写 pack.log；打包后还会走 adb 安装并拉起应用。看到成品之后，按本轮验收点逐项确认。
7. 归档收尾。把成品改成发布名，复制到发布目录，连同 pack.log、apktool.log 和轮次记录一起归档。归档完成，才把轮次表里的状态改成“通过”。

这套动作里，最容易被忽略的是第 1 步和第 7 步。大家愿意花时间调 AI 需求，却不愿意花两分钟登记和归档。结果就是：AI 改得越多，版本越难找。循环任务设置的核心不是让工具跑得更快，而是让每一轮都能被指认、被复现、被回退。

如果一轮任务比较大，可以把需求拆成“本轮目标 + 不改动范围 + 验收点”三段来写。比如：“本轮只替换首页顶部活动图，不改应用名、不改启动页、不改其他页面；验收时打开首页看到新图，退出重进仍然是新图。”这种写法比“再优化一下”有效得多。AI 需要边界，打包也需要边界；边界越清楚，循环越稳定。

关于“自动”，还要补充一句：智能修改电脑版的工作目录会自动挑盘，按 D、E、F、G、C 的顺序找第一个可读写且剩余空间不少于 1GB 的盘，下面分 tools 和 Project 两个子目录。循环打包会产生多份成品和多份日志，开始前看一眼工作盘剩余空间，比跑到一半再清理更省事。成品和日志最好分目录存放，不要把发布文件直接丢在 build 目录里，下一次打包很容易把它们和中间文件混在一起。

三、每轮 ai_done.flag 与四步打包：等交接信号，留打包证据

循环打包能不能稳定，关键看两个环节：AI 改完有没有可靠的交接信号，打包有没有完整的证据。智能修改电脑版把这两件事做成了固定动作：AI 完成后留下 ai_done.flag，主窗口轮询到就开始后续打包；打包按四步执行，全过程写 pack.log。你要做的是理解这两个环节的边界，不要在中间乱插手。

1. ai_done.flag 是交接信号，不是“打包成功”的通知

在智能修改电脑版里，点“立刻修改”之后，需求会送进右侧 AI 工作区执行。AI 完成修改，会在项目目录里留下 ai_done.flag。主窗口每 2 秒轮询一次，读到这个文件就删除，然后继续往下走，等待上限是 1 小时。这个顺序很重要：flag 出现，只说明 AI 这一轮写完了；成品能不能装、签名有没有过，要看后面的打包和校验。

所以，循环任务里不要把这个文件当成“完成证书”，更不要把它复制到归档目录。它被主窗口读走就会删除，属于一次性的交接信号。真正应该归档的是成品、pack.log、apktool.log 和你的轮次记录。把一次性信号当证据，过两天就什么都查不到。

等待 flag 的时候，有四条规矩。第一，触发本轮之前，确认项目目录里没有残留的 flag；如果有，先让主窗口按正常轮询处理，不要手动删。第二，触发之后不要反复点“立刻修改”，也不要在 AI 工作区里再提交一遍，重复提交会让同一轮出现两份改动。第三，flag 迟迟不出现时，先看 AI 工作区是否还在执行、项目目录有没有新文件、error.log 有没有异常，再决定是否停止。第四，超过等待上限仍然没有结果，按异常收尾处理，不要无限等下去，也不要把上一轮的成品当成本轮成品发出去。

循环打包最危险的时刻，不是 AI 改错，而是上一轮还没打包完，下一轮就开始了。主窗口和 AI 工作区都盯着同一个项目目录，上一轮的 flag 可能被这一轮的等待逻辑读到，打包也可能读到改到一半的工程文件。结果就是：成品名字是第 3 轮，内容却混了第 2 轮和第 4 轮。避免方法很朴素——上一轮的四步打包和安装验收没有结束，不开下一轮。

2. 四步打包：unsigned、align、sign、verify 各看什么

智能修改电脑版的打包不是“一键出包”四个字就结束了，它按固定四步执行，每一步都有明确目的。你不需要每次手敲命令，但要知道日志里这四步分别意味着什么，出问题时才能判断该看哪里。

apktool b -f -o build\unsigned.apk
zipalign -f -p 4
apksigner sign
apksigner verify --print-certs

第一步，回编。apktool 把修改后的工程重新编译成 build\unsigned.apk。这一步失败，通常要看 apktool.log，重点检查资源引用、文件路径、编码和工程完整性。回编没通过，后面的对齐和签名都没有意义，不要拿旧的 unsigned.apk 继续凑。

第二步，对齐。zipalign 对 APK 做 4 字节对齐，让安装后的资源读取更规范。它处理的是打包产物的内部对齐，不负责签名。对齐这一步如果失败，先确认输入文件是不是刚回编出来的完整 APK，不要把一个正在被其他程序占用的文件传进去。

第三步，签名。apksigner 用你选择的密钥给 APK 签名。智能修改电脑版支持四选一：默认签名、JKS 或 keystore、PEM 加 PK8、随机签名；签名方案支持 v1、v2、v3、v4，默认 v1+v2+v3。口令走环境变量，不拼进命令行，也不写进日志。循环打包时，签名配置要保持一致；同一台测试设备上，签名变了通常要先卸载旧版再装新版，否则会安装失败。

第四步，校验。apksigner verify --print-certs 用来确认“到底签没签上”，并打印证书信息。多这一步不是形式主义：密钥格式错误、签名方案不匹配这类问题，只有 verify 会明确报出来。循环打包时，把每一轮的证书信息记进轮次表，后面排查“这一版是不是我签的”会很快。

四步都通过之后，pack.log 才是一份完整的打包记录。循环打包时，建议每轮把 pack.log 复制一份到发布目录，文件名带上轮次，例如 pack_r03.log。不要等所有轮次跑完再从同一个日志里翻，日志会不断被新一轮覆盖或追加，越晚找越费劲。复制而不是移动，原日志留在项目里，方便工具后续排查。

3. 打包后的安装与前台复核：自动预览不等于自动验收

签名校验通过后，智能修改电脑版会尝试自动运行：adb 找设备、安装 APK，再用 am start -W -n 包名/Activity 拉起应用。启动组件名有三档查找方式，先看 config.ini 里的 LaunchableActivity，再用 cmd package resolve-activity --brief 查，最后走旧方式兜底；拉起后用 dumpsys 复核前台应用。手机可以通过 scrcpy 投屏，模拟器会被提到最前。对循环打包来说，这套自动预览非常省事，但它只负责“把成品跑起来”，不负责“这一轮是否合格”。

验收要你自己做。至少看四件事：应用能不能正常启动；应用名和图标是不是本轮要的；改动页面是不是正确；返回、重进、切后台之后状态是否还在。活动包还要看图片有没有被压缩得过头、文案有没有截断；多客户版本还要看包名、入口地址、主题色有没有串。自动安装成功只说明包能装，不说明内容对。

循环打包最好固定一台测试设备。每轮都换手机，出现问题时无法判断是包的问题还是设备环境的问题。设备固定之后，安装失败的排查顺序也固定：先看 adb 是否识别到设备，再看安装命令的返回，再看签名是否和上一版一致，最后看系统版本和架构是否匹配。把这条顺序写进轮次表，下一轮遇到同样问题就不用重新猜。

四、发布文件名规则：时间戳、数字后缀、同名覆盖怎么选

循环打包一旦超过三轮，文件名就不只是文件名了，它是人和脚本共同使用的接口。运维问“发我第三版”，客户问“上周那版还能装吗”，测试脚本按固定路径取包，靠的都是命名。命名规则没定好，后面每加一轮，混乱就多一层。

先记住一个总原则：打包产物和发布成品分开命名，中间文件不进入发布目录。build 目录里的 unsigned.apk、对齐后的临时文件、签名过程中的中间产物，都不应该直接发给别人。发布目录里只放已经通过四步打包和验收的 APK，名字要能独立回答“这是哪个项目、哪一天、第几轮、哪个变体”。

1. 时间戳命名：适合归档和对外交付

时间戳命名的典型写法是“项目_场景_日期_时分.apk”，例如“活动包_20261021_1530.apk”。它的优点是天然唯一、按名称排序就是按时间排序，特别适合归档、发给外部合作方、或者在云盘里按日期翻找。循环打包时，如果同一分钟内可能出两版，就在后面补上轮次或秒，例如“活动包_20261021_1530_r02.apk”，不要为了省几个字符让两个文件撞名。

时间戳命名要注意三点。第一，日期用“年月日”连续数字，不要用“10-21”这种容易和月日混淆的写法；第二，时分用 24 小时制，避免上午下午看不出；第三，不要把冒号、斜杠、星号、问号、引号、尖括号、竖线放进文件名，这些字符在 Windows 上不合法，复制到云盘或压缩包里也容易出问题。用下划线分隔最稳。

2. 数字后缀命名：适合多轮比选和内部评审

数字后缀是循环打包最常用的方式，例如“活动包_20261021_r01.apk”“活动包_20261021_r02.apk”。r 是 round 的缩写，后面补零，保证排序稳定。它的好处是轮次一眼可见，和轮次表一一对应；评审时说“看 r03”比说“看那个最新版”准确得多。数字后缀不要从 1 开始每轮重置，也不要跳号，跳号会让归档缺一块，后面很难判断是没做还是丢了。

数字后缀最好和“唯一变量”绑定。比如 r01 对应活动图 A，r02 对应活动图 B，r03 对应活动图 C；轮次表里写清楚，文件名只负责标识，不负责解释。这样即使过了一周，看到 r03 也能从表里查到当时改了什么。不要把“r03”同时用于两个不同变量，否则数字后缀就失去了比较意义。

3. 同名覆盖：只给“最新入口”用，不给唯一成品用

同名覆盖指的是始终输出一个固定名字，例如“活动包_最新.apk”，每轮打包后覆盖它。它适合一种场景：下游测试脚本、内部下载页或某个固定路径只认这个名字，你不想每次都改配置。除此之外，尽量少用。因为同名覆盖会抹掉“上一版是什么时候的”这个信息，一旦新版本有问题，连回退都要靠记忆。

如果确实要用同名覆盖，至少加三道保险。第一，覆盖之前先把旧文件复制到归档目录，用时间戳或轮次命名，确保上一版还在。第二，只有通过验收的成品才能覆盖“最新”，没验收的留在候选目录。第三，云盘同步要避开覆盖动作，或者干脆让云端只存版本化文件名，固定名只在本地发布目录使用。这样即使同步冲突，也不会把云端唯一一份旧版冲掉。

不管用哪种命名，都建议带上一段“人话前缀”。纯数字文件名在聊天窗口里排成一列，很难分辨；带上项目名和场景，至少能看懂一半。名字也不要太长，超过几十个字符后在手机上显示不全，复制来复制去容易截断。把项目、场景、日期、轮次、变体这五段控制住，基本就够用了。

五、本地与云存储：成品、日志、归档三层分工

循环打包会持续产生文件，存储不分工，很快就会变成“什么都在一个盘里”。比较稳的做法是分三层：项目工作层、本地发布层、归档层。三层各放各的，谁也不替谁做备份，谁也不把中间文件混进成品。

第一层是项目工作层。智能修改电脑版会给每个项目建一个 8 位随机目录，里面有 config.ini、history.ini、source.apk，反编译工程在 apktool 目录，日志包括 apktool.log，打包产物在 build 目录。这个目录是工具的工作现场，文件多、变化快，不适合直接拿云盘实时同步。尤其是 apktool 工程和 build 目录，同步过程中被占用或半写一半，下一次打包很容易读坏。工作层就放在本地，等成品验证完再往外复制。

第二层是本地发布层。在项目之外单独建一个发布目录，按“项目/日期/轮次”分类，只放已经通过四步打包和安装验收的 APK。比如“发布/活动包/20261021/活动包_20261021_r03.apk”。这一层是日常交付用的，打开就能找到，不需要进工具目录翻 build。同名覆盖的“最新”文件也放在这里，但旧版必须先复制到归档层。

第三层是归档层。每一轮一个文件夹，里面放成品、pack.log、apktool.log、轮次记录，必要时再放验收截图。归档层可以放在本地另一块盘、移动硬盘或企业网盘，关键是和发布层分开。发布层可以清理，归档层不要随手删。循环打包的“自动归档”，最终要落到这一层，而不是只把文件改个名放在桌面。

云存储怎么用？建议只同步发布层和归档层，不同步项目工作层。云端目录按“项目/日期/轮次”组织，文件名保持版本化，不要用“最新”这种会变的名字作为云端唯一副本。每一批上传后，核对文件大小和数量；如果条件允许，再算一次校验值，确保上传完整。签名密钥、口令、包含敏感路径的配置不要放进云盘；日志在上传前看一眼，避免把不该外传的路径或账号信息带出去。

本地和云端还要约定“谁是真源”。我的习惯是：本地发布层是交付真源，归档层是历史真源，云端是副本。需要发文件时从本地发布层取，需要查历史时去归档层找，云端只用于跨设备访问和灾备。这样即使云盘同步冲突，也不会影响本地已经验收的成品。关于各版本的功能和下载方式，以 www.apkeditor.cn 公布的信息为准，不要从第三方转存站拿不确定的安装包。

空间管理也要提前想好。循环打包的 APK 本身不一定很大，但反编译工程、build 中间文件和日志会不断累积。每完成一个阶段，可以清理工作层里不再需要的旧 build 产物，但归档层的成品和日志不要跟着清。清理前先确认“最新”入口指向的是哪一轮，避免把正在使用的文件删掉。工作目录自动挑盘时要求剩余空间不少于 1GB，这不是让你可着 1GB 用，而是提醒你在开始前留出余量。

六、停止任务：先定停止条件，再做安全收尾

循环打包如果没有停止条件，就不是自动化，而是把风险交给时间。开始第一轮之前，先把“什么时候停”写下来。停止条件不需要复杂，但要具体到能判断。比如“最多做五轮”“验收点全部通过就停”“同一个问题连续两轮没解决就停”“测试设备离线就停”。这些条件写在轮次表顶部，每轮开始前看一眼，比事后靠感觉决定更可靠。

常见的停止场景有六类。第一，验收已经通过，继续改也没有明确收益，停。第二，达到计划轮次，哪怕还有小瑕疵，也先停下来复盘，不要无限加轮。第三，同一个问题连续两轮出现，说明不是“再改一次”能解决的，停下来查原因。第四，需求方向被推翻，原来的轮次基线已经失效，停下来重新立基线。第五，设备、工具链、磁盘空间出现异常，停下来处理环境。第六，发现应用授权不清或不是自己的应用，立即停止，不再继续。

怎么停，比什么时候停更容易出错。最稳的停法是在一轮结束时停：四步打包完成、安装验收做完、成品和日志归档，然后不再开始下一轮。这个时候停，项目是干净的，下一轮随时可以接上。不要在 AI 正在写文件的时候强行开下一轮，也不要在签名进行到一半的时候把进程杀掉，前者会让工程处于半改状态，后者会让成品处于半签状态。

如果确实要在 AI 执行中途停止，先在 AI 工作区停止当前任务，确认没有新的文件写入，再处理项目。停止之后不要马上点“立刻修改”，先看项目目录里有没有残留的临时文件、build 目录里有没有不完整的 APK。必要时从 source.apk 重新复制一份干净工程，不要让下一轮在不确定的工程上继续。循环打包最贵的成本不是多跑一轮，而是在脏工程上跑十轮。

如果停止发生在打包阶段，先判断停在哪一步。回编没完成，build 目录里的产物不能用于发布；对齐没完成，文件可能还不是最终形态；签名没完成，安装很可能失败；verify 没通过，说明签名结果不可信。这几种情况统一按“本轮作废”处理：保留日志，删除不完整产物，不要拿它去覆盖“最新”，也不要用它给客户看。日志要留着，因为它记录了失败的位置，下一轮排查用得上。

关于 ai_done.flag，停止任务时也不要去手动新建或删除它。它是主窗口和 AI 工作区之间的交接信号，按正常轮询处理即可。如果等待超过上限，主窗口会按超时逻辑结束等待；这时你应该检查 AI 工作区和项目文件，而不是反复触发任务。把“停止任务”理解成“停止继续加轮，并把现场收拾干净”，而不是“把所有相关文件都删掉”。

停止之后要不要恢复？看两件事：问题是否已经定位，基线是否还成立。如果只是设备掉线，重连后可以从新一轮继续；如果是需求方向变了，就不要在原轮次上补，重新开一个轮次序列。恢复时先跑一轮“小改动”确认链路正常，再回到正常节奏。不要一恢复就叠加大改，否则出了问题分不清是环境没修好，还是改动本身有问题。

七、日志归档：把每一轮的证据链收齐

循环打包的日志不是“出问题才看的附件”，而是每一轮的证据链。智能修改电脑版会留下几类日志：apktool.log 记录反编译和回编过程，pack.log 记录打包四步，error.log 记录未处理异常，dock.log 记录窗口吸附和布局。它们的作用不同，归档时不要只拿一个 pack.log 就完事。

apktool.log 最适合排查“工程为什么回编不过”。资源引用、文件缺失、编码问题，通常会在这里留下线索。pack.log 适合排查“四步走到哪一步失败”，它按顺序记录回编、对齐、签名、校验，能看出是命令失败还是产物不对。error.log 适合排查工具本身的异常退出，尤其是界面卡住、任务没有反应的时候。dock.log 只和双窗口布局有关，不要拿它当打包证据；但它能帮你确认当时窗口有没有被拖动、工作区有没有异常。日志的价值在于“当时发生了什么”，所以不要事后编辑，也不要只保留最后一份。

归档目录建议按“项目/日期/轮次”建，每一轮一个文件夹。里面至少放五样：成品 APK、pack.log、apktool.log、轮次记录、验收截图。轮次记录不用写成长文，一张表就够，把项目、轮次、日期、需求原话、附件清单、唯一变量、输出文件名、签名证书信息、安装结果、验收结论和遗留问题写清楚。以后别人问“r03 改了什么、谁验的、装在哪台机器上”，翻这一页就能回答。

归档/活动包/20261021/
  第01轮/
    活动包_20261021_r01.apk
    pack_r01.log
    apktool_r01.log
    轮次记录_r01.txt
    验收截图_r01.png
  第02轮/
    活动包_20261021_r02.apk
    pack_r02.log
    apktool_r02.log
    轮次记录_r02.txt
    验收截图_r02.png

归档动作要固定成流程：先验收，再复制，再写记录，再打包压缩，最后上传。验收没通过的那一轮也可以归档，但要在记录里明确写“未通过”和原因，不要和通过轮次混在一起。压缩包命名同样遵循第四节的规则，例如“活动包_20261021_归档_r01-r04.zip”。上传云盘后核对文件大小，必要时算校验值；不要只看到“同步完成”就认为文件完整。

日志里可能包含本地路径、设备信息、工程名称。对外提供日志前，先检查有没有不适合外传的内容；签名口令不要写进任何轮次记录，密钥文件也不要放进归档包。日志可以复制，但不要编辑；需要摘录时，新建一份说明，把原始日志留在原处。归档的目的不是“看起来整齐”，而是“出了问题时能还原当时的过程”。

八、实例一：自家活动包多轮微调（以前 / 现在 / 验证）

这一节用一个自家电商展示应用的活动包做例子。应用和素材都属于自己团队，改动范围是首页活动图、活动文案和图标细节，不涉及他人应用。活动周期是一周，运营需要比较三套主视觉，再根据数据选一套收尾。以前的做法是每改一次就重新打包、手动改名、发到群里；现在的做法是把四轮微调放进同一套循环流程。

以前：每轮都从“再来一次”开始

以前最头疼的不是改图，而是改完之后的版本管理。运营发来一张新 banner，设计说上一张再调亮一点，测试又反馈启动页被顺带改了。每一轮都要重新找素材、重新说需求、重新打包；成品名从“活动包_最终.apk”变成“活动包_最终2.apk”，最后连自己都分不清哪一版对应哪张图。更麻烦的是，某一轮装不上时，没有 pack.log 可查，只能从头再打一次。时间花在重复劳动上，真正的验收反而被压缩。

现在：同一项目、四轮、每轮只换一个变量

现在先建一个固定项目，导入自家应用的 source.apk，工作目录放在空间充足的盘。发布目录单独建在“发布/活动包/20261021/”，下面再分“候选”和“最新”。轮次表写四行：r01 换主视觉 A，r02 换主视觉 B，r03 换主视觉 C 并修正文案换行，r04 根据评审意见定稿。每一轮只改一个主要变量，其他内容保持不动。

需求模板也固定下来。基础句是“保持应用名、包名、启动页和其他页面不变，只替换首页顶部活动图为本轮附件，并同步替换活动文案”，后面接本轮变量。每轮把对应的 banner 作为附件上传，附件用途写清楚，例如“r02 首页顶部活动图，尺寸与上一轮一致，用于 B 方案比选”，确保不少于 10 个字。附件路径和轮次对得上，后面归档时不会拿错图。

每一轮的操作顺序是：登记轮次，点“立刻修改”，等 ai_done.flag 被主窗口读走，等四步打包完成，安装到固定测试机，按验收点检查，最后把成品改名为“活动包_20261021_r01.apk”这样的版本名，复制到候选目录。四轮都通过之后，才把最终选中的 r04 复制成“活动包_最新.apk”，同时把 r01 到 r03 原样留在候选目录，不删不改。

验证：每一轮都按同一张验收单走

四轮用的是同一台测试机。每轮安装后先看应用能不能正常启动，再看应用名、图标、首页活动图和文案是否为本轮内容，然后退出重进一次，确认不是缓存造成的假象。接着看版本信息是否符合本轮计划，签名是否能通过校验，最后用 dumpsys 复核前台应用确实是刚安装的这一版。手机通过 scrcpy 投屏，验收时直接看大屏，比在小屏幕上眯眼找细节可靠。

每轮验收都截一张首页图，和成品、日志一起放进本轮归档目录。r01 到 r03 的截图并排看，能很直观地比较三套主视觉；r04 定稿时，评审不需要再装三个包，直接看归档截图就能回忆当时的选择。打包日志里记录的四步结果和签名证书信息也一并保留，后续如果出现“这版是不是我们签的”这种问题，不用重新翻工具目录。

这个实例的关键不是“四轮”这个数字，而是每一轮都能独立回答三个问题：这一轮改了什么，成品叫什么，验证结果在哪。以前这三个问题要靠聊天记录拼，现在打开归档目录就有。循环打包把重复的打包动作交给工具，把判断和验收留给人，分工清楚了，多轮微调才不会变成多轮混乱。

九、实例二：按客户出多版本（以前 / 现在 / 验证）

第二个实例是自家团队为不同客户定制的展示应用。应用的核心功能一致，差异在应用名、入口页面、主题色和欢迎文案；代码、素材和品牌使用均已获得客户授权。三个客户对应三份固定的 source.apk，分别建项目，但共用同一套循环打包规则。这样既不会把客户内容串在一起，也不用为每个客户重新设计流程。

以前：复制文件夹、手动改名、靠记忆分辨

以前的做法是复制上一个客户的项目文件夹，改成新客户的名字，再手动替换应用名、入口地址和主题色。听起来简单，实际问题不少：有时只改了显示名称，忘了改包名；有时入口地址改对了，主题色还是上一个客户的；打包完成后文件名随手写成“客户版最终”，发给客户前还要再确认一遍。三个客户交替改，时间一长，谁也说不清某个 APK 到底是哪一版、给谁打的。

更麻烦的是返工。客户 A 说主题色再深一点，客户 B 说入口页面要换成新活动页，客户 C 说应用名少了一个字。每次调整都要重新找项目、重新打包、重新命名，日志也没有按客户归档。一次发错版本，客户打开看到的是另一个品牌的页面，后面解释成本很高。问题不在改包本身，而在“多版本”没有一套统一的命名、存储和验收规则。

现在：一个客户一个项目，一套规则管三个版本

现在先做一张客户清单，把客户、项目目录、包名、输出前缀、入口页面、主题色和“最新”文件名写清楚。清单不追求好看，追求一眼能核对。三个客户分别使用独立项目，独立 source.apk，独立发布目录；循环任务按客户顺序串行执行，不并行。一个客户的两轮做完、验收完、归档完，再开始下一个客户。

每个客户安排两轮微调。r01 只改主题色和入口页面，r02 只改欢迎文案和图标细节；每轮仍然只引入一个主要变量，附件仍然逐个写清用途。需求模板用同一份，只替换客户名和本轮变量，避免甲客户的需求话术被复制到乙客户时忘了改称呼。触发、等待 ai_done.flag、四步打包、安装验收、改发布名、归档，这七步和活动包实例完全一样。

客户版本的输出名建议把客户名放在最前面，例如“客户A_展示_20261021_r01.apk”。这样在同一个归档盘里，三个客户的文件按名称就能分组，不会混在一起。每个客户的“最新”入口单独命名，例如“客户A_最新.apk”，不要三个客户共用一个“最新.apk”。同名覆盖只在本客户的发布目录里发生，覆盖前先把上一版复制到本客户的归档目录。

三个客户串行执行还有一个好处：测试设备可以复用，但验收记录必须分开。每完成一个客户，就在客户清单里更新“当前最新版本、验收人、验收日期、归档位置”，再开始下一个。不要三个客户同时开 AI 任务，也不要把三个客户的 APK 放进同一个 build 目录。循环打包看起来是重复动作，实际上最怕的就是“图省事”把边界合并。

验证：每个客户都要过“身份、页面、数据、签名”四关

客户版本的验收比活动包多一关“身份”，因为最容易出错的是把甲客户的包发给乙客户。每轮安装后先看应用名和包名，再看入口页面是不是本客户的地址，然后看主题色和欢迎文案，最后确认应用里没有出现其他客户的名称、联系方式或页面。四关都过了，再看签名和版本信息，确认安装的是本轮成品，不是设备上残留的旧版。

如果测试设备上同时装过同一客户的旧版，签名不一致会导致安装失败。处理方式不是反复重试，而是先确认新旧包的签名配置是否一致；如果是测试阶段故意换了密钥，就在记录里写明，并按测试机的实际情况卸载旧版再装。不要把“卸载重装”当成常规操作，正式交付前要把签名策略定下来，避免客户升级时遇到同样的问题。

三个客户都验收通过后，再统一做一次清单核对：客户名、包名、版本名、输出文件、签名证书、验收人、归档位置，一行一个客户。这张清单既可以给内部 review，也可以在客户问“这版是不是最新的”时直接截图回复。循环打包到这里才算真正闭环：不是打了三个包，而是三个客户都能被准确指认、独立回退、随时复查。

十、五条用户评价与合规提醒

下面五条评价来自日常使用类似流程的运营、开发、企业信息化和测试人员，重点不在“工具多快”，而在循环打包之后版本是否更好找、交接是否更清楚。

“以前活动包改到第三版，群里还在传第一版。现在按轮次命名，r01、r02 一眼分清，谁要哪个版本直接发文件名，少解释很多。”
—— 本地生活运营 老周

“我最怕重复点立刻修改，结果同一轮跑出两份改动。后来按流程等 ai_done.flag 被读走、看 pack.log 四步走完再开下一轮，心里踏实多了。”
—— 独立开发者 阿岚

“三个客户三套品牌，以前总担心发串。现在一个客户一个项目、一个发布目录，外加一张清单，交付前逐项打勾，至少不会把 A 的页面发给 B。”
—— 企业信息化 陈工

“同名覆盖确实方便测试脚本取包，但一定要先把旧版归档。我吃过一次亏，最新包有问题，回头发现上一版被覆盖了，只能重打。”
—— 设计转开发 小满

“验收出问题的时候，pack.log 和 apktool.log 比聊天记录有用。哪一步失败、哪一轮装的、签名对不对，翻归档目录就能对上。”
—— 测试工程师 林可

合规提醒：先有授权，再谈效率

循环打包提高的是重复劳动的效率，不是修改权限。请务必确认你对应用拥有自有版权，或已经取得权利人的明确书面授权；只对自己开发、自己运营或客户明确委托的应用做修改。请勿用于破解、绕过安全机制、去除他人应用的合法限制，也不要把改包成品用于冒充官方、欺骗用户或其他违法用途。本文的所有实例都限定在自家应用和已授权客户应用范围内。

多客户版本尤其要注意品牌和数据边界。客户 A 的素材、文案、入口地址不能出现在客户 B 的包里；测试机上的旧数据要及时清理；对外交付前确认客户已经验收。签名密钥和口令要由专人保管，不要写进需求、日志、文件名或聊天记录；归档包对外提供前，先检查是否包含密钥、账号、内部路径等敏感信息。应用分发还要遵守各平台规则和当地法律法规，内部测试版不要随意公开传播。

如果你只是学习改包流程，建议用自己写的练习应用，或在明确授权的测试应用上操作。不要拿别人的商业应用练手，也不要把“能改”当成“可以改”。循环打包的每一轮都应该有边界：改什么、为什么改、给谁用、如何验证、何时停止。边界清楚，效率才是正向的。