无人值守也会遇到的事：智能修改电脑版循环打包的六种情况

先说一个很具体的场景。晚上十一点，项目里的需求已经调到满意，你把「循环打包去毒」勾上，设了 20 轮，命名规则选"前缀 + 数字后缀、补零"，发布目录指向 D 盘一个专门的文件夹，云存储的 Bucket 和密钥都填好了，点了「立刻修改」，然后关灯睡觉。

第二天早上打开电脑，发布目录里躺着 14 个包。第 15 个没了，后面全没了。这一刻你要回答的其实不是"软件怎么了"这种大问题，而是三个很小、很具体的问题：断在第几轮、为什么断、剩下的还要不要接着跑。

这篇文章讲的就是这三个问题。顺带讲一件更要紧的事：在无人值守这件事上，"能自己停下来"比"从不出错"重要得多。

本文的对象是安卓修改大师智改工坊旗下的 智能修改电脑版：当前版本 V1.9.0.0，大小约 7.01MB，支持 Windows 10 / 11，免安装、解压即用，更新日期 2026-10-24。产品介绍页在 https://www.apkeditor.cn/ai-version.aspx，官网 www.apkeditor.cn 上同时挂着智能修改安卓版与修改大师经典版。

一、先把"无人值守"拆开：省掉的是守着，不是判断

"无人值守"这四个字很容易被误读成"不用管"。它实际省掉的是一串重复动作：盯着进度条、等 AI 改完的标志、看到弹出打包窗口再点下一步、打包完去复制产物、复制完去上传、传完再开始下一轮。这套动作重复二十遍，人的注意力就被钉在椅子上了，什么事都干不了。循环打包替你干的就是这一串。

它没有替你干的是判断。判断包括：这一版的改动到底对不对，要不要就这么发出去；这一轮失败的原因是需求写歪了、素材没给全，还是这个包本身就有边界；剩下 6 轮要不要接着跑；云存储密钥失效是一次网络抖动，还是权限被管理员收走了。这些问题，工具答不了，也不该答。

所以这一篇的立场很明确：自动化省的是人守着的时间，不是人判断的责任。循环打包真正的价值，是你能在它跑的时候去睡觉、去带孩子、去处理别的事，回来之后再判断；而不是你可以彻底不看结果。前者是效率，后者是事故的开始。

还有一层常被忽略的前提：循环能连跑二十轮，靠的不是"每轮都成功"，而是"每轮失败时损失有边界"——一轮失败最多让你少一个包。

关于正常路径——循环的状态怎么推进、五种发布文件名规则怎么选、九种云通道怎么配——那是另一篇文章的事（t1-06 讲的是调度与命名）。这一篇只管异常：出事的时候会发生什么、你怎么知道、怎么把它拉回来。两篇合起来才是一次完整的无人值守。

二、先立一个基准：一轮循环的正常时序，和它身上的三个接缝

要讲异常，得先知道"正常"长什么样。一轮循环走五步，顺序是固定的，中间没有并行。

1. AI 改完这一轮。你点「立刻修改」之后，需求送进右侧的 AI 工作台执行。改完，AI 会在项目目录里留一个标志文件 ai_done.flag。主窗口每 2 秒轮询一次，读到就删掉，并弹出打包窗口。等待有上限：1 小时，超时会明确告诉你"已停止等待"。
2. 自动打包四步。回编（apktool b -f）→ 对齐（zipalign -f -p 4）→ 签名（apksigner + 内置签名）→ 校验（apksigner verify --print-certs）。产物依次落在 build\unsigned.apk、aligned.apk、signed.apk，全过程写进 pack.log。第四步不省：前三步只看退出码，"到底签没签上"要 verify 说了算。
3. 按命名规则保存到发布目录。前缀留空就沿用原名；前缀以 .apk 结尾就是固定名（同名覆盖）；也可以前缀 + 毫秒时间戳，或前缀 + 数字后缀循环（可补零），还能选转大写。
4. 上传云存储。阿里云 OSS、亚马逊 S3、腾讯云 COS、华为云 OBS、百度云 BOS、Minio、金山云 KS3、七牛云、FTP，或者干脆只存本地。
5. 立即开始下一轮，或者等 N 秒再开始。计数器往上走一格，回到第 1 步。

这五步里有三个"接缝"，值得单独标出来，因为六种异常几乎都发生在接缝上：

• 接缝一：AI 与打包之间。靠一个标志文件交接。标志不来，打包就不该开始——这是设计上最重要的一条纪律，后面还会讲。
• 接缝二：打包与保存之间。包已经在 build 里了，要搬到发布目录去。这一步失败，包还在，只是没搬过去。
• 接缝三：保存与上传之间。本地有了，要过网络和凭据这一关。这一关最不受你控制。

把六种异常按接缝归一下位，你会发现问题比想象中整齐：

异常	卡在哪一步	这一轮的包会出去吗	第一眼判据
AI 这一轮改失败	接缝一之前，根本没到打包	不会，也不会污染	等待窗口不动，标志文件不来
磁盘写满	打包中途（写 build 时）	不会，产物可能残缺	pack.log 尾部写入失败，盘剩空间见底
发布目录不可写	接缝二（保存）	不会，但包里已有成品	build 里有 signed.apk，发布目录没新文件
云存储密钥失效	接缝三（上传）	本地有，云端没有	本地文件数与云端对象数对不上
程序被关掉	任何一步，整条链断掉	这一轮不完整，编号会跳	error.log、进程消失时间、编号断点
项目被删除	每一轮都会失败在"找不到路径"	不会，且会连续失败	项目列表里没有它，目录不存在

这张表最值得看的是第三列：六种里有五种，这一轮的包根本不会出去。这不是巧合，是串行设计的直接结果——上一环没成立，下一环不会带着病往下走。所以才会说"损失有边界"。

三、异常一：AI 这一轮改失败

这是六种里最常见的一种，也是最容易被误判的一种。

会发生什么。AI 没能把这一轮改完，项目目录里就不会出现 ai_done.flag。主窗口还在每 2 秒轮询一次，界面上看起来就是"一直在等"。打包这一步压根没开始，所以 build 目录不会有新产物，发布目录不会有新文件，云上更不会有。等到 1 小时上限，界面会明确写出"已停止等待"——注意这句话的含义：它不是说"改失败了"，而是说"我不再等了"，判断权交回给你。

为什么会这样。常见的原因有五类：需求本身不可执行（比如让它改一个这个包里根本不存在的页面）；附件没给全或说明太短，AI 拿不到要用的素材；工程在上一轮被改出了结构性问题，这一轮一开始就崩；改动范围太大，超出了能稳定完成的程度；以及最朴素的一类——这一轮确实出了意外，没有任何产出。

怎么发现。有四条判据，从软到硬：

• AI 等候窗口一直停在等待状态，时间越过了你预估的单轮耗时还不动。
• 项目目录里没有新的标志文件（这个文件在被读到后会立刻删除，所以"没有"有两种可能：还没来，或者已经来过了。要看下面两条来区分）。
• apktool.log 没有新内容。反编译与回编的输出都在这里，没有新内容说明这一轮连回编都没走到。
• pack.log 没有新增段落。打包全过程都写在这里，没有新段落，等于这一轮从未打包。

这里有一个特别容易踩的坑，值得单独说：修改历史里有这一轮的需求记录，不等于这一轮改成功了。需求原文是在你点「立刻修改」的那一刻就写进 history.ini 的，那一刻 AI 还没开始干活。所以早上翻历史，看到"第 15 条：把启动图换成附件这张"——这条记录只能证明你发过这个需求，不能证明它被执行完了。要看的是标志文件、apktool.log、pack.log 这三样。

怎么恢复。顺序建议是：先按「停止任务」，让当前这一轮收尾（而不是让它继续空等到上限）；然后到 AI 工作台看这一轮到底输出到哪一步，是有报错、还是无产出；再判断问题出在需求侧还是包侧。需求侧的修法很直接——把范围缩小、把位置说具体、把素材补齐，重发一次。包侧的修法要谨慎——如果连续两三轮都失败在同一个位置，别急着加轮数，先把这个包单独拿出来跑一轮，看它能不能改成功。

这一类异常最值得安心的一点是：它是一次空转，不是一次污染——没有产物出去，没有半成品覆盖掉好包，编号也没往前走。它浪费的是时间，不是数据。

四、异常二与三：磁盘写满、发布目录不可写

这两种放在一起讲，因为它们都发生在"写文件"这件事上，表现也容易混。

磁盘写满会发生什么。回编要把整个工程重新打成包，对齐要再写一份，签名还要再写一份——一轮下来，build 目录里同时躺着 unsigned、aligned、signed 三个文件。盘不够的时候，最可能断在回编写 build 的中途，也可能断在对齐那一步。pack.log 里会出现写入失败的痕迹，build 里的产物可能是缺的、也可能是 0 字节的。

这里有个很关键的设计细节要说清：自动挑盘只在启动时做一次。软件启动时会按 D→E→F→G→C 的顺序找盘，取第一个可读写、且剩余空间不小于 1GB 的盘，拼成 <盘符>:\AiApkEditor，tools 和 Project 两个子目录都在下面。但循环跑起来之后，盘满了他不会自己搬家——它不是不知道盘满了，是"搬家"这件事本身需要停任务、需要你确认新路径。所以这个判断得你来做。

实操上给一个粗算的方法：开工前按"轮数 × 单包体积 × 3"估一遍剩余空间。乘 3 是因为一轮里 build 目录要同时存在三个 APK，外加发布目录的成品和反编译出来的工程目录。20 轮、单包 30MB，留 2GB 以上才踏实。这个估算不需要精确，它只需要让你在点「立刻修改」之前看一眼盘的剩余空间。

怎么发现。三条：任务管理器或资源管理器看盘的剩余；pack.log 尾部看最后一段是不是完整的四步；build 目录里 signed.apk 在不在、大小对不对。

怎么恢复。先停，再清，再跑。清的时候有个优先级：已经交付完的旧项目（Project 下那些 8 位随机字符串目录）、发布目录里已经上传过云端的旧包、build 目录里的中间产物、以及盘上别的临时文件。清完确认剩余空间，重新点「立刻修改」。如果这一轮没走完，计数器不会前进，所以编号不会跳——这一点在下面讲计数器时还会提到。

发布目录不可写会发生什么。这一步的性质和前一种完全不同：包已经打好了，签也签过了，verify 也过了，就差"搬过去"。搬失败的原因通常是这几类：目录被删掉或改了名；目录指向了一块移动硬盘或者网络盘，而那块盘不在了；目录被设成了只读；路径太长或者带了特殊字符；被安全软件拦了一下。

怎么发现。这一种有一个特别干净的判据：build 里有 signed.apk，发布目录里没有新文件。两个条件同时成立，基本可以断定是"保存"这一步的问题，而不是"打包"的问题。这个判据比看报错快得多，因为它不需要你读懂任何一条错误信息。

怎么恢复。先把 build 里的成品手工取出来——这一轮的劳动不该白费，尤其当它是你调了好几版才满意的那一轮。然后修目录（重建、换回本地盘、去掉只读），再放开循环。建议发布目录放在本地固定盘上：循环跑一整夜，中间任何一次盘符消失，都会让后面所有轮次失败在同一个地方。

五、异常四：云存储密钥失效

这一种最"阴"，因为它不影响你本地看到的一切。

会发生什么。AI 改完了，打包成功了，本地发布目录里也有包了——一切看起来都正常。只有上传那一步失败了。远端看不到新对象，本地该有的都有。如果循环的顺序是"上传完才进下一轮"，它会停在这里；如果顺序允许跳过，它会继续出包但一个都没传上去。这两种情况都不算灾难，因为最贵的那部分劳动（改包与打包）保住了。

"密钥失效"其实有四种常见形态，表现一模一样，原因完全不同：

形态	典型原因	怎么确认
密钥被轮换或删除	管理员定期换密钥，旧的那对失效了	用同一个密钥手工传一次，也失败
权限被收回	子账号策略调整，写权限没了	能列出对象但上传被拒，是典型的权限问题
临时凭证过期	用的是有时效的临时密钥	之前一直好，某个时刻之后全失败
配置项填错	Bucket 名、区域、Endpoint 对不上	从头就没成功过，一次都没传上去

最后一行值得留意："从头就没成功过"和"以前好过、现在不行"是两条完全不同的排查路线。前者是配置问题，去看你填的那几个字段；后者是凭据或权限问题，去问管账号的人。搞清楚这一点，能省掉一半瞎试。

怎么发现。三个层次，从粗到细：

1. 看云控制台。对象列表里最新的几个文件的时间戳停在什么时候。停在昨晚十一点，说明从那一刻起就没再传上去过。
2. 对数量。本地发布目录里有多少个 APK，云端对应前缀下有多少个对象。这个数目对不上，就是上传通道的问题，不用再往下猜。
3. 看软件侧的上传反馈。循环界面会给出上传这一步的结果，权限类失败和网络类失败的表述是不一样的。

怎么恢复。四步，不要跳步：重新签发一对密钥（只给这一个 Bucket 的写权限，别用主账号的全权限密钥）；更新配置；先用软件里的"选一个文件真实上传一次测试"把通道验通；验通之后再放开循环。第三步是最容易被跳过的，也是最不该跳的——把一个没验过的密钥直接丢进 30 轮的夜里，你得到的只是"明天早上再发现一次"。

再补一句安全上的话：密钥这种东西，最小权限是底线。为上传一个发布目录专门开一个子账号、只授权这一个 Bucket 的写，比图省事用主账号密钥要好得多。真出了问题，能一键换掉、影响面可控，这本身就是运维的一部分。

六、异常五与六：程序被关掉、项目被删除

这两种都属于"外部动了手"，区别是一个动的是程序，一个动的是项目。

程序被关掉会发生什么。原因很多：任务管理器里点了结束、系统更新重启、笔记本合盖睡过去被强杀、停电。结果是当前这一轮停在半路——可能停在等 AI，可能停在打包，也可能停在保存。已经完成的轮次和它们的产物都还在，缺的只是这一轮。

重开之后有三件事要确认，第一件特别重要：

• 看项目目录里有没有残留的标志文件。如果上一次是在"AI 已经改完、还没被打包窗口读到"的瞬间被关掉的，ai_done.flag 会留在那里。重开之后主窗口一读到它，就会删掉并弹出打包窗口——你看到的是一个"AI 刚改完"的信号，但它其实来自上一次。判断方法很朴素：看文件时间戳，再看历史里最新那条需求是不是这一轮的。宁可多看一眼，也不要稀里糊涂打一个上一轮的包出去。
• 看计数器停在哪。计数器存在项目目录的 loop_task.ini 里，重启之后接着轮，不会从 1 重来。所以编号不会撞、不会覆盖上一批。
• 接受"少一轮"。被掐断的那一轮不会自动补做。20 轮里第 15 轮断了，重开之后从第 16 轮接着，总数变成 19 个包。这不是 bug，这是"不做假账"——它没有假装那一轮完成了。

怎么恢复。重启软件 → 检查标志文件残留 → 确认计数器 → 重新勾上循环、点「立刻修改」，从下一轮接着走。如果你希望补上缺的那一轮，最干净的做法是单跑一轮（不勾循环）、把它出的包按命名规则手工补上，再放开循环。

项目被删除会发生什么。循环还在跑，但它指向的目录已经不在了：每一轮都失败在"找不到路径"上，而且是连着失败，因为它不会自己去找一个新项目。这时去项目列表里看，那个项目已经没了。

这里有一个概念要说清：项目不是一个名字，是磁盘上那个 8 位随机字符串目录。重新导入同一个 APK 建新项目，会得到另一个 8 位目录名，它和旧项目在文件系统上没有关系；旧项目的 config.ini（签名设置、启动组件名）、history.ini（修改历史）、loop_task.ini（计数器）、source.apk（原始包备份），都跟着旧目录一起没了。

怎么恢复。重新导入原包建项目 → 重新配签名（自己的 jks / keystore 或 pem + pk8 文件还在你手里，重填一次就行）→ 重新设循环参数 → 放开。要注意两件事：编号会从头开始，用"数字后缀"命名的话先去发布目录看一眼已经用到几号，避免撞号；用"固定名"规则（前缀以 .apk 结尾）则同名直接覆盖——覆盖的是旧成果还是别人的成果，得你自己判断。

所以有一条很实用的纪律：循环在跑的时候，别去动项目目录。不要删、不要改名、不要挪位置、不要"清理一下看着乱的文件"。它不是一堆散文件，它是这个循环的锚点。

七、三处兜底：为什么它能自己把场面收住

讲完六种异常，回头看设计。有三处兜底，全都做在"接缝"上，值得一个一个说。

兜底一：每一轮都等 AI 改完才打包。机制很土：AI 改完在项目目录留一个标志文件，主窗口每 2 秒轮询一次，读到才弹打包窗口。土，但极其有效——它保证了打包永远不会打在"改到一半的工程"上。想象一下反过来的做法：定时打包，不管 AI 改完没有。那你得到的大概率是一堆回编失败，或者更糟——一个能编过但改了一半的包。前者浪费机器，后者浪费人。

兜底二：停止任务时，当前轮收尾。打包窗口和 AI 等候窗口都有「停止任务」。它的语义不是"立刻掐断"，而是"把手上的这一轮做完再停"。这个区别很重要：立刻掐断会留下一个写到一半的 signed.apk，而那个文件看起来和正常的成品没区别，很容易被当成能发的包；收尾再停，你拿到的是一个完整的、可用的产物，或者一个明确的"这一轮没成"。

兜底三：计数器存在 loop_task.ini 里，重启接着轮。这一条最不起眼，但它是"编号"这件事能成立的基础。计数器不在内存里，在项目目录的文件里，所以关掉软件、重启电脑、隔一天再开，它都还记得上一轮走到几。加上命名规则里的"数字后缀（可补零）"，你得到的就是一串连续编号的包：第 1 个、第 2 个……第 20 个。哪一天回头看，缺了第 15 个，一眼就知道断在哪。

工具能替你守着的，是那些"必须有人在场但不需要人思考"的时刻。它替不了你的，是那些"必须在场并且必须思考"的时刻——而恰恰是后者，决定了这批包能不能发出去。

除了这三处设计上的兜底，还有一条属于使用者的次序，值得写下来：先单轮跑通，再"真实上传一次测试"，最后才放开多轮。单轮跑通验的是"改得对、打得出来、装得上"；真实上传验的是"通道通、权限够、路径对"；两关都过，再交给夜里。这个次序不是软件的限制，是你对自己时间的尊重。

八、两个实例：以前、现在、校验

下面两个例子都发生在自家的、内部的应用上。故事的重点不在改得多复杂，而在"异常真的发生时，人是怎么把它接住的"。

实例一：夜里出包失败，第二天早上怎么查

背景。自家一套内部巡检工具，每个月要出 20 个渠道变体包，命名用"前缀 + 数字后缀、补零两位"。晚上十一点勾上循环，设 20 轮，间隔 60 秒，发布目录指向 D 盘，云存储配好。

以前。这件事得手工一轮一轮做：改一处、点打包、等窗口弹出来、复制产物、改名、上传、再来一遍。人必须守着，因为每一步都要点。守到第十几轮脑子已经木了，最容易出两种错：改名时手滑把 08 打成 09 撞了下一轮的号；复制时拿错文件，把上一轮的包当这一轮的传上去。更麻烦的是第二天——你只知道"昨晚出了 14 个"，说不出第 15 个为什么没出，因为当时没留下任何过程记录。

现在。勾上循环就能去睡。早上打开电脑，发布目录里 14 个包，编号 01 到 14 连续，15 之后没有。这时候按五步取证：

1. 数编号。01 到 14 连续，说明前面十四轮都是干净的、没有半途而废的。缺号从 15 开始，断点就定位到第 15 轮。
2. 翻 pack.log。看最后一段是不是完整的四步。如果它停在回编，问题在工程或磁盘；如果四步全齐、只差保存，问题在发布目录；如果根本没有第 15 轮的新段落，说明这一轮连打包都没开始，问题在前面。
3. 翻 apktool.log。回编失败的原因都在这里。常见的是资源引用断了、上一轮的改动留下了结构性问题。
4. 看盘的剩余空间。如果 pack.log 里出现写入失败，而盘只剩几百兆，那答案就摆在眼前。
5. 看 error.log 和进程记录。如果四份日志都在第 15 轮之前戛然而止、没有任何报错，那多半不是软件的问题，是程序被关了或者机器重启了——去看系统的事件记录，时间能对上。

那一次的结果是：第 15 轮回编失败，apktool.log 里报的是一个资源引用错误。原因是第 14 轮的需求里让它"删掉某个页面"，AI 把页面删了，但另一处布局还在引用它。前十四轮能出包，是因为这个引用直到第 15 轮才被编到。

校验。修法不是"再跑一遍"，而是先把工程修回来：补一句需求把那个引用一并处理掉，单跑一轮确认能出包；再看这一轮的包能不能装上、打开、进到目标页面；三件事都过了，才把循环放开，从第 16 轮接着跑（计数器记着 15，所以下一轮是 16）。第二天再数一次：编号 01 到 19 连续，20 个包少一个，少的正是断掉的那一轮——账对得上，这件事就算结了。

这个例子里最值钱的不是"找到了原因"，而是账能对上：编号连续、日志分段、缺号唯一，三样东西让你五分钟内知道发生了什么。

实例二：云存储密钥失效的那一次

背景。同一套巡检工具，包要发到云存储上给外地同事下载。某天公司统一调整了云账号的权限策略，把原来那个子账号的密钥轮换了。

以前。手工上传的年代，这个问题反而好发现——你点上传，它当场报错，你当场就知道。但代价是必须有人在场点那一下。如果改成"下班前批量传一批"，问题就变成第二天早上才发现：本地文件夹里 20 个包整整齐齐，云端一个都没有，而且你根本不知道是从第几个开始没传上去的。

现在。表现是：本地照常出包、照常保存，发布目录里的编号连续、文件大小正常，只有云端的对象列表停在昨晚十一点。发现路径就是"对数量"——本地 20 个，云端 9 个，差 11 个，说明从第 10 轮开始上传就失败了。这中间本地一点没耽误，所以最贵的劳动保住了。

处理分四步：重新签发一对只带这个 Bucket 写权限的密钥；在软件里更新上传配置；点"选一个文件真实上传一次测试"，把通道验通；验通之后才放开循环，把缺的那 11 个补传上去（可以直接用本地已有的包，不必重跑）。

校验。三重，缺一不可：一是数量对齐，本地 20 个、云端 20 个；二是抽样下载，从云端随手下一个回来，比对文件大小，能下回来且大小一致，才叫"真的传上去了"（只看列表里有个文件名不算）；三是再跑两轮，看新出的包能不能稳定传上去，验证这对密钥不是"只能传一次"。

这次之后加了一条规矩：凡是换过密钥、换过账号、换过 Bucket，都先用单文件真传一次，再放开循环。这条规矩的成本是一次点击，收益是省掉一整夜的无效劳动。

九、离开工位之后：手机上接住"发现"这一步

循环打包这件事本身是电脑版的活——它要长时间占着机器、要写盘、要上传，手机上做不了也不该做。但"发现异常"和"判断这一版行不行"这两件事，不该被绑在电脑前。

这里就是智能修改安卓版的位置：版本 V50.07.00.00，安装包约 7MB，支持 Android 10 及以上，首次启动按需准备一次运行环境，之后反编译、改包、回编、对齐、签名全在手机本地完成。它的用法很具体：写一句中文需求点「立刻修改」，AI 自动动手；内置 3000 条话术模板、六大分类，点一条就填进需求框；改完自动打包，产物可装到本机、一键分享到微信或 QQ、或另存到「下载」；每次需求都记进项目历史，回头能查。

放在"无人值守"这个语境里，它的价值有三层：

• 验证不被拖延。晚上跑出来的包，如果只能等第二天到工位才装上看，那一整夜的 20 个包就有可能全是同一个问题。手边有手机，随手装一个，五分钟就能判断"这批能不能用"。
• 需求可以在现场改。白天在外面看到问题、想到一句更准的说法，手机上直接改一版、装上看效果。晚上回工位，把这个已经验证过的说法原样丢进循环，跑出来的 20 个包就是对的版本，而不是"想法还没验过就批量生产"。
• 小批量的活不必开机。临时要一个改动、只出一两个包，手机上做完就发了，不用为了两分钟的事启动一套桌面流程。

所以两个版本的分工可以说得很干脆：手机负责"接住"，电脑负责"批量"。循环在夜里跑着的时候，手机是你离开工位之后仍然能"判断"的那一端；而当你需要连续出二十个包、需要写盘、需要往云上传的时候，还是得回到电脑前，把循环勾上。

十、常见问题

Q1：循环跑到一半我按了「停止任务」，这一轮会不会只出半个包？

不会。这个按钮的语义是"当前轮收尾"，不是"立刻掐断"。它会把手上的这一轮做完再停，所以你拿到的是一个完整的产物，或者一个明确的"这一轮没成"。这个设计的意义就在于不留下"看起来像成品、实际是半成品"的文件——那种文件最容易被误发出去。

Q2：计数器存在哪？我删了会怎样？

存在项目目录下的 loop_task.ini 里。删掉它，计数就会从头开始，编号会从 1 重来，可能和发布目录里已有的包撞号。如果用的是"固定名"规则（前缀以 .apk 结尾），同名会直接覆盖。所以除非你确认要重来一遍，否则别动这个文件。

Q3：AI 这一轮改失败了，会不会把一个坏包传到云上？

不会。AI 没改完就不会留标志文件，主窗口等不到标志就不会弹打包窗口，打包不开始就没有产物，也就谈不上上传。这一轮是一次空转：浪费时间，不污染数据，编号也不往前走。等到 1 小时上限，界面会明确写"已停止等待"，把判断权交回给你。

Q4：命名规则选"固定名"会不会把之前的包覆盖掉？

会。前缀以 .apk 结尾就是固定名，同名直接覆盖。这个规则适合"只保留最新一版"的场景，比如某个固定下载地址背后的包。如果你要留每一轮的历史，就选"前缀 + 毫秒时间戳"或"前缀 + 数字后缀（可补零）"——后者配合 loop_task.ini 的计数器，能得到一串连续编号，最适合事后核对。

Q5：磁盘满了，软件会自动换一个盘吗？

不会。自动挑盘只在启动时做一次：按 D→E→F→G→C 的顺序找第一个可读写、剩余不小于 1GB 的盘，拼成 <盘符>:\AiApkEditor。跑起来之后盘满了，它不会自己搬家——搬家要停任务、要你确认新路径。所以开工前按"轮数 × 单包体积 × 3"估一遍剩余空间，是使用者该做的那一步。

Q6：云存储密钥失效了，本地出的包还在吗？

在。上传失败只影响远端，本地发布目录里的包是完整的，build 目录里也有。所以最贵的劳动（改包与打包）保住了，损失的是"传输"这一环。补传的时候直接用本地已有的包就行，不必重跑一遍循环——重跑反而会多消耗时间和配额。

Q7：程序被关掉再打开，会从第几轮接着跑？

从计数器停在的那个值接着。计数器在项目目录的 loop_task.ini 里，重启不会清零。被掐断的那一轮不会自动补做，所以总数会少一个——这是"不做假账"，它没有假装那一轮完成了。要补的话，单跑一轮、手工按命名规则补上，反而更干净。

Q8：我怎么知道一共出了几个、缺了哪几个？

三样东西对一下就行：发布目录里按编号排序数文件；pack.log 里数"每轮一段"的分段；历史里数需求条数。三者一致说明账是平的；差一个，缺号的位置就是断点。这套核对方法不需要读懂任何报错，只要会数数。

Q9：我只想存本地、不传云，可以吗？

可以。九种云通道之外，还有"只存本地"这一档。适合包不往外发、或者走别的渠道分发的场景。少了上传这一环，"密钥失效"这类异常自然也不存在了——但"发布目录不可写"和"磁盘写满"这两条依然要防，因为它们发生在更前面。

十一、用户怎么说

"第一次开循环我特别紧张，怕它半夜出事没人管。后来发现真正会出事的地方就那么几处，而且每一处都能从编号和日志里查出来。现在我敢在睡前点开始了，因为我知道明早该看哪三样。"

—— 老周 · 安卓逆向爱好者

"我被磁盘写满坑过一次，跑 18 轮断了 5 轮。后来学乖了，开工前先看一眼剩余空间，按轮数乘一乘。这个动作三十秒，省掉的是第二天重跑一整晚。"

—— 阿凯 · 测试工程师

"公司换云账号权限那次，我压根没收到通知。本地出了 20 个包，云端一个没有。要不是顺手点开控制台看了一眼，这批包就白等了。现在换密钥我一定先单文件真传一次。"

—— 阿灿 · 工作室打包执行

"最让我服气的是'停止任务'那个语义。以前用过别的批量工具，一按停就留一堆半截文件，还得自己分辨哪个能用。这个是把当前轮做完再停，我拿到手就知道能不能发。"

—— 麦子 · 电商运营

"我删过一次项目，想清理一下目录看着清爽。结果循环一直在失败，我以为是软件坏了。后来才明白那个 8 位目录就是项目本身。教训是：跑着的时候手别欠。"

—— 小林 · 独立开发者

"我们出渠道包，一次十几个，靠的就是数字后缀加补零。哪个月少了一个，数数编号就知道。这个'能对账'的感觉，比任何花哨功能都实在。"

—— 苏苏 · 企业行政

"我现在的习惯是：白天在手机上把说法验一遍，晚上回家把它丢进循环跑批。手机验的是'对不对'，电脑跑的是'多不多'。分工清楚之后，返工少了很多。"

—— 栗子 · 高职学生

"我给学生讲自动化，最爱拿这个循环当例子。它没有假装自己不会出错，而是把每次出错的损失控制在一轮以内。这个思路比'保证不出错'可靠得多。"

—— 沈老师 · 高校讲师

十二、写在最后：把守着的时间省下来，把判断留下来

把这篇的脉络收一下。循环打包正常走五步：AI 改完留标志 → 自动打包四步 → 按命名规则存到发布目录 → 上传云存储 → 立即或等 N 秒下一轮。六种异常全都长在三个接缝上：AI 与打包之间、打包与保存之间、保存与上传之间。

六种异常一条线穿下来：前四种都长在接缝上，损失只在一轮以内；后两种是外部动了手——程序被关掉要小心残留的标志文件，项目被删除则等于换了一个锚点，旧的签名、历史、计数器都跟着旧目录走了。

三处兜底把场面收住：每轮等 AI 改完才打包，所以永远不会打到改到一半的工程；停止任务当前轮收尾，所以不会留下半个包被当成成品；计数器存 loop_task.ini，所以重启之后编号接着走、不撞不覆盖。它们的共同点不是"防止出错"，而是"让出错的损失有边界"。

这就回到那句核心的话：自动化省的是人守着的时间，不是人判断的责任。它让你不必在深夜盯着进度条，但它没有、也不该替你决定"这一版能不能发"。你可以在它跑的时候去睡觉、去陪家人、去干别的活——这是它给你的；你第二天早上要看编号、翻日志、判断断在哪、决定要不要接着跑——这是它留给你的。前面那半是效率，后面那半是分寸。

只需说话，就能让应用变成你想要的样子——这句话在无人值守这件事上，还有一层意思：话是你说清楚的，活是它干完的，判断还是你做。三者各归其位的时候，工具才真的省时间；任何一环想偷懒，省下来的时间都会以别的方式还回去。

如果你还没试过循环打包：安卓修改大师智改工坊旗下智能修改电脑版的介绍与下载入口在 https://www.apkeditor.cn/ai-version.aspx，官网 www.apkeditor.cn。今晚先拿一个自家的包、跑一轮、真实上传一次，把这条链验通；明天再谈 20 轮的事。