循环发布的文件名引擎：每次出包叫什么，谁说了算

一、从那个勾选框说起

入口在详情页的「保存参数设置」面板：勾上「循环打包去毒」，右边浮现「任务设置」按钮，点开就是这台引擎的驾驶舱。先把位置感建立起来：这里的每一项参数——发布目录、发布文件名、云存储、任务调度——都是每个项目单独一份，存在各自项目目录的 loop_task.ini 里。A 项目用时间戳、B 项目用固定名，互不干涉；换台电脑拷走项目目录，设置也跟着走。

还有一道必须先讲的防线：这个勾选框每次打开详情页都默认不勾。为什么这么设计？设想你上个月给某项目配过一整夜的循环任务，今天打开它只想改个小图标——如果勾选状态被记住，点「立刻修改」的瞬间就会意外触发一轮又一轮的自动发布。默认不勾，等于每次都要你亲手确认「我知道我要干什么」。无人值守是重武器，重武器的保险栓，永远由人亲手打开。

理解了这道防线，再看参数的存留规则就顺理成章：发布目录、文件名、云存储、调度这些参数会保留——它们是「怎么干」的说明书，记住无害；唯独「干不干」这个总开关每次归零——它是扳机，扳机不能替你扣。一套参数两种待遇，这个细节把「效率」和「安全」的边界划得干干净净。

二、引擎的四条命名规则

「发布文件名」这一栏是整台引擎的核心。它不是让你填一个死名字，而是给你一套规则系统——你只写一个前缀，剩下的交给规则。四条规则按优先级依次判定，先把全表摆出来：

你怎么填	引擎怎么命名	适合什么场景
前缀留空	沿用签名后 APK 的原文件名	不在乎历史版本，省事
前缀以 .apk 结尾	原样作为固定文件名（同名覆盖）	对外分发的「始终最新」地址
勾了时间戳	前缀_当前毫秒时间戳.apk（优先于数字）	每一版都要留档、永不撞名
数字后缀个数大于 0	前缀_1..N 循环，按补零长度补零	定期清灰、目录不无限膨胀
以上都不是	前缀.apk（固定名）	简单场景的兜底

判定顺序有讲究：先看前缀是不是空，再看是不是以 .apk 结尾，然后时间戳优先于数字后缀——两者同时配置时，走的是时间戳。最后如果勾了「转大写」，整条文件名连扩展名一起转成大写。规则不多，但组合出来的花样足以覆盖循环发布的所有常见需求。后面几节把每条规则单独拆开讲。

三、留空：让原名自己说话

最省事的填法是什么都不填。前缀留空时，引擎沿用签名后 APK 的原文件名——也就是打包流水线产出的那个名字，通常带着应用名和版本号。这条规则的潜台词是：每个包生下来就有个像样的名字，引擎尊重它，不添乱。

留空适合什么人？适合「我只关心最新版」的用户。循环跑十轮，发布目录里每次都是那个熟悉的名字，旧版被新版顶掉——你永远知道最新版在哪，代价是历史版本不落地。它和后面讲的「固定文件名覆盖」殊途同归，区别在于名字的来源：一个继承自打包产物，一个由你钦定。

这条规则还有个隐性好处：发布出去的文件名和应用本身的身份天然一致。给同事传包、给测试装机，文件名即说明——「这是哪个应用的哪个版本」，不用额外解释。命名这件事，工具能定的就别麻烦人，而「沿用原名」是其中最没存在感、也最不会出错的一种定法。

四、同名覆盖：云端的「始终最新」

第二条规则是分发场景的王牌：前缀填一个以 .apk 结尾的完整名字，比如 myapp_vip.apk，引擎就把它原样作为固定文件名。每次发布都叫这个名字，后浪推前浪，新包覆盖旧包。

它的威力要在云存储上才完全释放。所有云存储的上传都是同名覆盖同一个位置——固定文件名时，用户从你给的下载地址拿到的，始终是最新一轮发布的包。你半夜改了个需求重发，客户的手机上明天打开的还是那条链接，内容已经悄悄换了新。地址永远不变，内容永远最新，这就是固定名覆盖的全部魔法。

注意它和「留空沿用原名」的微妙差别：留空时名字跟随打包产物，版本号变了名字就变；固定名则彻底和版本脱钩，名字钉死在你想钉的地方。前者适合自用留档，后者适合对外分发。选哪条，取决于这个包是给「存」的还是给「传」的。

五、时间戳：永不撞名的流水账

勾上「时间戳后缀」，文件名就变成前缀_一长串数字.apk——那串数字是当前时刻的毫秒级时间戳。它的第一美德是永不撞名：两次发布之间哪怕只隔一秒，时间戳也几乎不可能相同，循环跑一百轮，一百个包并排躺好，谁也不覆盖谁。

这让它成为留档场景的首选。调试期的循环任务，每一轮的产物都可能包含不同的尝试，时间戳名天然按时间排序——发布目录本身就是一本流水账，翻目录等于翻历史。想回溯「第三轮改完是什么样」，按文件名找时间点就行，比任何笔记都直观。

代价当然也有：目录会持续膨胀。百轮循环就是上百个文件，长期任务用时间戳，最好配一条定期清理的纪律——比如每周归档一次、只留里程碑版本。时间戳名是「全都要」的选择，全都要，就得自己动手断舍离。

六、数字轮换：N 格循环与补零的美学

时间戳管「全都要」，数字轮换管「要最新几个」。配置两项——循环个数 N 和补零长度——文件名就变成前缀_01、前缀_02……一路排到前缀_05（如果 N 是 5），然后回到 01 重新来过。发布目录里永远只有最近 N 个包，新包顶掉最老的那个，目录大小恒定。

轮换的接力棒藏在 loop_task.ini 里一个叫 CurrentFileCounter 的字段：每发布一次前进一格，走到 N 归一。最妙的是它重启后接着轮换——今天发到 03，明天开机继续 04，不会因为关机重头再来。这个不起眼的小字段，让「昨天的包」和「今天的包」生活在同一条时间线上。

补零长度则是强迫症福音：设成 2，个位数也写成 01、02——文件名等宽，目录里排序整整齐齐。别小看这个细节，轮换到第 9 和第 10 个文件时，有补零的目录依然是漂亮的一列，没补零的目录里 10 会排在 2 前面。工具对秩序的尊重，往往就藏在这类一眼看不见的地方。

七、实时预览：填参数时就能看到下一个名字

任务设置窗口里有个小功能值得单独一节：实时预览下一个文件名。你在这头改前缀、勾时间戳、调循环个数，窗口那头当场把「按当前配置，下一个包会叫什么」渲染出来。

为什么这个小功能重要？因为命名规则的组合是有理解成本的——「前缀以 .apk 结尾是固定名」「时间戳优先于数字」这些判定，纸上读十遍不如眼看一遍。有了实时预览，配置过程变成了「试出来」而不是「背出来」：改一项、看一眼，名字符合预期就收工，不符合立刻能发现是哪项在作怪。把验证从「发布之后」提到「配置之中」，这个设计省掉的是一整轮试错。

建议的配置节奏也因此成型：改一项参数，扫一眼预览；全配完，拿预览的名字和心里的预期对一遍；对上了，再走第八节讲的测试上传。配置、预览、彩排、开跑——四步走完，无人值守才敢真的无人。

八、发布目录与十种发布方式

名字定了，包发往哪？「发布目录」先接住它：打包产物先保存到这里，目录不存在会自动创建，点「选择…」用文件夹选择框一指即达。本机留档到这一步就齐了；要上云，接着看发布方式那一排。

发布方式的选择之多可能会超出你的预期：本地发布目录、阿里云 OSS、亚马逊 S3、腾讯云 COS、华为云 OBS、百度云 BOS、Minio、金山云 KS3、七牛云、FTP——十种。选哪个，窗口就显示哪个的配置字段：Endpoint、Bucket、AK、SK、Region、端口，各就各位。国内云、海外云、自建 Minio、老牌 FTP 全都照顾到了——这个清单本身就是一张「用户在哪存包」的地图。

选型的常识顺带一提：个人和小团队分发，对象存储（OSS/COS/S3 那一族）性价比最高，配好 AK/SK 就能覆盖上传；有内网机房的老单位，FTP 和 Minio 是最常见的存量通道。无论哪条路，循环发布的动作对它们一视同仁：按规则命好名，覆盖同名位置，完事。

九、测试上传：开跑前的彩排

云存储参数填好了，怎么确定没填错？靠「测试上传」。选任意一个文件，程序用当前云存储参数真正上传一次——不是连通性 ping，是真刀真枪的完整上传。传上去了，说明地址对、权限对、密钥对；传不上去，错误当场报出来，改完再试。

这个按钮的两个边界设计得很细：测试按原文件名上传，不在你的命名规则管辖之内；也不把文件复制到发布目录、不推进计数器——彩排就是彩排，不污染正片的任何痕迹。数字轮换发到 03，测一次上传，下个包还是老老实实从 04 开始。彩排和正式演出之间隔着一堵墙，这堵墙让「随便测」变成零心理负担的动作。

把测试上传放进整个开跑前的流程看：配参数看预览，是确认「名字对不对」；测试上传，是确认「路通不通」。两件事都绿了，无人值守才托付得出去。循环任务一跑几十分钟甚至一整夜，起跑线上多花两分钟彩排，是整个流程里回报率最高的两分钟。

十、任务调度：立即下一轮，还是喘口气

任务调度只有一道选择题：打包并上传完毕后，立即通知 AI 开始下一轮，还是等待 X 秒再通知。默认节奏是立即——循环的密度拉满，机器不休息。

那「等 X 秒」给谁用？给「轮与轮之间需要留观察窗口」的任务。比如你开着打包窗口盯着每一轮的产出，间隔几秒的喘息让日志可读、让确认来得及；再比如云存储有带宽顾虑，错峰发布能给同网络的同事留条活路。X 秒不是拖延，是给流程里的人类观察员留的座位。

顺带讲清循环的记账规则，它是理解调度的基础：第一轮发需求时照常记录修改历史、照常计费——那是一次真实的「表达」；后续每一轮都是 AI 按同一段需求自我接力，不再写历史、不再计费。首轮立账、后续白跑，这个设计让长循环的成本可预期——你为需求付一次钱，不为循环次数付钱。

十一、循环怎么自己转起来

文件名是零件，整台机器怎么转？花一节讲全景。第一轮由「立刻修改」点火：需求连同「这是循环任务」的约定一起发给 AI。此后每一轮，AI 改完在项目目录里留下完成信号，主窗口看到就自动打包——回编、对齐、签名四步走完，按任务设置把包复制进发布目录、改上规则名、传上云，然后写一个「继续」信号通知 AI 开始下一轮。AI 取走信号，按同一段原始需求继续干活。如此往复，直到你喊停。

这套「信号接力」最怕的是断棒——信号没人接，循环卡死。程序为每个薄弱点备了兜底：AI 没按约定等信号，主窗口发现信号两分钟没人取走，会自动退回「重新发送需求」的老办法，循环不中断，只是那一轮多等两分钟；AI 会话写到上下文满了要换新会话，主窗口会在本轮发布完成后自动把同一段循环需求重新发进去；打包失败、发布失败、等待超时，任何一环出了错都自动停止循环，原因写进详情页和打包窗口——要么转下去，要么明明白白地停，绝不明不白地卡住。

每轮信号还带着专属令牌——不同循环任务、不同 AI 会话各有各的标记，换会话时给旧令牌写停止标志，旧会话不会抢走新会话的下一轮。这些护栏用户全程无感，但正是它们撑起了「放心离开电脑」这六个字的分量。

十二、四种喊停的方式

无人值守的另一半话题是怎么停。第一种：打包窗口左下角的「停止任务」。循环期间这个窗口一直保持打开，打包中、上传中、等待下一轮的倒计时中，任何时刻都能点。点了之后本轮已经开始的打包上传会先收尾——不会留半个包在云端——然后不再发布、不再开下一轮，干净利落。

第二种：AI 等候窗口里的「停止任务」。循环任务的轮次里，这个窗口原来的「取消修改」会换成「停止任务」，点了同时停掉 AI 的生成和整个循环——AI 正在改到一半也不要了，最彻底的急停。第三种：详情页取消勾选「循环打包去毒」，等价于停掉这个项目正在跑的循环，而且只停这个项目，别的项目不受牵连。

第四种最容易被忽略：循环跑到发布和等待阶段，打包窗口是可以关掉的——关掉不等于停止，任务在后台继续。这时候顶部状态栏会出现「循环任务中」，点它能把打包窗口重新唤出来（停止按钮就在里面）。这个设计解决的是「窗口占地方」和「任务要盯梢」的矛盾：窗口随叫随到，任务从不失踪。

十三、重启之后：任务不续跑，参数全都在

一个很实际的问题：程序退出、电脑重启之后，循环还在吗？不在。循环不会在重启后自动续跑——这是有意为之的保守选择：无人值守的前提是「有人确认过要无人」，重启之后那个人不在场，机器就不擅自开工。同理，项目被删、工作目录不可写，也会结束循环。

但所有参数都在。发布目录、文件名规则、云存储密钥、调度间隔，一项不少地躺在 loop_task.ini 里；数字轮换的 CurrentFileCounter 也守着上次的进度。想续上，只需回到详情页，勾上「循环打包去毒」，再点一次「立刻修改」——循环从断点处的参数原样接续。停的是任务，存的是全部记忆。

把这个行为和「默认不勾」放在一起看，逻辑就完整了：参数持久化让重启无损，开关不持久化让重启无险——记忆归记忆，扳机归扳机。一套配置系统的分寸感，全在这两句话里。

十四、一条安全提醒：密钥在本机明文

有一件事必须用单独一节讲清楚：云存储的 AK/SK 密钥，和参数一起以明文保存在本机的 loop_task.ini 里。这换来了配置的随拷随用，也立下了一条使用纪律——别把配置了云存储的项目目录发给别人。项目目录平时是改包的工作区，配了循环任务之后，它同时是一串能打开你云仓库的钥匙。

三条实操建议：给循环任务用专用的最小权限密钥——只开目标 Bucket 的写权限，不碰主账号密钥；换密钥时在云控制台直接作废旧密钥，再回任务设置里填新的；需要分享项目成果时分享发布出来的包和下载地址，而不是项目目录本身。密钥安全这件事，工具把选择权给了你，你就要行使好它。

顺带回应一个常见担忧：明文本地保存会不会不安全？对单机工具而言，密钥落在本机配置文件是行业常态，风险边界在于「谁能拿到这台机器的文件」。管好自己的项目目录，就管好了自己的密钥——这句话反过来读也成立。

十五、实战例一：固定名分发的白名单客户

把规则放进真实场景。例一：工作室给十几家白名单客户定制同一款自有应用，每家的包名、图标、启动页不同，改完发到各自的下载地址。做法：每家客户一个项目，发布文件名填成以 .apk 结尾的固定名（比如 shoppe_client_a.apk），发布方式选客户的对象存储。此后每次内容更新，勾上循环跑一轮，云端同名覆盖——发给客户的下载链接从第一天起就没变过，客户永远拿到最新版。

这个例子 里文件名引擎扮演的角色是「地址管理器」：固定名让分发地址成为可以印在合同里的稳定资产。要是用时间戳名，每次更新都得给客户发新链接，十几家客户几轮更新下来，聊天记录里全是链接灾难。分发场景选名字的第一原则不是记录，而是稳定——固定名覆盖是为它而生的。

十六、实战例二：数字轮换的回归防线

例二：内测团队用循环任务做「每轮改完自动出一版安装包」的回归验证。要求：每个版本可回溯、但目录不许无限膨胀。配置：前缀填 app_nightly，数字后缀循环个数 10、补零长度 2——发布目录里永远躺着 app_nightly_01 到 app_nightly_10 共十个包，每轮新的顶掉最老的，最新的永远在，最老的自然淘汰。

配合 CurrentFileCounter 的断点续轮，这套防线跨天也成立：周一发到 06，周二开机接着 07——文件名的序号和真实的时间线严丝合缝。测试同事要「昨天下午那个版本」，翻目录按序号一指就到。十个版本的窗口期，既是回溯的余量，也是自动清理的纪律，要留几个、留多久，一个数字说了算。

十七、问答四连

问一：时间戳和数字后缀同时勾了，走哪个？走时间戳——它的优先级更高。想用数字轮换，就别勾时间戳；想两个都要，建议分两个项目各配各的。判定顺序在第二节那张表里，配置时对照实时预览看一眼最保险。

问二：前缀不以 .apk 结尾，也没勾后缀，会叫什么？前缀加 .apk——直接拿你填的词当文件名主体。这个兜底规则最朴素，也最容易踩「以为是固定名覆盖」的坑：前缀不加 .apk 结尾时它不是覆盖式固定名，请务必以窗口里的实时预览为准。

问三：循环中途改文件名规则，会乱吗？新规则从下一次发布开始生效，已发布的文件不受影响。数字轮换的计数器不会重置，还是从上次进度接着走。担心新旧混排的话，发布前先清一遍发布目录，或换一个新前缀让新旧文件天然分区。

问四：本地发布目录模式下，循环还成立吗？成立。本地模式只是少了「上传」这一步——每轮照样打包、改名、落进发布目录，AI 照样接下一轮。没有云存储的用户照样能享受无人值守的打包流水线，云只是选项，不是门槛。

十八、和「自动保存到桌面」的分工

电脑版里其实有两条「出包之后去哪」的通道，容易混为一谈。第一条是「保存参数设置」里的「自动保存到桌面」：每次打包完，往桌面拷一份签名包，名字是应用名_版本号_signed.apk——这是给人看的通道，桌面就是你的工作台，拿起包就能装机。第二条是循环发布的发布目录通道：按规则命名、按配置上传——这是给机器和分发用的通道，讲秩序、讲稳定、讲无人值守。两条通道不冲突也不替代。循环任务跑起来时，桌面照样收它的「应用名_版本号」，发布目录照样落它的规则名——一份给你随时取用，一份给流程自动流转。理解成「人通道」和「机器通道」，分工立刻清晰。实际用起来的小建议：循环任务期间关掉「自动保存到桌面」。一整夜几十轮下来，桌面会垒起几十个同名或近名的包，最后互相覆盖或者淹没了你的工作台。桌面通道属于「人盯着的时候」，机器值夜班，就让它只走发布目录那条线。

十九、转大写：一个为特殊场景留的开关

文件名规则里还有个不起眼的勾选项：文件名和扩展名转大写。勾上之后，shoppe_vip.apk 变成 SHOPPE_VIP.APK——连扩展名一起转。日常场景用不上它，那它为谁而设？一类是某些老系统的兼容要求——历史上有不少平台和中间件只认大写文件名，或者对大小写敏感得寸步不让；一类是渠道规范——部分内部分发渠道对上传文件的命名有硬性格式要求，大写是最常见的一条。工具没法预知你会遇到哪种，干脆把开关交给你，需要时一勾即达。这个开关的存在提醒我们一件事：文件名引擎的每条规则都不是随手的装饰，而是从真实分发场景里长出来的需求。留空、固定、时间戳、轮换、大写——五个构件，拼出的是一套能应对各种奇怪甲方的命名语法。

二十、多项目并行的命名策略

前文说过，循环任务的参数每个项目单独一份。这个设计在多项目并行时价值翻倍：十个项目就是十套独立的文件名规则、十份计数器、十条发布通道，彼此绝缘。但工具给了你分仓库的能力，「怎么分」还得自己规划。给三条多项目命名策略。第一条，前缀带项目身份：哪怕发布目录各不相同，前缀里也建议带上应用标识——shoppe_nightly_01 和 mall_nightly_01 永远不会认错，哪天你把两个目录的包挪到一起做归档，前缀就是天然的出生证明。第二条，发布目录按项目分家：一个项目一个目录，别让十个项目的产物挤一个屋檐——目录一旦混居，轮换清理就会误伤邻居。第三条，循环个数按项目价值定：核心项目留十个版本不嫌多，边缘实验留三个足够——CurrentFileCounter 各自独立，互不牵连。多项目并行的本质是「把命名当成目录管理的一部分来设计」。文件名引擎给了你零件，架构图还得自己画——画好之后，几十个项目同时转起来，发布目录依然清爽得像刚整理过的书房。

二十一、什么时候不该用循环

讲了这么多循环的好处，得用一节泼冷水：不是所有任务都值得无人值守。第一种不该用的：单次修改。改个图标、换句文案，一轮就完事的需求，走普通流程点一次「立刻修改」就是最优解——上循环等于开卡车去买菜，setup 的成本比任务本身还高。第二种：需求还不稳定。循环任务里 AI 每一轮都按同一段原始需求接力——需求写歪了，循环会忠实地把歪的方向重复几十遍。所以循环开工的前提是需求已经验证过：先手动跑一轮、装包确认效果符合预期，再把这个「已验证的需求」交给循环去量产。拿未验证的需求开无人值守，是对自动化最大的误用。第三种：需要人眼判断的迭代。有些改包的下一步取决于上一步的实际效果——「启动页改成什么样」要看上一版装出来的样子——这种每轮都需要人类决策的任务，循环帮不上忙，老老实实一轮一轮手动来。循环擅长的是「重复」，不是「判断」。

二十二、实战例三：时间戳留档的复盘现场

例三回到时间戳。一次真实事故：内测包上线三天后用户反馈「闪屏页面偶尔白一下」，但测试环境怎么都复现不出来。幸好那三天的循环任务用的是时间戳命名——发布目录里三十多个包，按时间排得整整齐齐。做法：二分法回溯——拿中间时间点的包装机测试，白屏就把范围往前推，不白就往后推，四五个包试下来，问题锁定在某天下午两点之后的第一版。再对照那轮的修改历史——当天下午改的正是启动页的加载逻辑——问题和改动对上了，回滚那一处逻辑，白屏消失。整个定位过程不到一小时，靠的就是时间戳名留下的完整版本切片。要是当时用的是覆盖式固定名，白屏出现之前的版本早没了，这种「回不去了」的排障要多花十倍力气。这个故事给时间戳规则的定位下了注脚：它不只是「不撞名」，更是过程的证据链。凡是你觉得「以后可能要回头看」的任务，发布名就该选时间戳——存证的价值，永远在出事的那天才显现。

二十三、问答再四连

问五：云存储上传失败了怎么办？自动停止循环，失败原因写进详情页和打包窗口。不会无限重试，也不会假装成功。看到提示后检查网络和密钥，修好后重新点「立刻修改」接上——参数和计数器都还在，损失只是中断的那几轮。问六：能不能只存本地、不上传云？能。发布方式选「本地发布目录」就是纯本地模式：每轮打包、按规则命名、落进发布目录，不上传任何东西。云存储只是十种方式之一，没有云照样循环。问七：中途换云存储参数，旧文件会动吗？不会。已发布到旧地址的文件原地不动，新参数从下一次上传开始生效。稳妥做法是换参数前先点一次「测试上传」，确认新路通了再让循环接手。问八：循环任务能和「打包后自动运行」同时用吗？技术上不冲突，但通常没意义——自动运行每轮都往模拟器装一次、拉起一次，几十轮下来你的模拟器会忙到没空干别的。循环任务的关注点在「产出发布」，验证交给发布渠道那头；想让循环安静跑，就别叠这个勾。

二十四、用户怎么说

反馈里出现最多的词是「讲究」——一个文件名而已，居然配了四种规则加实时预览。用户嘴上说着「至于吗」，手上都诚实地把发布目录越理越顺——被讲究的工具伺候过，就回不去将就的日子了。

二十五、文件名里的版本哲学

把四条规则连起来看，会发现它们其实在回答同一个问题的四种答案：版本之间是什么关系？固定名覆盖的回答是「新换旧」——只有现在，没有历史；时间戳的回答是「并列」——每一版都是独立的存在，谁也不顶替谁；数字轮换的回答是「滑动窗口」——保留最近 N 段记忆，更早的随风而去；留空的回答是「跟随」——版本叫什么，产物生下来叫什么。这四种关系没有高下，只有合不合身。对外分发的下载地址要「新换旧」，调试复盘要「并列」，长期夜跑要「滑动窗口」，随手自用「跟随」就好。选规则之前先问自己一句：这些版本之间，我希望是什么关系——答案一出口，规则就定了。再往深一层：文件名是你对版本管理态度的最小表达。很多团队的版本混乱不是从流程开始的，是从「v2_final_真的最终版.apk」这种名字开始的。文件名引擎的价值，说到底是把版本关系的决定从每次发布时的临时起意，提前到配置时的一次深思——想一次，管百次。

二十六、发布目录的卫生习惯

规则再好，也需要几条使用纪律来配套。给发布目录立三条卫生习惯。第一条，一个项目一个目录。哪怕前缀已经带了项目名，目录层面也建议分家——混居的目录里，一个项目的轮换清理可能误删另一个项目的存证，两个互不相识的循环在同一个屋檐下打架，输的永远是你的数据。第二条，定期归档而不是定期删除。时间戳目录膨胀到影响心情时，别一把删光——把超过窗口期的包按月份打包压缩、挪进归档区。磁盘成本几乎可以忽略，而「某天突然要找三个月前的那个版本」这种事，发生的频率比所有人预想的都高。归档是删除的文明形态。第三条，目录里不留非产物文件。别把临时笔记、测试素材随手丢进发布目录——循环任务和你的文件管理习惯共享同一块地盘，地上杂物越多，自动化的车轮越容易颠簸。发布目录只放产物，是机器与人相安无事的基本公约。

二十七、循环任务上岗清单

最后送一份可以直接照着走的上岗清单。循环任务点火之前，六项过一遍：一，需求已验证——手动跑过至少一轮、装包确认过效果；二，文件名规则已定——对照实时预览确认下一个名字符合预期；三，发布方式已配——云存储选型、参数填写完毕；四，测试上传已通过——真传一次，路是通的；五，密钥最小化——专用子密钥、只写目标仓库；六，桌面通道已关——停止自动存桌面，避免值夜班的产物淹了你的工作台。六项全绿，回到详情页：勾上「循环打包去毒」，点「立刻修改」，循环开始。此后你要做的事只剩一件——隔段时间瞄一眼顶部状态栏的「循环任务中」，确认它还在转。什么时候想看细节，点它唤出打包窗口；什么时候想收工，左下角「停止任务」四字永在。这份清单打印出来贴在显示器边上也不过分。无人值守的全部秘密，就在于起跑前把有人时的谨慎一次做完——把人的判断前置，把机器的耐力后置，两者各展所长，这才是自动化该有的样子。

二十八、循环与话术库的配合

循环任务的第一轮，需求从哪来？很多人是一字一字现写的，其实工具里还备着一座弹药库——「话术列表」。那里存着大量现成的修改话术，详情页点「选择话术」，跳到话术列表页里挑一条，内容自动回填到输入框，改两个词就能用。常见的改法套路——换图标、改名称、调文案、去开屏——库里都有成熟措辞，措辞是无数前人踩坑磨出来的，比自己临场组织更不容易让 AI 理解偏。话术与循环的配合点在「第一轮」：循环的需求一旦发出就不再更改，后续几十轮都按它接力——所以这第一段话术值得用最讲究的版本。从库里挑一条骨架，套上你的具体参数（应用名、目标文案、附件说明），再手动跑一轮验证效果，验证过了才交给循环量产。「库里的措辞 + 你的参数 + 一轮验证」，这是循环需求的黄金配方。话术库本身还是可生长的：用出来的好话术，回头存进库里，下次同类任务直接复用。个人的话术库越用越厚，循环任务的起跑线就越垫越高——工具给的是基础设施，复利得靠自己攒。

最后提醒一个容易忽略的搭配细节：循环任务跑起来之后，输入框就不再是你和 AI 的通道了——后续每一轮由信号接力自动完成，中途在输入框里打的字不会进入循环。想调整循环中的任务，正确姿势是先停止、再改需求、再重新点火。把「输入框属于第一轮」这件事想清楚，就不会出现「我明明发了新需求它怎么不理我」的困惑——它不是不理你，是它正在专心跑你上一句托付的事——这份专注，正是循环任务最可靠的品质。

顺带一提，话术列表和任务设置是详情页之外的两位好搭档：一个管需求怎么写，一个管产物怎么发。开头和结尾都讲究了，中间交给 AI——一条循环任务的完整链路，每一段都有各自的讲究之处，讲究到位了，无人值守才名副其实，人也才真正省心省力，把时间留给更值得做的那些事情上。

二十九、写在最后

留空沿用原名、固定名同名覆盖、时间戳流水账、数字轮换恒定窗口——四条规则四种性格，背后是四种真实需求：省事、稳定、留档、防膨胀。加上实时预览的即时确认、测试上传的彩排兜底、十种发布渠道的各奔前程，这台文件名引擎把循环发布里最琐碎的一环，做成了最省心的一环。

安卓修改大师智改工坊家族还有两位成员：智能修改安卓版装在手机和平板上，走到哪儿改到哪儿；经典版把反编译树完整摊开，资深玩家逐层动手。产品介绍页：https://www.apkeditor.cn/ai-version.aspx。只需说话，就能让应用变成你想要的样子。