安卓修改大师无人值守跑包：一轮结束到下一轮之间发生了什么

改一个包，多数人第一次是一路盯着屏幕走完的：点「立刻修改」，等 AI 跑完，看打包窗口里回编、对齐、签名一行行往下滚，最后在电脑上装上试一遍。这条路走得通，但它有一个前提——你得坐在那儿。

现实里的活往往不是这样。一套包要出八个渠道名，每个名字都要单独签名；一个活动页面要轮着换 banner，今晚十一点换一版、明天上午十点再换一版；一个内部测试包要给十二个人轮流装，每隔两小时得重新生成一次。这些活的共同点是：动作一模一样，只是要重复很多遍。人坐在那儿重复，出错率一定高于机器；人不坐在那儿，机器就得知道一轮结束之后该干什么。

这篇讲的就是那一段：一轮打包结束，到下一轮开始之前，程序到底按什么顺序做了哪些判定。把这段讲透，你才知道为什么有时候它停了、停在哪一步，以及怎么把间隔调到一个既不浪费时间也不互相打架的数值。

一、先把场景说清：什么时候真需要无人值守

判断标准其实很简单：同一个需求要被重复执行三次以上，而且每次的产物都要落盘或上传，就值得配循环。少于三次，你手动点三下的时间比配置窗口的时间还短，没必要。

第一个场景是渠道包。同一份功能改动，要在启动图和关于页上分别挂不同的渠道名，包名也可能不同。人做这件事的错法非常固定：做到第六个的时候忘了改回文件名，第七个直接覆盖了第六个。

第二个场景是素材轮换。运营那边给了一组活动图，要求早上八点、中午十二点、晚上八点各换一版，每版都要重新出包并推到下载页。这类活的特点是你不想为它加班，但它必须准点。

第三个场景是活体测试。测试同事要反复装同一个包的不同版本，每换一次就要重新生成。手工做的话，一小时能出三个已经算快的，而且中间只要有一次忘了签名，装上去就是「解析包错误」，白折腾。

这三种场景对应三种不同的循环节奏：渠道包是跑完就停（跑够八轮自己关），素材轮换是按时间（等 N 秒），活体测试是连着跑（立刻下一轮）。任务设置里那两条调度选项，就是给这三种节奏准备的。

二、「循环打包」这个名字里，后半句才是重点

第一次看到这个勾选项的人，通常会把它读成「打包很多次」。这个理解不算错，但漏了关键的一半。

真正的完整动作是：等 AI 改完 → 打包 → 按规则改名 → 复制到发布目录 → 上传到云存储 → 等一会儿 → 再来一遍。打包只是中间的一步，前后两头才是循环存在的理由。

如果只打包不上传，那循环的意义就是把一堆同名文件堆在本地，你还得自己挑哪个是最新的；如果只上传不按规则改名，云上的文件会被反复覆盖，渠道包就变成了一个包。

所以配循环的时候，顺序应该是反的：先想清楚产物最后要落在哪、叫什么名字，再回头设置打包参数。这一步想不明白，循环跑得越久，收拾起来越麻烦。

三、默认不勾选：一个防误触设计的价值

这个勾选项有一个很克制的细节：参数全部记住，但每次打开详情页，勾选状态一律是空的。

发布目录、文件名规则、云存储地址、调度间隔，这些配好一次就不用再动，程序会把它们存在项目目录里，下次打开原样还在。唯独那个勾，每次都要重新勾。

原因不难猜。循环任务一旦启动，它会自己跑下去，直到你叫停或者出错。如果勾选状态被记住，那么「昨天挂了一夜，今天点开详情页想改一个小地方」这个动作，就变成了一次误启动——你以为只是看看，它已经开跑了。

这个设计牺牲了一点点方便：想跑循环，每次都得手动勾一下。但它换来的是「打开详情页」这个动作永远不会产生副作用。对于一个会在后台自己跑、还会往云上推文件的功能来说，这个交换是划算的。

同一类思路在别处也有：参数面板里那个「测试上传」按钮，也是要求你每次主动点，不会在你保存设置的时候偷偷试一次。凡是会往外发东西的动作，都不做成隐式的。

四、任务设置窗口：五个分组，一张表看完

点开「任务设置」之后，窗口里的内容按分组排，一共五块。这五块的分工是清楚的，没有重叠：

这五块的填写顺序建议是：发布方式 → 发布目录 → 发布文件名 → 测试上传 → 任务调度。先定终点，再定路径，最后定节奏。反过来填的话，很容易出现「文件名规则配好了，结果发现目标存储根本不支持这种命名」的返工。

窗口里还有一处做得挺细：文件名区域会有下一个文件名的实时预览。你不用等第一轮跑完才知道规则对不对，改一个字符，预览就跟着变。这个预览比任何文档都直观。

五、发布目录：不存在就建，建不了就停

发布目录是循环的第一站。它的行为和大多数人的预期一致：路径不存在时自动创建，不需要你提前手工建文件夹。

但有一类情况它会直接失败：目录存在、但当前账户没有写权限。比如你把发布目录指到了某个受管目录、或者指到了一个已经被别的程序占用的网络盘。这种失败不会等到上传那一步才暴露，而是在复制产物的时候就会报出来。

这时候循环会停，原因会写进详情页、打包窗口和提示窗口三个地方。这一点很重要：它不会「跳过这一轮继续跑」。因为一旦允许跳过，你就会得到一个跑了一整夜、实际只成功了两轮的循环，而你在早上看到的是「第 47 轮已发布」这种让人安心但实际上错误的信号。

宁可停在第一个失败上，也不要给出一个看起来在工作的假象。这是整个循环设计里最一致的一条原则。

六、文件名规则：四条分支和它们的优先级

文件名规则看起来是一堆小开关，实际上它是一棵四层的判断树。把顺序记住，就不会配错：

这棵树里最容易踩坑的是第二层和第三层的交界：前缀以 .apk 结尾时，后面所有规则都不生效。有人写了前缀 channel_main.apk，同时又勾了时间戳，结果发现文件名永远是 channel_main.apk，以为是时间戳坏了。其实是被第二层拦住了。

这个设计不是随手写的。以 .apk 结尾的前缀，语义上就是「我要一个确定的名字」，这种情况通常用于固定下载地址——下载页上挂的就是 xxx.apk，多一个时间戳反而会让链接失效。

七、时间戳优先于数字后缀：一个容易被忽略的排序

时间戳和数字后缀都能让每轮的产物不重名，但它们的性质完全不同，程序里的优先级也是定死的：只要勾了时间戳，数字后缀就不参与命名。

时间戳用的是当前时间的 Unix 毫秒数。好处是天然有序、绝不会重复、事后按文件名排序就是时间顺序。坏处是文件名很长，而且不适合做固定下载地址。

数字后缀是 1 到 N 循环，好处是名字短、可预测、适合做多个固定入口；坏处是会覆盖——第 N+1 轮会回到 1，把第一轮的文件顶掉。

这个覆盖特性在很多场景下是优点而不是缺点。比如你要维护八个渠道的下载入口，每个入口的地址写死成 ch01.apk 到 ch08.apk，循环跑到第九轮时正好刷新第一号，云上的八个地址永远有效，永远是最新的包。

但如果你要的是留档——每一版都要能找回来——那就必须用时间戳，而且要把数字后缀个数清成 0。两个都勾着的结果是时间戳赢，数字后缀白配，计数器也不推进。

补零长度这个小参数，只在数字后缀个数大于 9 的时候才有存在感。八个渠道不用管它；一百个文件的时候，补零到三位，文件名按字典序排出来才是 001、002、…、100 的正确顺序，不补零就会变成 1、10、100、11 这种排序，人工翻起来很难受。

八、计数器存在哪：重启之后接着轮换

数字后缀的当前值不是内存里的一个变量，它被写进了项目目录下的任务参数文件里，键名就叫计数器。

这个设计解决了一个很实际的问题：你不希望重启程序之后，八个渠道的轮换从头开始。如果计数器在内存里，那么每重启一次，第一号就被覆盖一次，第二到第八号永远是旧的。跑上一个月，你的下载页上就是「一号最新、其余过期」这种奇怪的状态。

写进文件之后，重启接着数。这一点和「循环不会在重启后自动续跑」并不矛盾：进度会被记住，但任务不会自己重启。你重新勾上、重新点「立刻修改」，它会从上次停下的那个号继续。

同一份参数文件里还存着发布目录、文件名规则、云存储的连接参数和调度间隔。这也是为什么详情页那个勾默认不勾——参数都在，只有启动意图每次都要重新表达一次。

九、发布方式：十种去处，字段跟着选择变

发布方式这一栏列了十种：本地发布目录、阿里云 OSS、亚马逊 S3、腾讯云 COS、华为云 OBS、百度云 BOS、Minio、金山云 KS3、七牛云，以及 FTP。

选哪个，下面才出现哪个的字段。选本地目录只要一个路径；选对象存储会多出 Endpoint、Bucket、AK、SK、Region；选 FTP 则是主机、端口、账号、密码和远端目录。没有被选中的那些，字段根本不显示。

这种「跟着选择变」的界面，比把所有字段平铺出来要省心得多。平铺的界面会让你不确定哪些是必填的，而且很容易把 OSS 的 Region 填到 COS 的框里。

九种云存储加一个 FTP，覆盖了国内做分发时最常见的那几种情况。如果你的存储不在这十种里，退路是「本地目录」：把发布目录挂成一个同步盘的本地路径，让同步客户端去上传。这条路多一层，但循环本身照样跑得通。

选择的时候还有一个容易被忽略的点：上传是覆盖同名的。这句话对固定文件名是优点（用户永远下到最新的），对时间戳命名则意味着「同名不可能发生」，两种情况下都不会出问题。真正需要小心的是在多台机器上配同一个 Bucket 和同一个前缀——两台机器各自跑循环，就会互相覆盖。循环任务是单机的，它不知道隔壁还有一台在往同一个地方推。

十、测试上传：循环开始前唯一一次真正的握手

这个按钮的名字起得很朴素，但它做的事很关键：拿当前填好的参数，真刀真枪地上传一次。

注意它的三个限定：按原文件名上传、不复制到发布目录、不推进计数器。也就是说，它只验证「这些参数能不能把文件送上去」，不产生任何业务副作用。你随便挑一个小文件传一次，成功了再去勾循环；失败了就在这里改，不用等第一轮跑完才发现 AK 写错了。

为什么一定要在循环之前做这件事？因为循环的失败处理是「停下来」，而不是「重试」。如果 AK 填错，你会在第一轮就停住，损失不大；但如果你是在深夜挂机、人不在电脑前，那这一夜就是白挂的。一个十秒钟的测试，换一整夜的时间，这笔账很好算。

测试上传还会暴露一类不报错但很烦的问题：路径对、权限对、传上去了，但传到了一个你不想要的位置。比如远端目录多写了一层，文件跑到 /apk/apk/ 下面去了。这种事只有真传一次才看得见。

十一、调度：两条路，节奏完全不同

任务调度只有两个选项，看起来简单，但它决定的东西比想象的多。

第一条：打包并上传完毕后立即开始下一轮。适合做活体测试包、适合反复生成看效果、适合把一组素材连着跑完。它的节奏是「机器能跑多快就跑多快」，一轮接一轮，中间几乎没有间隙。

第二条：打包并上传结束后等待 X 秒再开始下一轮。适合素材轮换、适合给测试同事留出安装的时间、也适合那些「改一次要等一会儿才看得出效果」的场景。

为什么不等「X 分钟」而是「X 秒」？因为很多真实需求是按几十秒算的：换一张图重新出包，等 30 秒足够测试同事装上看一眼；等 5 分钟就太长了，你的注意力早就跑了。用秒做单位，粒度够细。

倒计时期间是有界面的：打包窗口里能看到还剩多少秒，也可以直接点停止。这一段不是黑盒等待，这一点比很多同类功能做得踏实。

十二、一轮的六个动作：状态机里到底有什么

把循环拆开看，一轮就是六个动作按固定顺序执行，任何一个失败都会终止整个循环：

这六步里，前两步（等 AI、打包）和手动操作时用的是同一套代码。循环没有另起一套打包流程，它只是把「点按钮」这个动作换成了「等标志」。这一点决定了循环产物的质量和手动操作完全一致——你在循环里拿到的东西，和你坐在电脑前一个个点出来的是同一种东西。

第五步里那句「打包窗口保持打开」，是给无人值守留的一只眼睛。很多人挂循环的时候会隔一会儿瞟一眼屏幕，看到窗口里那行「第 N 轮已发布」，就知道它还在正常工作。如果窗口是关着的，你就只能靠时间去猜，反而更焦虑。

十三、那个被删掉的残留标志：为什么每轮开始前要先清一次

AI 改完会留下一个完成标志文件。循环靠它判断「这一轮可以打包了」。

这里有一个必须处理的问题：上一轮留下的标志，如果不删，下一轮一开始就会被误判成「已经改完了」。结果是 AI 还没开始跑，程序就去打包了，打出来的是上一轮的旧产物，然后上传、发布，一切看起来都很正常。

这种错误最恶心的地方在于它不报错。你会在第二天早上看到一条漂亮的发布记录，然后发现云上那个包的版本号和昨天一样。

所以循环在每一轮开始之前，会先把残留的标志删掉，再发需求。这是一个只有两行代码的动作，但它挡住的是最难排查的一类问题——看起来成功了，其实什么都没做。

十四、第一轮和之后每一轮，有两处不一样

循环里唯一「只做一次」的事情有两件：写需求历史、扣额度。这两件都发生在第一轮把需求发出去的那一刻。

为什么不每一轮都写历史？因为循环的每一轮用的是同一段需求原文，写第二遍只是把同样的内容重复堆进历史列表，下次你翻这个项目的历史，会看到几十条一模一样的记录，反而找不到真正改过什么的那几次。

为什么不每一轮都扣？因为从计费角度看，跑十轮和跑一轮是同一件事被重复执行，把额度消耗和「一次需求」绑定，比和「一次产物」绑定更符合直觉。

这两个选择都指向同一条设计取向：循环是「一次需求的多次执行」，不是「多次需求」。理解这一点，后面所有的行为都变得可预测了。

十五、三种失败，同一种处理

循环会在三种情况下停下来：打包失败、发布失败、AI 等待超时。

三种失败的性质完全不同，但处理方式是一致的：立刻停止循环，并把原因写出来。

打包失败通常意味着工程本身有问题——回编报错、资源缺失、签名参数不对。这种错不会因为多跑两轮就自己好，继续跑只是把同一个错误重复二十遍。

发布失败通常是环境问题——网络断了、AK 过期、远端目录没权限、磁盘满了。停下比继续有意义，因为继续也传不上去。

AI 等待超时则是一个边界判定：等了足够久还没完成，就认为这一轮没戏了。这个超时是有意义的，因为如果不设，一个卡住的任务会让整个循环永远悬在那里，你以为它在跑，其实它早就停了。

三处失败的提示会同时出现在详情页、打包窗口和提示窗口。为什么要在三个地方都写？因为你不知道用户此刻在看哪个窗口。挂机的人可能在看详情页，可能在看打包窗口的滚动日志，也可能刚切回桌面只看到一个弹窗。

十六、停止任务：四个入口，一个结果

无人值守的功能最怕的是「停不下来」。这个循环给了四个停止入口，分布在四个你可能会在的位置：

这四条的语义是一致的：本轮已经开始的打包或上传会先收尾，之后不再发布、不再开始下一轮。不是「立刻掐断」，而是「把手上的这一件做完再停」。

这个选择有代价，但代价是合理的。如果点下去就硬断，你可能得到一个传到一半的文件——云上留着一个残缺的对象，比没有更麻烦。让它把这一轮走完，你至少知道云上那个文件是完整的，只是不再有下一轮了。

还有一条细节值得说：在详情页取消勾选，只停这个项目的循环，别的项目不受影响。这个「只停自己」的判定看起来是废话，但如果你同时挂了三四个项目的循环，这条规则就是安全绳——你不会因为在 A 项目上点了取消，把 B 项目的夜间任务一起干掉。

十七、关掉打包窗口，去干别的

发布和等待下一轮的这段时间，打包窗口是可以关掉的。关掉之后，顶部状态栏会出现一个「循环任务中」的提示。

这个设计解决的是一个心理问题：打包窗口是个模态感很强的窗口，它开着的时候你总觉得电脑被占着。实际上这段时间程序只是在上传文件、在等倒计时，不吃你的鼠标键盘。

关掉它，你就能去改另一个项目的素材、能去看日志、能开浏览器查资料。而状态栏那行字是一个低干扰的提醒：还在跑，别关机。

想停的时候点那行字，窗口回来，按钮还在原位。这个来回不需要你记住任何快捷键或者路径，符合「挂机的人随时可能回来」这个真实状态。

十八、五条边界和一条不能存

任何自动化都有边界，把边界写在前面，比事后解释要诚实得多。这个循环的边界有五条：

第一，程序退出就结束。循环活在主程序里，不是系统服务。关掉程序，循环就没了。

第二，项目被删就结束。产物要往项目目录里落，项目没了自然跑不下去。

第三，工作目录不可写就结束。这通常发生在目录被别的程序占用、或者权限被改过的时候。

第四，重启之后不会自动续跑。勾选状态会还在，参数也还在，但要你重新点一次「立刻修改」。

第五，同一时刻不处理多台机器。它不知道别处还有谁在往同一个 Bucket 推东西。

这五条里，第四条最容易被误解成缺陷。但从安全角度讲，一个「开机自动开始往云上推文件」的程序，在你不记得自己配过它的时候，是相当可怕的东西。要求人工确认一次，是正确的取舍。

至于那条不能存的——云存储的 AK 和 SK 是明文保存在项目目录里的。这句话必须写在这里，因为它直接决定了一件事：不要把项目目录打包发给别人。你要给别人看效果，发那个 apk；要给别人看工程，先清掉任务参数里的密钥。

十九、实例一：一套包要出八个渠道名

这是循环最典型也最省事的用法。需求是这样的：同一个功能改动，要在八个渠道各出一个包，文件名分别是八个固定的英文名，都要上传到同一个 Bucket 的同一个目录。

过去怎么做：改完第一个，打包，手动重命名成第一个名字，上传；然后回去改第二个名字，再打包，再重命名，再上传。八轮下来大概四十分钟，中间还要不停确认「我现在改的是第几个」。做到第六个的时候，几乎一定会有一轮忘记改文件名。

现在怎么做：先把八个名字的需求一次性说清楚，比如「启动页标题改成渠道名，关于页也加一行渠道标识，八个渠道分别是 A、B、C……」，然后在任务设置里把前缀填成不带 .apk 的公共部分，数字后缀个数填 8，补零长度填 2，发布方式选对象存储，把 Bucket 和目录填好。

先点一次测试上传，确认权限和路径没问题。然后勾上循环，点「立刻修改」。

第一轮跑完，打包窗口里出现「第 2 轮已开始」，倒计时结束自动进入下一轮。八轮之后你得到八个文件，名字从 01 排到 08，一个不多一个不少。

改完怎么验证：进发布目录，按名字排序，数一下是不是八个；挑第一个和最后一个各装一次，看启动页和关于页上的渠道标识对不对得上。这两个验证动作花不了三分钟，但它们能挡住「八个包内容其实全一样」这种最难发现的错。

二十、实例二：夜里换一组 banner 图

第二个例子更适合说明「等 N 秒」这个调度的价值。

需求是：一组五张活动图，每张都要单独出一版包，出完立刻推到一个固定下载地址，测试同事会在这几个小时里陆续装上比对。

过去怎么做：改一张，打包，上传，然后在群里说「第二版好了」；过一会儿再改第三张。整个流程被人的注意力切得七零八落，而且经常出现「图换了但包没重新打」的情况——用户装上去看到的还是上一张。

现在怎么做：把五张图对应的需求写成一段话，说明「每轮换一张，按顺序来」，发布方式选本地目录加云存储，文件名用固定名（前缀带 .apk 结尾），这样云上那个地址永远指向最新一版。调度选「等待 X 秒再开始下一轮」，X 填一个让测试同事来得及装上的数值。

这样跑起来之后，云上那个固定地址每隔一段时间就自动刷新一次，测试同事只要反复点同一个链接，就能拿到不同版本。整个过程没有人需要盯屏幕，也没有人需要在群里报数。

这里的关键是固定文件名。如果用了时间戳，每轮都会生成一个新地址，测试同事就得每次问你要新链接，那这个自动化就只省了你一半的事。

二十一、手机上能不能跑循环：边界要说清

这是被问得最多的一个问题。答案是：循环任务属于电脑版的能力，手机端不跑这个状态机。

道理不复杂。循环要做的事是「等标志 → 调打包工具 → 改名 → 复制 → 上传」，打包那一步依赖一套完整的构建链，这套东西在桌面上跑得稳，搬到移动端就是另一回事了。

但手机上真正省事的地方在别处：把需求说清楚这件事，在手机和平板上做更顺。你在地铁上想到一句「启动页那张图换成深色版本，标题字再大一点」，掏出平板说一句，需求就落到项目里了。回到电脑前，要做的只是勾一下循环、点一下开始。

所以合理的分工是这样：需求在移动端说，循环在桌面上跑。这个分工承认了两种设备的强项——移动端强在随时随地能表达，桌面端强在能长时间稳定干活。

安卓修改大师智改工坊在两端做的是同一件事：把人话变成改动，把改动变成包。只是「连续不断地把改动变成包」这一段，交给了更合适的那个平台。

二十二、间隔设多少：三个可以直接抄的经验值

「等 X 秒」这个数值没有标准答案，但有三档可以照着起步：

三十秒。适合「换一张图看看效果」这类场景。出包本身用不了这么久，剩下的时间是留给你装上、打开、看一眼的。如果你在看的时候它已经开始下一轮了，说明设短了。

一百二十秒。适合给测试同事轮流装的场景。两分钟够一个人装完、点两下、发现一个明显问题并在群里说一句。再短的话，群里会出现「我刚装的那个是第几版」这种问题。

三百秒以上。适合素材按时段轮换的场景。这个量级已经不是「等技术跑完」，而是「等时间到点」，你需要的是让它慢一点，别在你还没准备好素材的时候就跑过去了。

还有一个反向的判断方法：如果你发现自己总在倒计时快结束时手忙脚乱，那就是设短了；如果你发现自己总在等它、盯着数字跳，那就是设长了。这两个感觉比任何表格都准。

二十三、失败之后去哪儿看：三个地方，各有各的用处

循环停下来的时候，原因会同时写进三个地方。它们不是重复，而是给三种不同的查看习惯准备的。

详情页。这是你回到这个项目时第一眼看到的地方，适合「过了一夜，先看看怎么样了」。原因会挂在那儿，不用翻日志。

打包窗口。这里是从头到尾的过程记录，适合「我知道失败了，想看它走到第几步」。回编、对齐、签名、上传各占一段，断在哪一段一目了然。

提示窗口。这是当时那一下的提醒，适合「人就在电脑前，需要立刻知道」。它的作用是打断你，而不是供你事后查。

三个地方各写一份，看起来有点啰嗦，但真实的排查路径就是这样：先在详情页看到「失败了」，再打开打包窗口看「断在哪一步」，最后回到提示窗口确认「当时弹的是不是这个消息」。

二十四、别用它做的三件事

边界讲完之后，还要讲三条红线。这三件事不是「做不好」，而是「不该用它做」。

第一，别用它做需要人工确认的发布。循环的设计是「跑下去直到停」，它没有「等我审核再继续」这种环节。如果每次出包都要人看过才能上架，那它就不该配循环。

第二，别用它绕过该有的验证。循环能连着出二十个包，但它不负责告诉你这二十个包对不对。打包成功只代表文件生成了，不代表功能正确、不代表没有崩。验证这一步永远不能自动化掉。

第三，别把密钥和项目目录一起发出去。这一条前面提过，这里再强调一次，因为它是最容易发生也最难挽回的一种。

这三条之外的场景，基本都可以放心交给循环。它擅长的是重复、准时、不偷懒，这三样恰好是人最容易出错的三个地方。

二十五、配循环之前，过一遍这张检查单

第一次配循环的时候，按下开始之前把这七条过一遍，能省掉大部分返工：

这七条里，第六条最容易被跳过。配好了、跑起来了、人走了，然后第二天发现跑了一整夜——如果你提前知道自己能在哪儿停，这种事故的概率会低很多。

二十六、从「改一个包」到「守住一条流水线」

把这一篇和前几篇连起来看，会发现一个很清晰的层次：先是能改，然后是能改对，最后是能一直改对。

能改，靠的是把需求翻译成具体的改动——说一句「标题大一点」，程序知道那是字号从 14 到 16，而不是把整段文字放大。

能改对，靠的是出包四步一步都不省——回编、对齐、签名、校验，少一步都会在装机那一刻暴露。

能一直改对，靠的才是循环：把前面两步固定下来，交给机器一遍遍执行，人只在开始和结束的时候各出现一次。

这也是「只需说话，就能让应用变成你想要的样子」这句话在长时间尺度上的样子。说的那一下依然是人，但说的结果会自己重复、自己落盘、自己上传，不需要有人守在旁边。

二十七、几个常被问到的细节

问：循环跑到一半，我改了需求怎么办？答：循环用的是第一轮发出去的那段原文，中途改需求不会影响正在跑的轮次。要换需求，先停，再改，再重新开始。

问：跑完八轮之后它会自己停吗？答：不会。除非你在第八轮的时候点停止，否则它会继续按规则出第九个、第十个。数字后缀会转回 1，覆盖掉第一个。要限定轮数，得靠自己盯或者设置一个合适的间隔。

问：本地目录模式还需要网络吗？答：不需要，本地模式只保存不上传。这也是它在弱网环境下的用法。

问：能不能同时挂两个项目的循环？答：可以，停止是分项目的。但要注意别让它们往同一个云目录推同名文件。

问：中途关掉电脑会怎样？答：程序退出就等于结束循环。已经发出去的那一轮可能停在半路，下次打开需要重新点「立刻修改」。

这些细节都不复杂，但它们决定了你在凌晨三点被叫起来的时候，能不能三分钟内判断出发生了什么。

写在这一轮之后

无人值守这件事，说到底是把「重复」从人的工作里拿掉，而不是把「判断」拿掉。循环负责一轮接一轮地跑，人负责在开始之前想清楚要什么、在结束之后看一眼对不对。这两件事分清楚，机器才不会替你做错决定。

合规提醒：循环批量出包只适用于你自己拥有或已获得授权的应用。修改他人应用、绕过授权校验、去除付费限制都属于侵权行为，可能违反《著作权法》《计算机软件保护条例》与《网络安全法》；分发时请遵守各应用市场与云存储服务商的规则，不要用自动化手段批量投放违规内容。

把一段需求交给机器重复执行，前提是这段需求本身说得足够清楚。只需说话，就能让应用变成你想要的样子——而说清楚这件事，永远是人的活。

安卓修改大师智改工坊把改包之后那一串动作收在同一个界面里：说一句话，改完自动回编、对齐、签名，还能装回手机看一眼再交付。官网是 www.apkeditor.cn，产品介绍页 https://www.apkeditor.cn/ai-version.aspx。